Коль соединение установлено, передача данных осуществляется с по-
мощью обмена сегментами. Т.к. сегменты могут быть потеряны в резуль-
тате ошибок (например, ошибки в контрольной сумме) или перегрузки
сети, то программа протокола TCP использует механизм повторной посыл-
ки (по истечении определенного времени) с тем, чтобы убедиться в по-
лучении каждого сегмента. В главе, посвященной номерам очередей, об-
суждалось, как программа TCP в сегментах осуществляет проверку номе-
ров очередей и номеров подтверждения на предмет их корректности.
Отправитель данных с помощью значения переменной SND.NXT отслежи-
вает следующий номер в очереди, подлежащий отправке. Получатель дан-
ных с помощью переменной RCV.NXT отслеживает следующий номер, прибы-
тие которого он ожидает. В переменную SND.UNA отправитель данных по-
мещает значение самого старого номера, который был отправлен, но еще
не получил подтверждения. Если бы поток данных моментально иссяк, а
все отправленные данные получили подтверждение, то тогда бы все эти
при переменные содержали одинаковое значение.
Когда отправитель информации создает и посылает некий сегмент, он
увеличивает значение переменной SND.NXT. Адресат по получении сегмен-
та увеличивает значение переменной RCV.NXT и отправляет подтвержде-
ние. Когда программа TCP, пославшая данные, получает подтверждение,
она увеличивает значение SND.UNA. Разность в значениях этих перемен-
ных является мерой, характеризующей задержку сегментов в сети. Вели-
чина, на которую надо всякий раз осуществлять приращение значения
этих переменных, является длиной поля данных в сегменте. Заметим, что
поскольку соеднения находятся в состоянии ESTABLISHED, все сегменты,
в дополнение к собственно данным, должны нести некую информацию о
подтверждении ранее отправленных сегментов.
Запрос пользователя о закрытии соединения (CLOSE) подразумевает
использование функции проталкивания, что осуществляется с помощью
контрольного флага FIN приходящем сегменте
Контрольное время повторной посылки
Вследствие непостоянства сетей, составляющих единую объединенную
систему, и большого числа клиентов, пользующихся услугами TCP соеди-
нений, существует необходимость в динамическом определении контроль-
ного времени повторной посылки. В качестве иллюстрации здесь приво-
дится одна из процедур определения этого времени.
Пример процедуры измерения контрольного времени для повторной
посылки сегментов
Во-первых, измерьте время, прошедшее между посылкой октета дан-
ных, имеющего некий определенный номер в очереди, и получение под-
тверждения, указывающего наряду с другими и на этот номер (посыла-
емые сегменты не обязаны соответствовать полученным сегментам).
Измеренная временная задержка - это время обращения (Round Trip
Time - RTT). Следующий шаг - вычисление усредненного времени обра-
щения (Smoothed Round Trip Time - SRTT):
SRTT = (ALPHA * RSTT) + ( (1-ALPHA) * RTT)
Затем с помощью найденного значения определяется контрольное время
повторной посылки (Retransmission Timeout - RTO):
RTO = min[ UBOUND, max[ LBOUND, (BETA * SRTT) ]]
где UBOUND - верний предел контрольного времени (например, 1 мин),
LBOUND - нижний предел (например, 1 сек). ALPHA - фактор сглажива-
ния (например, от 0.8 до 0.9), а BETA - фактор изменения задержки
(например, от 1.3 до 2.0).
Передача срочной информации
Механизм срочной передачи протокола TCP предназначен для того,
чтобы клиент, отправляющий данные, мог побудить получателя принять
некую срочную информацию, а также позволить программе TCP, принимаю-
щей данные, информировать своего клиента, когда вся имеющаяся на на-
стоящий момент информация будет получена.
Данный механизм позволяет помечать некую точку в потоке данных как
конец блока срочной информации. Когда в программе TCP, принимающей
данные, данная точка окажется впереди индикатора номера в очереди
получения (RCV.NXT), эта программа TCP должна дать команду своему
клиенту перейти в "срочный режим". Когда номер в очереди получения
догонит срочный указатель в потоке данных, программа TCP должна дать
команду клиенту прийти в "нормальный режим". Если срочный указатель
сменит свое положение, когда клиент находится в "срочном режиме",
последний не узнает об этом.
Данный метод использует поле флага срочности, котрый присутствует
во всех передаваемых сегментах. Единица в поле контрольного флага URG
означает, что задействовано поле срочности . Чтобы получить указатель
этого поля в потоке данных, необходимо дополнить его номером рассмат-
риваемого сегмента в очереди. Отсутствие флага URG означает отсут-
ствие у отправителя непосланных срочных данных.
При указании срочности клиент должен также послать по крайней мере
один октет данных. Если клиент, помещающий данные, дополнительно за-
кажет функцию проталкивания, то передача срочной информации ждущему
ее процессу многократно ускорится.
Управление окном
Окно, посылаемое с каждым сегментом, указывает диапазон номаров
очереди, которые отправитель окна (он же получатель данных) готов
принять в настоящее время. Предполагается, что такой механизм связан
с наличием в данный момент места в буфере данных.
Указание окна большого размера стимулирует передачу. Но если при-
шло большее количество данных, чем может быть принято программой TCP,
данные будут отброшены. Это приведет к излишним пересылкам информации
и ненужному увеличению нагрузки на сеть и программу TCP. Указание
окна малого размера может ограничить передачу данных скоростью, кото-
рая определяется временем путешествия по сети после каждого посыла-
емого сегмента.
Такие механизмы протокола позволяют программе TCP заявлять большое
окно, но впоследствии объявлять окна намного меньшего размера и не
принимать такое большое количество данных. Такое, так называемое,
сокращение окна выглядит довольно обескураживающе. Принцип устойчиво-
сти диктует, чтобы программа протокола TCP не сокращала сама окно, но
была бы готова к таким действиям со стороны другой программы TCP.
Программа TCP, посылающая данные, должна быть готова принять от
клиента и передать по сети по крайней мере один октет новых данных,
даже если окно отправления равно нулю. Программа TCP должна периоди-
чески повторно посылать данные другой программе TCP, даже если окно
нулевое. В случае нулевого окна рекомендуется использовать интервал
повторной посылки в две минуты. Такие повторные посылки важны для
того, чтобы гарантировать, что в случае, когда одна из двух программ
TCP имеет нулевое окно, открытие этого окна будет гарантированно со-
общено партнеру.
Когда программа TCP, получающая данные, имеет нулевое окно, но к
ней приходит сегмент, то эта программа должна послать подтверждение и
указать, какой следующий номер в очереди она ожидает и какое у нее
окно в настоящий момент (окно нулевое).
Программа TCP пакует предназначенные к в пересылке данные в сег-
менты, заполняющие текущее окно. Однако она не может перепаковать уже
имеющиеся сегменты в очереди на повторную посылку. Такая перепаковка
хоть и не обязательна, но может быть полезна.
В соединении, имеющем односторонний поток данных, информация об
окне будет передаваться с сегментами подтверждения, а они будут все
иметь одинаковый номер очереди. Поэтому не будет способа восстановить
их очередность при получении. Это не является серьезной проблемой, но
может случайно привести к получению информации об окне из какого-
нибудь устаревшего сообщения. Во избежание такой проблемы должен осу-
ществляться отсев и информация об окне должна браться из сегментов,
имеющих самый большой номер в очереди (это сегменты, чей номер под-
тверждения больше или равен наибольшему из ранее полученных номеров).
Процедура управления окном оказывает значительное влияние на ха-
рактеристики коммуникаций. Дальнейшие комментарии содержат пожелания
разработчикам.
Пожелания по управлению окном
Выделение очень малого окна приводит к передаче данных очень
маленькими сегментами, тогда как лучший режим осуществляется при
использовании сегментов большего размера.
Чтобы избежать применения малых окон, получателю данных предла-
гается откладывать изменение окна до тех пор, пока свободное место
не составит X процентов от максимально возможного в памяти для
этого соединения (где X может быть от 20 до 40).
Другой совет, чтобы не посылать малые сегменты, состоит в том,
чтобы отправитель не спешил с посылкой данных, пока окно не станет
достаточно большим. Но если клиент дает команду на использование
функции проталкивания, то данные следует немедленно отправлять,
даже если это будет осуществляться малым сегментом.
Заметим, что во избежание ненужных повторных пересылок не нужно
медлить с посылкой подтверждений. Стратегия может заключаться в
посылке подтверждения при получении сегмента малого размера (без
обновления информации обокне), затем посылается другое другое под-
тверждение с новой информацией об окне, если последнее расширяет-
ся.
Сегмент, посылаемый для проверки нулевого окна, может иницииро-
вать разбивку передавамых данных на все более и более мелкие сег-
менты. Если сегмент, содержащий единичный октет данных и отправ-
ленный для проверки нулевого окна, получен, то он займет один ок-
тет в имеющемся в данный момент окне. Если же программа TCP просто
посылает столько данных, сколько может, всякий раз, когда окно
ненулевое, то передаваемые данные будут разбиваться на большие и
малые сегменты. По истечении некоторого времени случающиеся паузы
в выделении окна получателем данны приведут к разбивке больших
сегментов на многочисленные и уже не столь большие пары. Итак, по
прошествии некоторого времени передача данных будет осуществляться
преимущественно малыми сегментами.
Предложение состоит в том, чтобы реализации протокола TCP ак-
тивно пытались объединить малые окна в более крупые, поскольку
механизмы управления окном стремятся ввести много малых окон в
простейших реализациях протокола.
|
