Галкин В.А., Григорьев Ю.А. Телекоммуникации и сети

Подождите немного. Документ загружается.

5. Сетевые

протоколы

Порт источника

Порт приемника

Номер в последовательности

Номер подтверждения

Смещение

Резерв

UL\|

GttCl

т\ым

Контрольная сумма

Размер окна

Указатель

Дополнительные данные заголовка

Данные

вьфавнивания

Рис.

5.48.

Формат заголовка пакета TCP

Несмотря на то что для пользователя передача данных с использованием

протокола TCP выглядит как потоковая, на самом же деле обмен между парт-

нерами осуществляется посредством пакетов данных, которые мы будем на-

зывать «ТСР-пакетами».

Формат заголовка пакета TCP и назначение полей. На рис. 5.48 при-

веден формат заголовка ТСР-пакета. Порт источника и порт приемника пред-

ставляют собой 16-битовые поля, содержащие номера портов, соответствен-

но,

источника и адресата ТСР-пакета. Номер в последовательности (sequence

number) - 32-битовое поле, содержимое которого определяет (косвенно) поло-

жение

данных ТСР-пакета

внутри

исходящего потока

данных,

существующего

в рамках текущего логического соединения.

момент установления логического соединения каждый

из

двух партнеров

генерирует свой начальный «номер

последовательности», основное требова-

ние к которому - не повторяться в промежутке времени, в течение которого

ТСР-пакет может находиться в сети (по сути, это время жизни 1Р-сегмента).

Партнеры обмениваются этими начальными номерами и подтверждают их

получение. Во время отправления ТСР-пакетов с данными поле «номер в пос-

ледовательности» содержит сумму начального номера и количества байт ра-

нее

переданных данных.

Номер подтверждения (acknowledgement

number)

- 32-битовое

поле,

содер-

жимое которого определяет (косвенно) количество принятых

данньпс из

входя-

щего потока к ТСР-модулю, формирующему ТСР-пакет.

Смещение данных - 4-битовое поле, содержащее длину заголовка ТСР-па-

кета

32-битовьпс словах и используемое для определения начала расположе-

ния данных в ТСР-пакете.

Флаг URG -

бит,

единичное значение которого означает, что ТСР-пакет со-

держит

важные

(urgent)

данные.

Подробно

информащ1Я

содержится

в поле

дан-

ных ТСР-пакета, определенного как «Важные данные».

400

5.6.

Протоколы

IIуровня стека TCP/IP

Флаг АСК - бит, единичное значение которого означает, что ТСР-пакет со-

держит в поле «номер подтверждения» верные данные.

Флаг PSH - бит, единичное значение которого означает, что данные, содер-

жащиеся в ТСР-пакете, должны быть немедленно переданы прикладной про-

грамме, для которой они адресованы. Подтверждение для ТСР-пакета, содер-

жащего единичное значение во флаге PSH, означает, что и все предьщущие

ТСР-пакеты достигли адресата.

Флаг RST - бит, устанавливается в единицу в ТСР-пакете, отправляемом в

ответ на получение неверного ТСР-пакета. Также может означать запрос на

переустановление логического соединения.

Флаг SYN - бит, единичное значение которого означает, что ТСР-пакет

представляет собой запрос на установление логического соединения. Получе-

ние пакета с установленным флагом SYN должно бьггь подтверждено прини-

мающей стороной.

Флаг FIN -

бит,

единичное значение которого означает, что ТСР-пакет пред-

ставляет собой запрос на закрытие логического соединения и является призна-

ком конца потока данных, передаваемых в этом направлении. Получение паке-

та с установленным флагом FIN должно бьггь подтверждено принимающей

стороной.

Размер окна - 16-битовое поле, содержащее количество байт информации,

которое может принять в свои внутренние буфера ТСР-модуль, отправляющий

партнеру данный ТСР-пакет. Данное поле используется принимающим поток

данных ТСР-модулем для управления интенсивностью этого потока, так, уста-

новив нулевым значение этого поля, можно полностью остановить передачу

данных, которая будет возобновлена только, когда размер окна примет доста-

точно большое значение. Максимальный размер окна зависит от реализации, в

некоторых реализациях максимальный размер устанавливается системным ад-

министратором (типичное значение максимального размера окна - 4096 байт).

Определение оптимального размера окна - одна из наиболее сложных задач

реализации протокола TCP.

Контрольная сумма - 16-битовое поле, содержащее контрольную сумму,

