Книга: TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

10.13.2 Синдром "бестолкового окна"

10.13.2 Синдром "бестолкового окна"

В первых реализациях TCP/IP разработчики столкнулись с феноменом синдрома "бестолкового окна" (Silly Window Syndrome — SWS), который проявлялся достаточно часто. Для понимания происходящих событий рассмотрим следующий сценарий, приводящий к нежелательным последствиям, но вполне возможный:

1. Передающее приложение быстро отсылает данные.

2. Принимающее приложение читает из входного буфера по 1 байту данных (т.е. медленно).

3. Входной буфер после чтения быстро заполняется.

4. Принимающее приложение читает 1 байт, и TCP отправляет ACK, означающий "Я имею свободное место для 1 байта данных".

5. Передающее приложение отправляет по сети пакет TCP из 1 байта.

6. Принимающий TCP посылает ACK, означающий "Спасибо. Я получил пакет и не имею больше свободного места".

7. Принимающее приложение опять читает 1 байт и отправляет ACK, и весь процесс повторяется.

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

Реальные ситуации, конечно, не столь экстремальны. Быстрый отправитель и медленный получатель будут обмениваться небольшими (относительно максимального размера сегмента) кусками данных и переключаться по почти заполненному приемному окну. На рис. 10.18 показаны условия для появления синдрома "бестолкового окна".

Рис. 10.18. Буфер приемного окно с очень малым размером свободного пространства

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

minimum(1/2 входного буфера, Максимальный размер сегмента)

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

Предложенное решение легко проверить в рассмотренном выше случае с выводом ACK для каждого из полученных байтов. Этот же способ пригоден и для случая, когда входной буфер может хранить несколько сегментов (как часто бывает на практике). Быстрый отправитель заполнит входной буфер, но приемник укажет, что не имеет свободного места для размещения информации, и не откроет этот ресурс, пока его размер не достигнет целого сегмента.

Оглавление книги