> В чем различия между HTTP/1.1 и HTTP/2 (Python)

Короткий ответ

HTTP/2 - это бинарный протокол с мультиплексированием, сжатием заголовков (HPACK), приоритизацией потоков и server push. HTTP/1.1 - текстовый, последовательный, с head-of-line blocking на уровне соединения. Основное практическое отличие: в HTTP/2 одно TCP-соединение обслуживает множество параллельных запросов, что радикально снижает задержки. Для backend-разработчика это означает необходимость учитывать поведение пула соединений, таймаутов и балансировки, а также переход на TLS (в большинстве реализаций h2 требует ALPN).

Подробное объяснение

HTTP/1.1 использует один запрос-ответ на соединение (pipelining не решает проблему полностью из-за head-of-line blocking на уровне ответов). Каждый запрос требует либо нового соединения, либо ожидания освобождения текущего. Это приводит к большому количеству параллельных TCP-соединений (обычно 6 на домен в браузерах) и повышенной нагрузке на сервер.

HTTP/2 вводит:

• Бинарный framing layer: все сообщения разбиваются на фреймы (headers, data, settings, etc.), что упрощает парсинг и уменьшает ошибки.
• Мультиплексирование: множество потоков (streams) в одном TCP-соединении. Каждый поток независим, ответы могут приходить в произвольном порядке.
• HPACK: сжатие заголовков с использованием статических и динамических таблиц, что особенно важно для повторяющихся cookie и заголовков.
• Приоритизация потоков: клиент может указать вес и зависимость потоков, сервер может оптимизировать отправку.
• Server push: сервер может отправлять ресурсы до явного запроса (например, CSS/JS вместе с HTML), но на практике это часто отключают из-за сложности кэширования.
• Stream reset: возможность отменить запрос без закрытия соединения (RST_STREAM).

Ключевое отличие в модели: HTTP/1.1 - это "один запрос на соединение", HTTP/2 - "много запросов на соединение". Это меняет поведение на уровне прокси, балансировщиков и пулов соединений в приложениях.

На практике

Для Python-бэкенда (например, FastAPI, Django, aiohttp) переход на HTTP/2 чаще всего прозрачен, если используется ASGI-сервер (uvicorn, hypercorn) с поддержкой h2. Однако есть нюансы:

• Пул соединений: в HTTP/2 одно соединение может обслуживать много запросов, поэтому клиентские библиотеки (httpx, aiohttp) должны корректно управлять мультиплексированием. Если клиент открывает новое соединение на каждый запрос - выигрыша не будет.
• Таймауты: head-of-line blocking на уровне TCP (потеря пакета) в HTTP/2 может затронуть все потоки в соединении. На практике это редкость, но для long-lived connections нужно настраивать keep-alive и таймауты.
• Server push: в большинстве случаев его отключают, так как он усложняет кэширование и может приводить к избыточной передаче данных. Используйте только если точно знаете, что ресурс не в кэше.
• TLS: HTTP/2 в браузерах работает только через TLS (h2). Для внутренних сервисов можно использовать cleartext (h2c), но это редкость.
• Балансировка: если у вас несколько инстансов за балансировщиком, убедитесь, что балансировщик поддерживает HTTP/2 и корректно проксирует фреймы (например, nginx с http2).

Пример кода

PYTHON
# Пример клиента с мультиплексированием через httpx (HTTP/2)
import httpx
import asyncio

async def fetch_all():
    async with httpx.AsyncClient(http2=True) as client:
        # Все запросы идут по одному соединению
        tasks = [
            client.get("https://example.com/api/resource1"),
            client.get("https://example.com/api/resource2"),
            client.get("https://example.com/api/resource3"),
        ]
        responses = await asyncio.gather(*tasks)
        return [r.status_code for r in responses]

asyncio.run(fetch_all())

PYTHON
# Пример ASGI-сервера с HTTP/2 (hypercorn)
# hypercorn main:app --bind 0.0.0.0:443 --certfile cert.pem --keyfile key.pem --http2

Как отвечать на собеседовании

Начните с ключевого отличия: бинарный протокол и мультиплексирование. Затем перечислите остальные фичи (HPACK, приоритизация, server push). Обязательно упомяните head-of-line blocking в HTTP/1.1 и как HTTP/2 его решает на уровне приложения, но не решает на уровне TCP. Покажите понимание практических последствий: меньше соединений, сложнее отладка (бинарный формат), необходимость поддержки в инфраструктуре. Если спросят про HTTP/3 - скажите, что он решает HOL на уровне TCP через QUIC.

Что проверяет интервьюер

• Понимание сетевого стека и модели OSI.
• Знание ограничений HTTP/1.1 (pipelining, HOL, лимит соединений).
• Умение объяснить, как мультиплексирование влияет на производительность.
• Осведомленность о практических аспектах: TLS, ALPN, поддержка в серверах и клиентах.
• Способность связать теорию с реальным backend-кодом (пулы, таймауты, прокси).

Типичные ошибки

• Утверждение, что HTTP/2 полностью устраняет head-of-line blocking - это не так, он остаётся на уровне TCP.
• Путаница между server push и WebSocket/SSE - это разные механизмы.
• Игнорирование того, что HTTP/2 требует TLS в браузерах (h2c - исключение для внутренних сервисов).
• Предположение, что HTTP/2 автоматически ускорит приложение без настройки клиента и сервера - нужно корректное мультиплексирование.
• Забывают про HPACK и его влияние на размер заголовков при большом количестве cookie.