大型メッセンジャーがXMPPで動作しない理由、またはプロトコルの運命についての考え

ユーザーから寄せられる最も一般的な質問の1つは、「エージェントとICQがいつXMPPに切り替わるのか、なぜこれがまだ行われていないのか」です。



一方では、Jabber（XMPPはよく呼ばれますが、JabberはXMPP仕様の単なる旧バージョンですが）は多くの人が独自のプロトコルに代わる最良の選択肢であると考えられています。これには特定の理由があります。



この質問は一見簡単そうではないので、できる限り詳細に回答することにしました。自社製品の例であるMail.Ru Agentを使用することも含まれます。 追加のPRのためではなく、単にビジネスの議論が抽象的な例に基づく結論よりも常に興味深いためです。



では、なぜXMPPを使わないのでしょうか？



物語



Mail.Ru Agentの最初のバージョンは、ビジネスモデルから技術的なソリューションまで、インターネットが広義の意味で完全に異なっていた2003年に8年以上前にリリースされました。



当時、XMPP（またはJabberと呼ばれていました）は完全に新しく、どこにも使用されておらず、メッセージングの議論の余地のない標準とは思われませんでした-それを標準化する最初の試みは2001年末に行われたと言えば十分です、現在のRFC 3920標準の日付は2004年です。



ただし、XMPPはその種の最初のものではなく、唯一のものでした。 その時までにインスタントメッセンジャーの市場はすでに基本的に発展しており、それらはすべて独自のプロトコルに取り組んでいました。 さらに、IM用の別のオープンプロトコルがすでに存在し、標準化されています（ RFC 3428 ） -SIMPLE （インスタントメッセージングおよびプレゼンスレバレッジング拡張機能用のSIP）。 そのため、その時点でどのプロトコルが「勝つ」かという問題は未解決のままでした。そして今でも、その答えは一般的にあいまいです。



XMPPのサーバーとクライアントの両方の実装は当時非常に未加工であり、実験的使用にのみ適していました-一般に、この技術は明らかに最初の段階にあり、時間が経つにつれて何かに発展するという証拠はなかったため、製品を構築する特別な理由はありませんでした。



さらに、最初はメッセンジャーを作成するつもりはまったくありませんでした！ Mail.Ru Agentは、メールボックス内の新しいメールをユーザーに通知するだけの小さなユーティリティと考えられていました。 2003サンプルのMail.Ru Agentサーバーは、メッセージングサーバーではなく、POP3サーバーにほとんど似ています-唯一の違いは、クライアントが新しいメッセージを求めてサーバーをポーリング（プル）しなかったことと、サーバー自体がクライアントにそのような通知を送信（プッシュ）したことです永続的に確立されたTCP接続を介して（MXサーバーでレターを受信した時点で）。 この問題を解決するには、実装された非常に簡単なプロトコルが必要でした。



このユーティリティは人気を博し、その結果、サーバー上で同時に接続された何千人ものユーザーを受け取ったため、少し後に彼らの間でメッセージングを実装するというアイデアが浮上しました。 その後-ファイル転送など。 もちろん、新しい「機能」はそれぞれ、新しいサーバーをゼロから開発するよりも、既存のサーバーとそのプロトコルに基づいて実装するのが最も簡単でした。 さらに、プロトコルのスケーリング機能の一部が最初に定められました。



それでは...その後、Mail.Ru Agentの対象ユーザーは1日に数百万人のユーザーに到達し、顧客がサポートするプラットフォームの数は徐々に7に達しました。 そのため、突然XMPPに切り替える必要があったとしても、長い時間がかかります。その間、とにかく2つのバージョンのプロトコルをサポートする必要があります。



ただし、このような移行の客観的な理由は決して発生していません。 私たち自身のプロトコルは、そのタスクを成功裏に実行し続け、私たちに完全に適合しました。



テクニック



XMPPプロトコルの支持者の主な議論は、そのオープン性とIETF標準のステータスです。 実際、一般的なプラットフォームで利用可能な最も多様なXMPPクライアントとサーバーの膨大な選択を過大評価することは困難です。



しかし、それほど単純ではありません。 実際、XMPPプロトコル自体は、必要な機能の基本セットのみを提供します。 詳細には触れませんが、これは、サーバーでの承認、プレゼンス状態、連絡先リスト（名簿）の管理、およびダイレクトメッセージングです。 本質的に、これは2つのクライアント（またはクライアントとサーバー）間で発生する抽象的な「イベント」の単なるトランスポートです。



