Управление передачей в TCP

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

Отправитель передает четыре сегмента данных (4-7), чтобы заполнить окно объявленное получателем. Затем отправитель останавливается и ожидает подтверждения. Получатель отправляет подтверждение (сегмент 8), однако объявляет окно равное 0. Это означает, что получатель получил данные, однако все они находятся в TCP буферах получателя, потому что приложение не имеет возможности считать данные.

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

Еще один ACK (называемый обновлением окна) посылается через 17,4 миллисекунды и объявляет о том, что получатель теперь может получить следующие 4096 байт. То, что выглядит как подтверждение (ACK), в действительности является обновлением окна, потому что здесь не происходит подтверждения каких-либо вновь полученных данных, а просто объявляется новый размер окна.

Отправитель не обязан передавать данные сразу, как только они приходят от приложения. Также не требуется от получателя посылать подтверждения как можно скорее. Эта свобода действий может использоваться для улучшения производительности.

Отправитель передает свои последние четыре сегмента (10-13) и опять заполняет окно принимающего. Обратите внимание, что сегмент 13 содержит два флаговых бита: PUSH и FIN. После этого следуют еще два подтверждения от принимающего. Они подтверждают последние 4096 байт данных (байты от 4097 до 8192) и FIN (который имеет номер 8193).

Теперь посмотрим, как осуществляется передача данных через TCP соединение в случае, когда приложению требуется пересылка мелких порций данных, на примере интерактивного ввода команд в Rlogin или Telnet соединении. Указанные протоколы используются для удаленной работы на компьютере с обеспечением текстового интерфейса. Для этого ввод каждого символа (каждое нажатие клавиши) генерирует процедуру отправки этого символа на используемый компьютер и подтверждение им получения этого символа (для этого символ пересылается обратно на терминал и только после такого эхо-приема отображается на его экране). В результате каждое нажатие клавиши генерирует 4 TCP сегмента: (1) интерактивный ввод символа от клиента, (2) подтверждение получение символа от сервера, (3) эхо введенного символа от сервера и (4) подтверждение на эхо от клиента. На рисунке показан происходящий обмен данными.

При этом генерируются пакеты размером 41 байт: 20 байт - IP заголовок, 20 байт - TCP заголовок и 1 байт данных. Маленькие пакеты - обычно не проблема для локальных сетей, так как большинство локальных сетей не перегружаются, однако они могут привести к перегрузке глобальной сети. Простое и элегантное решение было предложено в 1984 (John Nagle), которое сейчас называется алгоритмом Нагля.

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

Еще одна проблема, которую должен уметь решать TCP принято называть синдромом «глупого окна». Эта ситуация возникает, когда отправитель передает сегмент с большим количеством байт, заполняет буфер получателя, а приложение получателя считывает из буфера по 1 байту. Тогда в ACK - подтверждении получателя будет установлен размер окна 1 байт и эффективность передачи снизится, а нагрузка на сеть возрастет. Для преодоления этой проблемы Дэвидом Кларком (David Clark) было предложено запретить передачу окна размером в 1 байт.