Как http-сервер будет обрабатывать веб-сокеты html5? - PullRequest
4 голосов
/ 08 июля 2010

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

Но мы продолжаем читать о Chrome, Opera, Firefox, Safariготовимся к html5.Какой веб-сервер готов использовать функцию веб-сокетов?Я имею в виду, способны ли веб-серверы инициировать последующее общение с сегодняшнего дня?Как насчет собственного Appengine от Google?

Как написать пример веб-приложения, использующего эту функцию в Java?

Ответы [ 2 ]

10 голосов
/ 08 июля 2010

Двунаправленная связь между веб-серверами и браузерами не является чем-то новым.Переполнение стека делает это сегодня, если новый ответ опубликован на вопрос, который вы читаете.Существует несколько различных стратегий реализации поведения в стиле сокетов с использованием существующих технологий:

  • Краткий опрос AJAX: подключитесь к серверу и спросите, есть ли какие-либо новые сообщения.Если нет, немедленно отключитесь и повторите запрос через короткий промежуток времени.Это полезно, когда вы не хотите оставлять много длительных незанятых соединений открытыми для сервера, но это означает, что вы будете получать новые сообщения только так быстро, как ваш интервал опроса, и вы будете вынуждены устанавливатьновое HTTP-соединение каждый раз при опросе.
  • Длинный опрос AJAX: подключитесь к серверу и оставьте соединение открытым, пока не будет доступно новое сообщение.Это дает вам быструю доставку новых сообщений и менее частые HTTP-соединения, но приводит к более длительным бездействующим процессам на сервере.
  • Длинный опрос iframe: То же, что и выше, только со скрытым iframe вместоОбъект XHR.Полезно для обхода политики одного и того же источника, когда вы хотите выполнять межсайтовый длинный опрос.
  • Плагины: FlashSocket XMLSocket, Java-апплеты и т. Д. Могут быть использованы для установления чего-то более близкого к настоящему низкоуровневому постоянному.Сокет для браузера.

Сокеты HTML5 на самом деле не изменяют доступные стратегии.В основном они просто формализуют стратегии, которые уже используются, и позволяют явно идентифицировать постоянные соединения и, таким образом, обрабатывать их более разумно.Допустим, вы хотите отправлять push-сообщения через Интернет в мобильный браузер.При обычном продолжительном опросе мобильное устройство должно оставаться в активном состоянии, чтобы сохранить соединение.С помощью WebSockets, когда мобильное устройство хочет перейти в спящий режим, оно может передать соединение с прокси-сервером, а когда прокси-сервер получает новые данные, оно может разбудить устройство и передать обратно сообщение.

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

Реализация длинного опроса на стороне сервера - это то место, где ваш выбор начинает сужаться.Большинство HTTP-серверов предназначены для кратковременных запросов: подключиться, запросить ресурс, а затем отключиться.Если 300 человек посещают ваш сайт за 10 минут, и каждому требуется 2 секунды для подключения и загрузки ресурсов HTTP, на вашем сервере в среднем будет открыто 1 соединение HTTP в любой момент времени.С длинным приложением опроса вы внезапно получаете в 300 раз больше соединений.

Если вы используете свой собственный выделенный сервер, вы можете справиться с этим, но на платформах с общим хостингом вы, вероятно,столкнуться с ограничениями ресурсов, и App Engine не является исключением.App Engine предназначен для обработки большого количества запросов с низкой задержкой, например, коротких опросов.Вы можете реализовать длительный опрос в App Engine, но это не рекомендуется;запросы, которые выполняются дольше 30 секунд, будут прерваны, а длительные процессы сожрут квоту вашего процессора.

Решением App Engine для этого является предстоящий Channel API.API канала реализует длительные опросы с использованием существующей надежной инфраструктуры XMPP от Google.

Доклад Бретта Бавара и Мойши Леттвина о вводе / выводе Google излагает схему использования следующим образом:

ПриложениеПриложения движка создают канал на удаленном сервере и возвращают идентификатор канала, который они передают в веб-браузер.

class MainPage(webapp.RequestHandler):

    def get(self):
        id = channel.create_channel(key)
        self.response.out.write(
            {'channel_id': id})

Веб-браузер передает идентификатор канала на тот же удаленный сервер, чтобы установить соединениес помощью длинного опроса iframe:

<script src='/_ah/channel/jsapi'></script>
<script>
  var channelID = '{{ channel_id }}';
  var channel =
    new goog.appengine.Channel(channelId);
  var socket = channel.open();
  socket.onmessage = function(evt) {
    alert(evt.data);
  }
</script>

Когда происходит что-то интересное, приложение App Engine может отправить сообщение на канал пользователя, и длинный запрос браузера немедленно его получит:

class OtherPage(webapp.RequestHandler):

    def get(self):
        # something happened
        channel.send_message(key, 'bar')
3 голосов
/ 08 июля 2010

Jetty, например, поддерживает эту функцию начиная с версии 7: Jetty Websocket Server

Google App Engine также планирует это.У них даже есть рабочая демонстрация этого на Google I / O 2010, но она еще не запущена.Смотрите билет # 377

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...