これらの機能を超えるものはすべて、XEP（XMPP拡張プロトコル）と呼ばれるプロトコルの拡張機能によって記述されますが、これはロシアの耳には奇妙です。 幸いなことに、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の種類はさまざまですが、すべてが標準または標準化（ドラフト）の「候補」とはほど遠いものです。 多くの重要な拡張機能には実験的なステータスがあります。つまり、いつでも変更したり、完全に拒否したりできます。



明確な標準の欠如とクライアント/サーバー「動物園」は、避けられない互換性の問題につながります。 これは根拠のない声明ではありません。Mail.RuAgentにXMPPクライアントを実装すると、各サーバーの作成者がXEP仕様を非常に異なる方法で解釈するという私たち自身の経験からわかりました。 これは驚くことではありません-結局、仕様の規定の多くは厳密ではなく、本質的に推奨事項であり、さらに定期的に見直されています。 以下に典型的な例を示します。http ： //xmpp.org/extensions/xep-0153.html#bizrules-image



さらに、2つの異なるXEPによって同じ機能を簡単に実装できます。 したがって、たとえば、2つの連絡先間でファイルを転送するには、 XEP-0066 （帯域外データ）を使用するか、技術的に高度なXEP-0096 （ストリーム開始ファイル転送）を使用できます。 したがって、2つの異なるクライアントにファイル転送機能が存在しても、それらの間でのファイル転送が実際に可能であることは保証されません。



これらすべての要因により、XMPPに基づいたメッセンジャーの開発は非常に遅くなります。 このような停滞の典型的な例は、たとえば、音声通話とビデオ通話です（現代のIMアプリケーションには必須です）。 対応する拡張機能（ XEP-0166 、 XEP-0176 、 XEP-0266 、 XEP-0299など）のさまざまな程度の「公式」の存在にもかかわらず、「通常のユーザー」のコンピューターでの呼び出しをサポートするXMPPクライアントは実際には見つかりません（私にとっては）知られているのは2つだけで、そのうちの1つ（ 共感 ）はWin32に移植されていないようです）。



つまり、XMPPプロトコルに基づいて新しいIMシステムを作成し、標準の文字に厳密に従う場合、サーバーとクライアントソフトウェアの機能は、既存のXEPによって意図的に制限されます。 もちろん、独自の独自の拡張機能を作成することを誰も禁止していませんが、そのような拡張機能があればあるほど（そしてそれらの拡張機能の必要性はすぐに現れます）、システムが他のシステムと「オープン」で互換性が低くなります。 しかし、これはまさに全体的なアイデアでしたね。



一方、ゼロから作成された独自のプロトコルに基づいてマネージャーを開発すると、開発者の手が完全に不自由になります。 マネージャーが考案した機能のために新しいタイプのパッケージを追加する必要がありましたか？ 問題ありません。 既存のパッケージのデータ構造を拡張する必要がありますか？ 簡単！ 標準を確認してソフトウェアの設計を調整する必要はありません-サードパーティのアプリケーションの群れではなく、クライアントの以前のバージョンとの下位互換性についてのみ覚えておく必要があります。



XMPPベースのインスタントメッセンジャーの開発を妨げる純粋に「イデオロギー的な」問題に加えて、このプロトコルには客観的な技術的な欠陥もあります。 そして何より、そのかさ高さ。 もちろん、設計およびデバッグの段階では、人間が読めるXMLはバイナリプロトコルよりも便利です。 しかし、インスタントメッセンジャーのようなアプリケーションは、常にデータの小さな部分をサーバーと交換しますが、XMLを使用すると過剰なトラフィックが発生します。これは、低帯域幅のチャネルや転送データ量に基づいた課金（モバイルネットワークなど）で特に重要になる可能性があります。 また、XMLツリーの解析やXMLデータのシリアライズ/デシリアライズなどのルーチン操作には、何らかの種類の追加のプロセッサー時間が必要です。



事業内容



グローバルに状況を見ると、大きなインターネット企業のメッセンジャーが必要になる主な理由は、ユーザーの忠誠心を強化するためです。



