HTTP/2 і HTTP/3: еволюція протоколу

Чим HTTP/2 відрізняється від HTTP/1.1?

Найточніша рамка для відповіді така: змінилося подання, а не сенс. Той самий набір методів, статус-кодів і заголовків їде по зʼєднанню інакше — і саме в цьому «інакше» весь виграш. MDN зводить різницю до трьох пунктів: формат став бінарним замість текстового, обмін став мультиплексованим, а поля заголовків почали стискатися. Бінарність означає, що запит більше не почитаєш і не складеш руками — потрібен інструмент, який уміє розібрати кадри. Мультиплексування означає, що кілька обмінів живуть в одному зʼєднанні паралельно, а не по черзі. Стиснення бʼє по давній ваді HTTP/1.1 — повторюваних багатослівних заголовках, які їхали в кожному запиті. Слабка відповідь на це питання починається зі слова «швидший»: інтервʼюер саме її й чекає, щоб уточнити, за рахунок чого.

Чи доведеться переписувати автотести після переїзду на HTTP/2 або HTTP/3?

Ні, і це основний практичний висновок теми. Семантику протоколу після ревізії специфікацій винесли в окремий документ, спільний для всіх версій, — версійні лише документи про подання. Тобто асерти на статус-код, тіло, кукі й заголовки лишаються чинними без жодної правки. Якщо тест таки зламався одночасно з переїздом, «винен HTTP/2» — не діагноз, а гіпотеза, і її треба звузити до чогось конкретного: розміру заголовків, стелі паралельних потоків, поведінки проміжного вузла. Окремо варто памʼятати організаційний бік: оновлення протоколу зазвичай не є релізом застосунку, тож команду про нього можуть просто не попередити. Саме тому версію протоколу фіксують в описі середовища поруч із версією браузера, а цифри поширеності подають обережно — вони існують як частка сайтів на конкретну дату, а не як частка трафіку.

Чому браузер відкриває кілька зʼєднань до одного домену і звідки взялося число шість?

Зʼєднання HTTP/1.x пропускає запити строго послідовно: наступний стартує після того, як приїхала відповідь на попередній. Саме зʼєднання при цьому лишається живим і перевикористовується, економлячи рукостискання, але черга в ньому одна. Єдиний спосіб отримати паралельність — підняти кілька зʼєднань до того самого домену: колись їх було два-три, зараз поширений дефолт — шість. Ключова обережність у формулюванні: шістку задають самі браузери, а не документ, — жодна специфікація цього числа не називає. І задирати його безкарно не вийде — на боці сервера велика кількість одночасних зʼєднань може виглядати як атака й зачепити захист від відмови в обслуговуванні.

Що таке домен-шардінг і чому його прибирають?

Це трюк епохи HTTP/1.1: статику розкладають по піддоменах на кшталт www1, www2, www3, які насправді ведуть на той самий сервер, — і браузер відкриває свою пачку зʼєднань до кожного з них замість однієї на всіх. У прикладі MDN так виходить 18 паралельних зʼєднань замість шести. Сьогодні техніку позначено застарілою, і на HTTP/2 вона не просто безкорисна, а шкідлива для продуктивності: паралельність там дають потоки в одному зʼєднанні, а розсипані піддомени цю модель ламають. Більшість реалізацій ще й «розшивають» шардінг назад, обʼєднуючи зʼєднання (connection coalescing), тож ефект від піддоменів може виявитися нульовим. Для тестувальника звідси конкретна дія: піддомени «для швидкості» у старому проєкті — кандидат на видалення, а не на перевірку, і довести, що вони ведуть в одне місце, найлегше колонкою Remote address.

Скільки зʼєднань на «хост+порт» дозволяє HTTP/2?

Стандарт формулює це як наполегливу пораду: піднімати більше одного зʼєднання до тієї самої пари «хост+порт» клієнтові не варто. Модальність тут принципова — за нею стоїть SHOULD NOT, тобто рекомендація з винятками, а не заборона. Винятки названо прямо: заміна наявного зʼєднання, різні значення SNI, різні клієнтські сертифікати. Задум при цьому однозначний — паралельність купують потоками, а не новими зʼєднаннями. На співбесіді на цьому місці перевіряють акуратність: людина, яка перетворює SHOULD NOT на «протокол забороняє», зазвичай так само вільно поводиться і з рештою вимог.

