QA Interview Hub · База знань · Тести

Мережі

Версії HTTP та інфраструктура

HTTP/1.1, HTTP/2 і HTTP/3: що змінилося

HTTP/1.1 — текстовий протокол поверх TCP. Головні риси:

  • Keep-alive (за замовчуванням): одне TCP-з'єднання обслуговує багато запитів, тож handshake не повторюється. Закрити його можна заголовком Connection: close;
  • Head-of-line blocking (HOL): на з'єднанні запити йдуть по черзі, повільна відповідь блокує наступні. Конвеєризація (pipelining) на практиці не використовується. Обхід: браузер відкриває до ~6 паралельних з'єднань на хост, а розробники колись «шардили» домени й склеювали файли.

HTTP/2 зберігає семантику (методи, коди, заголовки), але змінює транспорт:

  • Бінарні кадри і мультиплексування: багато потоків (запитів) одночасно в одному з'єднанні, відповіді перемежовуються. Шардування доменів і склеювання файлів стають зайвими;
  • HPACK: стиснення заголовків зі спільною таблицею (cookies і User-Agent не передаються повністю щоразу);
  • пріоритети потоків; server push фактично виведено з ужитку (Chrome його прибрав);
  • на практиці — лише поверх TLS (ALPN h2).

Проблема: HTTP/2 усе ще працює на одному TCP-з'єднанні, тому втрата одного пакета зупиняє всі потоки (HOL blocking на рівні TCP). На поганих мережах HTTP/2 може бути гіршим за кілька з'єднань HTTP/1.1.

HTTP/3 працює поверх QUIC (UDP, порт 443 зазвичай). QUIC реалізує надійність, мультиплексування й TLS 1.3 у самому протоколі: втрата пакета зачіпає лише свій потік; з'єднання зі встановленням за 1 RTT (0-RTT при відновленні); міграція з'єднання між мережами (Wi-Fi → мобільна) без розриву; заголовки стискає QPACK. Браузер дізнається про HTTP/3 з Alt-Svc або запису DNS HTTPS; якщо UDP заблоковано, відбувається відкат на HTTP/2.

Для QA: стовпець Protocol у DevTools (http/1.1, h2, h3); curl -v --http2 URL (--http3 лише у збірках curl із підтримкою); семантика й тест-кейси API від версії не залежать, а от продуктивність, поведінка при втратах і заголовки в нижньому регістрі (h2) — залежать.

Проксі, балансувальники, CDN і таймаути

Між браузером і застосунком рідко буває пряме з'єднання. Кожен вузол — потенційне джерело дивних помилок, тому QA варто знати, що вони роблять.

  • Forward-проксі стоїть на боці клієнта (корпоративний вихід в інтернет, Charles, mitmproxy). Reverse-проксі — на боці сервера (nginx, Envoy): термінує TLS, роздає статику, маршрутизує на сервіси, стискає відповіді;
  • Балансувальник: L4 працює з TCP-з'єднаннями (швидкий, не бачить HTTP), L7 розуміє HTTP і маршрутизує за хостом, шляхом чи заголовками. Алгоритми: round-robin, least connections. Health-check виключає несправні інстанси; «липкі» сесії (sticky) прив'язують клієнта до інстансу;
  • CDN кешує відповіді на «краю» ближче до користувача й розвантажує origin. Помилки кешу (старий файл, чужа персоналізована відповідь) вирішують Cache-Control, Vary, версіями в імені файлу, інвалідацією;
  • Заголовки проксі: X-Forwarded-For (реальний IP клієнта, може підробляти сам клієнт), X-Forwarded-Proto, стандартизований Forwarded. Якщо застосунок не довіряє проксі, він бачить IP балансувальника, а rate limit спрацьовує на всіх разом.

Таймаути є на кожному кроці, і найменший виграє:

  • connect timeout — скільки чекати на встановлення TCP;
  • read/response timeout — скільки чекати на дані від сервера;
  • idle timeout на балансувальнику (часто 60 секунд) — з'єднання без трафіку закривається. Саме він «вбиває» довгі запити без відповіді та WebSocket без ping;
  • таймаут клієнта (fetch сам його не має, потрібен AbortSignal.timeout(ms)), таймаут тесту й таймаут CI-кроку.

Симптом «запит рівно через 60 секунд повертає 504» — майже завжди збіг із idle/proxy timeout, а не випадкова повільність. Тест із таймаутом 30 с впаде раніше, ніж проксі віддасть 504, і діагноз виглядатиме інакше.