IETF утвердил HTTP/2 как RFC 7540 в феврале 2015 года. Это первое крупное обновление протокола с 1999 года, и оно меняет не синтаксис запросов, а механику их доставки. Семантика остаётся прежней: методы, коды статусов, заголовки работают как раньше. Переписывать прикладную логику не нужно. Но транспортный слой становится бинарным и мультиплексированным, и это напрямую влияет на скорость отдачи страниц и пропускную способность API. Разберём, что это значит для корпоративных систем и госпорталов.
Что именно изменилось в протоколе
HTTP/1.1 открывал на каждый ресурс отдельное соединение или гонял запросы по очереди. Браузеры обходили ограничение, держа по 6 соединений на хост и склеивая файлы в спрайты и бандлы. HTTP/2 убирает эти костыли. Одно TCP-соединение мультиплексирует десятки параллельных потоков, заголовки сжимаются алгоритмом HPACK, а сервер может выталкивать ресурсы клиенту до явного запроса через server push.
Для веб-приложений это означает заметный выигрыш на страницах с большим числом мелких ресурсов: формы, дашборды, личные кабинеты. Практики оптимизации под HTTP/1.1 – доменное шардирование, конкатенация скриптов – в HTTP/2 теряют смысл, а иногда вредят, потому что мешают приоритизации потоков.
Отдельный нюанс: спецификация не требует TLS, но все браузеры – Chrome, Firefox – поддерживают HTTP/2 только поверх зашифрованного соединения. На практике переход на протокол означает переход на HTTPS по умолчанию. Для госсектора это совпадает с курсом на шифрование персональных данных и защищённый межведомственный обмен.
Что это даёт API и интеграциям
REST-API под нагрузкой страдают от той же проблемы, что и веб-страницы: множество мелких запросов, каждый со своим набором заголовков. Авторизационные токены, версии, трассировка раздувают служебную часть до объёма, сопоставимого с полезной нагрузкой. HPACK сжимает повторяющиеся заголовки между запросами в одном соединении, и накладные расходы падают в разы.
Мультиплексирование снимает блокировку очереди (head-of-line на уровне приложения): медленный ответ одного эндпоинта больше не задерживает остальные в том же соединении. Для интеграционных шин и шлюзов это прямой рост пропускной способности без увеличения числа соединений к бэкенду. На границе кластера HTTP/2 разгружает балансировщики и сокращает задержки между микросервисами, поэтому протокол стоит закладывать уже при проектировании интеграционных решений и API-шлюзов.
Ограничение тоже стоит назвать честно: server push капризен в кешировании и пока даёт выигрыш не везде, а выгода мультиплексирования проявляется при реальной параллельной нагрузке, а не на единичных запросах.
Как готовить инфраструктуру
Прикладной код в большинстве случаев трогать не нужно – достаточно обновить периметр. Nginx обещает поддержку в течение года, в Apache модуль mod_http2 уже на подходе. Реальный сценарий внедрения: терминируем HTTP/2 на реверс-прокси или балансировщике, а к бэкенду общаемся по HTTP/1.1. Так вы получаете выигрыш на участке клиент–сервер без переделки внутренних сервисов.
Перед переходом проверьте три вещи. Первое – актуальность TLS-сертификатов и поддержку ALPN, через который согласуется версия протокола. Второе – не сломают ли отказ от спрайтов и шардирования текущую сборку фронтенда. Третье – совместимость старых клиентов: HTTP/2 откатывается на 1.1 прозрачно, но это стоит протестировать. Те же требования к зрелости инфраструктуры мы предъявляем, когда разворачиваем ML-сценарии для бизнеса или выстраиваем хранение данных по дорожной карте локализации.
Вывод
HTTP/2 – не повод переписывать приложения, а повод пересмотреть транспортный слой и периметр. Семантика прежняя, выигрыш реальный: меньше задержек, выше пропускная способность API, проще архитектура фронтенда. Начинайте с обновления балансировщиков и перехода на HTTPS – остальное можно мигрировать поэтапно.
