Параметры протокола rfc 2068


Содержание

Протокол HTTP

Протокол HTTP используется в World Wide Web (WWW) начиная с 1990 года. Его версия описана 1.0 в RFC 1945, версия 1.1 в RFC 2068/

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

Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию — 80)., и, не дожидаясь никакой реакции от сервера, посылает запрос, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например:

В примере используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html с виртуального сервера www.example.com.

Послав запрос и заголовки, клиент может отправить дополнительные данные. Эти данные используются главным с методом POST для передачи .

Сервер отвечает на запрос клиента следующим образом:

Первая часть строка ответа сервера — строка состояния, содержащая три поля: версию HTTP, числовой код ответа и текстовое описание этого кода.

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

HTTP не сохраняет информацию по транзакциям, каждая пара запрос-ответ проводится независимо, даже в рамках одного TCP соединения.

Методы

Метод — это HTTP-команда, с которой начинается первая строка запроса клиента.Реально используются GET, HEAD и POST. При задании имен методов учитывается регистр, поэтому GET и get различаются.

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

Метод GET

GET — это запрос к серверу, который ничего не изменяет на сервере, например, выполняет считывание записи из БД.

В URL кодируются параметры запроса. Сначала идут позиционные параметры, разделенные знаком ‘/’, а затем, после символа ‘&’ — именованные в виде пар ключ-значение. Пары отделяются друг от друга амперсандом ‘&’. Например:

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

Хотя позиционные параметры могут выглядеть, как имена каталогов и файлов, реальная интерпретация зависит от реализации на стороне сервера. Например, следующая запись может означать запуск скрипта /cgi-bin/display.pl для вывода файла /text/doc.txt (а может и не означать):

Метод POST

Метод POST это запрос к серверу, который изменяет состояние сервера, например вносит запись в БД.

Параметры запроса в методе POST могут передаваться в теле запроса. В этом случае их общая длина ничем не ограничена.

Метод HEAD

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Этот метод используется, когда клиент хочет получить информацию о документе, не получая его. Например, клиента может интересовать:

  • время изменения документа;
  • размер документа;
  • тип документа;
  • тип сервера.

Некоторые заголовки не являются обязательными и могут отсутствовать в ответе сервера.

Авторизация

Если ресурс требует авторизации пользователя, то сервер в ответ на запрос может вернуть код ответа 401 Unauthorized и строку заголовка с указанием области доступа для которой требуется авторизация

Чтобы получить права доступа, клиент посылает в последующих запросах идентификатор пользователя и пароль, разделенные символом двоеточия «:». Строка авторизации кодируется в base64.

В реальной жизни используется тип авторизации Basic и NTLM.

Заголовки запроса

В запросе клиент должен передать URI запрашиваемого документа. Это может быть сделано в абсолютной или относительной форме. В первом случае в состав URI должны входить название протокола и имя сервера.

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

В этом случае имя и порт хоста, может быть передано в строке заголовка Host:

Наличие имени хоста необходимо для обращений к прокси-серверу, или для обращения к одному из виртуальных хостов размещенных на одном сервере. Если хост, заданный одним из двух способов, не существует, то сервер возвращает ответ 400- Bad Request.

Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Передача данных в ответе сервера

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

Content-Type: Тип сообщения, аналогичен типу содержимого в стандарте MIME и указывается в формате тип/подтип.

Серверы используют типы сообщения в заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое

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

Content-Encoding: Для 8 битового протокола HTTP, данный заголовок означает, что данные дополнительно закодированы, например сжаты. Определены три типа кодирования gzip, compress, deflate, что соответствует форматам программ gzip, compress и библиотеки zlib. Например:

Большое значение в реализации протокола HTTP имеет уведомление клиента о размере данных в теле ответа, т.к. в силу 8 битовости протокола тело ответа не может сопровождаться каким либо ограничителем.

Content-Length: Длина тела сообщения. В протоколе HTTP/1.0 это была единственная возможность передать клиенту информацию о размере данных.

Кодирование данных кусками (chunced) было введено в HTTP/1.1. В заголовках ответа должна присутствовать строка

А тело сообщения строится по следующим правилам

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

Следует отметить, что символы в конце куска, не являются его частью. Подобное кодирование очень удобно в тех случаях, когда размер данных заранее неизвестен, и достаточно велик.

