Транспортный протокол tcp обеспечивает. Протокол TCP

). В отличие от приложение получит данные точно в такой же последовательности, в какой они были отправлены, и без потерь.

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

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

Формат TCP-сегмента

Формат TCP-сегмента

Бит	0 - 3	4 - 9	10 - 15	16 - 31
0	Порт источника			Порт назначения
32	Номер последовательности
64	Номер подтверждения
96	Смещение данных	Зарезервировано	Флаги	Окно
128	Контрольная сумма			Указатель важности
160	Опции (необязательное)
160/192+	Данные

Порт источника

Порт назначения

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

Номер последовательности

Номер последовательности выполняет две задачи:

Если установлен флаг SYN, то это начальное значение номера последовательности и первый байт данных - это номер последовательности плюс 1.
В противном случае, если SYN не установлен, первый байт данных - номер последовательности

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

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

Если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз. Помечает этот сегмент как подтверждение получения.

Смещение данных

Это поле определяет размер заголовка пакета TCP в 32-битных словах. Минимальный размер составляет 5 слов, а максимальный - 15, что составляет 20 и 60 байт соответственно. Смещение считается от начала заголовка TCP.

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

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

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-битных слов заголовка и текста. Если сегмент содержит нечетное число октетов в заголовке /или тексте, последние октеты дополняются справа 8 нулями для выравнивания по 16-битовой границе. Биты заполнения (0) не передаются в сегменте и служат только для расчета контрольной суммы. При расчете контрольной суммы значение самого поля контрольной суммы принимается равным 0.

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

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

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

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

Состояния сеанса TCP
CLOSED	Начальное состояние узла. Фактически фиктивное
LISTEN	Сервер ожидает запросов установления соединения от клиента
SYN-SENT	Клиент отправил запрос серверу на установление соединения и ожидает ответа
SYN-RECEIVED	Сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения
ESTABLISHED	Соединение установлено, идёт передача данных
FIN-WAIT-1	Одна из сторон (назовём её узел-1) завершает соединение, отправив сегмент с флагом FIN
CLOSE-WAIT	Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь сегмент ACK и продолжает одностороннюю передачу
FIN-WAIT-2	Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN
LAST-ACK	Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN
TIME-WAIT	Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт 2*MSL секунд, перед окончательным разрушением канала
CLOSING	Обе стороны инициировали закрытие соединения одновременно: после отправки сегмента с флагом FIN узел-1 также получает сегмент FIN, отправляет ACK и находится в ожидании сегмента ACK (подтверждения на свой запрос о разъединении)

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

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

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

Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED. В противном случае после таймаута он закрывает сокет и переходит в состояние CLOSED.

Процесс называется «тройным рукопожатием», поскольку возможен процесс установления соединения с использованием 4 сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), но для экономии времени используется 3 сегмента.

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

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

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

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

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

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

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

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

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

Проявление этой проблемы выглядит как «зависание» соединений. При этом «зависание» может происходить в произвольные моменты времени, а именно тогда, когда отправитель использовал сегменты длинее допустимого размера.

Для решения этой проблемы на маршрутизаторах применяются правила Firewall-а, добавляющие параметр MSS во все пакеты, инициирующие соединения, чтобы отправитель использовал сегменты допустимого размера.

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

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

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

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

Реализация

См. также

Ссылки

RFC 793 - Transmission Control Protocol

Литература

Терри Оглтри Модернизация и ремонт сетей = Upgrading and Repairing Networks. - 4-е изд. - М.: «Вильямс» , 2005. - С. 1328. - ISBN 0-7897-2817-6
Дуглас Камер Сети TCP/IP, том 1. Принципы, протоколы и структура = Internetworking with TCP/IP, Vol. 1: Principles, Protocols and Architecture. - М.: «Вильямс» , 2003. - С. 880. - ISBN 0-13-018380-6

Андрей Робачевский, Сергей Немнюгин, Ольга Стесик Операционная система UNIX. - 2-е изд. - "БХВ-Петербург" , 2007. - С. 656. - ISBN 5-94157-538-6

Основные протоколы TCP/IP
Прикладной уровень	IMAP4
Передача файлов			XDR
Транспортный уровень	TCP ·	IPv4 ·

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

