Чем отличается протокол TCP от UDP, простым языком. Протокол TCP

Transmission Control Protocol (TCP) (протокол управления передачей) - один из основных сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.

Выполняет функции протокола транспортного уровня модели OSI.

TCP - это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета (см. также T/TCP). В отличие от UDP гарантирует, что приложение получит данные точно в такой же последовательности, в какой они были отправлены, и без потерь.

Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.

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

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

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

Передача данных

Завершение соединения

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

Процесс начала сеанса TCP называется «тройным рукопожатием».

1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN.

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.

Передача данных

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

Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приемник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приемника передающей стороне в поле «окно» указывается текущий размер приемного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приемник. Если приемник указал нулевой размер окна, то передача данных в направлении этого узла не происходит, до тех пор пока приемник не сообщит о большем размере окна.

Завершение соединения

Завершение соединения можно рассмотреть в три этапа:

Посылка серверу от клиента флагов FIN и ACK на завершение соединения.

Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.

После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

Говорят, что протокол TCP осуществляет передачу с установлением логического соединения, поскольку перед началом обмена данными два процесса осуществляют «рукопожатие» - процедуру, заключающуюся в передаче друг другу специальных сегментов, предназначенных для определения параметров обмена данными. Частью процедуры установления TCP-соединения является инициализация переменных состояния (многие из которых будут рассмотрены в этом разделе и разделе «Контроль перегрузок в ТСР»), связанных с ТСР-соединением.

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

TCP-соединение обеспечивает дуплексную передачу данных. Если на двух хостах выполняются соответственно процессы А и В, то данные могут одновременно передаваться как от процесса А к процессу В, так и от процесса В к процессу А. ТСР-соединение также называют соединением точка-точка, то есть соединением между единственным приемником и единственным передатчиком. Групповая рассылка, описанная в главе 4, позволяет передавать данные сразу множеству адресатов с помощью одной операции, однако такая рассылка не поддерживается протоколом TCP.

Теперь давайте подробнее рассмотрим процесс установления ТСР-соединения. Предположим, что процесс, выполняющийся на одном хосте, желает установить соединение с процессом, выполняющимся на другом хосте. Вспомним о том, что процесс, инициирующий соединение, мы договорились называть клиентским, а процесс, с которым устанавливается соединение, - серверным. Сначала клиентский процесс сообщает транспортному уровню своего хоста о том, что необходимо установить соединение с серверным процессом. Обратившись к разделу «Программирование ТСР-сокетов» в главе 2, можно увидеть, что программа-клиент на языке Java делает это при помощи следующей команды:

Socket clientSocket = new Socket(«hostname», portNumber);

Здесь hostname - имя сервера, a portNumber - номер порта, идентифицирующий процесс внутри сервера. Затем транспортный уровень клиента начинает установление TCP-соединения с транспортным уровнем сервера. Эту процедуру мы детально рассмотрим в конце этого раздела, а пока нам достаточно знать, что клиент сначала посылает серверу специальный TCP-сегмент, сервер отвечает клиенту другим специальным сегментом, и, наконец, клиент посылает серверу третий специальный сегмент. Первые два сегмента не содержат данных прикладного уровня; третий сегмент может содержать их. Поскольку обмен сегментами входит в процедуру установления соединения, последнюю часто называют тройным рукопожатием.

После того как TCP-соединение установлено, прикладные процессы могут начинать обмен данными. Передача данных от клиента к серверу происходит следующим образом: клиент направляет поток своих данных в сокет («дверь» процесса), как описано в разделе «Программирование ТСР-сокетов» главы 2. Через сокет данные попадают в протокол TCP, выполняющийся на стороне клиента. Как показано на рис. 3.25, TCP направляет эти данные в буфер передачи - один из буферов, создаваемых при выполнении тройного рукопожатия. Время от времени TCP извлекает данные из буфера передачи. Интересной особенностью спецификации TCP (RFC 793) является свобода в выборе моментов отправки данных, находящихся в буфере. Согласно спецификации, протокол TCP должен «передать эти данные в виде сегментов в любой подходящий для этого момент времени». Максимальный объем данных, который может быть извлечен из буфера и помещен в сегмент, ограничивается максимальным размером сегмента (Maximum Segment Size, MSS). Максимальный размер сегмента зависит от реализации протокола TCP (определяется операционной системой) и может быть сконфигурирован; наиболее часто используются значения 1500,536 и 512 байт (размер сегмента часто устанавливается так, чтобы избежать IP-фрагментации, которая будет рассмотрена позже в этой главе). Обратите внимание на то, что максимальный размер относится к данным приложения, содержащимся в сегменте, а не к сегменту вместе с заголовком (такая терминология является несколько запутанной, однако мы вынуждены придерживаться этой терминологии ввиду ее распространенности).

