Что же, спрашивается, ReverseHTTP и почему это было бы полезно?
reversehttp.net предлагает мало непосредственного понимания, что действительно reversehttp и как это может быть лучше всего использовано, это заставляет его казаться, что этот инструмент слишком трудно реалистично реализовать. В каких видах сред это могло бы быть идеальной веб-ситуацией с данными в реальном времени и когда это не работало бы, Какие браузеры поддерживают этот метод, и Что это точно?
- Что делает reversehttp уникальный из других реализаций НАЖАТИЯ?
Спасибо любому, кто может помочь и в первую очередь услышал об этом, и знает, каково это.
4 ответа
Обратный HTTP - это способ для клиента поддерживать открытое соединение с веб-сервером, чтобы веб-сервер мог отправлять обновления клиенту (вместо того, чтобы клиент постоянно запрашивал обновления).
Возьмем, к примеру, свой классический клиент Twitter.
В настоящее время клиент периодически спрашивает Twitter, есть ли у вас обновления. Если нет, то это напрасный запрос.
С такой технологией, как Reverse HTTP, как только вы установите соединение с Twitter ... Twitter сможет отправлять вам обновления, когда они произойдут, сэкономив как вам, так и Twitter некоторую пропускную способность, накладные расходы и немного усилий.
Обратный HTTP работает путем запуска веб-сервера в браузере, с которым сервер взаимодействует.
Существуют аналогичные технологии, которые достигают той же цели более безопасным и надежным способом. Microsoft.NET реализует эти виды служб как службы двустороннего связывания в WCF, сохраняя соединение между клиентом и сервером открытым после его создания (вместо запуска отдельного сервера на клиенте). Также есть технология под названием Comet, которая позволяет то же самое.
Из просмотра некоторых демонстраций ( например этот ) похоже, что он построен поверх стандартного интерфейса в стиле кометы. Реализация просто представляет собой законченный HTTP-сервер для клиента.
Итак, в вашем javascript "похоже", что вы размещаете веб-сервер, который отвечает на запросы для " http://reversehttp.net/demo12345/ ", но на самом деле запросы выполняются туннелируется с «настоящего» веб-сервера через запросы кометы к клиенту javascript, запущенному в браузере, и обратно.
При таком описании это кажется довольно неэффективным, но если учесть, что в большинстве ситуаций клиент и сервер будут работать на одном компьютере (так что только два компьютера общаются друг с другом), то в основном неэффективность исчезает.
Я просмотрел источник обратного HTTP, с которым вы связались. Реализация состоит из двух частей:
HTTP-ретранслятор. Этот размещен на сайте
reversehttp.net. Он просто ожидает запросов к определенному URL-адресу (созданному) и перенаправляет его в канал (см. 2). Затем он ожидает на другом канале (см. 2) и пересылает его запрашивающей стороне.Сервер HTTP JavaScript. «Клиент-сервер» опрашивает «сервер-сервер» на наличие любых входящих запросов с использованием Ajax. Затем, когда вы запросили URL-адрес на «сервере-сервере», и он был перенаправлен на канал, он будет отправлен на «клиентский сервер». Затем клиентский сервер проанализирует исходный HTTP-запрос из запроса на шаге 1, создаст ответ (HTTP-ответ).Этот ответ будет отправлен обратно на «сервер-сервер», который попадает в канал, который отправляет фактический ответ обратно запрашивающей стороне.
Это вовсе не хостинг реального HTTP-сервера на клиенте. Для этого требуется открытый порт 80, которого нет у большинства людей. Если вы находитесь за NAT или брандмауэром, он будет заблокирован в любом случае, если он настроен правильно.
Думаю, лучше использовать длинный опрос или Comet, чем это. Накладные расходы на синтаксический анализ заголовков HTTP на клиенте довольно громоздки.
В спецификации описан способ ретрансляции HTTP-запросов. Это будет сделано путем установки заголовка Content-Type любого запроса к «серверу-серверу» на message / http . Я думаю, что в любом случае есть лучшие решения для проксирования или ретрансляции HTTP-запросов, просто изменив поле Host в поле to-be-relayed-to, добавив специальное поле, которое содержит некоторую ссылку на исходного отправителя и путь он прошел и отправил измененный HTTP-запрос следующему серверу. Затем получатель просто отправит запрос обратно, а получатель ищет специальное поле, извлекает его источник и передает ответ дальше по цепочке.
Просто просматриваю страницу: я считаю, что вместо, скажем, опроса веб-браузера обновлений и извлечения любых новых данных, веб-сервер вместо отправляет Новые данные о клиенте, когда они становятся доступными.
Для приложений, которым требуется быстрый ответ на любые новые данные, это устранит большой объем трафика, вызванный повторным опросом.