Жесткие минусы длинного опроса?

Для интерактивных веб-приложений такие вещи, как Websockets, становятся все более популярными. Однако, поскольку клиент и мир прокси не всегда полностью совместимы, обычно используют сложную структуру, такую как "Socket.IO", скрывая несколько разных механизмов для любого случая, который может отключить другие.

Мне просто интересно, каковы недостатки правильно выполненного длительного опроса, потому что с сегодняшними серверами, такими как node.js, его довольно просто реализовать и полагается на старую технологию http, которая хорошо поддерживается (несмотря на то, что поведение самого длинного опроса может сломать его).

С точки зрения высокого уровня длительный опрос (несмотря на то, что некоторые дополнительные накладные расходы, доступные для приложений среднего трафика), похоже на истинное поведение push, как это делают WebSockets, поскольку сервер действительно посылает ему ответ, когда ему нравится (несмотря на некоторый механизм таймаута/сердцебиения).

Таким образом, у нас есть еще несколько накладных расходов из-за большего количества подтверждений TCP/IP, которые я предполагаю, но никакой постоянный трафик, такой как частый опрос, не будет.

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

Итак, есть ли еще какой-то трудный недостаток, который заставляет приложения среднего трафика, такие как чаты, использовать WebSockets, а не длительный опрос?

Ответ 1

Верхний

Он будет создавать новое соединение каждый раз, поэтому он отправит HTTP-заголовки... включая заголовок файла cookie, который может быть большим.

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

Если вы используете HTTPS, вы делаете снова и снова самую дорогую операцию, рукопожатие TLS. Производительность TLS хороша, как только соединение установлено, и симметричное шифрование работает, но процесс установления соединения, обмена ключами и всего этого джаза происходит не быстро.

Кроме того, когда соединения выполняются, записи журнала записываются где-то, счетчики где-то где-то увеличиваются, память потребляется, объекты создаются... и т.д. и т.д. Например, причина, по которой у нас разные конфигурации ведения журнала, когда в производстве и в разработке, заключается в том, что запись записей в журнале также влияет на производительность.

Присутствие

Когда длинный опрос подключен или отключен пользователем? Если вы проверите это в данный момент времени..., что будет надежным количеством времени, которое вы должны ждать, чтобы дважды проверить, чтобы убедиться, что он отключен или подключен?

Это может быть совершенно неуместно, если ваше приложение просто передает материал, но это может быть очень актуально, если ваше приложение является игрой.

Не постоянно

Это большое дело.

Так как новое соединение создается каждый раз, если у вас есть серверы с балансировкой нагрузки, в сценарии round robbin вы не можете знать, на каком сервере будет падать следующее соединение.

Когда пользовательский сервер известен, например, при использовании WebSocket, вы можете сразу отправить события на этот сервер, и сервер будет передавать их на соединение. Если пользователь отключается, сервер может сразу уведомить пользователя о том, что пользователь больше не подключен, а при повторном подключении может снова подписаться.

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

SignalR (я думаю, что это эквивалент в .NET для socket.io), например, имеет шину сообщений с именем объединительной платы, которые передают все сообщения всем серверы, как ключ для масштабирования. Поэтому, когда пользователь подключается к другому серверу, "его" ожидающие события есть "также" (!) Это "не очень плохой подход", но, как вы можете догадаться, влияет на пропускную способность:

Ограничения

Используя объединительную плату, максимальная пропускная способность сообщения ниже, чем когда клиенты разговаривают напрямую с одним сервером node. Это потому, что объединительная плата направляет каждое сообщение на каждый node, поэтому объединительная плата может становятся узким местом. Является ли это ограничение проблемой, зависит от приложение. Например, вот некоторые типичные сценарии SignalR:

Передача сервера (например, биржевой тикер): объединительные платы хорошо работают для этого сценарий, поскольку сервер контролирует скорость, с которой отправлено.

Клиент-клиент (например, чат): в этом случае объединительная плата может быть узким местом, если количество сообщений масштабируется с количеством клиенты; то есть, если скорость сообщений растет пропорционально больше клиенты присоединяются.

Высокочастотное реальное время (например, в режиме реального времени): объединительная плата не является рекомендуется для этого сценария.

Для некоторых проектов это может быть showstopper.

Некоторые приложения просто транслируют общие данные, но другие имеют семантику соединения, например, например, многопользовательскую игру, и важно отправить правильные события в правильные соединения.

ИМХО

Длинный опрос - хорошее решение для небольших проектов, но стало большой нагрузкой для высоко масштабируемых приложений, которым требуется высокая скорость и/или очень сегментированная отправка событий.