Що таке HOL-блокування (head-of-line blocking)?

Це коли незавершений елемент на початку черги стопорить усе, що стоїть за ним, — включно з тим, що давно готове їхати. У вебі поняття живе одразу на двох рівнях, і саме їх плутають найчастіше. Прикладний рівень — це черга запитів усередині одного HTTP-зʼєднання: поки не приїхала відповідь на перший, решта чекає. Транспортний рівень — це вже властивість TCP: втрачений або переставлений пакет зупиняє доставку всього, що йде після нього. Кожна нова версія HTTP закриває рівно один із цих рівнів, і відповідь «HTTP/2 усе полагодив» ловить кандидата саме тут.

«HTTP/2 усунув HOL-блокування» — це правда?

Наполовину, і це наполовину треба назвати вголос. На прикладному рівні — так: потоки в HTTP/2 майже незалежні, заблокований запит не спиняє сусідів, черги запитів більше немає. Але про рівень TCP специфікація HTTP/2 говорить прямо — цього блокування протокол не усуває. Механізм такий: механізми відновлення втрат у TCP нічого не знають про потоки HTTP/2, для них зʼєднання — один потік байтів, тож втрачений пакет спиняє всі активні обміни, включно з тими, чиїх даних у ньому взагалі не було. Чи побачите ви це, залежить від каналу: там, де втрачати нічого, ефекту практично немає, а на мобільній мережі з втратами він виходить на перший план. Другий рівень закриває вже HTTP/3: упорядкованість QUIC обіцяє тільки в межах окремого потоку, а між потоками не обіцяє нічого, — тож втрата бʼє по одному потоку, а не по всіх одразу.

Чи лишилося щось від HOL-блокування в HTTP/3?

Так, одне джерело — саме стиснення заголовків. Щоб розтиснути блок полів, приймальна сторона має мати відповідний стан таблиці, а він приїжджає окремими потоками; поки потрібного запису немає, розбір чекає. Тому QPACK свідомо дає кодувальнику важіль: можна тиснути сильніше й ризикувати блокуванням або тиснути обережніше й не залежати від ще не доставлених оновлень таблиці. Практично це означає, що фраза «у HTTP/3 HOL-блокування немає взагалі» — неточна, і сильний кандидат сам зробить цю поправку.

Чи може HTTP/2 виявитися повільнішим за HTTP/1.1?

Може, і специфікація це визнає. Логіка така: коли всі обміни зведено в одне зʼєднання, зникає той грубий паралелізм, який раніше давали шість окремих каналів TCP. Далі все залежить від того, наскільки розумно сервер вирішує, чиї кадри відправляти першими. Погана схема пріоритезації здатна поставити критичний ресурс за хвостом другорядних, і сторінка відмальовується помітно пізніше, ніж відмальовувалася б на HTTP/1.1. Історія тут повчальна й на рівні стандарту: схему сигналізації пріоритетів із першої редакції HTTP/2 визнали невдалою і в чинній редакції оголосили застарілою.

Що таке кадр і потік у HTTP/2 і як з них складається мультиплексування?

Кадр — найменша одиниця обміну в межах зʼєднання: заголовок плюс послідовність октетів змінної довжини, структура якої залежить від типу кадру. Типів кадрів кілька, і вони діляться за роллю: корисне навантаження запиту й відповіді везуть HEADERS та DATA, а службу — SETTINGS, WINDOW_UPDATE, PUSH_PROMISE. Потік — незалежна двонаправлена послідовність кадрів усередині одного зʼєднання; кожна пара «запит-відповідь» живе у власному потоці, а цілочисельний ідентифікатор потоку призначає та сторона, яка його ініціює. Мультиплексування — це і є перемежовування кадрів різних потоків в одному зʼєднанні, і робити його може будь-яка зі сторін. Звідси й головна відмінність від HTTP/1.1: паралельність перестала бути кількістю каналів і стала кількістю потоків.

