Установление соединения

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

Соединение между двумя устройствами производится в три этапа (рис.2.9).

Рис.2.9.Установление соединения

Во-первых, инициализирующее устройство производит установление связи путем посылки устройству назначения запроса синхронизации SYN (1).

Во-вторых, принимающий узел подтверждает запрос синхронизации и задает свои параметры синхронизации в противоположном направлении ACK (2).

Третья часть – это подтверждение, посылаемое адресату назначения, что обе стороны согласны, чтобы соединение было установлено (3). После того, как соединение было установлено, начинается передача данных.

Такой механизм получил название трехэтапного установления связи (Three-way handshake). Кроме того, оба узла должны согласовать начальную последовательность номеров передаваемых частей информации, что происходит через обмен сегментами, несущими служебный бит синхронизации (SYN) и начальные номера последовательности.

Синхронизация требует, чтобы каждая сторона послала собственный начальный номер последовательности и получила подтверждение обмена (ACK) от другой стороны. Каждая сторона, получив начальный номер последовательности от другой стороны, отвечает подтверждением ACK. При этом последовательность, соответствующая рис.2.9, будет следующей:

1. Посылающий узел (A) инициализирует соединение, посылая сегмент SYN узлу получения (B), в котором указывает последовательный номер Sequence Number, например, SEC_А = 101.

2. Получив сегмент инициализации соединения, узел B делает запись принятого номера последовательности 101 и формирует ответ в виде ACK_В = 101 + 1 = 102. Ответ ACK_В = 102 означает, что хост B получил все байты данных, включая байт с номером 101, и ожидает следующий байт с номером 102. Одновременно хост B формирует начальный номер своей ответной последовательности порций данных, например, SEC_В = 51.

3. Узел A, получив сегмент от B со значениями ACK_В = 102, SEC_В = 51, формирует ответ ACK_А = 52, SEC_А = 102, который завершает процесс соединения.

Управление потоком данных

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

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

Рис.2.10. Процесс передачи данных при размере окна равном 1

Размер окна (Window) определяет число пакетов (или байт данных), которые отправитель может передать до получения ответа ACK. Номер ACK относится к номеру следующего пакета, который ожидается. О размере окна узлы договариваются динамически в сеансе TCP. Узел-получатель сообщает о размере окна хосту источнику. Окно определяет число пакетов, которые хост адресат готов получить. При увеличении размера окна, например, до трех (рис.2.11) производительность передачи данных повышается.

Производительность сети повышается, поскольку адресат на три полученных пакета данных посылает только одно подтверждение исходному устройству, которое затем может передать следующие три пакета.

Рис.2.11. Процесс передачи данных при размере окна равном 3

Если адресат не получает три пакета, например, из-за переполнения буферов, он не посылает подтверждение. Поскольку источник не получает подтверждение, он знает, что пакеты должны быть повторно переданы, и что скорость передачи должна быть уменьшена. Например, согласно рис.2.12 отправитель посылает три пакета прежде, чем ожидает получить подтверждение ACK.

Рис.2.12. Процесс передачи данных при переполнении буферных устройств

Если получатель может обработать только 2 пакета, он в качестве следующего запрашивает пакет 3, при этом указывает новый размер окна, равный двум.

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

В устройстве-получателе протокол TCP собирает сегменты в целое сообщение в соответствии с последовательными номерами. Если какой-то порядковый номер отсутствует в полученном ряде, то этот пропущенный сегмент передается повторно.

Последовательность частей (порций) передаваемых данных обычно представляет собой последовательность байтов. Поэтому и размер окна в заголовке сегмента задается в количестве передаваемых байт. Узел-получатель передает отправителю подтверждение ACK, когда примет указанное в окне количество байт данных. На рис.2.13 приведен пример, когда размер окна составляет 3000 байт.

Рис.2.13. Процесс передачи байт данных

Каждый передаваемый пакет содержит 1500 байт, что соответствует максимальному размеру кадра Ethernet. Поэтому узел-отправитель передает два сегмента подряд, на которые узел-получатель посылает подтверждение ACK с номером следующего ожидаемого байта, т.е. ACK = 3001. После получения узлом-отправителем подтверждения процесс передачи данных повторяется.

Если какой-то сегмент в процессе передачи был потерян, например, из-за перегрузки сети, то узел-получатель в ответе укажет начальный номер потерянного сегмента (рис.2.14), чтобы этот сегмент был передан повторно. При этом размер окна уменьшается до 1500 байт, т.е. до размера одного передаваемого пакета.

Рис.2.14. Перегрузка в процессе передачи байт данных

Одним из механизмов контроля потока является посылка отправителю индикаторов «не готов» (not ready) и «готов» (ready). Процесс передачи данных может повторяться либо до окончания передачи всего сообщения, либо до момента перегрузки сети, которая может произойти по двум причинам:

1. Высокоскоростной узел-отправитель генерирует трафик быстрее, чем сеть может передать его, а узел-получатель принять.

2. Несколько узлов одновременно посылают пакеты одному узлу-получателю.

Когда данные прибывают на узел-получатель слишком быстро, то буферные устройства адресата могут быть перегружены и приходящие пакеты будут отбрасываться. Чтобы не потерять данные, процесс TCP на узле-получателе может послать отправителю транспортный индикатор «не готов» (not ready). Этот индикатор сообщает отправителю, что следует приостановить передачу данных. Когда получатель вновь сможет обработать дополнительные данные, он посылает транспортный индикатор «готов» (ready). Когда этот индикатор получен, отправитель может продолжить передачу.

Для завершения соединения в конце передачи данных, узел-отправитель, инициализировавший обмен данными, посылает сигнал конца передачи FIN, вместо сигнала синхронизации SIN в начале установления соединения. В ответ на это узел-получатель подтверждает (ACK) конец передачи и также посылает сигнал конца передачи FIN. Узел-отправитель подтверждает получение информации (ACK), на этом соединение заканчивается, т.е. завершение соединения происходит в четыре этапа.

Следует помнить ещё об одном различии между протоколами транспортного уровня TCP и UDP. При прохождении по сети пакеты одного большого сообщения могут двигаться по разным маршрутам. Поэтому на устройство назначения они могут приходить не в том порядке, в котором передавались. Протокол контроля передачи TCP, используя механизм нумерации последовательности, позволяет восстановить (реассемблировать) исходный порядок следования пакетов. Напротив, протокол дейтаграмм пользователя UDP не может выполнить операцию восстановления исходного порядка следования пакетов. При этом такая возможность реализуется только протоколом прикладного уровня.