В чём разница между HTTP 1.0 и HTTP 2.0?

Разница между HTTP/1.0 и HTTP/2.0: эволюция протокола

Разница между HTTP/1.0 (1996) и HTTP/2.0 (2015) — это огромный технологический скачок, направленный на преодоление фундаментальных ограничений старого протокола и соответствие требованиям современного веба. Если HTTP/1.0 можно сравнить с узкой грунтовой дорогой, то HTTP/2 — это многополосная скоростная магистраль.

Ключевые отличия

1. Модель передачи данных: от последовательной к мультиплексированной

• HTTP/1.0: Каждое TCP-соединение обрабатывает только один запрос за раз. Для загрузки нескольких ресурсов (CSS, JS, изображения) браузер вынужден открывать множество соединений (обычно 6-8 на домен), что создает большую нагрузку.
• HTTP/2: Вводит концепцию мультиплексирования (multiplexing). В рамках одного TCP-соединения можно параллельно передавать множество запросов и ответов, перемешивая их фрагменты. Это устраняет проблему блокировки начала очереди (Head-of-Line blocking) на уровне протокола.

<!-- HTTP/1.1 (наследник 1.0) - Запросы линейны, даже если их 6 в параллельных соединениях -->
Запрос CSS -> Ожидание -> Ответ CSS -> Запрос JS -> Ожидание -> Ответ JS -> ...

<!-- HTTP/2 - Все запросы и ответы перемешаны в одном потоке -->
Поток: [Ч1 CSS][Ч2 JS][О1 CSS][Ч3 IMG][О2 JS][О3 IMG]...

2. Сжатие заголовков

• HTTP/1.0: Заголовки передаются в виде простого, часто повторяющегося текста. Для каждого запроса отправляется полный набор заголовков (User-Agent, Cookie, Accept-*), что приводит к значительным издержкам.
• HTTP/2: Использует алгоритм HPACK для сжатия заголовков. Он кодирует заголовки в бинарном формате и поддерживает динамическую таблицу на стороне клиента и сервера, где часто используемые поля передаются ссылкой на индекс в таблице. Это резко сокращает объем служебных данных.

3. Бинарный протокол против текстового

• HTTP/1.0: Текстовый (ASCII) протокол. Читаем для человека, но сложен для парсинга машиной, подвержен ошибкам и менее эффективен.
• HTTP/2: Бинарный протокол. Работает с фреймами (кадры) — минимальными единицами обмена. Это делает парсинг быстрее, компактнее и надежнее. Основные типы фреймов: HEADERS, DATA, SETTINGS, PUSH_PROMISE.

// Упрощенная аналогия: HTTP/2 фрейм похож на структуру в Go
type FrameHeader struct {
    Length    uint24 // Длина полезной нагрузки
    Type      uint8  // Тип фрейма (например, 0x1 для HEADERS)
    Flags     uint8  // Флаги
    StreamID  uint31 // Идентификатор потока
    // Payload следует за заголовком
}

4. Server Push

• HTTP/1.0: Сервер пассивно ждет запросов. Если HTML-страница требует для отображения стили style.css, браузер должен полностью получить HTML, распарсить его, обнаружить ссылку на CSS и только затем отправить новый запрос за ним.
• HTTP/2: Server Push позволяет серверу proactively отправить клиенту ресурсы, которые, как он знает, понадобятся (например, тот же style.css), еще до того, как браузер о них запросит. Это экономит целый цикл запроса-ответа.

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

• HTTP/2: Позволяет клиенту назначать приоритеты каждому запросу (потоку). Сервер может использовать эту информацию для оптимизации распределения ресурсов (например, сначала отправить критически важный CSS, а потом фоновые изображения). В HTTP/1.0 подобное было возможно лишь через неочевидные хаки.

Сравнительная таблица

Практические последствия для разработчика

• Производительность: HTTP/2 радикально уменьшает задержки (latency) для современных сайтов с десятками ресурсов. Отпадает необходимость в конкатенации файлов, спрайтах изображений и доменном шардинге — это были костыли для HTTP/1.
• Сложность отладки: Текстовый поток HTTP/1.0 можно было читать в telnet или сыром сокете. Для отладки HTTP/2 нужны специальные инструменты (например, Wireshark с поддержкой расшифровки TLS или DevTools браузера), которые преобразуют бинарные фреймы в удобочитаемый вид.
• Backward compatibility: HTTP/2 сохраняет семантику HTTP/1.1 (методы, коды статусов, заголовки), поэтому API и приложения не требуют изменений. Протоколы различаются на транспортном уровне. Согласование версии происходит через механизм ALPN (Application-Layer Protocol Negotiation) во время TLS-рукопожатия или через специальный заголовок Upgrade для незашифрованных соединений.

Итог: Переход на HTTP/2 — одна из самых эффективных оптимизаций производительности веб-приложения без изменения его кода. Он решает фундаментальные проблемы своего предшественника, делая сетевой обмен быстрее, эффективнее и надежнее. Для Go-разработчика понимание этих отличий критически важно при настройке веб-серверов (например, стандартного net/http или nginx в качестве reverse proxy) и диагностике проблем с производительностью сети.