подсчитанную для ТСР-заголовка, данных пакета и ряда полей IP-заголовка.

Указатель - 16-битовое поле, содержащее указатель (в виде смещеьшя) на

первый байт в теле ТСР-пакета, начинающий последовательность важных

(urgent) данных.

Дополнительные данные заголовка ~ последовательность полей произволь-

ной длины, описывающих необязательные данные заголовка. Протокол TCP

определяет только три типа дополнительных: данных заголовка:

• конец списка полей дополнительных данных;

• пусто (No Operation);

• максимальный размер пакета.

401

5. Сетевые

протоколы

Дополнительные данные последнего типа посылаются в ТСР-заголовке в

момент установления логического соединения

для выражения

готовности

ТСР-

модулем принимать пакеты длиннее 536 байт. В UNIX-реализациях длина па-

кета обычно определяется максимальной длиной 1Р-сегмента для сети.

Номера

портов

играют роль адресов транспортного уровня, идентифшщруя

на

конкретных узлах

сети,

по

сути

дела,

потребителей транспортных

услуг,

пре-

доставляемых как протоколом

TCP,

так и протоколом UDP. При этом протоко-

лы TCP и UDP имеют свои собственные адресные пространства: например,

порт номер 513 для TCP не идентичен порту номер 513 для UDP.

Примечание,

Своя собственная адресащм на транспортном уровне стека

протоколов

сетевого взаимодействия необходима

для

обеспечения возможности функционирова-

ния на узле сети

одновременно

многих сетевых

приложений.

Наличие в

ТСР-заголовке

номера порта позволяет

ТСР-модулю,

получающему последовательности

ТСР-пакетов,

формировать

раздельные потоки

данных к прикладным

программам.

Взаимодействие прикладных программ, использующих транспортные услу-

ги протокола TCP (или UDP), строится согласно модели «клиент-сервер», ко-

торая подразумевает, что одна программа (сервер) всегда пассивно ожидает

обращения к ней другой программы (клиента). Связь программы-клиента и

сервера идентифшщруется пятеркой:

Используемый транспортный протокол (TCP или UDP);

IP-адрес сервера;

Номер порта сервера;

IP-адрес клиента;

5. Номер порта клиента.

Для того, чтобы клиент мог обращаться к необходимому ему серверу, он

должен знать номер порта, по которому сервер ожидает обращения к нему

(«слушает сеть»). Локальное присвоение номера порта заключается

том, что

разработчик некоторого приложения просто связывает с ним любой доступ-

ный,

произвольно выбранный числовой идентификатор, обращая внимание на

то,

чтобы он не входил

число зарезервированных номеров

портов.

В дальней-

шем все

удаленные запросы к данному приложению от других приложений

дол-

жны адресоваться с указанием назначенного ему номера порта.

Как должны назначаться номера протокольных портов? Эта проблема важ-

на, так как два компьютера должны договариваться о номерах портов, прежде

чем они смогут взаимодействовать. Например, когда компьютер А хочет по-

лучить файл от компьютера В, он должен знать, какой порт в компьютере В

использует программа передачи

файла.

Существуют два фундаментальных под-

хода

назначению портов.

Первый

подход использует централизованное управление назначением. Все

договариваются позволить центральному органу назначать номера всем необ-

ходимым портам и затем опубликовать список назначений.Тогда все програм-

мы создаются в соответствии с этим списком. Этот подход иногда называют

«универсальным назначением». Такие назначения портов становятся широко

известными назначениями,

номера

портов

фиксированы

носят название

<осо-

402

5.6.

Протоколы

IIуровня стека TCP/IP

шо известных номеров портов» (well-known port numbers). Централизованное

присвоение сервисам номеров портов выполняется организацией Internet

Assigned Numbers Authority.

Второй подход использует динамическое назначение. При этом подходе но-

мера портов неизвестны всем. Вместо этого само сетевое обеспечение назна-

чает порт, когда программа в этом нуждается. Чтобы узнать о текущем на-

значении портов

на другом

компьютере, нужно послать запрос,

котором задан

примерно такой вопрос: «как мне вызвать службу передачи файлов?».

Компьютер-получатель ответит, какой порт необходимо использовать.

Разработчики TCP/IP приняли смешанный подход, при котором группа

портов назначается априорно, но большинство из них можно свободно исполь-

зовать для любых целей прикладными программами в локальной сети. Цент-

рализованно назначаемые номера портов начинаются с маленьких значений и

затем увеличиваются, а порты с большими значениями используются для ди-

