Транспортные протоколы TCP и UDP

Протоколы уровня 4 мультиплексируют соединения между конечными процессами и служат интерфейсом между верхними (5-7) И нижними (1-3) уровнями: сегментируют сообщения верхних уровней; преобразовывают адреса, исключая неоднозначность адресных ссылок.

Под конечным процессом понимается любая прикладная программа верхних уровней: FTP, HTTP, SMTP и др. Если две конечные точки IP-сети идентифицируются с помощью уни­кальных IP-адресов, то конечные процессы идентифицируются с помощью номеров портов. Комбинация IP-адреса и номера порта даст возможность процессам быть одновременно ак­тивными в одной физической среде.

Протоколы уровня 4 ведут мультиплексирование с помощью номеров портов. Каждый сервис (FTP и SMTP) имеет известный номер порта, функционирующий как адрес для этого сервиса. Кроме номера порта - стандартного номера порта назначения, существуют динами­чески назначаемые номера портов, используемые как номера портов источника. Это адреса приложений, инициирующих запрос сервиса.

Протоколы уровня 4 обеспечивают интерфейс между приложениями и сетевым оборудованием (или между протоколами верхних и нижних уровней), см. рис. 12-4. Протоколы верхних уровней (5-7) для взаимодействия с уровнем 4 (т.е. для прохождения через "верхний интерфейс") должны иметь стандарт­ные номера портов назначения. Исключение — про­токол OSPF, который не имеет стандартного номера порта. Поэтому он формально считается протоколом уровня 4 и имеет стандартный номер протокола (а не порта), что дает ему возможность непосредственно взаимодействовать с сетевым протоколом IP.

Рис.12-1 Прохождение протоколов верх- ­них уровней через транспортный уровень
Проектировщики обычно определяют, с каким из базовых протоколов уровня 4 (TCP или UDP) они будут работать.

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

Протоколы уровня 4, в свою очередь, взаимодействуют с уровнем 3 через "нижний интер­фейс" (см. рис.12-4), требующий наличия стандартного номера протокола. IP-адрес нужен для направления сегмента от источника к назначению. Как только он туда прибыл, извлекается номер порта назначения, чтобы направить сегмент нужному приложению. Оно может вос­пользоваться номером порта источника (он содержится в этом сегменте) как адресом для по­сылки узлу-источнику отклика от узла-назначения, что сегмент прибыл.

Если между источником А и назначением В установлено мультиплексное соединение, объединяющее три активных приложения (РГР, HTTP, SMTP), то по прибытии сегментов в узел-назпаченне они будут направлены разным приложениям в зависимости от номера порта назначения. Это м.б. FTP-сервер, если в сегменте указан порт #21, Web-браузер (HTTP), если указан порт #80, или e-mail (SMTP)- cервеp, если указан порт #25 (см. рис. 12-5). Число таких мультиплексируемых приложений м.б. значительно больше, конкретное значение зависит от сети и выделяемых ресурсов.

 

Рис.12-5. Компоненты мультиплексного соединения IP-сети

Кроме понятий: номер порта и IP-адрес, используют: номер розетки и номер соединения. Номер розетки источника - это конкатенация IP-адреса источника и номера порта-источника, номер розетки назначения - это конкатенация IP-адреса назначения и номера порта- назначепия, а номер соединения - это конкатенация номеров розеток источника и назначения. Эти компоненты мультиплексного соединения IP-сети показаны на рис.12-5.

Протокол TCP

Протокол TCP - транспортный протокол TCP/IP, ориентированный на установление соедине­ния и дуплексную передачу. Он обеспечивает надежный сервис протоколов верхних уровней и доставку пакетов, используя последовательное квитирование факта приема с повторной пере­дачей пакетов при необходимости. Он описан в RFC 793 (STD 0007) с расширениями в RFC 2018 (1072), 1146, 1323, 1623. Протокол TCP может нумеровать и квитировать каждый байт данных передаваемого сообщения. Размер окна (рис.12-6) может динамически меняться, а ус­тановление соединения инициируется с двух сторон.

 

байт 0 6айт1 байт 2 байтЗ
7-4 3-0 7-6 5-0 7-4 3-0 7-4 3-0
Порт источника Порт назначения
Номер последовательности
Номер подтверждения
Offset Resrvd Code-bits Window
Check sum Urgent pointer
Options Padding
TCP Data
                       

 

Рис.12-6. Формат заголовка протокола TCP

 

Опишем кратко формат заголовка протокола TCP:

Порт источника - 16-битный номер, не закрепляемый за источником; ID приложения, запрашивающего сервис;

Порт назначения - 16-битный номер, закрепляемый за приложением, идентифицируемым в узле приема как сервисное приложение, например, FTP (20, 21), Telnet (23), TFTP (69), SNMP (161);

