Поддерживает ли прокси HTTP/3? Как проверить QUIC и переход на HTTP/2

Поддерживает ли прокси HTTP/3?

Да, но это зависит от типа прокси, возможности передачи UDP и способа использования прокси браузером. Заявленная провайдером поддержка HTTP или HTTPS не означает, что сервис поддерживает HTTP/3. Чтобы сделать точный вывод, необходимо определить протокол на каждом участке соединения и проверить реальный сеанс доступа.

Во многих традиционных конфигурациях HTTP-прокси или HTTPS-прокси браузер обращается к HTTPS-сайтам через туннель CONNECT, работающий поверх TCP. При этом HTTP/3 использует QUIC поверх UDP. Поэтому для соединения с сайтом через такой туннель браузер обычно использует HTTP/2 или HTTP/1.1, а не HTTP/3.

В этой статье разъясняются понятие прокси HTTP/3, условия поддержки прокси QUIC и порядок проверки HTTP/3, позволяющий подтвердить переход на HTTP/2, не полагаясь только на рекламные заявления.

Что важно знать об HTTP/3, QUIC и участках прокси-соединения

HTTP/3 использует QUIC вместо TCP

Браузеры обычно используют HTTP/2 в соединении TLS поверх TCP. HTTP/3 передаёт обмен HTTP через QUIC — транспортный протокол, работающий поверх UDP и включающий механизм защиты на основе TLS.

Это различие важно при использовании прокси. Прокси, передающий только потоки TCP, не может автоматически передавать пакеты QUIC. При этом одного разрешения UDP в локальной сети недостаточно: приложение, прокси и сетевой маршрут должны поддерживать соответствующий способ передачи.

Соединение с прокси отличается от соединения с сайтом

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

Например, обратный прокси может принимать HTTP/3 от пользователей, но взаимодействовать с сервером за ним по HTTP/2. И наоборот, сервис может использовать HTTP/3 на внутреннем участке, тогда как браузер обменивается данными с внешней точкой подключения только по HTTP/2.

Поддержка HTTP/3 на одном участке не доказывает, что HTTP/3 используется на всём пути. В отчёте о проверке следует чётко указывать, какой участок наблюдается, а не просто делать вывод о наличии или отсутствии QUIC у прокси в целом.

Какие типы прокси могут передавать QUIC?

Традиционные HTTP-прокси и HTTPS-прокси

При обращении к HTTPS-сайту браузер обычно запрашивает у HTTP-прокси открытие туннеля CONNECT до целевого сервера. Традиционный CONNECT предоставляет поток TCP, подходящий для TLS и HTTP/2, но не передаёт UDP-датаграммы QUIC напрямую.

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

SOCKS5 и поддержка UDP

В SOCKS5 предусмотрен механизм UDP ASSOCIATE, однако наличие такой возможности в протоколе не означает, что браузер будет её использовать. Многие конфигурации SOCKS в браузерах предназначены преимущественно для трафика TCP.

Поэтому заявления о поддержке UDP у SOCKS5-прокси недостаточно, чтобы подтвердить работу HTTP/3 через этот прокси в браузере. Необходимо проверить и прокси-сервер, и клиентское приложение, и то, как приложение передаёт трафик QUIC через прокси-соединение.

CONNECT-UDP и архитектура MASQUE

CONNECT-UDP — это механизм, непосредственно связанный с передачей UDP через HTTP. Реализации архитектуры MASQUE могут обеспечивать основу для передачи UDP-трафика, включая QUIC, через прокси.

Однако не следует считать, что одной поддержки CONNECT-UDP на прокси достаточно для автоматической работы в любом браузере. Клиентское приложение должно поддерживать соответствующий механизм, быть правильно настроено и совместимо с сервисом. Прокси, использующий HTTP/3 для приёма соединений, также не обязательно предоставляет функцию передачи UDP до сайта.

Подготовка среды для проверки HTTP/3

Для достоверной проверки нужен исходный результат без прокси. Если сайт ни разу не работал по HTTP/3 при прямом подключении, появление HTTP/2 после включения прокси ещё не доказывает, что причина именно в прокси.

• Выберите сайт с поддержкой HTTP/3: предпочтительнее явно заявленный тестовый ресурс, для которого можно наблюдать протокол в браузере.
• Сохраняйте одинаковые условия: используйте одно и то же устройство, браузер, сеть и адрес сайта при сравнении результатов.
• Зафиксируйте конфигурацию: сохраните тип прокси, способ аутентификации и область применения настроек — для браузера или операционной системы.
• Учитывайте промежуточные факторы: отметьте наличие VPN, программ проверки HTTPS, расширений и административных политик.
• Используйте отдельный тестовый сеанс: закройте связанные сеансы или используйте отдельный профиль браузера, чтобы уменьшить влияние уже открытых соединений.

Сайт может сообщать о поддержке HTTP/3 через Alt-Svc или DNS-запись HTTPS. Иногда браузеру требуется первоначальное посещение, прежде чем он установит соединение HTTP/3. Поэтому использование HTTP/2 при первой загрузке не обязательно означает, что сайт не поддерживает HTTP/3.

Как проверить HTTP/3 в браузере

Наблюдение за столбцом Protocol в DevTools

В браузере на базе Chromium откройте инструменты разработчика, перейдите в Network и включите столбец Protocol через меню заголовка таблицы. Названия пунктов могут отличаться в зависимости от языка и версии браузера.

1. Отключите прокси, откройте тестовый сайт и панель Network.
2. Перезагрузите страницу; при открытых DevTools можно включить Disable cache, чтобы уменьшить влияние HTTP-кеша.
3. Проследите за запросом основного документа и запросами к тому же имени хоста.
4. При необходимости посетите сайт повторно, чтобы браузер мог использовать информацию о поддержке HTTP/3.
5. Зафиксируйте значение протокола, доменное имя и статус ответа для показательных запросов.

