6. Управление передачей в tcp

9.6.1 Управление окном в TCP не привязано напрямую к подтверждениям, как это делается в большинстве протоколов передачи данных. Например, предположим, у получателя есть 4096-байтовый буфер, как показано на рисунке 111. Если отправитель передает 2048-байтовый сегмент, который успешно принимается получателем, то получатель подтверждает получение сегмента. Однако при этом у получателя остается всего лишь 2048 байт свободного буферного пространства (пока приложение не заберет сколько-нибудь данных из буфера), о чем он и сообщает отправителю, указывая соответствующий размер окна и номер следующего ожидаемого байта.

Теперь отправитель посылает еще 2048 байт, получение которых подтверждается, но размер окна объявляется равным 0. Отправитель должен остановиться, пока получающий хост не освободит места в буфере и не увеличит размер окна.

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

Отправители не обязаны передавать данные сразу, как только они приходят от приложения. Также никто не требует от получателей посылать подтверждения как можно скорее. Например, на рисунке 111. TCP-сущность, получив от приложения первые 2 Кбайт данных и зная, что доступный размер окна равен 4 Кбайт, была бы совершенно права, просто сохранив полученные данные в буфере до тех пор, пока не прибудут другие 2 Кбайт данных, чтобы передать сразу сегмент с 4 Кбайт полезной нагрузки. Эта свобода действий может использоваться для улучшения производительности.

Рассмотрим TELNET соединение с интерактивным редактором, реагирующим на каждое нажатие клавиши. В худшем случае, когда символ прибывает к передающей TCP-сущности, она создает 21-байтовый ТСР-сегмент и передает его IP-уровню, который, в свою очередь, посылает 41-байтовую IP-дейтаграмму. На получающей машине TCP-сущность немедленно отвечает 40-байтовым подтверждением (20 байт TCP-заголовка и 20 байт IP-заголовка). Затем, когда редактор прочитает этот байт из буфера, TCP-сущность пошлет обновленную информацию о размере буфера, передвинув окно на 1 байт вправо. Размер этого пакета также 40 байт. Наконец, когда редактор обработает этот символ, он отправляет обратно эхо, передаваемое также 41-байтовым пакетом. Итого для каждого введенного с клавиатуры символа пересылается четыре пакета общим размером в 162 байта. При недостаточной пропускной способности линий этот метод работы нежелателен.

Для улучшения этой ситуации многие реализации TCP используют задержку подтверждении и обновлении размера окна на 500 мс, в надежде получить дополнительные данные, вместе с которыми можно будет отправить подтверждение одним пакетом. Если редактор успеет выдать эхо в течение 500 мс, удаленному пользователю нужно будет выслать только один 41-байтовый пакет, таким образом снизив нагрузку на сеть вдвое.

Рисунок 111- Управление окном в TCP

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

41-байтовом пакете. Метод, позволяющий повысить эффективность, известен как алгоритм Нагля (Nagle).

Предложение Нагля было простым: если данные поступают отправителю по одному байту, отправитель просто передает первый байт, а остальные помешает в буфер, пока не будет получено подтверждение приема первого байта. Тогда переслать все накопленные в буфере символы в виде одного ТСР - сегмента и снова начать буферирование до получения подтверждения отосланных символов. Если пользователь вводит символы быстро, а сеть медленная, то в каждом сегменте будет передаваться значительное количество символов, таким образом, нагрузка на сеть будет значительно снижена. Дополнительно этот алгоритм позволяет посылать новый пакет, если число символов в буфере превысит половину размера окна или максимальный размер сегмента.

Алгоритм Нагля широко применяется различными реализациями протокола TCP, однако иногда бывают ситуации, в которых его лучше отключить. В частности, во время работы приложения X-Windows в Интернете информация о перемещениях мыши пересылается на удаленный компьютер. Если буферизировать эти данные для пакетной пересылки, курсор будет перемещаться рывками с большими паузами, в результате чего пользоваться программой будет очень сложно, если вообще возможно.