намического назначения.

На рис. 5.49 приведены примеры номеров портов для некоторых служб.

В протоколе TCP использован принцип «скользящего окна», который обес-

печивает «опережающую» посьшку данных с «отложенным» их подтвержде-

нием.

Следует отметить недостаток этого механизма: если в течение некото-

рого времени не будет получено «отсроченное» подтверждение ранее

отправленного пакета, то отправляющий ТСР-модуль будет вынужден повто-

рить посылку всех ТСР-пакетов, начиная с не-

подтвержденного. Размер

окна,

как

правило,

оп-

ределяется объемом свободного места в

буферах принимающего ТСР-модуля.

Протокол TCP предусматривает возмож-

ность информирования принимающей стороны

взаимодействия отправляющей стороной о на-

личии в ТСР-пакете важных данных (urgent

data),

требующих особого внимания согласно

логике прикладной задачи. Отличие важных

данных от данных основного потока заключа-

ется в том, что принимающая сторона должна,

как

правило,

обработать их прежде ранее полу-

ченных, но

еще не

обработанных данных потока.

Для индикации наличия в ТСР-пакете важ-

ных данных используется флаг URG ТСР-заго-

ловка, местоположение важньпс данных в теле

ТСР-пакета определяется полем «Указатель»

ТСР-заголовка - оно задает смещение первого

байта важньпс данных в теле ТСР-пакета.

Служба

ftp-data

ftp

telnet

smtp

time

1 finger

portmap

exec

vAio

shell

talk

route

Xserver

Номер

порта

111

512

513

514

517

520

6000

Протокол

TCP

UDP

TCP

UDP

TCP

UDP

TCP

UDP

TCP

Рис. 5.49. Номера портов для

некоторых служб

403

5. Сетевые

протоколы

TCP

Номер в Номер Флаги Длина

последовательности подтверждения данных

TCP

<=1

1 1000

SYN

1 3000 1001

SYN, АСК

1 1001 3001 АСК

0 1

Рис.

5.50. Установление логического соединения

Протокол TCP предусматривает передачу важных (urgent) данных в рам-

ках общего потока данных

(«in-band»).

Существуют протоколы (например ISO),

поддерживающие режим передачи важных (expedited) данных вне общего по-

тока данных («out-band»), что в общем случае быстрее.

Этапы ТСР-взаимодействия. Взаимодействие партнеров с использова-

нием протокола TCP строится в три этапа:

• установление логического соединения;

• обмен данными;

• закрьггие соединения.

Рис.

5.50-5.52

иллюстрируют последовательность обмена ТСР-пакетами

двумя ТСР-модулями: А и В. ТСР-пакеты представлены тремя полями ТСР-

заголовка («Номер в последовательности», «Номер подтверждения», «Флаги»)

и числом, характеризующим длину данных из которых тело ТСР-пакета (заме-

тим, что реально поля «Длина данных» в ТСР-заголовке нет). Стрелками пока-

заны направления пересылки пакетов.

Рис.

5.50 демонстрирует этап установления соединения, реализуемый как

«трехшаговое рукопожатие» (three-way handshake). На первом шаге ТСР-мо-

дуль А, играя роль клиента, посылает ТСР-модулю В пакет с установленным

флагом SYN и начальным значением номера в последовательности, равным

1000.

ТСР-модуль В, будучи готов со своей стороны установить соединение,

отвечает ТСР-пакетом, подтверждающим правильный прием запроса (поле

«Номер подтверждения» на

больше начального номера в последовательнос-

ти для ТСР-модуля А и среди флагов есть установленный в 1 флаг АСК) и

информирующим о готовности установить соединение (установлен флаг SYN

и установлено значение 3000 начального номера последовательности). На тре-

тьем шаге ТСР-модуль А подтверждает правильность приема ТСР-пакета от В.

На рис. 5.51 показан этап двустороннего обмена данными между ТСР-мо-

дулями А и В. ТСР-модуль, принимающий адресованные ему данные, всегда

подтверждает их прием, вьгчисляя значение поля «Номер подтверждения» в

заголовке ответного ТСР-пакета как сумму пришедшего «Номера в последо-

вательности» и длины правильно принятых данных. Посьшка данных к партне-

ру и подтверждение принятьЕс от него данных реализуются в рамках одного

ТСР-пакета.

404

5.6.

Протоколы

IIуровня

стека TCP/IF

TCP

Номер в Номер Флаги Длина

последовательности подтверждения данных