Внимание! Этот материал рассчитан на тех, кого действительно интересуется вопросом: «Как устроена сеть, и что я могу сделать, если буду это знать». Если же тебя еще смущают слова вроде DNS, Telnet, Socket — то можешь сразу забить на этот материал — такие «страшные» слова тут конечно не встретятся, но от этого содержание понятней не станет…

Для тех кто остался:

Наверное, многие из вас слышали такие слова как SYN-flooding или IP-spoofing. Все это разновидности атак — первая D.O.S., вторая
состоит в подмене IP-адреса. На первый взгляд между этими примерами нет ничего общего, но между тем, это не так — обе эти атаки не возможны без глубокого знания протокола TCP, протокола на котором стоит
Inet.

Спецификация протокола TCP описана в RFC793 . Рекомендую тебе ознакомится с этим документом, потому как хоть я и постараюсь повести до тебя самое важное, снабдив это важное соответствующими комментариями, которых ты не найдешь в мануале, но все же из-за малого объема и практического угла зрения, могу и упустить некоторые тонкости.

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

Структура TCP-пакета:

Поясню только самые важные места:

Адрес получателя, порт получателя и адрес отправителя, порт отправителя — это надеюсь понятно.

Sequence Number(SYN) — номер очереди или последовательный номер, показывает порядковый номер пакета при передаче, именно поэтому принимающая система собирает пакеты именно так, как надо, а не в том порядке, как они пришли.

Acknowledgment Number(ACK) — номер подтверждения, показывает, на пакет с каким SYN отвечает удаленная система, таким образом мы имеем представление, что удаленная система получила наш пакет с данным
SYN.

Контрольные биты- 6 бит (на схеме между reversed и window). Значения битов:

URG: поле срочного указателя задействовано
ACK: поле подтверждения задействовано
PSH: функция проталкивания
RST: перезагрузка данного соединения
SYN: синхронизация номеров очереди
FIN: нет больше данных для передачи

DATA — это непосредственно те данные, которые мы хотим передать.

Думаю, для начала это все, что нужно, чтобы понять принцип работы протокола. Более подробно о значении остальных полей ты можешь прочитать в в RFC793. Ну а мы лучше разберем как же все-таки это работает на практике.

Когда мы хотим установить соединение, мы отправляем удаленной системе пакет следующей структуры:

Client — SYN (856779) — Host

Где Client- это мы, a Host — это удаленная система. Как ты видишь, мы посылаем пакет лишь с указанием SYN — это значит, что этот пакет первый, мы ни на что не отвечаем (отсутствует ACK). Данный пакет выглядит примерно так:

20 53 52 43 00 00 44 45 53 54 00 00 08 00 45 00 00 2C C3 00 40 00 20 06 10 0C CB 5E FD BA CB 5E F3 47 04 07 00 17 00 0D 12 CB 00 00 00 00 60 02 20 00 D9 70 00 00 02 04 05 B4 2D

Интересный момент в том, откуда берется SYN. SYN образуется от первоначального номера очереди
(ISN) — это 32-битный номер от 1 до 4294967295 (2 в 32-ой степени). ISN при перезагрузке системы равен 1, затем каждую секунду он увеличивается на 128000 (строго говоря изменение происходит каждые 4 микросекунды) + при каждом установленном соединении он увеличивается на 64000. Получается, что цикл уникальности ISN, при условии того, что никакие соединения не устанавливались, составляет примерно 4,55 часа. Поскольку ни один пакет так долго по сети не путешествует, мы можем полагать, что SYN будет абсолютно уникальным.

Получив наш пакет, удаленная система отвечает, что получила и готова установить соединение. Данные пакет выглядит так:

Host — SYN (758684758) и ACK (856780) — Client

Как видишь, удаленная система дает понять, что получила наш пакет. Для этого она посылает нам ACK с номером «наш SYN+1». В добавок к этому удаленная система посылает нам свой SYN (мы же тоже будем отвечать). А ответ наш будет такой:

Client — SYN (856780) и ACK (758684759) — Host

Думаю тебе уже должно быть все понятно. Если кто не понял, то пакет означает следующее: ваш пакет с SYN (758684758) получен, соединение установлено, наш SYN равен 856780.

Эту процедуру называют «трехкратным подтверждением» или «трехкратным рукопожатием». Первые два этапа необходимы для синхронизации SYN наших систем, а третий — подтверждение того, что синхронизация произошла.

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

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

Client — FIN(4894376) и ACK (1896955378) — Host

Host — ACK (4894377) — Client

