Bun получил HTTP/2: что проверить у API и WebSocket

В Bun 1.4.1 появилась поддержка HTTP/2 в Bun.serve, но это не делает любой API, WebSocket или gRPC-сервис совместимым с новым режимом. Проверять нужно каждый участок соединения: клиент с прокси и прокси с приложением могут использовать разные протоколы. Надпись h2 в браузере отвечает только на часть вопроса.

Что объявил Bun и что ограничивает документация

Выпуск Bun 1.4.1 от 4 сентября 2026 года добавил HTTP/2 на том же порту и с теми же routes и fetch-обработчиком, что у HTTP/1.1. Общий обработчик удобен для кода приложения, но не отменяет различия в возможностях транспорта.

Документация Bun.serve помечает поддержку HTTP/2 как экспериментальную. В ней отдельно указано отсутствие WebSocket поверх HTTP/2, server push и response trailers, необходимых gRPC. Поэтому фразу «поддерживается HTTP/2» нельзя сокращать до «подходит любой сценарий на HTTP/2».

Карта соединений вместо одной отметки в браузере

Начните с рисунка маршрута конкретного запроса. Где завершается TLS? Кто устанавливает соединение с приложением? Через какой узел идут долгие подключения? Ответы нужны для каждого сервиса, а не для сайта вообще. Следующая таблица — наша схема разбора, не результат нагрузочного тестирования Bun.

Почему отключать HTTP/1.1 вслепую опасно для чата

В текущем описании Bun server.upgrade работает только с запросами HTTP/1.1. Если приложение одновременно отдаёт API и обслуживает чат, решение отказаться от HTTP/1.1 должно учитывать этот отдельный путь. Успех обычного запроса не подтверждает установление постоянного соединения.

В учебной схеме клиент обращается к прокси, а прокси передаёт запросы приложению. Проверяющий видит HTTP/2 снаружи и решает отключить HTTP/1.1 на сервере. Но внешний протокол не говорит, как настроен upstream и куда попадает WebSocket. Это условный пример; он не описывает конкретную инфраструктуру читателя.

Одинаковый обработчик не гарантирует одинаковую эксплуатацию

В тесте API сравнивайте прикладной результат: переданные данные, полученный статус, обработку отказа и запись результата. Отдельно проверьте длинный ответ и прекращение соединения клиентом, если это действительно используется. Цель — увидеть отличия вашего маршрута, а не собрать произвольный набор сетевых проверок.

Не обещайте владельцу сервиса ускорение только из-за смены протокола. Время ответа может определяться обращением к базе или внешней системе. Чтобы обсуждать выигрыш, заранее выберите пользовательскую операцию, одинаковые условия сравнения и показатель. Опубликованные производителем измерения другой нагрузки не становятся измерениями вашего API.

Как принять решение по существующему проекту

1. Запишите необходимые сценарии: обычные запросы, потоки, WebSocket, другие используемые протоколы.
2. Для каждого нарисуйте фактическую цепочку соединений.
3. Сверьте ограничения текущей документации с требованиями сценария.
4. Оставьте совместимый путь для возможностей, которые новый режим не обслуживает.
5. Проверьте прикладной результат на отдельной среде.
6. Согласуйте условия включения и возврата настройки без потери данных.

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

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