Извините за то, что поднял этот вопрос, но я верю, что многие сталкиваются с этой веткой, и принятый ответ, ИМХО, по крайней мере устарел, если не сказать, что вводит в заблуждение.
В порядке приоритета я бы обозначил это следующим образом:
1) WebSockets является решением в настоящее время. У меня лично был опыт внедрения WebSockets в корпоративных приложениях. Все основные браузеры (Chrome, Firefox, IE - в алфавитном порядке :)) изначально поддерживают WebSockets . Все основные серверы / сервлеты (IIS, Tomcat, Jetty) одинаковы, и в Java существует множество платформ, реализующих API JSR 356 . Там есть проблема с прокси, особенно в облачном развертывании. Тем не менее, существует высокая осведомленность о требованиях WebSockets, поэтому NginX поддержал их уже 1,5 года назад. В любом случае, защищенный протокол 'wss' решает проблему с прокси на 99,9% (а не на 100%, просто чтобы быть в безопасности, никогда сам этого не испытывал).
2) Длинный опрос , вероятно, является вторым лучшим решением, и часть «вероятно» связана с альтернативой «короткого опроса». Говоря о длительных опросах, я имею в виду повторный запрос от клиента к серверу, который отвечает, как только появляются какие-либо данные. Таким образом, один опрос может закончиться за несколько миллисекунд, другой - до максимального времени ожидания.
Обязательно ограничьте время опроса чем-то меньшим, чем 2 минуты, так как обычно в противном случае вам придется управлять ошибкой тайм-аута на стороне клиента. Я бы предложил ограничить время опроса до десятков секунд.
Конечно, после завершения опроса (своевременно или до этого) он немедленно повторяется (но лучше установить какой-нибудь простой протокол и дать вашему серверу возможность сказать клиенту - «приостановить»).
Недостатки длинного опроса, который, по-моему, оправдывает продолжение списка, состоят в том, что он содержит одно из немногих (4, 8 - все же не так много) разрешенных соединений, что браузер позволяет устанавливать каждую страницу на сервере. Таким образом, это может поглотить ~ 12% до ~ 25% клиентского трафика вашего сайта.
3) Короткий опрос не так сильно любим многими, но иногда я предпочитаю это. Основными минусами этого, конечно же, является высокая нагрузка на браузер и сервер при установлении новых соединений. Тем не менее, я считаю, что при правильном использовании пулов соединений эти накладные расходы значительно меньше, чем кажется на первый взгляд.
4) Потоковая передача HTTP , будь то потоковая передача страниц через IFrame или потоковую передачу XHR, - это, ИМХО, решение BAD , поскольку это как накопление всех остальных больше:
вы будете держать открытыми соединения (ресурсы браузера и сервера);
вы по-прежнему будете съедать общий лимит клиентского трафика;
самое зло: вам нужно спроектировать / реализовать (или повторно использовать дизайн / реализацию) фактическую доставку контента, чтобы можно было отличить новый контент от старого один (будь то пушинг скриптов, о боже! Или отслеживание длины накопленного контента). Пожалуйста, не делайте этого.
Обновление (20/02/2019)
Если WebSockets не доступны - Отправленные сервером события - второй лучший вариант IMHO - браузеры эффективно реализовали потоковую передачу HTTP для вас здесь на более низком уровне.