HTTP/2 и прокси: где помогает одно соединение

Основная идея

HTTP/2 объединяет несколько потоков в одном соединении, поэтому серия ресурсов может загружаться быстрее без открытия отдельного TCP/TLS-канала для каждого файла. Туннель до прокси и соединение прокси с сайтом при этом могут использовать разные версии протокола.

В теме «HTTP/2 и прокси: где помогает одно соединение» слово «скорость» нужно разложить на задержку соединения, ожидание первого байта и передачу данных. Один маленький файл почти полностью измеряет задержку, а большой может упереться в канал клиента или сервера. Поэтому вывод делают по серии одинаковых запросов и сравнивают с прямым маршрутом в то же время.

Что подтверждает первичный источник

Объясняем мультиплексирование и почему скорость нельзя оценивать по единственной маленькой загрузке.

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

Практический стенд

Разместите на своём домене страницу из 20 небольших ресурсов и один файл известного размера. В DevTools или curl сравните прямой запрос и HTTPS через прокси: версию протокола между браузером и origin, число соединений, TTFB и общее время. Повторите после прогрева. Мультиплексирование HTTP/2 относится к конкретному участку и не гарантирует, что клиент общается с самим прокси по HTTP/2.

Проверка шаг за шагом

Сравнивайте не один маленький файл, а одинаковую группу ресурсов после холодного запуска. В DevTools сохраните negotiated protocol, число соединений, TTFB и полный объём, затем повторите в той же географии.

Подготовьте два объекта на контролируемом сервере: небольшой ответ для задержки и файл известного размера для пропускной способности. Выполните прогрев, затем не менее пяти измерений напрямую и через прокси. Ограничьте параллельность одним соединением, если проверяете маршрут, и отдельно повторите реальную нагрузку, если приложение обычно открывает несколько соединений.

Записывайте DNS, connect, TLS, time to first byte, total и число переданных байтов. Используйте медиану, а не лучший результат. Если медленным оказался только первый запрос, причиной может быть DNS, TLS или холодный кэш. Если растёт время передачи большого файла, проверяйте канал, потери и ограничения сервера; смена IP без этих данных ничего не доказывает.

• Проверить negotiated protocol
• Снять холодный запуск
• Повторить после прогрева
• Сравнить медианы и число соединений

Какие данные сохранить

Сохраните negotiated protocol, количество соединений, времена отдельных фаз, размер ответа и медиану пяти запусков. Укажите кэширован ли ресурс; иначе прогретый HTTP/1.1 может выглядеть быстрее холодного HTTP/2.

В отчёт включают размер файла, расположение контрольного сервера, тип подключения, пять исходных значений и медиану. Для 10 МБ указывайте, что это скорость между клиентом и проверочным endpoint WorldProxy через выбранную прокси, а не универсальная скорость всего интернета. Отдельно отмечайте HTTP-ошибки: быстрая страница 403 не является успешным замером.

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

Как читать результат

Мультиплексирование не лечит медленный origin, потерю пакетов или ограничение полосы на прокси. По одному ping нельзя сделать вывод о скорости страницы.

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

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

Разбор рабочего решения

Для темы «HTTP/2 и прокси: где помогает одно соединение» заранее задайте бюджет измерения. Один цикл может включать прогрев, пять маленьких запросов, пять передач файла и такой же прямой контроль. Между тяжёлыми циклами нужна пауза, а параллельность должна быть фиксированной. Это защищает сервис от собственной проверки и делает серии сравнимыми. Если используется тарификация по трафику, в отчёте укажите ожидаемый расход до запуска, чтобы тест не стал неожиданной докупкой.

Разделяйте задержку и пропускную способность. Маленький ответ показывает стоимость DNS, соединения, TLS и первого байта; файл 10 МБ сильнее отражает передачу между клиентом и проверочным сервером через выбранную прокси. Ни один результат не является универсальной скоростью интернета. Для сайта с множеством ресурсов отдельно измерьте реальный сценарий браузера, потому что повторное использование соединений и кэш меняют картину.

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

Типичные ошибки

Нельзя сравнивать Wi‑Fi утром с кабелем вечером, разные файлы или разные CDN-узлы. Не отключайте таймаут, пытаясь дождаться бесконечного ответа, и не запускайте десятки тяжёлых тестов подряд. Они расходуют трафик и сами создают очередь. Лучше ограниченная серия, пауза и повтор только аномальных значений.

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

Критерии внедрения и сопровождение

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

Через неделю после запуска проверьте, совпадают ли фактическая нагрузка, расходы и качество с тестом. Затем назначьте регулярный малый контроль и повторную проверку после обновления клиента, прокси-сервиса или сетевой схемы. Устаревшую инструкцию архивируйте вместе с датой и причиной замены, чтобы сотрудники не использовали две конфликтующие конфигурации.

Рабочий регламент

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

• Есть прямой контроль
• Файл и endpoint одинаковы
• Сохранены отдельные фазы
• Используется медиана серии
• Ошибки отделены от скорости
• Указано, какой участок маршрута измерен