Posts
-
RFC 793 vs RFC 9293, 뭐가 왜 바뀌었나
기본 단계에서는 “TCP는 이렇게 동작한다”고 설명하고 넘어간 것들이 많습니다. 심화 단계는 그걸 원문으로 검증하는 구간입니다. 첫 글은 스펙 자체부터 봅니다 — TCP의 원본 명세인 RFC 793(1981)과, 그걸 대체한 최신 명세 RFC 9293(2022) 사이에는 41년의 간격이 있습니다. 그동안 뭐가 왜 바뀌었을까요.
-
연결 종료 - 4-way handshake와 TIME_WAIT
지난 글까지 연결을 맺고, 데이터를 주고받고, 혼잡을 피하는 법을 봤습니다. 기본 단계 마지막인 이번 글은 연결을 어떻게 끝내는지를 다룹니다.
-
혼잡제어, 큰 그림
지난 글에서 “패킷이 유실되면 재전송한다”까지 다뤘습니다. 그런데 애초에 왜 유실이 일어날까요? 대부분은 네트워크 중간의 라우터가 처리 용량을 넘는 트래픽을 받아서 패킷을 그냥 버리기 때문입니다. 이번 글은 이 문제, 혼잡제어(congestion control)를 다룹니다.
-
신뢰성 보장 - ACK와 재전송
지난 글에서 흐름제어는 “얼마나 보낼지”를 조절한다고 했습니다. 이번 글은 다른 질문입니다: 보낸 데이터가 실제로 도착했는지, TCP는 어떻게 알까요?
-
데이터 전송과 흐름제어
지난 글에서 연결을 맺었습니다. 이제 데이터를 주고받을 차례인데, TCP는 한 번에 몽땅 보내지 않습니다. 왜 그런지, 그리고 얼마나 보낼지는 누가 정하는지를 봅니다.
-
연결 수립 - 3-way handshake
지난 글에서 TCP 연결은 5-tuple로 식별된다고 했습니다. 이번 글은 그 연결이 실제로 어떻게 맺어지는지를 다룹니다. 다들 한 번쯤 들어봤을 “3-way handshake”입니다.
-
포트와 소켓 - 연결을 식별하는 방법
지난 글에서 TCP는 IP 위에서 동작하며, 연결이라는 상태를 맺고 유지한다고 했습니다. 그런데 IP 주소 하나로 컴퓨터 한 대는 찾아갈 수 있어도, 그 컴퓨터 안에서 어떤 프로그램에게 데이터를 전달해야 하는지는 아직 정해지지 않았습니다. 이번 글은 그 문제를 다룹니다.
-
TCP란 무엇인가
뇌절의 첫 시리즈 주제, TCP입니다. 로드맵에서 예고한 대로, 이번 글은 기본 단계의 첫 번째 글이라 아주 기초적인 질문부터 시작합니다: TCP가 정확히 뭘 하는 프로토콜인가?
-
TCP 뇌절 시리즈: 로드맵
뇌절의 첫 시리즈 주제는 TCP입니다. 다만 “뇌절”이라고 해서 처음부터 커널 코드나 RFC로 들어가지는 않습니다.
-
뇌절을 시작하며
GitHub Pages와 Jekyll로 뇌절을 시작합니다.
subscribe via RSS