Модель OSI является эталонной моделью взаимодействия сетевых устройств. В реальности в сети Интернет для этого взаимодействия применяется стек протоколов TCP/IP.  Модель TCP/IP состоит из четырех уровней, которые соответствуют определенным уровням модели OSI. Соответствие модели TCP/IP и модели OSI представлено на рис. 1.

Уровень приложений (Application) модели TCP/IP объединяет функции сеансового, представления и прикладного уровня модели OSI. Этот уровень задействует различные протоколы, среди которых можно выделить HTTP, FTP, Telnet, NTP и DHCP.

Транспортный уровень модели TCP/IP соответствует транспортному уровню модели OSI. На нём используются такие протоколы как TCP и UDP.

Сетевой уровень модели TCP/IP соответствует сетевому уровню модели OSI. На нём используются такие протоколы как IP, ARP, ICMP, IGMP и другие.

Уровень доступа к среде (Network Interface) модели TCP/IP соответствует канальному и физическому уровням модели OSI. На нём осуществляется общение между устройствами сетей Ethernet, ATM, WLAN и других.

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

Заголовок сегмента содержит следующие поля:

·Source port (Порт Отправителя) – 16-ти битное поле, указывающее на номер порта приложения, с которого отправлены данные и на которое Отправителю будут переданы ответные данные от Получателя.

· Destination port (Порт Получателя) – 16-ти битное поле, указывающее на номер порта целевого  приложения, на которое передаются данные Отправителя.

· Sequence number – (Номер сегмента) – 32-битное поле, содержащее номер сегмента в последовательности передаваемых сегментов, позволяет контролировать порядок сообщений, а также позволяет принимающей системе обрабатывать пакеты в правильной последовательности, как они были сформированы при отправлении, а не в том порядке, как они были получены.

·Acknowledgment (Подтверждение) - 32-битное поле, содержащее номер сегмента в последовательности получаемых сегментов. Каждая из сторон (Отправитель и Получатель) подсчитывает свой Sequence number для переданных данных и отдельно Acknowledgement number для полученных данных. Sequence number каждой из сторон соответствует Acknowledgement number другой стороны.

·  Header length (Длина заголовка) – 4-х битное поле, определяющее длину заголовка в 32-битных словах, которая может быть разной из-за наличия в нём необязательного поля опций, но в большинстве случаев эта длина равна 20 байтам.

· Reserved (Зарезервировано) – 6-битное  резервное поле.

· Flags (Флаги) – 6-битное поле, содержащее следующие флаги:

• URG – установленный флаг в этом поле свидетельствует о том, что Получателю передаются важные данные, которые последний принимает на отдельном канале;

•  ACK – (1 бит). Устанавливается, когда пакет содержит значение номера подтверждения в поле подтверждения. Все пакеты после стартового пакета SYN будут иметь установленный флаг ACK;

• PSH (1 бит). Делает этот пакет пакетом PUSH (проталкивания). При нормальном потоке передачи данных система получателя не будет подтверждать получение каждого пакета сразу же после его получения. Вместо этого система получателя в течении некоторого времени будет собирать и хранить полученные данные в буфере, пока не передаст их приложению пользователя. Пакет PUSH инструктирует систему получателя немедленно передать все полученные ранее данные из буфера в приложение пользователя и сразу же отправить сообщение с подтверждением;

• RST - установленный флаг в этом поле предлагает оборвать соединение и очистить буфер;

• SYN - установленный флаг в этом поле включает синхронизацию номеров последовательности сегментов данных;

• FIN - установленный флаг в этом поле свидетельствует о завершении соединения.

• · Siding-window size- 16-битное поле, которое определяет, сколько байтов данных может быть передано отправителем до получения подтверждения от получателя. Подтверждение означает, что данные были успешно получены или что у получателя есть буфер размером «размер окна» байт для приёма данных;

  · Checksum – 16-ти битное поле контрольной суммы заголовка и данных, рассчитываемая как 16-битное дополнение к сумме всех 16‑битных слов заголовка и данных (при расчёте значение данного поля принимается равным 0);

  · Urgent Pointer (Указатель важности) - поле указывающее порядковый номер октета, которым заканчиваются важные (urgent) данные, содержащее 16-битовое значение положительного смещения от порядкового номера в данном сегменте и принимаемое во внимание только при установленном флаге URG;

  · Options (Опции) – это поле может использоваться в некоторых случаях для расширения протокола, иногда используется для тестирования;

  ·Padding (Заполнитель) – фиктивное поле переменной длины, используемое для доведения размера заголовка до целого числа 32-битовых слов.

  1.1    Работа протокола ТСР

  Протокол ТСР рассчитан на гарантированную передачу данных в соединении точка-точка и не работает с многоадресной рассылкой данных. Работа протокола будет рассмотрена далее в самом упрощённом виде. В работе протокола можно выделить три стадии:

· установление соединения;

·  передача данных;

·  разрыв соединения после завершения передачи данных.

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

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

