long polling что это
Простая реализация long polling механизма на PHP
Теория
Итак, что же из себя представляет Long Polling?
Выглядит это примерно следующим образом:
1) Клиент отсылает на сервер обычный ajax-запрос
2) Сервер, вместо того, чтобы быстро обработать этот запрос и отправить ответ клиенту, запускает цикл, в каждой итерации которого следит за возникновением событий (другой клиент добавил запись или удалил).
3) При возникновении события сервер генерирует ответ и отсылает его клиенту, таким образом завершая запрос.
4) Клиент, получив ответ от сервера, запускает обработчик события и параллельно отправляет очередной «длинный» запрос серверу.
То есть всё довольно просто и понятно. Однако, при реализации возникает несколько вопросов, которые нужно решить.
Шаги к практике
В первую очередь возникает вопрос о том, как скрипты будут взаимодействовать друг с другом. Ведь на каждый запрос клиента к серверу создаётся независимая копия PHP-скрипта. То есть нужна какая-то общая память для хранения данных о событиях.
Традиционный вариант — запускается демон, который оперирует событиями и держит соединение с клиентами. Использование демона естественным образом решает проблему памяти. Клиенты обращаются для получения событий не на веб-сервер, а к демону. В то же время, клиент, инициализирующий событие, также сообщает демону, что произошло событие. И таким образом всё крутится в памяти этого демона. который вообще может быть написан на чём угодно.
Но нам, в виду шила в одном месте и желания обойтись без сторонних приложений, демон на чём угодно не подойдёт. А писать демона на PHP, на мой вкус, не слишком интересно. У хостера могут быть проблемы с изменением максимального времени работы скрипта, а ещё продумывать интерфейсы взаимодействия клиентов с этим демоном… Нет, мы пойдём другим путём.
А остаётся только решить, как реализовать общую память в самом PHP. В голову приходят варианты хранения событий в файлах и БД, но хочется-то, чтобы всё было поближе — в памяти. Memcache нам, увы недоступен, а что тогда делать? А есть в php такое понятие как shared memory, точнее понятие-то не является особенностью этого языка, но нам дают возможность этим пользоваться. Механизмы этой технологии позволяют нам создать ячейку в оперативной памяти и использовать её в своих целях. Вот её я и буду использовать.
Практика
Попробуем представить интерфейс класса, который будет реализовывать нужный нам функционал.
Какие нужны методы?
1) Естественно, метод «прослушки», который будет вызываться, когда клиенты будут посылать polling-запросы, и следить за возникающими событиями. Я назвал этот метод listen.
2) Кроме того нам понадобится метод, который будет создавать событие. Этот метод носит имя push.
3) Вполне вероятно, что мы захотим обработать данные о событии, прежде чем отправить результат клиенту. Поэтому я добавил метод, который регистрирует событие и связывает с ним обработчик. Называется метод registerEvent.
В итоге получаем такой интерфейс класса:
Несколько примечаний:
1) В методе registerEvent поддерживается только по одному обработчику на событие по причине того, что возвращаемое обработчиком значение возвращается клиенту как данные события. В одном обработчике можно вызвать несколько функций и из результата их работы собрать ответ клиенту. Впрочем переделать код для поддержки нескольких обработчиков можно без особых затруднений.
2) В методе listen используется параметр lastQueryTime, который позволяет обработать события, возникшие раньше, чем поступил запрос на прослушку. Это может пригодиться когда нагрузка на сеть высока и между завершением одного polling-запроса от клиента и началом другого может пройти заметный промежуток времени, в который возникают события.
3) В приведённом коде не учитывается одновременный доступ к памяти. А вообще. для более надёжной работы желательно использовать семафоры.
4) В методе listen используется вызов функции sleep(1). Это нужно для того, чтобы уменьшить количество холостых итераций. Частоты обновления раз в секунду вполне достаточно для имитации реалтайма.
Ну и на клиенте всё также предельно просто. Нам нужен метод, который будет посылать polling-запрос серверу, ждать ответ, запускать обработчики событий и заново посылать запрос. Ну и метод, регистрирующий сами обработчики событий.
Исходники:
Описанный класс Polling на PHP.
Если кому-нибудь понадобится, приведу в порядок и выложу клиентскую часть.
Long Polling от А до Я своими руками
Как реализовать long polling с помощью Nginx и Javascript в сети достаточно много материала. Но полного руководства я ещё не встречал. То возникают проблемы с компиляцией модуля под Nginx, то в браузере вертится иконка загрузки при long poll запросах. Под катом, полный материал как же все таки это сделать правильно.
Компиляция Nginx модуля под linux
Для поддержки long polling подключений в сервере Nginx, реализован замечательный модуль nginx-push-stream-module. Так как он не входит в официальную поставку, его нужно скачать, настроить и скомпилировать вместе с Nginx.
Перед этим у вас должны быть установлены все необходимые пакеты
Далее нужно скачать сам модуль nginx-push-stream-module, nginx и скомпилировать их вместе.
Клонируем проект из GIT
Скачиваем и распаковываем последний nginx
Настраиваем и компилируем nginx вместе с nginx-push-stream-module
Если нет ошибок компиляции, все готово. Проверим, что мы установили именно тот nginx и то, что теперь в нем действительно есть модуль nginx-push-stream-module
После выполнения этих команд, вы должны увидеть такое:
Настройка Nginx для Long Polling подключений
Для настройки поддержки long polling, в конфигурации Nginx, нужно прописать как минимум два контроллера. Первый для подписчиков (тех кто будет получать сообщения), второй для публикации сообщений (тех кто будет посылать сообщения).
Опуская настройку остальных параметров сервера, конфигурационный файл /usr/local/nginx/nginx.conf должен выглядеть так:
В данном примере /pub — адрес для публикации сообщений, его должен видеть только ваш сервер (1.1.1.1), от которого приходят события, /sub — адрес для подписчиков, тех кому будут пересылаться сообщения. Идентификатор, который будет идентифицировать подписчиков, передается после /sub, и принимается как параметр id в /pub.
Об очень важных параметрах push_stream_last_received_message_tag и push_stream_last_received_message_time речь пойдет ниже, когда коснемся javascript.
Пример для понимания работы:
Можно создать несколько подписчиков, вызвав: stream.example.com/sub/1, stream.example.com/sub/2, stream.example.com/sub/3. Каждый из них будет «висеть» на Nginx сервере в течении 25 секунд (push_stream_longpolling_connection_ttl). Если мы вызовем POST запрос на stream.example.com/pub?id=2 и передадим в теле сообщение «Hello», то подписчик «висящий» на /sub/2, получит ответ «Hello». Удобно проверять это в плагине Poster для FireFox.
Создание подписчиков в Javascript
Скорее всего, long polling вам нужно использовать для обновления каких-либо данных в браузере, и для этого вам понадобится написать Javascript клиента.
Пускай в переменной subID — хранится уникальное значение для подписчика
Важно сказать о двух параметрах etag и time.
Без них long polling работал далеко не всегда и сообщения приходили через раз. Эти два параметра, нужны модулю nginx-push-stream-module, для идентификации сообщений, которые ещё не получил подписчик. Так что для стабильной работы это просто необходимо.
Что такое Long-Polling, WebSockets, SSE и Comet
Недавно один из подписчиков спросил, как работают уведомления вконтакте? Или других высоконагруженных проектах, ведь они приходят мгновенно и, если использовать обычный ajax, то сервер достаточно быстро упадет. Вот о том, какие существуют способы реализации данного функционала, мы и поговорим в сегодняшней статье.
Для начала рассмотрим, как вообще идет http запрос при обычной работе
Regular http
1. Клиент посылает запрос на вебстраницу к серверу
2. Сервер формирует ответ
3. Сервер посылает ответ клиенту
AJAX Polling
1. Клиент посылает запрос на вебстраницу серверу, используя обычный http(regular http)
2. Запрошенная страница выполняет JavaScript, который запрашивает файл от сервера через какой-то интервал времени(например, 0.5 секунд)
3. Сервер формирует ответ для каждого запроса и отсылает его обратно
AJAX Long-Polling
1. Клиент запрашивает страницу у сервера, используя обычный http
2. Запрошенная страница выполняет JavaScript, который запрашивает файл от сервера.
3. Сервер НЕ реагирует на запрошенную информацию и ждет, пока не появится новой информации
4. Когда появляется новая информация, сервер отсылает ее клиенту
5. Клиент получает новую информацию и НЕМЕДЛЕННО отсылает другой запрос серверу, запуская процесс ожидания на нем снова.
HTML5 Server Sent Events(SSE)
1. Клиент запрашивает страницу у сервера, используя обычный http
2. Запрошенная страница выполняет JavaScript, который открывает соединение с сервером
3. Сервер посылает событие клиенту, когда появляется новая информация
HTML5 WebSockets
1. Клиент запрашивает страницу у сервера, используя обычный http
2. Запрошенная страница выполняет JavaScript, который открывает соединение с сервером
3. Сервер и клиент могут посылать друг другу сообщения, когда новая информация доступна(либо на сервере, либо на клиенте)
Comet
Итак, мы рассмотрели возможные способы реализации данного функционала. У каждого способа есть как свои плюсы, так и свои минусы. Однако, сейчас лучшим и быстро развивающимся способом считается WebSockets. Но помните, что HTML5 поддерживают только современные браузеры и про старые, увы, придется забыть, если вы будете использовать сокеты.
В ближайшее время я буду писать статьи про каждый из этих способов, так что подписывайтесь на обновления сайта, чтобы не пропустить! 🙂
Спасибо за внимание и удачного вам кодинга!
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Комментарии ( 4 ):
Вот теперь ясно! Спасибо 🙂
тоесть непрерывного айфрейма больше не существует по вашему?
Было бы не плохо посмотреть пример
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Copyright © 2010-2021 Русаков Михаил Юрьевич. Все права защищены.
Длинные опросы
Длинные опросы – это самый простой способ поддерживать постоянное соединение с сервером, не используя при этом никаких специфических протоколов (типа WebSocket или Server Sent Events).
Его очень легко реализовать, и он хорошо подходит для многих задач.
Частые опросы
Самый простой способ получать новую информацию от сервера – периодический опрос. То есть, регулярные запросы на сервер вида: «Привет, я здесь, у вас есть какая-нибудь информация для меня?». Например, раз в 10 секунд.
В ответ сервер, во-первых, помечает у себя, что клиент онлайн, а во-вторых посылает весь пакет сообщений, накопившихся к данному моменту.
Это работает, но есть и недостатки:
Так что, если речь идёт об очень маленьком сервисе, подход может оказаться жизнеспособным, но в целом он нуждается в улучшении.
Длинные опросы
«Длинные опросы» – гораздо лучший способ взаимодействия с сервером.
Они также очень просты в реализации, и сообщения доставляются без задержек.
Как это происходит:
Для данного метода ситуация, когда браузер отправил запрос и удерживает соединение с сервером в ожидании ответа, является стандартной. Соединение прерывается только доставкой сообщений.
Если соединение будет потеряно, скажем, из-за сетевой ошибки, браузер немедленно посылает новый запрос.
Функция subscribe() делает запрос, затем ожидает ответ, обрабатывает его и снова вызывает сама себя.
Архитектура сервера должна быть способна работать со многими ожидающими подключениями.
Некоторые серверные архитектуры запускают отдельный процесс для каждого соединения. Для большого количества соединений будет столько же процессов, и каждый процесс занимает значительный объём памяти. Так много соединений просто поглотят всю память.
Часто такая проблема возникает с бэкендом, написанными на PHP или Ruby, но технически дело не в языке, а в реализации. На большинстве современных языков можно написать подходящий сервер, но на некоторых это проще сделать.
COMET с XMLHttpRequest: длинные опросы
Материал на этой странице устарел, поэтому скрыт из оглавления сайта.
Более новая информация по этой теме находится на странице https://learn.javascript.ru/long-polling.
В этой главе мы рассмотрим способ организации COMET, то есть непрерывного получения данных с сервера, который очень прост и подходит в 90% реальных случаев.
Частые опросы
Первое решение, которое приходит в голову для непрерывного получения событий с сервера – это «частые опросы» (polling), т.е периодические запросы на сервер: «эй, я тут, изменилось ли что-нибудь?». Например, раз в 10 секунд.
В ответ сервер во-первых помечает у себя, что клиент онлайн, а во-вторых посылает сообщение, в котором в специальном формате содержится весь пакет событий, накопившихся к данному моменту.
При этом, однако, возможна задержка между появлением и получением данных, как раз в размере этих 10 секунд между запросами.
Другой минус – лишний входящий трафик на сервер. При каждом запросе браузер передаёт множество заголовков и в ответ получает, кроме данных, также заголовки. Для некоторых приложений трафик заголовков может в 10 и более раз превосходить трафик реальных данных.
Причём, простота реализации тут достаточно условная. Клиентская часть – довольно проста, а вот сервер получает сразу большой поток запросов.
Даже если клиент ушёл пить чай – его браузер каждые 10 секунд будет «долбить» сервер запросами. Готов ли сервер к такому?
Длинные опросы
Длинные опросы – отличная альтернатива частым опросам. Они также удобны в реализации, и при этом сообщения доставляются без задержек.
Ситуация, когда браузер отправил запрос и держит соединение с сервером, ожидая ответа, является стандартной и прерывается только доставкой сообщений.
При этом если соединение рвётся само, например, из-за ошибки в сети, то браузер тут же отсылает новый запрос.
Примерный код клиентской части:
Функция subscribe делает запрос, при ответе обрабатывает результат, и тут же запускает процесс по новой.
Сервер, конечно же, должен уметь работать с большим количеством таких «ожидающих» соединений.