Транспортный уровень
Протоколы транспортного уровня могут решать проблему негарантированной доставки сообщений («дошло ли сообщение до адресата?»), а также гарантировать правильную последовательность прихода данных. В стеке TCP/IP транспортные протоколы определяют, для какого именно приложения предназначены эти данные.
Протоколы автоматической маршрутизации, логически представленные на этом уровне (поскольку работают поверх IP), на самом деле являются частью протоколов сетевого уровня.
Протокол TCP обеспечивает надежную доставку потоков и сервис поддержки виртуальных соединений за счет использования подтверждений и повторной передачи пакетов при возникновении необходимости.
Структура заголовка TCP показана на рисунке.
4 10 16 32
Порт отправителя |
Порт получателя |
|||||||||
Порядковый номер |
||||||||||
Номер подтверждения |
||||||||||
Смещ. |
Резерв |
U |
A |
P |
R |
S |
F |
Окно |
||
Контрольная сумма |
Указатель важности |
|||||||||
Опции и заполнение |
||||||||||
Данные |
||||||||||
Структура заголовка TCP
Порт отправителя – Номер порта-отправителя.
Порт получателя – Номер порта-получателя.
Порядковый номер – Порядковый номер первого октета в данном сегменте (за исключением присутствия SYN). При наличии SYN поле порядкового номера содержит изначальный порядковый номер (Initial Sequence Number - ISN) и первый октет имеет номер ISN+1.
Номер подтверждения – Если бит управления ACK установлен (1), это поле содержит значение следующего порядкового номера, который отправитель сегмента ожидает получить. После организации соединения значение этого поля устанавливается во всех случаях.
Смещение данных – 4-битовое поле, указывающее число 32-битовых слов в заголовке TCP. После заголовка размещаются данные, поэтому поле указывает на начало данных в пакете. Заголовок пакетов TCP всегда имеет размер, кратный 32 битам.
Резерв – Зарезервированное поле размером 6 битов.
Биты управления – 6 битовое поле, содержащее флаги управления:
U (URG) - значимое поле указателя важности;
A (ACK) - значимое поле подтверждения;
P (PSH) - функция push;
R (RST) - сброс соединения;
S (SYN) - синхронизация порядковых номеров;
F (FIN) - нет данных от отправителя.
Окно – 16-битовое поле, содержащее число октетов данных, которые отправитель данного сегмента будет воспринимать, начиная с октета, указанного в поле подтверждения.
Контрольная сумма – 16-битовое значение контрольной суммы, вычисляемой для 16-битовых слов заголовка и текста. Если сегмент содержит нечетное число октетов в заголовке /или тексте, последние октеты дополняются справа 8 нулями для выравнивания по 16-битовой границе. Биты заполнения (0) не передаются в сегменте и служат только для расчета контрольной суммы. При расчете контрольной суммы значение самого поля контрольной суммы принимается равным 0.
Указатель важности – 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, с которого начинаются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом U.
Опции – Опции передаются в конце заголовка TCP и всегда имеют размер, кратный 8 битам. При расчете контрольной суммы пакета значения опций принимаются во внимание. Опции могут начинаться на любой границе октета.
Существуют два формата опций:
• Однооктетные опции
• Многооктетные опции, содержащие поля типа опции (1 октет), ее размера (1 октет) и собственно опций.
Поле длины опций учитывает все субполя опций - тип, размер и сами опции.
Список опций может закончиться раньше, нежели указывает поле смещения данный, поэтому значения битов после поля End-of-Option должны быть заполнены нулями.
Протокол TCP Должен реализовать все опции.
TCP (IP идентификатор 6) — «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных. TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP.
Протокол UDP (User Datagram Protocol – протокол пользовательских дейтаграмм) обеспечивает простой сервис передачи сообщений без гарантии доставки для ориентированных на транзакции услуг. Каждый заголовок UDP содержит идентификаторы портов отправителя и получателя, которые позволяют протоколам вышележащих уровней связать указанные приложения и услуги с хостами.
Структура заголовков UDP показана на рисунке.
16 32
Порт-отправитель |
Порт-получатель |
Размер |
Контрольная сумма |
Данные |
|
Структура заголовков UDP
Порт-отправитель – Необязательное поле, указывающее порт процесса-отправителя. По номеру указанного в этом поле порта адресуются ответы, если явно не указан другой порт. При отсутствии номера порта-отправителя это поле заполняется нулями.
Порт-получатель – Номер порта-получателя, рассматриваемый в контексте указанного IP-адреса получателя.
Размер – Размер данной пользовательской дейтаграммы в октетах с учетом заголовка и данных. Минимальная длина дейтаграммы составляет 8 октетов.
Контрольная сумма – 16-битовое значение контрольной суммы псевдозаголовка, содержащего информацию из заголовков IP и UDP, а также данных с дополнением (при необходимости) нулей для выравнивания по двухоктетной границе.
Данные – Поле данных UDP.
UDP (IP идентификатор 17) протокол передачи датаграмм без установления соединения. Также его называют протоколом «ненадёжной» передачи, в смысле невозможности удостовериться в доставке сообщения адресату, а также возможного перемешивания пакетов.
UDP обычно используется в таких приложениях, как потоковое видео и компьютерные игры, где допускается потеря пакетов, а повторный запрос затруднён или не оправдан, либо в приложениях вида запрос-ответ (например, запросы к DNS), где создание соединения занимает больше ресурсов, чем повторная отправка.
И TCP, и UDP используют для определения протокола верхнего уровня число, называемое портом.
Источники: http://www.protocols.ru/files/Protocols/TCPIP.pdf
http://ru.wikipedia.org/wiki/TCP/IP
SCTP (англ. Stream Control Transmission Protocol — «протокол передачи с управлением потоком»), протокол транспортного уровня в компьютерных сетях, появившийся в 2000 году в IETF.
Как и любой другой протокол передачи данных транспортного уровня, SCTP работает аналогично TCP или UDP. Будучи более новым протоколом, SCTP имеет несколько нововведений, таких как многопоточность, защита от SYN-flood атак, синхронное соединение между двумя хостами по двум и более независимым физическим каналам (multi-homing).
Создание нового подключения в протоколах TCP и SCTP происходит при помощи механизма подтверждения (квитирования) пакетов. В протоколе TCP данная процедура получила название трехэтапное квитирование (three-way handshake). Клиент посылает пакет SYN (сокр. Synchronize). Сервер отвечает пакетом SYN-ACK (Synchronize-Acknowledge). Клиент подтверждает прием пакета SYN-ACK пакетом ACK. На этом процедура установления соединения завершается.
Протокол TCP имеет потенциальную уязвимость, обусловленную тем, что нарушитель, установив фальшивый IP-адрес отправителя, может послать серверу множество пакетов SYN. При получении пакета SYN сервер выделяет часть своих ресурсов для установления нового соединения. Обработка множества пакетов SYN рано или поздно, затребует все ресурсы сервера и сделает невозможным обработку новых запросов. Такой вид атак называется «отказ в обслуживании» (Denial of Service (DoS)).
Протокол SCTP защищен от подобных атак с помощью механизма четырехэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения посылкой пакета INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, посланный сервером. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправлением клиенту пакета COOKIE-ACK.
SCTP пакеты имеют более простую структуру, чем пакеты TCP. Каждый пакет состоит из двух основных разделов:
Общий заголовок, который занимает первые 12 байт .
Блоки данных, которые занимают оставшуюся часть пакета.
Достоинства использования SCTP включают в себя:
Использование множественных интерфейсов (англ Multihoming) Допустим, у нас есть два хоста. И хотя бы один из них имеет несколько сетевых интерфейсов, и соответственно несколько IP-адресов. В TCP, понятие «соединение» означает обмен данными между двумя точками, в то время, как в SCTP имеет место концепция «ассоциации» (англ. association), обозначащая всё происходящее между двумя хостами.
Многопоточность Данные приходят в точку по независимым потокам. Это позволяет устранить феномен en:Head-of-line blocking, которым так страдает TCP
Поиск пути с мониторингом Протоколом выбирается первичный маршрут передачи данных, а также производится проверка и мониторинг связности пути.
Механизмы валидации и проверки подлинности Защита адресата от flood-атак (технология 4-way handshake), и уведомление о потерянных пакетах и нарушенных цепочках.
Улучшенная система контроля ошибок, подходящая для jumbo-пакетов в Ethernet.
Часть достоинств вытекает из того факта, что изначально разработчики SCTP проектировали протокол под нужды передачи телефонии (SS7) по протоколу IP.
Сравнение возможностей протоколов транспортного уровня
Параметр |
UDP |
TCP |
SCTP |
Установка соединения |
Нет |
Да |
Да |
Надежная передача |
Нет |
Да |
Да |
Сохранение границ сообщения |
Да |
Нет |
Да |
Упорядоченная доставка |
Нет |
Да |
Да |
Неупорядоченная доставка |
Да |
Нет |
Да |
Контрольные суммы данных |
Да |
Да |
Да |
Размер контрольной суммы (бит) |
16 |
16 |
32 |
Путь MTU |
Нет |
Да |
Да |
Управление накоплением |
Нет |
Да |
Да |
Многопоточность |
Нет |
Нет |
Да |
Поддержка множественных интерфейсов |
Нет |
Нет |
Да |
Связка потоков |
Нет |
Да |
Да |
Источник: http://ru.wikipedia.org/wiki/SCTP
DCCP (англ. Datagram Congestion Control Protocol) — протокол транспортного уровня модели OSI, разрабатываемый IETF. Принят в качестве стандарта в марте 2006 года. Он предоставляет механизмы для отслеживания перегрузок в сети, избегая возможности использования механизмов прикладного уровня. Этот протокол не гарантирует доставку информации в нужном порядке.
DCCP очень эффективен для приложений, в которых данные, пришедшие не вовремя, становятся бесполезными. Например: потоковое медиа-вещание, онлайн игры и интернет-телефония. Главная особенность этих приложений состоит в том, что старые сообщения очень быстро становятся бесполезными, поэтому лучше получить новое сообщение, чем пытаться переслать старое. Но на данный момент большинство таких приложений самостоятельно реализуют отслеживание перегрузок, а в качестве протоколов передачи используются TCP или UDP.
Протокол DCCP доступен в ядре Linux с версии 2.6.14 и улучшается с каждым выпуском.
Источник: http://ru.wikipedia.org/wiki/DCCP