(Пакет №1). Клиент отправляет пакет с установленным флагом SYN и случайным числом («R1»), включенным в поле порядкового номера (sequence number).

(Пакет №2). При получении пакета №1 сервер в ответ отправляет пакет с установленным флагом SYN, а также с установленным флагом ACK. Поле порядкового номера будет содержать новое случайное число («R2»), а поле номера подтверждения будет содержать значение порядкового номера клиента, увеличенного на единицу (то есть «R1 + 1»). Таким образом, он будет соответствовать следующему порядковому номеру, который сервер ожидает получить от клиента.

(Пакет №3). В ответ на пакет SYN от сервера (пакет №2) клиент отправляет пакет с установленным флагом ACK и полем номера подтверждения с числом «R2 + 1». По аналогии, это число будет соответствовать следующему порядковому номеру, который клиент ожидает получить от сервера.

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

При передаче данных ТСР использует так называемый механизм квитирования с плавающим окном. Размером окна W (поле Window size в заголовке сегмента) является разрешённое количество непрерывно передаваемых сегментов в максимально возможном для Отправителя темпе. Подтверждение приёма первого сегмента может поступить Отправителю после передачи W сегментов данных.

Получатель посылает Отправителю сегмент, в поле Sequence number которого помещает число на единицу большее максимального номера байта в полученном сегменте. Подтверждение высылается только в случае правильного приёма данных. Отсутствие подтверждения означает либо потерю сегмента, либо искажение данных, либо потерю квитанции. Если Отправитель получил подтверждение получения сегмента с байтом N, то он может отправить ещё некоторое количество сегментов до получения приёма сегмента c байтом N+W. Если следующее подтверждение от Получателя за это время не получено, то передача данных на время приостанавливается.

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

В протоколе ТСР предусмотрена реакция на перегрузку сети. Чем больше размер окна передаваемых данных Отправителя, тем большее количество неподтверждённых данных можно отправить в сеть. Если в сети есть проблемы с нагрузкой, то могут возникать очереди в приёмных буферах промежуточных маршрутизаторов и/или компьютеров. Если приёмный буфер промежуточного или конечного узла переполнен, то протокол ТСР этого узла посылает Отправителю в подтверждении новый уменьшенный размер окна. Если он полностью отказывается от дальнейшего приёма, то указывается нулевой размер окна.

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

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

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

Завершение соединения так же, как и его установление, проходит в три этапа:

· Отправитель в сегменте с последними передаваемыми данными устанавливает флаг в бите FIN;

· Получатель высылает Отправителю сегмент с установленными флагами ACK и FIN;

· Отправитель закрывает соединение и отправляет Получателю подтверждение того, что соединение закрыто.

1.1.4   Использование псевдозаголовка

В заголовке ТСР-сегмента отсутствуют данные об адресах Отправителя и получателя. Из-за этого даже при совпадении порта нет никакой гарантии, что сообщение пришло по нужному адресу. Этот момент принципиален, так как основным назначением протокола ТСР является гарантированная доставка сообщений адресату. Чтобы не нарушать принцип инкапсуляции-декапсуляции данных в модели OSI, к заголовку ТСР-сегмента был добавлен псевдозаголовок. Он не является частью ТСР‑сегмента и используется для расчёта контрольной суммы перед отправлением сегмента и при его получении. Формат псевдозаголовка для Ipv4 представлен на рис. 3.

Поле «Протокол» содержит идентификатор протокола ТСР – 6 (00000110 – в двоичном коде).

Поле «Длина ТСР-сегмента» содержит длину ТСР-сегмента в байтах без учёта псевдозаголовка.

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

1.2    Протокол UDP

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

Заголовок протокола UDP имеет минимальную длину — 8 байт. Хотя этот протокол не обеспечивает доставку сообщений до адресатов, считается, что вероятность потери пакетов данных невелика.

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

UDP не выполняет разделение или объединение сообщений прикладных процессов. Протокол UDP чаще всего используется для ответов серверов на DNS‑запросы большого количества клиентов, трансляции потоковых мультимедийных приложений (IPTV, Voice over IP) и многих онлайн игр.

1.3    Сравнение протоколов ТСР и UDP

Основные отличительные особенности этих протоколов приведены на рис. 5.

Оба протокола являются протоколами 4 уровня модели OSI и не поддерживают многоадресную передачу данных. Отличаются же эти протоколы следующим:

· TCP является протоколом, устанавливающим соединение между Отправителем и Получателем, а UDP не требует установления такого соединения.

·ТСР не поддерживает широковещательный трафик, а UDP – поддерживает.

· TСP контролирует ошибки в сообщениях, а UDP – нет.

· ТСР контролирует поток данных, а UDP – нет.

·ТСР поддерживает полнодуплексную связь, для UDP такой тип связи не определён.

· сообщением ТСР является сегмент данных, а UDP – дейтаграмма.

Можно привести ещё несколько отличий:

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

• Упорядоченность. TCP гарантированно передаёт пакеты данных именно в той последовательности, которая была задана изначально. В UDP такие возможности не реализованы.

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

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