Протокол TCP добавляет заголовок к каждому фрагменту данных, формируя TCP-сегменты. Сегменты передаются сетевому уровню, где заключаются в IP-дейтаграммы. Дейтаграммы пересылаются по сети и принимаются получателем. Когда сегмент оказывается на транспортном уровне, протокол TCP помещает данные сегмента в приемный буфер, как и показано на рисунке. Затем приложение считывает поток данных из буфера. Приемный и передающий буферы имеются на обеих сторонах соединения (мы рекомендуем читателю обратиться к апплету, который находится на нашем сайте _http://www.awl.com/kurose-ross и позволяет просмотреть анимацию, иллюстрирующую работу приемного и передающего буферов).
Итак, TCP-соединение состоит из буферов и переменных на передающей и принимающей сторонах, а также сокетного соединения между сторонами. При этом для соединения не выделяется никаких буферов или переменных на промежуточных сетевых устройствах (маршрутизаторах, мостах и повторителях).

ИСТОРИЧЕСКАЯ СПРАВКА —
В начале 1970-х годов стали получать распространение сети с коммутацией пакетов. Сеть APRAnet, предок Интернета, была одной из таких сетей. В каждой сети использовался собственный протокол. Двое исследователей, Уинтон Серф и Роберт Канн, понимая важность взаимодействия компьютерных сетей между собой, разработали межсетевой протокол TCP/IP (Transmission Control Protocol/Internet Protocol - протокол управления передачей/Интернет-протокол). Несмотря на то что изначально TCP/IP представлял собой единую сущность, позже он был разделен на две части, TCP и IR каждая из которых функционировала независимо. В мае 1974 года Серфом и Канном были выпущены публикации в IEEE Transaction on Communication Technology.

Протокол TCP/IP, составляющий основу современного Интернета, был разработан до появления персональных компьютеров и рабочих станций, технологий локальных сетей (Ethernet и др.), web, потокового аудио и чатов. Серф и Канн осознали необходимость в создании сетевого протокола, который бы обеспечивал, с одной стороны, мощную поддержку будущих сетевых приложений и, с другой стороны, взаимодействие протоколов более низких и более высоких уровней.

Вообще, организация соединения по протоколу TCP начинается с так называемого трехстороннего квитирования (рукопожатия).

Шаг 1. Отправка SYN пакета

Отправляется пакет с выставленным флагом SYN, что означает инициализацию сессии. Разумеется, на этом этапе будет задан порт источника и порт назначения (порт источника выбирается случайно из диапазона 1024-65535), хотя на этом участке можно выделить два диапазона ещё. Порты с 1024 до 49151 используются для проприетарных приложений, контролируется IANA (те же чуваки, которые и выделяют IP адреса). Порт назначения здесь зависит от используемой службы. Стандартные порты ssh – 22, http – 80, pop3 – 110 и т.д. Все эти порты прописаны в c:\Windows\System32\drivers\etc\services ну или аналогичный файл в Linux.

Как же выбирается этот номер? Приведу выдержку из RFC 793:

При организации нового соединения генерируется начальный порядковый номер (initial sequence number) ISN. Генерация номера основана на текущем (возможно, фиктивном) 32-битовом значении времени, в котором младший бит инкрементируется приблизительно каждые 4 микросекунды. Таким образом, цикл номеров ISN занимает около 4.55 часа. Поскольку мы предполагаем, что сегмент сохраняется в сети в течение времени, не превышающего MSL (Maximum Segment Lifetime – максимальное время жизни

сегмента), и значение MSL < 4.55 час., можно считать значения ISN уникальными.

То есть в первом пакете с битом SYN задается некий номер последовательности. На скрине выше я привел пример, видим бит SYN и ISN 2686526190 .

Шаг 2. Отправка подтверждения SYN+ACK

В ответ на этот пакет, сервер, если он не против соединения, посылает пакет с битами SYN,ACK и произвольным номером последовательности Sequence Number, вычисленным по похожему принципу. А поле Acknowledgment Number будет равняться полю ISN+1.

На примере видно, что сгенерировано число Initial Receive Sequence (IRS) = 675813843 и пакет послан как ответ AN: 2686526191 (предыдущий SN: 2686526190 + 1).

Шаг 3. Отправка подтверждения ACK

Теперь инициатору подключения не остается ничего другого, как ответить ACK и пояснить, что речь идёт об Acknowledgment number предыдущего шага IRS + 1, т.е. 675813843+1 = 675813844! А Sequence nuber остаётся неизменным, AN предыдущего пакета 2686526191.

Иначе, в переводе с TCP на русский это выглядит так:

1. Клиент: Кодовое слово “1” (Sequence number), сервер, давай мутить! (SYN);
2. Сервер: Моё кодовое слово “5” (Sequence number), клиент, на твой запрос по кодовому слову “1” (Acknowledgment number) отвечаю (+1) ну давай мутить (SYN+ACK).
3. Клиент: Ну хорошо! Раз ты, сервер, получай мой окончательный ответ ответ (ACK) на твое согласие (5+1) на мой запрос (1+1).

Всё. С этого момента соединение считается установленным. Дальнейшие пакеты будут передавать уже полезную нагрузку – данные протоколов вышестоящих уровней, например SSH.

При этому так же происходит взаимное увеличение Sequence Number у сервера и у клиента, но только уже не на 1, а на размер отправляемых данных.

С предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым, в отличие от UDP , целостность передаваемых данных и уведомление отправителя о результатах передачи.

Реализации TCP обычно встроены в ядра ОС . Существуют реализации TCP, работающие в пространстве пользователя .

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

Заголовок сегмента TCP

Порт источника, Порт назначения

Эти 16-битные поля содержат номера портов - числа, которые определяются по специальному списку .

Порт источника идентифицирует приложение клиента, с которого отправлены пакеты. Ответные данные передаются клиенту на основании этого номера.

Порт назначения идентифицирует порт, на который отправлен пакет.

Порядковый номер

Порядковый номер выполняет две задачи:

1. Если установлен флаг SYN, то это изначальный порядковый номер - ISN (Initial Sequence Number), и первый байт данных, которые будут переданы в следующем пакете, будет иметь номер, равный ISN + 1.
2. В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот порядковый номер

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

Номер подтверждения

Acknowledgment Number (ACK SN) (32 бита) - если установлен флаг ACK, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN+1 до ACK-1 включительно) были успешно получены.

