В 2000-х годах разработчики интернет-приложений сталкивались с одной проблемой: каждое обновление состояния на сервере требовало отдельного запроса. Пользователь ждал, пока сервер отвечал, а в ответ приходили сотни байт заголовков. Это было не просто неудобно — оно замедляло взаимодействие и ухудшало пользовательский опыт. В ответ на это появился новый подход: не обновлять данные по запросам, а устанавливать постоянное соединение, где обмен происходил в режиме реального времени.
Эта идея была реализована через веб-сокеты — технологии, которая позволила избежать тяжелых заголовков и превратить общение между клиентом и сервером в плотную, непрерывную передачу данных. Вместо того чтобы ждать, пока сервер отвечает, клиент теперь получал обновления мгновенно. Но за этим простым словом скрывалась сложная архитектура, построенная на бинарных структурах, где каждый байт имел строгий смысл.
От запросов к фреймам
Раньше приложения работали по принципу «запрос — ответ». Клиент отправлял запрос, сервер отвечал, и процесс повторялся. Каждый ответ приходил с полным набором HTTP-заголовков — в среднем от 100 до 500 байт. Это означало, что даже простое сообщение, например, «новый комментарий», требовало сотен байт для передачи.
Веб-сокеты изменили этот подход. Вместо запросов они создают одно соединение, которое остаётся открытым. В этом соединении данные передаются не как HTTP-запросы, а как фреймы — минимальные бинарные блоки данных с заголовком. Каждый фрейм содержит только два байта информации: тип данных, флаги (последний фрейм, маскировка), и длина полезной нагрузки. Это делает передачу данных чрезвычайно эффективной — без лишних заголовков, без дублирования, без пересылки состояний.
Работа веб-сокетов начинается с установления TCP-соединения. Клиент и сервер договариваются о параметрах: порт (по умолчанию 80 или 443), хост, и формат запроса. Первый шаг — это HTTP-запрос с заголовками Upgrade: websocket и Connection: Upgrade. Сервер проверяет, что запрос валиден: метод GET, версия HTTP/1.1, наличие обязательных заголовков. Если что-то не так — ответ 400 и закрытие соединения.
После проверки сервер вычисляет специальный ключ — accept-key. Он формируется путём соединения полученного ключа клиента с фиксированным GUID: 258EAFA5-E914-47DA-95CA-C5AB0DC85B11. Далее ключ шифруется SHA-1, и результат кодируется в Base64. Этот ключ возвращается в ответе как заголовок Sec-WebSocket-Accept. Клиент проверяет это значение — если оно совпадает, соединение считается успешным.
Как передаются данные
После успешного ответа сервер переходит в состояние OPEN. Теперь между клиентом и сервером идёт только передача фреймов. Каждый фрейм — это бинарный блок, где первые два байта — это заголовок. В них хранится тип данных (например, текст или бинарный), флаг «последний фрейм», флаг «маскировка» и длина полезной нагрузки. Остальная часть — это сама нагрузка, без дополнительных структур.
Фреймы не требуют текстового форматирования. Они не содержат HTML, не имеют заголовков, не привязаны к типам данных. Они просто передают данные в виде байтов. Это позволяет сократить размер передаваемых данных в десятки раз. Например, вместо 400 байт заголовков на каждый запрос — всего 2 байта в заголовке фрейма.
Важно понимать, что фреймы не обрабатываются как строки. Они не разбиваются на слова, не интерпретируются как JSON или XML. Они передаются в чистом виде — как биты. Это делает их устойчивыми к ошибкам, быстрыми и эффективными.
Сравнение производительности показывает разницу в масштабах:
- Обычный HTTP-запрос: 400 байт заголовков + 100 байт данных = 500 байт на сообщение
- Фрейм веб-сокета: 2 байта заголовка + 100 байт данных = 102 байта на сообщение
- Эффективность: 20% размера данных, что ведёт к снижению нагрузки на сеть и серверы
Для разработчиков это означает, что можно строить приложения, которые реагируют на события мгновенно — от уведомлений о новых сообщениях до обновлений в реальном времени. Не нужно ждать ответа. Достаточно открыть соединение и начать получать данные.
В будущем веб-сокеты продолжат развиваться. Появятся новые протоколы, поддерживающие более сложные типы данных, расширенные механизмы безопасности и поддержку в распределённых системах. Однако основа — фреймы — останется неизменной. Они продолжат быть основой для реального времени, где скорость и эффективность — ключевые параметры.
