9.4 Протокол tcp

9.4.1.Несмотря на кажущуюся простоту, ТСР протокол достаточно сложен и должен решать следующие основные проблемы:

-восстанавливать порядок сегментов;

-убирать дубликаты сегментов, в каком бы виде (фрагментация) они не поступали;

-определять разумную задержку для «time out» для подтверждений в получении сегмента;

-устанавливать и разрывать соединения надежно;

-управлять потоком;

-управлять перегрузками.

В TCP-соединении у каждого байта есть свой 32-разрядный последовательный номер. Если хост передает со скоростью 10 Мбит/с, теоретически порядковые номера могут совершить полный круг за один час, хотя на практике это занимает значительно больше времени. Порядковые номера используются как для подтверждений, так и для механизма скользящего окна, использующих отдельные 32-разрядные поля заголовка.

Две TCP-сущности обмениваются данными в виде сегментов. Сегмент состоит из фиксированного 20-байтового заголовка (плюс необязательная часть), за которым могут следовать байты данных. Размер сегментов определяется программным обеспечением TCP. Оно может объединять в один сегмент данные, полученные в результате нескольких операций записи, или, наоборот, распределять результат одной записи между несколькими сегментами. Размер сегментов ограничен двумя пределами. Во-первых, каждый сегмент, включая TCP-заголовок, должен поме­щаться в 65 535-байтовое ноле полезной нагрузки IP-пакета. Во-вторых, в каждой сети есть максимальная единица передачи (MTU, Maximum Transfer Unit), и каждый сегмент должен помещаться в MTU. На практике размер максимальной единицы передачи составляет несколько тысяч байт, определяя, таким образом, верхний предел размера сегмента. Если сегмент проходит через последовательность сетей и попадает в сеть, чья MTU-единица оказывается меньше размера сегмента, пограничный маршрутизатор фрагментирует сегмент на две или более части.

При фрагментации каждый новый сегмент получает свой IP-заголовок (20 байт), что увеличивает накладные расходы.

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

Поскольку сегменты могут фрагментироваться, возможна ситуация, в которой часть переданного сегмента будет принята, а остальная часть окажется потерянной. Кроме того, сегменты могут прибывать не в том порядке, так что возможна ситуация, в которой байты с 3072 по 4095 уже прибыли, но подтверждение для них не может быть выслано, так как байты с 2048 по 3071 еще не получены. К тому же сегменты могут так надолго задерживаться в сети, что у отправителя истечет интервал ожидания, и он передаст их снова. Если переданный повторно сегмент пройдет по другому маршруту и будет по-другому фрагментирован, отдельные части оригинала и дубликата будут появляться спорадически, в результате для восстановления исходного сегмента потребуется более сложная обработка. Наконец, сегмент может по дороге случайно попасть в перегруженную (или поврежденную) сеть.

Протокол TCP должен уметь справляться с этими проблемами и решать их эффективно. Оптимизации производительности TCP-потоков были уделены зна­чительные усилия.

9.4.2 Заголовок TCP-сегмента представлен на рисунке 104. Каждый сегмент начинается с 20-байтового заголовка фиксированного формата. За фиксированным заголовком могут следовать дополнительные поля. После дополнительных полей может располагаться до 65 536 - 20 - 20 = 65 495 байт данных, где первые 20 байт означают IP-заголовок, а вторые – TCP-заголовок. Сегменты могут и не содержать данных. Такие сегменты часто применяются для передачи подтверждений и управляющих сообщений.

32 бита

Порт отправителя 16 бит									Порт получателя 16 бит
Порядковый номер 32 бит
Номер подтверждения 32 бит
Длина TCP-заголовка 4 бит	Зарезервировано 6 бит	U R G	АСК	РSН	RSТ	SY N	F I N	Размер окна 16 бит
Контрольная сумма 16 бит								Указатель на срочные данные 16 бит
Параметры (0 или более 32-разрядных слов) (переменная длина)
Данные (необязательное поле) (переменная длина)