Длина заголовка (смещение данных)

Длина заголовка (Data offset) занимает 4 бита и указывает значение длины заголовка, измеренное в 32-битовых словах. Минимальный размер составляет 20 байт (пять 32-битовых слов), а максимальный - 60 байт (пятнадцать 32-битовых слов). Длина заголовка определяет смещение полезных данных относительно начала сегмента. Например, Data offset равное 1111 говорит о том, что заголовок занимает пятнадцать 32-битных слова (15 строк*32 бита в каждой строке/8 бит = 60 байт).

Зарезервировано

Зарезервировано (6 бит) для будущего использования и должно устанавливаться в ноль. Из них два (5-й и 6-й) уже определены:

• CWR (Congestion Window Reduced) - Поле «Окно перегрузки уменьшено» - флаг установлен отправителем, чтобы указать, что получен пакет с установленным флагом ECE (RFC 3168)
• ECE (ECN-Echo) - Поле «Эхо ECN» - указывает, что данный узел способен на ECN (явное уведомление перегрузки) и для указания отправителю о перегрузках в сети (RFC 3168)

Флаги (управляющие биты)

Это поле содержит 6 битовых флагов:

• URG - поле «Указатель важности» задействовано (англ. Urgent pointer field is significant )
• ACK - поле «Номер подтверждения» задействовано (англ. Acknowledgement field is significant )
• PSH - (англ. Push function ) инструктирует получателя протолкнуть данные, накопившиеся в приёмном буфере, в приложение пользователя
• RST - оборвать соединения, сбросить буфер (очистка буфера) (англ. Reset the connection )
• SYN - синхронизация номеров последовательности (англ. Synchronize sequence numbers )
• FIN (англ. final , бит) - флаг, будучи установлен, указывает на завершение соединения (англ. FIN bit used for connection termination ).

Размер окна

Количество байт данных начиная с последнего номера подтверждения, которые может принять получатель данного пакета. Иначе говоря, получатель пакета располагает для приёма данных буфером длиной "размер окна" байт.

Контрольная сумма

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

Указатель важности

16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG. Используется для внеполосных данных .

Опции

Могут применяться в некоторых случаях для расширения протокола. Иногда используются для тестирования. На данный момент в опции практически всегда включают 2 байта NOP (в данном случае 0x01) и 10 байт, задающих timestamps . Вычислить длину поля опции можно через значение поля смещения.

Механизм действия протокола

В отличие от традиционной альтернативы - UDP, который может сразу же начать передачу пакетов, TCP устанавливает соединения, которые должны быть созданы перед передачей данных. TCP соединение можно разделить на 3 стадии:

• Установка соединения
• Передача данных
• Завершение соединения

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

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

Процесс начала сеанса TCP (также называемый «рукопожатие» (англ. handshake )), состоит из трёх шагов.

1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN.

• Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буферы и управляющие структуры памяти) для обслуживания нового клиента.
  • В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED.
  • В случае неудачи сервер посылает клиенту сегмент с флагом RST.

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.

• Если клиент одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED.
• Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться.
• Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.

• В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED.

Процесс называется «трёхэтапным согласованием» (англ. three way handshake ), так как несмотря на то что возможен процесс установления соединения с использованием четырёх сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется три сегмента.

Пример базового 3-этапного согласования:

TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> --> SYN-RECEIVED 3. ESTABLISHED <-- <-- SYN-RECEIVED 4. ESTABLISHED --> --> ESTABLISHED 5. ESTABLISHED <-- <-- ESTABLISHED

В строке 2 TCP A начинает передачу сегмента SYN, говорящего об использовании номеров последовательности, начиная со 100. В строке 3 TCP B передаёт SYN и подтверждение для принятого SYN в адрес TCP A. Надо отметить, что поле подтверждения показывает ожидание TCP B приёма номера последовательности 101, подтверждающего SYN с номером 100.

В строке 4 TCP A отвечает пустым сегментом с подтверждением ACK для сегмента SYN от TCP B; в строке 5 TCP B передаёт некоторые данные. Отметим, что номер подтверждения сегмента в строке 5 (ACK=101) совпадает с номером последовательности в строке 4 (SEQ=101), поскольку ACK не занимает пространства номеров последовательности (если это сделать, придётся подтверждать подтверждения - ACK для ACK).

