示すように、IM技術は、いくつかの反復アップグレードを経験しました。
単純な、短いポーリング非効率的漸増からポーリングの制御可能な長さの相対的な効率に、
全二重は、プッシュサーバの問題を解決するためのWebSocket、および
長い接続を派生IMベースのTCPプロトコルは、アクティブプッシュサーバを実現することができます。
長短ポーリングベースのプロトコルのHTTP接続
|
|
|
|
|---|---|---|
| シーン | 定期的にポーリングサービス高周波側に新しいメッセージ。サーバーが要求を受信すると、新しいメッセージが新しいメッセージがクライアントに返されますされている場合、何のニュースは、空のリストを返していない、との接続を閉じます。それは次のとおりです。関係なく、生成されたニュースの現在のラウンドのサーバがありません、すぐに応答して、戻ります。 | この要求は、新しいメッセージを取得していない場合、結果はすぐに応答を返すことはありませんが、サーバー「サスペンション（ハング）」要求と一定の期間を待って、一度に新しいメッセージがこの時間の間に生成され、すぐにレスポンスを返すことができます。 |
| 短所 | サービス側では、要求の高い周波数が高くQPSになります。クライアントの場合、ポーリングの頻度が高いほど、要求の大半は役に立たないと高価な電気（費用対効果）とコストフロー（純費用）をしていますバックエンド・ストレージ・リソースに大きな圧力を引き起こします。 | サスペンションライブサーバー要求だけ減少入口QPS要求とポーリング資源の後端部に圧力を減らすことはありません。（メッセージを待っている1000の要求がある場合は、1000件のスレッド継続的にポーリングしている場合があります）、ロングポーリングがまだ完全にクライアントがタイムアウト期間内に無効な要求で問題が解決しない、メッセージへのリターンを終了します得ることはありません。 |
結論：両方がHTTPプロトコルに基づいているため、短期および長期ポーリング接続は「エッジ・トリガ」完全イベントベース行うことができず、HTTPはステートレスなプロトコルで、サーバは、新しいメッセージを生成し、クライアントに直接プッシュすることができず、クライアントが複数の要求を開始し、サーバーは、サーバーへのクライアントの状態を記録しません - すべてのリクエストのみがクライアントによって開始することができます。
単一のTCP接続のプロトコルに基づいて、第2の、全二重通信のWebSocket
クライアントおよびサーバーのみハンドシェイクを完了する必要があり、それが長期的な接続を作成することができ、いつでも、双方向のデータ伝送。
サーバが新しいメッセージを受信した場合、あなたはリアルタイムでメッセージを確実にするために確立された接続、ダイレクトプッシュ、本当に「エッジ・トリガ」をWebSocketをすることができます。
利点：
双方向通信支援サーバ側プッシュ、劇的サーバのポーリング圧力を低下させる1;
、当事者間のネットワークオーバーヘッド通信還元低い制御オーバーヘッド2データ交換、
比較的単純3.Webネイティブサポート。
第三に、IMに基づいて長い接続は、TCPプロトコル導出します
IMドメインでは、WebSocketのプロトコルと同様に、派生プライベートプロトコルのTCPに基づいて長い接続であるXMPP、MQTTピア通信プロトコル、除きます。
ラインはユーザ機器との間の良好な関係を維持するために、サーバー上のユーザーに接続し、サーバに接続するために、特定のTCP接続をマッピングし、一度長い接続を確立したときにネットワークが中断されない限り、これらの独自のプロトコルには、、がありました。このように、クライアントは、常にユーザーのクライアントの対応のオンラインマップを見つけるために、任意の時点で、この関係からも、サーバーをサーバーを見つけることができます。