Comment on page
Расширения
Протокол требует, что получатель должен считывать и игнорировать все неизвестные ему типы фреймов. Таким образом, две стороны могут согласовать использование нового типа фрейма на уровне от одного промежуточного хоста к другому, этим фреймам запрещено изменять состояние и их передача не управляется.
Дискуссия по поддержке расширений в http2 длилась на протяжении всего времени разработки протокола. После draft-12 маятник качнулся последний раз и расширения были разрешены.
Расширения не являются частью текущего протокола и будут задокументированы вне основной спецификации. На данный момент уже есть два типа фрейма, которые обсуждались для принятия в протокол и станут первыми фреймами отправляемыми как расширения. Я опишу их здесь, поскольку они популярны и изначально являлись «нативными» фреймами:
После адаптации http2 есть причины ожидать, что TCP-соединения будут более продолжительными и дольше сохраняться в рабочем состоянии, чем это было с HTTP 1.x соединениями. Клиент сможет делать многое, что он захочет в рамках одного соединения к каждому хосту/сайту и это соединение вероятно будет открыто очень долго.
Это повлияет на работу HTTP-балансировщиков, и могут возникнуть ситуации, когда сайт захочет предложить клиенту подключиться к другому хосту. Это может быть как по причинам производительности, но также и необходимости отключения для обслуживания или подобных целей.
Сервер отправляет заголовок Alt-Svc (или ALTSVC-фрейм в http2), сообщая клиенту о наличии альтернативного сервиса. Дополнительный маршрут к такому же контенту, используя другой сервис, хост и номер порта.
Ожидается, что клиент попытается асинхронно подключиться к сервису и начать использовать альтернативный сервис, если он нормально работает.
Заголовок Alt-Svc позволяет серверу, который предоставляет контент по http://, информировать клиента о наличии такого же контента доступного поверх TLS-соединения.
Это отчасти спорная возможность. Такое соединение выполняет неаутентифированный TLS и не будет помечаться «безопасным» где бы то ни было: не будет показывать замочек в интерфейсе программы и никак не сообщать пользователю, что это не обычный старый открытый HTTP. Но это будет оппортунистический TLS и некоторые люди очень уверенно выступают против этой концепции.
Фрейм данного типа может быть отправлен участником http2 только один раз, когда он имеет данные для отправки, но контроль потока запрещает ему отправку каких-либо данны х. Смысл идеи в том, что если ваша реализация получает такой фрейм, вы должны понять, что ваша реализация что-то упустила и/или вы не можете добиться высоких скоростей передачи данных из-за этого.
Цитата из черновика draft-12, до того как фрейм стал расширением:
“Фрейм BLOCKED включён в эту версию черновика для удобства экспериментирования. Если результат эксперимента не даст положительных результатов он будет удалён.”
Last modified 4yr ago