Передача данных

При обмене данными приёмник использует номер последовательности, содержащийся в получаемых сегментах, для восстановления их исходного порядка. Приёмник уведомляет передающую сторону о номере последовательности, до которой он успешно получил данные, включая его в поле «номер подтверждения». Все получаемые данные, относящиеся к промежутку подтверждённых последовательностей, игнорируются. Если полученный сегмент содержит номер последовательности больший, чем ожидаемый, то данные из сегмента буферизируются, но номер подтверждённой последовательности не изменяется. Если впоследствии будет принят сегмент, относящийся к ожидаемому номеру последовательности, то порядок данных будет автоматически восстановлен исходя из номеров последовательностей в сегментах.

Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приёмник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приёмника передающей стороне, в поле «окно» указывается текущий размер приёмного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приёмник. Если приёмник указал нулевой размер окна, то передача данных в направлении этого узла не происходит, пока приёмник не сообщит о большем размере окна.

В некоторых случаях передающее приложение может явно затребовать протолкнуть данные до некоторой последовательности принимающему приложению, не буферизируя их. Для этого используется флаг PSH. Если в полученном сегменте обнаруживается флаг PSH, то реализация TCP отдаёт все буферизированные на текущий момент данные принимающему приложению. «Проталкивание» используется, например, в интерактивных приложениях. В сетевых терминалах нет смысла ожидать ввода пользователя после того, как он закончил набирать команду. Поэтому последний сегмент, содержащий команду, обязан содержать флаг PSH, чтобы приложение на принимающей стороне смогло начать её выполнение.

Завершение соединения

Завершение соединения можно рассмотреть в три этапа:

1. Посылка серверу от клиента флага FIN на завершение соединения.
2. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.
3. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

Известные проблемы

Максимальный размер сегмента

TCP требует явного указания максимального размера сегмента (MSS) в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока (MTU) менее, чем стандартный MTU Ethernet (1500 байт).

В протоколах туннелирования, таких как GRE , IPIP , а также PPPoE MTU туннель меньше, чем стандартный, поэтому сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Это приводит к фрагментации и уменьшению скорости передачи полезных данных. Если на каком-либо узле фрагментация запрещена, то со стороны пользователя это выглядит как «зависание» соединений. При этом «зависание» может происходить в произвольные моменты времени, а именно тогда, когда отправитель использовал сегменты длиннее допустимого размера. Для решения этой проблемы на маршрутизаторах применяются правила Firewall-а, добавляющие параметр MSS во все пакеты, инициирующие соединения, чтобы отправитель использовал сегменты допустимого размера.

MSS может также управляться параметрами операционной системы.

Обнаружение ошибок при передаче данных

Хотя протокол осуществляет проверку контрольной суммы по каждому сегменту, используемый алгоритм считается слабым . Так, в 2008 году ошибка в передаче одного бита, не обнаруженная сетевыми средствами, привела к остановке серверов системы Amazon Web Services .

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

Атаки на протокол

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

9.5.1.В протоколе TCP соединения устанавливаются с помощью “тройного рукопожатия” (“three-way handshake”). Чтобы установить соединение, одна сторона (например, сервер) пассивно ожидает входящего соединения, выполняя примитивы LISTEN и ACCEPT, либо указав конкретный источник, либо не указав никого конкретно.

Другая сторона (например, клиент) выполняет примитив CONNECT, указывая IP-адрес и порт, с которым он хочет установить соединение, максимальный размер ТСР - сегмента и, по желанию, некоторые данные пользователя (например, пароль). Примитив «CONNECT» посылает ТСР-сегмент с установленным битом SYN u сброшенным битом АСК и ждет ответа.

Когда этот сегмент прибывает в пункт назначения, TCP-сущность проверяет, выполнил ли какой-нибудь процесс примитив «LISTEN», указав в качестве параметра тот же порт, который содержится в поле «Порт получателя». Если такого процесса нет, она отвечает отправкой сегмента с установленным битом RST для отказа от соединения.

Если какой-либо процесс ожидает соединения на данном порту, то входящий ТСР-сегмент вручается этому процессу. Затем процесс может принять соединение или отказаться от него. Если процесс принимает соединение, он отсылает в ответ подтверждение. Последовательность ТСР-сегментов, посылаемых в нормальном случае, показана на рисунке106 а. Обратите внимание, что сегмент с установленным битом SYN потребляет один байт пространства порядковых номеров, чтобы не было неоднозначности в их подтверждениях.

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

Рисунок 106- Установка TCP-соединения в нормальном случае (а); столкновение вызовов (б)

Начальное значение порядкового номера не равно нулю. Используется схема, основанная на часах, тикающих каждые 4 мкс. Для большей надежности хосту после сбоя запрещается перезагружаться ранее, чем через 120 с (максимальное время жизни пакета), чтобы гарантировать, что ни один пакет от прежних соединений не бродит где-нибудь в Интернете.

9.5.2 Хотя TCP-соединения являются дуплексными, чтобы понять, как происходит их разъединение, лучше считать их парами симплексных соединений. Каждое симплексное соединение разрывается независимо от своей пары.

