Кратко

  • UDP не устанавливает соединение, поэтому открывший сокет прокси не знает, достижим ли адресат. RFC 9298 требует отвечать, не дожидаясь пакета с той стороны.
  • Успешный CONNECT-UDP означает, что прокси открыл сокет в сторону запрошенной цели и готов пересылать UDP. Он не доказывает доставку, ответ, личность приложения или продолжительную двустороннюю работу.
  • David Schinazi зафиксировал полезную границу знания. Чтобы её не потерять, эксплуатация должна отдельно хранить квитанции авторизации, DNS, сокета, движения дейтаграмм и внутреннего протокола.

Пустое место, которое нельзя заполнять догадкой

В журнале сначала появляется успешный HTTP-ответ. Затем оператору хочется написать более понятную формулировку: «удалённый сервис доступен». Между этими записями нет технического перехода—только человеческая интерпретация.

RFC 9298 задаёт CONNECT-UDP как способ передавать UDP через HTTP-прокси. Клиент использует абсолютный URI Template с переменными target_host и target_port. Прокси извлекает цель, проверяет правила и открывает UDP-сокет. Полезная нагрузка проходит в HTTP Datagrams на базе RFC 9297; запуск туннеля использует Extended CONNECT либо Upgrade в зависимости от HTTP.

У TCP удалённая сторона участвует в установлении соединения. У UDP универсального обмена подтверждениями нет. Создание сокета—локальная операция системы прокси. В этот момент адресат может не существовать, быть отфильтрованным или не иметь нужного приложения. Никакой из этих вариантов не обязан мешать локальному открытию.

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

Этот статус содержателен. Он просто заканчивается раньше, чем начинается свидетельство адресата.

У имени и приложения разные часы

Для DNS-имени прокси обязан выполнить разрешение до ответа. Ошибка ведёт к отказу, который можно пояснить полем Proxy-Status из RFC 9209, например типом dns_error.

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

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

RFC 9209 описывает и другие отрицательные знания посредника: цель не найдена, недоступна, запрещена или не маршрутизируется. Отсутствие такого знания не становится положительным. ICMP может быть потерян; сеть может отбрасывать без сообщения; UDP-приложение может не отвечать на непонятный формат.

Нет ошибки—значит только, что ошибка не была получена и распознана.

Совпадение сетевой пары ещё не удостоверяет собеседника

Connected UDP-сокет позволяет ядру принимать только пакеты с ожидаемым 5-tuple. Для unconnected-сокета RFC 9298 требует от прокси проверить исходный IP и порт каждого входящего пакета и отбросить несовпадение.

Это сильная проверка сетевого соответствия. Но пакет с правильного адреса может быть повтором, мусором или неаутентифицированным сообщением. Внутренний протокол сам определяет личность и приём. Например, завершённый аутентифицированный handshake QUIC сообщает больше, чем один UDP-пакет с правильного порта.

Жизнь сокета связана с request stream. Пока поток открыт, сокет сохраняется. Если ОС сообщает, что сокет больше непригоден—возможный пример: ICMP Destination Unreachable,—прокси закрывает поток. Допустимо закрытие по бездействию; спецификация не рекомендует порог менее двух минут.

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

Доставка имеет собственные точки отказа

В RFC 9298 нулевой Context ID несёт UDP payload. Ненулевые значения оставлены расширениям и имеют область одной HTTP-заявки. При переупорядочивании дейтаграмма может прийти раньше регистрации контекста. Получатель вправе молча удалить её или ненадолго сохранить. То же возможно, если данные пришли раньше самой заявки.

Клиент может отправлять оптимистично до ответа CONNECT-UDP. Если запрос впоследствии отклонён или прокси не буферизует ранние пакеты, эти данные не будут обработаны.

Есть и предел размера. Payload с Context ID 0 не превышает 65 527 байт; реальный MTU часто ниже. Прокси не должен добавлять IP-фрагментацию и иногда обязан молча удалить слишком большую HTTP Datagram.

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

Автор стандарта и границы авторства

RFC 9298 вышел в августе 2022 года в Standards Track IETF и называет David Schinazi автором. Письменный профиль Datatracker, сохранённый 2 сентября 2026 года, описывает его как senior staff software engineer и senior manager в Google, работающего прежде всего над Privacy Proxy, MASQUE и OHTTP. Там же указаны прежняя совместная работа во главе QUIC, руководство Chrome Networking и сетевые технологии Apple. Должности, принадлежность и число RFC относятся ко времени снимка.

Официальный портрет IETF подтверждает публичную визуальную идентичность, но не контроль над развёртыванием. И техническая среда коллективна: RFC 9297 написан Schinazi и Lucas Pardue; RFC 9484 имеет пять авторов, расширяет семейство до IP proxy и обновляет регистрацию well-known URI masque. MASQUE Working Group—совместная работа IETF.

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

Running-Code Primacy Heng Lu предлагает тот же критерий: утверждать только то, что исполняемая функция действительно делает. Minimum Initial Specification оставляет общий механизм минимальным, а смысл аутентификации, ответа и повторов—ближе к конкретному приложению.

Пять источников факта вместо одного статуса

Первый источник—политика прокси. Записываются клиент или класс доступа, цель, версия правила, лимит скорости или объёма и решение. Это необходимо, потому что адресат видит источником прокси. Без ограничений клиент способен направить злоупотребление от его имени либо достичь loopback, link-local, multicast или broadcast.

Второй источник—DNS. Третий—сокет: локальный egress, connected или unconnected, peer, поток-владелец, время и причина завершения.

Четвёртый—телеметрия дейтаграмм. Она разделяет направления, первые и последние пакеты, количество, байты и удаления из-за размера, неизвестного Context ID, буфера, неправильного источника или системной ошибки. Для этого не требуется хранить содержимое.

Пятый—внутренний протокол. Он выдаёт удостоверенную личность, завершение handshake, связанную с запросом реакцию, явный отказ, timeout и правило retry. Только здесь можно определить прикладное значение ответа.

Вместо одного зелёного поля получаются ступени: доступ разрешён; имя разрешено; сокет открыт; исходящие данные видны; входящие видны; peer удостоверен; операция принята. Неизвестность остаётся видимой, а не превращается в ошибочную уверенность.

Ограниченная квитанция защищает решение

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

RFC 9298 не нуждается в более широкой формулировке. Прокси свидетельствует о готовности. Резолвер—об адресе. ОС—о сокете. Счётчики—о движении. Приложение—о личности и результате.

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

Источники