Чим обмежена кількість одночасних потоків і де це дивитися?

Параметром SETTINGS_MAX_CONCURRENT_STREAMS, і в ньому є тонкість, на якій люблять ловити: кожна сторона оголошує цей ліміт для свого партнера, а не для себе. Тобто скільки потоків одночасно дозволено відкривати клієнту — вирішує сервер, і навпаки. Практичний наслідок прямий: коли навантажувальний або великий e2e-сценарій упирається в стелю паралельності, дивляться на значення, оголошене сервером, а не будують здогади про браузер. Поруч працюють ще два механізми, які теж стримують потік даних: контроль потоку (не слати більше, ніж отримувач здатен перетравити) і пріоритезація.

Чому роздуті кукі й великі токени на HTTP/2 коштують дорожче, ніж здається?

Через правило суцільного блоку полів. Стиснені поля везе кадр HEADERS (або PUSH_PROMISE), а хвіст, що не вмістився, доїжджає кадрами CONTINUATION — і розривати цю послідовність нічим стороннім не дозволено. Перемежовування, на якому тримається весь HTTP/2, тут вимикається: доки величезний блок не доїде цілком, зʼєднання зайняте виключно ним, а решта потоків чекає. Тобто кілограмова кукі чи JWT на пів екрана бʼє не тільки по обсягу трафіку, а й по паралельності, заради якої HTTP/2 і вмикали. Для QA це готовий тест-кейс: додали новий заголовок автентифікації — подивіться, наскільки виріс блок і чи не почала сторінка гірше розкладатися.

Що таке сервер-пуш у HTTP/2 і чому він рідко окупається?

Це необовʼязковий режим, у якому сервер сам вирішує, що клієнту зараз знадобиться, синтезує за нього запит і надсилає кадр PUSH_PROMISE, а слідом дані. Причину невдачі фіксує сама специфікація: щоб пуш дав виграш, серверу треба точно передбачити наступні запити, врахувавши і кешування, і узгодження подання, і те, як людина поводитиметься далі, — а промах прогнозу означає марно передані дані й може обернутися просідом продуктивності. Найслабша ланка тут — кешування: сервер просто не знає, що вже лежить у браузера, тож регулярно пушить те, що клієнт і так має. Клієнт може відмовитися від режиму, виставивши SETTINGS_ENABLE_PUSH = 0, і ця домовленість діє окремо на кожному «стрибку» між сусідніми вузлами, а не наскрізно. У HTTP/3 режим нікуди не зник, але останнє слово за клієнтом стало ще вагомішим: доки від нього не приїде кадр MAX_PUSH_ID, серверу пушити не дозволено взагалі.

Чи вимагає HTTP/2 шифрування?

Стандарт — ні, браузери — так, і в цьому вся плутанина. Технічно незашифроване зʼєднання HTTP/2 можливе, просто зі зайвою складністю: HTTP/1.x і HTTP/2 ділять порт 80, тож версію доводиться узгоджувати механізмом Upgrade з токеном h2c і відповіддю 101 Switching Protocols. А от популярні браузери взялися підтримувати HTTP/2 лише поверх TLS — зокрема Firefox і Chrome заявили це прямо. Тому в браузері працює формула «TLS з ALPN — де-факто вимога», причому з умовою й на боці сервера: він має вміти узгоджувати протокол через ALPN, інакше браузер підніме HTTP/1.1. Прямий наслідок для тестувальника: стенд, відкритий по http://, лишиться на HTTP/1.1 за будь-яких налаштувань сервера, і тікет про це заводити не треба.

Як клієнт і сервер узагалі домовляються про версію?

Спосіб залежить від версії. Для HTTP/2 їх три: узгодження через ALPN усередині рукостискання TLS, апгрейд відкритого зʼєднання без попереднього знання і старт відкритого HTTP/2 із попереднім знанням. Рекомендований — перший, бо протокол вибирається всередині вже потрібного рукостискання й додаткових RTT не коштує. З HTTP/3 логіка інша: клієнт не може просто «спробувати QUIC», він спершу має дізнатися, що така точка існує. Походження оголошує її заголовком відповіді Alt-Svc з токеном h3 (у HTTP/2 те саме може приїхати кадром ALTSVC), і лише отримавши цей запис, клієнт може підняти QUIC-зʼєднання, вибравши h3 уже як ALPN-токен. Коли UDP у мережі зарізаний, підняти QUIC не вийде — і тоді клієнтові радять повернутися до версій HTTP, що працюють поверх TCP: сайт відкриється, просто по HTTP/2.