Рисунок 104 - TCP-заголовок

Рассмотрим TCP-заголовок поле за полем.

-Поля «Порт получателя» (Source Port) и «Порт (Destination Port) отправителя» являются идентификаторами локальных конечных точек соединения. Каждый хост может сам решать, как назначать свои порты, начиная с 1024. Номер порта вместе с IP-адресом хоста образуют уникальный 48-битовый TSAP-адрес. Пара номеров сокетов получателя и отправителя служит идентификатором соединения.

-Поле «Порядковый номер» (Sequence number) идентифицирует байт в потоке данных от отправляющего TCP к принимающему TCP. Если мы представим поток байтов, текущий в одном направлении между двумя приложениями, TCP нумерует каждый байт номером последовательности. Номер последовательности представляет собой 32-битное беззнаковое число, которое переходит через 0 по достижению значения 2³² - 1.

При установлении нового соединения взводится флаг SYN. Поле номера последовательности (sequence number field) содержит исходный номер последовательности (ISN - initial sequence number), который выбирается хостом для данного соединения. Номер последовательности первого байта данных, который посылается этим хостом, будет равен ISN плюс один, потому что флаг SYN занимает собой номер последовательности.

-Поле «Номер подтверждения» (acknowledgment number) - это следующий номер последовательности, который ожидает получить отправитель подтверждения. Это номер последовательности плюс 1 последнего успешно принятого байта данных. Это поле принимается в рассмотрение только если флаг ACK (описан ниже) взведен.

Отправка ACK не стоит ничего (это означает, что на подтверждение не тратится сегмент), потому что 32-битное поле номера подтверждения всегда является частью заголовка, так же как и флаг ACK. Мы увидим, что когда соединение установлено, это поле всегда установлено и флаг ACK всегда взведен.

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

-Поле «Длина TCP-заголовка» (Data Offset) означает размер TCP-заголовка в 32-разрядных словах. Эта информация нужна, так как поле Параметры может быть переменной длины, а вместе с ним и весь заголовок. Это поле можно рассматривать, как смещение от начала сегмента до начала данных в 32-битовых словах.

-Следом идет неиспользуемое 6-битовое поле (Reserved). Тот факт, что это поле выжило в течение десяти лет, является свидетельством того, насколько хорошо продуман дизайн TCP. Это резервное поле, должно быть заполнено нулями.

Затем следуют шесть 1-битовых флагов (Control Bits):

-Бит URG устанавливается в 1 в случае использования поля Указатель на срочные данные, содержащего смещение в байтах от текущего порядкового номера байта до места расположения срочных данных. Таким образом, в протоколе TCP реализуются прерывающие сообщения. Как уже упоминалось, содержимым срочных данных целиком занимается прикладной уровень. Протокол TCP лишь обеспечивает их доставку и не интересуется причиной прерывания;

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

-Бит АСК, будучи установлен в 1, означает, что поле «Номер подтверждения» содержит осмысленные данные. В противном случае данный сегмент не содержит подтверждения и поле «Номер подтверждения» просто игнорируется;

-Бит PSH является флагом PUSH, с помощью которого отправитель просит получателя доставить данные приложению сразу по получении пакета, а не хранить его в буфере, пока буфер не наполнится, что получатель может делать ради большей эффективности;

-Бит RST используется для сброса состояния соединения, которое из-за сбоя хоста или по другой причине попало в тупиковую ситуацию. Кроме того, он используется для отказа от неверного сегмента или от попытки создать соединение. Если вы получили сегмент с установленным битом RST, это означает наличие какой-то проблемы;

-Бит SYN применяется для установки соединения. У запроса соединения бит SYN = 1, а бит АСХ = 0, это означает, что поле подтверждения не используется. В ответе на этот запрос содержится подтверждение, поэтому значения этих битов в нем равны: SYN = 1, АСК = 1. Таким образом, бит SYN используется для обозначения сегментов «CONNECTION REQUEST» и «CONNECTION ACCEPTED», а бит АСК - чтобы отличать их друг от друга;

