Кратко

  • RFC 9218 определяет приоритет HTTP как предложение и один из входов планировщика; он не гарантирует порядок обработки, передачи или завершения.
  • Надёжная запись должна связать сигнал на каждом переходе с правилом объединения, состоянием планировщика, распределением байтов, временем и видимым результатом.

Представим общий узел доставки, который обслуживает страницу, важную таблицу стилей и несколько изображений. Браузер помечает таблицу как u=0. Панель замечает поле и объявляет критический ресурс защищённым. Однако пограничный узел объединяет ответный сигнал источника с локальными правилами справедливости и доступной мощности. Маленькое изображение завершается первым, а таблица стилей ждёт вычислений источника. Поле сохранилось, но предполагаемый порядок не доказан.

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

RFC 9218 определяет расширяемую схему приоритизации ответов HTTP. Поле Priority передаёт сквозной сигнал. Кадры PRIORITY_UPDATE в HTTP/2 и HTTP/3 несут начальные или изменённые данные лишь на одном переходе. Захват поля в браузере не доказывает, какое значение вошло в последний планировщик.

Основные параметры намеренно просты. Срочность u лежит в диапазоне от 0 до 7; меньшее число означает более высокий приоритет, значение по умолчанию — 3. Признак инкрементальной доставки i показывает, можно ли использовать отдельные части ответа по мере их поступления, и по умолчанию выключен. Эти параметры выражают взгляд узла, а не задают универсальную очередь, долю полосы или порядок завершения.

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

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

Приоритет может измениться после запроса. Фоновая предварительная загрузка может стать срочной при переходе пользователя. PRIORITY_UPDATE передаёт полный текущий набор параметров и способен прийти одновременно с открытием целевого потока. Доказательство должно сохранять порядок полей запроса и ответа, кадров обновления, время их получения и состояние планировщика, который их использовал.

Посредники создают ещё одну границу. Они могут объединять приоритет запроса клиента с приоритетом ответа источника; RFC 9218 оставляет алгоритм реализации. Если запросы нескольких клиентов объединены в одном соединении с сервером, безусловное исполнение каждого самостоятельно заявленного u=0 может задержать остальных. Локальная политика справедливости вправе ограничить преимущество и всё равно быть корректной, хотя результат расходится с простым прогнозом панели.

RFC 9113 фиксирует, что прежняя схема RFC 7540 внедрялась неравномерно и теперь устарела в HTTP/2. Когда сигналы приоритета важны, рекомендуется альтернатива вроде RFC 9218. Поэтому запись «приоритет HTTP/2» должна указывать схему, согласованные настройки и фактическое поведение реализации.

Операционная запись об эффекте приоритета должна объединять идентификаторы запроса и ответа, точные значения Priority, каждый PRIORITY_UPDATE с указанием сетевого участка и порядка получения, результат объединения, политику планировщика и конкурирующую работу, распределение байтов во времени, а также моменты первого байта, первого полезного для приложения байта, завершения и отображения. Рядом нужны состояние кэша, размер, готовность источника и сведения о совместном использовании соединения. Это редакционный операционный синтез, а не объект протокола IETF.

Так R066 остаётся отделённым от соседних тем. BGP Add-Path спрашивает, относятся ли объявленные пути к независимым областям отказа. RFC 8097 касается происхождения состояния проверки источника маршрута. R065 рассматривал подтверждённые сертификатом полномочия на соединении. Здесь вопрос уже: породило ли предпочтение HTTP именно то поведение доставки, которое ему приписали?

Источники