Кратко

  • RFC 9218 задаёт срочность u от 0 до 7 и Boolean i, показывающий пользу частичного получения. Начальное мнение несёт end-to-end поле Priority, а PRIORITY_UPDATE меняет мнение ближайшего peer в HTTP/2 или HTTP/3.
  • Сигнал не резервирует пропускную способность, CPU, место завершения или порядок retransmission. Поле Priority в response также не подтверждает, что какой-либо scheduler выполнил пожелание.
  • Надёжная эксплуатация отдельно хранит значения client, origin, cache и каждого intermediary, все перезаписи, merge rule, область клиента, queue, flow control, DATA bytes, потери, повторы и пользовательский milestone.

Важность становится известна позже запроса

Новостная страница сначала обнаруживает шрифт в head. Конкретное responsive-изображение выбирается после разбора layout. Аналитика начинается ещё позже из script. Шрифт блокирует читаемый текст, изображение может стать главным видимым элементом, аналитика не влияет на текущий жест. Поэтому браузер повышает уже отправленный image request, когда узнаёт больше.

Origin располагает другой картиной: шрифт может находиться почти во всех edge caches, а изображению нужен медленный shield. CDN видит ещё и другие frontend connections, сведённые в меньший backend pool. Полезность для одной страницы не равна справедливому распределению общей мощности.

Порядок завершения не выдаёт причину. Изображение могло победить из-за cache hit. Шрифт мог уйти раньше, потому что его bytes уже попали в окно. Маленькая background request может завершиться первой при низкой срочности. Waterfall показывает наблюдение клиента, а не внутреннее решение очереди.

Абсолютные значения не создают абсолютной власти

Старый HTTP/2 описывал относительное дерево dependencies и weights, которое оказалось сложным и неравномерно реализованным. RFC 9218 заменяет его небольшим Dictionary по Structured Fields.

u=0 означает наибольшую срочность, u=7 — наименьшую; без значения request получает 3. i по умолчанию false и говорит, даёт ли часть response полезный результат до полного получения. Несколько progressive images могут разделять полосу, а неделимый архив — выигрывать от последовательного завершения.

RFC рекомендует такое поведение, когда оно возможно, но не задаёт универсального алгоритма. Два объекта с u=0 остаются равными. В значении нет квоты, identity или срока. Если всё пометить срочным, сигнал перестаёт что-либо различать.

Уровень 7 предназначен для фоновых задач вроде software update, но не разрешает вечное starvation. Строгий приоритет на split backend connections способен выглядеть как stall и вызвать закрытие. Минимальный прогресс каждому stream — законная локальная защита системы.

Header идёт до конца, update — до следующего узла

Priority допускается в request и response. Как end-to-end field он переносит исходную оценку клиента к origin, а оценка origin может сохраниться вместе с cached response. Значение не привязано к версии HTTP на отдельном участке.

После отправки полезность может измениться. Для этого client использует PRIORITY_UPDATE: тип 0x10 в HTTP/2 и 0xF0700/0xF0701 для request/push в HTTP/3. Frame несёт полный Priority Field Value и действует hop by hop.

CDN может сохранить исходный header, но отправить другую update к backend. Он может и заменить header, изменив видимость для всех следующих получателей. Единственное поле “effective priority” уничтожает provenance. Нужны раздельные input, decision и output каждого hop.

В HTTP/3 update по control stream может прийти раньше целевого request stream. Server способен удержать последнее значение, но память ограничивается local policy. Право высказать предпочтение не обязывает peer хранить бесконечную историю.

Origin выражает знание, а не подтверждает действие

Client не всегда знает связи контента. Origin может знать, что шрифт открывает весь интерфейс или конкретное изображение несёт основной материал. Он сообщает это через response Priority.

Intermediary может объединить client и server view, но RFC 9218 не навязывает один merge algorithm. Отсутствие параметра в response означает отсутствие желания менять соответствующее client value. В request отсутствие вызывает default. Одинаковая нормализация двух направлений ошибочна.

Response field не является acknowledgement. Его наличие не доказывает работу scheduler, отсутствие не доказывает игнорирование. Cache мог уже обслужить объект, fairness могла иметь больший вес, flow control мог закрыть отправку. Метка “honored” по одному header создаёт несуществующее состояние протокола.

Множество конкурентов меняется на каждом соединении

Edge объединяет клиентов в меньшее число backend connections или разделяет один frontend по нескольким origin paths. Поэтому u сравнивается с разной группой на каждом hop. Это не глобальное место в Интернете.

Fairness требует client scope. RFC рекомендует для HTTP/1.1 backend учитывать client priority только тогда, когда её можно привязать к отдельному end client — через session или authentication. Само u identity не содержит. Иначе tenant с u=0 превращает предпочтение в требование чужой мощности.

Намеренное неравенство возможно: оплаченный tier получает больше capacity, а канал обновлений использует scavenger congestion controller. Это local business/operations policy с владельцем, метрикой, пределом и пересмотром. Wire value сам её не устанавливает.

Transport сохраняет право выбирать выполнимое

После HTTP scheduler TCP или QUIC всё ещё контролирует congestion, flow control, pacing, loss и recovery. Низкоприоритетный cache hit может обогнать срочный miss. Backend computation задерживает response ещё до byte queue.

В HTTP/3 реализация выбирает между retransmission потерянных данных менее срочного stream и новыми данными более срочного. RFC 9218 не даёт общего ответа, потому что только transport видит компромисс recovery и application value.

Причинный вывод требует connection/stream IDs, raw fields и updates, активных конкурентов, версии и quanta scheduler, окон и congestion, DATA bytes по интервалам, loss/retransmission, cache/backend timing и целевого render/application milestone.

Регистрация, интерфейс и эффект — разные доказательства

IANA регистрирует u, i, HTTP/2 setting 0x9, frame 0x10 и значения HTTP/3. Регистрация исключает конфликт синтаксиса, но не подтверждает negotiation, parsing, приём или связь с production scheduler.

nghttp2 показывает отдельные действия: application объявляет отказ от старых RFC 7540 signals, включает extension reception, передаёт header или вызывает update function. Наличие API не доказывает изменение byte allocation.

Поддержку нужно разложить на шесть проверок: negotiation, exact parsing, provenance/merge, queue state, byte allocation и outcome под контролируемой contention. Формулировка не должна идти дальше последнего наблюдаемого звена.

Тонкая спецификация оставляет последствия оператору

Minimum Initial Specification Хенга Лу ограничивает общий слой и сохраняет будущие решения локальными. RFC 9218 даёт два параметра, Dictionary, end-to-end field и version-specific updates, не учреждая глобальный scheduler.

Localized Future Decision оставляет fairness, cache, backend mapping и retransmission оператору, но требует наблюдаемости. Voluntary Adoption доказывается negotiation и поведением, а не номером RFC. Running-Code Primacy соединяет assertion, rewrite, rule, bytes, outcome и rollback.

Без этой цепочки “срочно” остаётся полезным пожеланием. Оно не владеет следующим байтом.

Источники