У Network видно, що перший запит пішов по h2, хоча сервер підтримує HTTP/3. Це баг?

Ні, це нормальний порядок подій. Браузеру нізвідки знати про точку HTTP/3 до першої відповіді — саме в ній приїжджає Alt-Svc, і лише наступні запити він пробує по QUIC. Тому перше завантаження часто повністю проходить поверх TCP, і це не привід заводити тікет. Із того самого механізму випливає ще два спостереження. Версія — властивість конкретного запиту, а не сайту: в межах однієї сторінки цілком законно уживаються http/1.1, h2 і h3 — усе залежить від того, з ким і про що вдалося домовитися. І версію здатен «зняти» проміжний вузол: домовленість про зʼєднання існує лише між двома сусідами в ланцюгу й наскрізною не буває, тому браузер і origin цілком можуть бачити різні картини.

Що QUIC дає понад стек TCP + TLS?

Три речі, які варто називати списком. Перше — потоки з власним контролем потоку: мультиплексування переїхало в транспорт, тому HTTP поверх QUIC нічого не мультиплексує сам, а втрата в одному потоці не гальмує інші. Друге — низьколатентне встановлення зʼєднання: криптографічне й транспортне рукостискання злиті в одне, заразом там узгоджуються транспортні параметри. Третє — міграція між мережевими шляхами. До цього обовʼязково додають шифрування: QUIC першої версії використовує TLS 1.3 або новішу як протокол рукостискання, тож незашифрованого HTTP/3 не буває взагалі. Дві дрібниці, які добре показують розуміння: схема http:// привʼязана до вміння приймати TCP-зʼєднання, тому прямого доступу по HTTP/3 до такого ресурсу не існує; а віддавати HTTP/3 сервер може на будь-якому UDP-порту, тож «а чому не 443» дефектом не є.

Що таке 0-RTT і чому це не просто «швидше»?

Це режим повторного зʼєднання, у якому клієнт відправляє прикладні дані ще до того, як почув відповідь сервера, — звідси й економія одного RTT. Ціну специфікація називає прямо: захисту від replay-атак там немає, тобто перехоплений ранній пакет можна відтворити знову. Наслідок практичний і жорсткий: не ідемпотентні операції — оплату, створення замовлення, списання — у ранній фазі зʼєднання відправляти не можна. Для тест-плану це окремий рядок, і перевіряють у ньому не таймінги, а перелік операцій, які застосунок узагалі погоджується виконати в 0-RTT. Формулювання «0-RTT — це обмін гарантій на швидкість» на співбесіді звучить набагато сильніше, ніж «це прискорення повторних зʼєднань».

Що таке міграція зʼєднання і як її перевіряти?

QUIC упізнає зʼєднання не за парою «IP + порт», а за ідентифікатором зʼєднання (connection ID), тому воно переживає зміну мережевого шляху чи переприсвоєння адрес у NAT — там, де TCP-зʼєднання просто розірвалося б. Звідси законний тест-кейс: активна сесія має пережити перехід із Wi-Fi у мобільну мережу, і перевіряти це треба на живій сесії, а не на холодному старті. Обмеження знати обовʼязково: право почати міграцію має тільки клієнт, і не раніше, ніж рукостискання підтвердилося, а нову адресу партнера доводиться підтверджувати валідацією шляху. Тому перемикання мережі до підтвердження рукостискання міграцією не є взагалі — специфікація її там забороняє, і «сесія відвалилася» в такому сценарії не доводить нічого. Другий бік того самого сюжету — конфігурація: специфікація радить дозволяти щонайменше сто одночасних потоків-запитів, тож дефіцит паралельності на HTTP/3-стенді шукають у налаштуваннях, а не в протоколі.

Як перевірити те, чим HTTP/3 справді відрізняється від HTTP/2?

Перше, що чекають почути, — чого робити не треба: звичайний smoke на офісному Wi-Fi перевіркою HTTP/3 не є. Уся різниця між версіями зосереджена в двох умовах — втрати пакетів і зміна мережі, — а на ідеальному дротовому каналі втрачати нічого, тож обидві версії поводяться однаково. Осмислений план виглядає так: під емуляцією втрат порівняти, як поводиться сторінка на h2 і на h3 (на HTTP/2 завмирає все одразу, на HTTP/3 — лише постраждалий потік), і окремо перевірити виживання активної сесії при перемиканні мережі. Перед будь-яким із цих прогонів версію треба не припускати, а побачити: у панелі Network є колонка Protocol, яка показує h2 чи h3 порядково, і типово вона прихована — вмикають її правою кнопкою по шапці таблиці. Поруч корисні ще дві колонки: Connection ID, де для одного домену на HTTP/1.1 буде розсип значень, а на HTTP/2 — одне-єдине, і Remote address, якою найлегше довести, що піддомени ведуть в одне місце.

Три кейси про одне й те саме: версія протоколу мовчазно змінює правила, за якими ви читаєте симптом. Спершу розбір гальмування, у якому діагноз залежить від версії; далі чотири тікети, що закриваються як «не дефект»; наприкінці — що з теми взагалі автоматизується, а що лишається ручним.

Кейс 1. «Один запит гальмує всю сторінку»: діагноз залежить від версії

Скарга типова: сторінка на мить завмирає повністю — не вантажиться жоден блок, потім усе оживає разом. У тікеті це виглядає як «підвисає бекенд», але перш ніж іти в логи застосунку, потрібні дві речі: увімкнена колонка Protocol у панелі Network і розуміння, що на різних версіях ця сама картина має різні причини.

Три висновки, які економлять час.

• Однакова картина, різні винні. «Все завмирає одночасно» на HTTP/1.1 — це черга запитів, на HTTP/2 — втрата пакета в TCP, а на HTTP/3 обидва пояснення просто не працюють. Тому версію дізнаються до того, як формулюють гіпотезу, а не після.
• Мережеві умови — частина відтворення. Різниця між HTTP/2 і HTTP/3 живе там, де є втрати пакетів або зміна мережі. У кабінеті з дротовим інтернетом обидві версії поводяться однаково, тож «не відтворюється» тут нічого не доводить.
• Не всі гальмування транспортні. Якщо на h3 завмер один запит, а сусідні пройшли — це найкорисніший з усіх сигналів: транспорт відпадає, і залишається сам ендпоінт.

Кейс 2. Чотири тікети, які закриваються як «не дефект»

Кожен із них хоч раз доїжджав до розробників. Спільна риса: симптом реальний, а очікування — хибне.

Ще два випадки з тієї самої серії, які варто ловити на етапі планування, а не після заведення тікета.

• «Увімкнули HTTP/2, а швидше не стало (або стало гірше)». Це можливий результат, а не обовʼязково поломка: коли всі обміни зведені в одне зʼєднання, грубого паралелізму шести каналів більше немає, і за поганої пріоритезації сторінка збирається довше, ніж на HTTP/1.1. Спершу дивляться порядок завершення критичних ресурсів, і лише потім заводять регресію продуктивності.
• «Мережа перемкнулася — сесія відвалилася, міграція QUIC не працює». Перевірте момент перемикання: ініціювати міграцію може тільки клієнт і тільки після підтвердження рукостискання, тож обрив до цієї точки міграцією не є взагалі. Коректний сценарій — активна сесія, яка вже обмінюється даними, і перехід із Wi-Fi у мобільну мережу посеред неї.

Кейс 3. Що з теми автоматизується, а що ні

Спокуса написати expect(protocol).toBe('h3') велика, і саме її варто погасити першою: керування зʼєднанням діє між сусідніми вузлами, тож проміжний проксі здатен «зняти» версію, і тест почне падати від зміни в інфраструктурі, якої ніхто не анонсував. Автоматизувати варто те, що є контрактом застосунку, а не властивістю каналу.

