HTTP и прикладные протоколы Веба

Предыдущая тема закончилась на том, что браузер получил от DNS адрес сервера. Дальше начинается работа протокола передачи гипертекста (англ. Hypertext Transfer Protocol, HTTP) — основного прикладного протокола Интернета. Через HTTP загружаются веб-страницы, работают мобильные приложения и программные интерфейсы облачных сервисов, распространяются обновления программ и видео; по различным оценкам, на HTTP и его зашифрованный вариант HTTPS приходится основная доля трафика Интернета. Из предыдущих тем известны транспортные механизмы, на которые HTTP опирается: надёжный поток байтов TCP с рукопожатием, управлением перегрузкой и блокировкой начала очереди (темы 12–13).

HTTP интересен для изучения тем, что в нём хорошо видны два уровня проектирования протокола. Первый — семантика: что означает запрос GET или код ответа 404, можно ли повторить запрос, можно ли сохранить ответ в кеше. Эта часть за тридцать лет почти не изменилась. Второй — способ передачи сообщений по сети: текстовые сообщения поверх TCP в HTTP/1.1, двоичные кадры с мультиплексированием в HTTP/2, независимые потоки поверх нового транспорта QUIC в HTTP/3. Эта часть менялась трижды, и каждый раз — из-за ограничений производительности, о которых пойдёт речь. Такое разделение закреплено и в стандартах: в 2022 году спецификация HTTP была переиздана комплектом документов, где семантика (RFC 9110) и кеширование (RFC 9111) описаны отдельно от версий протокола (RFC 9112, 9113, 9114) ¹²³.

Изложение построено следующим образом. Сначала рассматриваются модель Веба, идентификаторы ресурсов и устройство сообщения HTTP/1.1, затем — семантика методов, кодов и заголовков, включая способы передачи тела и механизм cookies. Третий раздел посвящён соединениям HTTP/1.1 и их влиянию на производительность, четвёртый — кешированию и промежуточным узлам: прокси, балансировщикам, сетям доставки контента. Пятый раздел описывает HTTP/2, транспорт QUIC и HTTP/3, шестой — прикладные протоколы поверх HTTP и рядом с ним: REST, WebSocket, электронную почту и SSH. Шифрование TLS упоминается там, где без него нельзя обойтись, а подробно рассматривается в теме 17.

Модель Веба и сообщение HTTP/1.1

Клиент, сервер и ресурс

Веб построен по модели «клиент — сервер»: клиент (браузер, мобильное приложение, утилита curl) отправляет запрос, сервер возвращает ответ. Предмет обмена — ресурс (англ. resource): всё, что можно идентифицировать, от HTML-документа до записи в базе данных или результата поиска. Сервер передаёт не сам ресурс, а его представление (англ. representation) — последовательность байтов в некотором формате, например HTML, JSON или PNG, с метаданными о нём: типом содержимого, языком, датой изменения ¹. Один ресурс может иметь несколько представлений, и клиент указывает в запросе предпочтительные (заголовки Accept, Accept-Language, Accept-Encoding); этот механизм называется согласованием содержимого (англ. content negotiation).

HTTP — протокол без сохранения состояния (англ. stateless): каждый запрос самодостаточен, и сервер не обязан помнить предыдущие запросы того же клиента. Это свойство упрощает масштабирование — любой запрос может обработать любой из множества одинаковых серверов, — но требует отдельного механизма там, где состояние всё же нужно, например для входа пользователя в систему; его роль выполняют cookies, рассмотренные ниже.

Между клиентом и сервером-источником (англ. origin server) могут находиться посредники (англ. intermediaries): прокси, шлюзы, кеши, балансировщики нагрузки. Протокол учитывает их явно: часть заголовков адресована только ближайшему узлу, часть — получателю на другом конце цепочки, а правила кеширования определяют, что посредник вправе сохранить и повторно выдать.

Идентификаторы ресурсов: URI и URL

Ресурс идентифицируется унифицированным идентификатором ресурса (англ. Uniform Resource Identifier, URI), синтаксис которого определён в RFC 3986 ⁹. URI, указывающий не только имя, но и способ доступа к ресурсу, исторически называется URL (англ. Uniform Resource Locator); в Вебе практически все URI являются URL. Разберём его составные части на примере:

https://www.nsu.example:8443/catalog/search?q=dns&page=2#results
\___/   \__________________/\_____________/\___________/\______/
схема       авторитет           путь         запрос     фрагмент

Схема (англ. scheme) определяет протокол: http (порт по умолчанию 80) или https (порт 443, HTTP поверх TLS). Авторитет (англ. authority) — имя или адрес сервера и необязательный порт; имя разрешается через DNS (тема 15). Путь (англ. path) и запрос (англ. query) передаются серверу и определяют ресурс. Фрагмент после # серверу не передаётся вовсе: он обрабатывается клиентом, например указывает место на странице. Символы, недопустимые в URI, кодируются процентной записью: пробел — %20, кириллическая буква «д» в UTF-8 — два байта %D0%B4.

Важное следствие: в URI имя сервера и путь разделены, а в запросе HTTP/1.1 они передаются в разных местах. Путь с запросом попадает в строку запроса, а имя сервера — в заголовок Host. Благодаря заголовку Host на одном IP-адресе и порту могут работать тысячи сайтов (англ. virtual hosting): сервер выбирает сайт по значению этого заголовка.

Устройство сообщения HTTP/1.1

Сообщение HTTP/1.1 — текст в кодировке ASCII, передаваемый по соединению TCP ³. Запрос состоит из строки запроса (англ. request line): метода, цели запроса и версии протокола; затем следуют поля заголовка (англ. header fields) вида Имя: значение, по одному в строке; затем пустая строка и необязательное тело (англ. body, content). Строки разделяются парой символов CRLF (байты 0d 0a). Ответ устроен так же, но начинается строкой состояния (англ. status line): версия, трёхзначный код состояния и поясняющая фраза. Ниже — реальный обмен из лабораторной работы, показанный curl -v: строки, начинающиеся с >, отправлены клиентом, с < — получены от сервера, со * — комментарии curl.

curl -v http://10.16.0.1/hello

