Откройте любую статью с обзором HTTP/1.1. Скорее всего, там найдётся хотя бы один пример запроса и ответа, допустим, такие:
GET / HTTP/1.1
Host: localhostHTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Content-Length: 38
Content-Type: text/html; charset=utf-8
<!DOCTYPE html>
<h1>Привет!</h1>Теперь откройте статью с обзором HTTP/2 или HTTP/3. Вы узнаете о мультиплексировании запросов, о сжатии заголовков, о поддержке push-технологий, но вряд ли увидите хоть одно конкретное сообщение. Ясно, почему так: HTTP/1.1 — текстовый протокол, тогда как сиквелы к нему бинарные. Это очевидное изменение открывает дорогу ко множеству оптимизаций, но упраздняет возможность просто и доступно записать сообщения.
Поэтому в этой статье предлагаю покопаться в кишках у HTTP/2: разобрать алгоритмы установки соединения, формат кадров, примеры взаимодействия клиента с сервером.
Статья рассчитана как на давно знакомых с HTTP, так и начинающих фронтендеров недавно изучивших HTTP/1.1, и пытающихся осознать, что там с HTTP/2. Естественно, я не могу описывать все подробности, поэтому новичкам в сетевых технологиях для лучшего понимания материала предлагается ознакомиться хотя бы с тем, как работает стек TCP/IP. Для этого очень рекомендую плейлист Networking tutorial на канале Ben Eater. Кроме того, как увидим далее, HTTP/2 на практике работает только поверх защищённого соединения (https), поэтому рекомендуется что-то в общих чертах понимать про TLS.
Спецификация HTTP/2 описана в RFC 9113 — здесь нужно искать все подробности о протоколе. Также пару раз я буду ссылаться на устаревшую спецификацию — RFC 7540. Она не актуальна, но для исторической справки бывает полезна. Плюс на ней были основаны большинство реализаций серверов, так что если вам доведётся с ними работать, возможно, пересечётесь с какими-нибудь отголосками прошлого.
Немножко терминологии
Далее везде
- Клиент — программа, реализующая клиентскую часть протокола.
- Сервер — программа, реализующая серверную часть протокола.
- Стороны — клиент и/или сервер.
- Собеседник — когда речь идёт о клиенте, это сервер; когда о сервере — клиент.
Кроме того, все числа с приставкой 0x — шестнадцатеричные, с 0b — двоичные, без приставки — десятичные, кроме блоков с представлением кадров в памяти. Также в блоках кода # отделяет комментарии.
Вспомним былое
Что значит фраза "HTTP/1.1 — текстовый протокол"? То, что все служебные данные являются простыми строками. Клиент, отправляя запрос, записывает метод, путь и заголовки в виде строки ASCII в своей памяти, и затем отправляет по сети получившиеся байты. Например, запрос из начала статьи в памяти и при передаче по сети, выглядит так:
47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 # GET / HTTP/1.1
0d 0a # \r\n
48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f 73 74 # Host: localhost
0d 0a 0d 0a # \r\n\r\nТело же сообщения — просто какой-то набор байтов, а то, как их следует интерпретировать, указано в заголовке Content-Type. Например, в ответе из начала статьи указано Content-Type: text/html; charset=utf-8. Это значит, что тело представляет собой разметку html, передаваемую в кодировке UTF-8. Если не указать атрибут charset, браузеру ничего не останется, кроме как попытаться угадать кодировку самостоятельно (спойлер: вряд ли угадает).
# Строка ответа и заголовки в ASCII
48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b # HTTP/1.1 200 OK
0d 0a # \r\n
44 61 74 65 3a 20 53 61 74 2c 20 30 39 20 4f 63 74 20 # Date: ...
32 30 31 30 20 31 34 3a 32 38 3a 30 32 20 47 4d 54
0d 0a # \r\n
53 65 72 76 65 72 3a 20 41 70 61 63 68 65 # Server: Apache
0d 0a # \r\n
43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 33 38 # Content-Length: 38
0d 0a # \r\n
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 # Content-Type:
74 65 78 74 2f 68 74 6d 6c 3b 20 # text/html;
63 68 61 72 73 65 74 3d 75 74 66 2d 38 # charset=utf-8
0d 0a 0d 0a # \r\n\r\n
# Заголовки закончились, дальше идёт тело в UTF-8 (как указано в Content-Type)
3c 21 44 4f 43 54 59 50 45 20 68 74 6d 6c 3e 0a # <!DOCTYPE html>\n
3c 68 31 3e d0 9f d1 80 d0 b8 d0 b2 d0 b5 d1 82 21 3c 2f 68 31 3e # <h1>Привет!</h1>Можно обратить внимание, что в теле 32 символа (включая один перевод строки), но в заголовках написано Content-Length: 38. Это связано с тем, что Content-Length содержит длину тела в октетах, а не символах. А так как тело записано в UTF-8, некоторые символы (а именно 6 кириллических в слове Привет) занимают больше одного октета. То есть HTTP вообще не имеет особого понятия, что написано в теле, с точки зрения протокола это просто какой-то набор байтов. Смысл в этот набор вкладывают приложения (клиент и сервер) с помощью подсказок в заголовках.
HTTP/2
Перейдём к виновнику торжества. Развлекательная программа следующая: сначала рассмотрим основные абстракции, которыми оперирует HTTP/2. Затем посмотрим на то, какие существуют кадры, и какое у них назначение. В заключение, разберём, как происходит обмен сообщениями.
Основные абстракции
В HTTP/1.1 по большому счёту была одна сущность — сообщение. Клиент и сервер обменивались сообщениями, которые бывали двух видов: запросы и ответы. Внутри TCP-соединения они чередовались: клиент отправляет запрос, ждёт на него ответ, затем отправляет следующий.
Одной из задач HTTP/2 же стало мультиплексировать запросы, то есть позволить клиенту отправить второе сообщение-запрос по тому же TCP-соединению, не дожидаясь ответа на первый. В такой схеме клиенту при получении сообщения от сервера нужно как-то узнать, на какой из запросов это ответ. Очевидный способ — клиенту генерировать для каждого сообщения идентификатор и, например, отправлять его в условном заголовке Request-Id, а серверу указывать этот же идентификатор в заголовках ответа. Однако есть ещё одна проблема: сейчас мы отправляем каждое сообщение целиком. Если первый запрос уже начал отправляться, то второй должен будет дождаться конца передачи. Если первый запрос очень большой и менее приоритетный, чем второй, получается неловкая ситуация. Хотелось бы иметь возможность дробить сообщения на более мелкие куски, тогда можно было бы, чередуя их, отправлять несколько сообщений параллельно.
Из этих соображений в HTTP/2 возникают следующие абстракции:
- Сообщения (messages) — запросы и ответы, всё как в HTTP/1.1. Состоят из заголовков и (необязательно) тела и трейлеров. Дробятся на более мелкие составные части — кадры.
- Кадр (frame) — простейшая единица обмена информацией, передаются целиком (нельзя начать передавать второй кадр, пока полностью не передался один). Бывают разных типов, в зависимости от чего чуть отличается их содержимое. Есть служебные кадры, например, для управления соединением и потоками; есть кадры, из которых составляются сообщения.
Замечание для самых смышлёных: кадры HTTP никак не связаны с пакетами TCP. Один пакет может содержать несколько кадров, один кадр может начинаться и заканчиваться в разных пакетах.
- Поток (stream) — последовательность кадров, составляющих один запрос и ответ на него. Тогда как предыдущие абстракции имеют физическое представление (каждый кадр — это последовательность октетов1 в определённом формате, а сообщение — некоторый набор кадров), потоки существуют только в наших
сердцахмыслях. В каждом кадре есть поле с идентификатором потока, соответственно все кадры с одинаковым идентификатором считаются принадлежащими одному потоку.
Новый поток может создать как клиент (отправив запрос с идентификатором, который не использовался ранее), так и сервер (если используется server push). По одному потоку можно передать только одну пару сообщений: после того, как получено сообщение-ответ, поток считается закрытым, и по нему больше нельзя ничего передавать (то есть если одна из сторон получает кадр с идентификатором потока, который закрыт, она либо его игнорирует, либо закрывает соединение с ошибкой).
1 Так как по определению (по крайней мере изначальному) байт не обязательно состоит из восьми бит, а октет — обязательно, то при обсуждении сетевых протоколов принято использовать именно октет. И я буду, чем я хуже.
Раздел кадров
Каждый кадр условно делится на заголовок (header, не путать с заголовками сообщения) и содержимое (payload). Заголовок содержит общую информацию о кадре, и одинаковый у них всех, а содержимое уже зависит от конкретного типа. Формат такой:
HTTP Frame {
# Заголовок
Length (24),
Type (8),
Flags (8),
Reserved (1),
Stream Identifier (31),
# Содержимое
Frame Payload (..),
}Здесь
Length(24 бита/3 октета) — длина кадра в октетах, не включая заголовок. Читатель, слышавший что-то об арифметике, заметит, что длина заголовка — 9 октетов, так что длина всего кадра отличается от значенияLengthровно на 9.Type(8 бит/1 октет) — тип кадра. Например, значение 0x00 значит, что это кадр DATA, а 0x04 — кадр SETTINGS.Flags(8 бит/1 октет) — набор булевых флагов. Каждый из восьми бит может быть 0 или 1, получается восемь флагов, которые можно устанавливать независимо. Доступные флаги зависят от типа кадра, так что о них будем говорить, обсуждая конкретные типы.Reserved(1 бит) — не используется, всегда равен 0.Stream Identifier(31 бит/почти 4 октета) — идентификатор потока, которому принадлежит кадр. Чтобы создать новый поток, клиент отправляет кадр (определённого типа, увидим позже) со значениемStream Identifier, которое не использовалось ранее. Чтобы отправить кадр по конкретному потоку, туда пишется соответствующий идентификатор. Есть кадры, которые относятся не к конкретному потоку, а к соединению в целом — для них используется зарезервированный идентификатор потока0.Frame Payload(Lengthоктетов) — содержимое, зависит от типа кадра.
Рассмотрим конкретные типы кадров и их назначения. В скобках после названия указан идентификатор типа (значение поля Type в заголовке). Здесь приведены типы в порядке не по возрастанию идентификатора, а по зову сердца.
HEADERS (0x01) и CONTINUATION (0x09)
Вернёмся к сообщениям. В HTTP/1.1 они состояли из трёх основных частей: заголовков (включая строку запроса/ответа) и (необязательно) тела и трейлеров. В HTTP/2 части те же, но передаются с помощью двух типов кадров: HEADERS и DATA.
Сначала посмотрим на заголовки и трейлеры. Несмотря на название, и для того, и для того используется кадр HEADERS, который имеет такой формат, самый сложный из основных кадров:
HEADERS Frame {
Length (24),
Type (8) = 0x01,
Unused Flags (2),
PRIORITY Flag (1), # Устарело
Unused Flag (1),
PADDED Flag (1),
END_HEADERS Flag (1),
Unused Flag (1),
END_STREAM Flag (1),
Reserved (1),
Stream Identifier (31),
[Pad Length (8)],
[Exclusive (1)], # Устарело
[Stream Dependency (31)], # Устарело
[Weight (8)], # Устарело
Field Block Fragment (..),
Padding (..2040),
}Первые 9 октетов — стандартный для всех кадров заголовок. Содержимое состоит из так называемого "блока заголовков" (header block, здесь уже речь о заголовках сообщения, а не кадра) и дополнения (padding). Вообще говоря, в новой спецификации используется термин "блок полей" (field block), а не "блок заголовков". Это связано как раз с тем, что HEADERS используется для передачи не только заголовков, но и трейлеров, поэтому говорить "блок заголовков" не совсем корректно. Но, я считаю, название "блок полей" может сбить с толку, поэтому дальше везде буду говорить только о заголовках и подразумевать, что всё что здесь описано, применимо и к трейлерам.
Флаг PRIORITY, как и значения Exclusive, Stream Dependency и Weight в содержимом, — останки механизма приоритизации потоков, который был предложен в первой итерации HTTP/2. На практике он оказался довольно сложным, и большинство клиентов и серверов либо вообще его не реализовали, либо реализовали очень неоптимально. Поэтому этот механизм и все сопутствующие части кадров в новой спецификации были признаны устаревшими, и предложен новый механизм приоритизации на основе заголовков и специальных кадров PRIORITY_UPDATE, который описан отдельно (RFC 9218). Его разбирать здесь не будем.
Если установлен флаг PADDED, первые 8 бит/1 октет в содержимом указывают длину дополнения (Pad Length), а само дополнение идёт в конце кадра, после заголовков. Дополнение представляет собой просто Pad Length нулевых октетов. Оно используется в качестве меры безопасности в дополнение к шифрованию — если нужно скрыть истинную длину заголовков.
Гвоздь кадра — блок заголовков. Заголовки передаются в сжатом с помощью алгоритма HPACK (RFC 7541) виде. Алгоритм довольно хитрый, так что подробно разбирать здесь его не будем. Вместо этого в примерах я буду записывать заголовки и трейлеры самым простым (по совместительству неэффективным) способом, каким позволяет HPACK.
У меня есть сомнения, можно ли кодировать заголовки, для которых есть сокращённые формы записи (например, accept в HPACK, вообще говоря, можно кодировать всего одним октетом 0x13 плюс сколько-то байт на значение), не используя эти сокращённые формы, то есть полностью выписывая название заголовка в ASCII.
В спецификации HPACK я не нашёл раздела, где такой способ бы был запрещен или хотя бы не рекомендован. Тем не менее, судя по всему, некоторые реализации его не поддерживают. В моих тестах самописный HTTP/2 сервер на NodeJS (использующий встроенную библиотеку node:http2, которая, в свою очередь, использует C++ библиотеку nghttp2) вполне себе замечательно обрабатывает заголовки, записанные таким образом. А сервера гугла при попытке отправить заголовки в таком виде возвращают ошибку сжатия. Но пока меня не ткнут носом, где написано, что так кодировать нельзя, буду использовать эту простую схему.
Сначала пишется один нулевой октет. Далее один октет — длина названия заголовка (только старший бит длины должен быть 0, но это детали) и само название в ASCII, затем длина значения и само значение тоже в ASCII. Все названия заголовков в HTTP/2 пишутся в нижнем регистре. Рассмотрим конкретный пример кадра HEADERS для наглядности:
00 00 4b 01 # Длина содержимого 0x00004b=75 октетов, тип HEADERS (0x01)
05 # Установлены флаги END_HEADERS и END_STREAM (6й и 8й биты, 0x05=0b0000 0101)
00 00 00 01 # Идентификатор потока 1
00 # Начинаются заголовки. Сначала нулевой октет
07 3a 6d 65 74 68 6f 64 # Длина названия 7 октетов, само название ":method" записано в ASCII
03 47 45 54 # Длина значения 3 октета, значение "GET"
00 # Начало второго заголовка
07 3a 73 63 68 65 6d 65 # Длина 7, название ":scheme"
05 68 74 74 70 73 # Длина 5, значение "https"
00
05 3a 70 61 74 68 # Название ":path"
01 2f # Значение "/"
00
0a 3a 61 75 74 68 6f 72 69 74 79 # Название ":authority"
09 6c 6f 63 61 6c 68 6f 73 74 # Значение "localhost"
00
04 68 6f 73 74 # Название "host"
09 6c 6f 63 61 6c 68 6f 73 74 # Значение "localhost" Только что мы невольно лицезрели простейший запрос в HTTP/2, аналогичный запросу HTTP/1.1 из самого начала статьи. Сразу бросаются в глаза заголовки, начинающиеся с двоеточия. Это так называемые псевдозаголовки. Они содержат в том числе данные, которые в HTTP/1.1 передавались в строке запроса. Невероятно, но :method — это метод, :path — путь. :scheme — схема URI, на который поступает запрос, обычно это https (браузеры не поддерживают использование HTTP/2 по http, это ещё обсудим позднее), :authority — имя сервера, на который поступает запрос, грубо говоря то, что в HTTP/1.1 указывалось в заголовке Host. Заголовок host однако, как видно в примере, в HTTP/2 тоже есть, только теперь не обязателен. Чем отличается от :authority позволю себе здесь не обсуждать.
Псевдозаголовки чуть отличаются от обычных заголовков, например, они обязательно должны идти первыми. Кому интересны подробности, тот почитает спецификацию. Ответы тоже не обделили псевдозаголовками, правда, он всего один: :status — код статуса. Простейший пример ответа в HTTP/2:
00 00 0d 01 # Длина содержимого 0x0d=13, тип кадра HEADERS
05 00 00 00 01 # Флаги END_HEADERS и END_STREAM, идентификатор потока 1
00
07 3a 73 74 61 74 75 73 # Псевдозаголовок ":status"
03 32 30 34 # Значение "204"Постоянно писать байты не удобно, поэтому кадры будем записывать в более простом виде, указывая только тип, установленные флаги и содержимое. После типа кадра через черту будем писать номер потока, по которому кадр отправляется:
# Запрос
HEADERS/1
+ END_HEADERS
+ END_STREAM
:method = GET
:scheme = https
:path = /
:authority = localhost
host = localhost
# Ответ
HEADERS/1
+ END_HEADERS
+ END_STREAM
:status = 204Вот и вышел простейший обмен сообщениями (предполагая, что стороны уже обменялись всеми необходимыми рукопожатиями. Конкретно о том, что должно произойти до обмена сообщениями, речь пойдёт позже).
Осталось что-то сказать про флаги END_HEADERS и END_STREAM. Бывают ситуации (например, большие файлы куки), когда заголовков нужно отправить очень много, и они не влезают в максимально разрешённый размер кадра (такой есть, им можно управлять с помощью кадров SETTINGS). В таком случае можно разбить их на несколько частей. Первую часть отправить в кадре HEADERS, а оставшиеся в одном или нескольких кадрах CONTINUATION, которые выглядят почти также, только проще:
CONTINUATION Frame {
Length (24),
Type (8) = 0x09,
Unused Flags (5),
END_HEADERS Flag (1),
Unused Flags (2),
Reserved (1),
Stream Identifier (31),
Field Block Fragment (..),
}Флаг END_HEADERS нужен, чтобы обозначить, где заканчиваются заголовки. Он устанавливается на последнем кадре CONTINUATION, либо на самом кадре HEADERS, если CONTINUATION не требуются. Стоит отметить, что кадр HEADERS и соответствующие CONTINUATION должны идти подряд: между ними не может быть других кадров, даже из других потоков. Это связано с особенностями HPACK, которые, возможно, обсудим в другой раз.
Флаг END_STREAM обозначает последний кадр сообщения. Так как по одному потоку можно отправить только одно сообщение с каждой стороны, то после отправки такого кадра сторона больше не может передавать по потоку данные. Если сообщение состоит только из заголовков, этот флаг стоит на первом кадре HEADERS; если из заголовков и тела — на последнем кадре DATA; если из заголовков, тела и трейлеров — на последнем кадре HEADERS, который содержит трейлеры.
DATA (0x00)
Используется для передачи тела сообщения. Формат простой:
DATA Frame {
Length (24),
Type (8) = 0x00,
Unused Flags (4),
PADDED Flag (1),
Unused Flags (2),
END_STREAM Flag (1),
Reserved (1),
Stream Identifier (31),
[Pad Length (8)],
Data (..),
Padding (..2040),
}Ситуация с дополнением (padding) точно такая же, как в кадрах HEADERS. С END_STREAM уже разобрались, поэтому без лишних слов посмотрим на более сложный пример сообщения.
HEADERS/1
+ PADDED
:status = 200
date = Sat, 09 Oct 2010 14:28:02 GMT
server = apache
<4 октета дополнения>
CONTINUAION/1
+ END_HEADERS
content-type = text/html; charset=utf-8
DATA/1
<!DOCTYPE html>\n
DATA/1
+ PADDED
+ END_STREAM
<h1>Привет!</h1>
<8 октетов дополнения># Первый кадр
00 00 45 01 # Длина содержимого 0x45=73 октета, тип HEADERS
08 00 00 00 01 # Флаг PADDED, поток 1
04 # Длина дополнения 4 октета
00
07 3a 73 74 61 74 75 73 # Псевдозаголовок ":status"
03 32 30 30 # Значение "200"
00
04 64 61 74 65 # Заголовок "date", значение "Sat, 09 Oct...."
1d 53 61 74 2c 20 30 39 20 4f 63 74 20 32 30
31 30 20 31 34 3a 32 38 3a 30 32 20 47 4d 54
00
06 73 65 72 76 65 72 # Заголовок "server"
06 61 70 61 63 68 65 # Значение "apache"
00 00 00 00 # 4 октета дополнения (padding)
# Второй кадр
00 00 27 09 # Длина содержимого 0x27=39 октетов, тип CONTINUATION
04 00 00 00 01 # Флаг END_HEADERS, поток 1
00
0c 63 6f 6e 74 65 6e 74 2d 74 79 70 65 # Заголовок "content-type",
18 74 65 78 74 2f 68 74 6d 6c 3b 20 63 # Значение "text/html; charset=utf-8"
68 61 72 73 65 74 3d 75 74 66 2d 38
# Третий кадр
00 00 10 00 # Длина содержимого 0x10=16 октетов, тип DATA
00 00 00 00 01 # Флагов нет, поток 1
3c 21 44 4f 43 54 59 50 # Строка "<!DOCTYPE html>\n" в UTF-8
45 20 68 74 6d 6c 3e 0a
# Четвёртый кадр
00 00 1f 00 # Длина содержимого 0x1f=31 октет, тип DATA
09 00 00 00 01 # Флаги PADDED и END_STREAM, поток 1
08 # Длина дополнения 8 октетов
3c 68 31 3e d0 9f d1 80 d0 b8 d0 # Строка "<h1>Привет!</h1>" в UTF-8
b2 d0 b5 d1 82 21 3c 2f 68 31 3e
00 00 00 00 00 00 00 00 # 8 октетов дополненияЭто сообщение, аналогичное примеру ответа из начала статьи. Только я разбил заголовки и тело на несколько кадров как мне вздумалось, чтобы жизнь мёдом не казалась.
Забавный факт: в ответе нет ни заголовка Content-Length, ни Transfer-Encoding: chunked. Так как в TCP данные идут потоком, а HTTP передаёт вполне себе ограниченные по длине сообщения, нужен какой-то способ узнать, где они заканчиваются. В HTTP/1.1 конец заголовков можно было определить по последовательности символов \r\n\r\n, а конец тела (ответа, по крайней мере) узнавали одним из двух способов: либо тело закончилось, когда сервер закрыл TCP-соединение, либо его длина указывалась явно с помощью одного из упомянутых заголовков. В HTTP/2 же в заголовке каждого кадра и так указана его длина, а последний кадр сообщения имеет флаг END_STREAM. Так что найти конец сообщения не составляет труда, соответственно Content-Length и Transfer-Encoding: chunked становятся необязательными.
SETTINGS (0x04)
Используется для установки параметров соединения. Формат такой:
SETTINGS Frame {
Length (24),
Type (8) = 0x04,
Unused Flags (7),
ACK Flag (1),
Reserved (1),
Stream Identifier (31) = 0,
Setting (48) ...,
}
Setting {
Identifier (16),
Value (32),
}Потоки не имеют настраиваемых параметров, SETTINGS применяется только к соединению в целом, так что идентификатор потока всегда 0. В содержимом перечисляются параметры, которые нужно изменить. Каждый параметр занимает 48 бит/6 октетов, из которых 2 октета — идентификатор, а остальные 4 — значение. Рассмотрим некоторые параметры в качестве примера. Список не полный, полный список и ссылки на спецификации, где параметры описаны, нужно искать на сайте IANA.
- SETTINGS_ENABLE_PUSH (идентификатор 0x02) — клиент может установить значение 0, чтобы запретить использование server push. Эту технологию оказалось довольно сложно использовать с толком, поэтому, например, хромиум всегда так делает.
- SETTINGS_MAX_CONCURRENT_STREAMS (0x03) — максимальное количество потоков, которое собеседнику разрешается использовать одновременно. Считаются только открытые потоки, то есть по которым что-то ещё передаётся. Можно указать значение 0: тогда собеседник не сможет отправлять новые сообщения, пока сторона его снова не увеличит.
- SETTINGS_INITIAL_WINDOW_SIZE (0x04) — элемент управления потоком (flow control). Подробнее в разделе про кадры WINDOW_SIZE.
- SETTINGS_MAX_FRAME_SIZE (0x05) — максимальный размер кадра в октетах, который собеседнику разрешено отправлять. Значение по умолчанию, оно же минимальное — 16 384=214 октетов.
- SETTINGS_NO_RFC7540_PRIORITIES (0x09) — можно установить значение 1, чтобы запретить использование той самой неудачной системы приоритизации из первой итерации HTTP/2.
Часто важно знать, получил и применил ли собеседник их новые значения. Для этого каждая сторона после получения SETTINGS отправляет в ответ ещё один такой кадр, на котором установлен единственный доступный для этого типа флаг ACK (acknowledged). Например, сервер отправил кадр SETTINGS и указал, что максимальное количество потоков, которые он готов одновременно обрабатывать (SETTINGS_MAX_CONCURRENT_STREAMS), равно 100. Как только клиент его получит, он должен запомнить новое значение параметра, и отправить в ответ пустой кадр SETTINGS с флагом ACK. Пока сервер не получил это подтверждение, он не может быть уверен, что клиент узнал о новом значении параметра, поэтому не может рассчитывать, что клиент не откроет больше 100 потоков.
Пример такого обмена:
# Сервер отправляет клиенту
SETTINGS/0
SETTINGS_ENABLE_PUSH = 0
SETTINGS_MAX_CONCURRENT_STREAMS = 100
# Клиент отправляет в ответ
SETTINGS/0
+ ACK# Сервер клиенту
00 00 0c 04 # Длина содержимого 0x0c=12 октетов, тип SETTINGS
00 00 00 00 00 # Флагов нет, поток 0
00 02 00 00 00 00 # Параметру SETTINGS_ENABLE_PUSH (идентификатор 0x0002) установить значение 0
00 03 00 00 00 64 # Параметру SETTINGS_MAX_CONCURRENT_STREAMS (0x0003) установить значение 100 (0x64)
# Клиент серверу
00 00 00 04 # Длина содержимого 0 (пустой кадр), тип SETTINGS
01 00 00 00 00 # Флаг ACK, поток 0PING (0x06)
Пока не происходит обмена сообщениями, клиент и сервер периодически обмениваются такими кадрами, чтобы проверить, не закрылось ли соединение, жив ли собеседник. Также с помощью них можно оценивать круговую задержку (round-trip time): сколько времени нужно, чтобы отправить кадр и получить на него ответ. Формат:
PING Frame {
Length (24) = 0x08,
Type (8) = 0x06,
Unused Flags (7),
ACK Flag (1),
Reserved (1),
Stream Identifier (31) = 0,
Opaque Data (64),
}Содержимое состоит из 64 бит/8 октетов произвольных данных (Opaque Data). Сами по себе они ничего не значат, но если одна из сторон получает кадр PING, она должна отправить в ответ ещё один PING с флагом ACK и продублировать содержимое.
# Клиент отправляет серверу
00 00 08 06 # Длина содержимого 8 октетов, тип PING
00 00 00 00 00 # Флагов нет, поток 0
2f b0 7a ee # 8 произвольных, ничего не значащих октетов
92 01 8a bc
# Сервер отвечает
00 00 08 06 # Длина содержимого 8 октетов, тип PING
01 00 00 00 00 # Флаг ACK, поток 0
2f b0 7a ee # Продублировано из предыдущего кадра
92 01 8a bcWINDOW_UPDATE (0x08)
Во многих сетевых протоколах, в том числе TCP и HTTP, обработка данных происходит не мгновенно по прибытии. Операционная система, получая сетевые пакеты, складывает их в некоторый буфер, из которого приложение потом может их считать сразу или через какое-то время. Из-за этого возникает необходимость в некотором механизме управления потоком (flow control): нельзя отправлять слишком много данных сразу — если они обрабатываются медленно, у собеседника может банально не хватить памяти всё сохранить для последующей обработки.
Самые большие кадры в HTTP — это кадры DATA, поэтому flow control применяется только к ним. Все остальные кадры обычно не слишком большие, поэтому обрабатываются сразу. Разве что HEADERS могут быть приличного размера, но их обработку очень нежелательно откладывать в том числе из-за пресловутых особенностей HPACK. За то, чтобы не отправить слишком много заголовков, отвечает механизм flow control, который уже есть в TCP.
У каждого потока и у соединения в целом есть "размер окна" (window size) — максимальное количество октетов, которые собеседнику разрешено отправить в данный момент на данном потоке/соединении. С каждым полученным кадром DATA размер окна уменьшается на размер его содержимого. Если отправить слишком много, размер окна станет слишком маленьким, и сторона откажется принимать новые кадры. Размер окна свой у клиента и у сервера.
Когда же сторона обработает полученные ранее данные и решит, что готова получать новые, она отправит кадр WINDOW_UPDATE, в котором увеличит свой размер окна, и позволит собеседнику отправлять новые кадры. Формат такой:
WINDOW_UPDATE Frame {
Length (24) = 0x04,
Type (8) = 0x08,
Unused Flags (8),
Reserved (1),
Stream Identifier (31),
Reserved (1),
Window Size Increment (31),
}Тело состоит из 4 октетов (только старший бит не используется), которые указывают, на сколько надо увеличить размер окна.
Изначальный размер окна задаётся параметром SETTINGS_INITIAL_WINDOW_SIZE, по умолчанию 65 535 октетов. Предположим, сервер отправил кадр размером 65 500 октетов:
00 ff dc 00 # Размер 0xffdc=65 500 октетов, тип DATA
00 00 00 00 01 # Флагов (в частности, END_STREAM) нет, поток 1
1a 2b 3c 4d... # Куча данных на 65 500 октетовИ теперь хочет отправить ещё столько же. Но размер окна сервера только что уменьшился на 65 500 и стал 35 октетов, то есть ещё один такой же кадр не поместится. Поэтому сервер не может отправить его сразу же, он должен подождать некоторое время. Когда клиент получит первый кадр и обработает его, он отправит, например, такой WINDOW_UPDATE:
00 00 04 08
00 00 00 00 01
00 00 ff ffТаким образом, увеличив размер окна для потока 1 ещё на 65 535 октетов. То есть после отправки этого кадра размер окна клиента станет 65 570 октетов. Rогда сервер получит этот WINDOW_UPDATE, он узнает, что размер окна клиента увеличился, и сможет отправить следующий кадр DATA.
Ещё замечание юридического характера: я не нахожу в спецификации места, где было бы оговорено, нужно ли увеличивать в этом сценарии размер окна для соединения в целом и для потока 1 двумя отдельными WINDOW_UPDATE, или же увеличение окна потока 1 автоматически увеличивает окно всего соединения. В моих тестах с самодельным HTTP/2 сервером на NodeJS и серверами гугла выглядит, как будто достаточно одного кадра, который увеличивает окно только для потока 1.
RST_STREAM (0x03) и GOAWAY (0x07)
Эти кадры позволяют преждевременно закрыть поток/соединение. Например, если клиент на каком-то потоке отправил кадр с ошибкой (не соответствующий спецификации HTTP/2), сервер скорее всего закроет этот поток с помощью RST_STREAM (по-русски reset stream), в котором укажет код ошибки. Либо, например, пока сервер отправляет ответ на запрос, клиент решил, что он больше не нужен (скажем, пользователь отменил загрузку картинки в вотсапе). Тогда он может остановить передачу ответа с помощью RST_STREAM. В общем, причин закрывать поток может быть множество.
Аналогично с GOAWAY: он служит для закрытия соединения либо в случае ошибки, либо просто по инициативе одной из сторон. В кадре GOAWAY содержится самый большой идентификатор потока, который отправитель смог получить и каким-то образом обработать — Last-Stream-Id. Таким образом, получатель GOAWAY узнаёт, какие сообщения нужно будет отправлять заново, а какие нет.
RST_STREAM Frame {
Length (24) = 0x04,
Type (8) = 0x03,
Unused Flags (8),
Reserved (1),
Stream Identifier (31),
Error Code (32),
}
GOAWAY Frame {
Length (24),
Type (8) = 0x07,
Unused Flags (8),
Reserved (1),
Stream Identifier (31) = 0,
Reserved (1),
Last-Stream-ID (31),
Error Code (32),
Additional Debug Data (..),
}Возможные коды ошибок и спецификации, в которых они определены, надо вновь искать на страничке IANA.
Additional Debug Data — произвольные данные, которые могут помочь при отладке ошибок. Обычно это какая-нибудь строка в ASCII с более подробным описанием ошибки, чем позволяет Error Code, но в принципе там может быть что угодно.
Пример: клиент закончил передачу запроса на потоке 5, отправив все необходимые кадры и установив в последнем флаг END_STREAM, а затем пытается отправить ещё один кадр HEADERS на том же потоке 5. Сервер закрывает его с ошибкой:
00 00 04 03 # Длина содержимого 4 октета, тип RST_STREAM
00 00 00 00 05 # Флагов нет, поток 5
00 00 00 05 # Ошибка 0x05 — STREAM_CLOSEDЕщё пример: на клиенте некорректно реализован алгоритм HPACK, и сервер не может понять заголовки в запросе из потока 7. В связи с очередными особенностями HPACK, в этом случае сервер должен закрыть соединение. При этом запросы, которые ранее приходили на потоках 1 и 3 уже обработаны, и на них отправлены ответы, а на потоке 5 сообщение начало обрабатываться, но не закончило, и ответ ещё даже не сформирован. Тогда сервер отправляет такой кадр:
00 00 14 07 # Длина содержимого 0x14=20 октетов, кадр GOAWAY
00 00 00 00 00 # Флагов нет, поток 0
00 00 00 05 # Последний обработанный поток — пятый
00 00 00 09 # Ошибка 0x09 — COMPRESSION_ERROR
68 70 61 63 6b 5f 65 72 72 6f 72 0a # Строка "hpack_error" для отладки, записанная в ASCIIПосле этого он закрывает TCP-соединение, но может продолжить обработку запроса из потока 5 (скажем, это был запрос на перевод денег, который нельзя просто оборвать посередине, чтобы база данных не оказалась в невалидном состоянии).
На этом завершим обзор кадров. Необсуждёнными из спецификации HTTP/2 остались только кадры PRIORITY (устаревшие останки вышеупомянутой системы приоризитации) и PUSH_PROMISE (используется для server push. Позволю себе пропустить его обсуждение, так как технология на данный момент не слишком востребованная, да и интересных подробностей нет: просто сервер отправляет PUSH_PROMISE с описанием запроса, на который он хочет без спросу выдать ответ, а затем сам ответ). Кроме того, упустили кадры, которые были введены в отдельных RFC. Полный список кадров со ссылками в очередной раз предлагаю искать на страничке IANA.
Как завязать общение с понравившимся сервером
Обсудили кусочки, из которых составляется обмен данными в HTTP/2. Теперь посмотрим на соединение с высоты: как оно зарождается, живёт и умирает.
Сервера HTTP/1.1 и HTTP/2 по умолчанию используют один и тот же порт — 443. Передаваемые данные у протоколов сильно отличаются, поэтому если клиент не знает заранее, какую версию поддерживает сервер, нужен какой-то механизм, как её выбрать.
Изначально (в старой спецификации) таких было два: один для защищённых соединений (тогда протокол называется HTTP/2 over TLS, сокращённо h2), один для незащищённых (HTTP/2 over cleartext TCP, сокращённо h2c). Однако большинство браузеров в принципе не стали поддерживать возможность использовать h2c, поэтому второй механизм в новой спецификации был признан устаревшим. Но для исторической справки и полноты картины описание, как это должно было работать, приведу в спойлере.
В случае защищённого соединения (с HTTP over TLS, он же h2, схема https) идея очень простая, но только если вы знаете TLS. Если не знаете, у меня есть статьи об этом протоколе (первая, вторая). Во второй части можно по байтам увидеть, как выбирается версия HTTP.
В общих чертах: TLS, помимо своей основной цели (шифрование трафика), поддерживает множество расширений — дополнительных полей, которыми сервер и клиент могут обменяться во время установки зашифрованного соединения. Одно из них — ALPN (Application-Level Protocol Negotation, согласование протокола прикладного уровня). Клиент отправляет список поддерживаемых протоколов (например, http/1.1 и h2), а сервер в ответе выбирает, какой из них предпочтителен.
Так как TLS в этом случае не используется, а в TCP расширения ALPN не предусмотрено, выбор протокола происходил бы на уровне HTTP. Если бы клиент заранее знал, что сервер поддерживает HTTP/2 (например, вы ручками указали в настройках, либо уже подключались к этому серверу ранее, и браузер сохранил версию протокола в кеш), то клиент сразу бы отправил свою преамбулу, как описано ниже, по которой сервер бы понял, что надо использовать HTTP/2. Если бы клиент ошибся (думал, что сервер поддерживает HTTP/2, а на самом деле нет), сервер бы просто закрыл соединение, не поняв, что от него требуется.
Иначе же, сначала клиент отправил бы запрос HTTP/1.1, в котором, среди прочего, указал заголовки Upgrade и HTTP2-Settings:
GET /hot-asian-girls.php HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: en
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: ...Значением Upgrade являлся бы идентификатор протокола HTTP/2 over cleartext TCP, то есть h2c. А HTTP2-Settings служил бы, чтобы сразу установить параметры соединения: в нём бы та же последовательность октетов, что и в содержимом кадра SETTINGS, только закодированная в base64. Если бы сервер не поддерживал HTTP/2, он бы просто отправил ответ, как будто это обычный запрос HTTP/1.1. Иначе, он бы отправил ответ со статусом 101:
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2cЗа ним сразу последовала бы преамбула сервера и ответ на запрос клиента. Но сейчас вся эта схема считается устаревшей, и не поддерживается практически ни одним браузером. Здесь приведена только в качестве исторической справки.
Итак, соединение установили, протокол выбрали, пора бы и чем-нибудь содержательным обменяться.
Что-нибудь содержательное
Первым делом, клиент сразу же отправляет серверу так называемую преамбулу (connection preface). Первая её часть — это фиксированная последовательность октетов
50 52 49 20 2a 20 48 54 54 50 2f 32
2e 30 0d 0a 0d 0a 53 4d 0d 0a 0d 0aЕсли интерпретировать эти октеты как последовательность кодов символов ASCII, получится следующая строка. Если закрыть глаза, она чем-то напоминает начало запроса HTTP/1.1.
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\nКто читал спойлер про незащищённое соединение, тому будет понятен смысл. Если бы протокол использовался без TLS, и клиент заранее знал, что сервер поддерживает HTTP/2, то эта строка служила бы индикатором для сервера, что клиент собирается использовать HTTP/2. Она специально выбрана так, чтобы даже сервера HTTP/1.1 с самыми нестрогими парсерами с большой вероятностью посчитали её ошибочным запросом. Поэтому если сервер бы не поддерживал HTTP/2, он бы просто закрыл соединение, и клиент бы понял, что ошибся с протоколом.
При использовании TLS важность этой строки теряется, поскольку выбор протокола происходит уже на этапе TLS-рукопожатия. Но по историческим причинам, и как дополнительное подтверждение выбора HTTP/2, она остаётся частью протокола.
Вторая часть — (возможно, пустой) кадр SETTINGS с изначальными параметрами соединения. После своей преамбулы клиент может сразу начать отправлять запросы, не дожидаясь преамбулы сервера. А у сервера она тоже есть, правда состоит всего из одного (опять же, возможно, пустого) кадра SETTINGS.
Сообщение-запрос выглядит так:
- Один кадр HEADERS, в котором указывается идентификатор потока, который не использовался ранее. Идентификаторы выбираются обязательно по возрастанию, причём клиент может открывать только потоки с нечётными номерами. Это нужно, потому что сервер тоже может открывать новые потоки (с помощью кадров PUSH_PROMISE при использовании server push) — он будет выбирать только чётные номера. Таким образом не возникает коллизий.
Если все заголовки поместились в HEADERS, у него должен быть флаг END_HEADERS. Иначе за HEADERS могут следовать сколько угодно кадров CONTINUATION, и флаг выставляется на последнем. Если у запроса нет тела, то у HEADERS должен быть флаг END_STREAM.
- Возможно, один или больше кадров DATA, содержащих тело запроса. Если нет трейлеров, на последнем должен быть флаг END_STREAM.
- Возможно, ещё один кадр HEADERS, содержащий трейлеры. Если он есть, то должен быть с флагом END_STREAM. Если трейлеров много, далее также могут следовать кадры CONTINUATION. В этом случае на последнем должен быть флаг END_HEADERS, иначе он должен быть на самом HEADERS. Список трейлеров, так же как и в HTTP/1.1, отправляется в заголовке `Trailers`.
В кадре HEADERS запроса первыми обязательно должны быть псевдозаголовки :method, :path и :scheme (кроме запросов с методом CONNECT, но это детали); псевдозаголовок :authority может отсутствовать.
После того, как сервер получил на потоке кадр с флагом END_STREAM, он может начинать отправлять ответ. Формат сообщения-ответа точно такой же, как и у запроса, только идентификатор потока указывается не новый, а тот, на котором пришёл запрос; и вместо :method, :path, :scheme и :authority, единственный псевдозаголовок, который ответ может и обязан содержать — это :status.
Когда размер окна одной из сторон подходит к концу, она увеличивает его кадром WINDOW_UPDATE. Пока никакие сообщения не отправляются, стороны периодически обмениваются кадрами PING. В любой момент можно изменить параметры соединения кадром SETTINGS. Любая из сторон может закрыть любой поток кадром RST_STREAM. HTTP-соединение прерывается, когда закрывается TCP-соединение. Перед тем как закрыть TCP-соединение, сторона может отправить кадр GOAWAY с объяснением причин (вообще говоря, не обязана, но рекомендуется).
Вот так и живём. Основные детали протокола разобрали, под конец приведу содержательный пример обмена сообщениями. Домашнее задание: написать простой клиент и сервер HTTP/2 на любимом языке.
Предполагается, что TCP-рукопожатие уже произошло, TLS-рукопожатие тоже, и HTTP/2 начал действовать. Слева записаны кадры, которые отправляет клиент, справа — сервер. Кадры указаны сверху вниз в порядке, в котором они отправляются. Ещё домашнее задание: расписать этот обмен кадрами по байтам.
PRI * HTTP/2.0\r\n\r\n |
SM\r\n\r\n | SETTINGS/0
| SETTINGS_MAX_CONCURRENT_STREAMS = 100
SETTINGS/0 |
SETTINGS_ENABLE_PUSH = 0 |
SETTINGS_NO_RFC7540_PRIORITIES = 1 |
|
HEADERS/1 |
+ END_STREAM | SETTINGS/0
:method = GET | + ACK
:scheme = https |
:path = / |
:authority = example.com |
accept = text/html |
accept-language = ru |
user-agent = My-Browser/1.0 |
|
CONTINUATION/1 |
+ END_HEADERS |
cookie = <2048 октетов> |
|
SETTINGS/0 |
+ ACK | HEADERS/1
| + END_HEADERS
HEADERS/3 | + END_STREAM
+ END_HEADERS | :status = 302
+ END_STREAM | location = https://example.com/ru
:method = GET | content-length = 0
:scheme = https | vary = accept-language
:path = /favicon.ico |
:authority = example.com |
accept = image/webp |
user-agent = My-Browser/1.0 |
|
HEADERS/5 |
+ END_HEADERS |
+ END_STREAM | HEADERS/3
:method = GET | + END_HEADERS
:scheme = https | :status = 200
:path = /ru | content-length = 68792
:authority = text/html | content-type = image/webp
accept-language = ru |
user-agent = My-Browser/1.0 | DATA/3
cookie = <2048 октетов> | <65535 октетов>
|
| HEADERS/5
WINDOW_UPDATE/3 | + END_HEADERS
Window Size Increment = 65535 | :status = 200
| content-length = 38
WINDOW_UPDATE/5 | content-type = text/html; charset=utf-8
Window Size Increment = 65535 |
| DATA/3
| + END_STREAM
| <3257 октетов>
|
| DATA/5
| + END_STREAM
| <!DOCTYPE html>\n
| <h1>Привет!</h1>
|
|
|
|
PING/0 |
2f b0 7a ee 92 01 8a bc |
| PING/0
| + ACK
| 2f b0 7a ee 92 01 8a bc
|
GOAWAY/0 |
Last-Stream-Id = 0 |
Error Code = 0x00 NO ERROR |
|
# Клиент закрыл TCP-соединение |
|