Pull to refresh
VK
Building the Internet

Почему крупные мессенджеры не работают с XMPP или Размышления о судьбе протокола

Reading time 11 min
Views 23K
Один из самых частых вопросов, задаваемых нашими пользователями, звучит так: «когда Агент и ICQ перейдут на протокол XMPP, и почему этого до сих пор не произошло?».
image
С одной стороны, Jabber (так часто называют протокол XMPP, хотя Jabber — это просто старая версия спецификации XMPP) многие считают лучшей альтернативой проприетарным протоколам, с другой – мировая практика показывает, что крупные интернет-компании не торопятся работать с XMPP, и у них есть для этого определенные причины.

Поскольку вопрос этот не так прост, как может показаться на первый взгляд, мы решили ответить на него максимально подробно, в том числе на примере собственного продукта — Mail.Ru Агента. Не ради дополнительного PR, а просто потому, что бизнес-аргументы всегда интереснее, чем заключения, построенные на абстрактных примерах.

Итак, почему не XMPP?

История

Первая версия Mail.Ru Агента увидела свет более 8 лет назад, в 2003-м году, когда интернет был абсолютно другим в самом широком смысле этого слова – от бизнес-моделей до технических решений.

В то время протокол XMPP (или Jabber, как он тогда назывался) был совсем новым, нигде особенно не применялся и вовсе не казался таким уж бесспорным стандартом для мессаджинга – достаточно сказать, что первые попытки по его стандартизации были предприняты в конце 2001-го года, а текущий стандарт RFC 3920 датирован 2004-м годом.

При этом протокол XMPP не был первым и единственным в своем роде. Рынок мессенджеров к тому времени уже, в основном, сложился, и все они работали по проприетарным протоколам. Кроме того, уже существовал и даже был стандартизирован (RFC 3428) другой открытый протокол для IM – SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions). Так что вопрос о том, какой из протоколов «победит», оставался на тот момент открытым – да и сейчас ответ на него, в общем-то, неоднозначен.

Как серверные, так и клиентские реализации XMPP были в те годы весьма «сырыми» и годились лишь для экспериментального использования – в общем, технология явно находилась в самом начале пути, не было никаких свидетельств того, что со временем она разовьется в нечто большее, поэтому у нас не было особых причин строить на ней наш продукт.

К тому же, изначально мы вообще не собирались делать мессенджер! Mail.Ru Агент задумывался как небольшая утилита, которая всего лишь уведомляла бы пользователя о новой почте в почтовом ящике. Сервер Mail.Ru Агента образца 2003-го года больше всего напоминал не сервер для мессаджинга, а POP3-сервер – с той лишь разницей, что не клиент опрашивал сервер о новых письмах (pull), а сам сервер отправлял клиенту такие уведомления (push) через постоянно установленное TCP-соединение (непосредственно в момент поступления письма на MX-сервер). Для решения этой задачи требовался очень простой протокол, который и был реализован.

Утилита стала популярной, и поскольку в результате мы получили на ее сервере тысячи одновременно подключенных пользователей, чуть позже появилась идея реализовать обмен сообщениями между ними. Затем – передачу файлов, и так далее. Разумеется, каждую из новых «фич» проще всего было реализовать на основе уже существующего сервера и его протокола, нежели разрабатывать новый сервер с нуля. Тем более, что некоторые возможности масштабирования в протоколе были заложены изначально.

Ну а потом… потом аудитория Mail.Ru Агента достигла нескольких миллионов пользователей в сутки, а количество платформ, поддерживаемых клиентами, постепенно достигло семи. Так что даже если бы у нас и возникла необходимость внезапно перейти на XMPP, это потребовало бы длительного времени, в течение которого нам в любом случае пришлось бы поддерживать две версии протокола.

Впрочем, объективных причин для такого перехода так ни разу и не возникло. Наш собственный протокол продолжал успешно выполнять свою задачу и полностью нас устраивал.

Техника

Основным аргументом сторонников протокола XMPP являются его открытость и статус IETF-стандарта. И действительно, трудно переоценить огромный выбор самых разнообразных XMPP-клиентов и серверов, доступных на любых распространенных платформах.

Но не все так просто. Дело в том, что сам по себе протокол XMPP обеспечивает лишь базовый набор обязательной функциональности. Не вдаваясь в детали, это авторизация на сервере, presence-статусы, управление списком контактов (ростером), а также непосредственно обмен сообщениями. По сути, это просто транспорт для абстрактных «событий», происходящих между двумя клиентами (или клиентом и сервером).

