Кратко

  • RFC 6455 открывал WebSocket через GET HTTP/1.1, Upgrade и ответ 101. RFC 7540 убрал переключение всего соединения из HTTP/2, где несколько потоков используют одну транспортную связь.
  • RFC 8441 ввёл расширенный CONNECT с :protocol = websocket, :scheme и :path. Клиент применяет его после получения от сервера SETTINGS_ENABLE_CONNECT_PROTOCOL = 1. IANA зарегистрировала параметр 0x8 с начальным значением 0.
  • Принятый поток несёт кадры WebSocket рядом с обычными потоками HTTP/2. При таком открытии не используются Connection, Upgrade и обработка Sec-WebSocket-Key/Accept; сами кадры WebSocket продолжают работать внутри туннеля.

Старый выключатель гасил весь этаж

Протокол WebSocket 2011 года начинался с запроса HTTP/1.1. Клиент отправлял GET с Upgrade: websocket и Connection: Upgrade, сервер мог ответить 101 Switching Protocols. После рукопожатия TCP-соединение превращалось в двусторонний канал. Если одно соединение обслуживало один запрос, передать всю линию разговору было естественным решением.

HTTP/2 расселил разные запросы по потокам одной линии. Страница может получать стили и изображения, пока другая её часть ждёт сообщений. RFC 7540 удалил ответ 101: смена протокола общего соединения разрушила бы работу соседних потоков. Upgrade и Connection говорят обо всём транспорте; одному потоку нельзя приказать остальным уйти. Старый ключ WebSocket оказался шире новой двери.

Противоречие возникало ещё до передачи первого сообщения. Для страницы уже имелось соединение HTTP/2, а для чата требовался иной способ входа. Открывать отдельную линию ради прежнего рукопожатия означало отказаться от совместного транспорта. Пытаться исполнить 101 внутри общего соединения означало подчинить чужие потоки одному разговору. RFC 8441 перенёс предмет согласования с линии целиком на конкретный поток.

Сначала разрешение сервера

Сервер объявляет SETTINGS_ENABLE_CONNECT_PROTOCOL = 1. Реестр параметров HTTP/2 IANA присвоил настройке код 0x8 и начальное значение 0. Лишь получив 1, клиент может применять расширенный CONNECT на новых потоках. Если отправить новый псевдозаголовок раньше, сервер без поддержки расширения получит некорректный запрос. Согласие должно предшествовать новому смыслу команды.

Получив разрешение, клиент открывает поток с :method = CONNECT и :protocol = websocket. В запросе также стоят :scheme, :path и :authority целевого URI. Последнее поле легко истолковать неверно. В обычном CONNECT :authority называет узел для создания туннеля. В расширенном CONNECT это authority целевого URI. RFC 8441 прямо запрещает серверу открывать обычный туннель к этому узлу лишь потому, что в запросе есть CONNECT. Новый псевдозаголовок определяет протокол потока.

Для защищённого WebSocket целевая схема будет https, для незащищённого — http. Путь и authority продолжают задавать место назначения. С прямым прокси HTTP/2 последовательность иная: стандарт рекомендует сначала обычный CONNECT до сервера WebSocket; версия HTTP внутри получившегося туннеля определяет дальнейшее открытие. Туннель прокси и расширенный поток к исходному серверу решают разные задачи.

После ответа 200 идут кадры

Расширенный CONNECT заменяет стартовый GET. Он не отправляет Connection и Upgrade; обработка пары HTTP/1.1 Sec-WebSocket-Key и Sec-WebSocket-Accept на этом пути тоже уступает месту :protocol. Заголовки Origin, версии WebSocket, подпротокола и расширений остаются в силе по правилам WebSocket. Меняется допуск на транспорт, а не формат последующего разговора.

Пример RFC показывает настройку сервера, запрос CONNECT и ответ :status = 200. Затем кадры DATA HTTP/2 переносят данные WebSocket в обе стороны. Поток играет роль, которую в RFC 6455 играло целое TCP-соединение. Приоритеты, отмена и управление потоком остаются механизмами HTTP/2; END_STREAM и RST_STREAM завершают именно этот канал обычным или аварийным образом. Соседние потоки при этом продолжают работать.

Долгий чат больше не держит загрузку изображений в заложниках. Сервер может отказаться от расширения, не включая настройку. Клиент увидит отказ ещё до специального CONNECT. Разрешение заметно в SETTINGS, применение — в запросе. Посреднику не приходится угадывать, что означал бы старый 101 среди мультиплексированных данных.

Остальные жильцы сохранили линию

RFC 8441 выбрал узкое изменение. Более глубокая переделка WebSocket была возможна, но расширенный CONNECT решал ближайшую задачу совместной работы WebSocket и HTTP/2. После открытия продолжают действовать кадры WebSocket и большинство положений о безопасности из RFC 6455. Маскирование этих кадров — другая история; здесь решается право занять несущий их поток.

Четыре официальных документа доказывают механизм и регистрацию настройки. Чтобы назвать конкретный сервис, который её применил, понадобятся датированные версии клиента, сервера и прокси вместе с захваченными сообщениями SETTINGS и HEADERS. Историческое решение уже зафиксировано: HTTP/2 не уступил общий транспорт одному разговору. WebSocket получил согласованный поток внутри него.