Протоколы HTTP/2 и HTTP/3: производительность, безопасность и преимущества

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

HTTP — протокол, на котором работает весь World Wide Web. HTTP/1.1 много лет был стандартом, но HTTP/2 и HTTP/3 принесли серьёзные улучшения производительности. В этой статье я разберу различия, преимущества и техническую основу этих протоколов.

Почему HTTP нужно было развивать

HTTP/1.1 имел два фундаментальных недостатка:

Head-of-Line Blocking: через одно TCP-соединение запросы идут один за другим. Браузеры обходят это, открывая несколько параллельных соединений, но каждое требует времени на установку и TLS-рукопожатие.
Несжатые заголовки: HTTP-заголовки передаются полностью и без сжатия с каждым запросом и ответом. При большом количестве запросов это создаёт значительный оверхед.

Эти проблемы привели к появлению HTTP/2 и HTTP/3.

HTTP/2: основы

HTTP/2 был опубликован в 2015 году как RFC 7540. Он изменил транспортный слой, но не семантику. Для веб-разработчика запросы и ответы выглядят так же, но передаются эффективнее.

Binary Framing

HTTP/1.1 передаёт данные простым текстом. HTTP/2 использует двоичное фреймирование. Сообщения разбиваются на маленькие пакеты, называемые фреймами. Фреймы объединяются в потоки, а потоки в одно соединение.

Пример:

Когда ты открываешь веб-страницу, HTML, CSS, JavaScript и изображения передаются через отдельные потоки внутри одного TCP-соединения.

Multiplexing

HTTP/2 позволяет мультиплексировать несколько запросов и ответов одновременно через одно TCP-соединение. Это решает проблему Head-of-Line Blocking из HTTP/1.1.

Аналогия: HTTP/1.1 — однополосная дорога. HTTP/2 — многополосная автострада.

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

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

Пример: User-Agent: Mozilla/5.0 при HTTP/1.1 передаётся заново с каждым запросом. При HTTP/2 после первого запроса просто ссылаются на него.

Server Push

HTTP/2 позволяет серверу заранее отправить клиенту ресурсы, которые тот ещё не запрашивал. Когда клиент требует HTML-файл, сервер может отправить CSS и JavaScript вместе с ним. На практике Server Push вызывает споры, так как может привести к избыточной передаче данных.

Приоритизация потоков

HTTP/2 позволяет задавать приоритет отдельным потокам. Важные ресурсы вроде CSS или критичного JavaScript передаются первыми.

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

Быстрые времена загрузки: Мультиплексирование и сжатие заголовков уменьшают задержку.
Меньше TCP-соединений: Обычно хватает одного соединения на хост.
Лучшее использование ресурсов: Сервер и сеть работают эффективнее.
Меньший оверхед: Двоичная передача и сжатые заголовки экономят трафик.

HTTP/3: основы

HTTP/3 был опубликован в 2022 году как RFC 9114. HTTP/2 работает на TCP, а HTTP/3 на QUIC, который построен на UDP.

QUIC вместо TCP

QUIC — транспортный протокол, разработанный Google:

Быстрое установление соединения: QUIC объединяет установку соединения и TLS-рукопожатие в один шаг. Это обычно экономит одну круговую поездку пакета.
0-RTT Resumption: При переподключении клиент может сразу же отправлять данные без нового рукопожатия.
Connection Migration: QUIC использует ID соединения, независимый от IP-адреса и порта. Переход с Wi-Fi на мобильную сеть происходит без разрыва.

UDP в качестве основы

UDP не требует установления соединения и ненадёжен. Нет гарантий на порядок доставки или получение пакетов. QUIC строится на UDP и самостоятельно обеспечивает надёжность, упорядочение и контроль потока.

Интеграция TLS 1.3

HTTP/3 требует TLS 1.3. Шифрование обязательно для HTTP/3. TLS 1.3 быстрее, чем TLS 1.2, благодаря сокращению рукопожатия и удалению устаревших алгоритмов.

Улучшенное Head-of-Line Blocking

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

Преимущества HTTP/3 для производительности

Ещё более быстрое установление соединения: QUIC и TLS 1.3 избавляют от отдельного TCP-рукопожатия.
Лучшая мобильность: Connection Migration обеспечивает безшовный переход между сетями.
Меньше Head-of-Line Blocking: Потоки более независимы друг от друга.
Выше безопасность: TLS 1.3 обязателен.
Лучшая производительность на плохих сетях: QUIC быстрее реагирует на потери пакетов.

Сравнение HTTP/1.1, HTTP/2 и HTTP/3

Свойство	HTTP/1.1	HTTP/2	HTTP/3
Транспортный протокол	TCP	TCP	UDP с QUIC
Передача	Текст	Двоичная	Двоичная
Мультиплексирование	Нет	Да	Да
Сжатие заголовков	Нет	HPACK	QPACK
Server Push	Нет	Да	Опционально
Установление соединения	Медленно	Быстрее	Быстрее всего
TLS	Опционально	Опционально	Обязательно
Head-of-Line Blocking	На уровне приложения	На уровне TCP	На уровне потока
Connection Migration	Нет	Нет	Да

Безопасность HTTP/2 и HTTP/3

Безопасность HTTP/2

HTTP/2 в реальной практике почти всегда используется с TLS. Ключевые аспекты безопасности:

TLS-шифрование: Данные защищены при передаче.
HPACK защита от DoS: Ограничения на размер заголовков и количество потоков затрудняют атаки на отказ в обслуживании.
Лимиты ресурсов: Сервер ограничивает количество одновременных потоков.

Безопасность HTTP/3