Все, что выходит за рамки этих возможностей, описывается расширениями к протоколу, которые называются странным для русского уха словом XEP (XMPP Extension Protocols). Благо, структуры данных в XMPP описываются иерархическим языком XML и легко расширяются.

Расширений «на все случаи жизни» существует довольно много, но поскольку все они являются опциональными (то есть не обязательными ни для сервера, ни для клиента), в реальности получается так, что каждый клиент и сервер поддерживают собственный, уникальный набор расширений, и это выливается вот в такие замысловатые таблицы:

http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP_clients

http://en.wikipedia.org/wiki/Comparison_of_XMPP_server_software

Иными словами, практически всегда возникает ситуация, когда клиент не может воспользоваться какими-то функциями сервера или наоборот. Усугубляет ситуацию некоторая путаница с официальным статусом расширений: несмотря на все многообразие XEP'ов, в качестве стандарта или «кандидатов» на стандартизацию (draft) приняты далеко не все. Многие важные расширения имеют экспериментальный статус – то есть могут быть изменены в любой момент или вообще отклонены.

Отсутствие однозначных стандартов и клиент-серверный «зоопарк» приводят к неизбежным проблемам совместимости. И это не голословное утверждение: реализуя XMPP-клиент в Mail.Ru Агенте, мы на собственном опыте убедились, что авторы каждого сервера весьма по-своему трактуют спецификации XEP’ов. Удивляться этому не приходится – ведь многие положения спецификаций имеют нестрогий, рекомендательный характер, да к тому же периодически пересматриваются. Вот лишь один из типичных примеров: http://xmpp.org/extensions/xep-0153.html#bizrules-image

Кроме того, одна и та же функциональность может быть запросто реализована двумя разными XEP'ами. Так, например, для передачи файлов между двумя контактами можно использовать XEP-0066 (Out-of-Band Data), а можно – технически более продуманный XEP-0096 (Stream Initiation File Transfer). Таким образом, наличие функции передачи файлов в двух разных клиентах вовсе не гарантирует того, что передача файлов между ними на самом деле возможна.

Все эти факторы обуславливают очень низкий темп развития мессенджеров, основанных на XMPP. Характерной иллюстрацией такой стагнации являются, например, голосовые звонки и видеозвонки (must have для любого современного IM-приложения). Несмотря на наличие соответствующих расширений (XEP-0166, XEP-0176, XEP-0266, XEP-0299 и т.д.) разной степени «официальности», XMPP-клиенты с поддержкой звонков на компьютерах «обычных пользователей» практически не встречаются (мне известно только два, причем один из них – Empathy – похоже, даже не портирован на Win32).

Короче говоря, если вы хотите создать новую IM-систему на базе протокола XMPP и собираетесь строго следовать букве стандарта, то возможности вашего серверного и клиентского софта будут заведомо ограничены рамками существующих XEP'ов. Конечно, никто не запрещает вам создавать собственные, проприетарные расширения — однако чем больше у вас будет таких расширений (а необходимость в них появится очень быстро), тем менее «открытой» и совместимой с другими будет ваша система. А ведь именно в этом была вся идея, не так ли?

С другой стороны, разработка менссенджера на основе собственного протокола, созданного «с нуля», полностью развязывает руки разработчика. Возникла необходимость добавить новый тип пакета под функциональность, придуманную менеджером? Нет проблем. Понадобилось расширить структуру данных существующего пакета? Запросто! Нет необходимости оглядываться на стандарты и подстраивать под них дизайн вашего софта — помнить нужно лишь об обратной совместимости с предыдущими версиями ваших клиентов (вместо армии сторонних приложений).

Помимо чисто «идеологических» проблем, тормозящих развитие мессенджеров, основанных на XMPP, у этого протокола есть и объективные технические недостатки. И прежде всего – его громоздкость. Безусловно, человеко-читаемый язык XML удобнее бинарных протоколов на этапе проектирования и отладки. Но в приложениях вроде мессенджеров, которые постоянно обмениваются небольшими порциями данных с сервером, использование XML приводит к генерации избыточного трафика, что может быть особенно критичным на каналах с низкой пропускной способностью и с тарификацией по объему переданных данных (например, в мобильных сетях). Да и рутинные операции типа парсинга XML-деревьев и сериализации/десериализации XML-данных требуют какого-никакого, а дополнительного процессорного времени.

Бизнес

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

Поскольку список контактов пользователя привязан к учетной записи Mail.Ru, то чем шире социальный граф этого пользователя и чем больше у него друзей в списке контактов, тем сильнее он «привязан» к нашей учетной записи.

И это очень хорошо для нас: несмотря на то, что мы практически ничего не зарабатываем непосредственно на сервисах Агента, он, в то же время, тесно интегрирован с нашими веб-сервисами, на которые пользователи переходят по ссылкам и уведомлениям в интерфейсе клиента.

Таким образом, с точки зрения бизнеса мы заинтересованы в двух вещах:
  • чтобы пользователи устанавливали, преимущественно, наш, «родной» клиент (содержащий все необходимые механизмы «конверсии» траффика на веб);
  • чтобы список контактов пользователя (социальный граф) постоянно прирастал новыми контактами

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

Впрочем, если взвешивать все «за» и «против», то XMPP здесь менее предпочтителен, чем проприетарный протокол — по причинам, о которых я говорил выше (ограниченная функциональность и проблемы с совместимостью между клиентами). Так, например, если из нашего «родного» клиента пользователь не сможет сделать видеозвонок своему собеседнику, то в первую очередь он будет винить не клиент собеседника, а сервис Mail.Ru («у них ничего не работает»). Это одна из причин, почему мы используем наш собственный клиент-серверный протокол. Стоит отметить при этом, что основные части спецификации нашего протокола доступны публично, и мы не препятствуем разработке сторонних клиентов.

Что же касается другой проблемы – расширения социального графа – то здесь, теоретически, XMPP мог бы нам здорово помочь. Дело в том, что помимо клиент-серверного подключения в XMPP предусмотрен обмен данными между серверами (так называемый Server-to-Server Federation или пиринг). Этот режим необходим для того, чтобы пользователи могли добавлять в свой список контактов (roster) пользователей из других доменов и обмениваться с ними сообщениями.

Соответственно, реализовав XMPP-гейт на стороне сервера Mail.Ru Агента, мы могли бы существенно увеличить списки контактов наших пользователей за счет контактов из других IM-сервисов, тоже поддерживающих пиринг. Но… увы! В реальности существует только один такой сервис, обладающий существенной аудиторией – Google Talk. Но по нашим данным (а также данным независимых исследований) там слишком мало пользователей (особенно русскоязычных), чтобы поддержка пиринга принесла нам хоть какой-то видимый эффект. Остальные сервисы, поддерживающие XMPP, либо еще меньше по размерам пользовательской базы, либо не поддерживают S2S Federation (к таким сервисам относятся, например, Facebook, Вконтакте, LiveJournal).

По иронии судьбы, единственный сервис, с которым нам удалось реализовать полноценный S2S-пиринг — это мессенджер ICQ. И даже здесь в качестве протокола пиринга использовался не XMPP, а SIP/SIMPLE.

Другими словами, глобальная открытость XMPP и его децентрализация – это, по большому счету, миф: по-настоящему большие аудитории пользователей концентрируются вокруг XMPP-серверов, изолированных друг от друга и не имеющих между собой интерконнекта. Крупные участники рынка отчасти боятся спама (в случае использования S2S federation приходится бороться не только с внутренним, но и внешним «мусором», что создает дополнительные сложности и требует серьезных ресурсов), отчасти не спешат «делиться» своей аудиторией, отчасти испытывают с этим технические сложности (ведь социальные сети – это нечто более, чем просто XMPP-сервер; и им нужно как-то интегрировать «чужих» пользователей в свою архитектуру, типа лент друзей, изначально на это не рассчитанную). Мелкие же игроки (например, энтузиасты-админы, поднимающие XMPP-серверы в своих офисах) не делают никакой погоды на рынке.

Резюме

Итак, подведем краткий итог.

1. Протокол XMPP родился в неудачное с исторической точки зрения время. На момент его появления рынок мессаджинга уже сформировался, и XMPP не смог занять место безусловного стандарта (как это произошло в свое время, например, с SMTP или HTTP). Появись XMPP раньше – возможно, сейчас ситуация была бы совершенно другой.

2. Когда пользователь выбирает мессенджер, последнее, что его интересует – по какому протоколу работает этот месенджер. Три основных вопроса, которые задает юзер – это «чем пользуются мои друзья?», «как выглядит этот мессенджер?» и «что он может?»

3. XMPP – это не панацея и не серебряная пуля. Все мессенджеры, лидирующие сейчас на рынке (как на российском, так и на мировом) основаны на закрытых (или супер-закрытых, как Skype) протоколах, и пока это абсолютно не мешает им развиваться. С другой стороны, неподкотрольность XMPP и отсутствие доминирующих игроков, задающих «тон» рынку, приводят к появлению множества продуктов довольно спорного качества (в первую очередь это касается клиентов), совместимых между собой лишь в части самых базовых возможностей. Так что открытость сейчас играет скорее против этого протокола — как бы парадоксально это ни звучало.

4. С точки зрения бизнеса, переходить на XMPP в качестве клиент-серверного протокола не имеет смысла, а запускать S2S Federation преждевременно, в силу уже описанных выше причин. Однако мы открыты к таким предложениям.

Знаем ли мы пароль и видим ли ориентир?

Позиция Mail.Ru насчет технологий мессаджинга очень проста – все флаги в гости к нам!

Мы стремимся к тому, чтобы Mail.Ru Агент был совместим с любыми сервисами, где есть возможность обмениваться сообщениями и присутствует заметная по численности аудитория, и на сегодня Mail.Ru Агент предлагает 4 варианта взаимодействия – как с сервисами Mail.Ru, так и со сторонними сервисами.

На клиентской стороне:

1. Подключение к серверу Mail.Ru Агента по нашему собственному протоколу под учетной записью Mail.Ru. В этом режиме доступно максимальное количество функций, включая аудио- и видеозвонки, конференции, отправка SMS, геколокация, игры, поиск музыки из Моего Мира и т.д.

2. Подключение к серверу ICQ по протоколу ICQ. Доступны все основные функции ICQ, и мы работаем над расширением их списка. Пользователю необходима учетная запись ICQ.

3. Подключение к любым XMPP-серверам по протоколу XMPP (включая XMPP-серверы таких социальных сетей, как Одноклассники, Вконтакте, Facebook, мессенджер Google Talk и т.д.). Реализована поддержка XMPP практически в полном объеме и некоторые XEP.

На серверной стороне:

4. Пиринг (interoperability) с ICQ на уровне серверов Агента и ICQ. Пользователь подключается клиентом Агента к серверу Агента под учетной записью Mail.Ru и может добавлять в свой список контактов пользователей ICQ. Этот режим наиболее похож на XMPP S2S Federation. Поддерживается лишь обмен сообщениями и статусами, но мы работаем над расширением функциональности.

Короче говоря...

Мы верим, что будущее — за открытыми технологиями. Как нам кажется, рано или поздно мессаджинг обязательно должен прийти к некоему единому стандарту, как это произошло в свое время, например, с телефонией (на любом телефоне вы сегодня можете набрать номер в международном формате и поговорить с собеседником – вне зависимости от того, услугами каких телефонных компаний вы оба пользуетесь). Станет ли таким стандартом именно XMPP – не столь важно; главное, что ненужные границы должны быть стерты.

На наш взгляд, в конечном счете это пойдет только на пользу всем участникам рынка. Например, многие уже не помнят, что еще не так давно, в начале 2000-х, в Москве было только два мобильных оператора, между которыми принципиально не ходили SMS. Расчет был прост: отсутствие пиринга заставляло абонента покупать контракт того оператора, которым пользуются его ближайшие родственники или друзья. Таким образом, один привлеченный абонент потенциально приводил еще двух-трех, так что эффект от каждой успешной маркетинговой кампании по сути мультиплицировался.

Тем не менее, в конце концов операторы все же запустили пиринг – и это привело к мгновенному росту их доходов, так как социальный граф SMS-сервиса увеличился в 1,5-2 раза (и, как следствие, люди стали общаться намного интенсивнее, чем раньше). Мы считаем, что нечто подобное должно случиться и в мессаджинге – главное, чтобы игроки, запускающие пиринг, были примерно сравнимы по аудитории, и вместо каннибализации аудиторий происходило их взаимное проникновение.

Илья Наумов,
руководитель проекта Mail.Ru Агент
Tags:
Hubs:
-7
Comments 307
Comments Comments 307

Articles

Information

Website
vk.com
Registered
Founded
Employees
5,001–10,000 employees
Location
Россия
Representative
Миша Берггрен