ユーザーの連絡先リストはMail.Ruアカウントに関連付けられているため、このユーザーのソーシャルグラフが広くなり、連絡先リストに友人が多くなるほど、アカウントに強く結び付けられます。



そして、これは私たちにとって非常に良いことです：私たちは実際にはエージェントのサービスから直接何も獲得しないという事実にもかかわらず、同時に、それはユーザーがクライアントインターフェースでリンクや通知をクリックするウェブサービスと密接に統合されています。



したがって、ビジネスの観点から、次の2つのことに興味があります。

• ユーザーが主に「ネイティブ」クライアント（トラフィックをWebに「変換」するために必要なすべてのメカニズムを含む）をインストールします。
• ユーザーの連絡先リスト（ソーシャルグラフ）が新しい連絡先で絶えず成長するように

最初の問題を解決する上で、一般的に言えば、クライアント/サーバープロトコルは特に重要ではありません。主なことは、製品の品質が競合他社に比べて十分に高く、ユーザーが必要な機能をすべて利用できることです。



ただし、長所と短所を比較検討する場合、XMPPは専用プロトコルよりも好ましくありません-前述の理由により（機能制限とクライアント間の互換性の問題）。 したがって、たとえば、ユーザーが私たちの「ネイティブ」クライアントから対談者にビデオ通話を行えない場合、まず、彼は対談者のクライアントではなく、Mail.Ruサービスを非難します（「何も機能しません」）。 これが、独自のクライアント/サーバープロトコルを使用する理由の1つです。 プロトコルの仕様の主要部分は一般に公開されており、サードパーティのクライアントの開発を妨げることはありません。



他の問題-ソーシャルグラフの拡大-に関しては、ここで、理論的には、XMPPは私たちを大いに助けることができます。 実際のところ、XMPPは、クライアントとサーバー間の接続に加えて、サーバー間のデータ交換（いわゆるサーバー間フェデレーションまたはピアリング）を提供します。 このモードは、ユーザーが他のドメインのユーザーを名簿の連絡先に追加してメッセージを交換できるようにするために必要です。



したがって、Mail.Ru Agentのサーバー側にXMPPゲートを実装することにより、ピアリングもサポートする他のIMサービスからの連絡先により、ユーザーの連絡先リストを大幅に増やすことができます。 しかし...悲しいかな！ 現実には、重要な視聴者を持つこのようなサービスはGoogleトークだけです。 しかし、私たちのデータ（および独立した研究からのデータ）によれば、ピアリングをサポートするユーザー（特にロシア語を話すユーザー）が少なすぎるため、少なくとも目に見える効果がもたらされました。 XMPPをサポートする他のサービスは、ユーザーベースのサイズがさらに小さいか、S2Sフェデレーションをサポートしていません（そのようなサービスには、Facebook、Vkontakte、LiveJournalなどがあります）。



皮肉なことに、本格的なS2Sピアリングを実装できた唯一のサービスはICQメッセンジャーです。 ここでも、XMPPではなく、SIP / SIMPLEがピアリングプロトコルとして使用されました。



言い換えれば、XMPPのグローバルな開放性と分散化は、概して神話です。真に大規模なユーザーオーディエンスは、相互に分離され相互接続のないXMPPサーバーに集中しています。 大規模な市場参加者は、部分的にスパムを恐れています（S2Sフェデレーションを使用する場合、内部だけでなく外部の「ガベージ」とも戦わなければなりません。これにより、さらに困難が生じ、深刻なリソースが必要です）困難（結局のところ、ソーシャルネットワークは単なるXMPPサーバーではありません。また、元々このために設計されていない友人のフィードなど、「エイリアン」ユーザーを何らかの形でアーキテクチャに統合する必要があります。 小規模なプレーヤー（たとえば、オフィスでXMPPサーバーを上げる熱狂的な管理者）は、市場に天気を立てません。



まとめ



要約すると。



1. XMPPは、歴史的に失敗した時期に生まれました。 登場当時、メッセージング市場はすでに形成されていて、XMPPは無条件の標準に取って代わることができませんでした（たとえば、SMTPやHTTPの場合など）。 XMPPが以前に登場していた場合-おそらく今では状況は完全に異なっていただろう。



