Протоколы транспортного уровня

26 0 0 0

Введение

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


Цели

По завершении этого раздела обучающиеся научатся:

  • Описывать общие различия между протоколами TCP и UDP.

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

  • Различать известные номера портов TCP и UDP.


Протокол управления передачей (ТСР)


d



  • Перед началом передачи данных устанавливается соединение.


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


Порты TCP


d



Протокол

Порт

FTP

20-21

HTTP

80

TELNET

23

SMTP

25


  • Определенные порты выделяются определенным сервисам.


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

Определенные процессы, имеющие свои порты, могут инициировать соединения на таких портах. Эти порты, определённые Агентством по выделению имен и уникальных параметров протоколов (IANA), также называемые хорошо известными портами, имеют диапазон значений 0-1023. Выделенные или зарегистрированные порты IANA также могут иметь диапазон значений 1024-49151. Динамические порты, также называемые частными или эфемерными портами, имеют значения в диапазоне 49152-65535, и такие порты не предназначены для какого-либо конкретного применения. Хостам обычно выделяется порт пользователя, для которого сгенерирован сокет  в данном приложении.

Примеры стандартных работающих на базе TCP-протокола приложений, которым были выделены хорошо известные номера портов - FTP, HTTP, TELNET и SMTP, которые, в свою очередь, часто работают вместе с другими известными транспортными протоколами, такими как POP3 (порт 110) и IMAP4 (порт 143).


Заголовок TCP


f



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

Управляющие биты (флаги) выполняют следующие функции: бит URG означает, что поле «Указатель важности» задействовано; бит ACK означает, что поле «Номер подтверждения» задействовано; бит PSH инструктирует получателя протолкнуть данные, накопившиеся в приёмном буфере, в приложение пользователя; бит  RST — оборвать соединения, сбросить буфер, бит SYN — синхронизация номеров последовательности; установка флага FIN указывает на завершение соединения. Дополнительные управляющие биты: CWR (Congestion Window Reduced) — поле «Окно перегрузки уменьшено» — флаг установлен отправителем, чтобы указать, что получен пакет с установленным флагом ECE; ECE (ECN-Echo) — Поле «Эхо ECN» — указывает, что данный узел способен на ECN (явное уведомление перегрузки) и для указания отправителю о перегрузках в сети.

ECN-nonce позволяет получателю уведомить отправителя, что подтверждаемый сегмент отправителя был принят без маркеров перегрузки. Случайные однобитовые значения (nonce) помещаются в 2-битовый код ECT. Однобитовая сумма этих значений возвращается в виде флага в заголовке TCP, называемого битом NS. Поле «Опции» содержит параметры, которые могут быть включены в состав заголовка TCP и часто используются во время первоначального установления соединения, как в случае с максимальным размером сегмента (MSS), используемым для определения размера сегмента, который должен использовать приемник. Размер заголовка TCP должен быть равен 32 битам, в противном случае добавляются дополнительные 0.




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


j



  • Соединение TCP устанавливается после прохождения процедуры трехстороннего рукопожатия.


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

Создаваемое соединение проходит через серию состояний. Состояние LISTEN означает, что сервер ожидает запросов установления соединения от клиента. SYN-SENT - клиент отправил запрос серверу на установление соединения и ожидает ответа. SYN-RECEIVED - сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения. ESTABLISHED - соединение установлено, идёт передача данных.

Механизм рукопожатия TCP-интерфейса начинается с номера начальной последовательности, генерируемого инициирующим TCP в рамках процесса синхронизации (SYN). Затем исходный сегмент TCP с установленным флагом SYN передается запланированному TCP-узлу назначения для достижения состояния SYN-SENT. В рамках процесса подтверждения, TCP-узел на другом конце генерирует свой номер начальной последовательности, чтобы синхронизировать поток TCP в другом направлении. Этот TCP передает этот номер последовательности, а также номер подтверждения, который равен полученному номеру последовательности, увеличенному на один, вместе с установленными флагами SYN и ACK в заголовке TCP для достижения состояния SYN-RECEIVED.

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


Процесс передачи TCP


g



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

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

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



Управление потоком TCP

k

Поле размера окна TCP (window) отвечает за управление потоком, регулируя количество данных, посылаемых отправителем. Это достигается путем возвращения значения "window" с каждым сегментом TCP, для которого установлено поле ACK, с указанием диапазона допустимых порядковых номеров, не входящих в последний успешно принятый сегмент. Окно указывает на разрешенное количество октетов, которые отправитель может передать перед получением дальнейшего разрешения.

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

Размер окна TCP, равный 0, означает, что сегменты обрабатываться не будут, за исключением входящих сегментов с установленным флагами ACK, RST и URG. Если существует окно с размером 0, отправитель должен периодически проверять размер окна получающего TCP-узла с целью своевременного оповещения об изменении размера окна. Период ретрансляции, как правило, составляет две минуты. Когда отправитель отправит периодические сегменты, TCP-получатель должен отправить в ответ подтверждение с порядковым номером текущего окна с размером 0.



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


h


  • Хост A отвечает за получение подтверждения ACK Сервером А перед закрытием соединения.


В процессе завершения TCP-соединения определяется ряд состояний, через которые TCP должен пройти. Эти состояния следующие: FIN-WAIT-1 - одна из сторон (узел-1) завершает соединение, отправив сегмент с флагом FIN; FIN-WAIT-2 - Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN; TIME-WAIT - Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт в течение 2*MSL перед окончательным закрытием соединения; CLOSE-WAIT - Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь, сегмент ACK и продолжает одностороннюю передачу;

LAST-ACK - Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN; TIME-WAIT - Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт  в течение 2*MSL перед окончательным закрытием соединения.


Протокол пользовательских датаграмм

h


  • Данные UDP отправляются без установления соединения.


User Datagram Protocol или UDP представляет собой альтернативу TCP и применяется в тех случаях, когда TCP считается неэффективным транспортным механизмом, главным образом при передаче трафика, чувствительного к высокой задержке. Если TCP считается сегментом, то UDP – это датаграмма блока данных протокола (PDU), под которой понимается самостоятельный, независимый объект, передающий информацию, которой достаточно для осуществления маршрутизации из источника в конечную систему назначения без необходимости установления предварительного соединения между этим источником и конечными системами назначения и транспортной сетью, как это определено в RFC 1594.

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


Формат датаграмм UDP

d


  • UDP задействует минимальный объем служебной информации для каждой датаграммы.

  • Доставка датаграмм не гарантируется протоколом UDP.


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


Процесс передачи UDP

d


  • UDP допускает дублирование датаграмм или неупорядоченную доставку датаграмм.


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

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


Процесс передачи UDP

d

  • Из-за отсутствия подтверждений потерянные пакеты не передаются повторно, однако это эффективно при передаче данных, чувствительных к задержке.


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

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



Заключение

  • Какова цель поля подтверждения в заголовке TCP?

  • Какие управляющие биты TCP используются в процессе трехстороннего рукопожатия TCP?


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

  2. Трехстороннее рукопожатие включает в себя управляющие биты SYN и ACK, которые служат для установления и подтверждения соединения между двумя конечными системами, между которыми происходит передача сгементов.

  • x

Комментарий

Отправить
Выполните вход в систему, чтобы ответить на пост. Вход | Регистрация

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

Авторизуйтесь и пользуйтесь всеми преимуществами участника!

Вход