Комітет IETF (Internet Engineering Task Force), що займається розвитком протоколів та архітектури інтернету, завершив формування RFC для протоколу HTTP/3.0 та опублікував пов'язані з ним специфікації під ідентифікаторами RFC 9114 (протокол) та RFC 9204 (технологія стиснення заголовків QPACK) . Специфікація HTTP/3 набула статусу «Запропонованого стандарту», після чого почнеться робота з надання RFC статусу чорнового стандарту (Draft Standard), що фактично означає повну стабілізацію протоколу та облік усіх висловлених зауважень. Одночасно опубліковані оновлені варіанти специфікацій для протоколів HTTP/3.0 (RFC 1.1) та HTTP/9112 (RFC 2.0), а також документи, що визначають семантику HTTP-запитів (RFC 9113) та HTTP-заголовки керування кешуванням9110 (RFC).
Протокол HTTP/3 визначає використання протоколу QUIC (Quick UDP Internet Connections) як транспорт для HTTP/2. QUIC є надбудовою над протоколом UDP, що підтримує мультиплексування декількох з'єднань і забезпечує методи шифрування, еквівалентні TLS/SSL. Протокол був створений у 2013 році компанією Google як альтернатива зв'язці TCP+TLS для Web, вирішальної проблеми з великим часом встановлення та узгодження з'єднань у TCP та усуває затримки при втраті пакетів у процесі передачі даних.
В даний час підтримка QUIC і HTTP/3.0 вже реалізована у всіх популярних web-браузерах (у Chrome, Firefox і Edge підтримка HTTP/3 включена за замовчуванням, а Safari вимагає включення налаштування «Advanced > Experimental Features > HTTP/3»). На серверній стороні реалізації HTTP/3 доступні для nginx (в окремій гілці та у формі окремого модуля), Caddy, IIS та LiteSpeed. Підтримка HTTP/3 також забезпечує мережу доставки контенту Cloudflare.
Основні особливості QUIC:
- Висока безпека, аналогічна TLS (насправді QUIC надає можливість використання TLS поверх UDP);
- Контроль за цілісністю потоку, що запобігає втраті пакетів;
- Можливість миттєво встановити з'єднання (0-RTT, приблизно в 75% випадків дані можна передавати відразу після відправки пакета установки з'єднання) та забезпечити мінімальні затримки між відправкою запиту та отриманням відповіді (RTT, Round Trip Time);
- Використання при повторній передачі пакета іншого номера послідовності, що дозволяє уникнути двозначності щодо отриманих пакетів і позбутися таймаутів;
- Втрата пакета впливає на доставку тільки пов'язаного з ним потоку і не зупиняє доставку даних паралельно передаються через поточне з'єднання потоках;
- Засоби корекції помилок, які мінімізують затримки через повторну передачу втрачених пакетів. Використання спеціальних кодів корекції помилок на рівні пакета для скорочення ситуацій, що вимагають повторної передачі даних втраченого пакета.
- Кордони криптографічних блоків вирівняні з межами пакетів QUIC, що зменшує вплив втрат пакетів на декодування вмісту наступних пакетів;
- Відсутність проблем із блокуванням черги TCP;
- Підтримка ідентифікатора з'єднання, що дозволяє скоротити час встановлення повторного з'єднання для мобільних клієнтів;
- Можливість підключення розширених механізмів контролю навантаження з'єднання;
- Використання техніки прогнозування пропускної спроможності в кожному напрямку для забезпечення оптимальної інтенсивності відправлення пакетів, запобігаючи скоченню в стан навантаження, при якому спостерігається втрата пакетів;
- Помітний приріст продуктивності та пропускної спроможності в порівнянні з TCP. Для відеосервісів, таких як YouTube, застосування QUIC показало скорочення операцій повторної буферизації під час перегляду відео на 30%.
Зі змін у специфікації HTTP/1.1 можна відзначити заборону відокремлене використання символу повернення каретки (CR) поза тілом із вмістом, тобто. в елементах протоколу символ CR може застосовуватись лише разом із символом перекладу рядка (CRLF). Алгоритм компонування chunked-запитів доопрацьований для спрощення поділу прикріплених полів та секції із заголовками. Додано рекомендації щодо обробки неоднозначного вмісту для блокування атак класу «HTTP Request Smuggling», що дозволяють вклинюватися у вміст запитів інших користувачів у потоці між фронтендом та бекендом.
В оновленні специфікації HTTP/2.0 явно визначено підтримку TLS 1.3. Переведено в категорію застарілих схему визначення пріоритетів і пов'язані з нею поля в заголовках. Оголошено застарілим механізм поновлення з'єднання з HTTP/1.1, що не набув поширення. Скорочено вимоги до перевірки імен полів та значень. Запропоновано для використання деякі раніше зарезервовані типи кадрів та параметри. Більш точно визначені заборонені поля заголовків, які стосуються з'єднання.
Джерело: opennet.ru