HTTP/2 и HTTP/3 в туннелях — разбор протоколов

Почему версия HTTP-протокола важна в туннелях

Когда вы создаёте HTTP-туннель, каждый запрос из внешнего мира проходит через relay-сервер к вашей локальной машине. Протокол, используемый для этого маршрута — HTTP/1.1, HTTP/2 или HTTP/3 — определяет, насколько эффективно передаются эти запросы. В HTTP/1.1 каждый запрос ждёт завершения предыдущего на данном соединении. В HTTP/2 десятки запросов летят параллельно через одно соединение. В HTTP/3 (QUIC) даже потеря пакета в сети не блокирует несвязанные запросы.

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

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

HTTP/1.1 vs HTTP/2 vs HTTP/3: ключевые различия

Вот как три версии HTTP соотносятся друг с другом, особенно в контексте туннелированного трафика.

HTTP/2 — это строгое улучшение HTTP/1.1 практически для всех сценариев. HTTP/3 идёт дальше, заменяя TCP на QUIC, решая последнюю проблему с head-of-line блокировкой и добавляя миграцию соединений. Для туннелирования оба протокола дают значительные преимущества перед оригинальным HTTP/1.1.

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

HTTP/1.1 использует простую модель «запрос-ответ». Браузеру нужны изображение, стиль и скрипт? Он открывает несколько TCP-соединений (обычно 6 на домен) и отправляет по одному запросу на соединение. Каждое соединение требует отдельного TCP-хэндшейка и TLS-согласования. В туннеле каждое из этих соединений пробрасывается отдельно.

HTTP/2 меняет это принципиально. Все запросы к домену идут через одно TCP-соединение как независимые потоки. Туннелю достаточно обслуживать одно соединение на клиента, пока десятки запросов проходят через него одновременно.

HTTP/1.1 через туннель: последовательная модель

Browser                    fxTunnel Server              fxTunnel Client         localhost:8080
   |                            |                            |                       |
   |--- TCP conn #1 ---------->|--- stream #1 ------------->|--- TCP conn #1 ------>|
   |    GET /style.css          |                            |    GET /style.css      |
   |    (ждёт ответа)           |                            |    (ждёт)              |
   |<-- response 1 ------------|<-- response 1 -------------|<-- response 1 ---------|
   |                            |                            |                       |
   |--- TCP conn #2 ---------->|--- stream #2 ------------->|--- TCP conn #2 ------>|
   |    GET /app.js             |                            |    GET /app.js         |
   |    (ждёт ответа)           |                            |    (ждёт)              |
   |<-- response 2 ------------|<-- response 2 -------------|<-- response 2 ---------|
   |                            |                            |                       |
   |--- TCP conn #3 ---------->|--- stream #3 ------------->|--- TCP conn #3 ------>|
   |    GET /logo.png           |                            |    GET /logo.png       |
   |<-- response 3 ------------|<-- response 3 -------------|<-- response 3 ---------|

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

HTTP/2 через туннель: мультиплексированная модель

Browser                    fxTunnel Server              fxTunnel Client         localhost:8080
   |                            |                            |                       |
   |=== single TCP + TLS =====>|=== single stream =========>|=== single TCP =======>|
   |                            |                            |                       |
   | stream 1: GET /style.css  | stream 1: GET /style.css   | stream 1: GET /style  |
   | stream 2: GET /app.js     | stream 2: GET /app.js      | stream 2: GET /app.js |
   | stream 3: GET /logo.png   | stream 3: GET /logo.png    | stream 3: GET /logo   |
   |                            |                            |                       |
   | <-- stream 3: logo.png    | <-- stream 3: logo.png     | <-- stream 3: logo    |
   | <-- stream 1: style.css   | <-- stream 1: style.css    | <-- stream 1: style   |
   | <-- stream 2: app.js      | <-- stream 2: app.js       | <-- stream 2: app.js  |
   |                            |                            |                       |
   |=== всё через 1 соед. ====>|==========================>|========================>|

