Есть ли реальный серверный пуш через http?

Question

Я знаю, что есть способы подделать это, опрос (или длительный опрос), но есть ли способ заставить сервер связаться с браузером, чтобы вытолкнуть информацию?

Любой вариант опроса тратит ресурсы на сервер ив зависимости от сервера его можно заблокировать (например, apache и iis).

Похоже, что многие сайты используют длинные опросы для фальсификации механизма push на стороне сервера через http.Разве не было бы лучше иметь настоящий протокол push, встроенный в браузер?

Какие есть варианты, которые удобны для сервера для передачи (поддельной или иной) информации в веб-браузеры?

Answer 1

Я знаю, что есть способы подделать это, опрос (или длительный опрос), но есть ли способ заставить сервер связаться с браузером, чтобы вытолкнуть информацию?

Сначала клиент должен установить соединение с сервером. Сервер не может связаться с веб-клиентом.

Любой вариант опроса тратит ресурсы на сервере и в зависимости от сервера может заблокировать его (например, apache и iis).

Это верно. Частые опросы неэффективны , что является одной из причин, по которой мы движемся в мир с постоянными связями. WebSockets будет лучшим решением для этого. Я работаю в Pusher , размещенном в режиме реального времени решении WebSocket, и мы наблюдаем массовое внедрение этой технологии в сообществе, которое считает, что это лучшее решение проблемы ресурсов и связи в реальном времени.

Похоже, что многие сайты используют длинные опросы для имитации механизма проталкивания на стороне сервера через http. Разве не было бы лучше иметь настоящий протокол push, встроенный в браузер?

Да, именно поэтому у нас теперь есть WebSockets. HTTP-решения для веб-браузеров в конечном итоге являются хаком и не работают согласованно (одинаково) между браузерами.

Какие есть варианты, которые удобны для сервера для передачи (поддельной или иной) информации в веб-браузеры?

• HTTP Long-Polling : Соединение остается открытым, пока на сервере не появится новая информация. Примечание: это отличается от стандартного опроса, где запросы на новую информацию могут быть пустой тратой времени.
• HTTP Streaming : Вероятно, это решение, которое вы ищете (отвечая на вопрос HTTP). Используя эту технику, соединение остается открытым, и новые фрагменты информации могут передаваться по существующему соединению от сервера к клиенту без закрытия и повторного открытия соединения, как это происходит при использовании длинного опроса HTTP.
• HTTP / 2 Server Push : еще один стандартизированный механизм для передачи с сервера на клиент. Они известны как «выдвинутые ответы», и браузер может их кэшировать.
• WebSockets : Полная двунаправленная и дуплексная связь через одно TCP-соединение в веб-браузере (или любом веб-клиенте).

Информация, связанная с данной:

1. Вы можете считать события, отправленные сервером (API-интерфейс EventSource ), как стандартизацию HTTP-длинного опроса и HTTP-потоковой передачи.
2. HTTP / 2 Server Push

Answer 2

Гм, нет.

Ваш браузер не прослушивает входящие соединения.

И вы не хотели бы, чтобы это было возможно.У нас достаточно подвигов как есть.

Answer 3

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

WebPush доступен в большинстве браузеров, и есть несколько поставщиков push-уведомлений, которые отправляют информацию с сервера в браузер. Помимо нескольких браузеров, таких как Safari, можно разработать обработчики, которые можно вызывать при получении уведомления и выполнять некоторые действия в браузере на стороне клиента.

Answer 4

Как утверждали другие, для сервера невозможно связаться с клиентом без запроса клиента (по обычному HTTP).

Но если вы ищете чистое решение для push notificatinons , тогда посмотрите на Отправленные сервером события .Это обычный HTTP и работает без проблем с большинством браузеров, которые поддерживают HTTP 1.1.

SSE работает только в одном направлении (сервер -> клиент), который является основным механизмом для push-уведомлений .Для связи клиент-сервер вы всегда можете использовать Ajax.Я кратко изложил это в Какая технология для связи в реальном времени для веб-приложения?

Answer 5

Я бы подумал, что WebSockets (см. http://en.m.wikipedia.org/wiki/WebSocket) - это настоящий толчок, поэтому ответ будет таким: он зависит от браузера. Если вам нужна широкая совместимость, лучшее, что вы можете сделать сегодня, - это библиотеки JavaScript, которые будут выбиратьлучший доступный протокол для браузера, в котором он работает (например, https://github.com/ffdead/jquery-graceful-websocket). Но вы хотели, чтобы он был дружественным к серверу, а поддержка нескольких протоколов не дружественна к серверу. Современный уровень техники заключается в том, что делать классные вещи, которые работают черезбраузеры - инженерно-интенсивный.

Answer 6

Вам не нужно ничего "подделывать".Flash имеет действительно красивый и хорошо продуманный объект Socket, который прекрасно работает, и вы можете написать крошечное маленькое приложение Flash, которое обращается к веб-странице, поэтому вам не нужно ничего делать во Flash, кроме связи с сервером(если вы предпочитаете строить страницу в HTML).Конечно, вам потребуется прослушиватель сокетов на стороне сервера, но их также довольно легко собрать вместе.Много документации в Интернете о том, как реализовать все это ... Вот первый пример, который я нашел (не рассматривал его слишком внимательно, но похоже, что он будет работать хорошо).http://www.giantflyingsaucer.com/blog/?p=205

Answer 7

Если вы используете технологию RIA, такую ​​как Adobe Flex, я полагаю, что версия Flex для сервера (AMF-сообщения) будет соответствовать вашему определению сервера.

Конечно, вы также можете сделатьпримитивный метод опроса ajax-y (hacky), но нет никаких причин, если вас не заставят.