Найстабільніший асерт у темі — факт оголошення точки HTTP/3. Це звичайний заголовок відповіді, і перевіряється він без браузера.

import { test, expect } from '@playwright/test';

test('походження оголошує точку HTTP/3', async ({ request }) => {
  const res = await request.get('/');
  const altSvc = res.headers()['alt-svc'] ?? '';

  // без цього заголовка браузеру нізвідки дізнатися, що QUIC-точка існує
  expect(altSvc, 'у відповіді немає Alt-Svc з токеном h3').toContain('h3=');
});

Другий кандидат — розмір блоку заголовків. Він прямо повʼязаний із паралельністю на HTTP/2, і його регресію легко проґавити: заголовок додає одна команда, а платять за нього всі запити.

test('блок заголовків запиту не роздувся після релізу авторизації', async ({ page }) => {
  const sizes: Promise<number>[] = [];

  page.on('request', (req) => {
    // allHeaders(), а не headers(): другий не віддає cookie — саме те, що роздуває блок
    sizes.push(
      req.allHeaders().then((headers) =>
        Object.entries(headers).reduce((sum, [k, v]) => sum + k.length + v.length + 4, 0),
      ),
    );
  });

  await page.goto('/dashboard');

  const worst = Math.max(...(await Promise.all(sizes)));
  // поріг беруть із заміру до релізу, а не зі стелі — цифра тут проєктна
  expect(worst, 'заголовки запиту виросли: на HTTP/2 це бʼє по паралельності').toBeLessThan(8192);
});

І дрібниця, що працює на будь-якій версії: замість фіксованої паузи чекають на конкретну відповідь. Скільки зʼєднань і потоків підняв браузер — на це очікування вже не впливає.

// прив'язуємось до події, а не до секунд: транспорт може змінитися, контракт — ні
await page.waitForResponse((r) => r.url().includes('/api/orders') && r.ok());

Що дивитися і чому:

• Асерт на версію протоколу — ламкий за конструкцією. Версія залежить від сусіднього вузла, а не від застосунку, тож у продуктових сюїтах їй не місце. Якщо версію все ж треба контролювати, робіть це окремою перевіркою інфраструктури з чесною назвою, а не всередині бізнес-сценарію.
• Alt-Svc перевіряють на факт і на токен, а не на порт. Номер UDP-порту — вибір сервера, і він може змінитися без жодного релізу застосунку; прибитий до :443 асерт зафейлиться на рівному місці.
• Ліміт на заголовки — це тест продуктивності, замаскований під тест контракту. Він ловить те, чого не побачить жоден функціональний сценарій: сторінка працює, просто кожен запит тягне на собі зайвий кілобайт. Тільки рахувати треба по allHeaders(): headers() не віддає cookie, тобто мовчки викине з підрахунку найтовщий заголовок.
• Втрати пакетів і зміну мережі лишають ручному прогону. Ці два сценарії й становлять усю практичну різницю між HTTP/2 і HTTP/3, але вони вимагають керування мережевими умовами, а не браузером, — тож у чеклист релізу вони йдуть як ручні кроки з описаними умовами, а не як e2e-тест.
• Перелік операцій, дозволених у 0-RTT, перевіряють головою, а не тестом. Питання не в таймінгах, а в тому, чи може оплата або створення замовлення поїхати в ранній фазі зʼєднання, де захисту від replay-атак немає. Це рядок у тест-плані й предмет розмови з бекендом.

Що версія міняє, а що ні

• Можу пояснити, чому переїзд на HTTP/2 чи HTTP/3 не змушує переписувати асерти (семантика — методи, статус-коди, заголовки — спільна для всіх версій, версійне лише подання) і чому «тест зламався через HTTP/2» — гіпотеза, яку звужують до розміру заголовків, стелі паралельних потоків або поведінки проміжного вузла.
• Знаю три відмінності HTTP/2 від HTTP/1.1 у формулюванні MDN: бінарний формат, мультиплексування, стиснення полів заголовків.

Паралельність на HTTP/1.x

