Как предотвратить синдром глупого окна в приемнике при протоколе tcp

Данные передаются по сети и Интернету с использованием протокола TCP/IP . TCP/IP не идеален, но его легче реализовать по сравнению с другими протоколами, теоретизированными для передачи данных… такими как модель ISO OSI. Как и в любой технической ситуации, в TCP/IP есть и некоторые недостатки, и Синдром Глупого Окна является одним из таких недостатков. Чтобы понять, что такое синдром «Глупого окна» или SWS, вам сначала необходимо понять механизм передачи данных в TCP/IP.

Синдром Глупого Окна

Понимание окна и его размера

Когда две точки обмениваются данными по TCP/IP, это включает механизм подтверждения. Этот механизм подтверждения — то, что вызывает синдром Глупого окна, как объяснено далее. Точки могут относиться к двум компьютерам, клиенту и серверу и т. Д.

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

Когда компьютер, скажем A, отправляет пакет данных на другой компьютер B, последний должен подтвердить и ответить, что он получил пакет данных. Наряду с подтверждением, он также должен отправить размер буфера, установленного отдельно для этого коммуникационного потока. Обычно это количество байтов, освобождаемых для связи.

Поэтому, когда B говорит, что 100B доступно для следующего сообщения, 100B — это окно в синдроме глупого окна. То есть это размер буфера. Со своим собственным недостатком механизм TCP/IP может уменьшать размер буфера для каждой связи/данных, поступающих от A. То есть, когда A отправляет сообщение, B предполагает, что размер буфера уменьшается, и отправляет меньшее число. Таким образом, размер окна продолжает уменьшаться, и в какой-то момент связь просто прекращается, когда B отправляет 0B в качестве размера окна.

Как работает синдром «Глупого окна»

В соответствии с приведенным выше примером A и B, если B отправляет 1000B в качестве размера окна, A разделяет его на два 500B и отправляет два пакета по 500B. После получения первого пакета B отправит подтверждение о том, что для окна доступно 500B, так как второй пакет еще не получен. Предполагается, что размер окна составляет 500 В, и, следовательно, отправляются два пакета по 250 В. В то время как на B используется 500B, а 500 только что получено, оно отправит 0B как доступный. На этом этапе A будет предполагать, что окно недоступно, хотя может случиться так, что буфер будет пуст, поскольку процессор использует данные там. A все равно отправит меньший пакет, чтобы увидеть, доступно ли какое-либо окно. Если содержимое буфера в B еще не удалено, он все равно получит 0 в качестве ответа/подтверждения.

Таким образом, размер окна продолжает уменьшаться, так как B отправляет подтверждение каждый раз, когда получает пакет от A. Этот размер обычно меньше, чем предыдущее подтверждение, поскольку B принимает пакеты данных по частям. Не было бы проблем, если бы А мог отправить пакет достаточно большой, чтобы покрыть размер буфера на Б одновременно. Но это потребует дополнительных механизмов и, следовательно, синдрома Глупого окна. Связь прекращается после того, как А получает 0 два или три раза.

Как предотвратить синдром глупого окна (SWS)

Существует простой алгоритм для избавления от SWS. Получив начальный пакет, B отправляет половину реально доступного пространства в качестве окна. Это заставит отправлять меньшие пакеты. Следовательно, когда пакеты становятся слишком маленькими, B отправляет общий размер буфера, чтобы A мог снова начать отправлять большие байты данных.

Другими словами, если 1000B доступно, B отправляет 500B в качестве подтверждения. Соответственно, A отправляет 250B x ​​2 пакета. Для этого A получает 100B в качестве подтверждения. Когда он получает пакет 50B, B отправляет 1000B — 50B в A. Это снова делает весь разговор работоспособным. Это может вызвать небольшую задержку в обработке, но предотвратит возникновение синдрома Глупого окна и остановит весь диалог.

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

Хотя я, возможно, использовал слова окно и буфер взаимозаменяемо. Я не имею в виду никакой разницы между ними. В исследованиях SWS буфер является окном.

Если вам нужна дополнительная информация, подробное объяснение доступно здесь, на tcpipguide.com.

«Скользящее окно» передатчика

Рассмотрим теперь, как передатчик меняет позицию окна передатчика. В нашем примере, допустим, передатчик посылает еще два байта (203 и 204) и получает из приемника подтверждение на успешный прием байтов 200-202. Теперь ожидают подтверждение два байта (203 и 204). Если размер окна приемника не меняется (пока еще равен 7), то передатчик может теперь сдвигать свое окно и освободить места, занятые байтами 200-202, которые могут быть использованы повторно. Рис. 10.7 показывает состояние буфера передатчика и окно передатчика перед и после этого события. Во второй части этого рисунка передатчик может теперь посылать байты с 205 до 209 (5 следующих байт).

Расширение «скользящего окна»

Если процесс приемника принимает данные быстрее, чем они поступают, размер окна может быть расширен (в буфер можно добавить свободные места). Эта ситуация может привести к увеличению (расширению) размера окна в передатчике. На Рис. 10.8 приемник прислал подтверждение еще на 2 байта (теперь ожидает подтверждения байт 205), и в то же самое время размер окна приемника увеличен до 10. Такое увеличение позволяет процессу передачи ввести дополнительно 5 байт и передать 5 байт.

Уменьшение окна передатчика