*   Trying 10.16.0.1:80...
* Connected to 10.16.0.1 (10.16.0.1) port 80 (#0)
> GET /hello HTTP/1.1
> Host: 10.16.0.1
> User-Agent: curl/7.81.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Content-Length: 24
< X-Backend: web1
< Date: Mon, 12 Oct 2026 09:46:00 GMT
< Server: LabProxy/1.0
< Via: 1.1 px
<
* Connection #0 to host 10.16.0.1 left intact
Привет от web1!

Запрос занимает 78 байт: строка GET /hello HTTP/1.1 (19 символов и CRLF — 21 байт), три заголовка и завершающая пустая строка из двух байтов. Конец заголовков сервер определяет по последовательности 0d 0a 0d 0a. Тела у запроса нет. Ответ сообщает длину тела — 24 байта — заголовком Content-Length, и по этому числу клиент узнаёт, где кончается ответ и где в том же соединении начнётся следующий. Строка «Привет от web1!» вместе с переводом строки содержит 16 символов, но 24 байта: 8 кириллических букв занимают в UTF-8 по два байта, а остальные 8 символов (пробелы, латиница, цифра, восклицательный знак и перевод строки) — по одному. Имена полей нечувствительны к регистру, и в HTTP/2 и HTTP/3 они передаются строчными буквами.

Текстовый формат делает HTTP/1.1 удобным для наблюдения и отладки: запрос можно набрать вручную через nc или telnet, что и делается в лабораторной работе. У этого удобства есть цена: текст нужно разбирать посимвольно, заголовки повторяются в каждом запросе, а неоднозначности разбора (лишние пробелы, дублирующиеся заголовки длины) становятся уязвимостями, о чём пойдёт речь в следующем разделе.

Семантика HTTP: методы, коды состояния, заголовки

Методы и их свойства

Метод (англ. method) указывает, что клиент просит сделать с ресурсом. RFC 9110 определяет восемь методов и два важных свойства, которые позволяют посредникам и клиентам принимать решения, не понимая смысла конкретного приложения ¹. Метод безопасен (англ. safe), если по замыслу он только читает и не изменяет состояние сервера. Метод идемпотентен (англ. idempotent), если результат нескольких одинаковых запросов такой же, как одного. Безопасные методы по определению идемпотентны.

Различие имеет практические последствия. Если соединение оборвалось до получения ответа, клиент или прокси может автоматически повторить идемпотентный запрос, но не POST: повтор оформления заказа может создать второй заказ. Именно поэтому браузер спрашивает пользователя перед повторной отправкой формы. Поисковые роботы и функции предварительной загрузки браузера следуют по ссылкам методом GET, исходя из его безопасности; приложение, удаляющее данные по ссылке вида GET /delete?id=5, нарушает семантику и рискует потерять данные из-за робота. Заметим, что PUT идемпотентен, а POST нет: два одинаковых PUT /users/7 оставляют одно и то же состояние, а два POST /users создают двух пользователей.

Коды состояния

Код состояния (англ. status code) — трёхзначное число, первая цифра которого задаёт класс ответа ¹. Клиент, не знающий конкретного кода, обязан обрабатывать его как код x00 того же класса; поэтому новые коды можно добавлять без поломки старых клиентов.

Несколько кодов заслуживают пояснения. Перенаправления 301 и 302 исторически позволяли клиенту сменить метод POST на GET, поэтому позднее введены 307 и 308, которые требуют сохранить метод и тело. Код 304 Not Modified не является ошибкой: это ответ на условный запрос, означающий «ваша копия актуальна», — он рассматривается в разделе о кешировании. Код 401 означает «не аутентифицирован» (не предъявлены или неверны учётные данные), а 403 — «аутентифицирован, но доступ запрещён». Коды 502 и 504 выдаёт не сам сервер-источник, а шлюз или обратный прокси: 502 — бэкенд вернул некорректный ответ или недоступен, 504 — бэкенд не ответил вовремя. Различение этих кодов — первый шаг диагностики: при 502 искать проблему следует за прокси, а не в браузере пользователя. Промежуточный код 103 Early Hints позволяет серверу ещё до готовности основного ответа сообщить браузеру, какие ресурсы стоит начать загружать; его можно увидеть у крупных сайтов, например curl -I https://www.cloudflare.com/ возвращает сначала HTTP/2 103, затем HTTP/2 200.

Длина тела: Content-Length и кодирование chunked

Поскольку соединение TCP — непрерывный поток байтов (тема 12), получатель должен знать, где кончается тело одного сообщения. HTTP/1.1 предусматривает три способа ³. Первый — заголовок Content-Length с длиной тела в байтах, как в примере выше. Второй — закрытие соединения сервером после тела; так работал HTTP/1.0, и этот способ не позволяет переиспользовать соединение и не отличает полный ответ от оборванного. Третий — кодирование передачи частями (англ. chunked transfer coding), объявляемое заголовком Transfer-Encoding: chunked. Оно нужно, когда длина тела заранее неизвестна: сервер генерирует страницу постепенно, передаёт результат долгого вычисления или поток журнала.

При кодировании chunked тело разбито на части (англ. chunks). Каждой части предшествует строка с её длиной в шестнадцатеричной записи и CRLF, за данными части следует ещё один CRLF; конец тела обозначается частью нулевой длины, после которой могут идти завершающие поля (англ. trailer fields) и пустая строка. Реальный ответ учебного сервера, полученный curl --raw (ключ отключает декодирование и показывает тело как есть):

22
часть 1, время 12:46:01

22
часть 2, время 12:46:01

22
часть 3, время 12:46:01

0

Число 22 — шестнадцатеричное, то есть 34 байта: строка «часть 1, время 12:46:01» и символ перевода строки. Слово «часть» и «время» содержат 10 кириллических букв по два байта (20 байт), остальные 13 символов и перевод строки — по одному (14 байт). Пустая строка после каждой части — это CRLF, завершающий данные части, и перевод строки внутри самих данных. Кодирование chunked существует только в HTTP/1.1: в HTTP/2 и HTTP/3 тело и так передаётся кадрами с собственной длиной, и заголовок Transfer-Encoding там запрещён.

Правила определения длины кажутся техническими, но их нарушение приводит к серьёзной уязвимости — контрабанде запросов (англ. HTTP request smuggling). Если сообщение содержит и Content-Length, и Transfer-Encoding: chunked, а прокси и бэкенд по-разному решают, какому заголовку верить, они разойдутся во мнении, где кончается запрос. Остаток, который бэкенд считает началом следующего запроса, злоумышленник формирует сам, и этот «контрабандный» запрос выполняется от имени другого пользователя того же соединения. RFC 9112 требует, чтобы Transfer-Encoding имел приоритет, а сервер, получивший оба заголовка, считал такое сообщение подозрительным и закрывал соединение после ответа ³.

Состояние поверх протокола без состояния: cookies и сессии

Чтобы интернет-магазин «помнил» корзину покупателя, а почтовый сервис — что пользователь вошёл в систему, сервер должен связывать последовательные запросы одного клиента. Механизм cookies, описанный в RFC 6265, решает эту задачу без изменения самого протокола ¹⁰. Сервер включает в ответ заголовок Set-Cookie с парой «имя=значение» и атрибутами; клиент сохраняет её и в последующих запросах к тому же сайту отправляет заголовок Cookie. Ответ учебного сервера на первое посещение:

HTTP/1.1 200 OK
Set-Cookie: sid=4f0c2a9e1b7d3e65; Path=/; HttpOnly; SameSite=Lax
...
сессия 4f0c2a9e1b7d3e65 на web1, посещение 1

Чаще всего в cookie хранится не само состояние, а случайный идентификатор сессии (англ. session ID), по которому сервер находит данные сессии в своём хранилище. Атрибуты ограничивают использование cookie: Domain и Path — область сайта, Expires или Max-Age — срок хранения (без них cookie удаляется при закрытии браузера), Secure — передавать только по HTTPS, HttpOnly — недоступно сценариям JavaScript на странице, что снижает ущерб от внедрения сценария, SameSite — не отправлять cookie в запросах, инициированных чужими сайтами, что защищает от подделки межсайтовых запросов (англ. Cross-Site Request Forgery, CSRF).

Хранение сессии на сервере создаёт проблему при балансировке нагрузки: если сессия лежит в памяти сервера web1, а следующий запрос пользователя попадёт на web2, пользователь «выйдет из системы». Решения три: общее хранилище сессий для всех серверов, «липкие» сессии (англ. sticky sessions), когда балансировщик направляет клиента всегда на один сервер, или хранение подписанных данных сессии в самом cookie. В лабораторной работе эта проблема воспроизводится намеренно. Отметим также, что cookies, установленные сторонними сайтами (англ. third-party cookies), долгое время служили основой отслеживания пользователей между сайтами, и браузеры последовательно ограничивают их.

Соединения HTTP/1.1 и производительность

Стоимость соединения и постоянные соединения

В HTTP/1.0 каждый запрос открывал новое соединение TCP, и сервер закрывал его после ответа. Рассмотрим, сколько стоит одно соединение. Установление TCP занимает один круговой обход (англ. Round-Trip Time, RTT): SYN, SYN-ACK, после чего клиент может отправлять данные вместе с ACK. Для HTTPS добавляется рукопожатие TLS: один RTT в TLS 1.3 и два в TLS 1.2 (тема 17). Затем ещё один RTT уходит на сам запрос и ответ. Кроме того, новое соединение начинает с малого окна перегрузки и медленного старта (тема 13), поэтому большой ответ по свежему соединению передаётся медленнее, чем по «разогретому».

Числовой пример. При RTT 50 мс получение одного небольшого ресурса по HTTPS с TLS 1.3 по новому соединению займёт не менее 3 × 50 = 150 мс, из которых 100 мс — подготовка; по TLS 1.2 — 200 мс. Страница из 30 ресурсов при последовательной загрузке по отдельным соединениям потребовала бы не менее 30 × 150 = 4,5 с только на круговые задержки. Реальные измерения подтверждают порядок величин. Ниже — разбивка времени загрузки документа RFC 9110 с сервера, RTT до которого, по данным ping, около 40 мс:

curl -so /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} http=%{http_version}\n' https://www.rfc-editor.org/rfc/rfc9110.html

dns=0.035299 connect=0.083492 tls=0.179763 ttfb=0.408104 total=0.643659 http=2

Все значения отсчитываются от начала: DNS-запрос занял 35 мс, установление TCP — ещё 48 мс (около одного RTT), рукопожатие TLS — ещё 96 мс, первый байт ответа пришёл через 408 мс (здесь существенна обработка на сервере), а весь документ размером около 1,2 МБ (curl без ключа --compressed не запрашивает сжатие) — через 644 мс. Более четверти времени ушло на подготовку соединения.

Постоянные соединения (англ. persistent connections, keep-alive) устраняют повторную подготовку: в HTTP/1.1 соединение по умолчанию остаётся открытым после ответа, и следующий запрос отправляется по нему ³. Закрыть соединение после ответа любая сторона может, указав заголовок Connection: close; сервер также закрывает соединение, простоявшее без запросов некоторое время. В лабораторной работе сервер, написанный на сокетах, нумерует запросы в пределах соединения, и два запроса, отправленные подряд через один nc, получают ответы «запрос 1» и «запрос 2 в этом TCP-соединении».

Конвейеризация и блокировка начала очереди

Постоянное соединение устраняет подготовку, но не ожидание: по одному соединению HTTP/1.1 запросы обслуживаются строго последовательно, и следующий запрос отправляется только после получения полного ответа на предыдущий. На каждый ресурс по-прежнему уходит не меньше одного RTT. Стандарт HTTP/1.1 предусматривает конвейеризацию (англ. pipelining): клиент может отправить несколько запросов подряд, не дожидаясь ответов, и сервер обязан ответить на них в том же порядке ³.

Требование порядка и стало причиной неудачи конвейеризации. Если первый запрос обращается к медленно генерируемой странице, а за ним стоят десять маленьких картинок, готовые ответы на картинки не могут быть отправлены, пока не завершится первый ответ: в HTTP/1.1 нет способа указать, к какому запросу относится фрагмент данных, — ответы различаются только порядком. Это явление называется блокировкой начала очереди (англ. head-of-line blocking, HOL blocking). Вдобавок многие прокси и серверы реализовывали конвейеризацию с ошибками, и браузеры в итоге отключили её. Конвейеризация осталась в стандарте, но на практике не используется.

Параллельные соединения и приёмы оптимизации

Вместо конвейеризации браузеры открывают к одному серверу несколько параллельных соединений — обычно до шести на пару «схема, хост, порт». Это сокращает время загрузки примерно во столько раз, сколько соединений открыто, пока не упирается в пропускную способность. Лабораторная работа воспроизводит эффект: страница ссылается на 30 картинок, задержка канала клиента искусственно увеличена на 50 мс утилитой tc netem, и загрузчик loadpage.py измеряет общее время в трёх режимах (реальный вывод):

соединений: 1 (параллельно до 1), keep-alive: да
запросов: 31, общее время: 1669 мс
соединений: 6 (параллельно до 6), keep-alive: да
запросов: 31, общее время: 433 мс
соединений: 31 (параллельно до 1), keep-alive: нет
запросов: 31, общее время: 3187 мс

Результаты совпадают с простой моделью. По одному постоянному соединению 31 запрос требует примерно 31 RTT по 52–54 мс (с учётом обработки), то есть около 1,65 с. Шесть соединений делят 30 картинок на группы по 5, и время составляет около (1 + 1 + 5) × RTT ≈ 0,4 с: одно рукопожатие, HTML, пять волн запросов. Без постоянных соединений каждый запрос стоит двух RTT — рукопожатие и запрос, — и 31 × 2 × 52 ≈ 3,2 с.

Ограничение в шесть соединений и стоимость каждого из них породили целый набор приёмов эпохи HTTP/1.1: объединение мелких файлов в один (склейка сценариев и стилей, «спрайты» из картинок), встраивание мелких ресурсов прямо в HTML, распределение ресурсов по нескольким доменам (англ. domain sharding), чтобы обойти ограничение числа соединений на домен. Все они — обходные пути вокруг отсутствия мультиплексирования в протоколе, и с переходом на HTTP/2 часть из них стала вредной: например, распределение по доменам мешает использовать одно соединение.

Кеширование и промежуточные узлы

Кеширование HTTP: свежесть и проверка актуальности

Кеш HTTP (англ. HTTP cache) хранит ответы, чтобы обслуживать повторные запросы без обращения к серверу-источнику. Кеши бывают частными (англ. private cache), принадлежащими одному пользователю, — кеш браузера, — и общими (англ. shared cache), обслуживающими многих пользователей: прокси организации, сеть доставки контента. Правила кеширования вынесены в отдельный стандарт RFC 9111 ².

Центральное понятие — свежесть (англ. freshness). Сервер указывает, сколько секунд ответ можно использовать без проверки, директивой Cache-Control: max-age=N; пока возраст сохранённого ответа меньше max-age, кеш отдаёт его, не обращаясь к серверу. Общий кеш сообщает возраст выдаваемого ответа заголовком Age. Другие часто используемые директивы: no-store — не сохранять ответ вовсе (для конфиденциальных данных); no-cache — сохранять можно, но перед каждым использованием проверять актуальность у сервера (распространённая ошибка — считать, что no-cache запрещает кеширование); private — только для частного кеша; s-maxage — срок свежести для общих кешей; immutable — ресурс никогда не изменится. Если сервер не указал срок явно, кеш может вычислить его эвристически; RFC 9111 предлагает в качестве разумного значения 10 % от времени, прошедшего с последнего изменения ресурса ².