Host — FIN (1896955378) и ACK (4894377) — Client

Client — ACK (1896955378) — Host

Думаю, ничего сложного здесь нет. Единственное, что стоит отметить — это флаг FIN, который означает желание завершить соединение.

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

Передача одного FIN Пакета = +1
Передача одного SYN Пакета = +1
Передача одного ACK Пакета = 0
Передача одного SYN/ACK Пакета = +1
Передача одного FIN/ACK Пакета = +1
Изменение за 1 секунду = +128,000
Установление одного соединения = +64,000

Возможно, кто-то спросит: «А что будет, если машин получит пакет с таким ACK, которого не было?» (SYN=ACK-1, а пакет с таким SYN мы не посылали). Получив ответ непонятно на что, мы в свою очередь ответим удаленной системе NACK-пакетом (означает «не знаю о чем ты», никакого соединения не устанавливается), но, надеюсь, более подробно мы поговорим с тобой об этом в следующий раз.

На транспортном уровне работают 2 протокола: TCP и UDP.

UDP (User Datagram Protocol) - протокол пользовательских дейтаграмм. Является ненадежным протоколом передачи данных, потому что он не устанавливает и не поддерживает соединения с удаленными узлами. То есть он просто передает данные на нижестоящий уровень и дальнейшая судьба этих данных его не интересует.
Кроме того, он не исправляет ошибки в принятых данных. Если будут обнаружены ошибки, то данные сегменты будут просто уничтожены и без запроса повторной передачи.

Для чего тогда такой протокол нужен?

Он очень полезен там, где передаваемые данные очень критичны к задержкам. Например, при передаче видео и голоса. Там недопустимы задержки, но можно пожертвовать несколькими пакетами в случае обнаружения ошибок - человеческие ухо и глаз не способны заметить потерю нескольких пакетов (если, конечно, число таких пакетов не слишком велико).
Однако для передачи чувствительных данных он совсем не годится, например, при передаче файлов - в данном случае задержки допустимы, но файл должен быть доставлен целостным.

Протокол добавляет следующий заголовок к передаваемым данным

Порт отправителя - идентифицирует приложение прикладного уровня, которое хочет общаться с таким же или другим приложением по сети. Например, Skype использует порт 80. Хотя может использовать и другие порты в зависимости от настроек. То есть, если Алиса пишет сообщение Кате по Skype, то компьютер Кати, приняв сообщение, сможет по номеру порта отправителя определить какое приложение отправило данное сообщение.

Порт получателя - идентифицирует приложение прикладного уровня, которое принимает сообщения от удаленных узлов. Иными словами, приложение “слушает” сеть на этом порту. Например, тот же Skype может принимать сообщение на порту 80. То есть, если Алиса отправит сообщение Кате на порт 80, то компьютер Кати его примет (при условии, что Skype будет в это время работать). Однако если, Алиса отправит на порт 100, а Катя слушает на порту 80, то компьютер Кати просто cбросит принятое сообщение.

А сколько всего может быть таких портов?

Всего насчитывается 65535 портов. Из них с 0 по 1023 зарезервированы под стандартные приложения, такие как FTP, SMTP, SNMP и другие. Остальные порты с 1024 и по 65535 могут быть использованы для любых других приложений. Эти порты еще называют динамическими, потому что у них нет жесткой привязки к определенному приложению и могут меняться от сеанса к сеансу.

Длина дейтаграммы - определяет длину всего сегмента, включая и сам заголовок.

Контрольная сумма - используется для проверки на наличие ошибок.

Как работает проверка?

Способ довольно примитивный. Передающий компьютер вычисляет контрольную сумму всего сегмента по специальному алгоритму и помещает это значение в поле Checksum. Затем принимающий компьютер вычисляет контрольную сумму данного сегмента и сравнивает с суммой в поле Checksum . Если значения совпадают, то сегмент принимается, в противном случае уничтожается.

Ничего, UDP не заботится о дальнейшей судьбе потерянных данных.

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

Вот как выглядит заголовок сегмента TCP

С некоторыми полями мы уже знакомы. Опишем новые поля.

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

Номер подтверждения - чтобы убедиться, что все переданные сегменты достигли адресата используются номера подтверждения. Например, узел А отправил сегмент с порядковым номером 45 узлу В. Когда узел В примет сегмент с номером 45, то отправит узлу А пустой сегмент с подтверждающим номером 46. Узел А будет знать, что все в порядке и отправит следующий сегмент под номером 46.

Флаги - специальные знаки-сигналы, указывающие на состояние сессии. Например, запрос на установление соединения или запрос на разрыв соединения.

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

А кто устанавливает размер окна?

Оба участника соединения. Например, принимающий узел сообщает передающему узлу размер окна исходя из того, как быстро принимающий узел справляется с поступающими данными. Если он не успевает обработать данные, то уменьшает размер и окна и передающий узел обязан уменьшить объем передаваемых данных.
Чтобы лучше понять назначение всех этих полей рассмотрим принцип работы протокола на примере установления соединения.

Установление соединения (Трехэтапное квитирование)

Процесс установления связи осуществляется в 3 этапа.

Этап 1

Когда сторона А хочет установить связь со стороной В, то сторона А отправляет запрос с установленным флагом SYN. После этого узел А переходит в состояние SYN SENT. Узел В остается в состоянии LISTEN:

Вот какие данные устанавливаются в заголовке TCP (для упрощения восприятия некоторые данные опущены):

Генерируется порядковый номер ISNa = 1 и формируется запрос на установление соединения. Если по истечении таймаута со стороны В не поступает никакого ответа, то узел А снова отправит запрос узлу В.

Этап 2

Когда сторона В принимает запрос SYN, то тоже генерируется порядковый номер ISNb = 200 (в реальности номер может принимать другие значения) для своего сегмента. Для формирования ответа стороне А, узел В устанавливает 2 флага: SYN и ACK. Причем в качестве номера подтверждения берется порядковый номер сегмента стороны А и увеличивается на 1, то есть 1 + 1. Это означает, что запрос успешно принят и ожидается следующий сегмент с номером 2. После того, как сегмент отправлен, узел В переходит в состояние SYN-RECEIVED, узел А остается в состоянии SYN SENT:

Вот как выглядит запрос в сетевом анализаторе:

Если по истечении таймаута от узла А не поступит подтверждения, то узел В снова отправит свой запрос.

Этап 3

После того, как узел А примет сразу 2 флага SYN и ACK, причем ACK будет на 1 больше ISN узла А, то сторона А сразу отправит второй сегмент узлу В. ISN будет увеличен на 1. Флаг будет установлен на ACK со значением ISNb + 1, то есть 200 + 1

Вот какие данные устанавливаются в заголовке TCP:

Вот как выглядит запрос в сетевом анализаторе:

После этого соединение считается успешно установленным, то есть помечается как ESTABLISHED.

Отказ в установлении соединения

Если сторона В по каким-то причинам не может установить соединение со стороной А, то генерируется ответ с флагом RST, которой информирует о прекращении попыток установления связи:

Вот какие данные устанавливаются в заголовке TCP:

Вот как выглядит запрос в сетевом анализаторе:

Завершение связи

Когда одна из сторон желает завершить сеанс связи, то формирует запрос FIN и переходит в состояние FIN_WAIT 1

Сторона В подтверждает запрос отправкой ACK и переходит в состояние CLOSE_WAIT. Сразу же вслед посылается запрос FIN. После этого узел В переходит в состояние LAST_ACK:

Сторона А подтверждает отправкой ACK и переходит в состояние CLOSED. Когда узел В примет ACK, то также перейдет в состояние CLOSED. На этом сеанс связи завершен:

Контроль над искаженными и потерянными данными

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

Для реализации данного механизма и используются порядковые и подтверждающие номера. Каждый сегмент нумеруется первым байтом полезной нагрузки. Затем приемник посылает подтверждающий сегмент, где указывает номер первого байта следующего сегмента. Например, первый сегмент имеет 100 байт полезной нагрузки (заголовок не учитывается), второй сегмент - 200 байт. Первому байту первого сегмента присваивается номер 1, у первого байта второго сегмента номер соответственно равен 101 (100 + 1) и так далее

Теперь посмотрим как будет проходить передача сегментов

Вот как это выглядит в сетевом анализаторе:

Если сложить ISN = 2155299270 первого сегмента с длиной данных Len = 711, то получится ISN = 2155299981 второго сегмента. Таким способом приемник формирует ACK SN для 3-го сегмента.

С этим разобрались. Но что произойдет, если данные потеряны или искажены в процессе передачи?

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

Теперь посмотрим, что произойдет, если один сегмент не дойдет до получателя. В данном случае приемник вышлет подтверждение только за принятые сегменты. А о 3-ем сегменте он вообще ничего не знает, поэтому ничего не отправит.
Передатчик будет ждать определенное время и не дождавшись подтверждения за 3-й сегмент отправит его снова

Вот так и достигается контроль над ошибками данных.

Контроль за передачей данными (Метод скользящего окна)

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

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

Буферы необходимы для постановки в очередь принятые и передаваемые данные, так как производительность приёмной и передающей систем, а также самой сети разные, то велика вероятность, что система не сможет на “лету” обработать большой объем данных.

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

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

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

И как работает данный механизм?

В TCP заголовке имеется поле “Размер окна (Window size )”, которое указывает на то, сколько байт приемник способен принять. Иными словами это говорит о доступности буфера и наличии в нем свободного пространства для поступающих данных.
После установления соединения приемник сообщает передатчику размер окна. Например, приемник сообщил, что окно равно 5 байтам. Передатчик передаст 5 байт информации и ждет подтверждения:

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

Окно в передающем буфере сместится на 5 байт и новая порция данных будет передана приемнику:

Теперь посмотрим, что произойдет, если приемник не успевает обработать все полученные данные и в его буфере свободное место только для 2-х байт:

Передатчик готов передать следующие 5 байт информации, так как получил подтверждение от приемника. Однако приемник также уведомил передатчик, что в приемном буфере свободно только для 2-х байт, то есть сообщает следующее: “Снижай скорость передачи. Готов принять пока 2 байта.”

И передатчик уменьшает окно и передает только 2 байта

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

Что происходит, когда в буфере приемника совсем нет места?

Тогда приемник установит размер окна равным 0. Это означает прекратить передачу данных.

Как же передатчик узнает, что буфер приемника снова готов к работе?

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

Итак подведем краткие итоги.
В таблице представлены сравнение протоколов UDP и TCP, а также функции, возложенные на транспортный уровень

Функции	TCP	UDP
Управление потоком	Да	Нет
Контроль над ошибками	Да	Нет
Скорость	Медленный	Быстрый
Установление соединения	Да	Нет
Использование в приложениях чувствительных к задержкам данных	Нет (иногда допустимо)	Да
Использование в приложениях менее чувствительных к задержкам данных	Да	Да (но не всегда)
Регулирование скорости передачи данных	Да	Нет
Запрос на повторную передачу потерянного или искаженного сегмента	Да	Нет
Многоканальный	Да	Да Назад

Транспортный уровень

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

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

Transmission Control Protocol

Transmission Control Protocol (TCP) (протокол управления передачей) - является обязательным протоколом стандарт TCP/IP , определенный в стандарте RFC 793, "Transmission Control Protocol (TCP)".

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

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

TCP обеспечивает свою надежность благодаря следующему:

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

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

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

Номер подтверждения - если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз. Помечает этот сегмент как подтверждение получения.
Длина заголовка - задается словами по 32бита.
Размер окна - количество байт, которые готов принять получатель без подтверждения.
Контрольная сумма - включает псевдо заголовок, заголовок и данные.
Указатель срочности - указывает последний байт срочных данных, на которые надо немедленно реагировать.
URG - флаг срочности, включает поле "Указатель срочности", если =0 то поле игнорируется.
ACK - флаг подтверждение, включает поле "Номер подтверждения, если =0 то поле игнорируется.
PSH - флаг требует выполнения операции push, модуль TCP должен срочно передать пакет программе.
RST - флаг прерывания соединения, используется для отказа в соединении
SYN - флаг синхронизация порядковых номеров, используется при установлении соединения.
FIN - флаг окончание передачи со стороны отправителя

Рассмотрим структуру заголовка TCP с помощью сетевого анализатора Wireshark:

TCP порты

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

Номер порта - это условное 16-битное число от 1 до 65535, указывающее, какой программе предназначается пакет.

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

Каждый отдельный порт сервера TCP может предложить общий доступ к нескольким соединениям, потому что все TCP соединения идентифицируются двумя значениями: IP-адресом и TCP портом (сокет).

Все номера портов TCP, которые меньше чем 1024 - зарезервированы и зарегистрированы в Internet Assigned Numbers Authority (IANA).

Номера портов UDP и TCP не пересекаются.

TCP программы используют зарезервированные или хорошо известные номера портов, как показано на следующем рисунке.

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

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

