Функционирование протокола tcp. Что такое протокол TCP-IP. Использование протокола UDP

Многим знакома аббревиатура 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-пакетом (означает «не знаю о чем ты», никакого соединения не устанавливается), но, надеюсь, более подробно мы поговорим с тобой об этом в следующий раз.

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

Что означают TCP и UDP

TCP – транспортный протокол передачи данных в сетях TCP/IP, предварительно устанавливающий соединение с сетью.

UDP – транспортный протокол, передающий сообщения-датаграммы без необходимости установки соединения в IP-сети.

Напоминаю, что оба протокола работают на транспортном уровне модели OSI или TCP/IP, и понимание того чем они отличаются очень важно.

Разница между протоколами TCP и UDP

Разница между протоколами TCP и UDP – в так называемой “гарантии доставки”. TCP требует отклика от клиента, которому доставлен пакет данных, подтверждения доставки, и для этого ему необходимо установленное заранее соединение. Также протокол TCP считается надежным, тогда как UDP получил даже именование “протокол ненадежных датаграмм. TCP исключает потери данных, дублирование и перемешивание пакетов, задержки. UDP все это допускает, и соединение для работы ему не требуется. Процессы, которым данные передаются по UDP, должны обходиться полученным, даже и с потерями. TCP контролирует загруженность соединения, UDP не контролирует ничего, кроме целостности полученных датаграмм.

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

Давайте рассмотрим основные отличия tcp от udp.

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

Примерами UDP приложений, например можно привести, передачу DNS зон, в Active Directory, там не требуется надежность. Очень часто такие вопросы любят спрашивать на собеседованиях, так, что очень важно знать tcp и udp отличия.

Заголовки TCP и UDP

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

Заголовок UDP

16 битный порт источника > Указание порта источника для UDP необязательно. Если это поле используется, получатель может отправить ответ этому порту.
16 битный порт назначения > Номер порта назначения
16 битная длина UDP > Длина сообщения, включая заголовок и данные.
16 битная контрольная сумма > Контрольная сумма заголовка и данных для проверки

Заголовок TCP

16 битный порт источника > Номер порта источника
16 битный порт назначения > Номер порта назначения
32 битный последовательный номер > Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
32 битный номер подтверждения > Если установлен бит АСК поля "Управление", в данном поле содержит следующий ожидаемый последовательный номер.
4 бита длина заголовка > Информация о начале пакета данных.
резерв > Резервируются для будущего использования.
16 битная контрольная сумма > Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
16 битный указатель срочности > В этом поле целевое устройство получает информацию о срочности данных.
Параметры > Необязательные значения, которые указываются при необходимости.

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

При размере окна 3, отправитель отправляет уже по 3 кадра, и ждет от 4, который подразумевает, что все три кадра у него есть, +1.

Надеюсь у вас теперь есть представления об отличиях tcp udp протоколов.

Транспортные протоколы 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.

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

Задача транспортного уровня - это передача данных между различными приложениями, выполняемых на всех узлах сети. После того, как пакет доставляется с помощью 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 (Transmission Control Protocol) – протокол управления передачей. Для обеспечения надежной доставки данных на уровне транспортного протокола в приложениях используется протокол TCP, проверяющий факт доставки данных по сети в нужном порядке. TCP – надежный, потоковый протокол, требующий создания логический соединений. Надежность TCP обеспечивает механизм подтверждения приема с повторной передачей. При использовании данного механизма повторная отправка данных будет происходить до тех пор, пока не получит от системы-адресата подтверждение, что данные были успешно переданы.

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

Рассмотрим процесс так называемого “рукопожатия” – установления TCP-соединения. Со стороны клиента отправляется пакет с выставленным флагом SYN – это означает инициализацию TCP-сессии. На данном этапе хостом будет сгенерирован порт источника и порт назначения (порт источника выбирается случайно из диапазона 1024 – 655535). Порт назначения зависит от конкретной службы (http – 80, ftp – 21, pop3 – 110).

При получении пакета сервер, если он не против соединения, посылает ответный пакет с битами SYN, ACK. ACK – означает бит подтверждения. Также в TCP-заголовке сервер генерирует произвольное число Sequence number, а к числу Acknowledgment number прибавляет единицу.

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

В заголовке протокола TCP содержится поле, которое называется Sequence Number, в которое заносится номер некоторой последовательности. Так же есть поле Acknowledgment Number, которое говорит о подтверждении пакета с этим номером. Числа Sequence Number, Acknowledgment Number применяются для сохранения порядка следования данных. Но если говорить более конкретно, то Sequence Number является точкой отчета для системы нумерации байтов. Из соображений безопасности ISN следует быть случайным числом. Acknowledgment Number служит для подтверждения приема и управления потоком. Подтверждение сообщает источнику, какой объем данных получен и сколько еще данных адресат способен принять. Номер подтверждения – это порядковый номер следующего байта, ожидаемый адресатом.

Поле Windows size (размер окна) – содержит количество байт, которое способен принять адресат. Окно является указанием источнику, что можно продолжать передачу сегментов, если общий объем передаваемых байт меньше байтового окна адресата. Адресат управляет потоком байтов источника, изменяя размер окна. Нулевое окно предписывает отправителю прекратить передачу, пока не будет получено ненулевое значение окна.

Поля Source port, Destination port – порт источника, порт назначения. UGR,

Поля UGR, ACK, PSH, RST, SYN. FIN – управляющие биты:

UGR – указатель срочности, показывает приоритет TCP-пакетов
ACK – подтверждение, помечает этот пакет как подтверждение получения
PSH – выталкивание, выталкивает поставленные в очередь данные из буферов
RST – сброс, сбрасывает соединение TCP по завершению или после разрыва
SYN – синхронизация, синхронизирует соединение
FIN – завершение, завершает передачу данных

На рисунке ниже показан поток данных TCP с нулевым значением исходного порядкового номера. Адресат получил и подтвердил получение 2000 байт, поэтому текущий номер подтверждения ACK = 2001. Кроме того, адресат обладает возможностью принять еще 6000 байт, а поэтому предъявляет окно со значением 6000. Источник отправляет сегмент размером 2000 байт с порядковым номером SN = 4001. Для байтов 2001 и последующих еще не были получены подтверждения, однако источник продолжает передачу данных, пока не исчерпаны ресурсы окна. Если на момент заполнения окна источником для уже отправленных данных не получены подтверждения, по истечению определенного интервала времени источник повторно передает данные, начиная с первого неподтвержденного байта.

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

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

Подписывайтесь на нашу