TCP

1 1001

3001 АСК 1

50 1

1 3001

1051

АСК

80 1

1 1051

3081 АСК

L.L J

Рис. 5.51. Обмен данными

Рис.

5.52 иллюстрирует закрытие соединения

по

инициативе ТСР-модуля

А,

посылающего партнеру ТСР-пакет с установленным флагом FIN. Прием зап-

роса на закрытие соединения ТСР-модуль В подтверждает пакетом, содержа-

щем в

своем заголовке

поле

«Номер подтверждения», значение которого (1052)

на

больше значения принятого «Номера в последовательности» (1051). Пос-

ле этого посылка каких-либо данных ТСР-модулем А невозможна, однако

модуль В имеет данные для передачи, которые он отправляет ТСР-модулю

А и получает подтверждение на их прием. Затем ТСР-модуль В формирует

пакет с флагом

FIN,

после подтверждения его»приема соединение считается

закрыгым.

При подтверждении ТСР-пакетов, содержащих единичные флаги SYN или

РШ,

значение поля «Номер подтверждения» на 1 больше значения соответ-

ствующего поля «Номер в последовательности», несмотря на то, что никакие

данные в подтверждаемых ТСР-пакетах не передаются.

Примечание.

Приведенный пример не

рассматривает

ситуащ1и,

связанные

«поте-

рей»

ТСР-пакетов

сети,

и их

обработку,

связанную с повторной передачей

данных.

TCP Номере Номер Флаги Длина ТСР

А последовательности подтверждения данных В

1 1051

3081

FIN, АСК

- оП

1 3081 1 1052 1 АСК 1 0 |

1 3081

! 1052 1 АСК 1 40 1

1 1052

3121 1 АСК

1 3121 1 1052

ACK,FIN | 0 |

1 1052 3122 1 АСК 1 0 1

Рис. 5.52. Закрытие соединения

405

5. Сетевые

протоколы

Таймеры и их назначение. Таймер повторной передачи. Данный тай-

мер устанавливается значением КТО (Retransmission Time Out - интервал до

повторной передачи) в момент посылки ТСР-пакета адресату. Если таймер

будет сброшен в ноль до моменгга получения подтверждения пакета, то этот

пакет должен быть послан вновь.

Ясно,

что величина RTO не может быть фиксированной, так как ТСР-паке-

ты до разных адресатов следуют по различным маршрутам через сети, ско-

рость передачи данных в которых может различаться более чем в тысячи раз.

Для вычисления «оптимального» значения RTO в каждом логическом соеди-

нении используется специальная процедура, специфицированная в

RFC-793.

Со-

гласно этой процедуре, для каждого ТСР-пакета измеряется величина RTT

(Round Trip Time - интервал времени от момента посьшки ТСР-пакета до мо-

мента получения подтверждения на него). По измеренным RTT определяют

величину SRTT (Smoothed RTT - сглаженный RTT):

SRTT - *

SRTT + (1- к)

RT (5.1)

Здесь

A:-

сглаживающий коэффициент (например, 0,9).

Формула (5.1) учитывает фильтрацию нетипичньгс (пиковьпс) значений из-

меренной величины RTT.

«Оптимальное» значение RTO вьршсляют по формуле:

RTO = min(U, max(L, р х SRTT)), (5.2)

где:

и - ограничение сверху на значение RTO (например, 30

с);

- ограничение

снизу на значение RTO (например, I с);р- коэффициент «запаса» (например, 2).

Если после повторной посылки ТСР-пакета, вновь не будет получено его

подтверждение за интервал времени RTO, то попытки послать ТСР-пакеты

будут повторены (до 12 раз), но каждый раз с экспоненциально возрастающим

значением RTO. Только после неудачи всей серии повторных посылок связь

между партнерами будет считаться аварийно закрытой.

Таймер возобновления передачи, В ходе взаимодействия двух ТСР-моду-

лей (А и В) вполне возможна следующая ситуация:

• ТСР-модуль В уведомляет ТСР-модуль А о невозможности приема от

него данньпс, определяя размер окна равным 0;

• ТСР-модуль А, имея данные для передачи, переходит в состояние ожида-

ния от ТСР-модуля В пакета с ненулевым размером окна;

• ТСР-модуль В, у которого освободилось некоторое пространство в буфе-

рах, посылает модулю А ТСР-пакет с ненулевым размером окна;

• адресованный модулю А пакет «потерян» по какой-либо причине и оба

