Silly Window Syndrome은 가상 회선에서 수신 시스템 쪽의 문제를 나타낸다. 즉 수신 버퍼로부터 데이터가 신속하게 읽히지 않아 작은 크기의 윈도우가 통보되고, 결과적으로 송신 시스템이 작은 세그먼트를 전송하게 만드는 것이다. 즉 아주 적은 데이터를 위해 많은 네트워크 트래픽이 생성되는 결과를 초래한다.
송신 시스템 역시 완전히 다른 이유에서 이런 종류의 문제를 일으킬 수 있다. TELNET과 같은 일부 애플리케이션은 끊임없이 많은 수의 작은 세그먼트를 전송하도록 설계되어, 적은 양의 데이터를 전송하면서 고도로 네트워크를 사용하게 한다. 또 10메가바이트짜리 데이터를 512바이트 블록으로 쓰는 등 데이터를 적은 단위로 쓰는 애플리케이션도 이런 문제를 일으킨다. 이런 모델에서 특히 같은 양의 데이터를 더 큰 패킷을 생성하여 전송할 수 있는 경우에 생성되는 패킷의 수는 대역폭을 심하게 낭비한다.
이런 종류의 문제를 위한 해결책으로 제안된 것 가운데 하나가 원래 RFC 896에서 설명한 Nagle 알고리즘이다. 간단히 말해서, Nagle 알고리즘은 최대 크기(수신 시스템의 MSS 옵션 또는 종단간 경로를 위해 발견된 MTU 값에 의해 정의되는)보다 작은 세그먼트는 이미 전송된 모든 세그먼트의 수신이 확인되거나 완전한 크기의 세그먼트가 전송될 수 있을 때까지 지연되어야 한다고 제안한다. 이 규칙은 TCP 스택이 작은 크기의 여러 세그먼트를 하나의 세그먼트로 병합하여 전송하게 만든다.
Nagle 알고리즘은 작은 크기의 세그먼트를 전송하면 확인 메시지가 신속하게 도착하여 즉시 다음 세그먼트가 전송될 수 있도록 하므로, 대기 시간이 짧은 LAN에서는 거의 사용하지 않는다. 그러나 확인 메시지가 송신 시스템으로 돌아오는 데 시간이 오래 걸리는 저속 WAN 연결에서는 Nagle 알고리즘을 자주 사용한다. 결과적으로 Nagle 알고리즘은 작은 크기의 세그먼트를 하나로 병합하여 전체적인 네트워크 효율성을 제고시킨다.
이런 이유에서 RFC 1122는 반드시 Nagle 알고리즘을 필수로 사용해야 하는 것은 아니지만 대체로 사용을 권장하고 있다. X Windodws와 같은 일부 애플리케이션은 작은 세그먼트가 병합되는 경우에 그것을 제대로 처리하지 못한다. 그런 경우에 사용자는 쇠선별로 Nagle 알고리즘을 해지시킬 수 있지만, 대부분이 그런 기능을 제공하지 안흔ㄴ다. 대신, 대부분의 TCP 구현은 전 회선에 대한 Nagle 알고리즘의 사용 여부를 설정할 수 있게하거나 애플리케이션 개발자가 필요한 경우를 결정할 수 있게 한다.
일부 개발자가 네트워크 사용률이 높아지는데도 불구하고 성능을 향상시킬 목적으로 연결에 Nagle 알고리즘을 사용하지 않은 채로 불충분한 세그먼트 크기를 자주 생성하는 프로그램을 작성하였기 때문에 이렇게 제한하는 것은 문제가 있다. 그런 개발자가 처음부터 작은 세그먼트 대신 큰 세그먼트를 생성하는 프로그램을 작성하였다면, Nagle 알고리즘 없이도 프로그램은 효율적으로 동작하였을 것이다.
Nagle 알고리즘은 해지할 때 나타나는 또 다른 부작용은 지연된 수신 확인 기법이 확인 메시지를 전송하기 이전에 완전한 크기의 두 세그먼트가 수신될 때까지 기다리기 때문에 작은 세그먼트가 생성되는 경우에는 제대로 동작하지 않는다는 것이다. 개발자가 Nagle 알고리즘을 해지키셔 완전한 크기의 세그먼트를 수신하지 못하면, 지연된 수신 확인 기법은 타이머가 만료되거나 송신 시스템으로 데이터가 돌아가지 않는 한 개입하지 못한다.
이런 현상은 특히 적은 양의 데이터를 전송해야 하는 경우에 문제가 된다. 송신 시스템은 데이터를 전송하지만, 수신 시스템은 타이머가 만료되기 전에 확인 메시지를 전송하지 않으므로 세션은 아주 변덕스러운 특성을 나타낼 것이다.
이런 상황은 적은 양의 데이터가 대용량(bulk) 전송의 끝에서 생성되는 경우에도 발생한다. 그러나 이런 경우는 수신 시스템에서 모종의 데이터(확인 상태 코드 또는 회선 종결 요청과 같은)를 생성할 가능성이 높다. 그런 경우, 지연된 수신 확인 기법은 돌아오는 데이터에 확인 메시지를 얹어 사용자가 특별히 더 지연된다는 느낌을 갖지 못하게 할 수 있다.
이런 모든 이유에서 애플리케이션 개발자에게는 큰 세그먼트를 생성하는 것이 권장되며, 주어진 연결에 가장 효율적인 세그먼트 크기를 알고 있다면 그 크기의 배수로 세그먼트를 생성하는 것이 가장 좋다. 예를 들어, 어떤 가상 횟너의 최대 세그먼트 크기가 1460바이트(이더넷의 경우)라면, 애플리케이션은 1460의 배수(2960바이트 블록, 5840바이트 블록 등)로 데이터를 전달해야 한다. 이렇게 하여 TCP는 짝수 개로 효율적인 크기의 세그먼트를 생성하여 Nagle 알고리즘이 지연을 일으키는 것을 원천적으로 막고, 지연된 수신 확인 기법이 확인 메시지를 지연시키는 것도 방지할 수 있다.
Quotes from Internet Core Protocols, Eric A. Hall, O'Reilly, 인터넷 핵심 프로토콜 가이드, 한빛미디어
송신 시스템 역시 완전히 다른 이유에서 이런 종류의 문제를 일으킬 수 있다. TELNET과 같은 일부 애플리케이션은 끊임없이 많은 수의 작은 세그먼트를 전송하도록 설계되어, 적은 양의 데이터를 전송하면서 고도로 네트워크를 사용하게 한다. 또 10메가바이트짜리 데이터를 512바이트 블록으로 쓰는 등 데이터를 적은 단위로 쓰는 애플리케이션도 이런 문제를 일으킨다. 이런 모델에서 특히 같은 양의 데이터를 더 큰 패킷을 생성하여 전송할 수 있는 경우에 생성되는 패킷의 수는 대역폭을 심하게 낭비한다.
이런 종류의 문제를 위한 해결책으로 제안된 것 가운데 하나가 원래 RFC 896에서 설명한 Nagle 알고리즘이다. 간단히 말해서, Nagle 알고리즘은 최대 크기(수신 시스템의 MSS 옵션 또는 종단간 경로를 위해 발견된 MTU 값에 의해 정의되는)보다 작은 세그먼트는 이미 전송된 모든 세그먼트의 수신이 확인되거나 완전한 크기의 세그먼트가 전송될 수 있을 때까지 지연되어야 한다고 제안한다. 이 규칙은 TCP 스택이 작은 크기의 여러 세그먼트를 하나의 세그먼트로 병합하여 전송하게 만든다.
Nagle 알고리즘은 작은 크기의 세그먼트를 전송하면 확인 메시지가 신속하게 도착하여 즉시 다음 세그먼트가 전송될 수 있도록 하므로, 대기 시간이 짧은 LAN에서는 거의 사용하지 않는다. 그러나 확인 메시지가 송신 시스템으로 돌아오는 데 시간이 오래 걸리는 저속 WAN 연결에서는 Nagle 알고리즘을 자주 사용한다. 결과적으로 Nagle 알고리즘은 작은 크기의 세그먼트를 하나로 병합하여 전체적인 네트워크 효율성을 제고시킨다.
이런 이유에서 RFC 1122는 반드시 Nagle 알고리즘을 필수로 사용해야 하는 것은 아니지만 대체로 사용을 권장하고 있다. X Windodws와 같은 일부 애플리케이션은 작은 세그먼트가 병합되는 경우에 그것을 제대로 처리하지 못한다. 그런 경우에 사용자는 쇠선별로 Nagle 알고리즘을 해지시킬 수 있지만, 대부분이 그런 기능을 제공하지 안흔ㄴ다. 대신, 대부분의 TCP 구현은 전 회선에 대한 Nagle 알고리즘의 사용 여부를 설정할 수 있게하거나 애플리케이션 개발자가 필요한 경우를 결정할 수 있게 한다.
일부 개발자가 네트워크 사용률이 높아지는데도 불구하고 성능을 향상시킬 목적으로 연결에 Nagle 알고리즘을 사용하지 않은 채로 불충분한 세그먼트 크기를 자주 생성하는 프로그램을 작성하였기 때문에 이렇게 제한하는 것은 문제가 있다. 그런 개발자가 처음부터 작은 세그먼트 대신 큰 세그먼트를 생성하는 프로그램을 작성하였다면, Nagle 알고리즘 없이도 프로그램은 효율적으로 동작하였을 것이다.
Nagle 알고리즘은 해지할 때 나타나는 또 다른 부작용은 지연된 수신 확인 기법이 확인 메시지를 전송하기 이전에 완전한 크기의 두 세그먼트가 수신될 때까지 기다리기 때문에 작은 세그먼트가 생성되는 경우에는 제대로 동작하지 않는다는 것이다. 개발자가 Nagle 알고리즘을 해지키셔 완전한 크기의 세그먼트를 수신하지 못하면, 지연된 수신 확인 기법은 타이머가 만료되거나 송신 시스템으로 데이터가 돌아가지 않는 한 개입하지 못한다.
이런 현상은 특히 적은 양의 데이터를 전송해야 하는 경우에 문제가 된다. 송신 시스템은 데이터를 전송하지만, 수신 시스템은 타이머가 만료되기 전에 확인 메시지를 전송하지 않으므로 세션은 아주 변덕스러운 특성을 나타낼 것이다.
이런 상황은 적은 양의 데이터가 대용량(bulk) 전송의 끝에서 생성되는 경우에도 발생한다. 그러나 이런 경우는 수신 시스템에서 모종의 데이터(확인 상태 코드 또는 회선 종결 요청과 같은)를 생성할 가능성이 높다. 그런 경우, 지연된 수신 확인 기법은 돌아오는 데이터에 확인 메시지를 얹어 사용자가 특별히 더 지연된다는 느낌을 갖지 못하게 할 수 있다.
이런 모든 이유에서 애플리케이션 개발자에게는 큰 세그먼트를 생성하는 것이 권장되며, 주어진 연결에 가장 효율적인 세그먼트 크기를 알고 있다면 그 크기의 배수로 세그먼트를 생성하는 것이 가장 좋다. 예를 들어, 어떤 가상 횟너의 최대 세그먼트 크기가 1460바이트(이더넷의 경우)라면, 애플리케이션은 1460의 배수(2960바이트 블록, 5840바이트 블록 등)로 데이터를 전달해야 한다. 이렇게 하여 TCP는 짝수 개로 효율적인 크기의 세그먼트를 생성하여 Nagle 알고리즘이 지연을 일으키는 것을 원천적으로 막고, 지연된 수신 확인 기법이 확인 메시지를 지연시키는 것도 방지할 수 있다.
Quotes from Internet Core Protocols, Eric A. Hall, O'Reilly, 인터넷 핵심 프로토콜 가이드, 한빛미디어