#http #browser #push #long-polling
#http #браузер #толкать #длительный опрос
Вопрос:
Я знаю, что есть способы подделать это, опрос (или длительный опрос), но есть ли какой-либо способ заставить сервер связаться с браузером, чтобы отправить информацию?
Любой из вариантов опроса тратит ресурсы на сервере и в зависимости от сервера может заблокировать его (например, apache и iis).
Похоже, что многие сайты используют длительный опрос, чтобы подделать механизм push на стороне сервера через http. Не лучше ли было бы просто иметь встроенный в браузер протокол true push?
Какие существуют удобные для сервера варианты отправки (поддельной или иной) информации в веб-браузеры?
Ответ №1:
Я знаю, что есть способы подделать это, опрос (или длительный опрос), но есть ли какой-либо способ заставить сервер связаться с браузером, чтобы отправить информацию?
Сначала клиент должен установить соединение с сервером. Сервер не может связаться с веб-клиентом.
Любой из вариантов опроса тратит ресурсы на сервере и в зависимости от сервера может заблокировать его (например, apache и iis).
Это правильно. Частый опрос неэффективен, что является одной из причин, по которой мы переходим в мир передачи данных с постоянными соединениями. WebSockets будут лучшим решением для этого. Я работаю в Pusher, размещенном решении WebSocket в реальном времени, и мы стали свидетелями массового внедрения этой технологии сообществом, которое считает, что это лучшее решение проблемы ресурсов и связи в реальном времени.
Похоже, что многие сайты используют длительный опрос, чтобы подделать механизм push на стороне сервера через http. Не лучше ли было бы просто иметь встроенный в браузер протокол true push?
Да, именно поэтому у нас теперь есть WebSockets. HTTP-решения для веб-браузеров в конечном счете являются взломом и не работают согласованно (одинаковым образом) между браузерами.
Какие существуют удобные для сервера варианты отправки (поддельной или иной) информации в веб-браузеры?
- Длительный HTTP-опрос: соединение остается открытым до тех пор, пока сервер не получит новую информацию. Примечание: это отличается от стандартного опроса, где запросы на новую информацию могут занимать целую кучу времени.
- Потоковая передача по HTTP: вероятно, это то решение, которое вы ищете (отвечая на HTTP-вопрос). При использовании этого метода соединение остается открытым, и новые фрагменты информации могут передаваться по этому существующему соединению с сервера на клиент, без закрытия и повторного открытия соединения, как при длительном опросе HTTP.
- HTTP / 2 Server Push: Еще один стандартизированный механизм для передачи данных с сервера клиенту. Они известны как «отправленные ответы», и браузер может кэшировать их.
- WebSockets: Полная двунаправленная и полнодуплексная связь по одному TCP-соединению в веб-браузере (или любом веб-клиенте).
Связанная информация и ресурсы:
- Вы можете рассматривать события, отправляемые сервером (EventSource API), как стандартизацию HTTP-длительного опроса и HTTP-потоковой передачи.
- HTTP / 2 Серверный толчок
Ответ №2:
Um, no.
Ваш браузер не прослушивает входящие соединения.
И вы бы не хотели, чтобы это было возможно. У нас и так достаточно эксплойтов.
Комментарии:
1. Как насчет RIAs? (т. Е. настоящие RIA, такие как Flex, Silverlight, JavaFX — не огромные браузерные библиотеки JavaScript, имитирующие поведение RIA)
2. Что насчет них? Даже если бы они могли привязываться к IP: порту и принимать сокет-соединения (чего, AFAIK, они не могут), ничто извне не могло бы добраться до них (при условии, что пользователь не делает что-то глупое, например, не использует брандмауэр). Попытка поддерживать такую бессмыслицу была бы кошмаром для компании / проекта, достаточно глупого, чтобы сделать это.
3. Прошло некоторое время с тех пор, как я изучал это, и, честно говоря, я забыл некоторые детали, но я почти уверен, что они поддерживают открытое соединение для сервера, чтобы отправлять сообщения клиенту. Они не могут принимать дополнительные подключения (прослушивание сокета), как сервер, конечно (если только не работает в AIR в случае Flex), но это что-то другое.
4. «ЖК-дисплеи передают на стол настоящие push-сообщения, потому что они используют собственный протокол обмена сообщениями Adobe в режиме реального времени (RTMP) для создания постоянного соединения между собой и клиентом …» (ЖК-дисплеи — это только один из способов, есть также GraniteDS w / Flex, Red5 и BlazeDS, поддерживающие форму push)
5. Да, и вы смогли сделать ту же самую базовую вещь на Java с апплетами с 1996 года. В этом нет настоящей магии, и они, конечно же, не встроены в браузер. Использование javascript и длинного опроса (comet) в значительной степени является стандартом defacto для выполнения подобных действий, и это просто работает — не требуется плагин или раздутое adobe-ware. Тот факт, что вам время от времени приходится переподключаться, на самом деле не так уж и важен.
Ответ №3:
Если вы используете технологию RIA, такую как Adobe Flex, я полагаю, что гибкая версия «отправки сообщений с сервера» (AMF messaging) будет соответствовать вашему определению отправки сообщений с сервера.
Конечно, вы также можете использовать примитивный ajax-y (хакерский) метод опроса, но для этого нет причин, если только вас не заставят.
Ответ №4:
Вам не нужно ничего «подделывать». Во Flash есть действительно красивый и хорошо проработанный объект Socket, который работает блестяще, и вы можете написать крошечное Flash-приложение, которое взаимодействует с веб-страницей, так что вам не нужно ничего делать во Flash, кроме связи с сервером (если вы предпочитаете создавать страницу в HTML). Конечно, вам понадобится прослушиватель сокетов на стороне сервера, но их также довольно легко объединить. Множество документации в режиме онлайн о том, как реализовать все это…. Вот первый пример, который я нашел (не просматривал его слишком внимательно, но, похоже, он будет работать хорошо). http://www.giantflyingsaucer.com/blog/?p=205
Комментарии:
1. Я не вижу, что это решает проблему: приложение Flash работает на стороне клиента и подключается к серверу, а не наоборот. Вопрос заключается в том, каким образом сервер может связаться с клиентом.
2. Что ж… клиент в абсолютно любой ситуации должен сначала связаться с сервером. Но после подключения он остается подключенным (пока пользователь находится на странице) и продолжает получать сообщения от сервера. Какую ситуацию вы пытаетесь решить? Пользователь должен в какой-то момент попасть на веб-страницу, верно? Это момент, когда клиент подключается. И пока они не уйдут, сокет остается открытым (если что-то не пойдет не так). Как вы себе это представляете? (значение… на что вы надеялись?)
3. Примерно с 1996 года вы можете делать то же самое с Java-апплетом. Это все равно не «push» больше, чем длительный опрос (comet); единственная разница в том, что при длительном опросе время от времени приходится переподключаться.
4. @DrDredel Точно. Приложения Flash / Flex, не говоря уже о Java и, возможно, Silverlight. Я не понимаю, почему Брайан настаивает на том, что, поскольку Java могла делать это годами, тот факт, что Flash может это делать, не имеет значения. Очевидно, что группа по особым интересам, защищающая от плагинов «AJAX», сегодня хорошо представлена. Дело в том, что независимо от того, кто открывает соединения (в данном случае Flash), это «настоящая» передача с сервера, и это Flash. Так что Apple может принять этот факт и засунуть его. 🙂
Ответ №5:
Я бы подумал, что WebSockets (см.http://en.m.wikipedia.org/wiki/WebSocket ) является реальным push, поэтому ответ будет таким: это зависит от браузера. Если вам нужна широкая совместимость, лучшее, что вы можете сделать сегодня, — это библиотеки JavaScript, которые выберут наилучший доступный протокол для браузера, в котором он запущен (напримерhttps://github.com/ffdead/jquery-graceful-websocket ). Но вы хотели серверный интерфейс, а поддержка нескольких протоколов не подходит для сервера. Современное состояние заключается в том, что создание крутых вещей, которые работают в разных браузерах, требует больших инженерных затрат.
Комментарии:
1. Веб-сокеты, однако, не работают через HTTP. Это одно из главных преимуществ (отсутствие накладных расходов HTTP)
2. Происходит первоначальное HTTP-подтверждение. На самом деле похоже на потоковую передачу по HTTP, хотя в веб-браузерах буфер (XHR.responseText) становится очень большим, и в конечном итоге соединение нужно будет разорвать и восстановить.
Ответ №6:
Как заявляли другие, сервер не может связаться с клиентом без запроса клиента (по обычному HTTP).
Но если вы ищете чистое решение для push-уведомлений, тогда посмотрите на события, отправляемые сервером. Это обычный HTTP и работает без проблем с большинством браузеров, поддерживающих HTTP 1.1.
SSE работает только в одном направлении (сервер -> клиент), что является основным механизмом для push-уведомлений. Для связи клиент-> сервер вы всегда можете использовать Ajax. Я обобщил это в Какой технологии для связи в реальном времени для веб-приложения?
Ответ №7:
Возможно, технология продвинулась с того момента, как был задан вопрос… Я наткнулся на это в поисках чего-то другого.
WebPush доступен в большинстве браузеров, и есть несколько поставщиков Push-уведомлений, которые отправляют информацию с сервера в браузер. Кроме нескольких браузеров, таких как Safari, можно разработать обработчики, которые могут вызываться при поступлении уведомления и выполнять некоторые действия в браузере на стороне клиента.