Перед началом передачи каких-либо данных, согласно протоколу TCP, стороны должны установить соединение. Соединение устанавливается в три этапа (процесс «трёхкратного рукопожатия» TCP).

Запрашивающая сторона (которая, как правило, называется клиент) отправляет SYN сегмент, указывая номер порта сервера, к которому клиент хочет подсоединиться, и исходный номер последовательности клиента (ISN).
Сервер отвечает своим сегментом SYN, содержащим исходный номер последовательности сервера. Сервер также подтверждает приход SYN клиента с использованием ACK (ISN + 1). На SYN используется один номер последовательности.
Клиент должен подтвердить приход SYN от сервера своим сегментов SYN, содержащий исходный номер последовательности клиента (ISN+1) и с использованием ACK (ISN+1). Бит SYN установлен в 0, так как соединение установлено.

После установления соединения TCP, эти два хоста могут передавать данные друг другу, так как TCP-соединение является полнодуплексным, они могут передавать данные одновременно.

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

Существуют два способа присвоения порта приложению:

· централизованный (присвоенные или назначенные номера от 0 до 1023), использующий стандартные номера, присвоенные общедоступным службам (приложениям), например: FTP – 21, telnet – 23, SMTP – 25, DNS – 53, HTTP – 80.

· локальный (динамические номера от 1024 до 65535), предоставляющий произвольный номер из списка свободных номеров при поступлении запроса от приложения пользователя.

Динамические номера портов приложений являются уникальными в пределах каждого компьютера, но могут совпадать с номерами портов в других компьютерах. Различие между ними определяется только различием интерфейсов каждого из компьютеров, задаваемых IP-адресами.

Таким образом, пара «IP-адрес; номер порта », называемая сокетом (socket), однозначно определяет прикладной процесс в сети.

Номера UDP- и TCP-портов в пределах одного и того же компьютера могут совпадать, хотя и идентифицируют разные приложения. Поэтому при записи номера порта обязательно указывается тип протокола транспортного уровня, например 2345/TCP и 2345/UDP. В некоторых случаях, когда приложение может обращаться по выбору к протоколу UDP или TCP, ему могут быть назначены одинаковые номера UDP- и TCP-портов, например DNS-приложению назначен номер 53 – 53/UDP и 53/TCP.

Транспортный протокол UDP

UDP – транспортный протокол, обеспечивающий передачу данных в виде дейтаграмм между любой парой прикладных процессов , выполняющихся в сети, без установления соединения . Сегменты состоят из 8-байтового заголовка, за которым следует поле данных. Заголовок UDP-сегмента показан на рис.4.61.

Наиболее широко UDP используется при выполнении клиент-серверных приложений (типа запрос-ответ).

При этом UDP не выполняет:

· контроль потока,

· контроль ошибок,

· повторной передачи после получения испорченного сегмента.

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

В некоторых случаях на одном конечном узле может выполняться несколько копий одного и того же приложения. Возникает вопрос: каким образом различаются эти приложения?

Для этого рассмотрим на простом примере процесс формирования запроса и процедуру обращения DNS-клиента к DNS-серверу, когда на одном компьютере запущены два DNS-сервера, причём оба используют для передачи своих данных транспортный протокол UDP (рис.4.62). Для того чтобы различать DNS-серверы, им присваиваются разные IP-адреса – IP1 и IP2, которые вместе с номером порта образуют два разных сокета: «UDP-порт 53, IP1» и «UDP-порт 53, IP2».

Рис.4.62,а) иллюстрирует процесс формирования DNS-клиентом запроса к DNS-серверу.

DNS-запрос транспортном уровне стека протоколов TCP/IP передаётся протоколу UDP, который вкладывает этот запрос в UDP-дейтаграмму и указывает в заголовке порт назначения 53/UDP. Затем UDP-дейтаграмма передаётся на межсетевой уровень, где она вкладывается в IP-пакет, заголовок которого содержит «IP-адрес: IP2». IP-пакет, в свою очередь, передаётся на уровень «межсетевой интерфейс», где он помещается в кадр канального уровня с соответствующим заголовком канального уровня (ЗКУ). Этот кадр передаётся по сети к компьютеру, содержащему два DNS-сервера (рис.4.62,б).