-Бит FIN используется для разрыва соединения. Он указывает, что у отправителя больше нет данных для передачи. Однако даже закрыв соединение, процесс может продолжать получать данные неопределенно долго. У сегментов с битами FIN и SYN есть порядковые номера, что гарантирует правильный порядок их выполнения.

Управление потоком в протоколе TCP осуществляется при помощи скользя­щего окна переменного размера.

-Поле «Размер окна» (Window) сообщает, сколько байтов может быть послано после получившего подтверждения байта. Значение поля «Размер окна» может быть равно нулю, это означает, что все байты вплоть до Номер подтверждения получены, но у получателя в данный момент какие-то проблемы, и остальные байты он пока принять не может. Разрешение на дальнейшую передачу может быть выдано отправкой сегмента с таким же значением поля «Номер подтверждения» и ненулевым значением поля «Размер окна».

-Поле «Контрольная сумма» (Checksum) призвано повысить надежность. Оно содержит контрольную сумму заголовка, данных и псевдо- заголовка, показанного на рисунке 105. При выполнении вычислений поле «Контрольная сумма» устанавливается на ноль, а поле данных дополняется нулевым байтом, если его длина представляет собой нечетное число. Алгоритм вычисления контрольной суммы просто складывает все 16-разрядные слова в дополнительном коде, а затем вычисляет дополнение для всей суммы. В результате, когда получатель считает контрольную сумму всего сегмента, включая поле «Контрольная сумма», результат должен быть равен 0.

-Поле «Указатель на срочные данные» (Urgent Pointer) используется совместно с управляющим битом URG. Число, помещаемое в это поле, указывает на конец срочных данных. Срочные данные передаются вне очереди (вне потока - out of band).

Псевдозаголовок содержит 32-разрядные IP-адреса отправителя и получателя, номер протокола для TCP и счетчик байтов для ТСР-сегмента (включая заголовок). Включение псевдозаголовка в контрольную сумму TCP помогает обнаружить неверно доставленные пакеты, хотя это нарушает иерархию протоколов, так как IP-адреса в нем принадлежат IP-уровню, а не TCP-уровню.

-Поле «Параметры» (Options) предоставляет дополнительные возможности, не покрываемые стандартным заголовком. Один из наиболее важных параметров позволяет каждому хосту указать максимальный размер поля полезной нагрузки, который он может принять. Использование сегментов большего размера является более эффективным, так как при этом снижается удельный вес накладных расходов в виде заголовка, однако не все хосты способны принимать очень большие сегменты. Хосты могут сообщить друг другу максимальный размер ноля полезной нагрузки во время установки соединения. По умолчанию этот размер равен 536 байтам. Все хосты обязаны принимать ТСР - сегменты размером

536+20=556 байт. Для двух направлений могут быть установлены различные значения размера поля полезной нагрузки.

Если параметры занимают не полностью 32 битовое поле то остаток заполняется нулями. Это действие называется выравниванием (Padding).

Для линий с большой скоростью передачи и большой задержкой окно

размером в 64 Кбайт оказывается слишком маленьким. Так, для линии 73 (44,736 Мбит/с) полное окно может быть передано в линию всего за 12 мс.

Рисунок 105 - Псевдозаголовок, включаемый в контрольную сумму TCP

Если значение времени распространения сигнала в оба конца составляет 50мс

(типично для трансконтинентального оптического кабеля), 3/4 времени отправитель будет заниматься ожиданием подтверждения. При связи через спутник ситуация будет еще хуже. Больший размер окна мог бы улучшить эффективность, но 16-битовое поле «Размер окна» не позволяет указать больше 64 Кбайт. В RFC 1323 был предложен новый параметр «Масштаб окна», о значении которого два хоста могли договориться при установке соединения. Это число позволяет сдвигать поле «Размер окна» до 14 разрядов влево, позволяя расширять размер окна до 2³⁰ байт (1 Гбайт). В настоящее время большинство реализации протокола TCP поддерживают эту возможность.

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