2.ユーザーがメッセンジャーを選択するとき、最後に関心があるのは、このメッセンジャーが機能するプロトコルに従うことです。 ユーザーが尋ねる3つの主な質問は、「私の友人は何を使用していますか？」、「このメッセンジャーはどのように見えますか？」、および「それは何ができますか？」です。



3. XMPPは万能薬でも特効薬でもありません。 現在市場をリードしているインスタントメッセンジャー（ロシアと世界の両方）はすべて、クローズド（またはSkypeのようなスーパークローズド）プロトコルに基づいており、これまでのところ、開発が妨げられていません。 一方、XMPPに対する制御の欠如と市場のトーンを設定する支配的なプレーヤーの不在は、最も基本的な機能の点でのみ互いに​​互換性のあるかなり議論のある品質の製品（主に顧客）の出現につながります。 そのため、オープン性は現在このプロトコルに対してむしろ機能しますが、逆説的に聞こえるかもしれません。



4.ビジネスの観点からは、クライアントサーバープロトコルとしてXMPPに切り替えることは意味がなく、既に説明した理由により、S2Sフェデレーションの起動は時期尚早です。 ただし、そのような提案は受け付けています。



パスワードを知っており、ランドマークを確認していますか？



メッセージングテクノロジーに関するMail.Ruの位置は非常に単純です-すべてのフラグは私たちの訪問です！



Mail.Ru Agentは、メッセージを交換する機会があり、多くの視聴者がいるサービスと互換性があるように努めています。現在、Mail.Ru Agentは、Mail.Ruサービスとサードパーティのサービス。



クライアント側で：



1. Mail.Ruアカウントで独自のプロトコルを使用して、AgentをMail.Ruサーバーに接続します。 このモードでは、音声通話とビデオ通話、会議、SMSの送信、位置情報、ゲーム、My Worldからの音楽の検索など、最大数の機能を使用できます。



2. ICQプロトコルを使用してICQサーバーに接続します。 すべての基本的なICQ機能が利用可能であり、それらのリストの拡張に取り組んでいます。 ユーザーにはICQアカウントが必要です。



3. XMPPプロトコルを使用したXMPPサーバーへの接続（Odnoklassniki、Vkontakte、Facebook、Google TalkメッセンジャーなどのソーシャルネットワークのXMPPサーバーを含む）。 XMPPのサポートをほぼ完全に実装し、一部のXEPを実装しました。



サーバー側で：



4.エージェントおよびICQサーバーのレベルでのICQとの相互運用性。 ユーザーは、Agentクライアントを使用してMail.Ruアカウントでエージェントサーバーに接続し、ICQユーザーを連絡先リストに追加できます。 このモードは、XMPP S2Sフェデレーションに最も似ています。 メッセージングとステータスのみがサポートされていますが、機能の拡張に取り組んでいます。



要するに...



未来はオープンテクノロジーにあると信じています。 遅かれ早かれ、例えばテレフォニーなどで、メッセージングが統一された標準に達しなければならないようです（どの電話でも、今日は国際形式で番号をダイヤルし、サービスに関係なく対話者と話すことができます）どちらの電話会社も使用しています）。 XMPPがそのような標準になるかどうかはそれほど重要ではありません。 主なものは、不要な境界線を消去する必要があるということです。



私たちの意見では、最終的にこれはすべての市場参加者にのみ利益をもたらします。 たとえば、2000年前半、モスクワには2人の携帯電話会社しかなく、その間に基本的にSMSがなかったということを、多くの人は覚えていません。 計算は簡単でした。ピアリングがないため、加入者はオペレーターの契約を購入せざるを得ませんでした。これは、最も近い親closestや友人が使用します。 したがって、1人の魅力的な加入者が別の2つまたは3つをもたらす可能性があるため、成功した各マーケティングキャンペーンの効果は本質的に倍増しました。



それにもかかわらず、結局のところ、オペレーターはピアリングを開始しました-そして、これはSMSサービスのソーシャルグラフが1.5から2倍増加したため、彼らの収入が即座に増加しました（その結果、人々はより集中的にコミュニケーションを始めました以前）。 メッセージングでも同様のことが起こると考えています-主なことは、ピアリングを開始するプレーヤーは視聴者でほぼ同等であり、視聴者を共食いする代わりに、お互いに浸透することです。



イリヤ・ナウモフ、

プロジェクトマネージャーMail.Ruエージェント