ТСР-модуля переходят в состояние бесконечного ожидания.

Для выхода из такого тупикового состояния и служит таймер возобновления

передачи (persistence timer -- «настойчивый» таймер). Он устанавливается в

момент получения ГСР-пакета с нулевым значением поля «Размер окна» в его

406

5.6.

Протоколы

IIуровня стека TCP/IP

заголовке (типичное начальное значение для этого таймера - 5 с). Если до

момента обнуления таймера не будет получено разрешение на возобновление

передачи

данных,

то ожидающий разрешения ТСР-модуль отправляет партне-

ру

пакет,

содержащий

всего лишь 1

байт

данных.

По

реакции

партнера,

возвра-

щающего пакет с нулевьв^1/ненулевым значением размера окна, ТСР-модуль

продолжает

ожидание или

возобновляет посылку данных:.

Таймер закрытия

связи.

Протокол TCP предусматривает следующий про-

стой прием

предотвращения появления

в сети

ТСР-пакетов,

не

имеющих адре-

сатов:

после закрытия логического соединения между партнерами номера

пор-

тов,

использовавшихся в этом соединении, остаются еще некоторый интервал

времени действительными, что дает возможность долго блуждавшим по сети

ТСР-пакетам добраться до места назначения (где они будут просто проигно-

рированы). Значение этого интервала

равно

удвоенному времени жизни IP-па-

кета (обычно, 2

X15

= 30 с).

Таймеры поддержки

соединения.

Для проверки наличия логического со-

единения между ТСР-модулями используют следующий механизм. Каждый

ТСР-модуль, участвующий в логическом соединении, через фиксированный

промежуток времени (keep-alive

timer),

равный обычно

с, периодически от-

правляет партнеру пустые (не содержащие данньпс) ТСР-пакеты и ждет их

подтверждения. Каждое полученное подтверждение говорит

сохранении

со-

единения.

Если же в

течении определенного интервала

времени (idle

timer),

рав-

ного

обычно 360

с,

не будет получено ни

одного подтверждения,

то

логическое

соединение считается оборванным.

Очевидно, что данный механизм имеет смысл включать в работу только

тогда, когда партнеры по ТСР-взаимодействию приостановили по какой-либо

причине обмен данных на достаточно длительный срок (более 45 с).

Протокол UDP

Протокол дейтаграмм пользователя UDP (User Datagram Protocol) являет-

ся протоколом транспортного уровня и базируется на возможностях, предос-

тавляемых межсетевым протоколом IP. Основная задача TCP - обеспечение

«быстрой» передачи данных в сети. Его транспортный адрес в заголовке IP-

сегмента равен

17.

Описание протокола UDP дано в рекомендащш RFC-768.

Назначение и основные хара1стеристики протокола. Протокол транс-

портного уровня UDP

играет

роль

интерфейса

для

прикладных программ

сред-

ствам протокола межсетевого уровня IP. Данные, отправляемые прикладным

процессом через модуль

UDP,

достигают места назначения как единое целое.

Например,

если процесс

отправитель производит

записей

UDP-порт,

то

про-

цесс-получатель должен будет сделать 6 чтений. Размер каждого записанного

сообщения будет совпадать

размером каждого прочитанного. Протокол UDP

сохраняет границы сообщений, определяемые прикладным

процессом.

Он

ни-

когда не объединяет несколько сообщений в одно и не делит одно сообщение

на части.

407

5. Сетевые

протоколы

Присвоение номера порта можно осуществить любым из рассмотренных

выше способов, в том числе и локальным, который состоит в том, что разра-

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

произвольно выбранный числовой идентификатор, обращая внимание на то,

чтобы он не входил в число зарезервированных номеров портов. В дальней-

шем все удаленные запросы к данному приложению от других приложений дол-

жны быть адресованы с указанием назначенного ему номера порта.

Основные характеристики протокола:

• реализует взаимодействие без установления логического (виртуального)

соединения;

• организует дейтаграммную передачу данных;

• использует 16-битовые номера портов для идентификащш партнеров по

взаимодействию на транспортном уровне;

• не гарантирует надежной передачи данных (возможна как потеря UDP-

пакетов, так и их дублирование);

• не имеет средств уведомления источника UDP-пакета о доставке пакета

адресату;

• не обеспечивает правильный порядок доставки UDP-пакетов от источни-

ка к приемнику;

• может гарантировать целостность даьшых в UDP-пакете за счет исполь-

зования контрольной суммы;

