Чем плох обычный HTTP для живых данных

Разбираемся, почему классический HTTP не умеет «толкать» данные пользователю сам.

Реалтайм — режим, при котором изменение на сервере доходит до пользователя за доли секунды, без его участия и без перезагрузки страницы.

Почему это важно

Представьте чат. Вы написали сообщение — собеседник должен увидеть его сразу, а не через 30 секунд и не после нажатия «Обновить». То же с уведомлениями, онлайн-статусом, тикером цен на бирже, счётом в матче. Все эти задачи объединяет одно: инициатором обмена выступает сервер, а не пользователь. Что-то поменялось — и об этом надо немедленно сообщить браузеру.

Беда в том, что обычный HTTP так не умеет. Он построен вокруг модели «запрос — ответ»: браузер спрашивает, сервер отвечает, соединение закрывается. Сервер физически не может «постучаться» в браузер первым.

Модель «запрос — ответ»

Любой обмен по HTTP инициирует клиент. Схема всегда одна:

Браузер  ----- GET /messages ----->  Сервер
Браузер  <---- 200 OK + данные -----  Сервер
         (соединение закрыто)

... проходит время, на сервере появилось новое сообщение ...

Сервер  ???  как сообщить браузеру?  ???
        (никак — браузер не спрашивал)

Сервер знает о новом сообщении, но у него нет открытого канала к браузеру. Остаётся ждать следующего запроса. Это фундаментальное ограничение: HTTP однонаправлен в смысле инициативы — говорит всегда клиент.

Как работает под капотом

HTTP/1.1 работает поверх TCP-соединения. Браузер открывает соединение, шлёт строку запроса и заголовки, получает ответ — и дальше соединение либо закрывается, либо живёт в режиме keep-alive для следующих запросов того же клиента. Но даже keep-alive не позволяет серверу заговорить первым: канал предназначен для следующего запроса браузера, а не для спонтанной отправки данных сервером.

Сравним две роли в TCP-соединении:

Кто	Может начать передачу?
Браузер (клиент)	Да — шлёт запрос, когда захочет
Сервер	Нет — только в ответ на запрос

Частые ошибки

«Поставлю запрос в цикл — будет реалтайм». Это polling, и он работает, но с задержкой и лишней нагрузкой (разберём в следующих уроках).
Путать keep-alive с двусторонним каналом. Keep-alive переиспользует TCP-соединение для запросов клиента, но не даёт серверу инициативу.
Думать, что проблема в скорости сети. Дело не в скорости, а в самой модели: сервер не имеет права заговорить первым.

Итоги

Реалтайм — это когда сервер сам и мгновенно доставляет изменения пользователю.
HTTP построен на модели «запрос — ответ»: инициатор всегда клиент.
Сервер не может «толкнуть» данные браузеру по обычному HTTP — нет открытого канала под его инициативу.
Из этого ограничения выросли все приёмы реалтайма, которые мы дальше разберём.