Еще одна проблема, способная значительно снизить производительность протокола TCP, известна под именем синдрома «глупого» окна (SWS - silly window syndrome). Суть проблемы в том, что данные пересылаются TCP-сущностью крупными блоками, но принимающая сторона интерактивного приложения читает их посимвольно. Чтобы ситуация стала понятнее, рассмотрим рисунок. 112. Вначале TCP-буфер приемной стороны полон, и отправителю это известно (то есть размер его окна равен 0). Затем интерактивное приложение читает один символ из TCP-потока. Принимающая TCP-сущность сообщает отправителю, что размер окна увеличился и что он теперь может послать один байт. Отправитель повинуется и посылает один байт. Буфер снова полон, о чем получатель и извещает, посылая подтверждение для 1-байтового сегмента с нулевым размером окна. И так может продолжаться вечно.

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

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

Алгоритм Нагля и решение Кларка дополняют друг друга. Нагль пытался решить проблему приложения, предоставляющего данные TCP-сущности посимвольно. Кларк старался разрешить проблему приложения, посимвольно получающего данные у TCP. Оба решения верны и могут работать одновременно. Принцип обоих решений состоит в том, чтобы не посылать и не просить передавать данные небольшими порциями.

Получающая TCP-сущность может пойти еще дальше в деле повышения производительности. Как и отправляющая TCP-сущность, она также может буферировать данные и блокировать запрос на чтение READ, поступающий от приложения, до тех пор, пока у нее не накопится большого объема данных. Таким образом, снижается количество обращений к TCP-сущности и, следовательно, снижаются накладные расходы.

Рисунок 112 - Синдром глупого окна

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

Еще одна проблема получателя состоит в сегментах, полученных с нарушением порядковых номеров. Они могут храниться или игнорироваться по усмотрению получателя. Разумеется, подтверждение может быть выслано, только если все данные вплоть до подтверждаемого байта получены. Если до получателя доходят сегменты 0, 1, 2, 4, 5, 6 и 7, он может подтвердить получение данных вплоть до последнего байта сегмента 2. Когда у отправителя истекает время ожидания, он передает сегмент 3 еще раз. Если к моменту прибытия сегмента 3 получатель со­хранил в буфере сегменты с 4 по 7, он может подтвердить получение всех байтов, вплоть до последнего байта сегмента 7.

9.6.2.Когда в сеть поступает больше данных, чем она способна обработать, в сети образуются заторы. Интернет в этом смысле также не является исключением. В данном разделе мы обсудим алгоритмы, разработанные для борьбы с перегрузкой сети за последнее десятилетие. Хотя сетевой уровень также пытается бороться с перегрузкой, основной вклад в решение этой проблемы, заключающееся в снижении скорости передачи данных, был сделан протоколом TCP.

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

В настоящее время потери пакетов при передаче случаются относительно редко, так как большая часть междугородных линий связи являются оптоволоконными (хотя в беспроводных сетях процент пакетов, теряемых из-за помех, довольно высок). Соответственно, большинство потерянных пакетов в Интернете вызвано заторами. Все TCP-алгоритмы Интернета предполагают, что потери пакетов вызываются перегрузкой сети и следят за тайм-аутами.

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

Решение, применяемое в Интернете, состоит в осознании существования двух потенциальных проблем: низкой пропускной способности сети и низкой емкости получателя - и в раздельном решении обеих проблем. Для этого каждый отправитель содержит два окна: окно, предоставленное получателем, и окно перегрузки. Каждое окно отражает количество байтов, которое отправитель имеет право передать. Отправитель руководствуется минимальным из этих двух значений. Например, если получатель говорит: «Посылайте 8 Кбайт», но отправитель знает, что если он пошлет более 4 Кбайт, то в сети образуется затор, он посылает 4 Кбайт. Если же отправитель знает, что сеть способна пропустить и большее количество данных, например 32 Кбайт, он передаст столько, сколько просит получатель.