Передача данных по инициативе сервера, обзор COMET

COMET-технологии позволяют организовать обновление данных на странице без участия пользователя.

Чаты, интернет-почта и многопользовательские админки - далеко не полный список, где они применимы.

В этом цикле статей - подробно описаны многочисленные тонкие моменты и решения частых проблем.

Что такое COMET ?

COMET (или "server push") - способ передачи данных с сервера на клиент, по инициативе сервера.

Например, у вас есть электронный магазин, и менеджер может отслеживать переходы клиента.
COMET позволяет менеджеру тут же, онлайн, спросить клиента о чем-то, предложить интересный вариант.

"По инициативе сервера" означает, что клиент сам не запрашивает сервер, он просто находится на странице.

Старейший пример COMET - чат. Человек просто находится на странице и получает новые сообщения.

Также COMET используется в админках для оповещения об изменениях со стороны других посетителей, для совместного редактирования документов и т.п.

Способы реализации

Способов реализации COMET достаточно много. У них - самые разные характеристики, достоинства и недостатки.
Есть два основных класса.

По сообщению на запрос

Каждое событие на сервере браузер получает отдельным запросом. Здесь есть два основных метода.

  1. Частый опрос (polling)
  2. Длинный опрос (long-poll)

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

<events> 
  <message> 
    <from>Vasya</from> 
    <text>Привет!</text> 
  </message> 
  <notification> 
    <type>processing</type> 
    <text>Обработка завершена</text> 
  </notification> 
</events>

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

Поток сообщений через постоянное соединение

Браузер держит постоянное соединение с сервером, так называемый "канал", и получает через него события.

Канал связи разрывается время от времени:

  • чтобы прокси не подумал, что настал таймаут соединения и не порвал его за нас
  • для очистки памяти от мусора старых сообщений

Кроме того, для измерения сетевых задержек и контроля соединения, сервер может периодически посылать по этому каналу ping-пакеты.

Основные способы поддержания постоянного соединения:

  1. Бесконечный IFrame
  2. XMLHTTPRequest, interactive
  3. Multipart XMLHTTPRequest
  4. Event-source

Вы найдете их в других статьях этого раздела.

Общие для постоянных соединений проблемы

Протокол HTTP изначально создавался так, чтобы один запрос возвращал одну единицу информации. А мы хотим - много, отсюда и некоторые сложности...

Буферизация прокси

Такое встречается редко, но прокси может буферизовать определенное количество данных до передачи клиенту. Например, принимать и отдавать ответ блоками по 2К. В этом случае сообщения будут оставаться на прокси, и ждать, пока их не наберется 2К (или какой там размер буфера) байт, и только тогда - передаваться клиенту.

Решение - добавлять к каждому сообщению 2K пробелов.

Неизвестно, коснется ли Вас эта проблема. Надеюсь, что нет, но иметь в виду буферизацию прокси как возможную причину жалоб пользователей - надо обязательно.

Нельзя GZIP

IFrame, который служит для передачи сообщений, НЕ должен сжиматься gzip/deflate. Иначе говоря, для служебного URL сообщений сжатие должно быть отключено.

Включенное сжатие подразумевает, что браузер ждет конца загрузки, а затем - распаковывает и показывает пользователю. В нашем же случае это категорически противопоказано, а сжимать кусочки страницы (сообщения) по отдельности нельзя.

Это - неприятное последствие хакерской натуры iframe. Например, в long poll сжатие проходит на ура, т.к события не являются частью одной страницы.

Буферизация страницы сервером

Не забудьте отключить буферизацию сервером. В связке Apache/PHP - отключите output buffering и включите ob_implicit_flush:

while (@ob_end_flush()) {}
ob_implicit_flush(1);

// ну и конечно убрать лимит на время выполнения скрипта
set_time_limit(0);

COMET: частый опрос VS постоянное соединение

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

  1. Реализация длинного коннекта, как правило, усложняет архитектуру. Возможно, можно обойтись решением попроще?
  2. Ряд веб-серверов плохо оптимизированы под большое количество длинных соединений. Например, используются потоки или процессы, которые отъедают фиксированное количество ресурсов и не освобождают их до конца соединения.На уровне OS проблема решается использованием kqueue(FreeBSD) или epoll(Linux).На уровне веб-сервера можно использовать
    1. Apache MPM event для apache 2.2 (экспериментальный и ограниченный MPM, специальный поток обрабатывает Listening и Keep-Alive сокеты)
      не работает как следует с mod_perl/mod_php
    2. Jetty (Java) / Twisted(Python), nginx и другие специализированные серверы c одним потоком/процессом на много клиентов.

    Потянет ли текущая серверная архитектура длинные соединения? Ответ неочевиден для сотен/тысяч одновременных соединений, но, скажем, до 100 соединений в любой архитектуре все хорошо.

  3. Насколько долго пользователи находятся на одной и той же странице? При переходах коннект, скорее всего, придется открывать заново в любом случае.
  4. Если допустимы задержки доставки событий, то, может быть, хватит частого опроса?

Классическая(transport-independant) модель COMET

Посмотрим на взаимодействие клиент-сервер "с высоты птичьего полета", выше деталей передачи данных, транспортов и т.п. Например, так это сделано в специализированном server-push движке lightstreamer.

Соединения с сервером делятся на два типа

  1. Control connection - контрольные соединения, через которые клиент отправляет запросы на сервер. Это - обычные AJAX-запросы через XMLHTTPRequest.
  2. Push connection(channel) - поток событий, соединение, через которые клиент получает события с сервера

У всех событий на сервере есть тип. Клиент может подписываться и отписываться на интересующие его события через контрольные соединения. Для удобства типы организованы по схемам. Например, в схеме chat может быть тип message.

Например, следующая диаграмма описывает типичную последовательность действий:

  1. Клиент открывает потоковое соединение к серверу
  2. Клиент подписывается на события типа Item1 в схеме Schema1
  3. Сервер шлет события
  4. Клиент отписывается от событий через новое контрольное соединение
  5. Клиент закрывает соединение

Или - вот более сложная диаграмма, в которой клиент подписывается уже на разные типы событий:

В качестве транспорта в lightstreamer используется iframe. Время от времени его необходимо закрывать для очистки от принятых объектов. При закрытии сессии (это же происходит при refresh страницы в браузере) сервер буферизует новые события до некоторого таймаута и отдает их, как только открывается новая сессия Stream Connection 2 того же пользователя.

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