リアルタイムウェブチャットシステムを実現するために、
最初のページ[0]
序文
このプロジェクトは、私が何のテストを実行するために3年間の大学に学ぶ方法です。最初に、ブログに記録ピットプロジェクトの開発プロセスおよび発生した問題を書くこと、第二は、（（╯ `□「一般的な方向を）知っているガイドブック内の長い断片化された知識で初心者を見つけることができるようにすることです╯ 〜╧╧確かに）私が正しかったとは言えません。私は川を渡って道を感じていたので、私は、最初からもっとゆっくり更新します。必要なときに知識の使用については、私は技術の彼らの関連知識を言及します。ブログは、多くの場合、知識を変更することによって、欠員を埋めるために、私は私のラップトップとしてそれをしたい、修正され、経験は私の本の一つとなりました。
プロジェクトの背景
ライブチャットシステム[インスタントメッセージ]、非常に有名なQQ、マイクロ手紙クライアントアプリケーションのこのタイプを考えることができます。QQのウェブ版は、2019年1月1日以降のサービスのうち、以前に存在してい、マイクロチャンネルウェブ版の存在下に来ます。それ以来、私はリアルタイムのチャット、インタラクティブなオンライン、オフラインメッセージ機能を実現することができ、同様のアプリケーション、Webベースのエンドインスタントチャットシステムを書きたかったです。私は、システムの一般的な性質は、プロジェクトの任意のチャットメッセージ機能に取り付けることができ、非常に高いと思います。結局のところ、今日のソーシャル・ソフトウェアの使用に前例のない高いとして記述することができます。
デザインのアイデア
少し集計データ
初期の通信ソフトウェアQQは、TCP / IPプロトコルに基づいています。UDPプロトコル、サーバーを介した双方向のトランジットを利用した通信をチャット。我々はすべて知っているように、UDPプロトコルは合意が、ちょうどかかわらず、それを受信した場合、それを送信しない、信頼性がありませんが、その送信は非常に効率的です。
ここではTCP / IPは、Baiduの百科事典によるとだBaiduの百科事典は_ TCP / IPプロトコルの彼の説明で書きました
TCP / IP（伝送制御プロトコル/インターネット・プロトコル、 プロトコル・スイートは、複数の異なるネットワーク間での情報の伝送を可能にする伝送制御プロトコル/インターネットプロトコル）を意味します。TCP / IPプロトコルがないだけでいいTCP とIPの2つのプロトコルが、手段FTP、SMTP、TCP、UDPだけTCPとIPプロトコルでTCP / IPプロトコルとして、プロトコルのクラスタ構成、IPおよびその他のプロトコルを最も代表的には、それはTCP / IPプロトコルと呼ばれています。
そして、これは通信プロトコルをネットワークへのQQのデスクトップソフトウェアである、と私たちのウェブ側が使用することをHTTP（アプリケーション層で定義されたプロトコルを、彼らの関係は、Baiduのを所有することができます）
HTTPは、応答プロトコル-単純な要求通常、TCPの上で動作します。これは、クライアントがサーバーにメッセージを送信し、得られた応答の種類も指定します。要求と応答 ASCIIコードの形で与えられたメッセージヘッダと同様のMIME形式のメッセージの内容。それは、開発を行い、展開が非常に簡単ですので、この単純なモデルでは、ウェブ功績の初期の成功です。
Webチャットの要求と応答システムは、最も重要なステップである、と私は、要求と応答が重要なステップになる理由を説明するために11以降のだろうどこ？
このステップをエスケープするすべてのWebアプリケーションが開いていないので、C / Sクライアントは - 操作の基本モードは、そのような要求することによって、クライアント - サーバアーキテクチャは、現在のネットワークアプリケーション（サーバー・アーキテクチャは、特別なC / sの構造であるB / S・ブラウザ）を構築することですサーバから所望のデータを取得します。
ここでは、知っているだろう、実際にはアイデアの根底にある実現上の他のWebアプリケーションとウェブライブチャットシステムも例外ではありません。
すなわち、核となるアイデア：ユーザーがサーバーにメッセージを送信する（メッセージ梱包、開梱、濾過し、前方に保存）した後、サーバは、ユーザB（または集団）を処理する一連のメッセージを転送します。
インスタントメッセージングプログラム
9012年、私たちは今も比較的新しい技術を見て今、プログラムは、この章のおよそ約4種類] [0-1]だけの簡単な導入を実現しました。詳細については、今後の記事を参照してください。
- Ajaxの世論調査
- アヤックスロングポーリング
- ウェブソケット接続長
- サーバー・送信・イベント（番組情報とオンラインまれ）
それ自体でアヤックスアヤックスロングポーリングとポーリングはHTTPベースされ、いずれか一方が欠陥：ポーリングは、より高速な処理を必要とし、長いポーリングが同時実行性の要件を処理するために、より多くの容量であり、両方が「受動的なサーバー」ですサーバが積極的に情報をプッシュしませんが、Ajaxのリクエストの後にクライアントから返された応答を送信：それは反映しています。
HTML5のWebSocketは、単一のTCP接続、サーバとクライアントの間で容易にそのようなWebSocketのデータ交換上の全二重通信を開始することによって提供されたプロトコルです。WebSocketのイニシアチブは、サーバーがクライアントにデータをプッシュすることができます。従来のHTTPプロトコルとは異なり、プロトコルは、サーバとクライアントの間で全二重通信を実現することができます。簡単に言えば、あなたは最初にこの部分は、httpに必要、クライアント側とサーバー側との間の接続を確立する必要があります。接続が確立されると、対等に、クライアントとサーバは、要求と応答との間の差が存在しない場合、相互にデータを送信することができます。
SSEは、サーバー送信されたイベントと呼ばれるHTML5の新機能、です。これは、サービスがクライアントにデータをプッシュできるようにすることができます。それらはhttpプロトコルに基づいているがSSEは、本質的に長いポーリングする前に、別の短い世論調査では、しかし、ポーリングリクエストを送信するためにクライアントが必要です。SSE最大の特徴は、サーバのデータが更新されると、それはクライアントにすぐに送信することができます限り、達成することができ、どのクライアントが要求を送信していないです。
優れた性能の「受動的」に比べて、この「積極的な」。
【2019年10月25日]