Протоколы уровня 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 Прохождение протоколов верх- них уровней через транспортный уровень |
Некоторые протоколы (например, 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).
