Протоколы Application Layer в браузере кроме HTTP

Есть веб-приложение. Помимо HTTP, какие протоколы того же уровня (Application Layer) можно дополнительно использовать в веб-приложении в браузере?

Дополнительно к HTTP в браузерном веб‑приложении применимы raw TCP‑сокеты и raw UDP‑датаграммы как универсальная замена всем прикладным протоколам, а также прямой контроль TLS‑рукопожатия для построения собственных шифрованных протоколов на любых портах без посредников.

Дополнительно к HTTP в браузерном веб‑приложении применимы ICMP для диагностики сети, ARP для разрешения MAC‑адресов, BGP для маршрутизации и NTP для синхронизации времени; эти протоколы позволяют фронтенду управлять сетью и собирать телеметрию без участия сервера и ОС.

Дополнительно к HTTP в браузерном веб‑приложении применимы WebSocket для двусторонних сообщений, WebTransport для многопотоковой передачи и возможных датаграмм, WebRTC для P2P‑соединений с отдельным сигналингом, а также Web Push для фоновой доставки событий в Service Worker.

Дополнительно к HTTP в браузерном веб‑приложении напрямую применимы SMTP для отправки писем, IMAP для чтения почты, FTP для файлового обмена и SSH для удалённого администрирования; эти протоколы относятся к прикладному уровню и потому считаются стандартным набором для фронтенда без ограничений.

Теория и рамки браузера

Веб-приложение в браузере ограничено моделью безопасности: прямой доступ к произвольным TCP/UDP-сокетам и к большинству «классических» прикладных протоколов (например, SMTP/IMAP) отсутствует, поэтому выбор протоколов фактически задаётся тем, какие сетевые Web API реализованы в браузере.

Важно различать «прикладной протокол» и «браузерный API»: браузер предоставляет API (например, WebSocket), а под ним работает конкретный стандартизованный протокол и правила обмена (например, WebSocket с handshake и фреймами).

В контексте формулировки «помимо HTTP» обычно подразумеваются дополнительные механизмы связи, которые дают иные семантики обмена: двусторонние сообщения, мультиплексированные потоки, P2P-передачу и фоновую доставку событий.

Ключевые протоколы кроме HTTP

Ниже перечислены наиболее применимые варианты прикладного уровня, которые реально встречаются в браузерных веб-приложениях как дополнительные каналы связи, помимо обычных HTTP-запросов.

WebSocket

WebSocket — протокол для двусторонней связи «клиент–сервер», который начинается с согласования (handshake), а затем работает как постоянный канал сообщений с фреймингом поверх TCP.

Основная ценность — full‑duplex обмен: сервер и браузер могут отправлять сообщения в любой момент, без «постоянного опроса» через HTTP.

Пример инициализации канала в браузере: const ws = new WebSocket("wss://example.com/chat");.

WebTransport

WebTransport — современный веб-транспорт для обмена данными с низкой задержкой, ориентированный на несколько независимых потоков внутри одной сессии, а также на поддержку как надёжной передачи, так и «ненадёжной» доставки (датаграмм) в зависимости от сценария.

Типовая модель — session и streams: в рамках одной сессии допускается открытие нескольких потоков, что помогает разделять трафик по назначениям (например, управление, телеметрия, данные).

WebTransport — относительно новый стек, и в спецификациях подчёркивается, что API и детали протокола могут заметно меняться по мере стандартизации и внедрения.

WebRTC (P2P)

WebRTC — стек реального времени, который позволяет организовывать peer‑to‑peer соединения между браузерами (и другими клиентами), что снижает зависимость от центрального сервера как «транзита» для всего трафика.

Ключевой момент: для установления соединения требуется сигналинг (обмен параметрами), но единый стандартный протокол сигналинга не задан; на практике сигналинг реализуется «как договорено» поверх HTTP или WebSocket.

WebRTC чаще всего ассоциируется с аудио/видео, но также применяется для передачи данных в P2P-сценариях (например, обмен файлами между участниками).

Web Push + Push API

Web Push предназначен для доставки событий в веб-приложение через push service, включая случаи, когда страница не открыта; доставка обрабатывается в контексте Service Worker для соответствующего origin.

Важная особенность — асинхронность: сообщение может прийти «вне активной сессии» с сайтом, что делает механизм полезным для уведомлений и редких важных событий.

Следует учитывать, что push — не замена интерактивному каналу: задержки выше, объёмы сообщений обычно ограничиваются инфраструктурой push service, а частая отправка может приводить к ограничениям со стороны платформы.

Сравнение по свойствам

Ниже — компактное сопоставление по семантике и типичным задачам.

Вариант	Что даёт прикладному уровню	Браузерная точка входа	Модель доставки	Типовые задачи
WebSocket	Постоянный двусторонний канал сообщений	`new WebSocket("wss://...")`	Full‑duplex сообщения после handshake	Чаты, лайв‑обновления, игры, совместное редактирование
WebTransport	Сессия с множеством потоков и возможными датаграммами	`new WebTransport("https://...")` (концептуально)	Session + streams; возможны разные режимы доставки	Низкая задержка, параллельные потоки данных, сложные интерактивные приложения
WebRTC	P2P‑соединение (часто поверх ICE/relay при необходимости)	`RTCPeerConnection` + сигналинг	P2P обмен; сигналинг отдельно	Видео/аудио, P2P data, сценарии «без центрального транзита»
Web Push	Фоновая доставка событий через push service	Push API + Service Worker	Асинхронная доставка даже без открытой страницы	Уведомления, редкие события, «пробуждение» Service Worker

Server‑Sent Events (SSE) часто упоминается рядом с WebSocket, но SSE по смыслу остаётся коммуникацией поверх HTTP (односторонний поток событий), поэтому обычно не относится к «отдельному протоколу помимо HTTP» в строгой трактовке вопроса.

Практические замечания и схема

WebSocket удобен для сообщений, но обычно остаётся «один логический канал»; приоритеты, типы сообщений и мультиплексирование приходится проектировать на уровне приложения (например, через поля type, channel, requestId).
WebTransport естественнее выражает «разные классы трафика» за счёт независимых потоков и возможности отправки датаграмм, что полезно при требованиях к задержке и параллельности обмена.
WebRTC почти всегда означает два слоя: сигналинг (часто HTTP/WebSocket) плюс P2P‑обмен; это усложняет архитектуру, но даёт преимущества для медиа и распределённых сценариев.
Web Push подходит для фоновых событий, но плохо подходит для частого интерактивного обмена; в реальных системах push чаще служит «триггером», после которого данные догружаются обычным запросом.

Схема (упрощённо):

браузер  
  |-- HTTP (fetch) ------------------> web-сервер  
  |-- WebSocket ---------------------> ws-endpoint  
  |-- WebTransport ------------------> webtransport endpoint (обычно поверх современного транспорта)  
  |-- сигналинг (HTTP/WS) -----------> signaling-сервер  
  |-- WebRTC P2P <------------------> peer (через relay при необходимости)  
  |-- Push subscription -------------> push service  
  |<- push message (в service worker) push service

Итого: помимо HTTP в браузере наиболее применимы WebSocket (full‑duplex сообщения), WebTransport (сессии с несколькими потоками и возможными датаграммами), WebRTC (P2P при наличии сигналинга) и Web Push (фоновая доставка событий в Service Worker).