Еще одной возможностью для кодирования данных является использование для тела сообщения типа multipart/bytranges – эквивалентного MIME multipart/*

Если размер сообщения не указан, не используется кодирование кусками и тип тела сообщения не multipart/bytranges, то клиент определяет конец тела ответа по закрытию TCP соединения.

3 пАРАМЕТРЫ ПРОТОКОЛА.

3.1 вЕРСИЯ HTTP.

HTTP ИСПОЛЬЗУЕТ СХЕМУ НУМЕРАЦИИ ТИПА » . «, ДЛЯ УКАЗАНИЯ ВЕРСИИ ПРОТОКОЛА. сТРАТЕГИЯ ВЕРСИФИКАЦИИ ПРОТОКОЛА ПРЕДНАЗНАЧЕНА ДЛЯ ТОГО, ЧТОБЫ ПОЗВОЛИТЬ ОТПРАВИТЕЛЮ УКАЗАТЬ ФОРМАТ СООБЩЕНИЯ И СВОИ СПОСОБНОСТИ ПОНИМАНИЯ ДЛЯ ДАЛЬНЕЙШЕЙ HTTP СВЯЗИ, ПРЕЖДЕ ЧЕМ ОН ПОЛУЧИТ ЧТО-ЛИБО ПОСРЕДСТВОМ ЭТОЙ СВЯЗИ. пРИ ДОБАВЛЕНИИ КОМПОНЕНТОВ СООБЩЕНИЯ, КОТОРЫЕ НЕ ВОЗДЕЙСТВУЮТ НА ПОВЕДЕНИЕ СВЯЗИ, ИЛИ КОМПОНЕНТОВ, КОТОРЫЕ ДОБАВЛЯЮТСЯ ТОЛЬКО К РАСШИРЯЕМЫМ ЗНАЧЕНИЯМ ПОЛЯ, НОМЕР ВЕРСИИ НЕ МЕНЯЕТСЯ. кОГДА ВНЕСЕННЫЕ В ПРОТОКОЛ ИЗМЕНЕНИЯ ДОБАВЛЯЮТ ВОЗМОЖНОСТИ, КОТОРЫЕ НЕ ИЗМЕНЯЮТ ОБЩИЙ АЛГОРИТМ АНАЛИЗА СООБЩЕНИЙ, НО КОТОРЫЕ РАСШИРЯЮТ СЕМАНТИКУ СООБЩЕНИЯ И ПОДРАЗУМЕВАЮТ ДОПОЛНИТЕЛЬНЫЕ ВОЗМОЖНОСТИ ОТПРАВИТЕЛЯ, УВЕЛИЧИВАЕТСЯ НОМЕР. кОГДА ФОРМАТ СООБЩЕНИЯ ПРОТОКОЛА ИЗМЕНЯЕТСЯ УВЕЛИЧИВАЕТСЯ НОМЕР.

вЕРСИЯ HTTP СООБЩЕНИЯ ОБОЗНАЧАЕТСЯ ПОЛЕМ HTTP-version В ПЕРВОЙ СТРОКЕ СООБЩЕНИЯ.

оБРАТИТЕ ВНИМАНИЕ, ЧТО major И minor ЧИСЛА должны ОБРАБАТЫВАТЬСЯ КАК ОТДЕЛЬНЫЕ ЦЕЛЫЕ ЧИСЛА И ЧТО КАЖДОЕ МОЖЕТ СОСТОЯТЬ БОЛЕЕ ЧЕМ ИЗ ОДНОЙ ЦИФРЫ. тАКИМ ОБРАЗОМ, HTTP/2.4 — БОЛЕЕ НИЗКАЯ ВЕРСИЯ, ЧЕМ HTTP/2.13, КОТОРАЯ В СВОЮ ОЧЕРЕДЬ НИЖЕ ЧЕМ HTTP/12.3. нУЛИ должны ИГНОРИРОВАТЬСЯ ПОЛУЧАТЕЛЯМИ И не должны ПОСЫЛАТЬСЯ.

пРИЛОЖЕНИЯ, ПОСЫЛАЮЩИЕ СООБЩЕНИЯ ЗАПРОСОВ ИЛИ ОТВЕТОВ, КОТОРЫЕ ОПИСЫВАЕТ ЭТА СПЕЦИФИКАЦИЯ, должны ВКЛЮЧИТЬ HTTP ВЕРСИЮ (HTTP-version) «HTTP/1.1». иСПОЛЬЗОВАНИЕ ЭТОГО НОМЕРА ВЕРСИИ УКАЗЫВАЕТ, ЧТО ПОСЫЛАЮЩЕЕ ПРИЛОЖЕНИЕ ПО КРАЙНЕЙ МЕРЕ УСЛОВНО СОВМЕСТИМО С ЭТОЙ СПЕЦИФИКАЦИЕЙ.

HTTP ВЕРСИЯ ПРИЛОЖЕНИЯ — ЭТО САМАЯ ВЫСОКАЯ HTTP ВЕРСИЯ, ДЛЯ КОТОРОЙ ПРИЛОЖЕНИЕ ЯВЛЯЕТСЯ ПО КРАЙНЕЙ МЕРЕ УСЛОВНО СОВМЕСТИМЫМ.

пРИЛОЖЕНИЯ, РЕАЛИЗУЮЩИЕ ПРОКСИ-СЕРВЕРА И ШЛЮЗЫ, ДОЛЖНЫ БЫТЬ ВНИМАТЕЛЬНЫ, КОГДА ПЕРЕСЫЛАЮТ СООБЩЕНИЯ ПРОТОКОЛА РАЗЛИЧНЫХ ВЕРСИЙ. нАЧИНАЯ С МОМЕНТА, КОГДА ВЕРСИЯ ПРОТОКОЛА УКАЗЫВАЕТ ВОЗМОЖНОСТИ ОТПРАВИТЕЛЯ, ПРОКСИ-СЕРВЕР/ШЛЮЗ НИКОГДА не должен ПОСЫЛАТЬ СООБЩЕНИЯ, ВЕРСИЯ КОТОРЫХ БОЛЬШЕ, ЧЕМ HTTP ВЕРСИЯ ОТПРАВИТЕЛЯ; ЕСЛИ ПОЛУЧЕНА БОЛЕЕ ВЫСОКАЯ ВЕРСИЯ ЗАПРОСА, ТО ПРОКСИ-СЕРВЕР/ШЛЮЗ должен ИЛИ ПОНИЗИТЬ ВЕРСИЮ ЗАПРОСА, ОТДАВ СООБЩЕНИЕ ОБ ОШИБКЕ, ИЛИ ПЕРЕКЛЮЧИТЬСЯ НА ТУННЕЛЬНОЕ ПОВЕДЕНИЕ. у ЗАПРОСОВ, ВЕРСИЯ КОТОРЫХ НИЖЕ, ЧЕМ HTTP ВЕРСИЯ ПРОКСИ-СЕРВЕРА/ШЛЮЗА можно ПЕРЕД ПЕРЕСЫЛКОЙ УВЕЛИЧИТЬ ВЕРСИЮ; ОТВЕТ ПРОКСИ-СЕРВЕРА/ШЛЮЗА НА ЭТОТ ЗАПРОС должен ИМЕТЬ ТУ ЖЕ САМУЮ major ВЕРСИЮ, ЧТО И ЗАПРОС.

оБРАТИТЕ ВНИМАНИЕ: пРЕОБРАЗОВАНИЕ ВЕРСИЙ HTTP МОЖЕТ ВКЛЮЧАТЬ МОДИФИКАЦИЮ ПОЛЕЙ ЗАГОЛОВКА, ТРЕБУЕМЫХ ИЛИ ЗАПРЕЩЕННЫХ В ЭТИХ ВЕРСИЯХ.

3.2 уНИВЕРСАЛЬНЫЕ иДЕНТИФИКАТОРЫ рЕСУРСОВ (URI).

URI ИЗВЕСТНЫ ПОД МНОГИМИ ИМЕНАМИ: WWW АДРЕСА, уНИВЕРСАЛЬНЫЕ иДЕНТИФИКАТОРЫ дОКУМЕНТОВ, уНИВЕРСАЛЬНЫЕ иДЕНТИФИКАТОРЫ рЕСУРСОВ (URI), И, В ЗАКЛЮЧЕНИЕ, КАК КОМБИНАЦИЯ еДИНООБРАЗНЫХ иДЕНТИФИКАТОРОВ рЕСУРСА (Uniform Resource Locators, URL) И еДИНООБРАЗНЫХ иМЕН рЕСУРСА (Uniform Resource Names, URN). HTTP ОПРЕДЕЛЯЕТ URL ПРОСТО КАК СТРОКУ ОПРЕДЕЛЕННОГО ФОРМАТА, КОТОРАЯ ИДЕНТИФИЦИРУЕТ — ЧЕРЕЗ ИМЯ, РАСПОЛОЖЕНИЕ, ИЛИ ЛЮБУЮ ДРУГУЮ ХАРАКТЕРИСТИКУ — РЕСУРС.

3.2.1 оБЩИЙ СИНТАКСИС.

URI В HTTP МОГУТ ПРЕДСТАВЛЯТЬСЯ В АБСОЛЮТНОЙ (absolute) ФОРМЕ ИЛИ ОТНОСИТЕЛЬНО НЕКОТОРОЙ ИЗВЕСТНОЙ ОСНОВЫ URI (relative), В ЗАВИСИМОСТИ ОТ КОНТЕКСТА ИХ ИСПОЛЬЗОВАНИЯ. эТИ ДВЕ ФОРМЫ РАЗЛИЧАЮТСЯ ТЕМ, ЧТО АБСОЛЮТНЫЕ URI ВСЕГДА НАЧИНАЮТСЯ С ИМЕНИ СХЕМЫ С ДВОЕТОЧИЕМ.

пОЛНУЮ ИНФОРМАЦИЮ ОТНОСИТЕЛЬНО СИНТАКСИСА И СЕМАНТИКИ URL СМОТРИТЕ RFC 1738 [4] и RFC 1808 [11]. вЫШЕУКАЗАННАЯ НОРМАЛЬНАЯ ЗАПИСЬ бЕКУСА-нАУРА ВКЛЮЧАЕТ НАЦИОНАЛЬНЫЕ СИМВОЛЫ, НЕДОЗВОЛЕННЫЕ В ДОПУСТИМЫХ URL (ЭТО ОПРЕДЕЛЕНО В RFC 1738), ТАК КАК HTTP СЕРВЕРЫ ПОЗВОЛЯЮТ ИСПОЛЬЗОВАТЬ ДЛЯ ПРЕДСТАВЛЕНИЯ ЧАСТИ rel_path АДРЕСОВ НАБОР НЕЗАРЕЗЕРВИРОВАННЫХ СИМВОЛОВ, И, СЛЕДОВАТЕЛЬНО, HTTP ПРОКСИ-СЕРВЕРА МОГУТ ПОЛУЧАТЬ ЗАПРОСЫ URI, НЕ СООТВЕТСТВУЮЩИЕ RFC 1738.

пРОТОКОЛ HTTP НЕ НАКЛАДЫВАЕТ a priori НИКАКИХ ОГРАНИЧЕНИЙ НА ДЛИНЫ URI. сЕРВЕРЫ должны БЫТЬ СПОСОБНЫ ОБРАБОТАТЬ URI ЛЮБОГО РЕСУРСА, КОТОРЫЙ ОНИ ОБСЛУЖИВАЮТ, И ИМ следует БЫТЬ В СОСТОЯНИИ ОБРАБАТЫВАТЬ URI НЕОГРАНИЧЕННОЙ ДЛИНЫ, ЕСЛИ ОНИ ОБСЛУЖИВАЮТ ФОРМЫ, ОСНОВАННЫЕ НА МЕТОДЕ GET, КОТОРЫЕ МОГУТ ГЕНЕРИРОВАТЬ ТАКОЙ URI. сЕРВЕРУ следует ВОЗВРАЩАТЬ КОД СОСТОЯНИЯ 414 (URI ЗАПРОСА СЛИШКОМ ДЛИННЫЙ, Request-URI Too Long), ЕСЛИ URI БОЛЬШЕ, ЧЕМ СЕРВЕР МОЖЕТ ОБРАБОТАТЬ (СМОТРИТЕ РАЗДЕЛ 10.4.15).

оБРАТИТЕ ВНИМАНИЕ: сЕРВЕРЫ ДОЛЖНЫ БЫТЬ ОСТОРОЖНЫ С URI, КОТОРЫЕ ИМЕЮТ ДЛИНУ БОЛЕЕ 255 БАЙТОВ, ПОТОМУ ЧТО НЕКОТОРЫЕ СТАРЫЕ КЛИЕНТЫ ИЛИ ПРОКСИ-СЕРВЕРА НЕ МОГУТ ПРАВИЛЬНО ПОДДЕРЖИВАТЬ ЭТИ ДЛИНЫ.

3.2.2 HTTP URL.

«Http» СХЕМА ИСПОЛЬЗУЕТСЯ ДЛЯ ДОСТУПА К СЕТЕВЫМ РЕСУРСАМ ПРИ ПОМОЩИ ПРОТОКОЛА HTTP. эТОТ РАЗДЕЛ ОПРЕДЕЛЯЕТ СХЕМО-ОПРЕДЕЛЕННЫЙ СИНТАКСИС И СЕМАНТИКУ ДЛЯ HTTP URL.

еСЛИ ПОРТ ПУСТ ИЛИ НЕ ЗАДАН — ИСПОЛЬЗУЕТСЯ ПОРТ 80. эТО ОЗНАЧАЕТ, ЧТО ИДЕНТИФИЦИРОВАННЫЙ РЕСУРС РАЗМЕЩЕН В СЕРВЕРЕ, ОЖИДАЮЩЕМ TCP СОЕДИНЕНИЙ НА СПЕЦИФИЦИРОВАННОМ ПОРТЕ port, КОМПЬЮТЕРА host, И ЗАПРАШИВАЕМЫЙ URI РЕСУРСА — abs_path. иСПОЛЬЗОВАНИЯ IP АДРЕСОВ В URL следует ИЗБЕГАТЬ, КОГДА ЭТО ВОЗМОЖНО (СМОТРИТЕ RFC 1900 [24]). еСЛИ abs_path НЕ ПРЕДСТАВЛЕН В URL, ОН должен РАССМАТРИВАТЬСЯ КАК «/» ПРИ ВЫЧИСЛЕНИИ ЗАПРАШИВАЕМОГО URI (Request-URI) РЕСУРСА (РАЗДЕЛ 5.1.2).

3.2.3 сРАВНЕНИЕ URI.

пРИ СРАВНЕНИИ ДВУХ URI, ЧТОБЫ РЕШИТЬ СООТВЕТСТВУЮТ ЛИ ОНИ ДРУГ ДРУГУ ИЛИ НЕТ, КЛИЕНТУ следует ИСПОЛЬЗОВАТЬ ЧУВСТВИТЕЛЬНОЕ К РЕГИСТРУ ПООКТЕТНОЕ (octet-by-octet) СРАВНЕНИЕ ЭТИХ URI, СО СЛЕДУЮЩИМИ ИСКЛЮЧЕНИЯМИ:

  • пОРТ, КОТОРЫЙ ПУСТ ИЛИ НЕ УКАЗАН, ЭКВИВАЛЕНТЕН ЗАДАННОМУ ПО УМОЛЧАНИЮ ПОРТУ ДЛЯ ЭТОГО URI;
  • сРАВНЕНИЕ ИМЕН ХОСТОВ должно ПРОИЗВОДИТЬСЯ БЕЗ УЧЕТА РЕГИСТРА;
  • сРАВНЕНИЕ ИМЕН СХЕМ должно ПРОИЗВОДИТЬСЯ БЕЗ УЧЕТА РЕГИСТРА;
  • пУСТОЙ abs_path ЭКВИВАЛЕНТЕН «/».

сИМВОЛЫ, ОТЛИЧНЫЕ ОТ ТЕХ, ЧТО НАХОДЯТСЯ В «ЗАРЕЗЕРВИРОВАННЫХ» («reserved») И «ОПАСНЫХ» («unsafe») НАБОРАХ (СМ. РАЗДЕЛ 3.2) ЭКВИВАЛЕНТНЫ ИХ КОДИРОВАНИЮ КАК «»%» HEX HEX «.

нАПРИМЕР СЛЕДУЮЩИЕ ТРИ URI ЭКВИВАЛЕНТНЫ:

3.3 фОРМАТЫ ДАТЫ/ВРЕМЕНИ.

3.3.1 пОЛНАЯ ДАТА.

HTTP ПРИЛОЖЕНИЯ ИСТОРИЧЕСКИ ДОПУСКАЛИ ТРИ РАЗЛИЧНЫХ ФОРМАТА ДЛЯ ПРЕДСТАВЛЕНИЯ ДАТЫ/ВРЕМЕНИ:

пЕРВЫЙ ФОРМАТ ВЫБРАН В КАЧЕСТВЕ СТАНДАРТА иНТЕРНЕТА И ПРЕДСТАВЛЯЕТ ПОДМНОЖЕСТВО ФИКСИРОВАННОЙ ДЛИНЫ, КАК ОПРЕДЕЛЕНО В RFC 1123 (МОДИФИЦИРОВАННОМ RFC 822). вТОРОЙ ФОРМАТ НАХОДИТСЯ В ОБЩЕМ ПОЛЬЗОВАНИИ, НО ОСНОВАН НА УСТАРЕВШЕМ И ПОТЕРЯВШЕМ СТАТУС СТАНДАРТА RFC 850 [12], ОПИСЫВАЮЩЕМ ФОРМАТЫ ДАТ, ОН ОБЛАДАЕТ ТЕМ НЕДОСТАТКОМ, ЧТО ГОД УКАЗЫВАЕТСЯ НЕ В ЧЕТЫРЕХРАЗРЯДНОЙ НОТАЦИИ. кЛИЕНТЫ И СЕРВЕРЫ HTTP/1.1, КОТОРЫЕ АНАЛИЗИРУЮТ ЗНАЧЕНИЕ ДАТЫ, должны ПОНИМАТЬ ВСЕ ТРИ ФОРМАТА (ДЛЯ СОВМЕСТИМОСТИ С HTTP/1.0), НО ГЕНЕРИРОВАТЬ ДЛЯ ПРЕДСТАВЛЕНИЯ ЗНАЧЕНИЙ ДАТ В ПОЛЯХ ЗАГОЛОВКА HTTP должны ТОЛЬКО ФОРМАТ RFC 1123 .

оБРАТИТЕ ВНИМАНИЕ: пООЩРЯЕТСЯ ПРАКТИКА, ПРИ КОТОРОЙ ПОЛУЧАТЕЛИ ЗНАЧЕНИЙ ДАТ ЗДРАВО ВОСПРИНИМАЮТ ЗНАЧЕНИЯ ДАТ, КОТОРЫЕ, ВОЗМОЖНО, ПОСЛАНЫ НЕ HTTP ПРИЛОЖЕНИЯМИ, ЧТО ИМЕЕТ МЕСТО ПРИ ЗАГРУЗКЕ ИЛИ РЕГИСТРАЦИИ СООБЩЕНИЙ ЧЕРЕЗ ПРОКСИ-СЕРВЕРА/ШЛЮЗЫ К SMTP ИЛИ NNTP.

вСЕ БЕЗ ИСКЛЮЧЕНИЙ ФОРМАТЫ HTTP ДАТЫ/ВРЕМЕНИ должны БЫТЬ ПРЕДСТАВЛЕНЫ В Greenwich Mean Time (GMT). в ПЕРВЫХ ДВУХ ФОРМАТАХ ДАННЫЙ ФАКТ УКАЗЫВАЕТСЯ ВКЛЮЧЕНИЕМ ТРЕХСИМВОЛЬНОГО СОКРАЩЕНИЯ «GMT» В КАЧЕСТВЕ ЧАСОВОГО ПОЯСА. в asctime() ФОРМАТЕ ЭТО должно ПОДРАЗУМЕВАТЬСЯ ПРИ ЧТЕНИИ.

оБРАТИТЕ ВНИМАНИЕ: эТИ ТРЕБОВАНИЯ — ЭТО ТРЕБОВАНИЯ К ДЛЯ ФОРМАТАМ ДАТЫ/ВРЕМЕНИ, КОТОРЫЕ ПРИМЕНЯЮТСЯ ВНУТРИ ПОТОКА ПРОТОКОЛА HTTP. кЛИЕНТАМ И СЕРВЕРАМ НЕ ТРЕБУЕТСЯ ИСПОЛЬЗОВАТЬ ЭТИ ФОРМАТЫ ДЛЯ ПРЕДСТАВЛЕНИЯ ПОЛЬЗОВАТЕЛЮ, РЕГИСТРАЦИИ ЗАПРОСОВ И Т.Д.

3.3.2 рАЗНОСТЬ СЕКУНД (delta seconds).

нЕКОТОРЫЕ ПОЛЯ HTTP ЗАГОЛОВКА ПОЗВОЛЯЮТ УКАЗЫВАТЬ ЗНАЧЕНИЯ ВРЕМЕНИ В ВИДЕ ЦЕЛОГО ЧИСЛА СЕКУНД, ПРЕДСТАВЛЕННОГО В ДЕСЯТИЧНОЙ ФОРМЕ, КОТОРЫЕ ДОЛЖНЫ ПРОЙТИ С ТОГО МОМЕНТА, КАК СООБЩЕНИЕ БЫЛО ПОЛУЧЕНО.

3.4 кОДОВЫЕ ТАБЛИЦЫ (character sets).

HTTP ИСПОЛЬЗУЕТ ТО ЖЕ САМОЕ ОПРЕДЕЛЕНИЕ ТЕРМИНА «КОДОВАЯ ТАБЛИЦА», КОТОРОЕ ОПИСАНО ДЛЯ MIME:

тЕРМИН «КОДОВАЯ ТАБЛИЦА» ИСПОЛЬЗУЕТСЯ В ДАННОМ ДОКУМЕНТЕ, ЧТОБЫ СОСЛАТЬСЯ НА МЕТОД, ИСПОЛЬЗУЮЩИЙ ОДНУ ИЛИ НЕСКОЛЬКО ТАБЛИЦ ДЛЯ ПРЕОБРАЗОВАНИЯ ПОСЛЕДОВАТЕЛЬНОСТИ ОКТЕТОВ В ПОСЛЕДОВАТЕЛЬНОСТЬ СИМВОЛОВ. сТОИТ ОТМЕТИТЬ, ЧТО ОДНОЗНАЧНОЕ ПРЕОБРАЗОВАНИЕ В ОБРАТНОМ НАПРАВЛЕНИИ НЕ ТРЕБУЕТСЯ, И ЧТО НЕ ВСЕ СИМВОЛЫ МОГУТ БЫТЬ ДОСТУПНЫ В ДАННОЙ КОДОВОЙ ТАБЛИЦЕ, И ЧТО КОДОВАЯ ТАБЛИЦА МОЖЕТ ОБЕСПЕЧИВАТЬ БОЛЕЕ ЧЕМ ОДНУ ПОСЛЕДОВАТЕЛЬНОСТЬ ОКТЕТОВ ДЛЯ ПРЕДСТАВЛЕНИЯ СПЕЦИФИЧЕСКИХ СИМВОЛОВ. эТО ОПРЕДЕЛЕНИЕ ДОПУСКАЕТ РАЗЛИЧНЫЕ ВИДЫ КОДИРОВАНИЯ СИМВОЛОВ, ОТ ПРОСТЫХ ОДНОТАБЛИЧНЫХ ОТОБРАЖЕНИЙ ТИПА US-ASCII ДО СЛОЖНЫХ МЕТОДОВ, ПЕРЕКЛЮЧАЮЩИХ ТАБЛИЦЫ, НАПОДОБИЕ ТЕХ, КОТОРЫЕ ИСПОЛЬЗУЮТ МЕТОДИКИ ISO 2022. оДНАКО ОПРЕДЕЛЕНИЕ, СВЯЗАННОЕ С ИМЕНЕМ КОДОВОЙ ТАБЛИЦЫ MIME должно ПОЛНОСТЬЮ ОПРЕДЕЛЯТЬ ОТОБРАЖЕНИЕ, КОТОРОЕ ПРЕОБРАЗУЕТ ОКТЕТЫ В СИМВОЛЫ. в ЧАСТНОСТИ ИСПОЛЬЗОВАНИЕ ВНЕШНЕЙ ИНФОРМАЦИИ ПРОФИЛИРОВАНИЯ ДЛЯ ОПРЕДЕЛЕНИЯ ТОЧНОГО ОТОБРАЖЕНИЯ НЕ РАЗРЕШАЕТСЯ.

оБРАТИТЕ ВНИМАНИЕ: эТО ИСПОЛЬЗОВАНИЕ ТЕРМИНА «КОДОВАЯ ТАБЛИЦА» ОБЫЧНО УПОМИНАЕТСЯ КАК «КОДИРОВАНИЕ СИМВОЛОВ». оДНАКО, С ТЕХ ПОР КАК HTTP И MIME СОВМЕСТНО ИСПОЛЬЗУЮТ ОДИННАКОВУЮ ЗАПИСЬ, ВАЖНО, ЧТОБЫ СОВПАДАЛА ТАКЖЕ И ТЕРМИНОЛОГИЯ.

кОДОВЫЕ ТАБЛИЦЫ HTTP ИДЕНТИФИЦИРУЮТСЯ ЛЕКСЕМАМИ, НЕ ЧУВСТВИТЕЛЬНЫМИ К РЕГИСТРУ. пОЛНЫЙ НАБОР ЛЕКСЕМ ОПРЕДЕЛЕН РЕЕСТРОМ КОДОВЫХ ТАБЛИЦ IANA [19].

хОТЯ HTTP ПОЗВОЛЯЕТ ИСПОЛЬЗОВАТЬ В КАЧЕСТВЕ ЗНАЧЕНИЯ charset ПРОИЗВОЛЬНУЮ ЛЕКСЕМУ, ЛЮБАЯ ЛЕКСЕМА, КОТОРАЯ ИМЕЕТ ПРЕДОПРЕДЕЛЕННОЕ ЗНАЧЕНИЕ В РЕЕСТРЕ КОДОВЫХ ТАБЛИЦ IANA, должна ПРЕДСТАВЛЯТЬ НАБОР СИМВОЛОВ, ОПРЕДЕЛЕННЫЙ В ДАННОМ РЕЕСТРЕ. пРИЛОЖЕНИЯМ следует ОГРАНИЧИТЬ ИСПОЛЬЗОВАНИЕ СИМВОЛЬНЫХ НАБОРОВ ТЕМИ, КОТОРЫЕ ОПРЕДЕЛЕНЫ В РЕЕСТРЕ IANA.

3.5 кОДИРОВАНИЕ СОДЕРЖИМОГО (content codings).


зНАЧЕНИЕ КОДИРОВАНИЯ СОДЕРЖИМОГО УКАЗЫВАЕТ КАКОЕ ПРЕОБРАЗОВАНИЕ КОДИРОВАНИЯ БЫЛО ИЛИ БУДЕТ ПРИМЕНЕНО К ОБ╝ЕКТУ. кОДИРОВАНИЕ СОДЕРЖИМОГО ИСПОЛЬЗУЕТСЯ ПРЕЖДЕ ВСЕГО ДЛЯ СЖАТИЯ ИЛИ ДРУГОГО ПОЛЕЗНОГО ПРЕОБРАЗОВАНИЯ К ДОКУМЕНТУ БЕЗ ПОТЕРИ ИДЕНТИФИКАЦИИ ОСНОВНОГО МЕДИА ТИПА И ИНФОРМАЦИИ. чАСТО, ОБ╝ЕКТ СОХРАНЯЕТСЯ В КОДИРОВАННОЙ ФОРМЕ, ЗАТЕМ ПЕРЕДАЕТСЯ, А ПОТОМ ДЕКОДИРУЕТСЯ ПОЛУЧАТЕЛЕМ.

вСЕ ЗНАЧЕНИЯ КОДИРОВАНИЯ СОДЕРЖИМОГО (content-coding) НЕ ЧУВСТВИТЕЛЬНЫ К РЕГИСТРУ. HTTP/1.1 ИСПОЛЬЗУЕТ ЗНАЧЕНИЯ КОДИРОВАНИЯ СОДЕРЖИМОГО (content-coding) В ПОЛЯХ ЗАГОЛОВКА Accept-Encoding (РАЗДЕЛ 14.3) И Content-Encoding (РАЗДЕЛ 14.12). хОТЯ ЗНАЧЕНИЕ ОПИСЫВАЕТ КОДИРОВАНИЕ СОДЕРЖИМОГО, НО, ЧТО БОЛЕЕ ВАЖНО — ОНО УКАЗЫВАЕТ, КАКОЙ МЕХАНИЗМ ДЕКОДИРОВАНИЯ ПОТРЕБУЕТСЯ ДЛЯ ОБРАТНОГО ПРОЦЕССА.

Internet Assigned Numbers Authority (IANA) ДЕЙСТВУЕТ КАК РЕЕСТР ДЛЯ ЗНАЧЕНИЙ ЛЕКСЕМ КОДИРОВАНИЯ СОДЕРЖИМОГО (content-coding). пЕРВОНАЧАЛЬНО РЕЕСТР СОДЕРЖАЛ СЛЕДУЮЩИЕ ЛЕКСЕМЫ:

gzip фОРМАТ КОДИРОВАНИЯ, ПРОИЗВОДЯЩИЙ СЖАТИЕ ФАЙЛА ПРОГРАММОЙ «gzip» (GNU zip), КАК ОПИСАНО В RFC 1952 [25]. эТО ФОРМАТ Lempel-Ziv КОДИРОВАНИЯ (LZ77) С 32 РАЗРЯДНЫМ CRC. compress фОРМАТ КОДИРОВАНИЯ, ПРОИЗВОДИМЫЙ ОБЩЕЙ ПРОГРАММОЙ «compress» ДЛЯ СЖАТИЯ UNIX ФАЙЛОВ. эТО ФОРМАТ АДАПТИВНОГО Lempel-Ziv-Welch КОДИРОВАНИЯ (LZW).

оБРАТИТЕ ВНИМАНИЕ: иСПОЛЬЗОВАТЬ НАЗВАНИЯ ПРОГРАММ ДЛЯ ИДЕНТИФИКАЦИИ ФОРМАТОВ КОДИРОВАНИЯ НЕ ЖЕЛАТЕЛЬНО И ДОЛЖНО БЫТЬ НЕ ПОНЯТНО БУДУЩИМ КОДИРОВАНИЯМ. иХ ИСПОЛЬЗОВАНИЕ ЗДЕСЬ ОБ╝ЯСНЯЕТСЯ ИСТОРИЧЕСКОЙ ПРАКТИКОЙ, НО ТАК ДЕЛАТЬ НЕ НУЖНО. дЛЯ СОВМЕСТИМОСТИ С ПРЕДЫДУЩИМИ РЕАЛИЗАЦИЯМИ HTTP, ПРИЛОЖЕНИЯ ДОЛЖНЫ РАССМАТРИВАТЬ «x-gzip» И «x-compress» КАК ЭКВИВАЛЕНТЫ «gzip» И «compress» СООТВЕТСТВЕННО.

deflate фОРМАТ zlib, ОПРЕДЕЛЕННЫЙ В RFC 1950 [31], В КОМБИНАЦИИ С МЕХАНИЗМОМ СЖАТИЯ «deflate», ОПИСАННЫМ В RFC 1951 [29].

нОВАЯ ЛЕКСЕМА ЗНАЧЕНИЯ КОДИРОВАНИЯ СОДЕРЖИМОГО (content-coding) ДОЛЖНА БЫТЬ ЗАРЕГИСТРИРОВАНА; ЧТОБЫ ОБЕСПЕЧИТЬ ВЗАИМОДЕЙСТВИЕ МЕЖДУ КЛИЕНТАМИ И СЕРВЕРАМИ, СПЕЦИФИКАЦИЯ АЛГОРИТМА КОДИРОВАНИЯ СОДЕРЖИМОГО, НЕОБХОДИМОГО ДЛЯ ОПРЕДЕЛЕНИЯ НОВОГО ЗНАЧЕНИЯ, ДОЛЖНА БЫТЬ ОТКРЫТО ОПУБЛИКОВАНА И АДЕКВАТНА ДЛЯ НЕЗАВИСИМОЙ РЕАЛИЗАЦИИ, А ТАКЖЕ СООТВЕТСТВОВАТЬ ЦЕЛИ КОДИРОВАНИЯ СОДЕРЖИМОГО ОПРЕДЕЛЕННОГО В ЭТОМ РАЗДЕЛЕ.

3.6 кОДИРОВАНИЕ ПЕРЕДАЧИ (Transfer Codings).

зНАЧЕНИЯ КОДИРОВАНИЯ ПЕРЕДАЧИ ИСПОЛЬЗУЮТСЯ ДЛЯ УКАЗАНИЯ ПРЕОБРАЗОВАНИЯ КОДИРОВАНИЯ, КОТОРОЕ БЫЛО ИЛИ ДОЛЖНО БЫТЬ ПРИМЕНЕНО К ТЕЛУ ОБ╝ЕКТА (entity-body) В ЦЕЛЯХ ГАРАНТИРОВАНИЯ «БЕЗОПАСНОЙ ПЕРЕДАЧИ» ПО СЕТИ. оНО ОТЛИЧАЕТСЯ ОТ КОДИРОВАНИЯ СОДЕРЖИМОГО ТЕМ, ЧТО КОДИРОВАНИЕ ПЕРЕДАЧИ — ЭТО СВОЙСТВО СООБЩЕНИЯ, А НЕ ПЕРВОНАЧАЛЬНОГО ОБ╝ЕКТА.

вСЕ ЗНАЧЕНИЯ КОДИРОВАНИЯ ПЕРЕДАЧИ (transfer-coding) НЕ ЧУВСТВИТЕЛЬНЫ К РЕГИСТРУ. HTTP/1.1 ИСПОЛЬЗУЕТ ЗНАЧЕНИЯ КОДИРОВАНИЯ ПЕРЕДАЧИ (transfer-coding) В ПОЛЕ ЗАГОЛОВКА Transfer-Encoding (РАЗДЕЛ 14.40).

кОДИРОВАНИЯ ПЕРЕДАЧИ — ЭТО АНАЛОГИ ЗНАЧЕНИЙ Content-Transfer-Encoding MIME, КОТОРЫЕ БЫЛИ РАЗРАБОТАНЫ ДЛЯ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОЙ ПЕРЕДАЧИ ДВОИЧНЫХ ДАННЫХ ПРИ ИСПОЛЬЗОВАНИИ 7-БИТНОГО ОБСЛУЖИВАНИЯ ПЕРЕДАЧИ. оДНАКО БЕЗОПАСНЫЙ ТРАНСПОРТ ИМЕЕТ ДРУГОЕ ПРЕДНАЗНАЧЕНИЕ ДЛЯ ЧИСТО 8-БИТНОГО ПРОТОКОЛА ПЕРЕДАЧИ. в HTTP ЕДИНСТВЕНАЯ ОПАСНАЯ ХАРАКТЕРИСТИКА ТЕЛА СООБЩЕНИЯ ВЫЗВАНА СЛОЖНОСТЬЮ ОПРЕДЕЛЕНИЯ ТОЧНОЙ ДЛИНЫ ТЕЛА СООБЩЕНИЯ (РАЗДЕЛ 7.2.2), ИЛИ ЖЕЛАНИЕМ ШИФРОВАТЬ ДАННЫЕ ПРИ ПОЛЬЗОВАНИИ ОБЩЕДОСТУПНЫМ ТРАНСПОРТОМ.

кОДИРОВАНИЕ ПО КУСКАМ (chunked encoding) ИЗМЕНЯЕТ ТЕЛО СООБЩЕНИЯ ДЛЯ ПЕРЕДАЧИ ЕГО ПОСЛЕДОВАТЕЛЬНОСТЬЮ КУСКОВ, КАЖДЫЙ ИЗ КОТОРЫХ ИМЕЕТ СОБСТВЕННЫЙ ИНДИКАТОР РАЗМЕРА, СОПРОВОЖДАЕМЫМ ОПЦИОНАЛЬНЫМ ЗАВЕРШИТЕЛЕМ, СОДЕРЖАЩИМ ПОЛЯ ЗАГОЛОВКА ОБ╝ЕКТА. эТО ПОЗВОЛЯЕТ ДИНАМИЧЕСКИ СОЗДАВАЕМОМУ СОДЕРЖИМОМУ ПЕРЕДАВАТЬСЯ ВМЕСТЕ С ИНФОРМАЦИЕЙ, НЕОБХОДИМОЙ ПОЛУЧАТЕЛЮ ДЛЯ ПРОВЕРКИ ПОЛНОТЫ ПОЛУЧЕНИЯ СООБЩЕНИЯ.

кОДИРОВАНИЕ ПО КУСКАМ (chunked encoding) ОКАНЧИВАЕТСЯ КУСКОМ НУЛЕВОГО РАЗМЕРА, СЛЕДУЮЩИМ ЗА ЗАВЕРШИТЕЛЕМ, ОКАНЧИВАЮЩИМСЯ ПУСТОЙ СТРОКОЙ. цЕЛЬ ЗАВЕРШИТЕЛЯ СОСТОИТ В ЭФФЕКТИВНОМ МЕТОДЕ ОБЕСПЕЧЕНИЯ ИНФОРМАЦИИ ОБ ОБ╝ЕКТЕ, КОТОРЫЙ СГЕНЕРИРОВАН ДИНАМИЧЕСКИ; ПРИЛОЖЕНИЯ не должны ПОСЫЛАТЬ В ЗАВЕРШИТЕЛЕ ПОЛЯ ЗАГОЛОВКА, КОТОРЫЕ ЯВНО НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В ЗАВЕРШИТЕЛЕ, ТАКИЕ КАК Content-MD5 ИЛИ БУДУЩИЕ РАСШИРЕНИЯ HTTP ДЛЯ ЦИФРОВЫХ ПОДПИСЕЙ И ДРУГИХ ВОЗМОЖНОСТЕЙ.

пРИМЕРНЫЙ ПРОЦЕСС ДЕКОДИРОВАНИЯ Chunked-Body ПРЕДСТАВЛЕН В ПРИЛОЖЕНИИ 19.4.6.

вСЕ HTTP/1.1 ПРИЛОЖЕНИЯ должны БЫТЬ В СОСТОЯНИИ ПОЛУЧАТЬ И ДЕКОДИРОВАТЬ КОДИРОВАНИЕ ПЕРЕДАЧИ «ПО КУСКАМ» («chunked» transfer coding), И должны ИГНОРИРОВАТЬ РАСШИРЕНИЯ КОДИРОВАНИЯ ПЕРЕДАЧИ, КОТОРЫЕ ОНИ НЕ ПОНИМАЮТ. сЕРВЕРУ, КОТОРЫЙ ПОЛУЧИЛ ТЕЛО ОБ╝ЕКТА СО ЗНАЧЕНИЕМ КОДИРОВАНИЯ ПЕРЕДАЧИ, КОТОРОЕ ОН НЕ ПОНИМАЕТ, следует ВОЗВРАТИТЬ ОТВЕТ С КОДОМ 501 (нЕ РЕАЛИЗОВАНО, Not Implemented) И РАЗОРВАТЬ СОЕДИНЕНИЕ. сЕРВЕР не должен ПОСЫЛАТЬ ПОЛЯ КОДИРОВАНИЯ ПЕРЕДАЧИ (transfer-coding) HTTP/1.0 КЛИЕНТАМ.

3.7 мЕДИА ТИПЫ (Media Types).

HTTP ИСПОЛЬЗУЕТ мЕДИА тИПЫ иНТЕРНЕТА (Internet Media Types) В ПОЛЯХ ЗАГОЛОВКА Content-Type (РАЗДЕЛ 14.18) И Accept (РАЗДЕЛ 14.1) ДЛЯ ОБЕСПЕЧЕНИЯ ОТКРЫТОЙ И РАСШИРЯЕМОЙ ТИПИЗАЦИИ ДАННЫХ И ОБСУЖДЕНИЯ ТИПОВ.

пАРАМЕТРЫ МОГУТ СЛЕДОВАТЬ ЗА type/subtype В ФОРМЕ ПАР АТРИБУТ/ЗНАЧЕНИЕ (attribute/value).

тИП, ПОДТИП, И ИМЕНА АТРИБУТОВ И ПАРАМЕТРОВ НЕ ЧУВСТВИТЕЛЬНЫ К РЕГИСТРУ. зНАЧЕНИЯ ПАРАМЕТРОВ МОГУТ БЫТЬ ЧУВСТВИТЕЛЬНЫМИ К РЕГИСТРУ, НО МОГУТ БЫТЬ И НЕ ЧУВСТВИТЕЛЬНЫ, В ЗАВИСИМОСТИ ОТ СЕМАНТИКИ ИМЕНИ ПАРАМЕТРА. лИНЕЙНЫЙ ПРОБЕЛ (LWS) не должен ИСПОЛЬЗОВАТЬСЯ МЕЖДУ ТИПОМ И ПОДТИПОМ, МЕЖДУ АТРИБУТОМ И ЗНАЧЕНИЕМ. аГЕНТЫ ПОЛЬЗОВАТЕЛЕЙ, РАСПОЗНАЮЩИЕ МЕДИА ТИПЫ, должны ОБРАБАТЫВАТЬ (ИЛИ ПОДГОТАВЛИВАТЬ ДЛЯ ОБРАБОТКИ ЛЮБЫМИ ВНЕШНИМИ ПРИЛОЖЕНИЯМИ) ПАРАМЕТРЫ ДЛЯ ТЕХ ТИПОВ MIME, КОТОРЫЕ ОПИСАНЫ, И СООБЩАТЬ ПОЛЬЗОВАТЕЛЮ О ОБНАРУЖЕННЫХ ПРОБЛЕМАХ.

оБРАТИТЕ ВНИМАНИЕ: нЕКОТОРЫЕ СТАРЫЕ HTTP ПРИЛОЖЕНИЯ НЕ РАСПОЗНАЮТ ПАРАМЕТРЫ МЕДИА ТИПОВ. пРИ ПОСЫЛКЕ ДАННЫХ К ТАКИМ HTTP ПРИЛОЖЕНИЯМ РЕАЛИЗАЦИИ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПАРАМЕТРЫ МЕДИА ТИПОВ ТОЛЬКО КОГДА ЭТО ТРЕБУЕТСЯ ПО ОПРЕДЕЛЕНИЮ ТИПА/ПОДТИПА.

зНАЧЕНИЯ МЕДИА-ТИПОВ РЕГИСТРИРУЮТСЯ Internet Assigned Number Authority (IANA). пРОЦЕСС РЕГИСТРАЦИИ МЕДИА ТИПА ОПРЕДЕЛЕН В RFC 2048 [17]. иСПОЛЬЗОВАНИЕ НЕ ЗАРЕГИСТРИРОВАННЫХ МЕДИА ТИПОВ ВВОДИТ В ЗАБЛУЖДЕНИЕ.

3.7.1 кАНОНИЗАЦИЯ И ПРЕДОПРЕДЕЛЕННЫЕ ЗНАЧЕНИЯ ТИПА text.

мЕДИА ТИПЫ иНТЕРНЕТА ЗАРЕГИСТРИРОВАНЫ В КАНОНИЧЕСКОЙ ФОРМЕ. вООБЩЕ, ТЕЛО ОБ╝ЕКТА, ПЕРЕДАВАЕМОЕ HTTP СООБЩЕНИЕМ, должно БЫТЬ ПРЕДСТАВЛЕНО В СООТВЕТСТВУЮЩЕЙ КАНОНИЧЕСКИОЙ ФОРМЕ ДО ПЕРЕДАЧИ; ИСКЛЮЧЕНИЕ СОСТАВЛЯЮТ ТИПЫ «text», ОПРЕДЕЛЯЕМЫЕ В СЛЕДУЮЩЕМ АБЗАЦЕ.

в КАНОНИЧЕСКОЙ ФОРМЕ МЕДИА ПОДТИПЫ ТИПА «text» ИСПОЛЬЗУЮТ CRLF В КАЧЕСТВЕ МЕТКИ КОНЦА СТРОКИ. HTTP ОСЛАБЛЯЕТ ЭТО ТРЕБОВАНИЕ И ПОЗВОЛЯЕТ ПЕРЕДАВАТЬ ТЕКСТ РАЗМЕЧЕННЫЙ ТАКИМ ОБРАЗОМ, ЧТО ЕДЕНИЧНЫЕ CR ИЛИ LF МОГУТ БЫТЬ МЕТКАМИ КОНЦА СТРОКИ, ПРАВДА ЭТО ПРАВИЛО ДОЛЖНО БЫТЬ ВЫПОЛНЕНО ДЛЯ ВСЕГО ТЕЛА ОБ╝ЕКТА (entity-body). HTTP ПРИЛОЖЕНИЯ должны ВОСПРИНИМАТЬ CRLF, ПРОСТО CR, И ПРОСТО LF КАК ПРЕДСТАВЛЕНИЕ КОНЦА СТРОКИ В ТЕКСТОВЫХ ТИПАХ, ПЕРЕДАННЫХ ПО HTTP. кРОМЕ ТОГО, ЕСЛИ ТЕКСТ ПРЕДСТАВЛЯЕТСЯ В КОДОВОЙ ТАБЛИЦЕ, КОТОРАЯ НЕ ИСПОЛЬЗУЕТ ОКТЕТЫ 13 И 10 ДЛЯ CR И LF СООТВЕТСТВЕННО, ЧТО ИМЕЕТ МЕСТО В НЕКОТОРЫХ МНОГОБАЙТОВЫХ КОДОВЫХ ТАБЛИЦАХ, ТО HTTP ПОЗВОЛЯЕТ ИСПОЛЬЗОВАТЬ ЛЮБЫЕ ПОСЛЕДОВАТЕЛЬНОСТИ ОКТЕТОВ, ОПРЕДЕЛЕННЫЕ ЭТИМ НАБОРОМ СИМВОЛОВ ДЛЯ ПРЕДСТАВЛЕНИЯ ЭКВИВАЛЕНТОВ CR И LF В КАЧЕСТВЕ КОДА КОНЦА СТРОКИ. эТА ГИБКОСТЬ В ОТНОШЕНИИ КОНЦОВ СТРОК ПРИМЕНИМА ТОЛЬКО К ТЕКСТОВЫМ ТИПАМ В ТЕЛЕ ОБ╝ЕКТА; ПРОСТО CR ИЛИ ПРОСТО LF не должны ЗАМЕНЯТЬ CRLF ВНУТРИ ЛЮБОЙ УПРАВЛЯЮЩЕЙ СТРУКТУРЫ HTTP (ТИПА ПОЛЯ ЗАГОЛОВКА И РАЗДЕЛИТЕЛЕЙ ТИПА multipart).

еСЛИ ТЕЛО ОБ╝ЕКТА КОДИРУЕТСЯ ПРИ ПОМОЩИ Content-Encoding, ТО ОСНОВНЫЕ ДАННЫЕ должны БЫТЬ В ОПРЕДЕЛЕННОЙ ВЫШЕ ФОРМЕ ДО КОДИРОВАНИЯ.

пАРАМЕТР «charset» ИСПОЛЬЗУЕТСЯ С НЕКОТОРЫМИ МЕДИА ТИПАМИ ДЛЯ УКАЗАНИЯ КОДОВОЙ ТАБЛИЦЫ (РАЗДЕЛ 3.4), ИСПОЛЬЗУЕМОЙ ДЛЯ ПРЕДСТАВЛЕНИЯ ДАННЫХ. еСЛИ ПАРАМЕТР «charset» НЕ УКАЗАН ОТПРАВИТЕЛЕМ, ТО ПРИ ПОЛУЧЕНИИ ПО HTTP МЕДИА ПОДТИПЫ ТИПА «text» ИМЕЮТ ЗНАЧЕНИЕ «charset», ПО УМОЛЧАНИЮ РАВНОЕ «ISO-8859-1». дАННЫЕ В КОДОВЫХ ТАБЛИЦАХ ИЛИ ИХ ПОДМНОЖЕСТВАХ, ОТЛИЧНЫХ ОТ «ISO-8859-1» должны БЫТЬ ПОМЕЧЕНЫ СООТВЕТСТВУЮЩИМ ЗНАЧЕНИЕМ «charset».

нЕКОТОРОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ HTTP/1.0 ИНТЕРПРЕТИРОВАЛО ЗАГОЛОВОК Content-Type БЕЗ ПАРАМЕТРА «charset» НЕПРАВИЛЬНО, КАК ОЗНАЧАЮЩЕЕ «ДОЛЖЕН ПРЕДПОЛОЖИТЬ ПОЛУЧАТЕЛЬ». оТПРАВИТЕЛИ, ЖЕЛАЮЩИЕ ПРЕДУСМОТРЕТЬ ТАКОЕ ПОВЕДЕНИЕ могут ВКЛЮЧАТЬ ПАРАМЕТР «charset» ДАЖЕ КОГДА charset РАВЕН ISO-8859-1 И должны СДЕЛАТЬ ЭТО, ЕСЛИ ИЗВЕСТНО, ЧТО ЭТО НЕ ЗАПУТАЕТ ПОЛУЧАТЕЛЯ.

к СОЖАЛЕНИЮ, НЕКОТОРЫЕ СТАРЫЕ HTTP/1.0 КЛИЕНТЫ НЕ РАБОТАЛИ ПРАВИЛЬНО С ОПРЕДЕЛЕНИЕМ ПАРАМЕТРА «charset». HTTP/1.1 ПОЛУЧАТЕЛИ должны ОТДАВАТЬ ПРИОРИТЕТ МЕТКЕ «charset», ПОСТАВЛЕННОЙ ОТПРАВИТЕЛЕМ; И ТЕ АГЕНТЫ ПОЛЬЗОВАТЕЛЕЙ, КОТОРЫЕ ИМЕЮТ ВОЗМОЖНОСТЬ «ПРЕДПОЛОЖИТЬ» charset должны ПРИ ПЕРВОНАЧАЛЬНОМ ОТОБРАЖЕНИИ ДОКУМЕНТА ИСПОЛЬЗОВАТЬ charset ИЗ ПОЛЯ content-type, ЕСЛИ ОНИ ПОДДЕРЖИВАЮТ ТАКОЙ charset, А ЗАТЕМ ИСПОЛЬЗОВАТЬ СОБСТВЕННЫЕ УСТАНОВКИ.

3.7.2 тИПЫ Multipart.

MIME ПРЕДУСМАТРИВАЕТ РЯД ТИПОВ «multipart» — ФОРМИРУЮЩИХ ПАКЕТ ИЗ ОДНОГО ИЛИ НЕСКОЛЬКИХ ОБ╝ЕКТОВ ВНУТРИ ТЕЛА ОДНОГО СООБЩЕНИЯ. вСЕ ТИПЫ mulptipart ИСПОЛЬЗУЮТ ОБЩИЙ СИНТАКСИС, ОПРЕДЕЛЕНЫЙ В MIME [7], И должны СОДЕРЖАТЬ РАЗДЕЛИТЕЛЬНЫЙ ПАРАМЕТР ЧАСТЬЮ ЗНАЧЕНИЯ МЕДИА ТИПА. тЕЛО СООБЩЕНИЯ — САМОСТОЯТЕЛЬНЫЙ ЭЛЕМЕНТ ПРОТОКОЛА И, СЛЕДОВАТЕЛЬНО, должно ИСПОЛЬЗОВАТЬ ТОЛЬКО сRLF ДЛЯ ПРЕДСТАВЛЕНИЯ КОНЦОВ СТРОК МЕЖДУ ЧАСТЯМИ ТЕЛА (body-parts). в ОТЛИЧИЕ ОТ MIME, ОКОНЧАНИЕ ЛЮБОГО multipart СООБЩЕНИЯ должно БЫТЬ ПУСТЫМ; HTTP ПРИЛОЖЕНИЯ не должны ПЕРЕДАВАТЬ ОКОНЧАНИЕ (ДАЖЕ ЕСЛИ ПЕРВОНАЧАЛЬНЫЙ multipart СОДЕРЖИТ ЗАКЛЮЧЕНИЕ).

в HTTP ЧАСТИ ТЕЛА (body-parts) ТИПА multipart могут СОДЕРЖАТЬ ПОЛЯ ЗАГОЛОВКА, КОТОРЫЕ ЯВЛЯЮТСЯ ЗНАЧАЩИМИ В ПРИМНЕНИИ К ЭТОЙ ЧАСТИ. пОЛЕ ЗАГОЛОВКА Content-Location (РАЗДЕЛ 14.15) следует ВКЛЮЧАТЬ В ЧАСТЬ ТЕЛА (body-part) КАЖДОГО ВКЛЮЧЕННОГО ОБ╝ЕКТА, КОТОРЫЙ МОЖЕТ БЫТЬ ИДЕНТИФИЦИРОВАН URL.

вООБЩЕ ГОВОРЯ, HTTP АГЕНТУ ПОЛЬЗОВАТЕЛЯ следует СЛЕДОВАТЬ ТАКОМУ ЖЕ ИЛИ ПОДОБНОМУ ПОВЕДЕНИЮ, КОТОРОМУ СЛЕДОВАЛ БЫ MIME АГЕНТ ПОЛЬЗОВАТЕЛЯ ПОСЛЕ ПОЛУЧЕНИЯ ТИПА multipart. еСЛИ ПРИЛОЖЕНИЕ ПОЛУЧАЕТ НЕЗАРЕГИСТРИРОВАННЫЙ ПОДТИП multipart, ОНО должно ОБРАБАТЫВАТЬ ЕГО КАК ПОДТИП «multipart/mixed».

оБРАТИТЕ ВНИМАНИЕ: ТИП «multipart/form-data» БЫЛ СПЕЦИАЛЬНО ОПРЕДЕЛЕН ДЛЯ ПЕРЕДАЧИ ДАННЫХ ФОРМЫ, ПОДХОДЯЩИХ ДЛЯ ОБРАБОТКИ МЕТОДОМ ЗАПРОСА POST, ЧТО ОПИСАНО В RFC 1867 [15].

3.8 лЕКСЕМЫ ПРОГРАММ (Product Tokens).

лЕКСЕМЫ ПРОГРАММ ИСПОЛЬЗУЮТСЯ, ЧТОБЫ ОБЕСПЕЧИТЬ КОММУНИКАЦИОННЫМ ПРИЛОЖЕНИЯМ ВОЗМОЖНОСТЬ ИДЕНТИФИЦИРОВАТЬ СЕБЯ НАЗВАНИЕМ И ВЕРСИЕЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. бОЛЬШИНСТВО ПОЛЕЙ, ИСПОЛЬЗУЮЩИХ ЛЕКСЕМЫ ПРОГРАММ ТАКЖЕ ДОПУСКАЕТ ПЕРЕЧИСЛЕНИЕ ПОДПРОГРАММ, КОТОРЫЕ ФОРМИРУЮТ ЗНАЧИТЕЛЬНУЮ ЧАСТЬ ПРИЛОЖЕНИЯ, И КОТОРЫЕ ПЕРЕЧИСЛЯЮТСЯ ЧЕРЕЗ ПРОБЕЛ. в СООТВЕТСТВИИ С СОГЛАШЕНИЕМ, ПОДПРОГРАММЫ ПЕРЕЧИСЛЯЮТСЯ В ПОРЯДКЕ ИХ ЗНАЧЕНИЯ ДЛЯ ИДЕНТИФИКАЦИИ ПРИЛОЖЕНИЯ.

лЕКСЕМЫ ПРОГРАММ ДОЛЖНЫ БЫТЬ КОРОТКИМИ И ПО СУТИ — ИСПОЛЬЗОВАНИЕ ИХ ДЛЯ РЕКЛАМЫ ИЛИ ДРУГОЙ НЕСУЩЕСТВЕННОЙ ИНФОРМАЦИИ ОДНОЗНАЧНО ЗАПРЕЩЕНО. хОТЯ В ЛЕКСЕМЕ product-version МОЖЕТ ВСТРЕЧАТЬСЯ ЛЮБОЙ СИМВОЛ, ВСЕ ЖЕ ЕЕ СЛЕДУЕТ ИСПОЛЬЗОВАТЬ ТОЛЬКО ДЛЯ ИДЕНТИФИКАТОРА ВЕРСИИ (ТО ЕСТЬ, ПОСЛЕДОВАТЕЛЬНЫМ ВЕРСИЯМ ОДНОЙ И ТОЙ ЖЕ ПРОГРАММЫ следует ИМЕТЬ ОТЛИЧИЯ ТОЛЬКО В ЧАСТИ product-version ЛЕКСЕМЫ product.

3.9 кАЧЕСТВЕННЫЕ ЗНАЧЕНИЯ (Quality Values).

оБСУЖДЕНИЕ СОДЕРЖИМОГО HTTP (РАЗДЕЛ 12) ИСПОЛЬЗУЕТ КОРОТКИЕ ЧИСЛА «С ПЛАВАЮЩЕЙ ТОЧКОЙ» ДЛЯ УКАЗАНИЯ ОТНОСИТЕЛЬНОЙ ВАЖНОСТИ («ВЕСА») РАЗЛИЧНЫХ ОГОВОРЕННЫХ ПАРАМЕТРОВ. вЕС — ЭТО НОРМАЛИЗОВАНОЕ ВЕЩЕСТВЕННОЕ ЧИСЛО В ДИАПАЗОНЕ ОТ 0 ДО 1, ГДЕ 0 — МИНИМАЛЬНОЕ, А 1 — МАКСИМАЛЬНОЕ ЗНАЧЕНИЕ. HTTP/1.1 ПРИЛОЖЕНИЯ не должны ГЕНЕРИРОВАТЬ БОЛЕЕ ТРЕХ ЦИФР ПОСЛЕ ДЕСЯТИЧНОЙ ТОЧКИ. пОЛЬЗОВАТЕЛЬСКИМ КОНФИГУРАЦИЯМ ЭТИХ ЗНАЧЕНИЙ следует ТАКЖЕ ОГРАНИЧИВАТЬСЯ ЭТИМ РЕЖИМОМ.

«кАЧЕСТВЕННЫЕ ЗНАЧЕНИЯ» — НЕ КОРРЕКТНОЕ НАЗВАНИЕ, ТАК КАК ЭТИ ЗНАЧЕНИЯ ПРОСТО ПРЕДСТАВЛЯЮТ ОТНОШЕНИЕ СНИЖЕНИЯ ПРОИЗВОДИТЕЛЬНОСТИ К ЖЕЛАТЕЛЬНОМУ КАЧЕСТВУ.

3.10 мЕТКИ ЯЗЫКОВ (Language Tags).

мЕТКА ЯЗЫКА ИДЕНТИФИЦИРУЕТ ЕСТЕСТВЕННЫЙ ЯЗЫК: РАЗГОВОРНЫЙ, ПИСЬМЕННЫЙ, ИЛИ ДРУГОЙ ИСПОЛЬЗУЕМЫЙ ЛЮДЬМИ ДЛЯ ОБМЕНА ИНФОРМАЦМЕЙ С ДРУГИМИ ЛЮДЬМИ. мАШИННЫЕ ЯЗЫКИ ЯВЛЯЮТСЯ ИСКЛЮЧЕНИЕМ. HTTP ИСПОЛЬЗУЕТ МЕТКИ ЯЗЫКА ВНУТРИ ПОЛЕЙ Accept-Language И Content-Language.

сИНТАКСИС И ЗАПИСЬ HTTP МЕТОК ЯЗЫКА ТАКИЕ ЖЕ, КАК ОПРЕДЕЛЯЕМЫЕ RFC 1766 [1]. в РЕЗЮМЕ, МЕТКА ЯЗЫКА СОСТОИТ ИЗ ОДНОЙ ИЛИ НЕСКОЛЬКИХ ЧАСТЕЙ: МЕТКА ПЕРВИЧНОГО ЯЗЫКА И, ВОЗМОЖНО ПУСТОЙ, РЯД ПОДЧИНЕННЫХ МЕТОК:

вНУТРИ МЕТКИ НЕ ДОПУСТИМ ПРОБЕЛ И ВСЕ МЕТКИ НЕ ЧУВСТВИТЕЛЬНЫ К РЕГИСТРУ. пРОСТРАНСТВО ИМЕН МЕТОК ЯЗЫКА УПРАВЛЯЕТСЯ IANA. нАПРИМЕР МЕТКИ СОДЕРЖАТ:

лЮБАЯ ДВУХСИМВОЛЬНАЯ ПЕРВИЧНАЯ МЕТКА ЯВЛЯЕТСЯ МЕТКОЙ АББРЕВЕАТУРЫ ЯЗЫКА ISO 639, А ЛЮБАЯ ДВУХСИМВОЛЬНАЯ ПОДЧИНЕННАЯ МЕТКА ЯВЛЯЕТСЯ МЕТКОЙ КОДА СТРАНЫ ISO 3166. (пОСЛЕДНИЕ ТРИ МЕТКИ ИЗ ВЫШЕПЕРЕЧИСЛЕННЫХ — НЕ ЗАРЕГИСТРИРОВАННЫЕ МЕТКИ; ВСЕ, КРОМЕ ПОСЛЕДНЕЙ — ПРИМЕРЫ МЕТОК, КОТОРЫЕ МОГЛИ БЫ БЫТЬ ЗАРЕГИСТРИРОВАНЫ В БУДУЩЕМ.)

3.11 мЕТКИ ОБ╝ЕКТОВ (Entity Tags).

мЕТКИ ОБ╝ЕКТОВ ИСПОЛЬЗУЮТСЯ ДЛЯ СРАВНЕНИЯ ДВУХ ИЛИ БОЛЕЕ ОБ╝ЕКТОВ ОТ ОДНОГО И ТОГО ЖЕ ЗАПРОШЕННОГО РЕСУРСА. HTTP/1.1 ИСПОЛЬЗУЕТ МЕТКИ ОБ╝ЕКТА В ПОЛЯХ ЗАГОЛОВКА ETag (РАЗДЕЛ 14.20), If-Match (РАЗДЕЛ 14.25), If-None-Match (РАЗДЕЛ 14.26), И If-Range (РАЗДЕЛ 14.27). оПРЕДЕЛЕНИЕ ТОГО, КАК ОНИ ИСПОЛЬЗУЮТСЯ И СРАВНИВАЮТСЯ В КАЧЕСТВЕ МЕТОК ПРОВЕРКИ КЭША НАХОДИТСЯ В РАЗДЕЛЕ 13.3.3. мЕТКА ОБ╝ЕКТА СОСТОИТ ИЗ НЕПРОЗРАЧНОЙ ЦИТИРУЕМОЙ СТРОКИ (opaque quoted string), ВОЗМОЖНО ПРЕДВАРЕННОЙ ИНДИКАТОРОМ СЛАБОСТИ (weakness indicator).

«сИЛЬНАЯ МЕТКА ОБ╝ЕКТА» («strong entity tag») МОЖЕТ БЫТЬ РАЗДЕЛЕНА ДВУМЯ ОБ╝ЕКТАМИ РЕСУРСА, ТОЛЬКО ЕСЛИ ОНИ ПООКТЕТНО ЭКВИВАЛЕНТНЫ.

«сЛАБАЯ МЕТКА ОБ╝ЕКТА» («weak entity tag»), ОБОЗНАЧЯЕМАЯ ПРЕФИКСОМ «W/», МОЖЕТ БЫТЬ РАЗДЕЛЕНА ДВУМЯ ОБ╝ЕКТАМИ РЕСУРСА ТОЛЬКО ЕСЛИ ОБ╝ЕКТЫ ЭКВИВАЛЕНТНЫ И МОГЛИ БЫ ЗАМЕНЯТЬ ДРУГ ДРУГА БЕЗ ЗНАЧИТЕЛЬНОГО ИЗМЕНЕНИЯ В СЕМАНТИКЕ. сЛАБАЯ МЕТКА ОБ╝ЕКТА МОЖЕТ ИСПОЛЬЗОВАТЬСЯ ТОЛЬКО ДЛЯ СЛАБОГО СРАВНЕНИЯ.

мЕТКА ОБ╝ЕКТА должна БЫТЬ УНИКАЛЬНА СРЕДИ ВСЕХ ВЕРСИЙ ВСЕХ ОБ╝ЕКТОВ, СВЯЗАННЫХ С КОНКРЕТНЫМ РЕСУРСОМ. дАННОЕ ЗНАЧЕНИЕ МЕТКИ ОБ╝ЕКТА МОЖЕТ ИСПОЛЬЗОВАТЬСЯ ДЛЯ ОБ╝ЕКТОВ, ПОЛУЧЕННЫХ ЗАПРОСАМИ РАЗЛИЧНЫХ URI БЕЗ ПРЕДПОЛОЖЕНИЯ ЭКВИВАЛЕНТНОСТИ ЭТИХ ОБ╝ЕКТОВ.

3.12 еДЕНИЦЫ ИЗМЕРЕНИЯ ДИАПАЗОНОВ (Range Units).

HTTP/1.1 ПОЗВОЛЯЕТ КЛИЕНТУ ЗАПРАШИВАТЬ ТОЛЬКО ЧАСТЬ ОБ╝ЕКТА. HTTP/1.1 ИСПОЛЬЗУЕТ ЕДЕНИЦЫ ИЗМЕРЕНИЯ ДИАПАЗОНОВ В ПОЛЯХ ЗАГОЛОВКА Range (РАЗДЕЛ 14.36) И Content-Range (РАЗДЕЛ 14.17). оБ╝ЕКТ МОЖЕТ БЫТЬ РАЗБИТ НА ЧАСТИ СООТВЕТСТВЕННО РАЗЛИЧНЫМ СТРУКТУРНЫМ МОДУЛЯМ.

еДИНСТВЕНАЯ ЕДЕНИЦА ИЗМЕРЕНИЯ ДИАПАЗОНОВ, ОПРЕДЕЛЕННАЯ В HTTP/1.1 — ЭТО «bytes». рЕАЛИЗАЦИИ HTTP/1.1 МОГУТ ИГНОРИРОВАТЬ ДИАПАЗОНЫ, ОПРЕДЕЛЕННЫЕ С ИСПОЛЬЗОВАНИЕМ ДРУГИХ ЕДЕНИЦ ИЗМЕРЕНИЯ. HTTP/1.1 БЫЛ РАЗРАБОТАН, ЧТОБЫ ДОПУСКАТЬ РЕАЛИЗАЦИИ ПРИЛОЖЕНИЙ, КОТОРЫЕ НЕ ЗАВИСЯТ ОТ ЗНАНИЯ ДИАПАЗОНОВ.

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожие статьи

Пошаговый ввод в домен Windows 10

Автоматическая смена паролей пользователей Linux

Ещё несколько полезных команд для CentOS

LXC, LXD и LXCFS – в чем разница?

HyperText Transfer Protocol (HTTP)

Работает прямо сейчас

4 минуты чтения

The HyperText Transfer Protocol, или HTTP, это самый распространенный в мире протокол уровня приложений модели OSI на сегодняшний день. Протокол HTTP образует пространство, которое большинство людей называют сетью Интернет. Основной задачей протокола HTTP является извлечение HTML (HyperText Markup Language) или любых других документов с WEB – сайтов через сеть Интернет. Каждый раз, когда вы открываете интернет — браузер, в дело вступает протокол HTTP, оперируя поверх стека протоколов TCP/IP.

Протокол HTTP был впервые выпущен на свет вначале 1990 года и имел три версии:

  • HTTP/0.9: Простейшая реализация протокола, позволяющая только получать WEB – страницы
  • HTTP/1.0: Даная версия обнародована Инженерным советом Интернета (Internet Engineering Task Force, IETF) в рамках RFC 1945 в 1996 году. В данной версии было добавлено большое количество дополнительных полей, именуемых заголовками в этой спецификации. Эта версия протокола расширяла взаимодействие между клиентом и сервером.
  • HTTP/1.1: Версия 1.1 определена в RFC 2068 советом IETF как доработанная и улучшенная версия протокола HTTP поверх спецификации 1.0. Одним из самых заметных улучшений версии 1.1 по сравнению с 1.0 стало внедрений методов постоянных TCP сессий, возможность отправки нескольких HTTP запросов одновременно, не дожидаясь ответа сервера (повышение скорости работы) и реализация алгоритма кэширования.

На сегодняшний день, большинство современных интернет – браузеров поддерживают обе версии 1.0 и 1.1 протокола HTTP. Важно отметить, что современные браузеры обеспечивают полную совместимость данных версий, то есть при условии отправки запрос версии 1.0 и получения ответа 1.1, данные будут успешно обработаны.

Получение веб страницы по HTTP

Рассмотрим процесс получения WEB – страницы обычным интернет браузером с сервера. Любая HTML страница содержит в себе множество объектов, тэгов и изображений. В целом, HTML можно рассматривать как структуру страницы, в которой все объекты расставлены на свои места. В свою очередь, интернет – браузер получает инструкции в рамках этого HTML документа, откуда брать шрифты, цвета, фон и прочие элементы оформления страницы. Порядок таков:

  1. Клиент (браузер) отправляет запрос на WEB – сервер для запрашиваемой страницы.
  2. Сервер анализирует запрос и отправляет HTML код необходимый для формирования страницы.
  3. Клиент начинает анализировать полученный документ и формировать WEB – страницу.
  4. Клиент в последующих запросах будет формировать изображения, видео или любую другую форму внутренних объектов из источников WEB – сервера.

Когда все элементы страницы получены, клиент (интернет браузер) отобразит запрошенную WEB – страницу. Порядок и время работы зависят от версии протокола (1.0 или 1.1).

HTTP запросы

Протокол HTTP (HyperText Transfer Protocol) позволяет не только получать HTML документы с Web – серверов, но и передавать информацию от клиента к серверу. Заголовки запросов в протокол HTTP версий 1.0 и 1.1 указаны в таблице ниже:

Запрос Описание HTTP/1.0 HTTP/1.1
GET Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
POST Позволяет клиенту отправлять информацию в сторону сервера, например через различные встроенные в сайт формы Да Да
PUT Позволяет клиенту добавить файл в определенную директорию сервера. Нет Да
DELETE Позволяет клиенту удалить файл указанный в рамках запроса. Нет Да
TRACE Позволяет клиенту отслеживать свой запрос к серверу. Нет Да
OPTIONS Позволяет клиенту определять параметры взаимодействия с сервером. Нет Да

В стандартном понимании Web – сайта, запросы GET и POST являются наиболее часто используемыми. Метода GET используется клиентом для получения каждого отдельного объекта страницы, в то время как POST зачастую используется в интернет магазинах, где необходимо отправить информацию в строну сервера.

Что такое URL?


Uniform Resource Locator (URL) одна из самых важных составляющих любого GET запроса, который состоит из хоста, на котором находится сайт, схемы обращения (сетевой протокол) и полного пути к HTML файлу. Опционально, URL может содержать в себе информацию о номере TCP порта и определенной точки на странице. Ниже приведен типичный пример URL:

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

Hypertext Transfer Protocol — HTTP/1.1

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the «Internet Official Protocol Standards» (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as «HTTP/1.1», and is an update to RFC 2068 [33].

Параметры протокола / rfc 2068

Network Working Group
Request for Comments: 2068
Category: Standards Track

R. Fielding
UC Irvine
J. Gettys
J. Mogul
DEC
H. Frystyk
T. Berners-Lee
MIT/LCS
January 1997

Hypertext Transfer Protocol — HTTP/1.1


Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the «Internet Official Protocol Standards» (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as «HTTP/1.1».

Table of Contents

Next: 1 Introduction Connected: An Internet Encyclopedia
RFC 2068

HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

Стандарты HTTP протокола. История развития HTTP протокола. Версии HTTP протокола

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол. В данной записи мы познакомимся со стандартами HTTP протокола, где их искать и что дадут нам эти стандарты, рассматривая стандарты HTTP, мы невольно затронем историю развития протокола HTTP, а заодно и то, какие изменения вводились от версии к версии HTTP.

Стандарты HTTP протокола. История развития HTTP протокола. Версии HTTP протокола

Рассмотрим какие есть стандарты HTTP протокола, посмотрев стандарты HTTP протокола мы заодно познакомимся с историей развития HTTP. Стандарт HTTP – это основной документ, исходя из которого мы должны разрабатывать свои приложения, использующие HTTP протокол.

Стандарты HTTP, версии HTTP протокола

На данный момент есть четыре стандарта HTTP протокола:

  1. Стандарт HTTP/0.9версия протокола HTTP 0.9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Протокол версии 0.9 был призван упорядочить взаимодействие между клиентом и сервером в сети. После появления стандарта HTTP/0.9 появилось разделение функций между клиентом и сервером при их взаимодействии. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
  2. В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0). Данный документ стал основой для реализации приложений и компонентов с использованием протокола HTTP версии 1.0. Кстати, разработчики могут идентифицировать свои приложения при передаче HTTP сообщений.
  3. В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). Доработки коснулись: общего дизайна стандарта, формулировки и разъяснения некоторых терминов, исправлены опечатки, даны некоторые разъяснения по взаимодействию клиента и HTTP сервера в спорных ситуациях. Основным нововведением в версию протокола HTTP 1.1 был режим постоянного соединения (можете почитать про постоянные HTTP соединения), другими словами: за одно соединение можно было отправлять несколько HTTP запросов и получать несколько HTTP ответов в том порядке, в котором делались запросы. Вторым основным нововведение в версию протокола HTTP 1.1 является то, что теперь клиент при установке соединения с сервером должен обязательно посылать имя хоста в специальном поле HTTP заголовка (данное нововведение привело к массовому распространению виртуальных хостингов). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Стоит заметить, что версия HTTP протокола является очень важным HTTP параметром, который должны использовать все приложения. Так же замечу, что независимо от номера стандарта HTTP протокол предъявляет требования к приложениям, которые его используют.
  4. 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета. Версия протокола HTTP 2 является бинарной. В версии протокола HTTP 2 будет поддерживаться мультиплексирование (объединение) запросов, поскольку появится объединение, появится и приоритет запросов и многое другое, думаю, в завершении цикла заметок по HTTP мы познакомимся со всеми нововведениями HTTP.

Хочу обратить ваше внимание на то, что все документы RFC, которые я перечислил являются открытыми и ознакомиться c версиями протокола HTTP вы можете на языке Шекспира. Другими словами, найти стандарт HTTP не проблема. Добавим, что HTTP протокол относится к прикладному уровню всем известной модели сетевого взаимодействия OSI.

Параметры протокола / rfc 2068

СРЕДСТВА ТЕХНИЧЕСКИЕ ТЕЛЕМАТИЧЕСКИХ СЛУЖБ

ОБЩИЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

СОГЛАСОВАНЫ Руководителем ДЭС Минсвязи России В.Ю.Квицинским 03.07.2002

УТВЕРЖДЕНЫ Первым заместителем Министра Российской Федерации по связи и информатизации Ю.А.Павленко 03.07.2002

1. НАЗНАЧЕНИЕ ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ

1. НАЗНАЧЕНИЕ ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ

1.1. Настоящие общие технические требования (ОТТ) распространяются на оборудование телематических служб, реализующего функции взаимодействия элементов сети по протоколу SIP (протокол инициирования сеанса), и являются дополнением к РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования».

1.2. ОТТ предназначены для руководства при проведении сертификационных испытаний оборудования, поддерживающего протокол SIP.

1.3. Протокол SIP описывает операции установления, модификации и окончания мультимедийных сеансов связи с одним или несколькими абонентами. Протокол обеспечивает взаимодействие между следующими элементами сети: агенты пользователя (клиента и сервера), прокси-сервер, сервер переадресации, сервер определения местоположения.

1.4. ОТТ составлены на основе документов, список которых приведен в Приложении 4.

1.5. Данные ОТТ распространяются на следующую аппаратуру связи, реализующую функции передачи речевой информации по сетям с маршрутизацией пакетов по протоколу IP:

— оконечное оборудование пользователя (персональный компьютер со специальным программным обеспечением или телефонный аппарат, работающий по аналоговым телефонным линиям или интерфейсам локальной сети);

— аппаратура регистрации пользователя в сети (персональный компьютер, работающий по интерфейсам локальной сети);

— аппаратуру маршрутизации пакетов IP с функциями преобразования речевой информации в пакеты IP и взаимодействия с ТфОП (шлюз).

2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К СЕРВЕРУ SIP

2.1. Соединения

2.1.1. Протокол нижнего уровня

Сообщения SIP могут передаваться с использованием соединения TCP или UDP. Если порт не назначен, то, по умолчанию, используется порт 5060.

2.1.2. Установление соединения и закрытие соединения

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

Сервер должен держать открытым установленное TCP-соединение до завершения SIP-транзакции. Соединение может быть закрыто после окончания SIP-транзакции.

3. ПЕРЕЧЕНЬ И СТРУКТУРА СООБЩЕНИЙ ПРОТОКОЛА SIP

3.1. Требования к элементам сообщений

3.1.1. В сообщении SIP должен использоваться формат адреса URI в соответствии с п.2.2. Приложения 2.

3.1.2. В сообщении SIP должен использоваться один из форматов представления даты, приведенных в п.2.3.1. Приложения 2.

3.1.3. Промежутки времени в полях сообщения SIP должны указываться в секундах в виде десятичного числа.

3.1.4. Описание Request-URI должно соответствовать описанию п.2.2. Приложения 2.

3.2. Адресация

3.2.1. Объекты, поддерживающие SIP-протокол, используют систему адресации подобную адресу электронной почты — user@host. В качестве адреса используется специальный универсальный указатель ресурсов SIP URL, описание которого приведено в п.2.2. Приложения 2.

3.2.2. Адрес состоит из двух частей:

а) user — имя пользователя, зарегистрированного в домене или на рабочей станции, или телефонный номер;

б) host — имя домена, рабочей станции или шлюза.

3.2.3. В начале адреса ставится слово «sip:» — указатель SIP-адреса.

3.3. Типы информации

3.3.1. Если сервер отправляет ответ с типом информации, отличным от application/sdp, он должен указать данный тип в поле Content-Type. Обозначение типа должно соответствовать RFC 2068.

3.3.2. Если к телу сообщения применяется преобразование, тип преобразования должен быть указан в поле Content-Encoding в соответствии с п.9.8. Приложения 2.

3.4. Запросы

3.4.1. Запросы образуют выходной поток. Структура запросов протокола SIP должна соответствовать п.3. и п.4. Приложения 2.

3.4.2. В сервере должна быть реализована обработка запросов с методами INVITE, АСК, BYE, CANCEL, REGISTER, OPTION.

3.4.3. Тело сообщения запроса INVITE, приглашающего принять участие в сеансе связи, должно содержать информацию об описании соответствующего сеанса связи. Описание может быть представлено в формате SDP в соответствии с RFC 2327. Описание протокола приведено в Приложении 3. Метод INVITE может использоваться для изменения характеристик уже организованных каналов с новым описанием сеанса связи.

3.4.4. При успешной обработке сервером поступившего запроса INVITE сервер должен выдать положительный ответ, после получения которого, клиент посылает соответствующий запрос АСК, подтверждающий получение ответа и содержащий окончательные параметры описания сеанса связи.

3.4.5. Для предоставления клиенту возможности запрашивать информацию о параметрах соединения с заданным URI до начала установления соединения должен использоваться метод OPTIONS.

3.4.6. Для регистрации нового местоположения клиента должен использоваться метод REGISTER.

3.4.7. Для предоставления вызываемому или вызывающему клиенту возможности завершения соединения используется метод BYE.

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

3.4.9. Для обеспечения качества обслуживания QoS может применяться резервирование ресурсов для заданного сеанса связи в соответствии с протоколом RSVP (RFC 2205).

3.5. Ответы

3.5.1. Ответы образуют входной поток. Структура ответов сервера должна соответствовать п.5. Приложения 2.

3.5.2. Сервер SIP v.2.0. должен поддерживать ответы с кодами статуса, приведенными в Таблице 1.

Запрос обрабатывается. Например, сервер обращается к базам данных, но местоположение вызываемого пользователя в настоящий момент не определено.

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

Прокси-сервер переадресует вызов к другому пользователю.

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

Команда успешно выполнена.

Вызываемый пользователь доступен по нескольким адресам. Вызывающий пользователь может выбрать любой из них.

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

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

Вызываемая сторона может принять входящий вызов только через прокси-сервер. Вызывающая сторона должна обратиться к прокси по адресу в Contact.

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

В запросе обнаружена синтаксическая ошибка.

Требуется проведение процедуры авторизации пользователя.

Требуется предварительная оплата услуг.


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

Сервер не обнаружил вызываемого пользователя в домене, указанном в поле Request-URI.

Не разрешается передавать запрос этого типа на адрес, указанный в поле request-URI. В поле Allow ответа указываются разрешенные типы запросов.

Ответы, генерируемые вызываемой стороной, не будут поняты вызывающей стороной.

Клиент должен подтвердить свое право доступа к прокси-серверу.

Сервер не может передать ответ в течение промежутка времени, указанного в поле Expire.

Обработка запроса register не может быть завершена из-за конфликта между действием, определенным в параметре action запроса, и текущим состоянием ресурсов.

Сервер больше не имеет доступа к запрашиваемому ресурсу и не знает, куда передавать запрос.

Требуется указать длину тела сообщения в поле Content-Length.

Размер запроса слишком велик для обработки.

Адрес, указанный в поле request-URI, оказался слишком большим, поэтому его интерпретация невозможна.

Запрос содержит не поддерживаемый формат тела сообщения.

Сервер не понял расширение протокола, специфицированное в поле Require.

Вызываемый пользователь временно недоступен.

Посылается в ответ на получение запроса BYE, не относящегося к текущим соединениям, или запроса CANCEL, не относящегося к текущим запросам.

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

Сервер обнаружил в поле Via, что принятый им запрос прошел через большее количество прокси-серверов, чем разрешено в поле Max-Forwards.

Сервер принял запрос с неполным адресом в поле То или Request-URI. Требуется дополнительная адресная информация.

Адрес вызываемого пользователя неоднозначен. В заголовке Contact ответа может содержаться список адресов, по которым этот запрос можно передать.

В настоящий момент вызываемый пользователь не желает или не может принять вызов на этот адрес. Ответ не исключает возможности связаться с пользователем по другому адресу.

Внутренняя ошибка сервера.

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

Сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответов сервера, к которому он направил запрос.

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

Сервер, функционирующий в качестве шлюза или прокси-сервера, в течение установленного интервала времени не получил ответ от сервера, к которому он обратился для завершения обработки ответа.

Сервер не поддерживает данную версию протокола SIP.

Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может указывать подходящее для вызова время.

Вызываемый пользователь не может или не желает принимать входящие вызовы. В ответе может быть указано подходящее время для вызова.

Вызываемого пользователя не существует.

Вызываемый пользователь не может принять входящий вызов из-за того, что вид информации, указанный в описании сеанса связи в формате SDP, полоса пропускания и т.д. неприемлемы.

3.5.3. В ответе сервера обязательно должно присутствовать поле Date, содержащее дату и время генерации сообщения сервером.

3.5.4. В таблице 2 приведены категории ответов, генерируемые различными SIP-объектами.

Агент пользователя сервера

Действия аналогичные действиям SIP-клиента

Возврат ответа с кодами 1хх

Возврат ответа с кодами 2хх

Возврат ответа с кодами 3хх

Возврат ответа с кодами 4хх

Возврат ответа с кодами 5хх

Возврат ответа с кодами 6хх

Включение поля Via

4. ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ ВЗАИМОДЕЙСТВИЯ SIP-ОБЪЕКТОВ

4.1. Действия SIP-клиента

4.1.1. Инициатор может использовать два метода для приглашения ответчика на конференцию: послать запрос на локальный прокси-сервер или послать запрос непосредственно вызываемой стороне в соответствии с заданным Request-URI.

4.1.2. Для первого случая вызывающий клиент посылает запрос на разрешенный SIP- сервер. Запрос и все ответы с него образуют SIP-транзакцию. Ответы содержат некоторые значения полей Call-ID, Cseq, To, From, которые соответствуют посланному запросу.

4.1.3. Для второго случая вызывающий клиент должен сам определить протокол, порт, IP-адрес вызываемой стороны, используя SRV-запросы к серверу DNS в соответствии с RFC 2052.

4.1.4. Клиент может кэшировать успешные ответы DNS-сервера, которые должны быть аннулированы по истечении срока жизни.

4.1.5. При изменении местоположения вызываемая сторона должна зарегистрировать свое новое местоположение на сервере определения местоположения. Информация о новом местоположении пользователя возвращается сервером переадресации в поле Contact.

4.1.6. Если прокси-сервер продвигает запрос, то он должен добавить в начало списка продвижения заголовок Via. Via используется для обратного продвижения ответа. В ответе каждый хост должен удалить свое значение Via.

4.1.7. Прокси-сервер может организовать параллельный поиск при неопределенном местоположении ответчика. Если прокси-сервер при продвижении запроса генерирует несколько разветвленных запросов, то вызываемый агент пользователя должен возвратить ответ только на первый пришедший запрос с заданным Call-ID. Дубликаты запроса не являются ошибкой.

4.2. Функционирование SIP-клиентов и серверов

4.2.1. Серверы при получении от клиента изоморфного запроса должны отбросить запрос и выдать соответствующий ответ. Если заголовок From не соответствует существующим маршрутам, то создается новый маршрут вызова. Если Call-ID не соответствует текущим сеансам, то создается новый маршрут со значениями То, From и Call-ID из заголовков запроса. Заголовок То не должен содержать тегов.

4.2.2.Серверы могут выдать один или более промежуточных ответов в любое время перед посылкой окончательного ответа. Если прокси-сервер с сохранением состояния, агент пользователя сервера, сервер переадресации или сервер регистрации не могут ответить на запрос окончательным ответом в течение 200 мс, то они должны выдать промежуточный ответ с кодами 1хх. Сервер без сохранения состояния не должен выдавать промежуточных ответов.

4.2.3. Если прокси-сервер с сохранением состояния получил ответ на запрос, информации о котором он не имеет, и заголовок Via описывает протокол TCP, то он должен установить TCP-соединение по заданному адресу и передать ответ.

4.2.4. Прокси-сервер с сохранением состояния должен удерживать соединение не менее 32 сек при получении первого заключительного ответа не с кодом 200 для случая повторной передачи ответа.

4.2.5. Групповые запросы по UDP должны содержать поле Request-URI, соответствующее данной административной системе. Ответ на групповой запрос должен быть групповым. Серверы на групповые запросы не должны выдавать ответы отличные от 2хх или 6хх. Сервер может подавить ответы с другими кодами, полученные от других серверов. Сервер может задержать отправку ответов для равномерного их распределения в течение 1 сек. Прокси-сервер или агент пользователя клиента должны послать запрос CANCEL при получении первого ответа с кодом 2хх или 6хх на групповой запрос.

4.2.6. Повторная передача запросов BYE, CANCEL, OPTIONS или REGISTER осуществляется SIP-клиентом только при использовании в качестве транспорта протокола UDP. Временные интервалы для повторной передачи рассчитываются следующим образом. Первая повторная передача через интервал Т1, вторая — 2*Т1, третья — 4*Т1 и так далее пока значение не достигнет интервала Т2, все последующие передачи через интервал Т2. При получении первого промежуточного ответа повторная передача осуществляется через интервал Т2. Значения интервалов Т1 и Т2 должны быть не меньше 500 мс и 4 сек соответственно. Сервер должен кэшировать окончательный ответ в течение 10*Т2. Число повторных передач должно быть ограничено для избежания перегрузок в сети. При получении запроса CANCEL каждый прокси-сервер должен генерировать соответствующее число запросов CANCEL на сгенерированные ранее повторные запросы.

4.2.7. Повторная передача запроса INVITE выполняется следующим образом. SIP-клиент начинает повторно передавать запрос INVITE с интервалом Т1, удваивая в дальнейшем этот интервал с каждым посланным пакетом. Клиент осуществляет повторную передачу пока не получит промежуточный или окончательный ответ, но не более 7 раз. Сервер посылает промежуточный ответ на каждый дублирующий запрос. Сервер повторно посылает окончательный ответ с интервалом Т1, удваивая его с каждым последующим пакетом, пока не получит запрос АСК, BYE, CANCEL или пока число посланных ответов не достигнет 7.

4.2.8. Запрос АСК не должен генерировать ответ для избежания формирования петли.

4.3. Функционирование агента пользователя клиента и сервера

4.3.1. Для осуществления вызова агент пользователя клиента формирует запрос INVITE, в котором поле То содержит адрес вызываемой стороны, Request-URI содержит тот же самый адрес, поле From содержит адрес вызывающей стороны. Если адрес в поле From был сформирован другим агентом пользователя клиента, то вызывающая сторона должна включить параметр тега в поле From. Агент пользователя клиента может добавить в поле Contact адрес для обеспечения взаимодействия с вызывающей стороной.

4.3.2. После получения запроса INVITE вызывающая сторона может обработать, переадресовать или отклонить запрос. В ответ должны быть скопированы из запроса поля То, From, Call-ID, Cseq и Via. Дополнительно агент пользователя сервера может добавить в ответе параметр тега в поле То, если в запросе содержался более чем один заголовок Via.

4.3.3. На один посланный запрос INVITE может прийти несколько ответов. Каждый ответ отличается параметром тега в поле То и каждый соответствует отдельному маршруту вызова. Вызывающая сторона может подтвердить или завершить вызов с каждым отвечающим агентом пользователя сервера. Для подтверждения посылается запрос АСК, для завершения запрос BYE. Запросы АСК и BYE должны содержать те же поля То, From с любыми параметрами тегов, что и в ответе агента пользователя сервера с кодом 200. Request-URI может быть взят из поля Contact (если оно представлено) или из поля То из ответа с кодом 200. Для маршрута вызова То — удаленный адрес, From — локальный адрес.

4.3.4. После установления вызова вызывающая или вызываемая стороны могут генерировать запросы INVITE или BYE для изменения или завершения вызова. Для этого используются значения То и From из предыдущих запросов или ответов.

4.3.5. При получении последующих запросов сервер может их интерпретировать следующим образом:

— установить новое соединение, если Call-ID неизвестно, независимо от полей То и From;

— считать повторной передачей, если Call-ID, To, From, Cseq имеют те же значения, что и в предыдущем запросе;

— считать новой транзакцией для уже существующего вызова (с теми же значениями Call-ID,To и From), если значение Cseq больше, чем в предыдущем вызове.

4.4. Функционирование прокси-сервера и сервера переадресации

4.4.1. Сервер переадресации не посылает собственные SIP-запросы. После получения запроса, отличного от CANCEL, сервер переадресации формирует список альтернативных значений местоположения и возвращает окончательный ответ класса 3хх или отклоняет запрос. При получении запроса CANCEL формирует ответ с кодом 2хх. Этот ответ завершает SIP-транзакцию.

4.4.2. Агент пользователя сервера аналогичен серверу переадресации, за исключением, того, что он также обрабатывает запросы и может возвратить ответ с кодом класса 2хх.

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

4.4.4. Прокси-сервер с сохранением состояния функционирует, как сервер при получении запросов и как клиент при генерации исходящих запросов, за исключением случая при получении ответа с кодом 2хх на запрос INVITE. Вместо генерации АСК он направляет ответ с кодом 2хх обратно во входной поток вызывающей стороны.

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

4.4.6. Для предотвращения зацикливания прокси-сервер должен проверять наличие своего адреса в поле Via при получении входящего запроса. Поля То, From, Call-ID и Contact должны быть скопированы из исходных полей, Request-URI должен содержать адрес, куда направляется запрос. Прокси-сервер всегда включает свой адрес в заголовок Via в выходящие запросы, вызванные входящим запросом. На один входящий запрос сервер может генерировать несколько исходящих (процесс разветвления).

4.4.7. Прокси-сервер обрабатывает только те ответы, в которых в поле Via содержится его адрес. Остальные ответы пропускаются.

4.4.8. Прокси-сервер с сохранением состояния удаляет при обработке из ответов поля Via, содержащие его адрес, и проверяет адреса в других полях Via. Для соединения UDP ответы посылаются по списку адресов, указанных в теге «maddr» (если он представлен), иначе по адресу, указанному в теге «received» (если он представлен), и в заключении по адресу из поля «sentby’. Прокси-сервер должен оставаться сервером с сохранением состояния при получении запросов по TCP-соединению. Сервер должен проверять, что установленное по заданному адресу TCP-соединение открыто. Ответы не с кодом 2хх могут повторно передаваться и по ТСР-соединению.

4.4.9. Прокси-сервер без сохранения состояния не должен генерировать свои промежуточные ответы. На один входящий запрос, как правило, сервер генерирует один исходящий запрос. Сервер должен кэшировать ответы для ускорения обработки повторных передач.

4.4.10. Прокси-сервер с сохранением состояния должен автоматически передавать повторно посланные промежуточные или окончательные ответы. Сервер может генерировать свои промежуточные ответы с кодом 1хх.

4.4.11. При получении запроса АСК сервером с сохранением состояния сравниваются значения полей То, From, Cseq, Call-ID со значениями из предыдущих запросов. Если они не соответствуют, то запрос обрабатывается аналогично запросу INVITE. Если они соответствуют, то сервер должен послать ответ с кодом 200 во входной поток, а запрос АСК передать дальше.

4.5. Идентификация доступа

4.5.1. Для начала процедуры идентификации должен использоваться ответ 401 (или 407 для идентификации на прокси-сервере) с полем WWW-Authenticate (Proxy-Authenticate). В процедуре идентификации должно использоваться содержимое поля запроса Authorization (Proxy-Authorization). Если сервер не принимает сообщение клиента с полем Authorization (Proxy-Authorization), он снова должен выдать ответ 401.

4.5.2. Если сервер поддерживает первичную схему идентификации доступа, ее реализация должна соответствовать п.8.1. Приложения 2.

4.5.3. Если сервер поддерживает обзорную схему идентификации доступа, ее реализация должна соответствовать п.8.2. Приложения 2.

4.5.4. Если сервер поддерживает схему идентификации доступа PGP, ее реализация должна соответствовать п.8.3. Приложения 2.

4.6. Обеспечение широковещательной рассылки

4.6.1. Широковещательная рассылка обеспечивается посылкой множественных запросов с использованием протокола UDP. Запрос должен быть распространен только в пределах своей административной системы.

4.6.2. Широковещательный запрос имеет независимое Request-URI. Ответы на широковещательный запрос имеют TTL такое же, что и TTL в заголовке Via из полученного запроса.

4.6.3. Клиент, пославший широковещательный запрос, не должен проверять Request-URI, соответствующий его собственному хосту или доменному имени.

4.6.4. Если запрос был послан, как широковещательный, то и ответ должен быть широковещательным.

4.6.5. Сервер не должен выдавать ответ на широковещательный запрос с кодом отличным от 2хх или 6хх. Сервер задерживает свои ответы в интервале от 0 до 1 сек.

4.6.6. Сервер может подавлять ответы, если они посланы подчиненным членом, или ответы с кодом 6хх, посланные от другого члена группы.

4.6.7. Сервер не должен отвечать на широковещательный запрос CANCEL.


4.6.8. Прокси-сервер или агент пользователя клиента должен послать CANCEL на полученный первый ответ с кодом 2хх или 6хх широковещательного запроса.

5. ВЗАИМОДЕЙСТВИЕ ПРОТОКОЛА SIP С ДРУГИМИ ПРОТОКОЛАМИ, ОБЕСПЕЧИВАЮЩИМИ ПОДДЕРЖКУ ПЕРЕДАЧИ РЕЧЕВОЙ ИНФОРМАЦИИ ПО СЕТЯМ ПЕРЕДАЧИ ДАННЫХ С ПРОТОКОЛОМ IP

5.1. Сервер определения местоположения может использовать также один из следующих протоколов:

— протокол finger, который должен быть реализован в соответствии с RFC 1288;

— протокол rwois, который должен быть реализован в соответствии с RFC 2167;

— протокол LDAP, который должен быть реализован в соответствии с требованиями «Средства технические телематических служб. Сервер LDAP. Технические требования», утвержденными Минсвязи России 24.08.2001.

5.2. Для описания устанавливаемого сеанса связи может быть использован протокол описания параметров связи SDP в соответствии с RFC 2327.

5.3. Для передачи речевой информации используется транспортный протокол реального времени RTP, который должен соответствовать требованиям РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

5.4. Для обеспечения качества обслуживания трафика речевых приложений используется протокол резервирования ресурсов RSVP, который должен соответствовать требованиям RFC 2205.

5.5. Для синхронизации работы устройств управления шлюзами протокол SIP может взаимодействовать с протоколом управления шлюзами MGCP, который должен соответствовать с требованиями RFC 2705.

6. ВЗАИМОДЕЙСТВИЕ С ТФОП

6.1. Взаимодействие с телефонной сетью общего пользования должно удовлетворять требованиям раздела 6.6. РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

7. ТРЕБОВАНИЯ К КОНСТРУКЦИИ

7.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к конструкции должна удовлетворять требованиям раздела 6.10 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

8. ТРЕБОВАНИЯ К ЭЛЕКТРОПИТАНИЮ

8.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к электропитанию должна удовлетворять требованиям раздела 6.11 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

9. ТРЕБОВАНИЯ К УСТОЙЧИВОСТИ К ВОЗДЕЙСТВИЮ ВНЕШНИХ ФАКТОРОВ

9.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к устойчивости к воздействию внешних факторов должна удовлетворять требованиям раздела 6.12 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

10. ТРЕБОВАНИЯ К НАДЕЖНОСТИ

10.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к надежности должна удовлетворять требованиям раздела 6.13 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

11. ТРЕБОВАНИЯ К ЭЛЕКТРОМАГНИТНОЙ СОВМЕСТИМОСТИ

11.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к электромагнитной совместимости должна удовлетворять требованиям раздела 6.14 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

12. ТРЕБОВАНИЯ К МАРКИРОВКЕ И УПАКОВКЕ

12.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к маркировке и упаковке должна удовлетворять требованиям раздело 6.15 и 6.16 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

13. ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ ПЕРСОНАЛА

13.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к безопасности персонала должна удовлетворять требованиям раздела 7 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

14. ТРЕБОВАНИЯ К ТРАНСПОРТИРОВАНИЮ И ХРАНЕНИЮ

14.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом ЕР с использованием SIP-протокола, в части требований к транспортированию и хранению должна удовлетворять требованиям раздела 8 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

15. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ

15.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IР с использованием SIP-протокола, в части требований к документации должна удовлетворять требованиям раздела 9 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

16. ТРЕБОВАНИЯ К ПРАВИЛАМ ПРИЕМКИ И МЕТОДАМ КОНТРОЛЯ

16.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IР с использованием SIP-протокола, в части требований к правилам приемки и методам контроля должна удовлетворять требованиям раздела 10 РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденного Гостелекомом России 12.11.99.

ПРИЛОЖЕНИЕ 1. ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

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

Маршрут вызова — идентификатор, состоящий из комбинации Call-ID, To, From.

Клиент — прикладная программа, посылающая SIP-запросы.

Конференция — мультимедийный сеанс, определенный общим описанием сеанса.

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

Окончательный ответ — ответ, завершающий SIP-транзакцию.

Инициатор — сторона, приглашающая на конференцию.

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

Ответчик — участник или служба, которых вызывающая сторона пытается пригласить на конференцию.

Изоморфный запрос или ответ — два запроса или ответа, имеющие одни и те же значения полей заголовка Call-ID, To, From, Cseg.

Сервер определения местоположения — служба, используемая сервером переадресации или прокси-сервером для получения информации о возможном местоположении вызываемой стороны.

Параллельный поиск — выдача нескольких запросов прокси-сервером на полученный входящий запрос для получения информации о возможном местоположении пользователя.

Промежуточный ответ — ответ сервера, характеризующий процесс, но не завершение SIP-транзакции.

Прокси — программа-посредник, выполняющая функции сервера и клиента с целью выполнения запросов от имени других клиентов.

Сервер переадресации — сервер, который принимает SIP-запрос, отображает адрес в ноль или более новых адресов и возвращает эти адреса клиенту.

Сервер — прикладная программа, которая принимает запросы по порядку для их обслуживания и посылает обратно ответы на эти запросы.

Сеанс — набор мультимедийных отправителей и получателей и поток данных, направленных от отправителей получателям.

SIP-транзакция — взаимодействие между клиентом и сервером, включающее все сообщения от первого запроса, посланного от клиента серверу, до финального (не 1хх) ответа, посланного от сервера клиенту. Транзакция определяется номером последовательности CSeq вместе с единственным маршрутом вызова.

Входной поток — ответы, посланные от агента пользователя сервера агенту пользователя клиента.

Агент пользователя клиента — приложение клиента, которое инициирует SIP-запросы.

Агент пользователя сервера — приложение сервера, которое взаимодействует с пользователем при получении SIP-запроса и возвращает ответ от имени другого пользователя.

Запрос — сообщение запроса SIP.

Ответ — сообщение ответа SIP.

Содержание — информация, передаваемая в виде полезной нагрузки запроса или ответа. Содержание состоит из метаинформации в форме полей заголовка содержания и содержимого в форме тела содержания.

Заголовок сообщения SIP — 1. набор строк между первой строкой сообщения (start-line) и пустой строкой, отделяющей заголовок от тела сообщения. 2. строка (несколько строк), содержащая выражение, задающее значение для отдельного поля заголовка сообщения.

IANA (Internet Assigned Numbers Autority) — орган назначения чисел Интернет.

CR — символ возврата каретки

LF — символ перевода строки

MGCP — протокол управления шлюзами

LDAP — облегченный протокол доступа к директории

PGP — протокол шифрования сообщений

RSVP — протокол резервирования ресурсов

RTP — протокол транспортировки в реальном времени

RTCP — протокол контроля транспортировки информации в реальном времени

SDP — протокол описания параметров связи

SIP — протокол инициирования сеансов связи

SRV — тип ресурсной записи DNS, обозначающий местонахождение сервера в домене, который обеспечивает определенный сервис

TCP — протокол управления передачей данных

UDP — протокол передачи дейтаграмм пользователя

TTL — время существования

URI — единообразный идентификатор ресурса

URL — единообразный указатель ресурса

Finger — протокол проверки наличия пользователя по ID

Rwhois — протокол представления информации о сетевых объектах и ресурсах

ПРИЛОЖЕНИЕ 2. ОПИСАНИЕ ПРОТОКОЛА SIP

1. Базовые определения

Спецификация синтаксиса запросов и ответов SIP приводится в расширенной форме Наура-Бекуса, соответствующей RFC-822.

Базовые определения:

Параметры протокола / rfc 2068

Этот документ содержит спецификацию стандарта DoD (Министерство обороны США) для протокола IP (IP). Документ основан на 6 предварительных вариантах спецификации протокола ARPA Internet и содержит фрагменты этих спецификаций. В разработке используемых в документе концепций и терминологии принимало участие множество людей. В данной редакции пересмотрены вопросы адресации, обработки ошибок, кодирования опций, приоритетов, изоляции (compartments) и ограничений протокола Internet.

Jon Postel, редактор

За время, прошедшее с момента завершения данного документа протокол IP стал одним из самых распространенных протоколов сетевого уровня ISO/OSI и сегодня этот протокол используется практически на каждом компьютере. Однако за прошедшие годы сильно изменилось толкование некоторых используемых в документе терминов и в переводе используются термины в их современном толковании, дабы не порождать путаницы.

Термин gateway в исходном документе использовался для обозначения устройств, которые сегодня называют маршрутизаторами (router), а термин шлюз (буквальный перевод gateway) обозначает обычно устройства (программы), обеспечивающие преобразование протоколов на более высоких уровнях модели ISO/OSI (например, почтовые шлюзы).

Термин Internet фактически перестал быть нарицательным именем и служит, прежде всего, для обозначения всего множества связанных между собой IP-сетей в масштабе планеты. Поэтому столь распространенное в оригинальном документе словосочетание protocol internet в переводе указывается как протокол IP.

Часто встречающийся в исходном документе термин local network interface переводится как ‘интерфейс канального уровня», в соответствии с современной терминологией.

Оглавление

1. Введение

1.1. Мотивация

Протокол IP предназначен для использования в соединенных между собой компьютерных сетях обмена данными на основе коммутации пакетов. Такие системы получили название catenet [1]. Протокол обеспечивает передачу блоков данных, называемых дейтаграммами между отправителем и получателем, хосты которых идентифицируются адресами фиксированной длины. Протокол также обеспечивает фрагментацию и сборку для дейтаграмм большого размера, если сеть не позволяет передать дейтаграмму целиком.

1.2. Сфера действия протокола

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

1.3. Интерфейсы

Этот протокол вызывается протоколами взаимодействия «хост-хост» и сам вызывает функции локальных сетевых протоколов для передачи дейтаграмм следующему маршрутизатору или хосту-получателю.

Например, модуль TCP будет вызывать модуль IP для размещения сегмента TCP (заголовок TCP и пользовательские данные) как объекта данных дейтаграммы IP. Модуль TCP будет указывать адреса и другие параметры заголовка IP в качестве аргументов при вызове функции IP. Модуль IP будет создавать дейтаграмму IP и обращаться к локальному сетевому интерфейсу для передачи дейтаграммы.

Для случая ARPANET, например, модуль IP будет вызывать модуль локальной сети, который добавит заголовок типа 1822 [2] к дейтаграмме, создавая сообщение ARPANET для передачи IMP. Адрес ARPANET определяется из адреса IP интерфейсом с локальной сетью и будет принимать значение адреса какого-либо из хостов ARPANET, который может быть шлюзом в другую сеть.

1.4. Работа протокола

Протокол IP выполняет две основных функции — адресацию и фрагментацию/сборку дейтаграмм.

Модули IP используют адреса из заголовков IP для передачи дейтаграмм в направлении получателя. Процесс выбора пути к адресату называется маршрутизацией.

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

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

Протокол IP трактует каждую дейтаграмму как независимый элемент, не связанный с другими дейтаграммами IP. Протокол не использует соединения или логических устройств (виртуальных или иных).

Для обеспечения сервиса протокол IP использует 4 ключевых механизма — ToS (тип обслуживания), TTL (время жизни), Options (опции) и Header Checksum (контрольная сумма заголовка).

Тип обслуживания (ToS) используется для индикации желаемого качества сервиса. ToS представляет собой абстрактный или обобщенный набор параметров, характеризующих выбранный сервис, который обеспечивается в сетях, образующих Internet. Индикация ToS используется маршрутизаторами для выбора реальных параметров передачи применительно к конкретной сети, следующего интервала или следующего маршрутизатора при доставке дейтаграмм IP.

Время жизни TTL определяет максимальный срок существования дейтаграмм IP. Это значение устанавливается отправителем и уменьшается в каждой точке на пути доставки, где дейтаграмма подвергается обработке. Если значение TTL становится нулевым до того, как дейтаграмма будет доставлена адресату, такая дейтаграмма просто уничтожается. Можно рассматривать TTL как время саморазрушения дейтаграмм.

Опции обеспечивают функции контроля требуемые или полезные в некоторых ситуациях, но не используемые для большинства рутинных задач. Опции включают временные метки, параметры безопасности и специальные средства маршрутизации.

Контрольная сумма заголовка обеспечивает возможность проверки корректности передачи дейтаграмм IP. Если при передаче дейтаграмма была повреждена вычисленная заново при обработке контрольная сумма заголовка не совпадет с содержащимся в дейтаграмме значением контрольной суммы и такая дейтаграмма отбрасывается как ошибочная.

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

При обнаружении ошибок информация о них может передаваться с помощью протокола ICMP (Internet Control Message Protocol) [3], реализуемого в модуле IP.

2. Обзор

2.1. Связь с другими протоколами

На приведенном рисунке (Рисунок 1) показаны связи IP с другими протоколами:

Протокол IP взаимодействует с протоколом вышележащего уровня (протоколы взаимодействия между хостами — host-to-host) и с нижележащим протоколом локальной сети (в этом контексте локальной сетью может считаться небольшая сеть в одном здании или распределенная сеть типа ARPANET).

2.2. Модель работы протокола

Модель передачи дейтаграмм от одной прикладной программы к другой можно проиллюстрировать описанным ниже сценарием.

Будем предполагать что передача включает лишь один промежуточный шлюз.

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

Модуль IP готовит заголовок дейтаграммы и присоединяет к нему данные. После этого модуль IP определяет локальный сетевой адрес для указанного получателя (в данном случае это адрес шлюза).

Модуль передает дейтаграмму и локальный адрес локальному сетевому интерфейсу.

Интерфейс канального уровня создает заголовок и присоединяет к нему дейтаграмму IP, после чего пакет передается в локальную сеть.

Дейтаграмма приходит на хост-шлюз в пакете канального уровня. Интерфейс канального уровня удаляет заголовок канального уровня и передает дейтаграмму модулю IP. Модуль IP определяет на основе IP-адреса, что дейтаграмму следует переслать хосту другой сети. Тогда модуль IP определяет адрес канального уровня для пересылки дейтаграммы получателю и вызывает интерфейс канального уровня той сети, куда будет передаваться дейтаграмма.

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

2.3. Функциональное описание

Задачей протокола IP является перемещение дейтаграмм через множество соединенных между собою сетей. Эта задача решается путем передачи дейтаграмм от одного модуля IP к другому, пока дейтаграмма не будет доставлена адресату. Модули IP размещаются на хостах и шлюзах (маршрутизаторах) Internet. Дейтаграммы маршрутизируются от одного модуля IP к другому через промежуточные сети на основе интерпретации адресов IP. Таким образом, одним из важнейших механизмов IP является адресация.

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

Адресация

Следует различать имена, адреса и маршруты [4]. Имя указывает объект, который мы видим. Адрес показывает местонахождение, а маршрут говорит, как до него добраться. Протокол IP имеет дело преимущественно с адресами. Отображение адресов на имена и обратно (преобразование) является задачей протоколов более высоких уровней (т. е., транспортного и сеансового). Модуль IP преобразует адреса IP в адреса локальной сети. Отображение адресов локальной сети в маршруты является задачей процедур нижележащего уровня (т. е.. локальной сети или шлюзов).

Адреса имеют IP фиксированную длину — 4 октета (32 бита). Адрес начинается с номера сети, за которым следует локальный адрес (его называют полем rest — остаток). Существует три класса адресов IP — класс A, в котором старший бит имеет значение 0, остальные 7 битов старшего октета задают номер сети, а 24 младших бита — номер хоста; класс B, в котором два старших бита имеют значения 10, следующие 14 битов определяют номер сети, а последние 16 битов — номер хоста; класс C, в котором три старших бита имеют значения 110, следующие 21 образуют номер сети, а последние 8 битов определяют номер хоста.

Следует с осторожностью относиться к преобразованию адресов IP в адреса локальной сети, поскольку один физический хост может функционировать как несколько различных хостов, использующих разные адреса IP. И наоборот, некоторые хосты могут использовать множество физических интерфейсов (многодомные хосты — multi-homing).

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

Примеры отображения адресов приводятся в работе Address Mappings [5].

Фрагментация

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

Дейтаграмма IP может быть помечена как don’t fragment (не фрагментировать). Такие дейтаграммы не будут фрагментироваться ни при каких обстоятельствах. Если нефрагментируемая дейтаграмма IP не может быть доставлена адресату без фрагментации, она просто отбрасывается.


Допускается использование невидимой для модуля IP фрагментации, передачи и сборки дейтаграмм в локальной сети [6].

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

Поле идентификации позволяет различать фрагменты разных дейтаграмм. Отправляющий дейтаграмму модуль протокола устанавливает значение поля идентификации в каждой дейтаграмме так, чтобы оно было уникальным для данной пары отправитель-получатель и протокола в течение времени присутствия дейтаграммы в сети Internet. Этот модуль также устанавливает нулевые значения смещения фрагмента и флага наличия других фрагментов (more-fragments flag).

Для фрагментирования длинной дейтаграммы IP модуль IP (например, на маршрутизаторе) создает две новых дейтаграммы IP и копирует содержимое полей заголовка из длинной дейтаграммы в заголовки обеих новых дейтаграмм. Данные исходной дейтаграммы делятся на две части по 64 битовой (8 октетов) границе. Вторая часть дейтаграммы может иметь размер, не кратный 8 октетам (64 битам), но первая часть должна содержать целое число 8-октетных блоков. Назовем число 8-октетных блоков в первой части дейтаграммы NFB (Number of Fragment Blocks — число блоков фрагментации). Первая часть дейтаграммы помещается в первую из новых дейтаграмм IP и поле длины устанавливается в соответствии длиной первой дейтаграммы. Для первой дейтаграммы устанавливается флаг наличия дополнительных фрагментов. Вторая часть данных помещается во вторую из созданных заново дейтаграмм и поле размера устанавливается в соответствии с длиной новой дейтаграммы. Значение поля смещения увеличивается на величину NFB. Значение флага наличия дополнительных фрагментов сохраняется в соответствии с флагом исходной нефрагментированной дейтаграммы.

Эту процедуру легко обобщить на случай разбиения дейтаграммы на n фрагментов, где n > 2. Для сборки фрагментов дейтаграммы IP, модуль IP (например, на хосте адресата) объединяет дейтаграммы IP с совпадающими значениями полей идентификации, адресов отправителя и получателя, а также протокола. Объединение осуществляется путем размещения данных из каждой дейтаграммы в позицию буфера, указанную полем смещения фрагмента в заголовке IP. Первый фрагмент будет иметь нулевое смещение, а для последнего фрагмента флаг more-fragments будет иметь нулевое значение.

2.4. Шлюзы

Шлюзы обеспечивают пересылку дейтаграмм IP между сетями, обеспечивая также поддержку протокола GGP (Gateway to Gateway Protocol — протокол обмена данными между шлюзами) [7] для обмена данными маршрутизации и другой управляющей информацией.

В шлюзах реализация протоколов вышележащих уровней не обязательна и функции GGP могут быть реализованы в модуле IP.

3. Спецификация

3.1. Формат заголовка IP

Заголовок дейтаграмм internet имеет следующий формат:

Version — 4 бита Это поле указывает номер версии протокола и определяет формат заголовка. Данная спецификация описывает версию 4.

IHL — 4 бита Это поле содержит размер заголовка IP в 32-битовых словах и указывает на начало данных. Отметим, что минимальное значение этого поля для корректного заголовка составляет 5.

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

биты 0-2: предпочтения.
бит 3: 0 = обычная задержка, 1 = малая задержка.
бит 4: 0 = обычная пропускная способность, 1 = высокая пропускная способность.
бит 5: 0 = обычная надежность, 1 = высокая надежность.
биты 6-7: зарезервированы для использования в будущем.

111 — управление сетью

110 — межсетевое управление

Использование флагов Delay, Throughput, Reliability может увеличивать стоимость (в том или ином смысле) обслуживания. Во многих сетях предпочтение по одному из этих параметров может быть связано с потерями по другому. За исключением специальных случаев следует использовать не более двух флагов из 3 возможных.

Значение ToS используется для задания способа обработки дейтаграмм в процессе их передачи через internet. Например, отображение значений ToS на реальные параметры обслуживания в сетях AUTODIN II, ARPANET, SATNET, PRNET описано в работе Service Mappings [8].

Уровень предпочтения Network Control (управление сетью) означает, что дейтаграмма предназначена для использования внутри сети. Реальная трактовка этого обозначения определяется местными условиями сети. Значение Internetwork Control (межсетевое управление) показывает дейтаграммы, предназначенные только для управления шлюзами. Если та или иная сеть использует значение уровня предпочтения, она берет на себя ответственность за доступ к этим полям и их использование.

Total Length — 16 битов

Это поле указывает общий размер (в октетах) дейтаграммы с учетом заголовка и данных. Размер этого поля позволяет создавать дейтаграммы длиной до 65 535 октетов. Столь большие дейтаграммы неприемлемы для большинства хостов и сетей. Все хосты должны быть готовы к восприятию дейтаграмм размером до 576 октетов (целиком или в виде фрагментов). Хостам рекомендуется передавать дейтаграммы, размер которых превышает 576 октетов только в тех случаях, когда есть уверенность, что адресат может принимать такие дейтаграммы.

Значение 576 выбрано для того, чтобы дейтаграммы могли кроме заголовка содержать блок данных разумных размеров. Например, такой размер позволяет передавать блок данных размером 512 октетов с 64-октетным заголовком. Максимальный размер заголовка IP составляет 60 октетов, а размер типичного заголовка IP — 20 октетов, что оставляет достаточно места для заголовков вышележащих уровней.

Identification — 16 битов Значение поля идентификации присваивается отправителем для обеспечения корректной сборки фрагментов дейтаграммы.

Набор флагов управления.

Бит 0: (зарезервирован (должен иметь значение 0)
Бит 1: (DF) 0 = фрагментация возможна, 1 = фрагментация недопустима.
Бит 2: (MF) 0 = последний фрагмент, 1 = фрагмент не является последним.

Fragment Offset — 13 битов

Это поле показывает положение данного фрагмента в исходной дейтаграмме. Смещение измеряется в единицах, кратных 8 октетам (64 бита). Смещение первого фрагмента равно нулю.

Это поле определяет максимальный срок существования дейтаграммы в системе internet. Дейтаграммы с нулевым значением времени жизни должны уничтожаться. Значение этого поля изменяется при обработке заголовков IP. Время измеряется в секундах, но, поскольку каждый обрабатывающий дейтаграмму модуль должен уменьшать значение TTL, по крайней мере, на 1 (даже если обработка длилась меньше секунды), значение TTL следует рассматривать как верхний предел срока жизни дейтаграммы в систем. Это поле введено для того, чтобы можно было избавиться от недоставленных дейтаграмм.

Protocol — 8 битов

Это поле указывает протокол следующего уровня, содержащийся в поле данных дейтаграммы IP. Идентификаторы протоколов указаны в Assigned Numbers [9].

Header Checksum — 16 битов

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

Контрольная сумма заголовка представляет собой 16-битовое поразрядное дополнение (one’s complement) суммы поразрядных дополнений всех 16-битовых слов заголовка. При вычислении контрольной суммы значение самого поля принимается нулевым.

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

Source Address — 32 бита

Адрес отправителя (см. параграф 3.2. Обсуждение).

Destination Address — 32 бита

Адрес получателя (см. параграф 3.2. Обсуждение).

Options — переменная длина

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

Поле опций имеет переменную длину. Существует два варианта форматирования опций:

октет типа опции, октет размера опции и октеты собственно опций (поле размера опции учитывает поля типа, размера и данных опции).

Октет типа опции содержит три поля:

флаг копирования (1 бит);

класс опции (2 бита);

номер опции (5 битов).

Флаг копирования показывает, что данная опция копируется во все фрагменты дейтаграммы:

0 — опция не копируется;

1 — опция копируется во фрагменты.

Поле класса опций может принимать 4 значения:

2 — отладка и измерения;

Определены следующие номера опций IP:

Класс Номер Длина Описание
Конец списка опций (End of Option list). Эта опция занимает только 1 октет и не использует поле длины.
1 Нет операции. Эта опция занимает только 1 октет и не использует поле длины.
2 11 Безопасность (Security). Используется для передачи опций Security (безопасность), Compartmentation (изоляция), User Group (TCC), Handling Restriction Codes (коды управления ограничениями), совместимых с требованиями DOD.
3 перем. Loose Source Routing (нестрогое задание маршрута отправителем). Используется для маршрутизации дейтаграмм IP с учетом данных, указанных отправителем.
9 перем. Strict Source Routing (строгое задание маршрута отправителем). Используется для маршрутизации дейтаграмм IP на основе данных, указанных отправителем.
7 перем. Record Route (запись маршрута). Используется для трассировки пути дейтаграмм IP.
8 4 Stream ID (идентификатор потока). Используется для обозначения потоков дейтаграмм.
2 4 перем. Internet Timestamp (временная метка).

Определения отдельных опций

End of Option List:

Эта опция указывает на завершение списка опций. Граница этой опции может не совпадать с окончанием заголовка IP, указанным полем длины заголовка. Данная опция служит для того, чтобы показать завершение списка использованных для дейтаграммы опций (а не отдельной опции). Использование опции требуется только в тех случаях, когда окончание списка опций не совпадает с завершением заголовка IP.

Эту опцию можно копировать, добавлять и удалять при фрагментации или по иным причинам.

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

Эту опцию можно копировать, добавлять и удалять при фрагментации или по иным причинам.

Эта опция обеспечивает хостам способ передачи информации о безопасности, изоляции (compartmentation), ограничениях обслуживания и TCC (закрытые группы пользователей). Опция использует следующий формат:

Security (поле S) — 16 битов

Опция позволяет задать 16 уровней безопасности (8 уровней зарезервированы для использования в будущем).

Compartments (поле C) — 16 битов

Значение этого поля, содержащее только нули, означает, что передаваемые данные не требуют изоляции (compartment). Другие значения могут использоваться с разрешения Defense Intelligence Agency.

Handling Restrictions (поле H) — 16 битов

Эти значения служат для управления разметкой и являются алфавитно-цифровыми направленными графами (определены в документе Defense Intelligence Agency Manual DIAM 65-19, «Standard Security Markings»).

Transmission Control Code (поле TCC) — 24 бита

Служит для разделения трафика и определения контролируемых «групп по интересам». Значения являются графами типа trigraph и доступны в HQ DCA Code 530.

Эта опция должна копироваться при фрагментации и появляется в дейтаграмме не более одного раза.

Опция LSRR (нежестко заданный отправителем маршрут и запись пути) обеспечивает отправителям дейтаграмм IP способ предоставления маршрутной информации, используемой маршрутизаторами при пересылке дейтаграмм адресату, и записи маршрутной информации.

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

Маршрутные данные состоят из цепочки адресов IP. Каждый адрес занимает 32 бита (4 октета). Если значение указателя превышает длину, это говорит о пустом маршруте source route (завершении записи пути) и маршрутизации на основе поля адреса получателя.

Если достигнут адрес из поля адреса получателя и указатель не превышает длину опции, следующий адрес из маршрута source route заменяет значение поля адреса получателя и адрес в записываемом маршруте заменяет используемый адрес отправителя, а значение указателя увеличивается на 4.

Адресом записываемого маршрута является собственный адрес модуля IP, известный в той среде, куда пересылается дейтаграмма.

Такая процедура замены source route записанным маршрутом (хотя в них и используется обратный по отношению друг к другу порядок) означает, что опция (и весь заголовок IP) сохраняет постоянный размер при передаче дейтаграммы через internet.

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

Опция должна копироваться при фрагментации и появляется в дейтаграмме не более одного раза.

Strict Source and Record Route

Опция SSRR (жестко заданный отправителем маршрут и запись пути) обеспечивает отправителю дейтаграммы IP способ задания маршрутной информации, которая будет использоваться промежуточными маршрутизаторами для доставки дейтаграммы адресату и записи пути.

Опция начинается с идентификатора типа (137), за которым следует октет размера опции с учетом полей типа, длины, смещения и маршрутных данных. Третий октет опции содержит указатель (смещение от начала данной опции) на октет, с которого начинается следующий обрабатываемый адрес отправителя. Минимальное значение указателя составляет 4 (см. выше).

Маршрутные данные представляют собой цепочку адресов IP, каждый из которых занимает 32 бита (4 октета). Если указатель превышает размер опции, это говорит о пустом маршруте source route (завершении записи пути) и маршрутизации на основе адреса получателя.

Если достигнут адрес из поля адреса получателя и указатель не превышает длину опции, следующий адрес из маршрута source route заменяет значение поля адреса получателя и адрес в записываемом маршруте заменяет используемый адрес отправителя, а значение указателя увеличивается на 4.

Адресом записываемого маршрута является собственный адрес модуля IP, известный в той среде, куда пересылается дейтаграмма.

Такая процедура замены source route записанным маршрутом (хотя в них и используется обратный по отношению друг к другу порядок) означает, что опция (и весь заголовок IP) сохраняет постоянный размер при передаче дейтаграммы через internet.

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

Опция записи маршрута обеспечивает способ записи пути передачи дейтаграммы IP.


Опция начинается с поля типа (7), за которым следует поле длины, учитывающее полный размер опции (тип, размер, смещение, маршрутные данные). Третий октет содержит указатель на октет, с которого начинается следующая область записи маршрута. Смещение отсчитывается от начала опции, поэтому значение указателя не может быть меньше 4.

Записываемый маршрут представляет собой последовательность адресов IP, каждый из которых имеет длину 32 бита (4 октета). Если значение указателя превышает размер опции, это говорит о завершении записи маршрута. Отправляющий дейтаграмму хост должен обеспечить достаточное пространство (размер опции) для записи адресов на пути к получателю. В исходной дейтаграмме поля адресов должны иметь нулевые значения.

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

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

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

Эта опция позволяет передавать 16-битовые идентификаторы потоков SATNET через сети, которые не поддерживают концепцию потоков.

Опция должна копироваться при фрагментации и появляется в дейтаграмме не более одного раза.

Поле длины опции содержит значение, указывающее число октетов в поле типа опции, ее длины, указателя, полей Overflow, флагов и временных меток (всего до 40 октетов).

Поле указателя (Pointer) показывает смещение (в октетах) от начала опции до начала следующей временной метки. Таким образом, минимальное значение указателя равно 5. Область временных меток считается заполненной, когда значение указателя превышает размер опции.

Поле Overflow (oflw, переполнение — 4 бита) показывает число модулей IP, которые не смогли включить свои временные метки в результате нехватки места в опции.

Поле флагов (flg, 4 бита) может принимать следующие значения:

  • 0 — только временные метки, сохраняемые в последовательности 32-битовых слов;
  • 1 — перед каждой меткой помещается IP-адрес регистрирующего метку модуля;
  • 3 — поля адресов IP указываются заранее (prespecified) и модуль IP помещает временную метку только в том случае, когда адрес этого модуля указан следующим в списке адресов опции.

Поля Timestamp (временная метка) выравниваются по правому краю и содержат число миллисекунд после полуночи по универсальному времени (UT).Если невозможно указать время в миллисекундах или нет привязки к универсальному времени, в поле метки может помещаться любое значение времени, а старший бит метки должен быть установлен (1), для индикации некорректности данной метки.

Отправляющий дейтаграмму хост должен предусмотреть достаточно места для записи временных меток по пути доставки дейтаграммы. Размер опции не может увеличиваться по мере добавления меток. Исходная дейтаграмма содержит нулевые значения всех предусмотренных в опции полей временных меток (кроме заранее указанных адресов IP).

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

Если в поле записи временных меток еще остается свободное место, но полная метка не помещается, такая дейтаграмма трактуется как ошибочная и отбрасывается. Отправителю такой дейтаграммы может быть передано сообщение ICMP о некорректности параметров дейтаграммы [3].

Опция не копируется во фрагменты и передается только в первом фрагменте. Опция появляется в дейтаграмме только один раз

  • Padding — переменная длина
  • Поле заполнения служит для выравнивания размера заголовка IP по 32-битовой границе. Для заполнения используется значение 0.
  • 3.2. Обсуждение

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

    Базовый сервис internet ориентирован на обработку дейтаграмм и обеспечивает фрагментацию дейтаграмм на шлюзах и сборку фрагментов модулем IP хоста-получателя. Фрагментация и сборка дейтаграмм внутри отдельной сети или на основе частного соглашения также допустимы, поскольку процесс фрагментации и сборки совершенно прозрачен для IP и протоколов вышележащих уровней. Такая прозрачная фрагментация/сборка называется внутрисетевой (network-dependent или intranet) и не рассматривается в данной спецификации.

    Адреса IP позволяют различить отправителя и получателя на уровне хоста. Дополнительные сведения содержатся в поле протокола. Предполагается, что каждый протокол обеспечивает мультиплексирование (если оно требуется) на хосте.

    Адресация

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

    Старшие биты Формат Класс
    7 битов задают номер сети, остальные 24 — номер хоста A
    10 14 битов задают номер сети, остальные 16 — номер хоста B
    110 21 бит задает номер сети, остальные 8 — номер хоста C
    111 Используется для расширенной адресации

    Нулевое значение поля номера сети означает, что пакет адресован для данной сети. Такая адресация используется только для некоторых сообщений ICMP. Расширенный режим адресации не определен. Обе эти возможности зарезервированы для использования в будущем.

    Реальные значения, выделенные для разных групп сетевых адресов указаны в работе Assigned Numbers [9].

    Локальные адреса распределяются на уровне локальной сети и должны позволять одному физическому хосту действовать как множество различных хостов internet. Т. е., должно поддерживаться отображение между адресами IP и физическим интерфейсом хоста, позволяющее связать несколько IP-адресов с одним физическим интерфейсом хоста. Должна также поддерживаться и обратная возможность — связывания нескольких физических интерфейсов с одним адресом IP.

    Преобразование адресов IP в адреса сетей ARPANET, SATNET, PRNET и т. п. описано в работе Address Mappings [5].

    Фрагментация и сборка

    Поле идентификации (ID) используется вместе с адресами отправителя/получателя и полем протокола для идентификации фрагментов дейтаграммы при сборке.

    Флаг наличия других фрагментов (More Fragments или MF) устанавливается для всех фрагментов дейтаграммы, кроме последнего.

    Поле Fragment Offset показывает положение фрагмента относительно начала исходной (нефрагментированной) дейтаграммы. Смещение учитывается в блоках размером 8 октетов. Стратегия фрагментации разработана таким образом, чтобы в нефрагментированной дейтаграмме вся поля, связанные с фрагментацией, имели нулевые значения (MF = 0, fragment offset = 0). Если дейтаграмма IP фрагментируется, ее поле данных должно делиться на части по 8-октетным границам.

    Таким образом, используемый формат поддерживает до 213 = 8192 фрагментов по 8 октетов (т. е., до 65 536 октетов). Отметим, что это значение соответствует возможным значениям поля размера дейтаграммы в ее заголовке (естественно, заголовок показывает общую длину дейтаграммы, а не ее фрагментов).

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

    Каждый модуль IP должен поддерживать пересылку без фрагментации дейтаграмм размером 68 октетов. Это значение выбрано потому, что заголовок дейтаграммы может достигать 60 октетов и поле данных должно содержать, по крайней мере, 8 октетов.

    Каждый получатель должен поддерживать прием дейтаграмм размером, по крайней мере, 576 октетов целиком или с использованием фрагментации и сборки.

    При фрагментации могут изменяться следующие поля:

    размер заголовка дейтаграммы

    контрольная сумма заголовка.

    Если установлен флаг запрета фрагментации (DF), дейтаграммы, которые невозможно передать целиком, отбрасываются. Этот вариант используется в тех случаях, когда принимающий хост не может собирать фрагменты дейтаграммы по причине нехватки ресурсов. Примером запрета фрагментации может служить ситуация с линией к небольшому хосту. Такой хост может иметь программу самозагрузки (boot strap), которая воспринимает дейтаграмму, хранящуюся в памяти и потом выполняет содержащийся в ней код.

    Процедуры фрагментации и сборки проще описать на примерах. Описанные ниже процедуры содержат примеры реализации. Знак = Процедура:

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

    Идентификация

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

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

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

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

    Значение TOS обеспечивает выбор уровня обслуживания с помощью абстрактных параметров precedence (предпочтение, приоритет), delay (задержка), throughput (пропускная способность), reliability (надежность). Эти абстрактные параметры преобразуются в реальные параметры обработки дейтаграмм в сетях на пути доставки.

    • Precedence
    • степень важности дейтаграммы.
    • Delay
    • для таких дейтаграмм большое значение имеет время доставки.
    • Throughput
    • для дейтаграмм имеет важное значение скорость передачи данных.
    • Reliability
    • для дейтаграмм важное значение имеет надежность (гарантия) доставки.

    Например, ARPANET использует бит приоритета и разделяет «стандартные (тип 0) и неконтролируемые (тип 3) сообщения (выбор между одно- и многопакетными сообщениями также может рассматриваться как параметр обслуживания). Неконтролируемые сообщения доставляются с меньшими гарантиями, но имеют более низкую задержку. Предположим, что дейтаграмма IP доставляется через сеть ARPANET с параметрами ToS:

    Precedence: 5
    Delay:
    Throughput: 1
    Reliability: 1

    В этом случае отображение параметров сервиса на поддерживаемые в сети ARPANET параметры обслуживания приведет к установке бита приоритета ARPANET, поскольку значение precedence находится в старшей половине возможного диапазона и выбора стандартных сообщений, поскольку заданы параметры throughput и reliability, а бит delay не установлен. Более детальную информацию по этому вопросу можно найти в работе «Service Mappings» [8].

    Значение TTL устанавливается отправителем и задает максимальное время существования дейтаграммы в internet. Если время, заданное полем TTL, истекло, дейтаграмма уничтожается.

    Значение этого поля должно уменьшаться в каждой точке обработки заголовка дейтаграммы для того, чтобы учесть затраты времени на такую обработку. Даже в тех случаях, когда нет информации о затратах времени на обработку, значение поля должно уменьшаться на 1. Время жизни измеряется в секундах и максимальное значение TTL (255) соответствует 255 секундам или 4,25 мин. Поскольку каждый модуль, обрабатывающий дейтаграмму, должен уменьшать значение TTL, по крайней мере, на 1, значение TTL должно трактоваться как верхний предел срока существования дейтаграммы. Назначение поля TTL состоит в том, чтобы недоставленные дейтаграммы уничтожались и ограничить срок существования дейтаграмм в системе.

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

    Опции

    Опции являются необязательными для дейтаграмм, но все реализации должны поддерживать опции. Т. е., использование опций определяется отправителем, но каждый модуль IP должен быть способен разобрать любые опции. Поле опций может содержать несколько значений опций.

    Опции не обязательно заканчиваются на 32-битовой границе. Заголовок IP в целях выравнивания по 32-битовой границе дополняется октетами нулей. Первый из таких октетов будет интерпретироваться как завершение поля опций, а остальная часть — как обычное заполнение.

    Каждый модуль IP должен уметь обрабатывать любые опции. Опции безопасности (Security) требуются для классифицированного, и изолированного трафика, а также трафика с ограничением доступа.

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

    Контрольная сумма заголовка заново вычисляется каждый раз при изменении заголовка (например, при уменьшении TTL, добавлении или изменении опций, фрагментации дейтаграммы). Контрольная сумма на уровне IP предназначена для защиты полей заголовка от ошибок при передаче.

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

    Ошибки

    Сообщения об ошибках протокола IP могут передаваться с использованием протокола ICMP [3].

    3.3. Интерфейсы

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

    Протокол IP взаимодействует с одной стороны с локальной сетью, а с другой — с протоколом вышележащего уровня или прикладной программой. Далее протокол вышележащего уровня и прикладные программы (или даже программы шлюзов) будем называть для краткости «пользователь», поскольку они используют услуги модуля IP. Поскольку IP имеет дело с дейтаграммами между передачей отдельных дейтаграмм нет почти никакой связи и пользователь при каждом обращении к модулю IP передает ему все требуемые параметры для выполнения запрашиваемой операции.

    Пример интерфейса с вышележащим уровнем

    Ниже приведены два примера вызовов, удовлетворяющих требованиям к пользовательским вызовам IP («=>» означает возврат):

    Для передачи дейтаграммы пользователь применяет вызов SEND, передавая все требуемые аргументы. Модуль IP, принявший вызов, проверяет аргументы, готовит и передает сообщение. Если параметры указаны корректно и дейтаграмма воспринята локальной сетью, модуль возвращает сообщение об успешной передаче. Если какой-то из параметров указан некорректно или дейтаграмма не принята локальной сетью, модуль возвращает сообщение об ошибке. В таких случаях модуль должен также возвращать соответствующий отклик, указывающий причину ошибки. Уровень детализации таких откликов зависит от реализации.

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

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

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

    Адрес отправителя включается в вызов SEND, если передающий хост имеет несколько адресов (для логических или физических устройств). Модуль IP должен убедиться, что полученный адрес корректен и связан с данным хостом.

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

    В этом параграфе было дано функциональное описание интерфейса пользователь — IP. Использованные обозначения похожи на нотацию большинства языков высокого уровня, однако такое использование не требует использования «функций-ловушек» (например, SVC, UUO, EMT) или иных форм взаимодействия между процессами.

    Приложение A: Примеры и сценарии

    Пример 1

    Ниже приведен пример минимальной дейтаграммы IP, содержащей данные.

    Показанная дейтаграмма соответствует протоколу IP версии 4; заголовок содержит пять 32-битовых слов, а полный размер дейтаграммы составляет 21 октет. Показанная выше дейтаграмма является полной (не фрагментом).

    Пример 2

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

    Ниже показан первый фрагмент, после выделения из дейтаграммы первых 256 октетов данных.


    Второй фрагмент будет иметь форму.

    Пример 3

    Ниже показан пример дейтаграммы, содержащей опции:

    Приложение B: Порядок передачи данных

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

    Когда октет представляет числовое значение, показанный бит является старшим или наиболее значимым. На приведенных в спецификации рисунках это бит 0. Например, показанная ниже последовательность битов задает десятичное число 170.

    Подобно этому для многооктетных полей, представляющих числа, указанный бит является старшим. При передаче многооктетных значений старший октет передается первым.

    Глоссарий

    • 1822
    • BBN Report 1822, «The Specification of the Interconnection of a Host and an IMP» — спецификация интерфейса между хостом и сетью ARPANET.
    • ARPANET leader
    • Управляющая информация сообщения ARPANET на интерфейсе хост-IMP.
    • ARPANET message — сообщение ARPANET
    • Элемент передачи между хостом и IMP в сети ARPANET. Максимальный размер сообщения около 1012 октетов (8096 битов).
    • ARPANET packet — пакет ARPANET
    • Единица передачи данных, используемая в сети ARPANET при обмене данными между IMP. Максимальный размер пакета составляет 126 октетов (1008 битов).
    • Destination — получатель
    • Адрес получателя — поле заголовка IP.
    • DF
    • Флаг запрета фрагментирования (Don’t Fragment).
    • Flags — флаги
    • Поле заголовка IP, содержащее различные флаги управления.
    • Fragment Offset — смещение фрагмента
    • Поле заголовка IP, указывающее смещение фрагмента в исходной дейтаграмме.
    • GGP
    • Gateway to Gateway Protocol — протокол, используемый шлюзами для управления маршрутизацией и других целей.
    • Header — заголовок
    • Служебная информация в начале сообщения, сегмента, дейтаграммы, пакета или блока данных.
    • ICMP
    • Internet Control Message Protocol — протокол, реализованный в модуле IP и используемый шлюзами и хостами для передачи информации об ошибках и проверки маршрутов.
    • Identification — идентификация
    • Поле заголовка IP, содержащее идентификатор, присваиваемый отправителем для правильной сборки фрагментов.
    • IHL
    • Internet Header Length — поле заголовка IP, указывающее размер заголовка в 32-битовых словах.
    • IMP
    • Interface Message Processor — коммутатор пакетов в сети ARPANET.
    • Internet Address — адрес IP
    • 4-октетный (32 бита) адрес отправителя или получателя, состоящий из полей Network (номер сети) и Local Address (номер хоста).
    • Internet datagram — дейтаграмма IP
    • Единица информации, используемая при обмене данными между парой модулей IP (включает заголовок IP).
    • internet fragment — фрагмент IP
    • Часть дейтаграммы IP с заголовком IP.
    • Local Address — локальный адрес (номер хоста)
    • The address of a host within a network. The actual mapping of an internet local address on to the host addresses in a network is quite general, allowing for many to one mappings.
    • MF
    • Флаг наличия других фрагментов (More-Fragments), передаваемый в поле флагов заголовка IP.
    • Module — модуль
    • Реализация (обычно программная) протокола или другой процедуры.
    • more-fragments flag
    • Флаг наличия других фрагментов (More-Fragments), передаваемый в поле флагов заголовка IP.
    • NFB
    • Number of Fragment Blocks — число блоков (по 8 октетов) данных во фрагменте дейтаграммы.
    • octet
    • Восьмибитовый байт.
    • Options — опции
    • Поле Options в заголовке IP может содержать тот или иной набор опций. Размер опции может быть переменным.
    • Padding — заполнение
    • Поле Padding используется для выравнивания заголовка IP по 32-битовой границе. Для заполнения используется 0.
    • Protocol — протокол
    • Поле Protocol заголовка IP содержит идентификатор протокола вышележащего уровня.
    • Rest — остаток
    • Локальная часть адреса IP (номер хоста).
    • Source — отправитель
    • Адрес отправителя в заголовке IP.
    • TCP
    • Transmission Control Protocol — протокол обмена данными между хостами, обеспечивающий гарантированную доставку в среде internet.
    • TCP Segment — сегмент TCP
    • Единица данных при обмене информацией между модулями TCP (включает заголовок TCP).
    • TFTP
    • Trivial File Transfer Protocol — простой протокол обмена файлами на основе протокола UDP.
    • Time to Live
    • Поле заголовка, определяющее верхнюю границу срока существования дейтаграммы IP.
    • TOS
    • ToS — тип обслуживания.
    • Total Length — общая длина
    • Поле заголовка Total Length показывает полный размер дейтаграммы в октетах с учетом заголовка и данных.
    • TTL
    • Время жизни (Time to Live).
    • Type of Service — тип обслуживания
    • Поле заголовка, определяющее тип (или качество) обслуживания дейтаграммы IP.
    • UDP
    • Протокол пользовательских дейтаграмм (User Datagram Protocol) — протокол пользовательского (транспортного в современной терминологии. прим. перев.) уровня для приложений на базе транзакций.
    • User
    • Пользователь IP — протокол вышележащего уровня, прикладная программа, программа шлюза.
    • Version
    • Поле версии определяет формат заголовка internet.

    Литература


    1. Cerf, V., «The Catenet Model for Internetworking,» Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
    2. Bolt Beranek and Newman, «Specification for the Interconnection of a Host and an IMP,» BBN Technical Report 1822, Revised May 1978.
    3. Postel, J., «Internet Control Message Protocol — DARPA Internet Program Protocol Specification,» RFC 792, USC/Information Sciences Institute, September 1981
    4. Shoch, J., «Inter-Network Naming, Addressing, and Routing,» COMPCON, IEEE Computer Society, Fall 1978.
    5. Postel, J., «Address Mappings,» RFC 796, USC/Information Sciences Institute, September 1981.
    6. Shoch, J., «Packet Fragmentation in Inter-Network Protocols,» Computer Networks, v. 3, n. 1, February 1979.
    7. Strazisar, V., «How to Build a Gateway», IEN 109, Bolt Beranek and Newman, August 1979.
    8. Postel, J., «Service Mappings,» RFC 795, USC/Information Sciences Institute, September 1981.
    9. Postel, J., «Assigned Numbers,» RFC 790, USC/Information Sciences Institute, September 1981.

    Перевод на русский язык

    Николай Малых, nmalykh@bilim.com

    После года разработки опубликован выпуск проекта Stratis 2.0, развиваемого компанией Red Hat и сообществом Fedora для унификации и упрощения средств настройки и управления пулом из одного или нескольких локальных накопителей. Stratis предоставляет такие возможности как динамическое выделение места в хранилище, снапшоты, обеспечение целостности и создание слоёв для кэширования. Код проекта написан на языке Rust и распространяется под лицензией MPL 2.0.

    Протоколы и стандарты Internet

    Продолжающееся быстрое развитие Internet, протоколов и стандартов, связанных с Сетью, требует систематизации и упорядочения достигнутых результатов. Этой цели служат периодически обновляемые документы, издаваемые Управляющим советом по вопросам архитектуры Internet (IAB ? Internet Architecture Board).

    Продолжающееся быстрое развитие Internet, протоколов и стандартов, связанных с Сетью, требует систематизации и упорядочения достигнутых результатов. Этой цели служат периодически обновляемые документы, издаваемые Управляющим советом по вопросам архитектуры Internet (IAB — Internet Architecture Board). Однако, несмотря на многообразие этих документов, ни один из них не дает достаточно полной и ясной картины о статусе выпускаемых документов и стадиях их разработки. Даже в совокупности они дают очень слабое представление о взаимоотношениях между протоколами и стандартами Internet.

    Общая их классификация имеет следующий вид:

    1. RFC Index (перечень RFC — Request for Comments) — список всех изданных RFC в порядке возрастания номеров, дополняемый по мере их появления.
    2. Internet official protocol standards (официальный перечень стандартов по протоколам Internet) — периодически обновляемый документ, где излагается общая характеристика процесса стандартизации в Internet, перечни вновь изданных RFC и обобщающие перечни протоколов, группируемые по стадиям стандартизации и иным признакам. Последняя версия этого документа изложена в RFC 2400.
    3. RFC Summary Numbers (сводный перечень номеров RFC) переиздается, начиная с номера 699, через каждые 100 номеров и содержит перечни с краткими аннотациями каждых 100 предыдущих номеров RFC.
    4. Assigned Numbers (присвоенные номера) — перечисляются присвоенные значения параметров, используемых в различных протоколах (например, адреса Internet, имена регионов, протокольные коды IP, номера портов TCP, коды опций Telnet, наименования типов терминалов).

    К концу сентября прошлого года IAB выпустил 2331 документ RFC (последний изданный в сентябре RFC имеет номер 2428, но в первой тысяче осталось 77 «пустых» или пропущенных номеров, под которыми никогда ничего не издавалось). Динамика количественного выпуска документов RFC по годам (дифференциальная кривая) и с нарастающим итогом (интегральная кривая), начиная с 1969 года, которая в какой-то мере отражает динамику развития самой сети Internet, показана на рис. 1.

    НОВОСТИ: Выпуск Stratis 2.0, инструментария для управления локальными хра . Thu, 07 Nov 2020 20:39:58 +0300
    Рис. 1. Динамика разработки документов RFC

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

    Кроме того, RFC никогда не переиздаются и не пересматриваются с тем же номером. Пересмотренный протокол издается под другим номером, а прежние сохраняются в каталогах под прежними номерами.

    Согласно RFC 2400 в Internet приняты две независимые системы классификации протоколов. Первая подразделяет протоколы по уровню зрелости или стадиям стандартизации на:

    • информационные (informational);
    • экспериментальные (experimental);
    • предложения по стандартам (proposed standards);
    • проекты стандартов (draft standards);
    • стандарты (standards);
    • исторические (historic).

    Вторая делит протоколы по уровню требований или статусу на:

    • обязательные (required);
    • рекомендуемые (recommended);
    • избирательного применения (elective);
    • ограниченного применения (limited use);
    • не рекомендуемые (not recommended).

    Протоколы проходят три стадии созревания: предложение по стандарту, проект и стандарт, подвергаясь на каждой стадии тщательному анализу и тестированию. Предложение по стандарту может стать проектом только при наличии минимум двух независимых реализаций и рекомендации Инженерной группы управления Internet (IESG — Internet Engineering Steering Group). Продвижение от проекта к стандарту требует обычно эксплуатационной проверки и демонстрации взаимодействия с двумя или более реализациями и также рекомендации IESG.

    От предложения до проекта стандарта минимальная задержка составляет 6 месяцев, от проекта до стандарта — 4 месяца. Фактические же задержки могут достигать нескольких лет.

    Некоторые документы, фиксирующие результаты проводимых исследований и разработок, получают название экспериментальных. Экспериментальный протокол не обеспечивает предлагаемых эксплуатационных услуг Internet и всегда имеет статус «ограниченного применения».

    Протоколы, разработанные другими организациями по стандартизации или поставщиками и представляющие информационный интерес, либо по каким то другим причинам не входящие в предмет рассмотрения IESG, помечаются как информационные. Информационные документы не имеют статуса.

    Вышедшие из употребления протоколы сохраняются в перечнях RFC с пометкой «исторические». Все такие протоколы должны иметь статус «не рекомендуемые». Протоколы, замененные новыми, получают название «устарелые» (obsolete).

    Если протокол находится в одной из стадий «предложение по стандарту», «проект стандарта» или «стандарт», считается, что он находится в «треке стандартов» (standards track). Протоколам в стадии «стандарт» присваиваются номера STD. При этом в отличие от нумерации документов RFC номер стандарта STD при его пересмотре не изменяется (хотя пересмотренный документ будет иметь новый номер RFC). Иначе говоря, стандарт по конкретному протоколу всегда будет иметь один и тот же номер STD.

    Другая особенность нумерации STD состоит в том, что если спецификация стандарта охватывает несколько документов RFC, они будут иметь один и тот же номер STD. Например, спецификация Domain Name System определяется комбинацией двух RFC — 1034 и 1035, которые охватываются одним номером STD 13. Шесть RFC по протоколам сетевого уровня (протокол IP, его расширения и протоколы ICMP, IGMP) охватываются одним STD 5. Для большей ясности один из нескольких RFC, охватываемых одним STD, можно указывать двойным номером, например, «STD 13/RFC 1034».

    Общее правило присвоения номеров STD состоит в том, что отдельный номер STD присваивается, если спецификация логически отделена от других. Такой логически отдельной опции присваивается отдельный номер, в то время как не опциональные расширения используют один и тот же номер SТD в качестве базовой спецификации. В подобных случаях документы, определяющие конкретный стандарт, должны ссылаться друг на друга.

    Согласно RFC 2400 при вхождении в трек стандартов (на стадии предложения по стандарту) протокол должен получить один из трех статусов, который, однако, может быть пересмотрен в любой момент времени:

    1. Обязательный — система должна реализовать этот протокол.
    2. Рекомендуемый — желательно (по соображениям экономичности, технической эффективности или лучшей совместимости), чтобы система реализовала данный протокол.
    3. Избирательного применения — система может реализовать один из нескольких протоколов аналогичного назначения по усмотрению разработчика. К таким протоколам должны относиться, например, протоколы электронной почты или протоколы маршрутизации. Фактически же, для всех протоколов в стадии «предложение по стандарту» независимо от наличия альтернатив и возможностей выбора в документе RFC 2400 указан статус «избирательного применения», что несколько противоречит определению этого статуса.

    Помимо этого протоколы (в основном экспериментальные и исторические) могут получить один из следующих статусов:

  • Ограниченного применения — протокол используется в ограниченном числе случаев. Это могут быть протоколы экспериментальные, специального характера или ограниченных функциональных возможностей.
  • Не рекомендуемые — не рекомендуются для общего пользования (ограниченные функциональные возможности, специального назначения, исторические или устарелые).
  • С 1995 году IAB ввоцедуре принятия предложений по стандартам. Статус этих документов определен в RFC 1818, а документы BCP имеют свою независимую нумерацию. К сегодняшнему дню разработано 25 RFC в статусе BCP, однако при формальном группировании RFC по RFC 2400 документы BCP в отдельный класс не выделяются.

    Рис. 2. Классификация протоколов Internet

    Изложенная классификация протоколов в схематическом виде представлена на рис. 2. К сожалению, фактическая классификация конкретных документов и протоколов Internet как в самом RFC 2400, так и в других перечисленных регламентирующих и обобщающих документах IAB не обладает четкостью этого рисунка и страдает иногда нелогичностью и противоречивостью.

    Прежде всего, в последнем обновленном RFC 2400, который перевел 20 ранее выпущенных версий этого документа в категорию исторических и одновременно устарелых, фактически упоминается лишь около 30% всех изданных RFC (758 документов). Сведения о стадии разработки и статусе остальных 70% RFC приходится разыскивать в 20 устарелых «исторических» RFC.

    Уже отсюда видно, что понятию «устарелый» в классификации протоколов Internet придается смысл, несколько отличный от общепринятого. Это подтверждается еще и тем фактом, что после появления по какому-либо протоколу нового «предложения по стандарту» прежний продолжающий действовать стандарт по этому протоколу объявляется устарелым, хотя очевидно, что новое предложение по стандарту не может заменить действующий стандарт. Фактически, что признается и в самом RFC 2400, все устарелые протоколы делятся на две категории — те, которые не имеет смысла упоминать в официальном перечне протоколов, и те, которые заслуживают того, чтобы на какое-то время сохранить их в перечне, поскольку в данном случае «устарелый стандарт находится в процессе замены». Типичным (но не единственным) примером подобного подхода является стандарт STD 12 по протоколу NTP (Network Time Protocol), версия 2 (RFC 1119), который согласно RFC 2400 переведен в разряд устарелых стандартом избирательного статуса по протоколу NTP, версия 3 (RFC 1305) и в то же время оставлен в перечне действующих стандартов со статусом «рекомендуемый», а новому стандарту (по RFC 1305) номер STD 12 не передан.

    Таблица 1. Количественное распределение протоколов
    Internet по стадиям разработки

    Стадия разработки Действующие Устарелые Всего
    Стандарт 55 2 57
    Проект стандарта 65 21 86
    Предложение по стандарту 374 78 452
    Экспериментальные 122 24 146
    Лучшая современная технология 24 1 25
    Информационные 516 61 577
    Исторические 49 51 100
    Не известна 740 168 908
    Пустые номера RFC 77
    ВСЕГО 1945 406 2428

    Здесь, видимо, правильнее было бы во избежание путаницы для документов, «находящихся в процессе замены» применить понятие «устаревающий», но не «устарелый».

    Официально считается, что стадии стандартизации, которые на рис. 2 изображены жирными прямоугольниками, являются долгосрочными, остальные же, особенно те, которые отражают процесс обновления стандартов, должны длиться один-два года. Фактически же эти «краткосрочные» стадии растягиваются иногда на десятилетия. Например, некоторые предложения по стандартам Telnet (RFC 652 — 658) сохранялись на этой стадии в течение 24 лет (с 1974 по 1998 год), после чего были переведены в категорию исторических, а многие проекты стандартов сохраняют свой статус с 1990 года (RFC 951, 954, 1191 и др.) по сегодняшний день.

    Анализ перечисленных документов IAB позволил выявить следующую статистику количественного распределения документов RFC и протоколов Internet по стадиям разработки.

    К документам с неизвестной стадией разработки относятся 908 начальных документов Internet, изданных до 1990 года, которые, судя по RFC 2400, не входят в трек стандартов и не относятся к экспериментальным (их можно отнести либо к информационным, либо к историческим). «Исторический» и одновременно «устарелый» документ должен означать, что он заменен новым документом, просто «исторический» должен означать, что он морально устарел и не имеет замены. Все документы RFC подразделяются на две группы: технические спецификации (TS — Technical Specifications) и положения о применимости (AS — Applicability Statements). Пока издано только 8 спецификаций AS, находящихся в различных стадиях разработки.

    Все документы RFC, как и протоколы Internet, можно подразделить по другому признаку еще на две группы: документы, определяющие внутреннее функционирование Internet, и документы, определяющие взаимодействие Internet с сетями других типов. При этом ко второй группе относится около 277 (из 2331) документов RFC (включая устарелые и исторические). По относительному количеству выпущенных документов попытаемся косвенно оценить заинтересованность Internet во взаимосвязи с другими сетевыми технологиями и сетевыми архитектурами.

    OSI ISO/ITU-T 110
    в том числе X.400/ISO 10021 29
    X.500/ISO 9594 40
    ARPANET 49
    Локальные сети 35
    ATM 26
    IPX Nowell 11
    Frame Relay 7
    AppleTalk 5
    ISDN 5
    SNA 4
    DECnet 4
    X.25 3

    Эта статистика не показывает, однако, динамики взаимоотношений. Так, если взаимосвязь Internet с устарелыми (ARPANET) или достаточно зрелыми, но в чем-то устаревающими системами (IPX Novell, AppleTalk), постепенно вытесняемыми самой Internet, стабилизировалась (судя по отсутствию новых RFC) в начале 80-х, то с конца 80-х началась проработка взаимосвязей с развивающимися новыми архитектурами Frame Relay, ATM, а также привлечение и освоение ресурсов, наработанных в ISO, ITU-T, что и отразилось в появлении соответствующих RFC.

    C 1990 года IAB ввел новую серию документов под названием FYI (For Your Information), которые носят информационный характер и должны обеспечить пользователей Internet централизованным справочником по наиболее важным темам и обобщающим вопросам (терминология, ответы на часто задаваемые вопросы относительно Internet и т.п.). Документы FYI имеют свою независимую нумерацию, и помещаются отдельным разделом в RFC Index, но не анализируются в RFC 2300. Издано 32 документа FYI, большинство из которых имеют своими дубликатами документы RFC.

    Взаимосвязи между протоколами Internet

    Уровневая архитектура протоколов Internet во многом соответствует концепции семиуровневой архитектуры протоколов эталонной модели OSI. Основное различие этих двух архитектур состоит в том, что протоколы трех верхних уровней эталонной модели OSI — прикладного, представления данных и сеансового в Internet, как правило, объединяются в один уровень — прикладной. Обобщенный профиль основных прикладных и коммуникационных протоколов Internet приведен на рис. 3.

    Рис. 3. Основополагающие протоколы Internet и взаимосвязи между ними

    Основными изначальными прикладными службами Internet были и остаются службы передачи файлов, электронной почты и обмена новостями, виртуальных терминалов и справочная служба. В каждой из таких областей шло постоянное развитие исходных и создание новых более эффективных протоколов, основные из которых, используемые сегодня перечислены на рисунке. Кроме того изначально применялись протоколы, выполняющие ряд вспомогательных, но повышающих эффективность работы функций — протоколы информирования о времени (TIME, NTP), получения собственных идентификаторов (BOOTP), получения информации об окружающей системе (Finger), диагностические протоколы (Echo) и др.

    С середины 90-х в Internet начала активно развиваться и внедряться технология World Wide Web, обеспечивающая гипертекстовые ссылки и связки различных видов информации. В эти годы были созданы язык HTML и протокол HTTP, претерпевшие к настоящему времени несколько модификаций, а также необходимые форматы адресных ссылок URL и URN.

    На прикладном уровне Internet используются также разработанные в рамках архитектуры OSI прикладные протоколы электронной почты Х.400 и справочной службы Х.500.

    Для управления Сетью, эксплуатации и технического обслуживания различного сетевого оборудования разработан стандарт (STD 15/RFC 1157, статус «рекомендуемый») по протоколу SNMP. Кроме того, имеется несколько десятков документов различной стадии разработки, расширяющих функции SNMP на работу с самым разнообразным сетевым оборудованием и на взаимодействие с другими сетями в целом.

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

    На уровне звена данных (канальном уровне) изначально использовался протокол SLIP, который сегодня фактически вытеснен протоколом двухпунктовых соединений PPP, поддерживающим как асинхронные (байт-ориентированные стартстопные), так и синхронные (бит-ориентированные) двунаправленные кабельные или модемные соединения. В последнее время дополнительно разработаны и успешно используются специальные стандарты для передачи IP-трафика по сетям различных архитектур, которые более полно учитывают особенности этих сетей. Кроме того на этом уровне часто используются (с применением инкапсуляции) протоколы других архитектур (Frame Relay, HDLC (в подсетях X.25), SDLC (в подсетях SNA), DDCMP (в подсетях DECNet), протоколы LAN и др.

    На физическом уровне в сети Internet могут быть использованы практически все широко известные протоколы и интерфейсы физического уровня, стандартизованные ITU-T (CCITT), EIA, ISO, Frame Relay Forum, ATM Forum, протоколы и интерфейсы LAN, SDH (SONET) и др. Единственным ограничением, налагаемым протоколом РРР на физический уровень, является наличие дуплексного канала, выделенного или коммутируемого, работающего в асинхронном или синхронном последовательном режиме, прозрачном для пакетов уровня PPP. На скорости передачи данных и тип интерфейса никаких ограничений не налагается.

    Протоколы прикладного уровня взаимодействуют с протоколами транспортного и сетевого уровней с использованием инкапсуляции. Так, в частности, протоколы HTTP, Telnet, FTP, SMTP, POP3, IMAP используют протокол TCP, протокол TFTP использует протокол UDP, а службы NetBIOS, TIME и протоколы OSI могут использовать оба транспортных протокола.

    Стандартизация протоколов защиты информации на всех уровнях Internet пока недостаточно зрелая — сегодня по этим вопросам нет ни одного принятого стандарта. Однако проработка вопросов защиты информации ведется достаточно активно — в стадии рассмотрения находится 14 предложений по стандартам и еще большее число документов находятся в экспериментальной и информационной стадиях.

    Взаимосвязь с другими сетями и архитектурами

    Большие информационные и коммуникационные возможности Internet, с одной стороны, наличие современных высокоскоростных сетевых технологий, а также прикладных программ других сетевых архитектур с более широкими и гибкими возможностями, с другой стороны, приводят к общей практической заинтересованности во взаимном обогащении прикладных и коммуникационных ресурсов различных сетей.

    Как уже отмечалось, вопросам взаимодействия Internet с другими сетями посвящено 290 документов RFC, отражающих используемые на практике конфигурации взаимодействия. Основные из таких конфигураций отражены на рис. 4, где указаны также соответствующие документы RFC, определяющие взаимодействие протоколов Internet с другими протоколами.

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

    1. Использование на нижних уровнях Internet современных высокоскоростных протоколов типа типа FDDI, Fast Ethernet, Frame Relay, ATM и др., повышающее эффективность работы прикладных протоколов Internet.
    2. Использование более эффективных прикладных программ других сетевых архитектур (типа OSI, SNA) для работы по практически апробированным, достаточно зрелым и широко распространенным коммуникационным протоколам Internet.

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

    1. разбиение длинного сообщения пользователя или единицы информации вышерасположенного уровня (пакета, кадра) на несколько более коротких фрагментов или сегментов. Этот процесс получил в литературе двоякое название: «фрагментация» (fragmentation) или «сегментирование» (segmenting);
    2. образование из полученных фрагментов единиц информации (кадров, ячеек), воспринимаемых используемой сетевой технологией и упаковка полученных единиц информации в кадры или ячейки данной сетевой технологии. Этот процесс получил название «инкапсуляция» (encapsulation);
    3. восстановление на принимающей стороне исходного сообщения, пакета или кадра. Этот процесс, в зависимости от конкретных используемых сетевых технологий, называется «сборка» (reassembling) (например, в X.25, ISDN) или «декапсуляция» (decapsulation) в большинстве других технологий.

    Метод инкапсуляции протоколов определен в рекомендациях ITU-T I.363, I.365, Q.2119, стандартах ANSI T1.617a, Frame Relay Forum FRF.3.1 и в RFC 1490. На рис. 4 взаимодействие различных протоколов методом инкапсуляции изображено стрелками.

    Метод преобразования услуг использован в показанном на рис. 4 взаимодействии протоколов Internet с прикладными протоколами OSI. В RFC 1006 (стандарт STD 35) определен механизм, позволяющий протоколу транспортного уровня ТР 0 (простой класс) по ISO/IEC 8073 (и, следовательно, любым прикладным программам OSI, работающим по ТР 0) функционировать над протоколом TCP Internet при использовании услуг протокола IP. В результате логические объекты всех верхних уровней OSI (прикладного, представления данных и сеансового) могут функционировать нормально, не ощущая того, что все они работают по TCP/IP.

    В RFC 2126 (предложение по стандарту) дополнительно к протоколу ТР 0 предусмотрено также функционирование протокола ТР 2 (класс с мультиплексированием сетевых соединений) ISO/IEC 8073 над протоколом TCP и, кроме того, уточняются механизмы преобразования услуг TCP в услуги сетевого уровня OSI, используемые TP 0 и TP 2. Аналогичный стандарт «Использование прикладных протоколов OSI над протоколом TCP Internet» разработан в ISO.

    Протокол по RFC 1006/2126 и ISO/IEC 14766 преобразует услуги протокола TCP Internet в стандартные по ISO/IEC 8348 услуги сетевого уровня OSI в режиме с установлением соединения (CONS), которые затем используются протоколом TP 0 или TP 2 по ISO/IEC 8073. Кроме того указанный протокол инкапсулирует протокольные блоки ISO/IEC 8073 в пакеты протокола ТСР. При этом все основные аспекты услуг транспортного уровня по ISO/IEC 8072 сохраняются, за исключением параметра качества услуг.

    Рис. 4. Взаимосвязь протоколов Internet с протоколами других сетевых архитектур и технологий

    Наряду с широко известными сетевыми архитектурами и сетевыми технологиями OSI, X.25, ISDN, Frame Relay, ATM, SDH/SONET, а также стандартными технологиями локальных сетей семейства IEEE 802 (Ethernet, Token Ring, FDDI) на рис. 4 изображены взаимосвязи Internet с другими менее известными технологиями.

    Технология SMDS, получившая название «коммутируемая многомегабитовая служба передачи данных», разработана компанией Bellcore. По ее определению, SMDS — это «высокоскоростная служба коммутации пакетов общего пользования, работающая в режиме без установления соединения и предназначенная для расширения локальных сетей за пределы оборудования пользователя через глобальные или региональные вычислительные сети». Эта служба может использоваться для многих применений, включая взаимосвязи локальных сетей, высокоскоростной доступ к удаленным базам данных, пакетная передача аудио- и видеоинформации, распределение ресурсов, передача изображений или телерадиология. При этом SMDS может обеспечивать взаимодействия с другими широкополосными технологиями, такими как Frame Relay и ATM. SMDS обеспечивает скорости передачи данных 56/64 Кбит/с (DS0), 1544 Мбит/с (DS1) и 44736 Мбит/с (DS3).

    Спецификация NetBIOS, опубликованная в 1984 году корпорацией IBM под названием «IBM PC Network Technical Reference Manual», определила интерфейс и услуги сети IBM PC и совместимых систем, коллективно использующих общую широкополосную физическую среду. Предусмотрены два режима работы — сются динамически.

    Поскольку служба NetBIOS сконструирована на основе различных протоколов и различного оборудования, то для обеспечения взаимодействия NetBIOS в Internet RFC 1001 и 1002 определили стандартный протокол для функционирования прикладных программ NetBIOS над протоколами TCP и UDP. Кроме того, поскольку для выполнения некоторых приложений NetBIOS типа серверов файлов ПК не подходят, то RFC 1001 и 1002 определили возможность построения реализаций на системах любого типа, где имеется комплект протоколов TCP/IP.

    С другой стороны, RFC 1088 определил стандартный метод инкапсуляции датаграмм протокола IP в датаграммы NetBIOS с тем, чтобы обеспечить возможность работы в компьютерах сети NetBIOS прикладных программ Internet, работающих над IP. Кроме того определено преобразование 4-байтовых адресов IP в 16-байтовые имена NetBIOS. Использование маршрутизаторов, способных инкапсулировать пакеты IP в обычные протоколы уровня звена данных (типа протоколов локальных сетей), а также в датаграммы NetBIOS, позволяют компьютерам NetBIOS взаимодействовать со всей Internet.

    Протокол PPP обеспечивает стандартный метод транспортирования многопротокольных датаграмм по двухпунктовым каналам. PPP определяет расширяемый Link Control Protocol и поддерживает семейство различных протоколов сетевого уровня NCP (Network Control Protocols). RFC 2097 определил один из протоколов NCP, поддерживаемых PPP, для функционирования протокола сетевого уровня NBFCP сети NetBIOS над PPP.

    Высокопроизводительный параллельный интерфейс HIPPI, разработанный в конце 80-х — начале 90-х рабочей группой ANSI X3T9.3 HIPPI, представляет собой простой канал данных. Пара таких каналов обеспечивает одновременный прием и передачу данных на скорости 800 Мбит/с и факультативно 1600 Мбит/с.

    Документы RFC Index:

    Следует учесть, что содержимое RFC Index по всем указанным адресам не идентичное. Если, например, по первому из адресов RFC Index содержит только перечень номеров RFC (без названий документов), форматы RFC (указываемые расширением имени файла) и емкость электронной версии документа в Кбайт, то по последнему из перечисленных адресов содержится наиболее подробный RFC Index с указанием дополнительно наименования документа, фамилий авторов, даты издания, устарелых или обновляемых версий документа и стадии разработки протокола.

    При этом ни по одному из перечисленных адресов в приводимых RFC Index не указан статус протоколов, а стадии разработки указываются только по последнему из адресов, однако здесь регламентированные в RFC стадии разработки (типа proposed standard, draft standard) именуются как «статус», а то, что в RFC 2400 трактуется как «статус» (типа required, recommended), в этом RFC Index вообще не упоминается. Из 55 разработанных STD в этом RFC Index упомянуты только 12. Для 928 документов (из 2331) стадии разработки помечены как «не известные» (UNKNOWN). В этом же RFC Index протоколы TELNET (RFC 856 — RFC 861) указаны со статусом UNKNOWN, тогда как в RFC 2400 они помечены как STANDARD со статусом Recommended.

    Во всех RFC Index 480 документов (в основном из первой тысячи) недоступны в электронном виде. Полный, оперативно дополняемый RFC Index, включая перечень FYI, с указанием стадий разработки протоколов и статусов документов и лишенный многих указанных выше неточностей других RFC Index можно найти на сервере http://incoma.ru

    Поделитесь материалом с коллегами и друзьями

    RTP и RTCP: протоколы для IP-телефонии

    4. Протокол управления RTCP

    Протокол управления RTP (RTCP — Real-Time Control Protocol) основан на периодической передаче пакетов управления всем участникам сеанса связи при использовании того же механизма распределения, что и протокол RTP. Протокол нижележащего уровня должен обеспечить мультиплексирование информационных и управляющих пакетов, например, с использованием различных номеров портов UDP. Протокол RTCP выполняет четыре основные функции.

    1. Главная функция — это обеспечение обратной связи для оценки качества распределения данных. Это — неотъемлемая функция RTP, как транспортного протокола, она связана с функциями управления потоком и перегрузками других транспортных протоколов. Обратная связь может быть непосредственно полезна для управления адаптивным кодированием, но эксперименты с IP-мультивещанием (IPM — IP Multicast) показали, что обратную связь с получателями также важно иметь для диагностики дефектов при распространении информации. Посылка отчетов обратной связи о приеме данных всем участникам позволяет при наблюдении проблем, оценивать, являются они локальными или глобальными. С механизмом распределения IPM для таких объектов, как поставщики услуг сети, возможно также получать информацию обратной связи и действовать при диагностике проблем сети, как монитор третьей стороны. Эта функция обратной связи обеспечивается отчетами отправителя и приемника RTCP, описанными ниже в разделе 4.3.
    2. RTCP поддерживает устойчивый идентификатор источника данных RTP на транспортном уровне, называемый «каноническим именем» (CNAME — canonical name), раздел 4.4.1. Так как идентификатор SSRC может изменяться, если обнаружен конфликт или перезапущена программа, то получателям для отслеживания каждого участника требуется каноническое имя CNAME. Получатели также требуют CNAME для отображения множества потоков информации от данного участника на множество связанных сеансов RTP, например, при синхронизации звукового и видеосигнала.
    3. Первые две функции требуют, чтобы все участники посылали пакеты RTCP, следовательно, для предоставления возможности масштабирования числа участников протоколом RTP должна регулироваться частота передачи таких пакетов. При посылке каждым участником телеконференции управляющих пакетов всем остальным участникам, каждый может независимо оценивать общее число участников. Это число используется при вычислении частоты отправления пакетов, как показано в разделе 4.2.
    4. Четвертая, дополнительная функция RTCP должна обеспечивать информацию управления сеансом (например, идентификацию участника), которая будет отражена в интерфейсе пользователя. Наиболее вероятно, что это будет полезным в «свободно управляемых» сеансах, где участники вступают в группу и выходят из нее без контроля принадлежности или согласования параметров.

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

    4.1. Требования к пакетам RTCP

    Для передачи различного рода информации управления определено несколько типов пакетов RTCP, в том числе:

    • SR: отчет отправителя, для статистической информации о передаче и приеме участников, которые являются активными отправителями;
    • RR: отчет получателя, для статистики приема от участников, которые не являются активными отправителями;
    • SDES: пункты описания источника, включая CNAME;
    • BYE: указатель завершения участия в телеконференции;
    • APP: функции, определяемые приложением.

    Каждый пакет RTCP начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP). За ней следуют структурные элементы, которые могут иметь переменную длину согласно типа пакета, но всегда выравниваются по 32-разрядной границе. Требование выравнивания и включение поля длины в фиксированную часть предназначены обеспечить «наращиваемость» пакетов RTCP. Несколько пакетов RTCP могут соединяться без каких-либо разделителей, формируя составной пакет RTCP, который передается в одном блоке данных протокола нижележащего уровня, например протокола UDP. Какого-либо указателя на количество отдельных пакетов RTCP в составном пакете не предусмотрено, так как протоколы нижележащего уровня для определения окончания составного пакета содержат сведения о его полной длине.

    Каждый отдельный пакет RTCP в составном пакете может обрабатываться отдельно без каких-либо требований относительно порядка или комбинации пакетов. Однако для корректного выполнения функций протокола существуют следующие требования.

    Статистика приема (в пакетах отчета отправителя SR или получателя RR) должна посылаться так часто, как позволяет полоса пропускания, чтобы максимизировать точность статистики: следовательно, в каждый составной пакет RTCP должен включаться пакет отчета.

    Новые участники телеконференции должны получить каноническое имя (CNAME) источника как можно скорее, чтобы опознать источник и начать согласовывать формат мультимедийных данных, так что каждый составной пакет RTCP должен также включать пакет описания источника SDES с пунктом CNAME.

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

    Таким образом, все пакеты RTCP должны передаваться в составном пакете, включающем, по крайней мере, два индивидуальных пакета (SR/RR и SDES), со следующим рекомендуемым форматом.

    Префикс шифрования. Если и только если составной пакет должен быть зашифрован, то ему предшествует произвольная 32-разрядная величина, повторно передаваемая в каждом составном пакете.

    SR или RR. Первый пакет RTCP в составном пакете должен всегда быть пакетом отчета, чтобы облегчить проверку корректности заголовка. Это требуется, даже если никакие данные не были ни посланы, ни получены и если единственный пакет RTCP в составном пакете — это пакет BYE (тогда посылается пустой пакет RR).

    Дополнительные пакеты RR. Если число источников, для которых передается статистика приема, превышает 31 (максимальное число источников, отмечаемых в одном пакете SR или RR), то за начальным пакетом отчета должны следовать дополнительные пакеты RR.

    SDES. Пакет SDES, содержащий пункт CNAME, должен включаться в каждый составной пакет RTCP. Если требуется конкретным приложением, то дополнительно и другие пункты описания источника могут быть включены в пакет SDES в соответствии с ограничениями полосы пропускания (см. раздел 4.2.2).

    BYE или APP. Другие типы пакетов RTCP могут следовать в любом порядке, за исключением того, что пакет BYE должен быть последним пакетом, посланным с данным SSRC/CSRC.

    Для трансляторов и микшеров желательно объединять индивидуальные пакеты RTCP из множества источников, с которыми они работают, в один составной пакет всякий раз, когда это возможно, чтобы уменьшить избыточность и не передавать лишние заголовки пакета (см. раздел 5). Если полная длина составного пакета превышает величину максимального блока передачи (MTU — maximum transmission unit) сетевого пути, то составной пакет может быть сегментирован на множество более коротких составных пакетов, которые будут переданы в отдельных блоках данных протокола нижележащего уровня. Заметим, что и в этом случае каждый из составных пакетов должен начинаться с пакета SR или RR.

    Приложение может игнорировать входящие пакеты RTCP с неизвестными ему типами. Дополнительные типы пакетов RTCP могут быть зарегистрированы в Сообществе назначения номеров Internet IANA (Internet Assigned Numbers Authority).

    4.2. Интенсивность передачи пакетов RTCP

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

    Для каждого сеанса предполагается, что трафик данных соответствует агрегированному пределу, называемому полосой пропускания сеанса связи, которая совместно используется всеми участниками. Эта полоса пропускания может быть зарезервирована, и ее предел установлен сетью. Полоса пропускания сеанса не зависит от типа кодирования мультимедийных данных, но выбор типа кодирования может быть ограничен полосой пропускания сеанса связи. Параметр полосы пропускания сеанса, как ожидается, будет обеспечен приложением управления сеанса, когда оно вызовет мультимедийное приложение, но мультимедийные приложения могут также устанавливать значение по умолчанию, основанное на полосе пропускания данных с единственным отправителем для типа кодирования, выбранного для данного сеанса.

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

    Трафик управления должен быть ограничен малой и известной частью полосы пропускания сеанса: малой настолько, чтобы не пострадала основная функция транспортного протокола — передача данных; известной так, чтобы трафик управления мог быть включен в спецификацию полосы пропускания, данную протоколу резервирования ресурсов, и так, чтобы каждый участник мог независимо вычислить свою долю. Предполагается, что часть полосы пропускания сеанса, выделяемая для RTCP, должна быть установлена равной 5%. Все участники сеанса должны использовать одинаковую величину полосы пропускания RTCP, так чтобы вычисленные значения интервала передачи пакетов управления были одинаковыми. Поэтому эти константы должны быть установлены для каждого профиля.

    Алгоритм вычисления интервала между посылками составных пакетов RTCP для разделения среди участников полосы пропускания, выделенной для трафика управления, имеет следующие основные характеристики.

    Отправители коллективно используют по крайней мере 1/4 полосы пропускания трафика управления так, как в сеансах с большим количеством получателей, но с малым числом отправителей; едва установив соединение, участники в течение короткого интервала времени получают CNAME передающих сайтов.

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

    Интервал между пакетами RTCP изменяется случайно в пределах от половины до полутора расчетных интервалов во избежание непреднамеренной синхронизации всех участников. Первый пакет RTCP, посланный после вступления в сеанс связи, также задерживается случайным образом (до половины минимума интервала RTCP) в случае, если приложение начато во множестве сайтов одновременно, например, при объявлении о начале сеанса связи.

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

    Этот алгоритм может использоваться для сеансов, в которых передача пакетов допустима для всех участников. В этом случае, параметр полосы пропускания сеанса — это произведение полосы пропускания индивидуального отправителя на число участников, и полоса пропускания RTCP составляет 5% от этой величины.

    4.2.1. Учет числа участников сеанса связи

    Вычисление величин интервалов передачи пакетов RTCP зависит от оценки числа участников сеанса связи. Новые участники учитываются, когда они отмечаются в работе и когда для каждого в таблице создается запись с соответствующим идентификатором SSRC или CSRC (см. раздел 6.2). Новые записи не могут иметь силу, пока не будет получено множество пакетов, содержащих новый SSRC. При получении пакета BYE с соответствующим идентификатором SSRC записи из таблицы удаляются.

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

    Если сайт, признанный участником телеконференции, впоследствии отмечается, как неактивный, то состояние этого сайта еще какое-то время должно сохраняться неизменным, и сайт все еще должен учитываться в общем числе сайтов, совместно использующих полосу пропускания RTCP. Для данного таймаута предложено значение, равное 30 минутам. Заметим, что это все же больше, чем умноженная на 5 самая большая ожидаемая и приемлемая величина интервала отчетности RTCP, приблизительно равная от 2 до 5 минут.

    4.2.2. Выделение полосы пропускания для пакетов описания источника SDES

    В дополнение к обязательному пункту CNAME пакетов описания источника (SDES source description) в данной статье рассмотрены и другие пункты, такие как NAME (персональное имя), EMAIL (адрес электронной почты) и т.п. Приложения должны учитывать возможность передачи дополнительных пунктов при распределении полосы пропускания RTCP, потому что это замедлит скорость, с которой будут передаваться отчеты о приеме и CNAME, таким образом, ухудшая характеристики протокола. Рекомендуется, чтобы для передачи дополнительной информации использовалось не более 20% полосы пропускания RTCP, выделенной одному участнику. Кроме того, не требуется, чтобы все пункты SDES использовались каждым приложением. За теми из них, которые включены в использование, должны быть закреплены некоторые части полосы пропускания.

    Например, приложение может быть разработано так, чтобы включать в пакеты SDES только пункты CNAME, NAME, EMAIL и никаких других. Пункту NAME может быть назначен гораздо более высокий приоритет, чем пункту EMAIL, потому что NAME будет индицироваться непрерывно в интерфейсе пользователя данного приложения, в то время как пункт описания пользователя EMAIL будет показываться только по требованию. В каждом интервале RTCP посылается пакет RR и пакет SDES с пунктом CNAME. Для сеанса с малым числом пользователей, работающего с минимальным интервалом отчетности, это было бы в среднем каждые 5 секунд. Каждый третий интервал (15 секунд), один дополнительный пункт был бы включен в пакет SDES. Семь из восьми раз это будет пункт NAME, а каждый восьмой раз (2 минуты) — пункт EMAIL.

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

    4.3. Пакеты отчетов отправителя и получателя (SR и RR)

    Получатели RTP обеспечивают обратную связь — оценку качества приема, используя пакеты отчета RTCP, которые могут принимать одну из двух форм в зависимости от того, является получатель также и отправителем или нет. Единственная разность между формами отчета отправителя (SR — sender report) и отчета получателя (RR — receiver report), помимо кода типа пакета, — это то, что отчет отправителя включает 20-байтовый раздел информации отправителя для использования активными отправителями. SR передается, если сайт посылал любые пакеты данных в течение интервала, начиная с передачи последнего или предыдущего отчета, в противном случае передается RR.

    Формы SR и RR включают нуль или более блоков отчета приема, один для каждого из источников синхронизации, от которых получатель принял пакеты данных RTP, начиная с последнего отчета. Для включаемых источников, перечисленных в списке CSRC, отчеты не выпускаются. Каждый блок отчета приема обеспечивает статистику относительно данных, полученных от конкретного источника, обозначенного в этом блоке. Так как максимум 31 блок приемных отчетов возможен в пакетах SR или RR, то дополнительные пакеты RR могут быть помещены в стек после начальных пакетов SR или RR. Это необходимо, чтобы содержать отчеты приема для всех источников, отмечаемых в течение интервала отчетности, начиная с последнего отчета.

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

    4.3.1. Формат пакета отчета отправителя (SR)

    Пакет отчета отправителя содержит три основных секции и может содержать дополнительную четвертую определяемую профилем секцию расширения. Первая секция, заголовок, имеет длину 8 октетов (см. таблицу). Ее поля имеют следующие значения.

    Версия (V version): 2 бита. Идентифицирует версию RTP, которая является одинаковой в пакетах RTCP и информационных пакетах RTP. В данной статье рассматривается протокол версии 2.

    Дополнение (P padding): 1 бит. Если бит дополнения установлен в 1, то этот пакет RTCP в конце содержит некоторые октеты дополнения, которые не являются частью информации управления. Последний октет дополнения — это счетчик дополнительных октетов, которые должны игнорироваться. Дополнение может требоваться некоторыми алгоритмами шифрования с фиксированными размерами блока. В составном пакете RTCP дополнение должно использоваться только в последнем индивидуальном пакете, потому что составной пакет шифруется в целом.

    Счетчик отчетов приема (RC reception report count): 5 бит. Число блоков отчетов приема, содержащихся в данном пакете. Нуль — возможное значение RC.

    Тип пакета (PT — packet type): 8 бит. Содержит константу 200 для идентификации пакета, как пакета SR протокола RTCP.

    Длина: 16 бит. Длина данного пакета RTCP в 32-разрядных словах минус одно слово, включая заголовок и любое дополнение (смещение на единицу делает нуль допустимой величиной и предотвращает возможность бесконечного зацикливания при просмотре составного пакета RTCP, с другой стороны, подсчет 32-разрядных слов исключает проверку допустимости значения длины на предмет кратности четырем).

    SSRC: 32 бита. Идентификатор источника синхронизации для источника данного пакета SR.

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

    Временная метка NTP: 64 бита. Указывает абсолютное время, когда был послан этот отчет, так, что она может использоваться в комбинации с временными метками, возвратившимися в отчетах приема от других получателей, чтобы измерить время передачи на маршруте туда и обратно для этих получателей. Получатели должны ожидать, что точность измерения временной метки может быть принята гораздо меньшей, чем разрешение временной метки NTP. Неопределенность измерения для временной метки не обозначается, поскольку она не может быть известна. Отправитель, который может следить за прошедшим временем, но не имеет данных об абсолютном времени, вместо этого может использовать время, прошедшее с начала соединения сеанса. Оно должно быть меньше, чем 68 лет, — тогда старший разряд будет иметь нулевое значение. Для оценки прошедшего абсолютного времени допустимо использование таймера дискретизации. Отправитель, который не имеет никаких данных об абсолютном или прошедшем времени, может устанавливать временную метку NTP в нуль.

    Временная метка RTP: 32 бита. Соответствует тому же самому времени, что и временная метка NTP (см. выше), но выражается в тех же единицах и с тем же самым случайным смещением, что и временные метки RTP в информационных пакетах. Это соответствие может использоваться для внешней и внутренней мультимедийной синхронизации источников, чьи временные метки NTP синхронизированы и могут использоваться независимыми от типа трафика получателями для оценки номинальной частоты таймера RTP. Заметим, что в большинстве случаев эта временная метка не будет равна временной метке RTP в любом соседнем информационном пакете. Она вычисляется из соответствующей временной метки NTP с использованием связи между счетчиком временной метки RTP и реальным временем, которое поддерживается периодически контролем абсолютного времени в моменты дискретизации.

    Счетчик пакетов отправителя: 32 бита. Общее количество информационных пакетов RTP, переданных отправителем от момента начала передачи вплоть до времени генерации пакета SR. Счетчик сбрасывается, если отправитель изменяет свой идентификатор SSRC.

    Счетчик октетов отправителя: 32 бита. Общее число октетов трафика (то есть октетов пакета, не включая заголовок и дополние), переданных в информационных пакетах RTP отправителем с момента начала передачи вплоть до времени генерации этого пакета SR. Счетчик обнуляется, если отправитель изменяет свой идентификатор SSRC. Это поле может использоваться для оценки средней скорости передачи трафика.

    Третий раздел пакета SR содержит нуль или более блоков отчета приема (начиная с последнего отчета) в зависимости от количества других источников, которых «видит» этот отправитель. Каждый блок отчета приема передает статистическую информацию о приеме пакетов RTP из одного источника синхронизации. Получатели не переносят статистику, когда источник изменяет свой идентификатор SSRC вследствие коллизий. Эта статистика включает следующую информацию.

    SSRC_n (идентификатор источника): 32 бита. Идентификатор SSRC источника, к которому относится информация в этом блоке отчета приема.

    Доля потерь: 8 бит. Часть информационных пакетов RTP из источника SSRC_n, потерянных, начиная с момента отправки предыдущего пакета SR или RR, представленная в виде целого числа с фиксированной точкой без знака (в виде целой части числа после умножения доли потерянных пакетов на 256). Эта доля определяется как число потерянных пакетов, разделенное на число ожидаемых пакетов. Если величина потерь — отрицательная из-за наличия дубликатов пакетов, то доля потерь приравнивается к нулю.

    Общее число потерянных пакетов: 24 бита. Общее число информационных пакетов RTP из источника SSRC_n, которые были потеряны с момента начала приема. Это число является разностью между числом пакетов, ожидаемых к получению, и числом фактически полученных пакетов. В число полученных пакетов входят любые пакеты, в том числе опоздавшие и дубликаты. Таким образом, пакеты, которые прибывают поздно, не причисляются к числу потерянных, а число потерь может быть отрицательным, если имеются дубликаты. Число ожидаемых пакетов определяется как разность последнего полученного порядкового номера и начального полученного порядкового номера.

    Расширенный наибольший полученный порядковый номер: 32 бита. Младшие 16 битов содержат наибольший порядковый номер, полученный в информационном пакете RTP из источника SSRC_n, а старшие 16 битов расширяют этот порядковый номер соответствующим счетчиком циклов порядкового номера. Заметим, что различные получатели в рамках одного и того же сеанса генерируют различные расширения порядкового номера, если время начала для них значительно различается.

    Джиттер прибытия: 32 бита. Это — статистическая оценка разницы относительного времени прибытия информационных пакетов RTP, измеряемая в единицах временной метки и выражаемая целым числом без знака. Джиттер прибытия J определяется как средняя величина (сглаженное абсолютное значение) разности D времени между поступлениями двух пакетов получателю и времени между моментами передачи этих пакетов. Как показано в уравнении ниже, это эквивалентно разности относительного времени передачи для двух пакетов (относительное время передачи — это разность между временной меткой пакета RTP и значением таймера получателя во время поступления, выраженным в тех же самых единицах).

    Если Si — это временная метка RTP из пакета i, а Ri — время поступления в единицах временной метки RTP для пакета i, то для двух пакетов i и j, D может быть выражено как

    Джиттер прибытия вычисляется непрерывно по мере того, как каждый информационный пакет i поступает от источника SSRC_n, с использованием этой разности D для этого пакета и предыдущего пакета i-1 в порядке поступления (не обязательно в последовательности передачи), согласно формуле

    Всякий раз, когда передан отчет приема, определяется текущая величина J. Вычисление джиттера, описанное здесь, позволяет независимым от профиля мониторам делать корректные интерпретации отчетов, поступающих от различных реализаций. Этот алгоритм является оптимальным оценивателем первого порядка, и весовой коэффициент 1/16 дает хороший коэффициент уменьшения шума при поддержании приемлемой скорости сходимости.

    Временная метка последнего SR (LSR): 32 бита. Средние 32 бита из 64 битов временной метки NTP (как показано в разделе 2.4), полученные как часть самых последних пакетов отчетов отправителя RTCP (SR) из источника SSRC_n. Если SR еще не был получен, то временная метка LSR имеет нулевое значение.

    Задержка с момента последнего SR (DLSR): 32 бита. Задержка в приемнике пакетов, выраженная в единицах, равных 1/65536 секунды, между получением последнего пакета SR из источника SSRC_n и посылкой этого блока отчета о приеме. Если пакет SR еще не был получен от SSRC_n, то поле DLSR имеет нулевое значение.

    С помощью значений временной метки последнего SR (LSR) и задержки в приемнике с момента последнего SR (DLSR) источник SSRC_n может вычислять задержку распространения пакетов на пути к получателю SSRC_r и обратно (круговую задержку). При поступлении отчета приема источник SSRC_n фиксирует время этого события Т. Затем он вычисляет общее время двойного прохода Т-LSR с использованием поля временной метки последнего SR (LSR) и вычитает задержку DLSR, в результате получая время распространения пакета туда и обратно (Т-LSR-DLSR). Это может использоваться как приблизительная мера расстояния до кластера получателей, хотя некоторые линии имеют очень асимметричные задержки.

    4.3.2. Формат пакета отчета получателя (RR)

    1 2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    V=2 P RC PT=SR=201 длина Заголовок
    SSRC отправителя
    SSRC первого источника (SSRC_1) Блок
    доля потерь общее число потерянных пакетов отчета
    расширенный наибольший полученный порядковый номер 1
    джиттер прибытия
    временная метка последнего SR (LSR)
    задержка с момента последнего SR (DLSR)
    SSRC второго источника (SSRC_2) Блок
    . . . отчета 2
    расширения, зависящие от профиля

    Формат пакета отчета получателя RR (receiver report) такой же, как и формат пакета SR, за исключением того, что поле типа пакета содержит константу, равную 201, а пять слов информации отправителя отсутствуют (временные метки NTP и RTP и счетчики пакетов и октетов отправителя). Оставшиеся поля имеют то же самое значение, что и для пакета SR.

    Когда нет никакой передачи данных или приема, о которых можно было бы сообщить, во главу составного пакета RTCP помещается пустой пакет RR (RC = 0).

    4.3.3. Расширение отчетов отправителя и получателя

    Если имеется дополнительная информация об отправителе или получателях, которая должна регулярно сообщаться, то профиль должен определять расширения к отчету отправителя и получателя. Использовать этот метод предпочтительнее, чем определять другой тип пакета RTCP, потому что он требует меньше избыточности:

    • меньше октетов в пакете (не требуется ни заголовка RTCP, ни поля SSRC);
    • более простой и быстрый анализ, потому что приложения, выполняющиеся в соответствии с данным профилем, могут программироваться так, чтобы всегда рассматривать поля расширения в непосредственно доступном месте после отчетов приема.

    Если требуется дополнительная информация отправителя, то она должна быть включена в первую очередь в расширение отчетов отправителя, но не должна присутствовать в отчетах приема. Если должна быть включена информация о получателях, то данные могут быть структурированы, как массив блоков, параллельный существующему массиву блоков отчета приема. Число блоков должно быть обозначено полем RC.

    4.3.4. Анализ отчетов отправителя и получателя

    Обратная связь качества приема полезна не только для отправителя, но также для получателей и мониторов третьей стороны. Отправитель может модифицировать свои передачи на основе обратной связи; получатели могут определять, являются ли проблемы локальными, региональными или глобальными; диспетчеры сети могут использовать независимые от профиля мониторы, которые получают пакеты RTCP, чтобы оценить характеристику сетей для группового распределения.

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

    Рассмотрим пример вычисления интенсивности потерь пакета на интервале между двумя отчетами приема. Разность значений кумулятивных счетчиков потерянных пакетов дает количество пакетов, потерянных в течение этого интервала. Разность в последних полученных расширенных порядковых номерах дает число пакетов, ожидаемых в течение интервала. Отношение этих двух величин — это доля потерь пакетов на интервале. Это отношение должно равняться значению поля доли потерь, если эти два отчета являются последовательными, в противном случае — нет. Число потерь пакетов за 1 секунду может быть получено путем деления доли потерь на разность временных меток NTP, выраженную в секундах. Количество полученных пакетов — это число ожидаемых пакетов минус число потерянных. Количество ожидаемых пакетов может также использоваться для определения статистической достоверности любых оценок потерь. Например, потеря одного пакета из пяти имеет более низкую представительную ценность, чем потеря 200 пакетов из 1000.

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

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

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

    Илон Маск рекомендует:  Что такое код sem_remove
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL