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

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

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

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

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

Что такое COMET ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, для измерения сетевых задержек и контроля соединения, сервер может периодически посылать по этому каналу 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:

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 одним потоком/процессом на много клиентов.

    Классическая(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 того же пользователя.

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

    Скажите, а как при помощи mpm event решить вопрос создания апачем файлов от юзеров, которым принадлежит папка, в которой работает скрипт, а не nobody. Спасибо!

    Вообще-то это не по теме, но все равно ответ - никак

    неужели в этом можно разобраться?

    Изображения вверху записаны в UML-нотации. Конкретнее - это диграммы последовательности (sequence diagram).

    Возможно, проще (и полезнее) - разобраться сначала с sequence diagram в UML вообще, а потом - в конкретными диаграммами здесь.

    я хотел бы написать на perl такой чат c jquery

    можете ли вы подсказать как в этом разобратся? нужно написать демона на сокетах? как это все будет?

    Есть ли у Вас информация о том какие из методов используют большие компании вроде Facebook (чат, оповещения), Gmail (чат), Twitter (notifications)?

    Facebook - Tornado (их разработка, Open Source, Python), Gmail - свой сервер, клиентская часть - open source Google Closure Library, Twitter - не в курсе.