TCP의 슬라이딩 윈도우는 수신자가 데이터를 잃지 않고도 "속도를 줄여달라"고 말할 수 있는 방법입니다. 윈도우 크기 통보, 스케일링, 제로 윈도우 프로브가 어떻게 빠른 송신자로부터 느린 수신자를 보호하는지 알아봅니다.
TCP는 모든 바이트에 시퀀스 번호를 부여하고 수신 확인을 요구합니다. 이 단순한 체계가 혼돈스럽고 불안정한 네트워크를 신뢰할 수 있는 통신으로 바꿉니다.
TCP 연결을 닫으면 60초 동안 흔적이 남습니다. TIME_WAIT는 버그가 아닙니다—네트워크가 따라잡을 때까지 TCP가 기억을 놓지 않는 것입니다.
TCP의 세 방향 핸드셰이크는 데이터를 보내기 전에 모든 연결에 왕복 통행료를 부과합니다. TCP Fast Open은 재방문 클라이언트가 절차를 건너뛸 수 있게 해줍니다—요청을 첫 번째 패킷에 바로 담아서. 완벽하게 작동합니다—작동하지 않을 때만 빼면요.
FIN은 전화를 끊기 전 인사를 하듯 TCP 연결을 종료합니다. RST는 대화 도중 갑자기 전화가 끊어지는 것과 같습니다. 어느 쪽이 일어났는지, 그리고 왜 그랬는지를 아는 것이 몇 분짜리 디버깅과 몇 시간짜리 디버깅을 가릅니다.
처음 만나는 두 기기가 데이터를 교환하기 전에 공통된 시작점에 합의해야 합니다. 3방향 핸드셰이크는 두 기기가 동기화하는 방법이며, 이 과정에는 공격자들이 무자비하게 악용하는 취약점이 존재합니다.
TCP는 네트워크를 믿지 않습니다. 모든 패킷에는 암묵적인 질문이 담겨 있습니다 — 이거 받았어요? — 그리고 침묵은 손실로 받아들여집니다. 재전송이 어떻게 신뢰할 수 없는 네트워크를 신뢰할 수 있는 채널로 바꾸는지 살펴봅니다.
네이글 알고리즘은 1984년에 탁월한 발상이었다—작은 패킷들을 묶어 전송함으로써, 오버헤드에 허덕이던 초기 인터넷을 구해냈다. 사십 년이 지난 지금, 이 알고리즘이 게임이 뚝뚝 끊기거나 터미널이 느려지는 원인인 경우가 많다. 어떤 상황에서 이 알고리즘을 받아들이고, 언제 TCP_NODELAY로 끊어버려야 하는지, 그리고 왜 정답이 뒤집혔는지를 살펴본다.
다운된 서버는 작별 인사도 없이 그냥 사라집니다. TCP keep-alive는 그 침묵을 두드려 죽은 연결을 찾아내고, 살아있는 연결이 앞으로 나아갈 수 있게 합니다.
TCP 옵션은 1970년대의 프로토콜이 기가비트 세계에서 살아남는 방법입니다. 단편화를 피하기 위해 세그먼트 크기를 협상하고, 원래의 64KB 한계를 넘어 윈도우를 확장하며, 타임스탬프로 고속 연결을 안정적으로 유지합니다.
TCP 송신자는 네트워크를 볼 수 없습니다—패킷이 사라질 때 비로소 알게 됩니다. 이 침묵 속에서 혼잡을 추론하고 스스로 속도를 조절해야 합니다. 그러지 않으면 붕괴가 찾아옵니다: 재전송으로 포화된 네트워크가 아무것도 이루지 못하는 상태로 치닫습니다.
TCP는 검증을 통해 신뢰할 수 없는 네트워크를 신뢰할 수 있는 통신으로 변환합니다: 상호 도달 가능성을 증명하는 핸드셰이크, 모든 바이트를 추적하는 순서 번호, 수신을 확인하는 확인 응답—네트워크가 아무것도 보장하지 않는 곳에서 신뢰를 쌓아갑니다.
이 페이지가 도움이 되었나요?