Для того чтобы установить соединение, необходимо 3 сегмента, а для того чтобы разорвать - 4. Это объясняется тем, что TCP соединение может быть в наполовину закрытом состоянии. Так как TCP соединение полнодуплексное (данные могут передвигаться в каждом направлении независимо от другого направления), каждое направление должно быть закрыто независимо от другого. Правило заключается в том, что каждая сторона должна послать FIN, когда передача данных завершена. Когда TCP принимает FIN, он должен уведомить приложение, что удаленная сторона разрывает соединение и прекращает передачу данных в этом направлении. FIN обычно отправляется в результате того, что приложение было закрыто.

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

Можно сказать, что та сторона, которая первой закрывает соединение (отправляет первый FIN), осуществляет активное закрытие, а другая сторона (которая приняла этот FIN) осуществляет пассивное закрытие. Обычно одна сторона осуществляет активное закрытие, а другая - пассивное, однако в обе стороны могут осуществить активное закрытие "Одновременное закрытие".

Когда сервер получает FIN, он отправляет назад ACK с принятым номером последовательности плюс один. На FIN тратится один номер последовательности, так же как на SYN. В этот момент TCP сервер также доставляет приложению признак конца файла (end-of-file) (чтобы выключить сервер). Затем сервер закрывает свое соединение, что заставляет его TCP послать FIN, который клиент должен подтвердить (ACK), увеличив на единицу номер принятой последовательности.

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

Соединения обычно устанавливаются клиентом, то есть первый SYN двигается от клиента к серверу. Однако любая сторона может активно закрыть соединение (послать первый FIN). Часто, однако, именно клиент определяет, когда соединение должно быть разорвано, так как процесс клиента в основном управляется пользователем, который вводит что-нибудь подобное "quit", чтобы закрыть соединение.

Рисунок 107 - Обычный обмен сегментами при закрытии соединения.

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

При разъединении оба конца переходят от состояния «Установлено» (ESTABLISHED) к состоянию «Ожидание FIN 1» (FIN WAIT 1) , когда приложение выдает сигнал к закрытию. При этом оба посылают FIN, которые возможно встретятся где-нибудь в сети. Когда FIN принят, на каждом конце происходит переход из состояния FIN WAIT 1 в состояние «Закрываю» (CLOSING) и с каждой стороны посылается завершающий ACK. Когда каждый конец получает завершающий ACK, состояние меняется на TIME WAIT. На рисунке 108 показаны изменения состояний.

Рисунок 108 - Обмен сегментами в процессе одновременного закрытия.

При одновременном закрытии происходит обмен таким же количеством пакетов, как и при обычном закрытии.

Чтобы избежать проблемы двух армий, используются таймеры. Если ответ на посланный FIN-ceruem не приходит в течение двух максимальных интервалов времени жизни пакета, отправитель FIN-сегмеита разрывает соединение. Другая сторона в конце концов заметит, что ей никто не отвечает, и также разорвет соединение. Хотя такое решение и не идеально, учитывая недостижимость идеала, при­ходится пользоваться тем, что есть. На практике проблемы возникают довольно редко.

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

Чтобы использовать эту характеристику программного интерфейса, необходимо предоставить возможность приложению сказать: "Я закончило передачу данных, поэтому посылаю признак конца файла (end-of-file) (FIN) на удаленный конец, однако я все еще хочу получать данные с удаленного конца до тех пор, пока он мне не пошлет признак конца файла (end-of-file) (FIN)."

На рисунке 109 показан стандартный сценарий для полузакрытого TCP. Мы показали клиента с левой стороны, он инициирует полузакрытый режим, однако это может сделать любая сторона. Первые два сегмента одинаковы: FIN от инициатора, за ним следует ACK и FIN от принимающего. Однако дальше сценарий будет отличаться от того, который приведен на рисунке 108, потому что сторона, которая приняла приказ "полузакрыть", может все еще посылать данные. На рисунке 109 показан только один сегмент данных, за которым следует ACK, однако в этом случае может быть послано любое количество сегментов данных. Когда конец, который получил приказ "полузакрыть", осуществил передачу данных, он закрывает свою часть соединения, в результате чего посылается FIN, при этом признак конца файла доставляется приложению, которое инициировало "полузакрытый" режим. Когда второй FIN подтвержден, соединение считается полностью закрытым.

Рисунок 109 - TCP в полузакрытом режиме.

9.5.4 Этапы, необходимые для установки и разрыва соединения, могут быть представлены в виде диаграммы конечных состояний, 11 состояний которой перечислены в таблице 11. В каждом состоянии могут происходить разрешенные и запрещенные события. В ответ на какое-либо разрешенное событие может осуществляться определенное действие. При возникновении запрещенных событий сообщается об ошибке. Каждое соединение начинается в состоянии CLOSED (закрытое). Оно может покинуть это состояние, предпринимая либо активную (CONNECT), либо пассивную (LISTEN) попытку открыть соединение. Если противоположная сторона предпринимает противоположные действия, соединение устанавливается и переходит в состояние ESTABLISHED. Инициатором разрыва соединения может выступить любая сторона. По завершении процесса разъединения соединение возвращается в состояние CLOSED.

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

