요약

  • Silly Window Syndrome(어리석은 창 증후군)은 안정적인 피드백 루프였습니다. 수신 창의 작은 증가가 작은 전송을 유도했고, 그 전송이 새 공간을 소비하면서 또 다른 작은 증가를 불러왔습니다.
  • TCP는 해결책을 둘로 나누었습니다. 수신자는 한계적 용량의 광고를 지연할 수 있고, 송신자는 유용한 전송 기회를 기다릴 수 있습니다.
  • Nagle 알고리즘은 작은 세그먼트의 또 다른 원천, 즉 작은 애플리케이션 쓰기를 다루므로 창 기반 절제를 대체하는 것이 아니라 보완합니다.

흐름 제어가 만든 패킷 공장

TCP의 수신 창은 경계입니다. 수신자가 추가로 얼마나 많은 시퀀스 공간을 받아들일 준비가 되어 있는지 송신자에게 알려 줍니다. 그 의미 어디에도 모든 양의 증가분을 반드시 즉시 사용해야 한다는 말은 없습니다. 그러나 문자 그대로 해석한 초기 구현은 그렇게 동작할 수 있었습니다.

가득 찬 수신 버퍼에서 애플리케이션이 1바이트를 소비했다고 상상해 보십시오. 수신자는 정직하게 1바이트의 새 공간을 광고할 수 있습니다. 대기 데이터를 가진 송신자는 정직하게 그 공간을 채울 수 있습니다. 버퍼는 다시 가득 차고, 애플리케이션이 또 1바이트를 소비하면 같은 교환이 반복됩니다. 어느 쪽도 흐름 제어를 위반하지 않지만, 연결은 작은 페이로드, 헤더, 승인(ACK), 인터럽트, 스케줄링 작업으로 이어지는 비싼 리듬에 안착합니다.

RFC 813은 이 안정적 패턴에 Silly Window Syndrome이라는 이름을 붙였습니다. 그 중요성은 유치한 이름이 아니라 진단에 있었습니다. 프로토콜상 유효한 국소적 판단들이 시스템 차원의 실패로 결합될 수 있다는 것입니다. 정확한 회계는 버퍼를 보호하면서 유용한 입도를 파괴했습니다.

수신자는 모든 사실을 광고하지 않는 법을 배웠다

수신자는 자기 버퍼를 직접 봅니다. 그래서 첫 번째 절제의 주인은 자연스럽게 수신자입니다. 작은 애플리케이션 읽기가 있을 때마다 광고된 창의 오른쪽 끝을 옮기는 대신, 그 끝을 고정한 채 새로 생긴 공간을 누적할 수 있습니다. 숨겨진 용량이 유용한 작업을 지원할 만큼 커지면, 더 큰 개구를 발표합니다.

공간은 언제나 실재합니다. 지연은 이미 수락한 바이트의 장부를 거짓으로 만들지도, 이전에 부여한 허가를 철회하지도 않습니다. 단지 매번 한계적 개선을 새로운 공개적 초대로 바꾸는 일을 거부할 뿐입니다. RFC 1122와 현대 TCP 사양은 수신자 측 SWS 회피 알고리즘과 버퍼 용량 및 실효 최대 세그먼트 크기에 기반한 실용적 임계값을 기술합니다.

이 구분은 중요합니다. 측정은 행동 준비가 되지 않은 채로 정확할 수 있습니다. 버퍼를 소유한 쪽이야말로 자기 최소 변화를 공개할 때 드는 운영 비용도 함께 봅니다.

송신자는 허가가 곧 지시가 아니라는 것을 배웠다

수신자의 절제만으로 모든 상대로부터 연결을 보호할 수는 없으므로, 송신자에는 별도의 판단이 있습니다. 광고된 창은 상한으로 남습니다. 그 이상을 보내는 것은 금지되지만, 양의 끝값까지 즉시 채울 의무도 없습니다.

송신자 측 SWS 회피는 유용한 기회를 찾습니다. 세그먼트 하나를 담을 만큼의 충분한 공간, 대기 중 푸시 데이터를 마무리할 적절한 방법, 연결에서 관측된 최대 창의 의미 있는 비율, 또는 무기한 대기를 막는 재정의 타임아웃 같은 것들입니다. 송신자는 수신자의 총 버퍼 크기를 직접 알 수 없으므로, 이 알고리즘은 관측값으로 동작하며 나쁜 추정에서 벗어날 탈출 경로를 포함합니다.

RFC 9293은 송신자 측과 수신자 측 SWS 회피를 별개의 절로 유지합니다. 이 분리가 곧 아키텍처적 요점입니다. 수신자는 용량이 언제 제안이 되는지 결정하고, 송신자는 그 제안이 전송을 정당화하는지 판단합니다. 어느 쪽 끝점도 상대의 내부 메모리에 대한 권한을 필요로 하지 않습니다.

Nagle은 다른 작은 패킷 원천을 해결했다

작은 세그먼트가 언제나 좁은 창에서 비롯되는 것은 아닙니다. 수신 용량이 넉넉한 상황에서도 애플리케이션이 아주 작은 단위로 TCP에 바이트를 전달할 수 있습니다. RFC 896은 1바이트 페이로드가 당시 약 40바이트의 TCP/IP 헤더와 함께 실리며 호스트와 혼잡한 게이트웨이에 부담을 줄 수 있음을 설명했습니다.

Nagle의 적응적 규칙은 작은 세그먼트가 아직 승인되지 않은 동안 새로운 작은 쓰기가 누적되도록 허용함으로써 이러한 애플리케이션 트리클의 곱셈을 제한합니다. 승인이 오거나 대기 데이터가 충분해지면 또 한 번의 전송이 풀립니다. 고정 타이머와 달리, 이 규칙은 연결의 피드백을 따릅니다.

기회의 원천이 두 메커니즘을 구분합니다. Nagle은 애플리케이션에서 작은 조각으로 도착하는 데이터에 대응하고, 송신자 측 SWS 회피는 상대에게서 작은 조각으로 도착하는 사용 가능한 창에 대응합니다. 지연에 민감한 용도를 소유한 애플리케이션은 Nagle을 끌 수 있지만, 그 선택이 별개의 창 문제를 지워 주지는 않습니다.

절제에는 탈출구가 필요했다

기다림은 효율을 높일 수 있지만, 무한한 기다림은 또 하나의 실패가 됩니다. 그래서 송신자 측 지침에는 재정의 타임아웃이 포함됩니다. 역사적 설계는 최적화를 영구적 거부권으로 만들지 않았습니다. 재량을 진행으로 돌아갈 경로와 짝지었습니다.

이 균형이 살아남은 이유는 좁은 권한을 배정했기 때문입니다. 수신자는 자기 버퍼의 공개를 소유하고, 송신자는 자기 전송 기회의 지출을 소유하며, 애플리케이션은 자기 지연 요구에 대해 병합이 허용되는지를 소유합니다. 프로토콜은 중앙 패킷 스케줄러가 아니라 한계와 탈출 조건을 제공합니다.

출처와 한계

이 메커니즘과 그 진화는RFC 793,RFC 813,RFC 896,RFC 1122,RFC 9293에 문서화되어 있습니다. 이 문서들은 설계와 표준의 역사를 확립합니다. 오늘날 운영체제에서 SWS가 얼마나 자주 나타나는지를 측정하지는 않으며, 이 문제는 혼잡 창 제어나 패킷 손실과 혼동해서는 안 됩니다.