WebSocket: HTTP-апгрейд до постоянного соединения

Вы открываете Discord. Друг отправляет сообщение — оно появляется мгновенно, без перезагрузки страницы. За этим стоит постоянное TCP-соединение, которое HTTP сам по себе обеспечить не может. WebSocket даёт обеим сторонам возможность отправлять данные в любой момент без ожидания запроса.

Проблема, которую HTTP не решает

HTTP — это request-response: клиент спрашивает, сервер отвечает, разговор окончен. Для живого чата, котировок, многопользовательских игр, совместного редактирования — всего, где сервер должен пушить данные без ожидания нового запроса — HTTP структурно не подходит. Каждый HTTP-запрос добавляет минимум один полный round-trip задержки прежде, чем данные могут потечь обратно.

WebSocket решает это, превращая существующее HTTP-соединение в постоянный двусторонний канал, где любая сторона отправляет в любой момент.

Метафора

С HTTP вы отправляете письма: пишете, посылаете, ждёте ответа. С WebSocket поднимаете трубку: как только соединились, обе стороны говорят свободно, не ожидая очереди.

Рукопожатие апгрейда шаг за шагом

Соединение начинается как обычный HTTP/1.1-запрос. Клиент сигнализирует, что хочет переключить протокол:

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

Каждый заголовок несёт конкретный смысл:

• Upgrade: websocket — объявляет целевой протокол.
• Connection: Upgrade — сообщает промежуточным прокси, что это смена протокола, а не обычный keepalive.
• Sec-WebSocket-Key — 16 случайных байт в base64. Сервер использует это, чтобы доказать, что намеренно обработал апгрейд (а не отдал кэшированный ответ — см. врезку ниже).
• Sec-WebSocket-Version: 13 — указывает RFC 6455, единственную версию на практике.

Сервер проверяет запрос (метод GET, HTTP/1.1, корректные заголовки) и отвечает:

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

Значение Sec-WebSocket-Accept вычисляется как:

base64(SHA-1(Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))

Фиксированная строка (258EAFA5-…) — это magic GUID из RFC. После ответа 101 обе стороны перестают говорить HTTP. TCP-соединение теперь является чистым WebSocket-потоком.

Сценарий от начала до конца

Вы открываете Discord в браузере:

1. Браузер делает TCP + TLS к gateway.discord.gg.
2. Браузер отправляет HTTP Upgrade-запрос выше.
3. Сервер отвечает 101. Обе стороны прекращают HTTP-парсинг.
4. С этого момента сервер Discord пушит фреймы с сообщениями в браузер в момент, когда друг что-то отправил. Браузер отправляет фреймы (индикаторы набора, сообщения) в другую сторону без открытия нового соединения.
5. Когда вы закрываете вкладку, обмениваются close-фреймами и TCP-соединение завершается.