Диаграмма конечных состоянии показана на рисунке 110. Обычный случаи клиента, активно соединяющегося с пассивным сервером, показан жирными линиями - сплошными для клиента и пунктиров для сервера. Тонкие линии обозначают необычные последовательности событий. Каждая линия на рисунке 110 маркирована парой событие/действие. Событие может быть либо обращением пользователя к системной процедуре (CONNECT, LISTEN, SEND или CLOSE), либо прибытием сегмента (SYN, FIN, ACK или RST), либо, в одном случае, истекшим периодом ожидания, равным двойному времени жизни пакетов. Действие может состоять в отправке управляющего сегмента (SYN, FIN или RST) или может не предприниматься никакого действия, что обозначается прочерком. В скобках приводятся комментарии.

Диаграмму легче всего понять, сначала следуя по пути клиента (сплошная жир­ная линия), затем по пути сервера (пунктир). Когда приложение на машине клиента вызывает примитив CONNECT, локальная TCP-сущность создает запись соединения, помечает его состояние как

SYN SENT посылает, SYN сегмент. Несколько приложений одновременно могут открыть несколько соединений, поэтому свое состояние, хранящееся в записи соединения, есть у каждого отдельного соединения. Когда прибывает сегмент SYN + ACK, TCP-сущность посылает последний ACK-сегмент «тройного рукопожатия» и переключается в состояние ESTABLISHED. В этом состоянии могут пересылаться и получаться данные.

На рисунке 110 жирной сплошной линией показан нормальный путь клиента. Пунктиром показан путь сервера. Тонкими линиями обозначены необычные события

Рисунок 110 - Диаграмма конечных состояний TCP-соединения.

Когда у приложения больше нет данных для передачи, оно выполняет прими­тив CLOSE, заставляющий локальную TCP-сущность послать F/N-сегмент и ждать ответного ACK-сегмента (пунктирный прямоугольник с пометкой «активное разъединение»). Когда прибывает подтверждение, происходит переход в состояние FIN WAIT 2, и одно направление соединения закрывается. Когда приходит встречный FIN-сегмент, в ответ на него также высылается подтверждение, и второе направление соединения также закрывается. Теперь обе стороны соединения закрыты, но TCP-сущность выжидает в течение времени, равного максимальному времени жизни пакета, чтобы гарантировать, что все пакеты этого соединения больше не перемещаются по сети, даже в том случае, если подтверждение было потеряно. Когда этот период ожидания истекает, TCP-сущность удаляет запись о соединении.

Рассмотрим теперь управление соединением с точки зрения сервера. Сервер выполняет примитив LISTEN и переходит в режим ожидания запросов соединения. Когда приходит SYN сегмент, в ответ на него высылается подтверждение, после чего сервер переходит в состояние SYNRCVD (запрос соединения получен). Когда в ответ на SYN-подтверждение сервера от клиента приходит ACK-сегмент, процеду­ра «тройного рукопожатия» завершается и сервер переходит в состояние ESTABLISHED. Теперь можно пересылать данные.

Когда клиент передал достаточное количество данных, он выполняет примитив CLOSE, в результате чего FIN-сегмент прибывает на сервер (пунктирный прямоугольник, обозначенный как пассивное разъединение). Теперь сервер выполняет примитив CLOSE, a FIN-сегмент посылается клиенту. Когда от клиента прибывает подтверждение, сервер разрывает соединение и удаляет запись о соединении.

Протокол TCP обеспечивает надёжную доставку информации в том смысле, что он организует прямое подтверждение (квитирование) корректного приёма информации получателем.

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

Ожидание квитанции может быть бесконечным. Для выхода из такого состояния используется механизм тайм-аута. Сущность его заключается в том, что отправитель, передав в канал блок, включает счетчик времени и ожидает квитанцию в течение некоторого временного интервала (тайм-аута) с момента передачи. По истечении этого времени отправитель считает, что пакет утерян или искажен, и повторяет передачу (положительное квитирование с повторной передачей – positive acknowledgment with retransmission).

В таблице 12. сведены состояния TCP соединения с указанием состояний битов управления на каждом из этапов состояния соединения, А также указаны содержания полей: «порядковый номер» N(S) и «Номер подтверждения» N(R). Поле «номер» указывает на последовательность передачи блоков.

Таблица 12– Состояния TCP соединения

9.5.5 Ожидание квитанции может быть бесконечным. Для выхода из такого состояния используется механизм тайм-аута. Сущность его заключается в том, что отправитель, передав в канал блок, включает счетчик времени и ожидает квитанцию в течение некоторого временного интервала (тайм-аута) с момента передачи. По истечении этого времени отправитель считает, что пакет утерян или искажен, и повторяет передачу (положительное квитирование с повторной передачей – positive acknowledgment with retransmission).

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

TCP управляет четырьмя таймерами для каждого соединения:

Таймер повторной передачи (retransmission) используется в том случае, когда ожидается подтверждение от удаленного конца.

Устойчивый (persist) таймер, в течение которого сохраняется информация о размере окна передачи, даже если удаленный конец закрыл свое приемное окно.

