Заголовок фрагмента дейтаграммы #1

Заголовок фрагмента дейтаграммы #2

Рис. 6.5. Содержание заголовков двух дейтаграмм после фрагментации

Таблица 6.2. Значения поля «Протокол»

Поле «Контрольная сумма» рассчитывается по всему заголовку. Так как не­которые поля заголовка меняют свое значение, например время жизни, при про­хождении дейтаграммы через маршрутизаторы контрольная сумма проверяется и повторно рассчитывается при каждой модификации заголовка. Определение контрольной суммы заголовка обеспечивает безошибочность передачи дейтаграммы через сеть. Перед отправкой дейтаграммы вычисляется контрольная сумма, которая вносится в ее заголовок. При получении дейтаграммы вычисляется ее контрольная сумма, которая сравнивается со значением контрольной суммы в ее заголовке. При обнаружении ошибки в контрольной сумме дейтаграмма отбрасывается. Алгоритм вычисления контрольной суммы заголовка дейтаграммы протокола IP применяется и во многих других протоколах, таких как UDP, TCP, ICMP и OSPF.

Поля «Адрес отправителя» и «Адрес получателя» имеют одинаковые длину и структуру. Поля содержат 32-битные IP-адреса отправителя и получателя дей­таграммы.

Поле «Опции» необязательно и обычно используется при настройке сети. В поле могут быть указаны точный маршрут прохождения дейтаграммы в рас­пределенной сети, данные о безопасности, различные временные отметки и т. д. Поле не имеет фиксированной длины, поэтому для выравнивания заголовка дейтаграммы по 32-битной границе предусмотрено следующее поле — поле «Выравнивание». Выравнивание осуществляется нулями.

Длина поля «Опции» меняется в зависимости от того, какие опции были выбраны. Опции в дейтаграмме размещаются друг за другом, без разделителей. Каждая опция состоит из кода опции (1 байт), за которым могут следовать длина опции (1 байт) и байты данных этой опции. На рис. 6.6 показан формат поля «Опции».

Рис. 6.6. Формат поля «Опиии»

Байт кода опции делится на три поля: флаг «Копировать», «Класс опции» к «Номер опции». Флаг «Копировать» управляет тем, как маршрутизаторы учи­тывают опции при фрагментации дейтаграммы. Если бит установлен, опции до­лжны копироваться во все фрагменты дейтаграммы. Если флаг не установлен опцию нужно скопировать только в первый фрагмент.

Поля «Класс опции» и «Номер опции» указывают класс опции и номер оп­ции внутри этого класса (табл. 6.3 и 6.4).

Таблица 6.3. Значения поля «Класс опции;

Из класса 3 применяется опция с номером 4. В нее записываются межсетевые временные метки. Они используются при протоколировании следования дейтаграммы по маршруту.

В настоящее время некоторые опции практически не используются. Напри­мер, опция «Безопасность» с номером 2 была разработана исключительно для нужд министерства обороны США, и в гражданских сетях не используется. Опция «Идентификатор потока» использовалась только в экспериментах с сетя­ми Satnet и сейчас не встречается.

Таблица 6.4. Номера опций класса 0

Перед дальнейшим анализом протокола IP необходимо рассмотреть механиз­мы IP-адресации и протокол разрешения адресов ARP.

Протокол ARP

Протокол ARP (Address Resolution Protocol, протокол разрешения адреса) опи­сан в документе RFC 826. Необходимость протокола ARP продиктована тем обстоятельством, что IP-адреса устройств в сети назначаются независимо от их физических адресов. Поэтому для доставки сообщений по сети необходимо определить соответствие между физическим адресом устройства и его IP-адре­сом — это называется разрешением адресов. В большинстве случаев прикладные программы используют именно IP-адреса. А так как схемы физической адреса­ции устройств весьма разнообразны, то необходим специальный, универсальный протокол. Разрешение адресов может быть произведено двумя способами: с по­мощью прямого отображения и с помощью динамического связывания. Прото­кол ARP использует механизм динамического связывания.

