Когда соединение установлено, передача данных осуществляется с помощью обмена сегментами. Т.к. сегменты могут быть потеряны в результате ошибок (например, ошибки в контрольной сумме) или перегрузки сети, то программа протокола 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 активно пытались объединить малые окна в более крупные, поскольку механизмы управления окном стремятся ввести много малых окон в простейших реализациях протокола.