Posts
-
소켓 버퍼·재전송 큐·RTO 계산의 실제 구현
지난 글에서 상태머신을 코드로 확인했습니다. 이번엔 5편에서 “일정 시간(RTO) 기다렸다가 재전송한다”고 뭉뚱그렸던 그 시간을 정확히 어떻게 계산하는지 봅니다. 여전히 Linux 커널 v6.6,
net/ipv4/tcp_input.c·tcp_timer.c·include/net/tcp.h기준입니다. -
Linux TCP 상태머신, 소스로 따라가기
8~10편에서 스펙 원문을 검증했습니다. 이제부터는 그 스펙이 실제로 코드로 어떻게 구현됐는지 봅니다. 기준은 Linux 커널 v6.6, 파일은
net/ipv4/tcp_input.c와net/ipv4/syncookies.c입니다. (커널 버전마다 세부 구현이 조금씩 다를 수 있습니다 — 아래 인용은 전부 v6.6 기준입니다.) -
시퀀스 넘버 wraparound과 PAWS
지난 글에서 Sequence Number가 32비트라는 걸 헤더 다이어그램으로 확인했습니다. 32비트는 유한합니다 — 그래서 언젠가는 최댓값을 넘고 다시 0으로 돌아갑니다. 이번 글은 그 순간 무슨 일이 일어나는지를 다룹니다.
-
TCP 헤더 32비트 완전분해
지난 글에서 스펙 본문이 어떻게 바뀌었는지 봤습니다. 이번엔 시선을 좁혀서, TCP 헤더 20바이트를 비트 단위로 완전히 분해합니다. RFC 9293 Section 3.1의 다이어그램을 그대로 따라갑니다.
-
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