Одно соединение, один TLS-хэндшейк, один поток через мультиплексор. Ответы приходят в произвольном порядке — какой готов первым. Туннель обрабатывает в три раза меньше накладных расходов на соединения, обеспечивая при этом лучшую производительность для пользователя.

Почему это особенно важно для туннелей

Выигрыш от мультиплексирования HTTP/2 усиливается в туннеле, потому что каждое соединение между сервером и клиентом проходит через relay с дополнительной задержкой. В HTTP/1.1 эта задержка оплачивается за каждое соединение. В HTTP/2 — один раз. Для страницы с 30 ресурсами это может означать разницу между отзывчивой демонстрацией и медленной.

Внутренний мультиплексор fxTunnel (описан в статье об архитектуре) уже мультиплексирует логические потоки через одно TLS-соединение. Когда входящий трафик — HTTP/2, собственное мультиплексирование протокола естественно совпадает с внутренней архитектурой туннеля — HTTP/2-соединение от браузера отображается в один мультиплексированный поток внутри туннеля.

Сжатие заголовков: HPACK и QPACK

HTTP-заголовки повторяются. Каждый запрос отправляет одни и те же User-Agent, Accept, Cookie и Authorization. В HTTP/1.1 они передаются как открытый текст при каждом запросе — часто 500-800 байт повторяющихся данных на запрос.

HTTP/2 вводит сжатие HPACK, которое использует общий словарь и кодирование Хаффмана для сжатия заголовков. После первого запроса последующие заголовки, совпадающие с записями в словаре, передаются как однобайтовый индекс вместо полной строки.

HTTP/3 использует QPACK — адаптацию HPACK, которая работает с неупорядоченной доставкой QUIC. Он достигает аналогичных коэффициентов сжатия, при этом избегая head-of-line блокировки на этапе декомпрессии заголовков.

Для туннелированного трафика сжатие заголовков снижает использование полосы пропускания между браузером и сервером туннеля. Когда вы проводите живое демо через туннель и десятки API-вызовов следуют один за другим, сжатые заголовки уменьшают общий объём данных на 30-50%.

Заголовки HTTP/1.1 (без сжатия):
  GET /api/users HTTP/1.1
  Host: demo.fxtun.dev
  User-Agent: Mozilla/5.0 (X11; Linux x86_64)...
  Accept: application/json
  Authorization: Bearer eyJhbGciOi...
  Cookie: session=abc123; theme=dark
  ~700 байт на запрос

HTTP/2 HPACK (после первого запроса):
  :method = GET         (индекс 2, 1 байт)
  :path = /api/users    (литерал, ~12 байт)
  :authority             (индекс, 1 байт)
  authorization          (индекс, 1 байт — значение то же)
  cookie                 (индекс, 1 байт — значение то же)
  ~50 байт на запрос (сокращение на 93%)

HTTP/3 и QUIC: следующий шаг для туннелирования

HTTP/3 заменяет TCP на QUIC — транспортный протокол, построенный поверх UDP. Это не просто новый формат фреймов: это принципиально другой подход к управлению соединениями, который решает проблемы, недоступные TCP.

Почему TCP — проблема для мультиплексированных протоколов

HTTP/2 решил head-of-line блокировку на уровне HTTP, но TCP создал собственную. Когда теряется один TCP-пакет, TCP-стек операционной системы останавливает все потоки на этом соединении до повторной передачи потерянного пакета. В HTTP/2 это означает, что один потерянный пакет блокирует каждый текущий запрос — изображение, скрипт и API-вызов замирают вместе.

HTTP/2 поверх TCP — блокировка head-of-line:

  Stream 1 (style.css):   [====]  [====]  [====]
  Stream 2 (app.js):      [====]  [====]  [====]
  Stream 3 (logo.png):    [====]  [==X=]  ← пакет потерян
                                    |
                          ВСЕ ПОТОКИ ЗАБЛОКИРОВАНЫ
                          ожидание повторной передачи
                                    |
  Stream 1:               ......... [====]  возобновление
  Stream 2:               ......... [====]  возобновление
  Stream 3:               ......... [====]  возобновление