Таймер времени жизни (keepalive) определяет, когда можно считать, что удаленный конец вышел из строя или перезагрузился.

Таймер 2MSL определяет время, в течение которого соединение может быть в состоянии «TIME WAIT».

Основой тайм-аутов и повторных передач TCP является расчет времени возврата (RTT - round-trip time), соответствующего данному соединению. Мы ожидаем, что оно может изменяться со временем, так как может измениться маршрут или загрузка сети. TCP должен отследить эти изменения и соответственно модифицировать тайм-ауты.

Состояние «Время ожидания» (TIME WAIT) также иногда называется состоянием ожидания 2MSL (MSL - maximum segment lifetime). В каждой реализации выбирается значение для максимального времени жизни сегмента MSL. Это максимальное время, в течение которого сегмент может существовать в сети, перед тем как он будет отброшен. Мы знаем, что это время ограничено, так как TCP сегменты передаются посредством IP датаграмм, а каждая IP датаграмма имеет поле TTL, которое ограничивает время ее жизни.

При использовании MSL действуют следующие правила: когда TCP осуществляет активное закрытие и посылает последний сегмент, содержащий подтверждение (ACK), соединение должно остаться в состоянии TIME WAIT на время равное двум MSL. Это позволяет TCP повторно послать последний ACK в том случае, если первый ACK потерян (в этом случае удаленная сторона отработает тайм-аут и повторно передаст свой конечный FIN).

Другое назначение ожидания 2MSL заключается в том, что пока TCP соединение находится в ожидании 2MSL, пара сокетов, выделенная для этого соединения (IP адрес клиента, номер порта клиента, IP адрес сервера и номер порта сервера), не может быть повторно использована. Это соединение может быть использовано повторно только, когда истечет время ожидания 2MSL.

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

Некоторые реализации и API предоставляют средства, которые позволяют обойти эти ограничения. С использованием API сокет может быть указана опция сокета «SO REUSEADDR». Она позволяет вызывающему назначить себе номер локального порта, который находится в состоянии 2MSL, однако мы увидим, что правила TCP не позволяют этому номеру порта быть использованным в соединении, которое находится в состоянии ожидания 2MSL.

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

Как мы уже показали, обычно клиент осуществляет активное закрытие и входит в режим «TIME WAIT». Сервер обычно осуществляет пассивное закрытие и не проходит через режим «TIME WAIT». Можно сделать вывод, что если мы выключим клиента и немедленно его перестартуем, этот новый клиент не сможет использовать тот же самый локальный номер порта. В этом нет никакой проблемы, так как клиенты обычно используют динамически назначаемые порты и не заботятся, какой динамически назначаемый порт используется в настоящее время.

Однако, с точки зрения сервера, все иначе, так как сервера используют заранее известные порты. Если мы выключим сервер, который имеет установленное соединение, и постараемся немедленно перестартовать его, сервер не может использовать свой заранее известный номер порта в качестве конечной точки соединения, так как этот номер порта является частью соединения, находящегося в состоянии ожидания 2MSL. Поэтому может потребоваться от 1 до 4 минут, перед тем как сервер будет перестартован.

Состояние ожидания 2MSL предоставляет защиту от опоздавших пакетов, принадлежащих ранним соединениям, при этом они не будут интерпретироваться как часть нового соединения, которое использует те же самые локальный и удаленный IP адреса и номера портов. Однако это работает только в том случае, если хост с соединением в состоянии 2MSL не вышел из строя.

Что если хост с портами в состоянии 2MSL вышел из строя, перезагрузился во время MSL и немедленно установил новые соединения с использованием тех же самых локальных и удаленных IP адресов и номеров портов, соответствующих локальным портам, которые были в состоянии 2MSL перед поломкой? В этом случае опоздавшие сегменты из соединения, которое существовало перед поломкой, могут быть ошибочно интерпретированы как принадлежащие новому соединению, созданному после перезагрузки. Это может произойти вне зависимости от того, какой исходный номер последовательности выбран после перезагрузки.

Чтобы защититься от подобных нежелательных сценариев, RFC 793 указывает, что TCP не должен создавать новые соединения до истечения MSL после момента загрузки. Это называется тихое время (quiet time).

В некоторых реализациях хосты ожидают даже дольше, чем время MSL после перезагрузки.

В состоянии «FIN WAIT 2» (Ожидание и подтверждение FIN) мы посылаем наш FIN, а удаленная сторона подтверждает его. Если мы не находимся в состоянии полузакрытого соединения, то ожидаем от приложения на удаленном конце, что оно опознает прием признака конца файла и закроет свою сторону соединения, причем пошлет нам FIN. Только когда процесс на удаленном конце осуществит это закрытие, наша сторона перейдет из режима «FIN WAIT 2» в режим «TIME WAIT».

Это означает, что наша сторона соединения может остаться в этом режиме навсегда. Удаленная сторона все еще в состоянии «CLOSE WAIT» и может оставаться в этом состоянии всегда, до тех пор, пока приложение не решит осуществить закрытие.