В этом компьютере протокол канального уровня (ПКУ) снимает заголовок ЗКУ и передаёт содержимое кадра на межсетевой уровень протоколу IP, который, в свою очередь, извлекает содержимое (UDP-дейтаграмму) из IP-пакета. Дальнейшие манипуляции с передаваемыми данными отличаются от принципов, заложенных в многоуровневую модель иерархии протоколов. Вместо того чтобы просто передать UDP-дейтаграмму, находящуюся в поле данных IP-пакета, транспортному уровню, IP-протокол присоединяет к UDP-дейтаграмме так называемый псевдозаголовк , содержащий среди прочего IP-адреса отправителя и получателя. Таким образом, протокол UDP, имея IP-адрес и порт назначения, однозначно определяет, что содержимое поля данных (то есть DNS-запрос), должно быть передано приложению «DNS-сервер 2».

Транспортный протокол TCP

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

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

Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байтов и заносится в буфер. Для передачи на сетевой уровень из буфера вырезается сегмент , не превосходящий 64 Кбайт (максимального размера IP-пакета). На практике обычно длина сегмента ограничивается значением 1460 байтами, что позволяет поместить его в кадр Ethernet с заголовками TCP и IP.

Соединение TCP ориентировано на полнодуплексную передачу .

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

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

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

Во-вторых, сегменты могут прибывать в узел назначения в произвольном порядке, что может привести к ситуации, при которой байты с 2345 по 3456 уже прибыли, но подтверждение для них не может быть выслано, так как байты с 1234 по 2344 еще не получены.

В-третьих, сегменты могут задержаться в сети так долго, что у отправителя истечёт интервал ожидания, и он передаст их снова. Переданный повторно сегмент может пройти по другому маршруту и может быть иначе фрагментирован, или же сегмент может по дороге случайно попасть в перегруженную сеть. В результате для восстановления исходного сегмента потребуется достаточно сложная обработка На рис.4.63 представлен формат заголовка TCP-сегмента. Первые 20-байт заголовка имеют строго фиксированный формат, за которым могут находиться дополнительные поля. После дополнительных полей заголовка размещается поле данных, содержащее не более 65 495 байт, которое вместе с TCP- и IP-заголовками размером по 20 байт даст максимально допустимый размер IP-пакета в 65 535 байт.

Не вдаваясь в детали, рассмотрим кратко назначение фиксированных полей заголовка ТСР-сегмента.

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

Поле «Порядковый номер» (4 байта) содержит номер первого байта данных в сегменте, который определяет смещение сегмента относительно потока передаваемых данных

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

Поле «Длина TCP-заголовка» (4 бита) задаёт длину заголовка ТСР-сегмента, измеренную в 32-битовых словах.

Поле «Резерв» длиной 6 бит зарезервировано на будущее.

Однобитовые флаги несут служебную информацию о типе сегмента и интерпретируются следующим образом:

· URG=1 указывает на наличие срочных данных , что означает использование поля «Указатель на срочные данные» ;

· ACK=1 означает, что сегмент является квитанцией на принятый сегмент и поле «Номер подтверждения» содержит осмысленные данные. В противном случае данный сегмент не содержит подтверждения и поле «Номер подтверждения» просто игнорируется.

· PSH=1 (PUSH-флаг) означает запрос на отправку данных без ожидания заполнения буфера;

· RST=1 используется для сброса состояния соединения при обнаружении проблем, а также для отказа от неверного сегмента или от попытки создать соединение;

· SYN=1 используется для установки соединения , при этом если АСК=0, то это означает, что поле подтверждения не используется;

· FIN=1 используется для разрыва соединения .

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

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

Алгоритм вычисления контрольной суммы выглядит следующим образом.

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

Получатель сегмента аналогичным образом подсчитывает контрольную сумму для всего сегмента, включая поле «Контрольная сумма». Очевидно, что полученный таким образом результат должен быть равен 0. Отметим, что дополнительный нулевой байт Поле «Указатель на срочные данные» (2 байта) содержит смещение в байтах от текущего порядкового номера байта до места расположения срочных данных, которые необходимо срочно принять, несмотря на переполнение буфера. Таким образом, в протоколе TCP реализуются прерывающие сообщения. Содержимым срочных данных занимается прикладной уровень. Протокол TCP лишь обеспечивает их доставку и не интересуется причиной прерывания.

Поле «Параметры» имеет переменную длину и может отсутствовать.

Примерами приложений, использующих протокол TCP для передачи данных, являются FTP, TFTP, DNS, POP3, IMAP, TELNET.