HTTP против WebSocket: модель соединения

Апгрейд начинается с самого обычного GET. Браузер шлёт запрос с четырьмя характерными заголовками: Upgrade: websocket — хочу другой протокол; Connection: Upgrade — это относится к текущему соединению, а не ко всему миру; Sec-WebSocket-Key — шестнадцать случайных байт, закодированных в base64; Sec-WebSocket-Version: 13 — единственная живая версия протокола. Веб-страница добавляет ещё Origin — адрес, откуда пришла страница, он станет основой безопасности в уроках про origins. Сервер, согласный на апгрейд, отвечает статусом 101 Switching Protocols и заголовком Sec-WebSocket-Accept — значением, вычисленным из клиентского ключа и жёстко заданной константы 258EAFA5-E914-47DA-95CA-C5AB0DC85B11. Зачем эта арифметика? Браузер должен убедиться, что отвечает настоящий WebSocket-сервер, а не кэш или глупый прокси, который решил, что 101 — это ошибка, и подставил свой ответ. С этой секунды соединение выведено из-под HTTP: gorilla забирает сокет через Hijack, и по проводам идут уже кадры.

По чему вообще честно сравнивать websocket vs http? По шести пунктам, каждый из которых влияет на архитектуру. Кто инициирует передачу: в HTTP всегда клиент, в WebSocket — обе стороны, и это главное различие, из которого растут остальные. Что стоит над каждым сообщением: HTTP тащит стартовую строку и заголовки — с cookies легко набегают сотни байт на каждый чих, кадр WebSocket несёт 2-14 байт служебных. Насколько быстро доходит событие: в HTTP — до следующего запроса клиента, в WebSocket — сразу, потому что соединение уже открыто. Что помнит сервер: HTTP stateless, WebSocket stateful — соединение живо и контекст при нём. Как относятся инфраструктура и кэши: HTTP — родная среда для CDN, прокси и ретраев, WebSocket сквозь промежуточные узлы проходит не всегда и кэшу не подлежит. Наконец, масштабирование: HTTP-клиенту всё равно, какой инстанс ответит, WS-клиент прибит к своему — и мост между инстансами становится отдельной задачей.

Годами работая с HTTP, команда накапливает рефлексы, и половина из них на WebSocket не просто бесполезна, а вредна. Рефлекс «повторю запрос при ошибке» на WS выглядит как переподключение — но соединение-то одно, и без backoff ретрай превращается в шторм reconnect-ов по всему серверу. Рефлекс «кэшируй ответ» не работает вовсе: кадры не кэшируются по определению, и попытки вложить HTTP-кэш между клиентом и сокетом заканчиваются прокси, который режет апгрейд. Рефлекс «серверы одинаковы» ломается о stateful: после рукопожатия клиент прирос к своему инстансу, и балансировщик больше не волен его переносить — отсюда sticky-сессии или мост между инстансами из плана курса. Наконец, рефлекс «ошибки — это статусы» меняет форму: протокол не приносит вам 500-е, соединение просто рвётся или уходит кодом закрытия, и логика ошибок переезжает в уровень сообщений. Ошибкой здесь не знание WS, а память HTTP: заметить рефлексы — значит избежать класса багов, который не ловится тестами на едином инстансе.

Кадр WebSocket — короткий заголовок и полезная нагрузка. В начале идут мелкие поля: FIN-бит — признак последнего фрагмента сообщения; opcode — тип содержимого: 0x1 текст, 0x2 бинарные байты, а управляющие типы 0x8, 0x9 и 0xA — close, ping и pong; маска-бит и длина нагрузки, которая кодируется семью битами, а при переполнении — ещё двумя или восемью байтами. Отсюда и вилка 2-14 байт служебных. У клиентских кадров к заголовку добавляются четыре байта маски, которой закрывается нагрузка; серверные кадры ходят открыто. Цель маскирования — историческая защита от отравления кэшей недобросовестными прокси, и библиотека делает её сама. Большое сообщение может приехать фрагментами с FIN-битом на последнем куске — библиотека собирает фрагменты и отдаёт одним ReadMessage, границы сообщений сохраняются всегда. Управляющие кадры не могут быть длиннее 125 байт нагрузки. Итог: поверх потока TCP появляется конвертация в сообщения — именно поэтому ReadMessage возвращает готовое сообщение, а не куски байтов.

У соединения четыре состояния, которые браузер показывает в readyState: CONNECTING — рукопожатие в полёте; OPEN — кадры ходят; CLOSING — идёт прощание; CLOSED — всё кончено. Прощание по правилам выглядит как рукопожатие наоборот: одна сторона шлёт Close-кадр с кодом и причиной, вторая отвечает тем же — и только тогда сокет закрывается. Коды стандартизованы: 1000 — нормальное закрытие, 1001 — сервер или страница уходят, 1008 — нарушение политики, например не прошёл Origin, 1009 — кадр оказался слишком большим, 1011 — сервер словил внутреннюю ошибку. Отдельно живёт 1006: этот код по сети не передаётся никогда — это локальная метка обрыва, когда close-рукопожатия не было вовсе. Жёсткая правда real-time: при выдёргивании Wi-Fi ни одной стороне close не приедет, и соединение будет числиться открытым, пока кто-то не попробует писать или не проверит соединение ping-кадром — механизм heartbeat и дедлайнов разберём в шестом уроке.