9.5.6 Максимальный размер сегмента (MSS) это самая большая порция данных, которую TCP пошлет на удаленный конец. Когда соединение устанавливается, каждая сторона может объявить свой MSS. IP дейтаграмма, которая получится в результате, обычно на 40 байт больше: 20 байт отводится под TCP заголовок и 20 байт под IP заголовок.

Когда соединение устанавливается, каждая сторона объявляет MSS, которой она собирается принимать. (Опция MSS может быть использована только в SYN сегменте.) Если одна сторона не принимает опцию MSS от другой стороны, используется размер по умолчанию в 536 байт. (В этом случае, при 20-байтном IP заголовке и 20-байтном TCP заголовке, размер IP датаграммы будет составлять 576 байт.)

В общем случае, чем больше MSS тем лучше, до тех пор пока не происходит фрагментация. Большие размеры сегмента позволяют послать больше данных в каждом сегменте, что уменьшает относительную стоимость IP и TCP заголовков. Когда TCP отправляет SYN сегмент, либо когда локальное приложение хочет установить соединение, или когда принят запрос на соединение от удаленного хоста, может быть установлено значение MSS равное MTU исходящего интерфейса минус размер фиксированных TCP и IP заголовков. Для Ethernet MSS может достигать 1460 байт. При использовании инкапсуляции IEEE 802.3 MSS может быть до 1452 байт.

Если IP адрес назначения "нелокальный", MSS обычно устанавливается по умолчанию - 536. Является ли локальным или нелокальным конечный пункт назначения можно следующим образом. Пункт назначения, IP адрес которого имеет тот же самый идентификатор сети и ту же самую маску подсети, что и у отправителя, является локальным. Пункт назначения, IP адрес которого полностью отличается от идентификатора сети, является нелокальным, Пункт назначения с тем же самым идентификатором сети, однако с другой маской подсети может быть как локальным, так и нелокальным. Большинство реализаций предоставляют опцию конфигурации, которая позволяет системному администратору указать, какие подсети являются локальными, а какие нелокальными. Установка этой опции определяет максимальный анонсируемый MSS (который по величине может достигать MTU исходящего интерфейса), иначе используется значение по умолчанию равное 536.

MSS позволяет хосту устанавливать размер дейтаграмм, который будет отправляться удаленной стороной. Если принять во внимание тот факт, что хост также ограничивает размер дейтаграмм, которые он отправляет, это позволяет избежать фрагментации, когда хост подключен к сети с меньшим MTU.

9.5.7.В TCP заголовке существует бит, называемый RST, что означает "сброс" (reset). В общем случае сигнал "сброс" (reset) посылается TCP в том случае, если прибывающие сегменты не принадлежат указанному соединению. (термин "указанное соединение" (referenced connection), который обозначает соединение, идентифицируемое IP адресом назначения и номером порта назначения, а также IP адресом источника и номером порта источника.(В RFC 793 - называется "сокет".)

Самый общий случай, при котором генерируется сброс (reset), это когда запрос о соединении прибывает и при этом не существует процесса, который слушает порт назначения. В случае UDP, если дейтаграмма прибывает на неиспользуемый порт назначения - генерируется ошибка ICMP о недоступности порта. TCP вместо этого использует сброс.

Рассмотрим поле номера последовательности и поле номера подтверждения в сбросе. Так как бит подтверждения (ACK) не был установлен в прибывшем сегменте, номер последовательности сброса установлен в 0, а номер подтверждения установлен во входящий исходный номер последовательности (ISN) плюс количество байт данных в сегменте. Несмотря на то, что в прибывшем сегменте не присутствует реальных данных, бит SYN логически занимает 1 байт в пространстве номера последовательности; таким образом, в этом примере номер подтверждения в сбросе устанавливается в ISN плюс длина данных (0) плюс один SYN бит.

Обычный метод, используемый для разрыва соединения, заключается в том, что одна из сторон посылает FIN. Иногда это называется правильным освобождением (orderly release), так как FIN посылается после того, как все данные, ранее поставленные в очередь, были отправлены, и обычно при этом не происходит потеря данных. Однако существует возможность прервать соединение, послав сброс (reset) вместо FIN. Иногда это называется прерывающим освобождением (abortive release).

Подобный разрыв соединения предоставляет приложению две возможности:

Любые данные, стоящие в очереди, теряются, и сброс отправляется немедленно;

Сторона, принявшая RST, может сказать, что удаленная сторона разорвала соединение, вместо того чтобы закрыть его обычным образом. Программный интерфейс (API), который используется приложением, должен предоставлять способ сгенерировать подобный сброс вместо нормального закрытия.

9.5.8 Определение полуоткрытого соединения

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

Еще одна причина, по которой может возникнуть полуоткрытое соединение, заключается в том, что на хосте клиента было выключено питание, вместо того чтобы погасить приложение клиента, а затем выключить компьютер. Это происходит когда, например, Telnet клиент запускается на PC, и пользователи выключают компьютер в конце рабочего дня. Если в момент выключения PC не осуществлялась передача данных, сервер никогда не узнает, что клиент исчез. Когда пользователь приходит на следующее утро, включает свой PC и стартует новый клиент Telnet, на хосте сервера стартует новый сервер. Из-за этого на хосте сервера может появиться очень много открытых TCP соединений.