Порядок создания СЗПДн. Требования к сетевым устройствам
 Скачать 1.38 Mb.
|
|
§4.1. UDP-протокол §4.1.1. Предисловие Протокол доставки дейтаграмм пользователя (User Datagram Protocol — UDP-протокол) реализует только минимальный транспортный сервис — негарантированную доставку UDP-блоков — и предоставляет прикладным модулям (процессам) прямой доступ к дейтаграммной службе сетевого (IP-)уровня. Этот протокол используется прикладными протоколами (системами, процессами), которые не требуют такого качества услуг, предоставляемых ТСР-протоколом, или которые желают использовать услуги по организации виртуального соединения, не предоставляемых ТСР-протоколом (например, доставка IP-пакетов с использованием групповой или широковещательной IP-адресации). UDP-протокол является почти “пустым протоколом” (“null protocol”). Среди услуг, которые он предоставляет, это только вычисление проверочной (контрольной) суммы с использованием IP-адресов и мультиплексирование блоков транспортного уровня на основе номера транспортного порта. Более того, прикладная программа, функционирующая совместно UDP-протоколом, обязана сама решать проблемы сквозного соединения, которые мог бы решить протокол транспортного уровня с установлением соединения (повторная передача для обеспечения надёжной доставки, фрагментация и обратная сборка, управление потоком, предотвращение перегрузок), когда бы это понадобилось. Довольно сложная связь между IP- и ТСР-протоколами будет также отражаться в соединении между UDP-протоколом и многими прикладными системами (процессами), использующими UDP-протокол. §4.1.2. Специфические проблемы §4.1.2.1. Пóрты Правила использования UDP-протоколом хорошо известных пóртов (well-known ports) полностью совпадают с правилами для ТСР-протокола. Если IP-пакет содержит UDP-блок с номером UDP-порта, который “не ожидает” получение такого блока (не находится в режиме “прослушивания порта”, “LISTEN call”), то программный модуль, реализующий функции UDP-протокола (UDP-модуль), должен передать ICMP-сообщение об ошибке “Порт не достижим” (“Port Unreachable”). §4.1.2.2. Дополнительные функции IP-протокола Программный UDP-модуль должен в обязательном порядке, причём в явном виде, транслировать данные любой дополнительной функции IP-протокола, принятые на сетевом (IP-)уровне, на прикладной уровень. Прикладной программный модуль (процесс) должен обладать способностью определения дополнительных функций IP-протокола для передачи их UDP-модулю с целью формирования UDP-блоков, а UDP-модуль обязан транслировать эти дополнительные функции на сетевой (IP-)уровень. В настоящее время, дополнительными функциями, которые необходимо транслировать через UDP-модуль, являются “Исходный маршрут или маршрут от источника” (“Source Route”), “Регистрация маршрута” (“Record Route”) и “Метка времени” (“Timestamp”). Тем не менее, в перспективе могут быть определены иные дополнительные функции, и UDP-модулю нет необходимости и даже не целесообразно “выдвигать” какие-либо предположения относительно формата или содержания таких функций, данные которых будут транслироваться на или от прикладного модуля (процесса). Исключением в данном случае может быть дополнительная функция IP-протокола “Безопасность” (“Security”). Прикладному модулю (процессу), функционирующему совместно с UDP-модулем, понадобиться получение маршрута от источника из UDP-блока/запроса и формирование обратного маршрута (то есть с точностью до “наоборот”) для отправки соответствующего ответа. §4.1.2.3. ICMP-сообщения Программный UDP-модуль должен в обязательном порядке транслировать ICMP-сообщения об ошибках, принятые от сетевого (IP-)уровня, на прикладной уровень. По крайней мере, на понятийном уровне это могло бы завершиться передачей ответа ERROR_REPORT (сообщение об ошибке) прикладному процессу. Следует заметить, что ICMP-сообщения об ошибках, полученные в ответ после передачи IP-пакета, содержащего UDP-блок, поступают асинхронно. Функционирующий совместно с UDP-модулем прикладной модуль (процесс), который пожелает принимать ICMP-сообщения об ошибках, берёт на себя ответственность за демультиплексирование таких сообщений при их поступлении через транспортный интерфейс. Например, с этой целью прикладной модуль (процесс) может находиться в состоянии ожидания процедуры приёма. Также прикладной модуль (процесс) несёт ответственность за предотвращение нештатных ситуаций, вызванных задержкой поступления ICMP-сообщений об ошибках, которые явились результатом раннее переданного UDP-блока, но транслируемых через один и тот же транспортный порт (или через несколько одинаковых портов). §4.1.2.4. Проверочная сумма UDP-протокола ГВМ должна обладать способностью вычисления и проверки контрольных сумм UDP-протокола. Дополнительно прикладной модуль (процесс) может обладать способностью контролировать наличие или отсутствие проверочной суммы UDP-протокола, но в режиме по-умолчанию эти две функции должны быть реализованы. Если был получен UDP-блок с проверочной суммой, которая является не нулевой и некорректной, то UDP-модуль должен по умолчанию его уничтожить. Дополнительно прикладной модуль (процесс) может обладать способностью контролировать отсутствие проверочной суммы UDP-блоках, и если последние без проверочной суммы, то их целесообразно уничтожать или транслировать на прикладной уровень. Некоторые прикладные системы, которые обычно функционируют во взаимодействующих между собой (противоположных) ЛВС через Internet-сеть, в целях повышения эффективности блокируют функции вычисления и проверки контрольных сумм UDP-протокола. И в результате такого блокирования имеют место многочисленные случаи не обнаруживаемых ошибок вследствие отсутствия ответных сообщений о них. Даже целесообразность блокировки функции вычисления и проверки контрольных сумм UDP-протокола является весьма сомнительной. Существует общая ошибка при реализации функции вычисления и проверки контрольных сумм UDP-протокола. В отличие от вычисления и проверки контрольных сумм ТСР-протокола, эта функция в UDP-протоколе является не обязательной. Нулевое значение, содержащееся в поле “Контрольная сумма” заголовка принятого UDP-блока, указывает на то, что значение контрольной суммы отсутствует. Если после вычисления контрольной суммы её значение действительно равно нулю, передающая сторона должна заполнить поле “Контрольная сумма” заголовка UDP-блока единицами (десятичное значение — 65535). §4.1.2.5. UDP-протокол и многоадресная ГВМ При получении IP-пакета с UDP-блоком его специфический IP-адрес получателя должен быть доставлен на прикладной уровень. Прикладной программный модуль (процесс) должен точно определять IP-адрес отправителя в принятом IP-пакете, доставляющем UDP-блок, или оставлять его не опознанным (в этом случае программный IP-модуль будет выбирать соответствующий IP-адрес отправителя). Целесообразно, чтобы был реализован способ установления канала взаимодействия с прикладным уровнем с целью выбора IP-адреса отправителя (например, для того, чтобы прикладной модуль мог в последующем принять ответный UDP-блок только через соответствующий интерфейс). Прикладной модуль, использующий UDP-протокол, должен использовать в ответе тот IP-адрес отправителя, который являлся специфическим IP-адресом получателя в запросе. §4.1.2.6. Некорректные IP-адреса Полученный IP-пакет, содержащий заголовок с некорректным IP-адресом отправителя и UDP-блок (например, широковещательный или групповой IP-адрес), должен уничтожаться UDP- или IP-модулем. Когда ГВМ транслирует IP-пакет, содержащий UDP-блок, то IP-адрес отправителя должен быть (одним из) IP-адресом(ов) самой ГВМ. §4.1.3. Транспортный интерфейс (между UDP- и прикладным модулями) транспортный интерфейс между UDP- и прикладным модулями (транспортным и прикладным уровнями) должен предоставлять все услуги сетевого интерфейса между сетевым(IP-) и транспортным модулями (сетевым(IP-) и транспортным уровнями), представленными в §3.4. Таким образом, прикладной модуль, использующий UDP-протокол, запрашивает функции GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB()иRECV_ICMP(), также представленные в §3.4. Например, функция GET_MAXSIZES() может использоваться для определения эффективного максимального размера UDP-блока, транслируемого IP-пакетом, для соответствующей структуры из трёх параметров {interface,remote host,TOS} (интерфейс, удалённая ГВМ, категория обслуживания). Прикладной программный модуль должен обладать способностью устанавливать значения параметров TTL и TOS, а также дополнительных IP-функций при трансляции IP-пакета, доставляющего UDP-блок. Значения этих параметров должны доставляться на IP-уровень прозрачно. Программный UDP-модуль может транслировать полученное значение параметра TOS на прикладной уровень. §4.1.4. Требования к ГВМ на транспортном уровне для UDP-протокола На рис.8 представлена таблица с общими требованиями к ГВМ на транспортном уровне для UDP-протокола.
Рис.8. Требования к ГВМ на транспортном уровне для UDP-протокола §4.2. Протокол управления передачей (ТСР-протокол) §4.2.1. Предисловие Протокол управления передачей (Transmission Control Protocol — TCP-протокол, RFC-793) является основным протоколом с установлением соединений транспортного уровня Internet-архитектуры. ТСР-протокол обеспечивает надёжную последовательную доставку полнодуплексного потока октетов (8-битовых последовательностей). Этот протокол используется теми прикладными системами (процессами), которые нуждаются в надёжной канально-ориентированной транспортной службе, например, электронная почта (SMTP-протокол), доставка файлов (FTP-протокол) и служба виртуального терминала (TELNET-протокол). §4.2.2. Обзор протокола §4.2.2.1. Хорошо известные по́рты: RFC-793 Программный модуль ТСР-протокола (ТСР-модуль) резервирует номера пóртов в диапазоне от 0 до 255 для так называемых хорошо известных пóртов, используемых для доступа к службам, которые стандартизированы в рамках Internet-архитектуры. Оставшаяся часть диапазона номеров может быть свободно распределена между прикладными системами (процессами). Перечень хорошо известных пóртов можно найти на WEB-сайте IETF (www.iana.org). Необходимые условия для определения нового хорошо известного номера порта представлены в соответствующих RFC-документах. Некоторые системы расширяют такой подход к распределению пространства номеров путем добавления третьего субдиапазона номеров ТСР-пóртов: так называемых зарезервированных по́ртов, которые используются, как правило, для обозначения специализированных служб, реализуемых операционными системами. Например, зарезервированные пóрты могут занять диапазон между значением 256 и некоторым верхним пределом, зависящим от конкретной системы. В дальнейшем некоторые системы предпочтут запрет хорошо известных и зарезервированных по́ртов за счёт допуска к открытым ТСР-соединениям с такими номерами по́ртов только привилегированных пользователей. Это вполне приемлемое решение, но только до тех пор, пока ГВМ не будет предполагать, что все ГВМ защищают свои пóрты с малыми значениями номеров именно таким способом. |