종합 연습 — TCP 의 동작을 패킷의 시점에서 읽어낸다

즉시의 refused 는 RST 가 돌아온 증거 — 호스트에는 도착하고 있는데, 그 포트에서 아무도 리슨하고 있지 않다(프로세스 미기동, 포트 번호 차이 등). 침묵 끝의 타임아웃은 응답이 돌아오지 않는다 — 경로 단절, 호스트 정지, 또는 말없이 버리는 방화벽입니다. A 의 존재로부터 「호스트는 살아 있고 포트에 문제」「B 와의 경로 어딘가에서 차단」까지 좁힐 수 있습니다. 도착한 뒤의 거부와, 도착하지 않는 침묵 — 제 2 장의 구분의 정석입니다.

TIME_WAIT 는 먼저 FIN 을 보낸 쪽이, 마지막 ACK 의 보험과 오래된 세그먼트의 독 빼기를 위해 남는 정상적인 상태입니다(제 2 장). 단명 접속을 초당 수백 건이나 맺고 버리면, 수십 초의 체류만으로 수만 건이 됩니다. 해는 커넥션 자원(포트 등)의 소비이며, 근본 대책은 접속을 매번 다시 맺지 않고 재사용하는 것. 「이상한 상태를 지운다」가 아니라 「정상적인 상태가 대량 발생하는 설계를 고친다」고 읽는 것이 정답입니다.

TCP 자체는 유휴 커넥션을 무기한 유지할 수 있습니다(양 끝의 장부가 남아 있으면 된다 — 제 2 장). 하지만 경로 상의 방화벽이나 NAT 는 4 요소 조합마다의 상태 표를 갖고 있어, 유휴가 계속된 항목을 타임아웃으로 지웁니다. 그 후에 도착한 세그먼트는 「소속 불명」이 되어, 파기나 RST 가 됩니다. 대책은 TCP 킵얼라이브나 앱 계층의 정기적인 생존 확인으로 「사용 중」이라고 계속 보여 주는 것입니다. 심야의 혼잡이라면 로스나 재전송이 먼저 보일 것입니다.

제로 윈도우 + 윈도우 프로브의 조합은 「수신 버퍼가 가득 차서, 앱이 recv 로 읽어내기를 전원이 기다리고 있다」는 상태의 교과서적인 캡처입니다(제 4 장). 네트워크는 올바르게 브레이크를 전하고 있을 뿐이고, 범인은 수신 측 앱의 처리 정체(디스크 쓰기의 느림, GC, 락 등). 로스나 혼잡이라면 재전송이나 중복 ACK 가 보일 것이고, 윈도우 0 과는 다른 풍경이 됩니다.

도중에 잘림(분할)과 연결(결합)이 양쪽 다 나오는 것은, 「1 recv = 1 메시지」 전제의 전형적인 증상입니다(제 6 장). TCP 는 바이트열과 순서를 완전히 지키고 있으며, 네트워크에도 프로토콜에도 이상은 없습니다. 리트라이는 깨진 잘라내기를 반복할 뿐입니다. 경계는 앱이 만든다 — 프레이밍의 도입과 「쌓고·잘라내고·넘긴다」 루프로의 수정이 유일한 근치입니다.

중복 ACK 가 거의 없음 + 침묵 후의 재전송은, 빠른 재전송이 아니라 RTO 만료형의 재전송입니다(제 3 장). 이때 TCP 는 중증으로 판단하고, cwnd 를 1 MSS 로 되돌려 슬로 스타트부터 다시 합니다(제 5 장). 회복에 몇 RTT 나 걸리므로, 체감은 「몇 초 굳었다가는 느릿느릿 달리기 시작한다」의 반복이 됩니다. 중복 ACK 형(반감으로 계속)과는 증상도 심각도도 다르다 — 재전송의 유형을 구별하는 것이, 성능 문제 해석의 갈림길입니다.