Асинхронный HTTP, но не AJAX
Макс ИщенкоОпубликовано 27.04.2006 в Статьи
Одна из особенностей протокола HTTP – “пассивность” сервера, который только обслуживает входящие запросы клиентов, но сам не является инициатором соединения с клиентом. Такая особенность, наверное, была одной из составляющей успеха Web/HTTP ввиду простоты реализации и хорошей масштабируемости.
Вместе с тем, некоторым веб-приложениям очень помогла бы возможность оперативного получения сообщений от сервера. Например, той же программе для управления дефектами, веб-чата и многим другим.
Традиционно такого рода проблемы решались нажатием клавиши F5 (Refresh) и/или использованием тега META Refresh. С распространением технологии AJAX стало легко запрашивать необходимые биты информации без перезагрузки основной страницы, канонический пример – обновление Inbox в Gmail.
Как скажет вам любой программист, использовавший select(2), постоянный опрос объекта (polling) часто является очень неэффективной стратегией. Избежать постоянного опроса сервера в HTTP можно при помощи т.н. технологии HTTP Streaming или Comet.
Идея проста: открыть и поддерживать дополнительное TCP/IP соединение между сервером и клиентом, куда сервер будет по необходимости “сбрасывать” новые сообщения, а клиент (браузер) – их получать и соответствующим образом обрабатывать. При этом с точки зрения конечного пользователя, браузер реагирует на изменения на сервере практически “мгновенно”.
С технической точки зрения это реализуется созданием отдельного XMLHttpRequest на клиенте и командами write(2)/flush(2) на сервере. Есть даже несколько коммерческих и открытых реализаций (например, LivePage из Twisted).
Главный минус такой технологии – ее “чужеродность” духу протокола HTTP.
Как следствие, ее применение с mainstream веб-серверами типа Apache не эффективно и плохо масштабируется. (Да, HTTP 1.1 предполагает поддержку pipelining но в этом случае рекомендуют ставить таймаут для таких соединений в 2-3 секунды, а никак не “вечность”).
С другой стороны, развертывание в интранет и/или использование специализированного веб-сервера может нивелировать этот минус, оставив только минусы поменьше (заметное усложнение клиентского и серверного кода) и бесспорные плюсы (”мгновенное” оповещение клиента).
Понравилась статья? Подпишись на обновления по RSS/E-mail


(5 голосов, средний: 3.6 из 5)
Опробовано. Работает под IIS очень хорошо. Больше всего проблема при работе через прокси, но если нормально реагировать на таймаут работает. Не работает хорошо с загрузкой картинок, так как IE странно себя ведет когда 1 конекшин с 2 занят.