Протоколы ws:// и wss://

Протоколы ws:// и wss://

Мы разобрали, как HTTP-соединение повышается до WebSocket. Но как URL WebSocket'а отличается от HTTP URL? В этом уроке разберём протоколы ws:// и wss://, их отношение к HTTP/HTTPS и что происходит под капотом при установке соединения.

ws:// и wss:// — что это такое

WebSocket имеет свои URL-схемы, аналогичные HTTP:

ws://example.com/chat        ← WebSocket без шифрования (как HTTP)
wss://example.com/chat       ← WebSocket с TLS-шифрованием (как HTTPS)

Схема wss:// — это WebSocket поверх TLS, точно так же как HTTPS — это HTTP поверх TLS. На практике почти всегда используется wss://: незашифрованные WebSocket'ы столь же опасны, как и HTTP — данные видны всем промежуточным узлам.

Как browser обрабатывает ws:// URL

Когда JavaScript вызывает new WebSocket('wss://example.com/chat'), браузер:

1. Берёт хост и порт из URL (example.com:443).
2. Устанавливает TCP-соединение с сервером (порт 443 для wss, порт 80 для ws).
3. Для wss:// — выполняет TLS-рукопожатие (точно как HTTPS).
4. Поверх TCP/TLS отправляет HTTP GET с Upgrade: websocket.
5. Получает 101 Switching Protocols.
6. Дальше — обмен WebSocket-фреймами.

Почему тот же порт, что и HTTP/HTTPS

WebSocket использует те же порты, что и HTTP, по дизайну:

ws://  → порт 80 (тот же, что у HTTP)
wss:// → порт 443 (тот же, что у HTTPS)

Это умное решение: WebSocket-трафик проходит через те же прокси, балансировщики и файрволы, что и обычный веб-трафик. Администратору не нужно открывать дополнительные порты. Прокси видит HTTP-запрос с Upgrade: websocket, понимает, что это WebSocket, и пропускает трафик.

WebSocket и прокси

Прозрачные HTTP-прокси — потенциальная проблема для WebSocket. Старый прокси может не понимать Upgrade: websocket и либо разорвать соединение, либо пропустить запрос как обычный HTTP (и не поддерживать долгоживущее TCP-соединение).

Маскировка фреймов от клиента к серверу (XOR с случайным ключом) была добавлена именно из-за прокси. Без маскировки злоумышленник мог бы через WebSocket-клиента инъецировать HTTP-подобные данные в кэш прокси. Маскировка делает данные случайными — прокси не распознаёт их как HTTP и не пытается кэшировать.

WebSocket поверх HTTP/2 и HTTP/3

Долгое время WebSocket работал только поверх HTTP/1.1. Современные браузеры поддерживают WebSocket поверх HTTP/2, а с 2024 года — и поверх HTTP/3 (через QUIC). Для разработчика это прозрачно: JavaScript-код тот же, браузер сам выбирает лучший транспорт:

WebSocket поверх HTTP/1.1:  HTTP GET Upgrade → 101 → WebSocket-фреймы
WebSocket поверх HTTP/2:    HTTP/2 CONNECT → туннель → WebSocket-фреймы
WebSocket поверх HTTP/3:    QUIC stream → WebSocket-фреймы

Сравнение URL разных протоколов

Разница только в том, какой протокол работает поверх TCP/TLS: HTTP или WebSocket. Транспорт один и тот же.

Проверь себя

1. Чем ws:// отличается от wss://?
2. Почему WebSocket использует те же порты, что и HTTP/HTTPS?
3. Зачем нужна маскировка фреймов в WebSocket?

1. ws:// — без шифрования (как HTTP), wss:// — с TLS-шифрованием (как HTTPS). На практике всегда используют wss://.
2. Чтобы проходить через существующие прокси, балансировщики и файрволы без дополнительной настройки. WebSocket маскируется под HTTP-соединение.
3. Защита от кэш-атак через HTTP-прокси. Без маскировки злоумышленник мог бы заставить прокси закэшировать сфабрикованные данные. XOR-маскировка делает данные случайными для прокси.

Что унести с урока

• ws:// (TCP, порт 80) и wss:// (TLS, порт 443) — WebSocket-аналоги HTTP/HTTPS.
• wss:// — стандарт; без шифрования WebSocket не используют в production.
• WebSocket использует те же порты, что HTTP, для совместимости с прокси и файрволами.
• Маскировка фреймов — защита от атак через кэширующие прокси.

В следующем уроке разберём WebSocket API в браузере — как JavaScript-код открывает соединение, отправляет и получает сообщения, обрабатывает ошибки и закрытие.