Обновления в реальном времени

Проблема

Рассмотрим редактор документов для совместной работы, такой как Google Docs. Когда один пользователь печатает символ, все остальные пользователи, просматривающие документ, должны увидеть это изменение в течение миллисекунд. В подобных приложениях вы не можете позволить каждому пользователю постоянно опрашивать сервер на наличие обновлений каждые несколько миллисекунд, не перегружая при этом вашу инфраструктуру.

Основная сложность заключается в установлении эффективных, постоянных каналов связи между клиентами и серверами. Стандартный HTTP следует модели "запрос-ответ": клиенты запрашивают данные, серверы отвечают, затем соединение закрывается. Это отлично работает для классического веба, но не подходит, когда серверам нужно отправлять (push) обновления клиентам.

Многие кандидаты в реальности не сталкивались с такими задачами: часто их один раз решает специализированная команда, а остальная компания просто пользуется готовой инфраструктурой. В этом паттерне мы разберем ключевые идеи, которых достаточно, чтобы принимать хорошие решения на собеседовании. А дальше, возможно, однажды вы будете теми, кто построит такую систему в новом проекте.

Решение

Когда системе нужны обновления в реальном времени, push-уведомления и похожие сценарии, решение почти всегда распадается на две независимые части:

1. Первый этап: как мы распространяем обновления от сервера к клиенту?
2. Второй этап: как сервер узнает об обновлениях в источнике?

Мы разберем каждый этап отдельно, так как они включают разные компромиссы, которые работают вместе.

Протоколы соединения клиент-сервер

Первый этап - это установление эффективных каналов связи между клиентами и серверами. Хотя классический HTTP запрос-ответ работает для удивительного количества сценариев использования, системы реального времени часто нуждаются в постоянных соединениях или продвинутых стратегиях опроса (polling), чтобы позволить серверам отправлять обновления клиентам. Здесь мы углубимся в детали сетевого взаимодействия.

Основы сетей

Прежде чем сравнивать разные протоколы для обновлений в реальном времени, полезно освежить в памяти, как работают сети. Сети построены на многоуровневой архитектуре (так называемая "модель OSI"), которая сильно упрощает жизнь разработчикам приложений.

Сетевые уровни

Каждый уровень сети строится на абстракциях предыдущего уровня. Таким образом, когда вы запрашиваете веб-страницу, вам не нужно знать, какие напряжения представляют 1 или 0 на сетевом проводе - вам просто нужно знать, как использовать следующий уровень стека. Хотя полный сетевой стек увлекателен, есть три ключевых уровня, которые чаще всего встречаются на собеседованиях по System Design:

• Сетевой уровень (уровень 3): здесь находится IP, протокол, отвечающий за маршрутизацию и адресацию. Он отвечает за разбивку данных на пакеты, обработку пересылки пакетов между сетями и обеспечение доставки по принципу "best-effort" на любой целевой IP-адрес в сети. Однако гарантий нет: пакеты могут потеряться, дублироваться или переупорядочиваться.
• Транспортный уровень (уровень 4): здесь находятся протоколы TCP и UDP, которые обеспечивают сквозную (end-to-end) связь:
  • TCP - это протокол, ориентированный на соединение: прежде чем вы сможете отправить данные, вам нужно установить соединение с другой стороной. Как только соединение установлено, оно гарантирует, что данные будут доставлены корректно и по порядку. Это отличная гарантия, но она также означает, что TCP-соединения требуют времени для установления, ресурсов для поддержки и полосы пропускания для использования.
  • UDP - это протокол без установления соединения: вы можете отправлять данные на любой другой IP-адрес в сети без какой-либо предварительной настройки. Но он не гарантирует ни доставку, ни порядок.
• Прикладной уровень (уровень 7): здесь находятся прикладные протоколы, такие как DNS, HTTP, Websockets, WebRTC. Это распространенные протоколы, которые строятся поверх TCP (или UDP в случае WebRTC) и дают удобные абстракции под типичные сценарии веб-приложений.

Эти уровни работают вместе, чтобы обеспечить все наши сетевые коммуникации. Чтобы увидеть, как они взаимодействуют на практике, давайте разберем конкретный пример того, как работает простой веб-запрос.

Жизненный цикл запроса

Когда вы вводите URL в браузер, в действие вступают несколько уровней сетевых протоколов. Сначала используется DNS для преобразования доменного имени, такого как nowinterview.ru, в IP-адрес, например 12.34.56.78. Затем начинается серия тщательно скоординированных шагов: