Интерпретация отправителем окна передачи показана на рис. 6.14. Размер окна передачи отправителя в данном случае покрывает с 4 по 8 байт. Это означает, что отправитель получил подтверждения на все байты, включая 3, а получатель анонсировал размер окна равным 5 байтам. Это также означает, что отправитель может еще передать 2 байта (7 и 8). По мере подтверждения получения данных окно будет смещаться вправо, открывая новые "горизонты" для передачи. Однако окно может изменять свои размеры, при этом имеет значение, смещение какого края окна (правого или левого) приводит к изменению размера.

 Окно закрывается по мере смещения левого края вправо. Это происходит при отправлении данных.

 Окно открывается по мере смещения правого края вправо. Это происходит в соответствии с освобождением буфера приема получателя данных.

 Окно сжимается, когда правый край смещается влево. Хотя такое поведение не рекомендуется, модуль TCP должен быть готов к обработке этой ситуации.

Рис. 6.14. Окно передачи TCP

Если левый край окна достигает правого, размер окна становится равным нулю, что запрещает дальнейшую передачу данных.

Суммируя вышесказанное, можно отметить, что размер окна, сообщаемый получателем данных отправителю, является предлагаемым окном (offered window), которое в простейшем случае равно размеру свободного места в буфере приема. При получении этого значения отправитель данных вычисляет фактическое, доступное для использования окно (usable window), которое равно предлагаемому за вычетом объема отправленных, но не подтвержденных данных. Таким образом, доступное для использования, или просто доступное, окно меньше или равно предлагаемому. Неэффективная стратегия подтверждений может привести к чрезвычайно малым значениям доступного окна и, как следствие, к низкой производительности передачи данных. Это явление, известное под названием синдром "глупого окна" (Silly Window Syndrome, SWS), будет рассмотрено ниже.

Рассмотренный стандарт протокола TCP определяет взаимодействие между удаленными объектами, достаточное для обеспечения совместимых реализаций. Другими словами, модуль протокола, в точности следующий спецификации стандарта, является гарантированно совместимым с модулями TCP, разработанными другими производителями. Тем не менее ряд вопросов функционирования протокола остается за рамками стандарта и допускает различные реализации, в конечном итоге влияющие не на совместимость, а на производительность приложений, использующих этот протокол. В данном разделе мы рассмотрим различные подходы к реализации TCP, направленные на повышение его производительности.

Механизм подтверждения получения данных является ключевым в протоколе TCP. Стандарт указывает, что подтверждение должно быть передано без задержки, но не определяет конкретно, насколько быстро данные должны быть подтверждены, и объем подтверждаемых данных. К сожалению, корректная с точки зрения спецификации протокола, но неоптимальная реализация стратегии подтверждения приводит к неудовлетворительной работе механизма управления потоком данных (оконного механизма), что приводит к синдрому "глупого окна" (SWS).

Для иллюстрации этого явления рассмотрим передачу файла большого размера между двумя приложениями, использующими протокол TCP. Допустим, что модуль протокола осуществляет передачу сегментами, размер которых составляет 200 октетов. В начале передачи предлагаемое окно отправителя — 1000 октетов. Он полностью использует этот кредит, послав пять сегментов по 200 октетов каждый. После обработки первого полученного сегмента адресат отправляет подтверждение (сегмент

), которое также содержит обновленное значение предлагаемого окна. Предположим, что адресат передал полученные данные приложению, и таким образом его буфер приема вновь содержит 1000 байтов свободного места. Поэтому обновленное значение окна будет также равным 1000 октетов. Эта ситуация показана на рис. 6.15.

Рис. 6.15. Возникновение SWS

При получении подтверждения отправитель вычисляет доступное окно. Поскольку получение 800 октетов данных еще не подтверждено, значение доступного окна получается равным 200.

Рассмотрим теперь процесс возникновения SWS. Предположим, что отправитель вынужден передать сегмент размером 50 октетов (например, если приложение указало флаг

). Таким образом, он отправляет 50 байтов, и вслед за этим следующий сегмент, размером 150 октетов (поскольку размер доступного окна равен 200). Через некоторое время адресат получит 50 байтов, обработает их и подтвердит получение, не изменяя значения предлагаемого окна (1000 октетов). Однако теперь при вычислении доступного окна, отправитель обнаружит, что не подтверждены 950 байтов, и, таким образом, его окно равняется всего 50 октетам. В результате отправитель вновь вынужден будет передать всего 50 байтов, хотя приложение этого уже не требует.

Если мы продолжим анализировать передачу данных, то заметим, что рисунок транзакций будет периодически повторяться, т.е. отправитель будет вынужден периодически передавать сегмент необоснованно малого размера. Этот порочный круг не может быть разорван естественным образом. Происхождение сегментов малого размера очевидно: периодически у отправителя возникает необходимость разделить доступное окно на несколько мелких сегментов. При непрерывной передаче больших объемов данных такие ситуации будут время от времени возникать, оставляя неизгладимый след на характере транзакций. В результате это может привести к "засорению" сети множеством мелких пакетов в одну сторону и множеством подтверждений в другую.