Функционально протокол ARP состоит из двух частей. Одна часть протокола определяет физические адреса при посылке дейтаграммы, другая отвечает на запросы от других устройств в сети. Протокол ARP предполагает, что каждое устройство знает как свой IP-адрес, так и свой физический адрес.

Для того чтобы уменьшить количество посылаемых запросов ARP, каждое устройство в сети, использующее протокол ARP, должно иметь специальную буферную память. В этой памяти хранятся пары (IP-адрес, физический адрес) устройств в сети. Всякий раз, когда устройство получает ARP-ответ, оно сохра­няет в этой памяти соответствующею пару. Если адрес есть в списке пар, то нет необходимости посылать АРР - запрос. Эта буферная память называется ARP-таблицей.

В ARP-таблице могут быть как статические, так и динамические записи. Динамические записи добавляются» и удаляются автоматически. Статические за­писи могут быть добавлены пользователем. Кроме того, ARP-таблица всегда со­держит запись с физическим широковещательным адресом (%FFFFFFFFFFFF) для локальной сети. Эта запись позволяет устройству принимать широковеща­тельные ARP-запросы.

Каждая запись в ARP-таблице имеет свое время жизни — обычно оно состав­ляет 10 мин. После того как записи была добавлена в таблицу, ей присваивается таймер. Если запись не используется в первые две минуты, она удаляется. Если используется — время ее жизни (доставляет 10 мин. В некоторых реализациях протокола ARP новый таймер устанавливается после каждого использования записи в ARP-таблице. На рис. 6.7 показан пример ARP-таблицы, сформирован­ной на компьютере с двумя сетевыми интерфейсами, работающим под управле­нием операционной системы Micrcosoft Windows NT. Это таблица выводится по команде агр -а.

Сообщения протокола ARP (при передаче по сети инкапсулируются в поле данных кадра. Они не содержат IP-заголовка. В отличие от большинст­ва протоколов сообщения, ARP не имеют фиксированного формата заголовка. Протокол ARP был разработан таким образом, чтобы его можно было использо­вать для разрешения адресов в различных сетях. Фактически протокол можно использовать с произвольными физическими адресами и сетевыми протоко­лами.

На рис. 6.8 показан формат сообщения ARP. В отличие от большинства протоколов, поля переменной длины в сообщениях ARP не выровнены по 32-би­товой границе, что вносит определенные трудности в изучение протокола. На­пример, аппаратный адрес отправителя занимает 6 байт, поэтому на рис. 6.8 он занимает две строки (одна строка — одно двойное слово).

В поле «Тип сети» для сетей Ethernet указывается 1. Для других типов сетей значение этого поля определено соответствующими документами RFC. Поле «Тип протокола» позволяет использовать сообщения ARP не только для прото­кола IP, но и для других сетевых, протоколов. Для протокола IP значение этого поля равно 0800 (шестнадцатеричное). В поле «Тип операции» для ARP-запросов указывается 1, а для ARP-ответов — 2. Поля «Длина аппаратного адреса» и «Длина сетевого адреса» позволяют использовать протокол ARP в любых сетях, так как длину адресов можно задать.

Рис. 6.8. Формат сообщения ARP

Протокол ARP работает по следующей схеме. Устройство, отправляющее ARP-запрос, заполняет в сообщении все поля, кроме искомого аппаратного ад­реса. Затем оно рассылает запросы по всей подсети. Поле заполняется устройством, опознавшим свой IP-адрес.

Протокол 1СМР

Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) описан в документе RFC 792. Этот протокол является вспомогательным в стеке TCP/IP. Протокол ICMP позволяет маршрутизатору сообщать конечной станции об ошибках или нештатных ситуациях, с которыми он столк­нулся при передаче IP-дейтаграммы от этой станции. Тем не менее, протокол должен рассматриваться в качестве неотъемлемой части протокола IP и должен включаться в каждую его реализацию.

Сообщения ICMP передаются по сети в поле данных IP-дейтаграммы. Конечным получателем сообщений ICMP является модуль ICMP, входящий в состав программного обеспечения поддержки IP. Если ICMP определит, что ошибка была вызвана протоколом более высокого уровня или прикладной про­граммой, он сообщит об этом соответствующему модулю, который связан с ис­точником возникновения ошибки.

Протокол ICMP посылает два вида сообщений: управляющие сообщения и сообщения об ошибках. Эти сообщения могут быть посланы как на другие мар­шрутизаторы, так и на конечные станции. Протокол ICMP позволяет драйверам IP на разных устройствах обмениваться друг с другом управляющими и инфор­мационными сообщениями.

Протокол ICMP служит для сообщения об ошибках, но не для исправления ошибок. Отправитель сам должен определить источник ошибки и предпринять меры к устранению ошибок. При этом протокол ICMP не может использоваться для передачи сообщений об ошибках промежуточным устройствам. Это связано с тем, что IP-дейтаграмма содержит поля адреса отправителя и получателя не включает адресную информацию о промежуточных устройствах на маршруте движения по сети. Поэтому, когда IP-дейтаграмма приходит к одному из промежуточных маршрутизаторов, нельзя узнать, какой путь она прошла. Если маршрутизатор обнаружит ошибки, он не сможет узнать, какие промежуточные устройства обрабатывали эту IP-дейтаграмму, и поэтому не сможет сформировать сообщение об ошибке для передачи его промежуточным устройствам. Однако дейтаграмма не будет просто уничтожена. Маршрутизатор, используя протокол 1СМР, отошлет сообщение об ошибке отправителю для принятия обходимых мер по ее устранению.

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

Сообщения ICMP требуют двух уровней инкапсуляции. На рис. 6.9 показана схема инкапсуляции сообщений ICMP в IP-дейтаграмму.

Сообщения ICMP начинаются с трех одинаковых полей:

q «Тип»,

q «Код»,

q «Контрольная сумма».

Кроме того, сообщения ICMP всегда включают заголовок и первые 64 бита данных дейтаграммы, вызвавшей ошибку. Это делается для более точного определения источника ошибок, так как у всех протоколов высокого уровня с TCP/IP критическая информация закодирована как раз в первых 64 битах.

Поле «Тип» (длиной 8 байт) определяет смысл сообщения и его формат (табл. 6.5).

Сообщения «Ответ на эхо» и «Запрос эха» (типы 0, 8) помогают сетевым администраторам и пользователям идентифицировать возникающие в проблемы. Эти сообщения очень часто используются при отладке сети. За эха и ответ на него применяются для проверки достижимости получателя дейтаграммы и его способности отвечать на запросы. Так как эхо переда в IP-дейтаграммах, то успешный прием ответа свидетельствует о том, что основные части транспортной системы работоспособны, то есть: маршрутизация выполняется, все промежуточные маршрутизаторы функционируют, получа­тель активен и работает корректно, программное обеспечение протоколов IP и ICMP выполняет свои функции. Во многих системах программа, которую пользо­ватели используют для запроса эха, называется ping. На рис. 6.10 показан при­мер работы программы ping, входящей в стек протоколов Microsoft TCP/IP.

Таблица 6.5. Значения поля «Тип»

На рис. 6.11 показан формат сообщений запроса эха и ответа на него.

С:\ping ds.internic.net

Pinging ds.internic.net [192.20.239.132] with 32 bytes of data:

Reply from 192.20.239.132: bytes=32 time=101ms TTL=243

Reply from 192.20.239.132: bytes=32 time=100ms TTL=243

Reply from 192.20.239.132: bytes=32 time=120ms TTL=243

Reply from 192.20.239.132: bytes=32 time=120ms TTL=243

Рис. 6.10. Пример работы программы ping

Рис. 6.11. Формат сообщения запроса эха и ответа на него

Поле «Необязательные данные» имеет переменную длину и содержит данные, которые необходимо вернуть отправителю. Поля «Идентификатор» и «Номер» используются отправителем для проверки соответствия между запросом и отве­том. Поле «Тип» определяет, является ли сообщение запросом (8) или ответом (0).

Сообщение «Получатель недостижим» (тип 3) посылается маршрутизатором, если он не может доставить IP-дейтаграмму по назначению. На рис. 6.12 пока­зан формат этого сообщения.

Рис. 6.12. Формат сообщения «Получатель недостижим»

Это сообщение содержит поле «Код», которое показывает, почему IP-дейта­грамму не удается доставить получателю (табл. 6.6).

Таблица 6.6. Причины невозможности доставки (поле «Код»)

Получатель дейтаграммы может быть недостижим по следующим причинам:

q оборудование временно неработоспособно,

q указан несуществующий адрес получателя,

q маршрутизатор не имеет маршрута передачи,

q сеть недостижима из-за чрезмерной удаленности и т. д.

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

Сообщение о подавлении источника (тип 4) требует от источника уменьше­ния скорости передачи дейтаграмм. Если дейтаграммы приходят на маршрути­затор быстрее, чем он успевает их обрабатывать, он временно ставит их в очередь (помещает в буфер). При полном заполнении буфера маршрутизатор будет вынужден удалять прибывающие дейтаграммы. В этом случае маршрути­затор посылает сообщение ICMP о подавлении источника. Сообщения посылаются при каждом удалении дейтаграммы. Отправитель дейтаграмм будет снижать скорость передачи до тех пор, пока к нему не перестанут поступать данные со­общения. На рис. 6.13 показан формат сообщений о подавлении источника.

Рис. 6.13. Формат сообщения «Подавление источника»

Сообщение ICMP об изменении маршрута (тип 5) посылается маршрутиза­тором в том случае, если отправитель дейтаграмм использует неоптимальный маршрут к получателю или при изменении топологии сети. При этом изменения в топологии могут быть постоянными (например, при добавлении новой подсе­ти) или временными (например, при ремонте оборудования). Маршрутизатор также возвращает отправителю исходную дейтаграмму. Этот механизм позволя­ет отправителю не знать в начале работы ничего, кроме адреса одного маршру­тизатора в сети. Этот маршрутизатор будет возвращать сообщение ICMP об изменении маршрута всякий раз, когда будет обнаружен более оптимальный путь к получателю. Эти данные заносятся в таблицу маршрутизации отправи­теля. Сообщения об изменении маршрута используются при взаимодействии между маршрутизатором и отправителем дейтаграмм в одной физической сети. На рис. 6.14 показан формат сообщения об изменении маршрута.

Рис. 6.14. Формат сообщения «Изменение маршрута»

Каждое сообщение содержит 32-битовое поле «IP-адрес рекомендуемого маршрутизатора». Это поле содержит адрес маршрутизатора, который впредь должен использовать отправитель при отправке дейтаграмм по исходному IP-ад­ресу. Поле «IP-заголовок и первые 64 бита исходной дейтаграммы» содержит заголовок IP и первые 64 бита дейтаграммы, которая вызвала сообщение ICMP. Отправитель из этой дейтаграммы выделяет адрес устройства, которое либо на­ходится на неоптимальном маршруте, либо временно не работает. Поле «Код» в сообщении об изменении маршрута указывает более конкретную причину, кото­рая привела к появлению этого сообщения (табл. 6.7). Например, код 0 означает недоступность участка сети, код 1 — недоступность устройства, коды 2 и 3 — невозможность предоставления сервиса и т. д.

Таблица 6.7. Поле «Код» в сообщениях «Изменение маршрута»

Сообщение ICMP «Время жизни дейтаграммы истекло» (тип 11) посылается отправителю при обнулении счетчика времени жизни дейтаграммы или при пре­вышении времени ожидания формирования фрагментов дейтаграммы. Такие со­общения возникают при слишком длинном пути до получателя дейтаграммы, когда времени жизни дейтаграммы не хватает для прохождения всего пути. На рис. 6.15 показан формат сообщения о превышении времени.

Рис. 6.15. Формат сообщения «Время жизни дейтаграммы истекло»

Поле «Код» объясняет причину возникновения сообщения (табл. 6.8).

Таблица 6.8. Поле «Код» в сообщениях «Время жизни дейтаграммы истекло»

Сообщение ICMP «Ошибка параметра» (тип 12) посылается маршрутизато­ром при обнаружении неправильного параметра в заголовке, что не позволяет завершить обработку дейтаграммы. При этом дейтаграмма уничтожается. Одной из причин возникновения этих сообщений могут быть неправильные аргументы в поле «Опции» заголовка IP-дейтаграммы. Сообщение посылается только в том случае, если ошибка приводит к ликвидации дейтаграммы. На рис. 6.16 показан формат сообщения «Ошибка параметра».

Поле «Указатель» необходимо для идентификации ошибочного байта в дей­таграмме.

Сообщения ICMP «Запрос временной метки» (тип 13) и «Передача времен­ной метки» (тип 14) необходимы для синхронизации часов в распределенной системе. Стек протоколов TCP/IP включает несколько протоколов, которые ис­пользуются для синхронизации часов. Протокол ICMP предоставляет самый простой способ. Одно из устройств в сети посылает сообщение «Запрос временной метки» и ждет, пока другое устройство вернет в ответ текущее значение времени. На рис. 6.17 показан формат сообщений временных меток.

Рис. 6.16. Формат сообщения «Ошибка параметра»

Рис. 6.17. Формат сообщений запроса и передачи временной метки

Поле «Тип» идентифицирует сообщение как запрос (13) или ответ (14). Поля «Идентификатор» и «Номер» используются источником для установления связи между ответами и запросами. Поле «Временная метка отправителя» — это время, которое зафиксировал отправитель непосредственно перед посылкой со­общения. Поле «Временная метка приема» содержит время, когда исходное со­общение дошло до получателя. Поле «Временная метка передачи» хранит время, когда получатель ответил на сообщение. Временные метки имеют размер 32 бита; в них записано время в миллисекундах, прошедшее после полуночи по Гринвичу. Получив эти метки, отправитель может вычислить время передачи по сети и разницу между своими часами и удаленными и выполнить синхрониза­цию своих часов. На практике бывает трудно точно оценить время передачи по сети. Поэтому для получения точной оценки потребуется выполнить множество измерений и усреднить их. Сообщение «Запрос маски адреса» (тип 17) необхо­димо для интерпретации адреса, а именно, для определения того, какие биты 32-битного IP-адреса соответствуют номеру сети, а какие — номеру устройства в ети. В ответ на сообщение передается 32-битная величина, называемая маской подсети. Ответ передается через сообщение «Передача маски адреса» (тип 18). Запрос может посылаться напрямую, если известен адрес маршрутизатора, или широковещательно. На рис. 6.18 показан формат сообщений запроса маски ад­реса и ответа на него.

Рис. 6.18. Формат сообшений запроса и передачи маски адреса

Поле «Тип» в сообщении указывает, является ли сообщение запросом (17) или ответом (18). В поле «Маска адреса» помещается ответ на запрос.

Протокол UDP

Протокол пользовательских дейтаграмм (User Datagram Protocol, UDP) описан в документе RFC 768. Протокол разработан для предоставления прикладным программам транспортных услуг. UDP, так же, как и IP, обеспечивает негаранти­рованную доставку дейтаграмм получателю и не поддерживает установку соеди­нений. В модели стека TCP/IP он располагается над протоколом IP.

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

Назначение портов происходит при участии сетевой операционной системы. Большинство операционных систем обеспечивают параллельный доступ к про­токольным портам. Протокольный порт идентифицируется целым положитель­ным числом. Для связи с протокольным портом на другой рабочей станции, отправитель должен знать IP-адрес получателя и номер порта на этой рабочей станции. Каждое сообщение содержит также номер протокольного порта отправ­ляющей рабочей станции. Таким образом прикладная программа, получающая сообщения, может напрямую ответить отправителю.

В стеке протоколов TCP/IP протокол UDP обеспечивает транспортный ме­ханизм, используемый прикладными программами для передачи дейтаграмм другим приложениям. Протокол UDP предоставляет протокольные порты, ис­пользуемые для раздельной работы нескольких приложений, выполняющихся на одной рабочей станции. При этом приложения, использующие транспорт про­токола UDP, должны сами обеспечивать надежность передачи сообщений. Каж­дое сообщение протокола UDP называется пользовательской дейтаграммой. Она состоит из двух частей: заголовка и области данных. Заголовок содержит четыре 16-битных поля, которые определяют протокольный порт отправителя, прото­кольный порт получателя, длину сообщения и контрольную сумму (рис. 6.19).

Поля «Порт отправителя» и «Порт получателя» содержат 16-битные номера портов. Поле «Порт отправителя» может не использоваться, тогда оно должно содержать нули. Поле «Длина сообщения» указывает количество байтов в поль­зовательской дейтаграмме. При этом учитывается длина заголовка протокола UDP и длина поля данных.

Контрольная сумма пользовательской дейтаграммы может вычисляться, а может и не вычисляться. Нулевое поле «Контрольная сумма» означает, что кон­трольная сумма не вычислялась. Контрольная сумма, как правило, не вычисля­ется при работе протокола UDP в высоконадежной локальной сети. Однако в ненадежной сети только контрольная сумма может указать на достоверность и целостность пришедших данных — ведь протокол IP не вычисляет контрольную сумму поля данных IP-дейтаграмм. Для расчета контрольной суммы пользова­тельской дейтаграммы необходима дополнительная информация. Для этой цели к началу пользовательской дейтаграммы приписывают псевдозаголовок и добав­ляют в конец этой дейтаграммы байт, заполненный нулями, так, чтобы число бит во всем сообщении было кратно 16. После этого вычисляется контрольная сумма полученной дейтаграммы. Концевое дополнение из нулей и псевдозаголо­вок не передаются вместе с пользовательской дейтаграммой. Для вычисления контрольной суммы полученной пользовательской дейтаграммы сначала сохра­няется ноль в поле «Контрольная сумма», затем вычисляется 16-битная сумма, включая псевдозаголовок, заголовок самой дейтаграммы и данных. При получе­нии пользовательской дейтаграммы контрольная сумма должна проверяться. При этом используется IP-адрес назначения, полученный из заголовка IP-дей­таграммы, которая содержала пользовательскую дейтаграмму протокола UDP. Если контрольные суммы одинаковы, то пользовательская дейтаграмма действи­тельно достигла нужного получателя и нужный протокольный порт на станции получателя. На рис. 6.20 показан формат псевдозаголовка.

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

Это означает, что только IP-заголовок определяет отправителя и получателя, а заголовок пользовательской дейтаграммы протокола UDP определяет прото­кольные порты приложений.

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

Порт UDP можно представить в виде очереди. Операционная система созда­ет внутреннюю очередь, которая хранит приходящие сообщения. Если поступи­ло сообщение с номером протокольного порта, которого нет среди используемых протокольных портов, оно удаляется и высылается сообщение протокола ICMP «Получатель недостижим» с кодом «Порт недостижим».

Некоторые номера протокольных портов стандартизированы. Эти номера вы­деляет центральный орган — организация IANA (Internet Assigned Numbers Aut­hority). Она регулярно публикует список назначений. Эти протокольные порты зарезервированы и их использование контролируется IANA. В большинстве сис­тем они могут использоваться только системными процессами или программа­ми, выполняемыми привилегированными пользователями. Несколько лет назад эти протокольные порты использовали диапазон номеров от 0 до 255. Однако недавно IANA расширила этот диапазон — теперь она отвечает за назначение портов с номерами от 0 до 1023.

Остальные порты могут назначаться динамически. Сетевое программное обеспечение назначает протокольный порт, когда программа в нем нуждается. Такие протокольные порты не контролируются IANA и могут свободно исполь­зоваться пользовательскими процессами. Номера этих протокольных портов лежат в диапазоне от 1024 до 65 535. Протокольные порты в диапазоне от 1024 до 5000 называются временными (ephemeral). Хотя IANA не контролирует использование этих протокольных портов, она поддерживает информацию о них в интересах сообщества пользователей Internet.

Для получения информации о текущем назначении протокольных портов не­обходимо послать соответствующий запрос.

Протокол RTP

Требование поддержки нескольких типов трафика с различными требованиями к качеству обслуживания на базе стека протоколов TCP/IP сейчас весьма акту­ально. Эту задачу призван решить транспортный протокол реального времени (Real-Time Transport Protocol, RTP), который является стандартом IETF для передачи таких данных, как голос или видео, в реальном времени по сети, не гарантирующей качества обслуживания.

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