Если процесс приемника принимает данные медленнее, чем они поступают, размер окна приемника уменьшается (сжимается). На рисунке приемник принимает 5 байт (с 205 до 209); однако процесс приема берет на обслуживание только один байт — это означает, что число свободных мест уменьшается по сравнению с показанным на Рис. 10.5. до 6 (10-5+1). Он подтверждает байты с 205 до 209 (ожидающий байт 210), но информирует передатчик, что надо сжать размер своего окна и не посылать более чем 6 байтов. Если передатчик уже послал 2 байта, когда он принял новые, а получил на три больше от процесса передатчика, мы будем иметь окно и буфер, показанный на рис. 10.9

Закрытие окна передатчика

Что произойдет, если буфер приемника заполнен? В этом случае размер окна приемника имеет значение нуль. Когда это транслируется передатчику, передатчик закрывает окно (левая и правая стенки перекрываются). Передатчик не может передать ни одного байта, пока приемник не передаст значение размера окна приемника, не равное нулю.

Синдром «глупого окна»

Серьезная проблема может возникнуть при работе со «скользящим окном», когда какая-либо передающая прикладная программа медленно создает данные, либо приемная прикладная программа медленно принимает данные, либо имеют места оба случая. В любой из этих ситуаций результат заключается в посылке очень маленьких сегментов, которые уменьшают эффективность работы. Например, если TCP посылает сегмент, содержащий один байт данных, это означает, что мы посылаем дейтаграмму 41 байт (20 байт — TCP-заголовок и 20 байт — IP-заголовок), которая передает только 1 байт пользовательских данных. Соотношение заголовок/информация (41/1) указывает, что производительность сети используется очень неэффективно. Эта проблема называется синдром «глупого окна». Рассмотрим детальнее, как создается эта проблема, а затем — как она может быть решена.

Синдром, создаваемый передатчиком

Протокол передачи TCP может создать синдром «глупого окна», если он обслуживает медленную прикладную программу, которая медленно создает данные, например, 1 байт за время передачи всего окна. Прикладная программа за это время записывает один байт в буфер передачи TCP. Если передающее TCP не имеет никаких заданных инструкций, он может создать сегмент, содержащий один байт данных. Результат — передача большого числа 41-байтных сегментов, которые проходят через Интернет.

Элементарное решение — запретить TCP-передатчику передавать данные длиной 1 байт. Можно алгоритм передатчика поставить в режим ожидания момента, когда соберутся данные, чтобы послать большой блок. Как долго должно TCP ждать? Если ожидание слишком долгое, то это может замедлить процесс. А если ждать недостаточно, это может окончиться посылкой маленького сегмента.

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

Алгоритм Нагла (Nagle’s algorithm)

Алгоритм Нагела прост, но решает проблему. Этот алгоритм для передатчика TCP:

1. Передатчик TCP посылает первый кусок данных, приемник получает этот кусок от передающей прикладной программы, даже если это только один байт.
2. После посылки первого сегмента TCP передатчик накапливает данные в выходном буфере и ждет, пока приемник TCP пришлет подтверждение или пока накопится достаточно данных для заполнения максимального размера сегмента. К этому времени TCP может передать сегмент.
3. Шаг 2 может повториться для всей дальнейшей передачи. Сегмент 3 может быть послан, если получено подтверждение на сегмент 2 или накоплено достаточно данных для заполнения максимального размера сегмента.

Алгоритм Нагла позволяет учитывать и согласовывать скорость передачи пакета данных программой TCP и фактической скоростью передачи данных по сети.Если прикладная программа быстрее, чем сетевая – создается больший сегмент (максимальный сегмент). Если прикладная программа медленнее, чем сетевая, то создается сегмент, меньший, чем максимальный. В медленных глобальных сетях, где ответ идёт долго, пакеты будут посылаться реже и, следовательно, в трафике будет меньше служебной информации.

Синдром, создаваемый приемником

TCP приемника может создать синдром «глупого окна», если он обслуживает программу, которая поглощает данные медленно, например, 1 байт за один цикл чтения всего буфера. Предположим, что программа передачи создает данные в блоках 1K, но программа приемника принимает 1 байт за один цикл. Также предположим, что входной буфер TCP приема равен 4 Кбайта. Передатчик посылает 4 Кбайта данных. Приемник сохраняет их в своем буфере. Теперь его буфер полный. Он превращает размер окна в нуль, что означает, что передатчик должен прекратить передачу данных. Приложения приемника читает первый байт данных из входного буфера приемника. Теперь мы имеем 1 байт пространства во входящем буфере. TCP приемника объявляет размер окна 1 байт, который означает, что передатчик TCP, который раньше ожидал разрешение на передачу, воспримет это преобразование окна как хорошую новость и пошлет сегмент, переносящий только один байт. Процедура будет продолжаться. Один байт данных поглощается, и посылается сегмент, переносящий
один байт данных. Опять мы имеем проблему эффективности.

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

Первое: послать подтверждение сразу, как данные приняты правильно, но сигнал о смене размера окна посылать по мере накопления в буфере пространства для приема сегмента максимального размера или когда буфер пуст.

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

Задержанное подтверждение также имеет другое преимущество: оно уменьшает трафик, поскольку приемник не подтверждает каждый сегмент. Однако его недостаток в том, что задержанное подтверждение может заставить передатчик повторно передать неподтвержденный сегмент.

Протокол находит баланс достоинств и недостатков. Он теперь определяет, что подтверждение не должно быть задержано более чем на 500 мс.