HTTP/3 поверх QUIC — независимые потоки:

  Stream 1 (style.css):   [====]  [====]  [====]  [====]  ← не затронут
  Stream 2 (app.js):      [====]  [====]  [====]  [====]  ← не затронут
  Stream 3 (logo.png):    [====]  [==X=]  ← потерян, повторная передача
                                    |
                          ТОЛЬКО STREAM 3 ЗАБЛОКИРОВАН
                                    |
  Stream 3:               ......... [====]  возобновление

Для туннелирования это важно, потому что relay добавляет дополнительный сетевой хоп, где может произойти потеря пакетов. На мобильной сети или перегруженном Wi-Fi HTTP/3 через туннель сохраняет работоспособность большинства потоков, даже когда отдельные пакеты теряются.

0-RTT восстановление соединения

QUIC поддерживает 0-RTT восстановление соединения: при повторном подключении к тому же серверу клиент может отправить данные приложения в первом же пакете. В сочетании с тем, что QUIC объединяет транспортный и TLS-хэндшейк, первое соединение занимает 1 RTT, а повторное — 0 RTT.

HTTP/1.1 + TLS 1.2:  TCP-хэндшейк (1 RTT) + TLS-хэндшейк (2 RTT) = 3 RTT
HTTP/2 + TLS 1.3:    TCP-хэндшейк (1 RTT) + TLS-хэндшейк (1 RTT) = 2 RTT
HTTP/3 + QUIC:       QUIC-хэндшейк (1 RTT, включает TLS)          = 1 RTT
HTTP/3 + QUIC 0-RTT: Повторное соединение                         = 0 RTT

Для пользователей туннелей 0-RTT означает, что когда браузер повторно открывает соединение к туннелированному сервису (типично для SPA с периодическими API-вызовами), запрос приходит с нулевыми накладными расходами на round-trip. На канале с задержкой 100 мс это экономия 200-300 мс на переподключении по сравнению с HTTP/1.1. Механика TLS-хэндшейков подробно разобрана в статье «TLS 1.3 в туннелировании».

Миграция соединения

Одна из уникальных возможностей QUIC — миграция соединения. Традиционные TCP-соединения привязаны к четвёрке: IP-адрес источника, порт источника, IP-адрес назначения, порт назначения. Если любой из них меняется (переключение с Wi-Fi на сотовую сеть, например), соединение разрывается и должно быть установлено заново.

QUIC использует идентификаторы соединений вместо IP-адресов для идентификации соединений. Когда мобильное устройство переключает сеть, соединение выживает — клиент просто отправляет пакеты с нового IP, а сервер распознаёт идентификатор соединения.

Для туннелирования через мобильные сети это трансформационное изменение. Разработчик, тестирующий мобильное приложение через туннель, может перемещаться между точками доступа Wi-Fi без разрыва туннеля. IoT-устройство с нестабильным соединением сохраняет туннель без задержек переподключения.

Как fxTunnel обрабатывает HTTP/2

HTTP-туннели fxTunnel поддерживают HTTP/2 из коробки. Протокол согласуется автоматически через ALPN (Application-Layer Protocol Negotiation) во время TLS-хэндшейка между браузером и сервером fxTunnel. Если браузер поддерживает HTTP/2 (все современные браузеры это делают), туннель использует HTTP/2.

На внутреннем участке между клиентом fxTunnel и вашим локальным сервером протокол зависит от возможностей вашего сервера. Если локальный сервер поддерживает HTTP/2 (Node.js с --http2, Go net/http, Nginx), fxTunnel будет использовать HTTP/2 на всём маршруте. Если нет — fxTunnel понизит протокол до HTTP/1.1 для локального соединения, продолжая использовать HTTP/2 на публичной стороне.

Browser ← HTTP/2 → fxTunnel Server ← multiplexed → fxTunnel Client ← HTTP/2 или 1.1 → localhost
          (ALPN)                     (TLS-соед.)                       (зависит от
                                                                        локального сервера)