Значение h3 означает, что инструмент зафиксировал использование HTTP/3 для запроса; h2 соответствует HTTP/2. Если отображается HTTP/1.1, запрос использует именно эту версию, а не переход на HTTP/2.

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

Как отличить сетевой ответ от уже доступных данных

Запрос, обслуженный из кеша или через service worker, может не создавать нового сетевого соединения. При проверке HTTP/3 отдавайте предпочтение запросам, действительно проходящим через сеть, и проверяйте сведения об источнике ответа.

Disable cache не обязательно очищает состояние Alt-Svc или закрывает существующие соединения. Если результаты трудно объяснить, полностью закройте браузер и повторите проверку в отдельном тестовом профиле вместо простой перезагрузки страницы.

Как подтвердить переход браузера на HTTP/2 при использовании прокси

Сравнение прямого подключения и подключения через прокси

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

1. Настройте прокси и проверьте, применены ли настройки к браузеру.
2. Подтвердите маршрут доступа с помощью журналов прокси или подходящего сервиса проверки IP-адреса.
3. Снова откройте тот же сайт, который использовался для исходной проверки.
4. Проверьте столбец Protocol для основного документа и запросов к тому же имени хоста.
5. Зафиксируйте, выполняются ли запросы успешно по h2, HTTP/1.1 или возникает ошибка соединения.
6. Отключите прокси, создайте новый сеанс и повторите проверку, чтобы повысить достоверность сравнения.

Если прямое соединение использует h3, а соединение через прокси — h2, можно заключить, что сеанс доступа через прокси использует HTTP/2 вместо HTTP/3. Это полезное практическое подтверждение перехода на HTTP/2 в проверенной конфигурации.

Как отличить выбор HTTP/2 от неудачной попытки QUIC

Само наличие h2 ещё не доказывает, что браузер сначала отправил трафик QUIC, потерпел неудачу и лишь затем сменил протокол. Браузер может заранее определить, что конфигурация прокси не подходит, и сразу выбрать HTTP/2.

Если необходимо установить точную последовательность событий, соберите сетевые журналы браузера, например с помощью функции NetLog в Chromium. Найдите сведения о выборе прокси, установлении QUIC, соединении TCP и согласованном протоколе.

Вывод должен точно соответствовать доказательствам: «при доступе через прокси используется HTTP/2» — не то же самое, что «зафиксирована неудачная попытка QUIC перед установлением HTTP/2».

Проверка QUIC на сетевом уровне и с помощью инструментов командной строки

Наблюдение за UDP с помощью анализатора пакетов

Инструмент захвата пакетов может помочь выявить UDP-трафик и соединения, распознаваемые как QUIC. Ограничьте область анализа временем проверки, адресом назначения и процессом, если инструмент это поддерживает.

Однако наличие UDP не означает, что запрос к сайту использует HTTP/3. Трафик может относиться к другому приложению или другой функции браузера. И наоборот, при использовании зашифрованного туннеля наблюдение на устройстве может показывать только внешнее соединение с прокси.

Чтобы подтвердить, что QUIC действительно передаётся через прокси, следует сопоставить сведения о протоколе в браузере, журналы прокси и данные захвата пакетов. Изменение выходного IP-адреса доказывает лишь то, что запрос проверки IP прошёл по этому маршруту, но не то, что так проходят все соединения.

Использование curl для дополнительной проверки

curl может помочь проверить HTTP/3, если установленная сборка скомпилирована с соответствующей поддержкой. Сначала проверьте сведения о версии и возможностях, затем изучите документацию используемой сборки по параметрам --http3, --http3-only и настройке прокси.

Необходимо различать режим, допускающий переход на другой протокол, и режим, разрешающий только HTTP/3. При этом поддержка HTTP/3 для соединения с целевым сервером не означает автоматически, что curl поддерживает передачу QUIC через проверяемый тип прокси.

Результаты curl лишь дополняют проверку в браузере, поскольку эти два приложения могут различаться библиотеками QUIC, обработкой прокси и политиками соединений.

Типичные ошибочные выводы при оценке прокси HTTP/3

• Увидеть Alt-Svc и утверждать, что HTTP/3 уже используется: этот заголовок сообщает о возможности, но не подтверждает протокол текущего ответа.
• Увидеть h2 и сразу обвинить прокси: необходимо исключить вероятность того, что сайт, сеть или политика браузера изначально не позволяли использовать HTTP/3.
• Увидеть h3 при включённом прокси и заключить, что QUIC проходит через него: необходимо проверить область действия настроек, правила исключений и фактический маршрут соединения.
• Приравнивать поддержку UDP к поддержке в браузере: сервер может поддерживать UDP, но клиентское приложение может не уметь использовать этот механизм.
• Считать переход на HTTP/2 ошибкой: HTTP/2 может оставаться штатным рабочим протоколом, подходящим для архитектуры прокси.

Заключение

Прокси может поддерживать HTTP/3, но необходимо отдельно оценить механизм передачи UDP, возможности клиентского приложения и каждый участок соединения. Для HTTP-прокси или HTTPS-прокси с традиционным CONNECT при доступе к HTTPS-сайтам практическим выбором часто становится HTTP/2, а не QUIC.

Надёжный порядок проверки — подтвердить h3 при прямом подключении, создать новый сеанс через прокси, проверить наличие h2 и при необходимости сопоставить журналы. Такой подход помогает отличить реальную передачу QUIC через прокси от использования браузером HTTP/2, а также не спутать первоначальный выбор протокола с неудачной попыткой QUIC.