Когда срок свежести истёк, ответ не обязательно устарел. Чтобы проверить это, не загружая ресурс заново, используются валидаторы (англ. validators) — метаданные, по которым сервер может сравнить версии. Валидатор Last-Modified содержит дату последнего изменения, валидатор ETag (англ. entity tag) — непрозрачную для клиента метку версии, обычно хеш содержимого. Сильный ETag ("11b93fcbe2ba5571") меняется при изменении любого байта представления; слабый (W/"...") — только при смысловом изменении. Клиент, имеющий устаревшую копию, отправляет условный запрос (англ. conditional request) с заголовками If-None-Match: <ETag> или If-Modified-Since: <дата>. Если версия не изменилась, сервер отвечает кодом 304 Not Modified без тела, и клиент продлевает срок жизни своей копии; если изменилась — обычным ответом 200 с новым телом. Временная диаграмма на рисунке ниже показывает обе ситуации.

Реальный обмен с учебным сервером. Первый ответ на GET /doc содержит валидаторы и срок свежести:

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 35
ETag: "11b93fcbe2ba5571"
Last-Modified: Mon, 12 Oct 2026 09:46:00 GMT
Cache-Control: max-age=30

Повторный запрос с заголовком If-None-Match: "11b93fcbe2ba5571" получает ответ без тела:

HTTP/1.1 304 Not Modified
ETag: "11b93fcbe2ba5571"
Last-Modified: Mon, 12 Oct 2026 09:46:00 GMT
Cache-Control: max-age=30

Экономия зависит от размера ресурса: для 35-байтового документа она ничтожна, а для изображения в 2 МБ ответ 304 сокращает передачу до нескольких сотен байтов заголовков. Однако круговой обход остаётся: условный запрос экономит пропускную способность, но не задержку. Поэтому для неизменяемых ресурсов применяется другой приём — версионирование имён (app.3f9a1c.js) с очень большим max-age и директивой immutable: при изменении файла меняется его имя, и проверять старое имя никогда не нужно.

Заголовок Vary сообщает кешу, от каких заголовков запроса зависит ответ: при Vary: Accept-Encoding сжатый и несжатый варианты хранятся раздельно. Ошибка в Vary или кеширование ответа, зависящего от cookie, приводит к тому, что общий кеш выдаёт одному пользователю страницу другого, — такие инциденты регулярно случаются у неаккуратно настроенных CDN.

Прямой и обратный прокси

Прокси-сервер (англ. proxy) — посредник, принимающий запросы клиентов и пересылающий их дальше от своего имени. Различают два вида по тому, чьим интересам он служит. Прямой прокси (англ. forward proxy) действует от имени клиентов: его настраивает организация, и браузеры сотрудников направляют запросы к любым сайтам через него ради фильтрации, журналирования или общего кеша. Для HTTPS прямой прокси получает запрос CONNECT host:443 и после ответа 200 просто передаёт байты в обе стороны, не видя содержимого. Обратный прокси (англ. reverse proxy) действует от имени серверов: клиент считает, что обращается к самому сайту, а прокси распределяет запросы между внутренними серверами (бэкендами), завершает TLS, сжимает ответы и кеширует их. Типичные программы — nginx, HAProxy, Envoy.

Обратный прокси устанавливает с бэкендом собственное соединение TCP, поэтому бэкенд видит в качестве адреса клиента адрес прокси. Чтобы сохранить сведения о клиенте, прокси добавляет заголовки: X-Forwarded-For (адрес клиента; каждый следующий прокси дописывает через запятую адрес своего соседа), X-Forwarded-Proto (исходная схема — http или https), X-Forwarded-Host. Эти заголовки — фактический стандарт, стандартизованный аналог — заголовок Forwarded из RFC 7239. Кроме того, каждый посредник может добавлять заголовок Via ¹. Схема на рисунке ниже показывает учебную площадку лабораторной работы и путь заголовков.

Ответ бэкенда, который возвращает полученные заголовки, показывает, что прокси дописал адрес клиента к значению, уже присланному клиентом:

GET /headers HTTP/1.1
клиент TCP: 10.16.0.1:35318

Host: 10.16.0.1
X-Forwarded-For: 203.0.113.7, 10.16.0.10
X-Forwarded-Proto: http
Via: 1.1 px

Заголовок Via в этом примере добавил учебный прокси proxy.py; nginx в роли обратного прокси его по умолчанию не добавляет.

Пример раскрывает типичную ошибку безопасности. Клиент 10.16.0.10 сам добавил в запрос заголовок X-Forwarded-For: 203.0.113.7, и бэкенд, наивно берущий первый адрес списка, «увидит» клиента 203.0.113.7. Доверять можно только адресам, дописанным собственными прокси, то есть следует брать адрес, добавленный последним доверенным посредником, — в данном случае последний элемент списка. В nginx для этого служит модуль realip с директивой set_real_ip_from, перечисляющей доверенные прокси.

Прокси также удаляет заголовки, относящиеся только к одному переходу (англ. hop-by-hop): Connection, Keep-Alive, Transfer-Encoding, Upgrade и перечисленные в заголовке Connection ¹. Например, бэкенд может прислать ответ кодированием chunked, а прокси — переслать его клиенту с Content-Length или наоборот: способ передачи тела выбирается на каждом участке отдельно.

Балансировщики нагрузки уровней L4 и L7 и сети доставки контента

Балансировщик нагрузки (англ. load balancer) распределяет запросы между несколькими серверами. Различают два класса по уровню, на котором принимается решение. Балансировщик уровня L4 (транспортного) работает с соединениями: он видит адреса и порты, выбирает бэкенд для нового соединения TCP или потока UDP (по кругу, по наименьшей загрузке, по хешу адресов) и далее пересылает пакеты, не разбирая их содержимое. Он быстр, может работать в ядре ОС или на сетевом оборудовании, не требует ключей TLS, но не может направлять запросы по URL или cookie, а все запросы одного постоянного соединения попадают на один бэкенд. Балансировщик уровня L7 (прикладного) — это обратный прокси: он завершает соединение клиента, разбирает каждый запрос HTTP и может направлять /api/ на одни серверы, а /static/ — на другие, повторять неудачный идемпотентный запрос на другом бэкенде, учитывать cookie сессии, добавлять заголовки. Плата — больший расход ресурсов, необходимость расшифровывать TLS и два соединения вместо одного.

Балансировщик проверяет состояние бэкендов (англ. health check): периодически запрашивает служебный адрес, например /healthz, и исключает не ответившие серверы. Учебный прокси в лабораторной работе делает упрощённый вариант: при отказе соединения с бэкендом пробует следующий, а если не ответил никто, возвращает 502.

Сеть доставки контента (англ. Content Delivery Network, CDN) — географически распределённая система обратных прокси с кешами. Пользователь направляется на ближайший узел CDN с помощью DNS (GeoDNS) или anycast (тема 15), узел отдаёт ресурс из кеша, а при промахе обращается к серверу-источнику. CDN сокращает RTT до пользователя, разгружает источник и поглощает атаки отказа в обслуживании. Все директивы кеширования, рассмотренные выше, касаются CDN напрямую: именно они определяют, что и как долго узел CDN вправе хранить.

HTTP/2 и HTTP/3

HTTP/2: двоичное кадрирование и мультиплексирование

HTTP/2 вырос из экспериментального протокола SPDY компании Google и был стандартизован в 2015 году (RFC 7540), а в 2022 году переиздан как RFC 9113 ⁴. Его цель — устранить блокировку начала очереди на уровне HTTP и накладные расходы текстовых заголовков, не меняя семантики: методы, коды состояния и заголовки остались прежними, и приложению безразлично, по какой версии пришёл запрос.

Главное изменение — двоичное кадрирование (англ. binary framing). Всё соединение разбито на кадры (англ. frames) с 9-байтовым заголовком: длина данных кадра (24 бита), тип (8 бит), флаги (8 бит), зарезервированный бит и идентификатор потока (31 бит) ⁴. Поток (англ. stream) — логический двунаправленный канал внутри соединения, по которому передаётся одна пара «запрос — ответ»; клиент открывает потоки с нечётными номерами 1, 3, 5 и так далее. Запрос — это кадр HEADERS (при необходимости с продолжениями CONTINUATION) и кадры DATA с телом; ответ передаётся так же в том же потоке. Служебные кадры относятся к потоку 0: SETTINGS (параметры соединения), PING, GOAWAY (корректное завершение), WINDOW_UPDATE (управление потоком данных). Кадр RST_STREAM отменяет один поток, не закрывая соединение.

Поскольку каждый кадр помечен номером потока, кадры разных ответов могут чередоваться в одном соединении TCP: сервер отправляет готовые фрагменты любого ответа, не дожидаясь завершения других. Это мультиплексирование (англ. multiplexing) устраняет блокировку начала очереди уровня HTTP, и браузеру достаточно одного соединения с сервером вместо шести. Схема на рисунке ниже сравнивает передачу трёх ответов в HTTP/1.1 и HTTP/2.

