Операционная система UNIX

 Доставка информации является надежной, не допускающей дублирования или нарушения очередности получения данных.

 Возможность управления потоком данных для избежания переполнения и затора.

 Доставка экстренных данных.

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

TCP-канал представляет собой двунаправленный поток данных между соответствующими объектами обмена — источником и получателем. Данные могут передаваться в виде пакетов различной длины, называемых сегментами. Каждый TCP-сегмент предваряется заголовком, за которым следуют данные, инкапсулирующие протоколы уровня приложения. Вид заголовка TCP-сегмента представлен на рис. 6.11.

Рис. 6.11. Формат TCP-сегмента

Положение каждого сегмента в потоке фиксируется порядковым номером (Sequence Number), представленным соответствующим полем заголовка и обозначающим номер первого октета сегмента в потоке TCP. Порядковые номера также используются для подтверждения получения: каждый TCP-сегмент содержит номер подтверждения (Acknowledgement Number), сообщающий отправителю количество полученных от него последовательных данных. Номер подтверждения определяется как номер первого неподтвержденного октета в потоке.

И порядковый номер, и номер подтверждения занимают по 32 бита в заголовке TCP-сегмента, таким образом, их максимальное значение составляет (2^3^2 - 1), за которым следует 0. При установлении связи стороны договариваются о начальных значениях порядковых номеров (Initial Sequence Number, ISN) в каждом из направлений. Впоследствии первый октет переданных данных будет иметь номер (ISN+1).

Управление потоком данных осуществляется с помощью метода скользящего окна (sliding window). Каждый TCP-заголовок содержит также поле Window, которое указывает на количество данных, которое адресат готов принять, начиная с октета, указанного в поле Acknowledgement Number.

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

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

Значение этого поля измеряется в 32-битных словах. Таким образом, при минимальном размере заголовка поле Offset будет равно 5.

Далее заголовок содержит шесть управляющих флагов Flags, каждый из которых занимает отведенный ему бит:

URG	Указывает, что сегмент содержит экстренные данные, и поле Urgent pointer заголовка определяет их положение в сегменте.
ACK	Указывает, что заголовок содержит подтверждение полученных данных В поле Acknowledgement Number.
PSH	Указывает, что данные должны быть переданы немедленно, не ожидая заполнения сегмента максимального размера.
RST	Указывает на необходимость уничтожения канала.
SYN	Указывает, что сегмент представляет собой управляющее сообщение, являющееся частью "тройного рукопожатия" для синхронизации порядковых номеров при создании канала.
FIN	Указывает, что сторона прекращает передачу данных и желает закрыть виртуальный канал.

Поле контрольной суммы Checksum используется для защиты от ошибок. Контрольная сумма вычисляется на основании 12-октетного псевдозаголовка, содержащего, в частности IP-адреса источника и получателя, а также номер протокола. Цель включения в контрольную сумму части заголовка IP та же, что и для протокола UDP — дополнительно защитить данные от получения не тем адресатом.

Поле Urgent Pointer позволяет указать расположение экстренных данных внутри сегмента. Это поле используется при установленном флаге URG и содержит порядковый номер октета, следующего за экстренными данными.

В конце заголовка располагается поле Options переменной длины, которое может содержать различные опции, например, максимальный размер сегмента (MSS). Это поле дополняется нулями (Padding) для того, чтобы заголовок всегда заканчивался на границе 32 бит.

Состояния TCP-сеанса

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

71

В нормальных условиях модули TCP хранят последние использованные порядковые номера. Поэтому при создании нового канала (сеанса) модуль выбирает следующее значение из адресного пространство порядковых номеров (которое составляет 2^3^2). При скорости передачи 2 Мбит/с потребуется 4,5 часа для передачи данных, адресуемых этими номерами (порядковыми и подтверждений). Это время на несколько порядков превышает время жизни TCP-сегмента в сети, которое по умолчанию составляет 2 секунды. Это гарантирует, что новые номера не "догонят" номера старых сегментов. Даже при скорости 100 Мбит/с полный цикл использования порядковых номеров составляет чуть больше 5 минут.

Начальная фаза сеанса передачи получила название "тройное рукопожатие" (three-way handshake), которое достаточно точно отражает процесс обмена служебными сегментами между сторонами. Этот процесс является ассиметричным — одна из сторон, называемая клиентом, инициирует начало сеанса, посылая другой стороне — серверу сегмент SYN. [72] Как правило этот сегмент является числом служебным, т.е. не содержит полезных данных, его заголовок определяет номер порта и начальный порядковый номер потока клиент-сервер. Если сервер готов принять данные от клиента, он создает логический канал (размещая соответствующие структуры данных) и отправляет клиенту сегмент с установленным начальным порядковым номером потока сервер-клиент и флагами SYN и ACK, подтверждающий получение сегмента SYN и выражающего готовность сервера к получению данных. Наконец, и это третье рукопожатие, клиент отвечает сегментом с установленным флагом ACK, подтверждающим получение ответа от сервера и тем самым завершающим фазу создания TCP-канала. Процесс установления связи в TCP-сеансе представлен на рис. 6.12.

72

Сегмент SYN имеет установленный флаг SYN в заголовке — отсюда и его название.

Рис. 6.12. Установление связи, передача данных и завершение TCP-сеанса

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

Завершение сеанса в TCP происходит в несколько этапов. Любая из сторон может завершить передачу данных, отправив сегмент с установленным флагом FIN (рис. 6.12). Получение такого сегмента подтверждается другой стороной и эквивалентно достижению конца файла при его чтении. Однако другая сторона может продолжать передавать данные, также впоследствии завершив передачу сегментом FIN. Подтверждение этого сегмента полностью разрушает канал и завершает сеанс. Для того чтобы гарантировать синхронизацию завершения сеанса, сторона, отправившая подтверждение на последний сегмент FIN, должна поддерживать сеанс достаточно долго, чтобы иметь возможность вновь подтвердить повторные сегменты FIN данного сеанса в случае, когда подтверждение не было получено другой стороной.

На рис. 6.12 также проиллюстрированы состояния коммуникационных узлов TCP-канала.

Как видно из рисунка, начальное состояние узла (сервера или клиента) — состояние CLOSED. Готовность сервера к обработке инициирующих запросов от клиента определяется переходом его в состояние LISTEN. С этого момента сервер может принимать и обрабатывать инициирующие сеанс сегменты SYN. При отправлении такого сегмента клиент переходит в состояние SYN-SENT и ожидает ответного запроса от сервера. Сервер при получении сегмента также отправляет сегмент SYN с подтверждением ACK и переходит в состояние SYN-RECEIVED. Подтверждение от клиента завершает "рукопожатие" и сеанс переходит в состояние ESTABLISHED. После завершения обмена данными одна из сторон (например, клиент) отправляет сегмент FIN, переходя при этом в состояние FIN-WAIT-1. Приняв этот сегмент другая сторона (например, сервер) отправляет подтверждение ACK и переходит в состояние CLOSE-WAIT, при этом канал становится симплексным — передача данных возможна только в направлении от сервера к клиенту. Когда клиент получает подтверждение он переходит в состояние FIN-WAIT-2, в котором находится до получения сегмента FIN. После подтверждения получения этого сегмента канал окончательно разрушается.