Как страница узнаёт о новом
Протокол HTTP устроен по схеме «запрос — ответ»: сервер сам не может отправить сообщение клиенту. Чтобы получать обновления, вроде новых сообщений в чате или цен, используют несколько подходов. Самый простой — polling: клиент через равные промежутки спрашивает сервер, есть ли что-то новое. Long polling удерживает запрос открытым, пока не появится событие. WebSocket устанавливает постоянное двустороннее соединение.
Выбор зависит от требований к задержке, числа клиентов и окружения, в котором работает приложение.
Задержка и нагрузка
При обычном polling задержка равна интервалу опроса: чем чаще спрашивать, тем быстрее реакция, но тем больше пустых запросов и нагрузки на сервер и сеть. Если обновления редкие, большая часть запросов бесполезна.
Long polling снижает пустые запросы и уменьшает задержку, но каждый клиент удерживает соединение и после каждого ответа заново устанавливает новое. WebSocket после установки соединения передаёт сообщения с минимальными накладными расходами в обе стороны, поэтому лучше подходит для частых обновлений.
Совместимость и инфраструктура
Polling и long polling работают поверх обычного HTTP и проходят практически через любые промежуточные узлы и межсетевые экраны. Их легко отлаживать и внедрять на существующем сервере.
WebSocket требует поддержки со стороны сервера, балансировщиков и промежуточных узлов. Некоторые корпоративные шлюзы и старые промежуточные узлы могут закрывать долгие соединения или не поддерживать переключение протокола. Поэтому во многих библиотеках предусмотрен резервный режим с откатом на long polling.
Сложность и надёжность
Постоянные соединения требуют продуманного управления: переподключения при обрыве, повторной синхронизации данных, проверки живости через служебные сообщения, а также учёта числа одновременно открытых соединений на сервере. Масштабирование потребует общего хранилища сообщений между узлами.
Простые запросы масштабируются проще и не хранят состояние, что облегчает восстановление после сбоев. Но при большой аудитории частые опросы могут быть дороже, чем поддержание соединений. Поэтому при небольшой нагрузке и редких обновлениях лишняя сложность постоянных соединений редко оправдана.
Когда что выбрать
Для чатов, совместного редактирования, игровых и торговых интерфейсов, где обновления частые и важна отзывчивость, обычно выбирают WebSocket. Для редких уведомлений, панелей мониторинга с обновлением раз в минуту и сред с жёсткими ограничениями сети подойдёт polling.
Long polling — компромисс, когда нужна быстрая реакция без поддержки нового протокола. Если однонаправленного потока от сервера достаточно, стоит присмотреться к серверным событиям поверх обычного HTTP, которые проще WebSocket, но не позволяют отправлять данные от клиента.
Подводные камни при эксплуатации
Постоянные соединения имеют неочевидные последствия. Каждый открытый WebSocket занимает ресурсы сервера, поэтому нужно знать лимит одновременных соединений и заранее проверить, как система ведёт себя при пике. Балансировщики нагрузки должны поддерживать долгие соединения и не закрывать их по таймауту, иначе клиенты будут постоянно переподключаться.
Вторая тонкость — обрывы. Мобильные сети, переход между Wi-Fi и мобильным интернетом и энергосбережение приводят к тому, что соединение молча пропадает, и ни клиент, ни сервер не замечают этого. Помогают периодические служебные сообщения и автоматическое переподключение с задержкой, которая нарастает, чтобы не создавать лавину запросов после сбоя.
Третья — потерянные сообщения. При переподключении клиент должен получить всё, что произошло за время отсутствия, поэтому событиям присваивают порядковые номера и позволяют запросить пропущенное. Для polling эта проблема решается проще, ведь каждый запрос независим. Перед выбором технологии оцените, готова ли ваша команда обслуживать состояние, и не берите более сложный механизм, если хватает простого опроса раз в несколько секунд.
И, наконец, о тестировании. Проверяйте решение в неудобных условиях: при медленном соединении, за корпоративным шлюзом, при частых переключениях сети и при внезапной потере питания устройства. Многие проблемы реального времени проявляются только в таких ситуациях. Если приложение продолжает работать корректно, выбранный подход справляется. Если нет, лучше упростить схему, чем добавлять слои исправлений поверх ненадёжной основы. Прикиньте заранее и объём трафика: частые короткие сообщения по постоянному соединению требуют меньше ресурсов, чем множество отдельных запросов с полными заголовками, но только если соединения не рвутся каждую минуту.