Кратко

  • RFC 10055 фиксирует интерфейсы, с помощью которых Chromium включал ECN поверх UDP в Apple, Linux и Windows; это информационный документ, а не требование унифицировать API операционных систем.
  • Приложение сможет использовать сигнал только при правильной настройке сокета, получении вспомогательных данных для каждой дейтаграммы и корректном разборе платформенного формата.

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

RFC 10055 описывает эксперименты по включению ECN поверх UDP в Chromium для Apple, Linux и Windows. Это документ IETF категории Informational, а не спецификация Internet Standards Track. Он не обязывает платформы к определённому API и подчёркивает, что изложенные сведения отражают состояние на момент подготовки текста. Для более новых версий следует обращаться к документации самих платформ.

ECN занимает два бита в IP-заголовке. RFC 3168 определяет явное уведомление о перегрузке; архитектура L4S в RFC 9330 использует явные сигналы в более частом режиме. QUIC работает поверх UDP: RFC 9000 требует проверять счётчики ECN на каждом пути и отключать ECN на пути при провале проверки. Для этого приложению нужно видеть метки, пришедшие с пакетами.

В RFC 10055 приём разделён на включение уведомлений на сокете и получение метки для каждой дейтаграммы. Linux, Apple и FreeBSD используют IP_RECVTOS для IPv4 и IPV6_RECVTCLASS для IPv6; вспомогательные данные читаются, как правило, через recvmsg(). Для двухстекового IPv6-сокета в Linux требуется ещё включить IP_RECVTOS, если он должен сообщать ECN для IPv4-пакетов. Описанный порядок для Apple и FreeBSD такого дополнительного шага не требует.

В Windows используется другая поверхность: документация рекомендует WSASetRecvIPEcn(), а управляющие данные возвращаются через WSARecvMsg. RFC 10055 указывает на исключения для сокетов двойного стека и IPv4-адресов, представленных в IPv6-форме. Самого факта, что приложение создало IPv6-сокет, недостаточно: нужно проверить режим и реальный тип сообщения управления.

Форма данных тоже различается. Linux, Apple и FreeBSD могут вернуть весь байт поля DS, включая DSCP и ECN. В Windows сообщения IP_ECN и IPV6_ECN содержат только кодовую точку ECN. Общий парсер должен знать, какой вариант перед ним, иначе одинаковое извлечение битов даст несовместимые значения.

При отправке можно выбирать постоянную настройку на сокете или метку на пакет. Apple, FreeBSD и Linux поддерживали настройку на сокете в снимке RFC; сервер, обслуживающий через общий сокет соединения с разными возможностями ECN, может использовать пометку каждого пакета. В той же версии описания Windows не предоставляла настройку ECN на сокете. Кроме того, изменение IP_TOS или IPV6_TCLASS может поменять DSCP на некоторых системах. Код, который хотел изменить ECN, способен затронуть класс обслуживания другого компонента, если не сохранит исходное значение и не защитит параллельные записи.

Отсюда следует операционная сложность: отсутствие полученного CE может означать отсутствие метки на пути, но может также означать не включённую опцию, пропавшие вспомогательные данные или ошибку разбора. RFC 10055 отдельно предупреждает, что разница в поддержке ECN между ОС может помогать собеседнику определять операционную систему. Это потенциальный риск приватности; измерений распространённости или точности такого отпечатка RFC не приводит. Сами описанные вызовы следует перепроверять по актуальным справочникам, прежде чем использовать в новой версии продукта.

Проверяемая матрица должна учитывать версию ОС, семейство IP и режим двойного стека: принята ли опция, какой cmsg пришёл, какая метка извлечена, сохранился ли DSCP и прошли ли счётчики проверку транспортом. Получение CE подтверждает только один участок интерфейса, но не реакцию отправителя и не улучшение качества сервиса.

Общий контракт можно оставить узким: передавать приложению правильный ECN-код для каждого пакета и не портить соседнее состояние DSCP. API конкретных систем вправе различаться; одинаково проверяемым должен быть результат.

Источники