# Расширения

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

Дискуссия по поддержке расширений в http2 длилась на протяжении всего времени разработки протокола. После draft-12 маятник качнулся последний раз и расширения были разрешены.

Расширения не являются частью текущего протокола и будут задокументированы вне основной спецификации. На данный момент уже есть два типа фрейма, которые обсуждались для принятия в протокол и станут первыми фреймами отправляемыми как расширения. Я опишу их здесь, поскольку они популярны и изначально являлись «нативными» фреймами:

## 7.1. Альтернативные сервисы

После адаптации http2 есть причины ожидать, что TCP-соединения будут более продолжительными и дольше сохраняться в рабочем состоянии, чем это было с HTTP 1.x соединениями. Клиент сможет делать многое, что он захочет в рамках одного соединения к каждому хосту/сайту и это соединение вероятно будет открыто очень долго.

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

Сервер отправляет заголовок [Alt-Svc](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (или ALTSVC-фрейм в http2), сообщая клиенту о наличии альтернативного сервиса. Дополнительный маршрут к такому же контенту, используя другой сервис, хост и номер порта.

Ожидается, что клиент попытается асинхронно подключиться к сервису и начать использовать альтернативный сервис, если он нормально работает.

### 7.1.1. Оппортунистический TLS

Заголовок Alt-Svc позволяет серверу, который предоставляет контент по http\://, информировать клиента о наличии такого же контента доступного поверх TLS-соединения.

Это отчасти спорная возможность. Такое соединение выполняет неаутентифированный TLS и не будет помечаться «безопасным» где бы то ни было: не будет показывать замочек в интерфейсе программы и никак не сообщать пользователю, что это не обычный старый открытый HTTP. Но это будет оппортунистический TLS и некоторые люди очень уверенно выступают против этой концепции.

## 7.2. Блокировка

Фрейм данного типа может быть отправлен участником http2 только один раз, когда он имеет данные для отправки, но контроль потока запрещает ему отправку каких-либо данных. Смысл идеи в том, что если ваша реализация получает такой фрейм, вы должны понять, что ваша реализация что-то упустила и/или вы не можете добиться высоких скоростей передачи данных из-за этого.

Цитата из черновика draft-12, до того как фрейм стал расширением:

> “Фрейм BLOCKED включён в эту версию черновика для удобства экспериментирования. Если результат эксперимента не даст положительных результатов он будет удалён.”