Номера последовательности посланных и принятых последних байтов сегментов данных, на которые TCP раз­бивает посылаемое сообщение (если кодовый бит S не установлен); номера имеют длину 32 бита каждый;

Offset - (биты 4-7 байта 0) - смещение, которое указывает 32-битное слово - начало данных;

Resrvd- (биты 0-3 байта 0 + биты 6-7 байта 1) - резервные биты;

Code bits - 6 кодовых бит управления: U (URG - факт срочности), А (АСК - режим подтверждения), Р (PSH - функ­ция проталкивания), R (RST - переустановка соединения), S (SYN - синхронизация), F (FIN - нет данных):

Window - поле для объявления размера буфера (в байтах) у источника для приема трафика управления потоком;

Check sum - контрольная сумма полей, включающих заголовок TCP и часть заголовка IP (псевдозаголовка);

Urgent pointer - указатель срочности, принимается во внимание, когда установлен кодовый бит U;

Options - поле выбора параметров при установлении вызова (можно установить максимальный размер сегмен­та);

Padding - поле длиной 1-3 байта для выравнивания 4-байтной границы;

TCP Data - поле данных, содержащее заголовки и сообщения верхних уровней.

TCP устанавливает соединение в три этапа. Сначала оговаривают начальные значения х номсрон последовательности сегментов, посланных источником, и все опции. Согласовав х с приемником и получив от пего начальные значения номеров последовательности подтвер­ждения у, соединение считается установленным. Затем передатчик начинает посылку дан­ных. Аналогично в три этапа TCP закрывает, когда нужно, установленное соединение.

Протокол UDP

UDP - протокол транспортного уровня, осуществляет простой DG-ссрвис, не требующий предварительного установления соединения. Не обеспечивая надежной доставки пакетов, он отличается высокой эффективностью. Его сервис идеален для выполнения базовых функций таких приложений, как TFTP и DNS. UDP, как и TCP, взаимодействует (через "нижний ин­терфейс" рис. 12-4) с IP (протокол #17) и пользуется его средствами управления. Как и TCP, UDP имеет в заголовке поле "порт назначения", позволяющее идентифицировать в узле на­значения то приложение, которому направлены данные. Заголовок протокола UDP компакт­- ный (4 поля) и содержит минимум информации, необходимой для реализации функций пе­- редачи и мультиплексирования (рис.12-7). Поля "Порт источника", "Порт назначения" и Check sum тс же, что и для TCP. Поле Length - длина сегмента UDP.

 

байт 0 байт 1 байт 2 байтЗ
7-4 3-0 7-4 3-0 7-4 3-0 7-4 3-0
Порт источника Порт назначения
Length Check sum
UDP Data
               

 

Рис.12-7. Формат заголовка протокола UDP

Протокол ICMP

ICMP - протокол управляющих сообщений Интернета (RFC 792) для обмена маршрутной информацией (посылки уведомлений) между хостами и маршрутизаторами той же ЛС. Он доставляет протоколу IP информацию о состоянии DG и контролирует прохождение DG по сети. Он же уведомляет источник о том, что DG сброшена в корзину.

Тип Код Контрольная сумма
Идентификатор Последовательный номер
Адресная маска

Выше представлена структура заголовка сообщения ICMP. Здесь поля "Тип" (0-16) и "Код" (0-5) указывают причину посылки или уведомляют о наступлении события. Например, тип=3 и код=0 говорит о том, что адрес назначения (или сеть) недостижимы. Идентификатор позволяет установить соответствие запроса и отклика, если требуется (это поле м.б. нулевым).

Формально ICMP м.б. рассмотрен как протокол уровня 4. т.к. он имеет статус протокола #1, но фактически это утилита, работающая с протоколом IP на уровне 3. ICMP не использует номера порта, а, значит, м.б. использован только между конечными точками, но не между ко­нечными процессами (поэтому он рассматривается в группе протоколов уровня 3). ICMP не обеспечивает услугу мультиплексирования.

Протокол ICMP может применяться в двух случаях:

- для посылки извещений, информирующих источник, например, о том, что сообщение сброшено в корзину;

- как протокол для выполнения функций диагностики, работающий в связке с командой Ping для осуществления сетевой диагностики. Посылая команду Ping, мы инициируем протокол ICMP (через IP) послать запрос серверу; ICMP-агент в точке назначения вернет нам ответ. Запрос выглядит так:

Ping→IСМР→IР→Интернет→Физическая сеть→ IP-узел и обратно.

ICMP был рассчитан на IPv4. Когда появилась версия IPv6, то появилась и версия ICMPv6 (RFC 1885). В дополнение к этому функции управления мультикастнпгом IPv4, реализуемые протоколом IGMP, были встроены в IPv6 (сообщения IGMP инкапсулируются в IP- дейтаграмму как протокол #2).