Кратко

  • Обновлённый 30 сентября проект рабочей группы MASQUE требует отбросить Ethernet-кадр, превышающий доступную ёмкость QUIC DATAGRAM, и запрещает отправлять именно этот кадр вместо него в капсуле DATAGRAM. После декапсуляции кадр также должен быть отброшен, если его не принимает по размеру выходной интерфейс, сеть назначения или получатель. Рекомендуется считать такие потери.
  • Редакция 14 включала исходную Frame Check Sequence — FCS — в передаваемый кадр. Редакция 15 заканчивает полезную нагрузку непосредственно перед FCS: обычный сетевой интерфейс снимает старое значение при приёме и создаёт новое при отправке. Документ пока остаётся Internet-Draft на рассмотрении IESG, а не опубликованным RFC или отчётом о реальном сбое.

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

CONNECT-ETHERNET описывает обмен кадрами второго уровня через HTTP-прокси, связанный с физическим или виртуальным сегментом Ethernet. В варианте HTTP/3 с расширением QUIC DATAGRAM кадр должен целиком поместиться в один DATAGRAM: тот не допускает фрагментации. Из максимальной полезной нагрузки вычитаются байты обрамления HTTP Datagram. Номинальная MTU интерфейса не равна получившемуся полезному пределу. Если прибывший кадр этот предел превышает, конечный узел обязан его отбросить. Текст дополнительно закрывает соблазн запасного пути: нельзя для данного кадра заменить DATAGRAM капсулой.

Измерение MTU маршрута способно помочь настройке интерфейса в дальнейшем, но не превращает уже отброшенный кадр в доставленный.

Режим капсул остаётся предусмотренным. В HTTP/1.1, HTTP/2 и HTTP/3 без расширения QUIC DATAGRAM капсулы передаются в надёжном потоке. Один Ethernet-кадр может растянуться на несколько пакетов TCP или QUIC, поэтому его размер может превышать MTU одного пакета пути. Это свойство отдельного режима, а не разрешение автоматически переключать каждый слишком большой DATAGRAM-кадр. Если испытания ограничить малой длиной, можно подтвердить установление туннеля и одновременно пропустить его важнейшее ограничение для пользовательской нагрузки.

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

Изменение FCS показывает, почему слово «полный» в описании кадра требует точности. В редакции 14 последовательность включалась в пересылаемый кадр; автор объяснял это нежеланием пересчитывать её на концах прокси. Редакция 15 определяет нагрузку с Context ID ноль от адреса назначения до последнего байта перед FCS. Причина практическая: распространённые сетевые адаптеры удаляют FCS при получении и создают новую при передаче на следующем линке. Это не отменяет проверку ошибок Ethernet и не утверждает, что каждый туннель небезопасен. Это лишь не позволяет считать исходную FCS неизменной сквозной квитанцией данного формата.

Возможность будущего расширения оговорена отдельно.

Авторы теперь называют эмулируемую связь двухточечным Ethernet-линком. Если оператор присоединяет его к широкому домену вещания, задачи мостирования, предотвращения петель и обработки широковещательных кадров остаются за конечными узлами или компонентами, которым они их поручили. Теги VLAN по умолчанию проходят прозрачно, а их интерпретация требует согласованного поведения сторон, не определённого здесь. Разные VLAN можно привязать к отдельным URI ради независимых правил и планирования; это необязательная возможность, а не гарантия изоляции либо доставки.

Официальная карточка IETF показывает активный проект MASQUE, переданный IESG и находящийся в состоянии AD Followup с нерешённым DISCUSS. Намечен статус Proposed Standard, но документ ещё не RFC. Ни число развёртываний, ни работу конкретного производителя, ни частоту потерь из него вывести нельзя. Новость относится к границам предложенного протокола; проверка реальной услуги требует увидеть, где кадр принят, где отброшен и какой режим при этом действовал.

Источники