• очень прост (особенно, по сравнению с протоколом TCP).

Формат UDP-дейтаграммы и назначение полей. Формат заголовка для

дейтаграмм пользователя приведён на рис. 5.53. Если задействован порт от-

правителя, то он указывает порт процесса, посьшающего дейтаграмму. Мож-

но принять, что это тот порт, на который при отсутствии какой-либо иной ин-

формации следует адресовать ответную дейтаграмму. Если данное поле не

задействовано, то в него следует записать нули. Порт получателя имеет смысл

только в конгексте конкретного Intemet-адреса получателя.

Длина - длина в октетах данной UDP-дейтаграммы, включающая как за-

головок, так и данные (это означает, что минимальное значение поля длины

равно восьми).

Контрольная сумма - 16-битное дополнение до единицы суммы дополне-

ний полей UDP-заголовка, поля данных, нескольких полей

из

заголовка в прото-

коле IP (IP-адрес отправителя, IP-адрес получателя, поле протокола) и поля

длины UDP-дейтаграммы. Это оз-

начает, что UDP должен взаимодей-

ствовать с IP для нахождения нужных

адресов перед посылкой дейтаграммы.

Целью использования IP-адресов

в контрольном суммировании явля-

Рис. 5.53. Формат заголовка

UDP-

ется проверка того, что UDP-дей-

дейтаграммы таграмма достигла своего настоящего

408

Порт отправителя

Длина

16 31

Порт получателя

Контрольная сумма

Данные...

5.6.

Протоколы

IIуровня стека TCP/IP

места назначения, так как UDP-заголовок определяет только номер протоколь-

ного порта. Таким образом, чтобы проверить место назначения, UDP на

компьютере-источнике вычисляет контрольную сумму, которая учитьюает IP-

адрес назначения, а так же саму UDP-дейтаграмму. При получении дейтаг-

раммы в месте назначения программы UDP проверяют контрольную сумму,

используя IP-адрес назначения, полученный из заголовка 1Р-дейтаграммы,

которая содержала UDP-сообщение. Если контрольные суммы одинаковы,

дейтаграмма действительно достигла нужного хост-компьютера и нужного порта

в нем.

Если контрольная сумма равна нулю, то это означает, что отправитель дей-

таграммы ее не подсчитывал, и, следовательно, ее нужно игнорировать. Если

два модуля UDP взаимодействуют только через одну сеть Ethernet, то от кон-

трольного суммирования можно отказаться, так как средства Ethernet обеспе-

чивают достаточную степень надежности обнаружения ошибок передачи. Это

снижает накладные расходы, связанные с работой UDP. Однако рекомендует-

ся всегда вьшолнять контрольное суммирование, так как возможно в какой-то

момент изменения в таблице маршрутов приведут к тому, что дейтаграммы

будут посьшаться через менее надежную среду.

Если контрольная сумма правильная (или равна нулю), то проверяется порт

назначения, указанный в заголовке дейтаграммы. Если к этому порту подклю-

чен прикладной процесс, то прикладное сообщение, содержащееся в дей-

таграмме, встает в очередь для прочтения. В остальных случаях дейтаграм-

ма отбрасьшается. Если дейтаграммы поступают быстрее, чем их успевает

обрабатывать прикладной процесс, то при переполнении очереди сообщений

поступающие дейтаграммы отбрасьюаются модулем UDP.

UDP-сообщения, включающие UDP-заголовок и данные, инкапсулируются

в IP-дейтаграммах при передаче по сети.

Мультиплексирование и демультиплексирование прикладных про-

токолов с помощью протокола UDP. Протокол UDP ведет для каждого

порта две очереди: очередь пакетов, поступающих в данный порт из сети, и

очередь пакетов, отправляемых данным портом в сеть. Процедура обслужи-

вания протоколом UDP-запросов, поступающих от нескольких различных при-

кладных сервисов, называется мультиплексированием. Распределение про-

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

высокоуровневых сервисов, идентифицированных номерами

портов,

называет-

ся демультиплексированием.

Концептуально все процессы мультиплексирования и демультиплексирования

между UDP и прикладными программами осуществляются с помощью меха-

низма

портов.

На практике каждая прикладная программа должна договориться

с операционой системой о получении протокольного порта и связанного с ним

номера перед посьшкой UDP-дейтаграммы. Когда порт выделен, прикладная

программа посьшает любую дейтаграмму через порт, номер которого указан в

поле «Порт отправителя» UDP-заголовка. В ходе обработки входных данных

409