Short Polling vs Long Polling: донимать пустыми запросами или ждать у моря погоды
Не так давно писал спеку по фиче, которая предполагает передачу данных в режиме реального времени. Не вдаваясь в детали, это разработка микросервиса, который определенным образом монтирует видео и было требование того, чтобы на UI в режиме реального времени видеть статус обработки. 🎬
Изначально для этой цели я предполагал использовать WebSocket: открывать канал связи и получать сообщения напрямую с сервера, однако после обсуждения с архитектурной командой было принято решение, что держать открытыми соединения по каждой заявке на монтаж видео лишь для того, чтобы красиво рисовать полоску загрузки на экране... Охренеть как Немного расточительно. 👌 Поэтому про WebSocket пост будет как-нибудь потом, а сегодня мы поговорим про Polling.
Polling — это в некотором смысле имитация обмена данными в режиме real-time, можно сказать в режиме псевдо-реального времени. Мы не передаем сообщение напрямую с сервера на клиент, клиент запрашивает данные с сервера, но делает он это автоматически с заданной регулярностью. Есть две концепции: Short Polling и Long Polling.
Short Polling — клиент с заданным интервалом (например, каждые 2 секунды) отправляет на сервер запрос по схеме «Есть ли что-нибудь новое?». Сервер всегда сразу отвечает — либо с новыми данными, либо с пустым ответом. Представим себе ребенка в машине, который с интервалом отправляет запрос спрашивает маму за рулем:
Он будет спрашивать это вне зависимости от того, молчит ли мама или уже рявкнула на него:
Long Polling — Клиент отправляет запрос, сервер не отвечает сразу, а «замораживает» запрос до тех пор, пока не произойдет нужное событие ИЛИ не истечет таймаут (например, 30 секунд). Как только событие происходит, сервер немедленно отправляет ответ клиенту. Клиент, получив ответ, тут же отправляет следующий запрос. По аналогии с предыдущим примером, это ребенок, случайно хлебнувший утром батиного чая с коньяком и поэтому он задает вопрос бате за рулем и спокойно ждет ответа, пока на стороне сервера таймаут:
После паузы батя отвечает и лишь после этого задается новый вопрос (надеюсь он не пил тот чай с коньяком, прежде чем сесть за руль).
Философское завершение: выбор между подходами — это классический компромисс между простотой и эффективностью.
P.S. Современными альтернативами для обоих подходов являются WebSocket (для двусторонней постоянной связи), его мы уже упоминали сегодня, Server-Sent Events (SSE) (для потоковой передачи данных от сервера к клиенту), gRPC Streaming и некоторые другие технологии, но везде есть свои нюансы и их мы обсудим в другой раз. 🔗
#системныйанализ #Архитектура #WebDevelopment #websocket #HTTP #интеграции
Не так давно писал спеку по фиче, которая предполагает передачу данных в режиме реального времени. Не вдаваясь в детали, это разработка микросервиса, который определенным образом монтирует видео и было требование того, чтобы на UI в режиме реального времени видеть статус обработки. 🎬
Изначально для этой цели я предполагал использовать WebSocket: открывать канал связи и получать сообщения напрямую с сервера, однако после обсуждения с архитектурной командой было принято решение, что держать открытыми соединения по каждой заявке на монтаж видео лишь для того, чтобы красиво рисовать полоску загрузки на экране... Охренеть как Немного расточительно. 👌 Поэтому про WebSocket пост будет как-нибудь потом, а сегодня мы поговорим про Polling.
Polling — это в некотором смысле имитация обмена данными в режиме real-time, можно сказать в режиме псевдо-реального времени. Мы не передаем сообщение напрямую с сервера на клиент, клиент запрашивает данные с сервера, но делает он это автоматически с заданной регулярностью. Есть две концепции: Short Polling и Long Polling.
Short Polling — клиент с заданным интервалом (например, каждые 2 секунды) отправляет на сервер запрос по схеме «Есть ли что-нибудь новое?». Сервер всегда сразу отвечает — либо с новыми данными, либо с пустым ответом. Представим себе ребенка в машине, который с интервалом отправляет запрос спрашивает маму за рулем:
"Мы уже приехали? Мы уже приехали?"
Он будет спрашивать это вне зависимости от того, молчит ли мама или уже рявкнула на него:
"ЕЩЕ НЕТ!" 💥
Long Polling — Клиент отправляет запрос, сервер не отвечает сразу, а «замораживает» запрос до тех пор, пока не произойдет нужное событие ИЛИ не истечет таймаут (например, 30 секунд). Как только событие происходит, сервер немедленно отправляет ответ клиенту. Клиент, получив ответ, тут же отправляет следующий запрос. По аналогии с предыдущим примером, это ребенок, случайно хлебнувший утром батиного чая с коньяком и поэтому он задает вопрос бате за рулем и спокойно ждет ответа, пока на стороне сервера таймаут:
"Сколько времени нам еще ехать?"
После паузы батя отвечает и лишь после этого задается новый вопрос (надеюсь он не пил тот чай с коньяком, прежде чем сесть за руль).
Философское завершение: выбор между подходами — это классический компромисс между простотой и эффективностью.
P.S. Современными альтернативами для обоих подходов являются WebSocket (для двусторонней постоянной связи), его мы уже упоминали сегодня, Server-Sent Events (SSE) (для потоковой передачи данных от сервера к клиенту), gRPC Streaming и некоторые другие технологии, но везде есть свои нюансы и их мы обсудим в другой раз. 🔗
#системныйанализ #Архитектура #WebDevelopment #websocket #HTTP #интеграции