Проверка HTTP/2 через curl

Вы можете проверить, что ваш туннель работает по HTTP/2, с помощью curl:

# Создаём HTTP-туннель
fxtunnel http 8080
# -> https://abc123.fxtun.dev

# Тест с HTTP/2 (curl 7.47+)
curl -v --http2 https://abc123.fxtun.dev 2>&1 | grep "< HTTP/"
# -> < HTTP/2 200

# Подробная информация о соединении
curl -w "Protocol: %{http_version}\n" -o /dev/null -s https://abc123.fxtun.dev
# -> Protocol: 2

Проверка в DevTools браузера

Откройте URL туннеля в Chrome или Firefox, затем:

1. Откройте DevTools (F12)
2. Перейдите на вкладку Network
3. Щёлкните правой кнопкой по заголовкам столбцов и включите «Protocol»
4. Перезагрузите страницу
5. Столбец Protocol покажет h2 для HTTP/2 или h3 для HTTP/3

Name              Status  Protocol  Size     Time
──────────────────────────────────────────────────
abc123.fxtun.dev  200     h2        1.2 KB   45 ms
style.css         200     h2        8.4 KB   12 ms
app.js            200     h2        24 KB    18 ms
logo.png          200     h2        5.1 KB   9 ms
api/data          200     h2        420 B    23 ms

Все запросы используют одно TCP-соединение — это видно в столбце Connection ID, если его включить.

Практическая производительность: HTTP/1.1 vs HTTP/2 через туннель

Реальная производительность зависит от типа приложения. Вот результаты сравнения HTTP/1.1 и HTTP/2 через туннель fxTunnel на типичном соединении с задержкой 50 мс.

Вывод: HTTP/2 раскрывается, когда есть множество параллельных запросов. Для одиночных последовательных API-вызовов разница минимальна. Для страниц с большим количеством ресурсов или параллельных API-сценариев HTTP/2 через туннель даёт значительное ускорение.

Использование fxTunnel с HTTP/2 на практике

Локальный сервер разработки с HTTP/2

Большинство современных фреймворков поддерживают HTTP/2 нативно. Вот как настроить популярные серверы разработки:

# Node.js (Express не поддерживает HTTP/2 напрямую, используйте spdy или http2)
node --experimental-modules server.mjs

# Go (net/http поддерживает HTTP/2 автоматически с TLS)
go run main.go

# Python (Hypercorn с HTTP/2)
hypercorn app:app --bind 0.0.0.0:8080

# Затем пробрасываем через fxTunnel
fxtunnel http 8080
# -> https://abc123.fxtun.dev (HTTP/2 ready)

Тестирование доставки вебхуков с HTTP/2

Когда провайдер вебхуков отправляет коллбэки в ваш туннель, мультиплексирование HTTP/2 позволяет нескольким доставкам вебхуков приходить одновременно без очереди:

# Запускаем туннель для тестирования вебхуков
fxtunnel http 3000
# -> https://abc123.fxtun.dev

# Настраиваем провайдера вебхуков на URL туннеля
# Stripe, GitHub, Slack — все поддерживают HTTP/2 для доставки вебхуков

# Мониторим входящие запросы инспектором fxTunnel
# Доступен на тарифе Pro (от $5/мес.)

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

CI/CD preview-окружения

При использовании туннелей для CI/CD preview-окружений поддержка HTTP/2 означает, что ваши preview URL ведут себя идентично продакшену. Рецензенты видят те же характеристики производительности, а интеграционные тесты, проходящие через туннель, выигрывают от мультиплексированных соединений.

# В CI-пайплайне
fxtunnel http 3000 --subdomain pr-${PR_NUMBER}
# -> https://pr-42.fxtun.dev (HTTP/2 с пользовательским субдоменом)

Что насчёт HTTP/3 в туннелях?

Поддержка HTTP/3 в инструментах туннелирования пока в стадии развития. Протокол работает поверх QUIC, который использует UDP — другой транспорт, требующий изменений в обработке трафика туннелями. fxTunnel уже поддерживает UDP-туннелирование, что обеспечивает фундамент для будущей поддержки HTTP/3.

Ключевая сложность в том, что трафик HTTP/3 приходит как UDP-датаграммы, а не TCP-потоки. Туннель должен либо:

1. Терминировать QUIC на edge-сервере — сервер fxTunnel принимает HTTP/3 от браузера, конвертирует его в HTTP/2 или HTTP/1.1 для внутреннего участка, и локальный сервер получает традиционное HTTP-соединение.
2. Туннелировать QUIC end-to-end — туннель пробрасывает сырые UDP-датаграммы, содержащие QUIC-пакеты, и локальный сервер обрабатывает HTTP/3 напрямую.

Подход 1 проще и работает с любым локальным сервером. Подход 2 сохраняет преимущества QUIC (0-RTT, миграция соединений) на всём маршруте, но требует поддержки HTTP/3 локальным сервером.

По мере роста распространения HTTP/3 fxTunnel реализует терминацию на edge-сервере первой, позволяя браузерам использовать HTTP/3 для подключения к URL туннелей, сохраняя совместимость с любым локальным сервером. Сквозное QUIC-туннелирование будет реализовано следующим шагом.

Лучшие практики HTTP/2 и HTTP/3 с туннелями

1. Включите HTTP/2 на локальном сервере

Туннель может использовать HTTP/2 на всём маршруте только если ваш локальный сервер его поддерживает. Большинство современных фреймворков это умеют — проверьте документацию вашего фреймворка для настройки HTTP/2.

2. Используйте один домен

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

3. Используйте server push аккуратно

Server push в HTTP/2 позволяет проактивно отправлять ресурсы браузеру до того, как он их запросит. Через туннель это может уменьшить воспринимаемую задержку — но избыточный push расходует полосу пропускания. Используйте push только для критического CSS и JavaScript.

4. Контролируйте согласование протокола

Используйте DevTools браузера или curl для проверки того, что ваш туннель использует HTTP/2. Если вы видите http/1.1 в столбце Protocol, проверьте настройку HTTP/2 на локальном сервере.

5. Тестируйте на реальных сетях

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

FAQ

Поддерживает ли fxTunnel HTTP/2 и HTTP/3?

HTTP/2 работает из коробки – мультиплексирование, сжатие заголовков и server push сохраняются при подключении клиента по этому протоколу. HTTP/3 на базе QUIC запланирован на будущие релизы. Так как TLS терминируется на edge-сервере, на внутреннем участке туннеля может использоваться любой протокол, который поддерживает ваш сервер, включая HTTP/1.1.

HTTP/2 сделает мой туннель быстрее, чем HTTP/1.1?

При одиночных последовательных запросах разница минимальна. HTTP/2 по-настоящему раскрывается на параллельных нагрузках: страницы с множеством ресурсов или API с параллельными запросами загружаются на 20-50% быстрее, потому что мультиплексирование убирает накладные расходы на отдельные соединения через туннель.

В чём разница между HTTP/2 и HTTP/3 для туннелирования?

Оба протокола мультиплексируют потоки, но HTTP/2 по-прежнему работает поверх TCP, поэтому потеря одного пакета тормозит все потоки на соединении. HTTP/3 заменяет TCP на QUIC (UDP), давая каждому потоку независимое восстановление после потерь. Добавьте 0-RTT при повторном подключении и миграцию соединений – и получится протокол, который справляется с нестабильными и мобильными сетями гораздо лучше.

Можно ли принудительно использовать HTTP/2 через туннель fxTunnel?

Принуждать не нужно – ALPN-согласование при TLS-хэндшейке автоматически выбирает HTTP/2, если и клиент, и ваш локальный сервер его поддерживают. Убедиться можно в столбце Protocol в DevTools браузера или запустив curl --http2 к URL туннеля.

Почему HTTP/3 важен для туннелирования через мобильные сети?

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