Эффект виден на реальном сервере. Ниже шесть параллельных загрузок одного документа утилитой curl -Z (параллельный режим) с принудительным HTTP/1.1 и с HTTP/2; подсчитаны строки отладочного вывода (номер соединения (#N) в конце строки Connected перед подсчётом отброшен):

== --http1.1
      6 * ALPN, server accepted to use http/1.1
      6 * Connected to www.rfc-editor.org (8.47.69.5) port 443
      6 < HTTP/1.1 200 OK
== --http2
      1 * ALPN, server accepted to use h2
      1 * Connected to www.rfc-editor.org (8.47.69.5) port 443
      5 * Multiplexed connection found!
      6 < HTTP/2 200

В первом случае curl открыл шесть соединений TCP и провёл шесть рукопожатий TLS, во втором — одно соединение, по которому все шесть запросов прошли как разные потоки. Версия протокола согласуется во время рукопожатия TLS расширением ALPN (англ. Application-Layer Protocol Negotiation): клиент предлагает h2 и http/1.1, сервер выбирает. На практике HTTP/2 используется только поверх TLS; вариант без шифрования (h2c) стандарт допускает, но браузеры его не поддерживают.

Мультиплексирование требует новых механизмов. Управление потоком данных (англ. flow control) действует и на уровне отдельного потока, и на уровне соединения: получатель объявляет окно (по умолчанию 65 535 байт) и расширяет его кадрами WINDOW_UPDATE, чтобы быстрый поток не занял весь буфер. Приоритизация позволяет клиенту сообщить, какие ответы важнее; исходная древовидная схема RFC 7540 оказалась слишком сложной, в RFC 9113 она объявлена устаревшей, а ей на смену пришла простая схема с заголовком Priority (RFC 9218). Функция серверного выталкивания (англ. server push), позволявшая серверу отправить ресурс до запроса, на практике почти не дала выигрыша и отключена в основных браузерах.

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

Заголовки HTTP/1.1 повторяются почти без изменений в каждом запросе: User-Agent, Accept, Cookie вместе легко занимают 500–800 байт, и при сотне запросов страницы это десятки килобайт только в направлении к серверу, где канал часто медленнее. Для HTTP/2 разработано специальное сжатие HPACK (RFC 7541) ⁵. Обычные алгоритмы сжатия вроде DEFLATE не подошли: атака CRIME 2012 года показала, что при сжатии секретов (cookie) вместе с данными, подконтрольными злоумышленнику, по размеру зашифрованного сообщения можно подобрать секрет.

HPACK использует три приёма. Статическая таблица содержит 61 частую пару «имя — значение» или только имя: например, индекс 2 — :method: GET, индекс 7 — :scheme: https. Динамическая таблица (по умолчанию до 4096 байт) заполняется в ходе соединения: заголовок, отправленный один раз, в следующих запросах передаётся номером записи, то есть одним-двумя байтами. Строки, которые всё же передаются, могут кодироваться статическим кодом Хаффмана, оптимизированным для типичных заголовков. В HTTP/2 строка запроса заменена псевдозаголовками :method, :scheme, :authority (замена Host) и :path, а строка состояния — псевдозаголовком :status; имена полей пишутся строчными буквами. Типичный второй запрос к тому же сайту сжимается HPACK до нескольких десятков байтов.

Динамическая таблица — общее состояние кодировщика и декодировщика, поэтому кадры с заголовками должны обрабатываться строго в порядке отправки. Для HTTP/2 поверх упорядоченного потока TCP это естественно, но для HTTP/3, где порядок между потоками не гарантирован, потребовалась другая схема — QPACK.

Блокировка начала очереди в TCP и транспорт QUIC

HTTP/2 устранил блокировку начала очереди на уровне HTTP, но перенёс её на уровень ниже. Все потоки идут по одному соединению TCP, а TCP доставляет байты строго по порядку (тема 13). Если потерян один сегмент, содержащий кадр потока 5, ядро получателя не передаст приложению уже пришедшие следующие сегменты с кадрами потоков 1 и 3, пока потерянный сегмент не будет передан повторно. При потерях в 1–2 % (мобильные сети, перегруженный Wi-Fi) одно соединение HTTP/2 может работать хуже шести соединений HTTP/1.1, у каждого из которых свой порядок. Исправить это внутри TCP нельзя: порядок доставки — часть его контракта, а сам TCP реализован в ядрах операционных систем и в промежуточном оборудовании, которое плохо переносит изменения протокола (явление окостенения, англ. ossification).

Ответом стал новый транспортный протокол QUIC, стандартизованный в 2021 году в RFC 9000 ⁶. QUIC работает поверх UDP, что позволяет реализовать его в пространстве пользователя, в составе браузера или серверного приложения, и проходить через существующие сети. Его основные свойства:

• потоки встроены в транспорт: QUIC сам знает, какие байты к какому потоку относятся, и потеря пакета задерживает только те потоки, данные которых в нём были; остальные потоки доставляются приложению без ожидания;
• шифрование обязательно и встроено: рукопожатие QUIC объединено с рукопожатием TLS 1.3 (RFC 9001), зашифрованы не только данные, но и большая часть заголовка пакета, включая номер пакета, что защищает протокол от вмешательства промежуточных устройств ¹⁴;
• установление соединения вместе с согласованием ключей занимает один RTT, а при повторном подключении к знакомому серверу возможна отправка данных уже в первом пакете (0-RTT);
• соединение идентифицируется не четвёркой «адреса и порты», а идентификатором соединения (англ. connection ID), поэтому при смене адреса клиента — переходе телефона с Wi-Fi на мобильную сеть, смене порта после перезапуска трансляции NAT — соединение продолжается без нового рукопожатия; это называется миграцией соединения (англ. connection migration);
• обнаружение потерь и управление перегрузкой (RFC 9002) наследуют идеи TCP, но номера пакетов никогда не повторяются, даже для повторной передачи, что устраняет неоднозначность измерения RTT, известную в TCP.

Схема на рисунке ниже сравнивает число круговых обходов до получения первого ответа для TCP с TLS 1.3 и для QUIC.

Числовой пример. При RTT 100 мс (пользователь в другой части континента) первый ответ по HTTPS поверх TCP и TLS 1.3 приходит не раньше чем через 300 мс, по TLS 1.2 — через 400 мс, по QUIC — через 200 мс, по QUIC с 0-RTT — через 100 мс. Данные 0-RTT имеют ограничение: злоумышленник может перехватить и повторно отправить такой пакет, поэтому в 0-RTT допустимы только запросы, повтор которых безопасен, — в первую очередь идемпотентные GET (подробнее о повторах — в теме 17).

Перенос транспорта в UDP имеет и обратную сторону. Часть корпоративных сетей блокирует UDP-порт 443, и клиенты должны уметь возвращаться к TCP. Обработка UDP в ядрах ОС исторически оптимизирована хуже, чем TCP, и реализация QUIC в пространстве пользователя расходует больше процессорного времени на байт. Для защиты от использования в атаках с усилением сервер QUIC до подтверждения адреса клиента может отправить не более чем втрое больше данных, чем получил, а первый пакет клиента дополняется до 1200 байт ⁶.

HTTP/3 и QPACK

HTTP/3 (RFC 9114, 2022) — отображение семантики HTTP на транспорт QUIC ⁷. Каждый запрос и ответ передаются в отдельном двунаправленном потоке QUIC кадрами HEADERS и DATA, похожими на кадры HTTP/2, но без номера потока: его роль играет поток QUIC. Управление потоком данных, мультиплексирование и надёжная доставка перешли в транспорт, и HTTP/3 устроен проще HTTP/2. Однонаправленные потоки используются для служебных целей: управляющий поток с кадром SETTINGS и потоки кодировщика и декодировщика заголовков.

Сжатие заголовков в HTTP/3 выполняет QPACK (RFC 9204) ⁸. Он сохраняет идеи HPACK — статическую таблицу (в QPACK она расширена до 99 записей), динамическую таблицу и код Хаффмана, — но решает проблему порядка: обновления динамической таблицы передаются по отдельному однонаправленному потоку, а каждый блок заголовков указывает, какое состояние таблицы ему нужно. Кодировщик сам выбирает компромисс: ссылаться на ещё не подтверждённые записи (лучше сжатие, но возможно ожидание) или нет (поток никогда не блокируется).

Как клиент узнаёт, что сервер поддерживает HTTP/3, если первое соединение идёт по TCP? Существуют два способа. Первый — заголовок Alt-Svc (англ. alternative services, RFC 7838) в ответе HTTP/2 или HTTP/1.1: alt-svc: h3=":443"; ma=86400 означает, что тот же сервис доступен по HTTP/3 на UDP-порту 443, и эти сведения действительны сутки. Браузер запоминает это и следующее соединение пробует устанавливать по QUIC. Второй — запись HTTPS в DNS с параметром alpn="h3,h2" (тема 15), позволяющая использовать HTTP/3 уже при первом подключении. Реальные ответы крупных сайтов содержат такие заголовки:

HTTP/2 200
server: cloudflare
alt-svc: h3=":443"; ma=86400

Сводная таблица сравнивает три версии протокола.

Прикладные протоколы поверх HTTP и рядом с ним

REST и программные интерфейсы

Термин REST (англ. Representational State Transfer) ввёл Рой Филдинг, один из авторов спецификации HTTP/1.1, в диссертации 2000 года для описания архитектурного стиля Веба ¹². Его ограничения — модель «клиент — сервер», отсутствие состояния на сервере между запросами, кешируемость ответов, единообразный интерфейс (ресурсы, идентифицируемые URI, и манипуляция ими через представления), многоуровневая система с посредниками. На практике «REST API» обычно означает программный интерфейс поверх HTTP, в котором ресурсы адресуются путями, действия выражаются методами, а результаты — кодами состояния:

GET    /api/v1/hosts          — список узлов                 200
POST   /api/v1/hosts          — создать узел (тело — JSON)   201, Location: /api/v1/hosts/17
GET    /api/v1/hosts/17       — получить узел                200 или 404
PUT    /api/v1/hosts/17       — заменить узел целиком        200 или 204
DELETE /api/v1/hosts/17       — удалить узел                 204

Такой интерфейс автоматически получает всё, что даёт инфраструктура HTTP: кеширование ответов GET, повтор идемпотентных запросов, балансировку на уровне L7, стандартную аутентификацию через заголовок Authorization. Неудачные интерфейсы, передающие всё методом POST на один адрес и всегда отвечающие кодом 200 с описанием ошибки в теле, теряют эти преимущества. Наряду с REST широко используются GraphQL (язык запросов, передаваемых обычно методом POST) и gRPC — система удалённого вызова процедур поверх HTTP/2 с двоичной сериализацией Protocol Buffers, популярная для взаимодействия внутренних сервисов. Интерфейсы управления сетевым оборудованием RESTCONF и gNMI, рассматриваемые в теме 22, построены на тех же принципах.

WebSocket

HTTP устроен по схеме «запрос — ответ»: сервер не может отправить клиенту данные по своей инициативе. Для чатов, биржевых котировок, совместного редактирования документов нужен двунаправленный канал. До 2011 года эту задачу решали искусственно — периодическим опросом (англ. polling) или «долгим опросом» (англ. long polling), когда сервер задерживает ответ до появления данных. Протокол WebSocket (RFC 6455) предоставляет полноценный двунаправленный канал сообщений поверх одного соединения TCP ¹¹.

Соединение WebSocket начинается как обычный запрос HTTP/1.1, просящий сменить протокол:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Сервер подтверждает, что понял именно протокол WebSocket, а не просто вернул закешированный ответ: значение Sec-WebSocket-Accept — хеш SHA-1 от присланного ключа, сцепленного с фиксированной строкой 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, в кодировке base64 (пример взят из RFC 6455) ¹¹. После ответа 101 соединение перестаёт быть HTTP: по нему в обе стороны передаются кадры WebSocket с коротким заголовком (2–14 байт), содержащим тип (текст, двоичные данные, закрытие, ping, pong) и длину. Кадры от клиента маскируются случайным 32-битным ключом — это защита от отравления кешей промежуточных прокси, которые могли бы принять данные внутри соединения за запрос HTTP. Заголовок Upgrade относится к одному переходу, поэтому обратный прокси должен быть явно настроен на пересылку WebSocket — частая причина того, что WebSocket «не работает за nginx».

Электронная почта: SMTP, IMAP и защита отправителя

Электронная почта старше Веба и устроена иначе: письмо проходит через несколько серверов, каждый из которых хранит его и пересылает дальше (англ. store-and-forward). Протокол SMTP (англ. Simple Mail Transfer Protocol, RFC 5321) передаёт письма между серверами и от почтового клиента к серверу отправки ¹³. Как и HTTP/1.1, он текстовый и работает поверх TCP: сервер-отправитель находит по записи MX (тема 15) сервер получателя, подключается к нему на порт 25 и ведёт диалог командами EHLO, MAIL FROM, RCPT TO, DATA, завершая текст письма строкой из одной точки; каждая команда получает трёхзначный код ответа, похожий по смыслу на коды HTTP (2xx — успех, 4xx — временная ошибка, повторить позже, 5xx — постоянная ошибка). Клиенты отправляют почту на порт 587 с аутентификацией, а читают её с сервера по протоколу IMAP (порт 993 с TLS), при котором письма хранятся на сервере и синхронизируются между устройствами.

Важно различать конверт и заголовки письма. Адреса в командах MAIL FROM и RCPT TO — конверт, по которому письмо доставляется; заголовок From: внутри текста письма — то, что видит пользователь, и в исходном SMTP он ничем не проверяется. Это открыло путь массовой подделке отправителя, и три механизма, публикуемые владельцем домена в DNS в записях TXT, сейчас обязательны для надёжной доставки почты. SPF (RFC 7208) перечисляет адреса, с которых разрешено отправлять почту домена, — например, v=spf1 mx -all означает «только серверы из MX, остальные отвергать». DKIM (RFC 6376) добавляет к письму цифровую подпись заголовков и тела, открытый ключ для которой публикуется в DNS. DMARC (RFC 7489) связывает обе проверки с видимым адресом From: и сообщает получателю политику: что делать с письмом, не прошедшим проверку (ничего, поместить в спам, отвергнуть), и куда присылать отчёты.

SSH

Протокол защищённой оболочки (англ. Secure Shell, SSH; RFC 4251–4254) обеспечивает удалённый вход в систему и выполнение команд по зашифрованному каналу TCP на порту 22. Он состоит из трёх уровней: транспортного (согласование алгоритмов, обмен ключами по Диффи — Хеллману, аутентификация сервера по его ключу), аутентификации пользователя (по паролю или, предпочтительнее, по ключу) и уровня соединения, мультиплексирующего в одном соединении несколько каналов — сеанс оболочки, передачу файлов SFTP, перенаправление портов. В отличие от TLS, SSH обычно не использует сертификаты удостоверяющих центров: при первом подключении клиент показывает отпечаток ключа сервера и запоминает его в файле ~/.ssh/known_hosts (модель «доверие при первом использовании», англ. Trust On First Use, TOFU), а при изменении ключа выдаёт предупреждение о возможной атаке «человек посередине». Перенаправление портов SSH (ssh -L, ssh -D) превращает его в простой туннель; туннели и VPN рассматриваются в теме 19.

Синхронизация сетевого времени: протокол NTP

Наряду с именами (DNS) и адресами (DHCP), распределённым системам требуется общее представление о времени. Без точной синхронизации часов невозможны сопоставление событий в распределённых журналах, проверка срока действия сертификатов TLS, работа протокола аутентификации Kerberos и алгоритмы репликации баз данных. Эту задачу решает сетевой протокол времени (англ. Network Time Protocol, NTP; RFC 5905) ¹⁵, работающий поверх UDP на порту 123.

NTP организован как иерархическая сеть стратумов (англ. stratum):

• Stratum 0: первичные физические эталоны времени (атомные цезиевые часы, сигналы GPS/ГЛОНАСС), подключённые к серверу напрямую через последовательный порт или интерфейс импульса в секунду (PPS);
• Stratum 1: серверы точного времени, непосредственно подключённые к источникам Stratum 0;
• Stratum 2: серверы и рабочие станции, синхронизирующиеся по сети с серверами Stratum 1;
• Stratum N (до 15): каждый последующий уровень синхронизируется с уровнем N-1, накапливая небольшую систематическую погрешность (обычно единицы миллисекунд в глобальном Интернете и доли миллисекунды в локальной сети).

Для вычисления смещения часов клиент и сервер обмениваются 48-байтными пакетами, фиксируя четыре временные метки с 64-битной точностью (32 бита — секунды с 1 января 1900 года, 32 бита — доли секунды):

• T_1 — время отправки запроса клиентом (по часам клиента);
• T_2 — время приёма запроса сервером (по часам сервера);
• T_3 — время отправки ответа сервером (по часам сервера);
• T_4 — время приёма ответа клиентом (по часам клиента).

Круговая сетевая задержка (Round-Trip Delay) \delta и смещение часов клиента относительно сервера (Clock Offset) \theta рассчитываются по формулам:

\delta = (T_4 - T_1) - (T_3 - T_2), \qquad \theta = \frac{(T_2 - T_1) + (T_3 - T_4)}{2}

Временная диаграмма и иерархия стратумов приведены на схеме ниже.

Формула предполагает симметричность сетевого пути. Чтобы отсеять асимметрию и дрожание задержки (джиттер), клиент опрашивает несколько серверов и применяет алгоритм пересечения интервалов Марзулло, отбрасывая источники с аномальными показаниями. Для плавной корректировки времени операционная система использует дисциплину фазовой автоподстройки: вместо резких скачков назад, способных нарушить монотонность временных меток в базах данных, ход системных часов плавно замедляется или ускоряется с помощью системного вызова adjtimex (режим slewing). Для простых встраиваемых устройств и IoT-датчиков применяется облегчённая версия SNTP (Simple NTP, RFC 4330).

Одноранговые сети и распределённые оверлеи (Peer-to-Peer)

Все рассмотренные ранее протоколы (HTTP, DNS, SMTP) следуют парадигме «клиент — сервер»: централизованный сервер несёт на себе всю нагрузку по хранению и раздаче контента. При лавинообразном росте числа пользователей серверная инфраструктура становится узким местом.

Альтернативой является парадигма одноранговых сетей (Peer-to-Peer, P2P). В P2P-сети каждый узел (пир, англ. peer или servent от server + client) одновременно выступает и клиентом, потребляющим данные, и сервером, раздающим их другим участникам ¹⁶. При росте числа скачивающих совокупная пропускная способность сети не падает, а масштабируется вместе с числом участников.

Логическая топология P2P-сети строится поверх физического Интернета в виде оверлейной сети (Overlay Network). Эволюция оверлеев привела к созданию структурированных сетей на основе распределённых хеш-таблиц (DHT — Distributed Hash Table), обеспечивающих децентрализованный поиск ключей с логарифмической сложностью O(\log N).

Де-факто стандартом современных DHT стал алгоритм Kademlia ¹⁶, используемый в протоколе BitTorrent (Mainline DHT), сетях IPFS и Ethereum. В Kademlia узлам и файлам присваиваются 160-битные идентификаторы. Расстоянием между двумя узлами x и y считается побитовое исключающее ИЛИ:

d(x, y) = x \oplus y

Метрика XOR обладает свойствами строгого математического расстояния. Узел хранит контакты соседей в списках (k-бакетах), сгруппированных по расстояниям степеней двойки, что позволяет найти узел, ответственный за любой ключ, за \log_2 N шагов маршрутизации.

Примером высокоэффективного прикладного P2P-протокола является BitTorrent ¹⁷. Файл делится на равные куски (pieces) по 256 КиБ — 2 МБ, контрольные суммы которых заверяются в файле метаданных или magnet-ссылке (BTIH — BitTorrent Info Hash). Ключевые механизмы BitTorrent:

• Стратегия «самый редкий первым» (Rarest-First): пиры в первую очередь скачивают и раздают те куски, которые реже всего встречаются в рое (swarm), предотвращая деградацию распределения при уходе источников;
• Игровой механизм «око за око» (Tit-for-Tat): пир отдаёт данные с максимальной скоростью тем узлам, которые быстрее всего отдают данные ему самому, поощряя раздающих участников;
• Преодоление NAT (NAT Traversal): установление прямых P2P-соединений между узлами за трансляторами адресов через технику согласования портов (UDP Hole Punching).

Итоги темы

HTTP разделяет семантику и способ передачи. Семантика — ресурсы, идентифицируемые URI, методы с определёнными свойствами безопасности и идемпотентности, коды состояния, заголовки, правила кеширования — едина для всех версий и позволяет клиентам, серверам и посредникам взаимодействовать, не зная устройства друг друга. На этой основе построены программные интерфейсы REST, а механизм cookies добавляет состояние поверх протокола без состояния.

HTTP/1.1 передаёт сообщения текстом поверх TCP и определяет длину тела через Content-Length или кодирование chunked. Постоянные соединения устраняют повторную подготовку соединения, но по каждому соединению запросы идут строго по очереди, а неудачная конвейеризация показала, что упорядоченные ответы порождают блокировку начала очереди. Браузеры компенсируют это параллельными соединениями, и время загрузки страницы со многими ресурсами определяется прежде всего числом круговых обходов, а не пропускной способностью.

Кеширование уменьшает и задержку, и нагрузку: свежий ответ выдаётся без обращения к серверу, а устаревший проверяется условным запросом с ETag и подтверждается кодом 304 без тела. Посредники — прямые и обратные прокси, балансировщики уровней L4 и L7, сети доставки контента — составляют неотъемлемую часть Веба, и протокол учитывает их явно: заголовками hop-by-hop, Via, X-Forwarded-For, директивами для общих кешей. Неаккуратное доверие этим заголовкам и расхождения в определении длины сообщения — источник реальных уязвимостей.

HTTP/2 ввёл двоичные кадры и мультиплексирование потоков в одном соединении, а сжатие HPACK сократило накладные расходы заголовков; но блокировка начала очереди осталась на уровне TCP. HTTP/3 переносит HTTP на новый транспорт QUIC поверх UDP со встроенным TLS 1.3, независимыми потоками, рукопожатием в один RTT и миграцией соединения. Шифрование, на котором держатся HTTPS, QUIC, DoH и SSH, — предмет следующей темы, посвящённой криптографическим примитивам, инфраструктуре открытых ключей и протоколу TLS.

Литература

1. Fielding R., Nottingham M., Reschke J. HTTP Semantics. — RFC 9110, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9110
2. Fielding R., Nottingham M., Reschke J. HTTP Caching. — RFC 9111, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9111
3. Fielding R., Nottingham M., Reschke J. HTTP/1.1. — RFC 9112, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9112
4. Thomson M., Benfield C. HTTP/2. — RFC 9113, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9113
5. Peon R., Ruellan H. HPACK: Header Compression for HTTP/2. — RFC 7541, IETF, 2015. https://www.rfc-editor.org/rfc/rfc7541
6. Iyengar J., Thomson M. QUIC: A UDP-Based Multiplexed and Secure Transport. — RFC 9000, IETF, 2021. https://www.rfc-editor.org/rfc/rfc9000
7. Bishop M. HTTP/3. — RFC 9114, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9114
8. Krasic C., Bishop M., Frindell A. QPACK: Field Compression for HTTP/3. — RFC 9204, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9204
9. Berners-Lee T., Fielding R., Masinter L. Uniform Resource Identifier (URI): Generic Syntax. — RFC 3986, IETF, 2005. https://www.rfc-editor.org/rfc/rfc3986
10. Barth A. HTTP State Management Mechanism. — RFC 6265, IETF, 2011. https://www.rfc-editor.org/rfc/rfc6265
11. Fette I., Melnikov A. The WebSocket Protocol. — RFC 6455, IETF, 2011. https://www.rfc-editor.org/rfc/rfc6455
12. Fielding R. T. Architectural Styles and the Design of Network-based Software Architectures. — Doctoral dissertation, University of California, Irvine, 2000. https://ics.uci.edu/~fielding/pubs/dissertation/top.htm
13. Klensin J. Simple Mail Transfer Protocol. — RFC 5321, IETF, 2008. https://www.rfc-editor.org/rfc/rfc5321
14. Thomson M., Turner S. Using TLS to Secure QUIC. — RFC 9001, IETF, 2021. https://www.rfc-editor.org/rfc/rfc9001
15. Mills D., Martin J., Burbank J., Kasch W. Network Time Protocol Version 4: Protocol and Algorithms Specification. — RFC 5905, IETF, 2010. https://www.rfc-editor.org/rfc/rfc5905
16. Maymounkov P., Mazières D. Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. — First International Workshop on Peer-to-Peer Systems (IPTPS '02), Lecture Notes in Computer Science, 2002, Vol. 2429, С. 53–65.
17. Cohen B. Incentives Build Robustness in BitTorrent. — Workshop on Economics of Peer-to-Peer Systems, 2003.

Дополнительные материалы

Вопросы для самопроверки

1. Какие части URI передаются серверу и где именно в запросе HTTP/1.1? Какая часть не передаётся вовсе?
2. Почему без заголовка Host невозможен виртуальный хостинг? Чем его заменяет HTTP/2?
3. Какие методы безопасны, какие идемпотентны? Приведите пример неидемпотентного метода и ситуацию, в которой это важно.
4. Ответ содержит заголовок Transfer-Encoding: chunked и тело 5\r\nhello\r\n6\r\n world\r\n0\r\n\r\n. Каково декодированное тело и сколько в нём байтов?
5. Чем отличаются коды 301, 302, 307 и 308?
6. Зачем cookie атрибуты HttpOnly, Secure и SameSite? От каких угроз защищает каждый?
7. Страница содержит 60 ресурсов, RTT равен 80 мс. Оцените время загрузки по HTTP/1.1 с шестью постоянными соединениями без учёта обработки и передачи данных.
8. Чем свежесть ответа отличается от его актуальности? Какие заголовки управляют каждой из них?
9. Что такое сильный и слабый ETag? Когда сервер может использовать слабый?
10. Какие заголовки являются hop-by-hop и почему прокси обязан их удалять?
11. Почему HTTP/2 устранил блокировку начала очереди на уровне HTTP, но не на уровне транспорта?
12. Какие преимущества дало сжатие HPACK по сравнению с DEFLATE и почему DEFLATE для заголовков небезопасен?
13. Почему QUIC работает поверх UDP, а не является новым протоколом IP с собственным номером, как TCP?
14. Чем рискованны данные 0-RTT и какие запросы в них допустимы?
15. Как SPF, DKIM и DMARC вместе защищают от подделки адреса отправителя письма?
16. Как протокол NTP вычисляет смещение часов (\theta) и круговую задержку (\delta) по четырём временным меткам, и почему операционные системы предпочитают плавную подстройку (slewing) скачкам времени?
17. Каковы преимущества децентрализованных оверлеев на основе DHT (Kademlia) перед централизованными P2P-каталогами, и как стратегия Rarest-First в BitTorrent защищает рой от деградации?

Глоссарий темы

Шпаргалка по инструментам

# curl: запросы и разбор
curl -v https://example.com/               # заголовки запроса (>) и ответа (<)
curl -sI https://example.com/              # только заголовки (метод HEAD)
curl -s -o /dev/null -D - URL              # заголовки ответа на GET без тела
curl -L URL                                # следовать перенаправлениям
curl -X PUT -H 'Content-Type: application/json' -d '{"a":1}' URL
curl --raw URL                             # тело без декодирования chunked
curl -b cj.txt -c cj.txt URL               # хранить cookies в файле
curl -H 'If-None-Match: "etag"' -i URL     # условный запрос
curl -so /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' URL
curl --http1.1 | --http2 | --http3 URL     # версия (http3 — если curl собран с её поддержкой)
curl --http2-prior-knowledge http://host:port/   # HTTP/2 без TLS
curl -Z URL1 URL2 -o f1 -o f2              # параллельная загрузка
curl --resolve www.example.com:443:192.0.2.10 https://www.example.com/   # подменить адрес без DNS

# «Сырой» HTTP
printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' | nc example.com 80
openssl s_client -connect example.com:443 -servername example.com -quiet   # затем ввести запрос вручную

# Простые серверы
python3 -m http.server 8000                # статические файлы из текущего каталога
nghttp -nv https://example.com/            # кадры HTTP/2 (пакет nghttp2-client)

# Проверка синхронизации времени NTP
chronyc sources -v                         # подробный статус источников времени и стратумов
timedatectl timesync-status                # статус встроенного клиента systemd-timesyncd
ntpdate -q pool.ntp.org                    # опрос сервера времени без изменения локальных часов

# Задержка и потери для экспериментов
sudo tc qdisc add dev eth0 root netem delay 50ms loss 1%
sudo tc qdisc del dev eth0 root

Фильтры Wireshark: http, http.response.code >= 400, http.request.uri contains "img", http2.type == 1 (кадры HEADERS), http2.streamid == 3, quic, tls.handshake.extensions_alpn_str. Для расшифровки HTTPS и HTTP/2 в Wireshark используется файл ключей SSLKEYLOGFILE — подробно в лабораторной работе 17.

Что почитать и посмотреть

• RFC 9110. HTTP Semantics — основной документ HTTP: методы (раздел 9), коды состояния (раздел 15), условные запросы (раздел 13). Хорошо структурирован и читается как справочник.
• MDN Web Docs: HTTP — подробное справочное руководство Mozilla по заголовкам, кодам и механизмам HTTP с примерами.
• Grigorik I. High Performance Browser Networking. — O'Reilly, 2013. Книга свободно доступна онлайн; главы о HTTP/1.1, HTTP/2 и о влиянии задержки на производительность Веба по-прежнему актуальны, хотя HTTP/3 в ней не описан.
• Pollard B. HTTP/2 in Action. — Manning, 2019. Подробное практическое изложение HTTP/2 с главой о QUIC.
• Daniel Stenberg. HTTP/3 explained — короткая свободная книга автора curl о QUIC и HTTP/3: мотивация, устройство и состояние внедрения.
• The Illustrated QUIC Connection — побайтовый разбор реального соединения QUIC с расшифровкой каждого пакета; аналогичные страницы есть для TLS 1.3.
• Блог Cloudflare: HTTP/3: the past, the present, and the future — история появления QUIC и HTTP/3 и опыт внедрения.
• PortSwigger Web Security Academy: HTTP request smuggling — объяснение и практические задания по атаке контрабанды запросов, рассмотренной в теме.
• Документация nginx: модуль ngx_http_proxy_module — описание директив обратного прокси, использованных в лабораторной работе: proxy_pass, proxy_set_header, proxy_next_upstream, тайм-ауты.
• Fielding R. T. Architectural Styles and the Design of Network-based Software Architectures, глава 5 — первоисточник понятия REST; полезно прочитать, чтобы отличать архитектурный стиль от распространённого употребления термина.

Углубление (по желанию)

От HTTP/0.9 к HTTP/3: тридцать лет эволюции

Первая версия HTTP, созданная Тимом Бернерсом-Ли в CERN в 1990–1991 годах и позже названная HTTP/0.9, состояла из одной строки GET /путь: ни заголовков, ни кодов состояния, ни методов, кроме GET; сервер возвращал HTML и закрывал соединение. HTTP/1.0 (RFC 1945, 1996) добавил заголовки, коды состояния, типы содержимого и методы POST и HEAD, но по-прежнему открывал соединение на каждый запрос. HTTP/1.1 (RFC 2068, 1997; RFC 2616, 1999; RFC 7230–7235, 2014; RFC 9110–9112, 2022) ввёл постоянные соединения, обязательный Host, кодирование chunked, развитое кеширование и согласование содержимого и оставался единственной версией почти двадцать лет. Медленная эволюция была следствием успеха: миллионы серверов, прокси и устройств промежуточной обработки должны были продолжать работать. HTTP/2 (2015) удалось развернуть только поверх TLS, где промежуточные устройства не видят содержимого, а HTTP/3 (2022) потребовал нового транспорта, зашифрованного почти целиком, — в том числе чтобы промежуточные устройства не смогли «окостенеть» вокруг его деталей, как это произошло с TCP.

Почему QUIC шифрует почти весь заголовок

Опыт TCP показал, что любое поле, видимое в сети, рано или поздно начинает использоваться промежуточным оборудованием — межсетевыми экранами, системами ускорения, балансировщиками, — и после этого его уже нельзя изменить: новые опции TCP, такие как Multipath TCP или TCP Fast Open, годами не могли пройти через сети, где оборудование отбрасывает или «исправляет» незнакомые значения. Проектировщики QUIC сознательно оставили открытыми только минимально необходимые поля: флаги формы заголовка, версию (в длинном заголовке) и идентификаторы соединения. Номер пакета защищён отдельной маской, вычисляемой из зашифрованных данных (англ. header protection), подтверждения и управляющие кадры передаются внутри зашифрованной полезной нагрузки, а для проверки того, что версия протокола может меняться, предусмотрен механизм «смазки» (англ. greasing) — отправки случайных зарезервированных значений, чтобы реализации не могли на них полагаться. Обратная сторона — операторам сетей стало труднее измерять задержку и потери пассивным наблюдением; для этого в заголовок QUIC добавлен единственный необязательный «бит спина» (англ. spin bit), позволяющий оценить RTT соединения со стороны.

Лабораторная работа 16. HTTP на уровне байтов

• Раздел курса: тема 16 «HTTP и прикладные протоколы Веба»

Введение

В лабораторной работе 15 клиент получал от DNS адрес сервера; в настоящей работе исследуется то, что происходит после этого, — обмен сообщениями HTTP. Учебная площадка компании «Северный узел» состоит из клиента, обратного прокси и двух серверов-бэкендов в пространствах имён Linux. Серверы написаны на Python: один — на стандартном модуле http.server, другой — «вручную» на сокетах, чтобы весь путь от байтов в соединении TCP до ответа был виден в коде. Обратный прокси работает на nginx — основной вариант, как в промышленной эксплуатации, — либо, если nginx не установлен, на учебном прокси proxy.py с тем же поведением.

Работа повторяет логику темы 16. Сначала запросы составляются вручную и разбираются по байтам, затем исследуются методы, коды состояния и способы передачи тела, включая ошибку согласования длины, которая лежит в основе атаки контрабанды запросов. Далее изучаются кеширование с условными запросами, обратный прокси с балансировкой и заголовком X-Forwarded-For и влияние числа соединений на время загрузки страницы при искусственно увеличенной задержке. Завершает базовую часть сравнение HTTP/1.1 с HTTP/2 по числу соединений и проверка поддержки HTTP/3 у реальных сайтов.

Части 1–7 составляют базовую часть работы. Часть 8 (кеширующий прокси) — продвинутая, выполняется по желанию.

Цель работы

Освоить анализ и диагностику обмена по протоколу HTTP: формат сообщений, семантику методов и кодов, кеширование, работу обратного прокси и влияние версии протокола и числа соединений на производительность.

После выполнения работы можно будет:

• составить запрос HTTP/1.1 вручную, отправить его через nc и объяснить по захвату трафика границы сообщений в потоке TCP;
• определить по выводу curl -v метод, код состояния, заголовки и способ передачи длины тела и объяснить различие кодов 301, 304, 404, 405, 501, 502;
• разобрать ответ с кодированием chunked и показать, к чему приводит неверное значение Content-Length;
• выполнить условный запрос с If-None-Match и объяснить, когда сервер отвечает 304, а когда 200;
• настроить обратный прокси перед двумя бэкендами, проверить балансировку, отказоустойчивость и передачу адреса клиента, найти ошибку доверия заголовку X-Forwarded-For;
• измерить время загрузки страницы со многими ресурсами при разном числе соединений и объяснить результат через RTT;
• показать различие HTTP/1.1 и HTTP/2 по числу соединений и определить поддержку HTTP/3 у реального сайта.

Теоретический минимум

Модель Веба, URI и устройство сообщения — тема 16, раздел «Модель Веба и сообщение HTTP/1.1»; методы, коды, chunked и cookies — раздел «Семантика HTTP: методы, коды состояния, заголовки»; постоянные соединения и параллельная загрузка — раздел «Соединения HTTP/1.1 и производительность»; кеширование, прокси и балансировщики — раздел «Кеширование и промежуточные узлы»; HTTP/2, QUIC и HTTP/3 — раздел «HTTP/2 и HTTP/3».

Учебная топология. Узлы подключены к мосту br0 в пространстве sw, сеть 10.16.0.0/24. В пространстве cl файл /etc/netns/cl/hosts сопоставляет имя www.nsu.example адресу прокси.

Ресурсы бэкенда server.py: /hello — короткий текст с Content-Length; /chunked?n=5&ms=500 — ответ частями; /doc — документ с ETag, Last-Modified и Cache-Control: max-age=30; /doc/bump — изменить документ; /headers — эхо заголовков запроса; /cookie — счётчик посещений в сессии; /page?n=30 — HTML-страница с n картинками; /img/N.svg?ms=50 — картинка с искусственной задержкой; /old — перенаправление 301; POST /echo — эхо тела. Каждый ответ бэкенда содержит заголовок X-Backend с его именем. Сервер rawhttp.py нумерует запросы в пределах одного соединения TCP и отдаёт /stream частями.

Команды работы.

Полезные фильтры Wireshark: http, http.request.method == "GET", http.response.code == 304, tcp.stream == 3, http2, quic; команда «Follow → TCP Stream» показывает поток байтов соединения в обе стороны.

Перечень оснащения

• Ubuntu 24.04 (физическая или виртуальная машина либо WSL2) с правами sudo.
• Пакеты: sudo apt install iproute2 curl netcat-openbsd tcpdump wireshark python3 nginx-light. Пакет nginx-light необязателен: без него используется прокси на Python. После установки служба nginx в основной системе может быть остановлена командой sudo systemctl disable --now nginx — учебный экземпляр запускается отдельно в пространстве px. По желанию: nghttp2-client (утилита nghttp) для части 7.
• Архив окружения lr-env: скрипты up.sh, down.sh, серверы server.py, rawhttp.py, прокси proxy.py, конфигурация nginx.conf, загрузчик loadpage.py, README.md.
• Доступ в Интернет для части 7.

Порядок выполнения работы

Архив распаковывается в домашний каталог, команды выполняются из каталога lr-env. Площадка поднимается командой sudo ./up.sh --nginx (вариант с nginx) или sudo ./up.sh (прокси на Python) и разбирается командой sudo ./down.sh. Журналы — в каталоге run/: px.log (прокси; для nginx также run/nginx/access.log), web1.log, web2.log, rawhttp.log. В журнале работы указывается, какой вариант прокси использовался.

В начале работы определяется функция для запуска команд в пространстве клиента:

cl() { sudo ip netns exec cl "$@"; }

Перед экспериментами, где это требуется, в журнал записывается предсказание, затем наблюдение и объяснение расхождения.

Часть 1. Запрос HTTP вручную

Задание

1. Поднять площадку и запустить захват трафика клиента в файл:

   sudo ./up.sh --nginx            # или sudo ./up.sh
   sudo ip netns exec cl tcpdump -i eth0 -nn -w /tmp/lr16-raw.pcap tcp port 9000
   

2. В другом терминале отправить серверу на сокетах два запроса в одном соединении:

   printf 'GET / HTTP/1.1\r\nHost: web1\r\n\r\nGET / HTTP/1.1\r\nHost: web1\r\nConnection: close\r\n\r\n' | cl nc -q 3 10.16.0.11 9000
   

   Объяснить по ответам, сколько соединений TCP было открыто и почему сервер закрыл соединение после второго ответа. Найти в журнале run/rawhttp.log соответствующие строки.

3. Повторить запрос в виде HTTP/1.0 без заголовка Host: printf 'GET / HTTP/1.0\r\n\r\n'. Объяснить, какой заголовок появился в ответе и почему.

4. Остановить захват, открыть файл в Wireshark и командой «Follow → TCP Stream» показать поток первого соединения. Найти байты 0d 0a 0d 0a, отделяющие заголовки от тела, и объяснить, как получатель определяет конец каждого ответа. Подсчитать длину первого запроса в байтах по захвату и проверить подсчётом вручную.

5. Отправить на порт 8080 бэкенда web1 строку, не являющуюся запросом HTTP (printf 'HELLO\r\n\r\n'), и записать код ответа. Открыть rawhttp.py и найти функцию, которая читает заголовки; объяснить, что сделал бы этот сервер с такой строкой.

Что должно получиться

Ответы сервера из п. 2 и 3 с пояснениями; снимок «Follow TCP Stream» с отмеченными границами сообщений; расчёт длины запроса; код ответа из п. 5.

Часть 2. Методы, коды состояния и заголовки

Задание

1. Выполнить cl curl -v http://www.nsu.example/hello и разобрать вывод: строки, отправленные клиентом, полученные от сервера, комментарии curl. Объяснить, откуда в ответе взялись заголовки Server и X-Backend и почему значение Server не совпадает с тем, что выдаёт бэкенд напрямую (cl curl -sI http://10.16.0.11:8080/hello).

2. Предсказать код ответа и проверить для каждого запроса:

   cl curl -sI http://www.nsu.example/old
   cl curl -sIL http://www.nsu.example/old
   cl curl -s -o /dev/null -w '%{http_code}\n' http://www.nsu.example/nope
   cl curl -s -d 'name=nsu' http://www.nsu.example/echo
   cl curl -si -d 'x=1' http://www.nsu.example/hello
   cl curl -si -X PUT -d 'x=1' http://www.nsu.example/echo
   

   Объяснить различие кодов 405 и 501 в двух последних случаях: какой из них сформировало приложение, а какой — библиотека http.server, и что означает каждый.

3. Подсчитать длину тела ответа на /hello в символах и в байтах и сравнить с Content-Length. Объяснить расхождение.

4. Cookie и сессия. Трижды выполнить

   cl curl -s -b /tmp/cj -c /tmp/cj http://www.nsu.example/cookie
   

   Предсказать, как будет расти счётчик посещений. Сравнить с наблюдением, найти причину расхождения (подсказка: заголовок X-Backend и порядок обхода бэкендов). Затем выполнить те же запросы напрямую к web1 (http://10.16.0.11:8080/cookie) и показать, что механизм cookie работает. Предложить два способа исправить поведение за прокси; для варианта с nginx реализовать привязку клиента к бэкенду директивой ip_hash; в блоке upstream файла nginx.conf (директива метода балансировки должна стоять до строки keepalive 8;; после правки — sudo kill -HUP $(cat run/nginx.pid)) и проверить. Объяснить, почему не помогла бы директива hash $cookie_sid consistent;: кто и когда выдаёт идентификатор sid и что получит в этом поле прокси при первом запросе клиента.

Что должно получиться

Разобранный вывод curl -v; таблица «запрос — предсказанный код — полученный код — пояснение»; расчёт длины тела; объяснение поведения сессий за прокси и проверка исправления.

Часть 3. Длина тела: chunked и ошибка согласования длины

Задание

1. Получить ответ частями в «сыром» виде и в обычном:

   cl curl -s --raw 'http://www.nsu.example/chunked?n=3&ms=1000'
   cl curl -s 'http://www.nsu.example/chunked?n=3&ms=1000'
   

   Объяснить значение строк 22 и 0, перевести длину части в десятичную систему и проверить подсчётом байтов. Объяснить, почему части появляются на экране с интервалом в секунду, а не все сразу.

2. Запросить /stream у сервера на сокетах через nc, предварительно включив захват. По захвату определить, сколько сегментов TCP с данными пришло и с какими интервалами. Объяснить, почему в этом ответе нет заголовка Content-Length.

3. Эксперимент «рассогласование длины». Отправить серверу на сокетах один запрос POST, в котором тело короче, чем указано, и сразу за ним — строку, похожую на второй запрос:

   printf 'POST / HTTP/1.1\r\nHost: web1\r\nContent-Length: 5\r\n\r\nhelloGET /secret HTTP/1.1\r\nHost: web1\r\n\r\n' | cl nc -q 2 10.16.0.11 9000
   

   Предсказать, сколько ответов вернёт сервер. Сравнить с журналом run/rawhttp.log. Затем изменить Content-Length на 41 (подсчитать, почему именно 41 байт составляют hello и весь «второй запрос» вместе со всеми CRLF) и повторить. Объяснить, как это расхождение между тем, где кончается запрос «по мнению» прокси и «по мнению» бэкенда, используется в атаке контрабанды запросов.

4. Задать Content-Length: 100 при пятибайтовом теле и отправить запрос дважды: printf '…' | cl nc -q 2 10.16.0.11 9000 и (printf '…'; sleep 5) | cl nc -q 2 10.16.0.11 9000. Измерить время до ответа в обоих случаях (time). Объяснить, чего ждёт сервер, почему в первом случае он всё же отвечает сразу (подсказка: nc закрывает своё направление передачи после конца входных данных — полузакрытие соединения TCP, тема 12) и что получит сервер в функции read_request вместо тела.

Что должно получиться

Разобранный «сырой» ответ chunked; снимок захвата с интервалами сегментов; ответы и журнал сервера для трёх вариантов Content-Length с объяснением.

Часть 4. Кеширование и условные запросы

Задание

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

   cl curl -si http://www.nsu.example/doc
   

   Выписать ETag, Last-Modified и Cache-Control. Объяснить, сколько секунд клиент вправе использовать ответ без обращения к серверу.

2. Выполнить условный запрос с полученным значением ETag и предсказать код ответа:

   cl curl -si -H 'If-None-Match: "значение_ETag"' http://www.nsu.example/doc
   

   Подсчитать по захвату трафика (или по выводу curl -v) размер ответов 200 и 304 в байтах и объяснить, что именно сэкономлено, а что — нет.

3. Изменить документ (cl curl -s http://www.nsu.example/doc/bump) и повторить условный запрос со старым ETag. Объяснить результат. Учесть, что /doc на двух бэкендах ведётся независимо: документ изменился только на том бэкенде, который обработал /doc/bump. Повторить условный запрос несколько раз и объяснить, почему ответы чередуются, и какой вывод из этого следует для согласованности ETag в кластере серверов.

4. Выполнить условный запрос с заголовком If-Modified-Since, указав дату из Last-Modified, затем — дату на минуту раньше. Объяснить результаты. Почему при наличии обоих заголовков сервер должен руководствоваться If-None-Match?

5. Ответить письменно: как изменилось бы поведение браузера при Cache-Control: no-cache и при Cache-Control: no-store?

Что должно получиться

Таблица запросов «заголовки условия — код — размер ответа»; объяснение чередования ответов в п. 3; ответы на вопросы п. 4 и 5.

Часть 5. Обратный прокси, балансировка и X-Forwarded-For

Задание

1. Выполнить шесть запросов /hello через прокси и определить по заголовку X-Backend (или по телу ответа) алгоритм распределения. Сравнить с конфигурацией nginx.conf (блок upstream) или с функцией next_backends в proxy.py.

2. Запросить /headers через прокси и напрямую у бэкенда. Объяснить, какой адрес бэкенд видит как адрес клиента TCP в каждом случае и откуда он узнаёт настоящий адрес клиента. Записать захват на интерфейсе px (sudo ip netns exec px tcpdump -i eth0 -nn -w /tmp/lr16-px.pcap port 80 or port 8080) и показать в Wireshark два соединения TCP — «клиент — прокси» и «прокси — бэкенд» — для одного запроса.

3. Найти ошибку доверия. Отправить запрос с поддельным заголовком:

   cl curl -s -H 'X-Forwarded-For: 203.0.113.7' http://www.nsu.example/headers
   

   Предположим, что бэкенд ограничивает доступ к административному разделу по первому адресу в X-Forwarded-For. Объяснить, как клиент обойдёт ограничение, какой элемент списка можно считать достоверным и почему. Для варианта с nginx предложить изменение конфигурации, при котором прокси перезаписывает заголовок, а не дописывает к нему (proxy_set_header X-Forwarded-For $remote_addr;), применить его в обоих блоках server — для порта 80 и для порта 8081, иначе через HTTP/2 подмена останется возможной (после правки конфигурации — sudo kill -HUP $(cat run/nginx.pid), сигнал заставляет nginx перечитать файл) и проверить.

4. Сломать и починить. Остановить бэкенд web2 (sudo kill $(cat run/web2.pid)) и выполнить шесть запросов, измеряя код и время (-w '%{http_code} %{time_total}\n'). Найти в журнале прокси запись о недоступном бэкенде. Остановить и web1, повторить запрос и объяснить код ответа. Затем «подвесить» бэкенд: запустить вместо web2 процесс, который принимает соединения, но не отвечает (sudo ip netns exec web2 nc -lk 10.16.0.12 8080 >/dev/null &), запустить заново web1 (sudo ip netns exec web1 python3 server.py --addr 10.16.0.11 --port 8080 --name web1 &) и выполнить четыре запроса с измерением кода и времени. Выяснить, какой код и через какое время получает клиент, когда запрос попадает на «подвешенный» бэкенд, и найти в конфигурации прокси параметр, определяющий время ожидания. Если доступны оба варианта прокси, сравнить их: учебный прокси на Python в этом случае возвращает 504, а nginx по умолчанию повторяет идемпотентный запрос на другом бэкенде (директива proxy_next_upstream) и временно исключает отказавший сервер (параметры max_fails и fail_timeout); объяснить по измеренным временам, что произошло в каждом запросе. Объяснить различие кодов 502 и 504. Восстановить площадку (sudo ./down.sh && sudo ./up.sh --nginx).

Что должно получиться

Определённый алгоритм балансировки; снимок захвата с двумя соединениями; объяснение уязвимости и исправленная конфигурация; таблица «состояние бэкендов — код — время — запись в журнале».

Часть 6. Число соединений и время загрузки страницы

Задание

1. Добавить задержку 50 мс исходящим пакетам клиента:

   cl tc qdisc add dev eth0 root netem delay 50ms
   cl ping -c 3 10.16.0.1
   

   Определить RTT до прокси.

2. Страница /page?n=30 ссылается на 30 картинок. Используя модель из темы 16, предсказать время загрузки страницы со всеми картинками в трёх режимах: одно постоянное соединение; шесть постоянных соединений; одно соединение на каждый запрос. Затем измерить:

   cl python3 loadpage.py 'http://10.16.0.1/page?n=30' --conns 1
   cl python3 loadpage.py 'http://10.16.0.1/page?n=30' --conns 6
   cl python3 loadpage.py 'http://10.16.0.1/page?n=30' --conns 1 --no-keepalive
   

   Сравнить измерения с предсказаниями и объяснить расхождения.

3. Повторить измерение с картинками, «генерируемыми» сервером 100 мс (/page?n=30&ms=100), при одном и при шести соединениях. Объяснить, почему выигрыш от параллельных соединений изменился.

4. Построить график зависимости времени загрузки от числа соединений (1, 2, 3, 6, 10, 30) при задержке 50 мс и объяснить форму кривой. Почему браузеры ограничивают число соединений к одному серверу, а не открывают по соединению на каждый ресурс?

5. Снять задержку (cl tc qdisc del dev eth0 root) и повторить измерение с одним соединением. Объяснить, какая составляющая времени теперь преобладает.

Что должно получиться

Таблица «режим — предсказание — измерение»; график из п. 4; ответы на вопросы.

Часть 7. HTTP/2 и HTTP/3

Задание

1. HTTP/2 на учебной площадке (только вариант с nginx). Порт 8081 прокси принимает HTTP/2 без шифрования. Выполнить

   cl curl -v --http2-prior-knowledge http://10.16.0.1:8081/hello
   

   и найти в выводе номер потока и псевдозаголовки. Загрузить шесть картинок параллельно по HTTP/1.1 (порт 80) и по HTTP/2 (порт 8081):

   U=http://10.16.0.1/img/1.svg
   cl curl -s -Z -v -o /dev/null -o /dev/null -o /dev/null -o /dev/null -o /dev/null -o /dev/null \
     "$U?1" "$U?2" "$U?3" "$U?4" "$U?5" "$U?6" 2>&1 | grep -E 'Connected|Multiplex|< HTTP'
   

   (для HTTP/2 — тот же запрос с --http2-prior-knowledge и портом 8081). Подсчитать число соединений TCP в обоих случаях и подтвердить его захватом трафика. Если установлен nghttp, выполнить cl nghttp -nv http://10.16.0.1:8081/hello и найти в выводе кадры SETTINGS, HEADERS, DATA и номера потоков.

2. HTTP/2 у реального сайта (выполняется в основной системе, обязательно для варианта с прокси на Python). Повторить параллельную загрузку для документа https://www.rfc-editor.org/rfc/rfc9110.txt с ключами --http1.1 и --http2 и подсчитать соединения. Найти в выводе строки о согласовании протокола через ALPN.

3. HTTP/3. Проверить, поддерживает ли установленный curl HTTP/3 (curl --version | grep -i http3). Независимо от результата определить для трёх-четырёх крупных сайтов (например, www.cloudflare.com, www.google.com, www.youtube.com, www.nsu.ru) поддержку HTTP/3 двумя способами: по заголовку alt-svc в ответе (curl -sI https://…) и по записи DNS типа HTTPS (dig HTTPS имя +short). Если curl поддерживает HTTP/3, выполнить curl -sI --http3 https://www.cloudflare.com/; иначе открыть сайт в браузере, в инструментах разработчика включить столбец «Protocol» на вкладке «Network» и найти значение h3.

4. Ответить письменно: почему HTTP/2 по одному соединению TCP при потерях пакетов может работать хуже, чем шесть соединений HTTP/1.1, и как эту проблему решает QUIC? Почему браузер не может сразу начать с HTTP/3, не узнав о нём заранее?

Что должно получиться

Подсчёт соединений для HTTP/1.1 и HTTP/2 со снимком захвата; таблица «сайт — alt-svc — запись HTTPS — HTTP/3 да/нет»; ответы на вопросы п. 4.

Часть 8. Кеширующий обратный прокси

Продвинутая часть.

Задание

Доработать учебный прокси proxy.py, превратив его в общий кеш по правилам RFC 9111 в упрощённом виде.

1. Сохранять ответы 200 на запросы GET, если в ответе есть Cache-Control: max-age=N и нет no-store и private; ключ кеша — путь с запросом.

2. Пока ответ свежий, отдавать его клиенту из кеша без обращения к бэкенду, добавляя заголовок Age с возрастом ответа в секундах и X-Cache: HIT; при промахе — X-Cache: MISS.

3. Когда ответ устарел, а в нём был ETag, выполнять к бэкенду условный запрос с If-None-Match; при ответе 304 обновлять время сохранения и отдавать клиенту сохранённое тело с кодом 200.

4. Проверить на ресурсе /doc (max-age=30): серия запросов в течение 60 с должна дать сначала MISS, затем HIT с растущим Age, затем условный запрос к бэкенду, видимый в его журнале как ответ 304. Объяснить, почему после /doc/bump клиенты до 30 с получают старую версию и как этим управлять.

5. Объяснить, почему кеширование ответа /cookie в общем кеше было бы ошибкой и какие заголовки ответа должен ставить сервер, чтобы её предотвратить.

Что должно получиться

Изменения в коде (diff); журнал прокси и бэкенда для сценария п. 4 с заголовками Age и X-Cache; ответы на вопросы п. 4 и 5.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Таблицы, графики и файлы захватов, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце полезно сформулировать несколько предложений собственных выводов по работе.

Контрольные вопросы

1. Как получатель определяет конец сообщения HTTP/1.1 в потоке TCP? Перечислите все способы и укажите, какой из них не позволяет переиспользовать соединение.
2. Почему метод PUT идемпотентен, а POST — нет? К каким практическим последствиям это приводит при обрыве соединения?
3. Чем коды 502 и 504 отличаются от 500? Какой узел цепочки формирует каждый из них?
4. Почему одно и то же значение Content-Length может по-разному толковаться прокси и бэкендом и чем это опасно?
5. В чём разница между Cache-Control: no-cache и no-store? Что экономит ответ 304 и чего он не экономит?
6. Почему балансировка «по кругу» ломает серверные сессии и какие есть способы это исправить?
7. Какой элемент заголовка X-Forwarded-For можно считать достоверным и при каком условии?
8. Почему время загрузки страницы со многими мелкими ресурсами почти не зависит от пропускной способности канала?
9. Что такое блокировка начала очереди? Где она возникает в HTTP/1.1, в HTTP/2 и почему её нет между потоками в HTTP/3?
10. Как клиент узнаёт, что сервер поддерживает HTTP/2 и HTTP/3?
11. Чем балансировщик уровня L4 отличается от балансировщика уровня L7? Какой из них может направлять запросы по пути URL?
12. Зачем в QUIC идентификатор соединения и что он даёт мобильному клиенту?