Реальное время с WebSockets
Держите открытый двусторонний канал между сервером и клиентом вместо опроса изменений.
- объяснить рукопожатие-апгрейд WebSocket и его отличие от опроса;
- построить низкоуровневый сервер на
wsи сервер «всё включено» на Socket.IO; - рассылать обновления, использовать комнаты и широковещание сразу многим клиентам;
- удерживать соединения живыми с помощью heartbeat и восстанавливаться после обрывов через переподключение;
- оценивать реальные компромиссы: сырой протокол против фреймворка и масштабирование по процессам.
1. От запрос/ответ к живому соединению
Вы уже знаете REST: клиент шлёт запрос, сервер шлёт ответ, готово. Чтобы узнать о новых данных, клиент должен спросить снова. Самый старый приём -- опрос (polling): дёргать GET /messages каждые несколько секунд. Это работает, но тратит запросы, когда ничего не изменилось, и добавляет задержку (новое сообщение ждёт следующего опроса). Долгий опрос (long-polling) лучше: он держит запрос открытым, пока не появятся данные, но это всё ещё один ответ на событие и постоянные переподключения.
WebSocket решает корень проблемы. Клиент открывает обычный HTTP-запрос с заголовком Upgrade: websocket; сервер соглашается ответом 101 Switching Protocols; с этого момента то же самое TCP-соединение становится двунаправленным потоком кадров (frames). Никаких новых рукопожатий на каждое сообщение, и сервер может слать данные когда угодно.
Аналогия. Опрос -- это как звонить в магазин каждую минуту и спрашивать «есть новости?». WebSocket -- это оставить линию открытой: как только появляется новость, любой из вас просто говорит -- без повторного дозвона.