TLS 1.3 обязателен: Нет незашифрованного HTTP/3.
Более быстрая безопасность: TLS-рукопожатие эффективнее.
Риски 0-RTT: 0-RTT Resumption теоретически может быть использована для replay-атак. Чувствительные операции не должны выполняться в первом 0-RTT-пакете.

Какую версию TLS должен поддерживать мой сервер?

При настройке веб-сервера или HTTP-сервера часто можно включить несколько версий TLS. Вопрос в том, какие имеют смысл, а какие лучше отключить.

Включать только TLS 1.2 и TLS 1.3

Это рекомендуемая стандартная конфигурация для современных веб-серверов:

TLS 1.3 — текущая версия. Она быстрее и безопаснее TLS 1.2.
TLS 1.2 — всё ещё необходим, потому что некоторые старые клиенты или системы не поддерживают TLS 1.3.

Отключать TLS 1.0 и TLS 1.1

Эти версии больше не следует использовать:

Уязвимости: TLS 1.0 и TLS 1.1 содержат известные слабости вроде BEAST и POODLE.
Устаревшие алгоритмы: Они поддерживают небезопасные наборы шифров вроде RC4 или SHA-1.
Поддержка браузерами: Современные браузеры предупреждают о сайтах, использующих TLS 1.0 или 1.1.

Никогда не включать SSL 2.0 и SSL 3.0

SSL — предшественник TLS. SSL 2.0 и SSL 3.0 считаются небезопасными и должны быть полностью отключены.

Включать все версии TLS неправильно

Может показаться логичным максимизировать совместимость, разрешив все версии. Но это создаёт серьёзный риск безопасности:

Downgrade-атаки: злоумышленник может принудить соединение на более слабую версию TLS, если разрешены старые версии.
Устаревшие алгоритмы: старые версии TLS поддерживают небезопасные методы шифрования.
Compliance: множество стандартов безопасности, таких как PCI DSS, запрещают TLS 1.0 и 1.1.

Практические примеры HTTP

Следующие примеры наглядно показывают, почему НОВОЕ также ЛУЧШЕ.

Пример 1: загрузка веб-страницы

Веб-страница требует 100 ресурсов. При HTTP/1.1 браузер открывает несколько TCP-соединений. При HTTP/2 все ресурсы передаются параллельно. При HTTP/3 дополнительно исчезает TCP handshake.

Пример 2: видеопотоковое вещание

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

Пример 3: мобильные приложения

Мобильные устройства часто переключаются между WiFi и мобильной сетью. HTTP/3 с QUIC может поддерживать соединение даже при смене IP-адреса.

Какую версию использовать и когда?

HTTP/1.1: только для старых или специальных legacy-систем.
HTTP/2: сегодня это повсеместный стандарт для веб-сайтов и API.
HTTP/3: всё более распространяется, особенно в мобильных приложениях, потоковой передаче и облачных сервисах.

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

FAQ: HTTP/2 и HTTP/3

1. В чём главное отличие между HTTP/2 и HTTP/3?

Главное отличие в транспортном протоколе. HTTP/2 использует TCP, HTTP/3 использует QUIC на базе UDP. Благодаря этому HTTP/3 быстрее устанавливает соединение и лучше справляется со сменой сети.

2. Что такое multiplexing в HTTP/2?

Multiplexing позволяет передавать несколько запросов и ответов одновременно через одно TCP-соединение. Это решает проблему Head-of-Line Blocking в HTTP/1.1.

3. Что такое QUIC?

QUIC это разработанный Google сетевой протокол, построенный на UDP. Он объединяет управление транспортом, шифрование и быстрое установление соединения в один протокол.

4. Почему HTTP/3 использует UDP вместо TCP?

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

5. Что такое HPACK?

HPACK это алгоритм сжатия заголовков для HTTP/2. Он сохраняет повторяющиеся поля заголовков в таблице и передаёт их заново только при изменении.

6. Что такое Server Push?

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

7. Что такое Connection Migration?

Connection Migration позволяет поддерживать QUIC-соединение даже при смене IP-адреса или сети. Это особенно важно для мобильных устройств.

8. Что такое 0-RTT Resumption?

0-RTT Resumption позволяет отправлять данные сразу при переподключении, без проведения нового handshake. Это значительно ускоряет повторные соединения.

9. Что такое QPACK?

QPACK это алгоритм сжатия заголовков для HTTP/3. Похож на HPACK в HTTP/2, но адаптирован для QUIC и независимости потоков.

10. HTTP/3 быстрее, чем HTTP/2?

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

11. Что такое Head-of-Line Blocking?

Head-of-Line Blocking означает, что заблокированный запрос замедляет все последующие запросы. При HTTP/1.1 это происходит на уровне приложения, при HTTP/2 на уровне TCP и при HTTP/3 почти только на уровне потока.

12. Какая версия TLS требуется для HTTP/3?

HTTP/3 требует TLS 1.3. Безопасность в HTTP/3 обязательна, а не опциональна, как в HTTP/1.1 или HTTP/2.

13. Что такое replay-атаки при 0-RTT?

При 0-RTT злоумышленник может перехватить зашифрованный пакет и отправить его повторно. Поэтому критичные операции вроде платежей или удаления не должны выполняться в первом 0-RTT пакете.

14. Когда следует использовать HTTP/2?

HTTP/2 это сегодня повсеместный стандарт для веб-сайтов и API. Используй его, если нужна современная конфигурация TLS и широкая совместимость с клиентами.

15. Когда следует использовать HTTP/3?

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

Продолжение пути обучения API

Следующий материал в пути обучения API посвящён принципам проектирования API — основным принципам создания качественных API, от структуры ресурсов до соглашений об именовании.

Täglicher Artikel