• Можу пояснити, чому одне зʼєднання HTTP/1.x дає одну чергу і чому єдиний вихід — кілька зʼєднань; при цьому «до шести на домен» подаю як практику браузерів, а не як норму RFC.
• Знаю різницю домен-шардінгу тоді й тепер: на HTTP/1.1 множив паралельність, на HTTP/2 шкодить, а реалізації ще й обʼєднують зʼєднання назад (connection coalescing).
• Памʼятаю модальність рекомендації HTTP/2 про одне зʼєднання на «хост+порт»: це SHOULD NOT з винятками (заміна зʼєднання, різні SNI, різні клієнтські сертифікати), а не заборона.

HOL-блокування

• Розводжу два рівні блокування: прикладний (черга запитів у зʼєднанні) і транспортний (втрата пакета в TCP) — і знаю, яка версія закриває який.
• Можу пояснити механіку транспортного рівня: потоки HTTP/2 не видні механізмам відновлення втрат TCP, тому один втрачений пакет спиняє всі активні обміни.
• Знаю, чому HTTP/3 цей рівень закриває (QUIC гарантує порядок лише всередині потоку, а кожна пара «запит-відповідь» займає окремий потік) і який залишок лишається — блокування через саме стиснення, тому QPACK дає кодувальнику вибір.
• Можу назвати умову, за якої HTTP/2 буває повільнішим за HTTP/1.1: погана пріоритезація там, де грубого паралелізму кількох TCP-зʼєднань уже немає.

HTTP/2 зсередини

• Розрізняю кадр (найменша одиниця обміну) і потік (незалежна двонаправлена послідовність кадрів) і можу описати мультиплексування як перемежовування їхніх кадрів в одному зʼєднанні.
• Знаю, що SETTINGS_MAX_CONCURRENT_STREAMS кожна сторона оголошує для партнера, тож стелю клієнта задає сервер — і туди дивляться при впертому e2e чи навантаженні.
• Можу пояснити, чому суцільний блок полів робить роздуті кукі й великі токени дорогими: поки блок їде кадрами HEADERS і CONTINUATION, зʼєднання зайняте лише ним.
• Знаю межі сервер-пушу: прогноз має враховувати кеш клієнта, клієнт вимикає режим через SETTINGS_ENABLE_PUSH = 0, а в HTTP/3 сервер мовчить, доки не приїде кадр MAX_PUSH_ID.

Узгодження версії

• Знаю різницю «стандарт HTTP/2 TLS не вимагає» vs «браузери вимагають»: відкритий шлях існує через Upgrade з токеном h2c і відповідь 101 Switching Protocols, але стенд на http:// лишиться на HTTP/1.1 за будь-якого конфігу, і це не дефект.
• Можу описати виявлення HTTP/3 — Alt-Svc з токеном h3 у відповіді, потім ALPN-токен у QUIC-рукостисканні, а при заблокованому UDP фолбек на версії поверх TCP — і розумію наслідки: перше завантаження часто йде по h2, а в межах однієї сторінки нормально уживаються http/1.1, h2 і h3.

QUIC, HTTP/3 і діагностика

• Можу назвати три властивості QUIC понад TCP+TLS (потоки з власним контролем потоку, злите низьколатентне рукостискання, міграція між мережевими шляхами) і памʼятаю, що незашифрованого HTTP/3 не буває, а прямого доступу по HTTP/3 до http://-ресурсу не існує взагалі.
• Розумію ціну 0-RTT: захисту від повторного відтворення там немає, тож перевіряють не таймінги, а перелік операцій, які застосунок дозволяє в ранній фазі зʼєднання.
• Можу описати міграцію зʼєднання через ідентифікатор зʼєднання і назвати її межі: ініціює лише клієнт, лише після підтвердження рукостискання, з валідацією нового шляху.
• Версію не вгадую, а вмикаю колонку Protocol (типово прихована; поруч читаю Connection ID і Remote address) і памʼятаю, що проміжний вузол здатен «зняти» версію — керування зʼєднанням діє між сусідніми вузлами, а не наскрізно.
• Фіксую версію протоколу в описі середовища (її оновлення не є релізом застосунку) і перевіряю різницю HTTP/2 з HTTP/3 емуляцією втрат та зміною мережі на активній сесії, а не smoke на офісному Wi-Fi.