転載-WebSocketプロトコル分析

さて、プッシュ技術を達成するために多くのサイトが、技術が使用され、ポーリングです。ポーリングは、特定の時間間隔（例えば、毎秒）を指し、それはブラウザによってサーバにHTTPリクエストを送信し、サーバによって、ブラウザにデータを返します
。HTTPプロトコルは不活性であるので、要求を開始しただけで、クライアント、サーバーはデータを返します。前提条件ポーリング技術も、このメカニズムに基づいています。WebSocketのサービス側プッシュ技術に属し、本質的にアプリケーション層プロトコル、全二重双方向通信を実現することができる永続的な接続です。ポーリング技術とHTTPストリーミング技術について話をする、のWebSocketを導入する前に。

記事のディレクトリ

従来のポーリング方式：Ajaxの短いポーリング
彗星
- Ajaxのロングポーリング
- HTTP流
HTML5は、サーバープッシュを実装します
- SSE
- WebSocketを

Ajaxの短いポーリング（Ajaxのポーリング）

短いポーリングが定期的にサーバにHTTPリクエストを送信しているのAjaxクライアントは、関係なく、サーバーが実際にデータを取得するかどうかの、応答がクライアントに返されます。なぜならHTTP / 1.1の要求応答にそれぞれ対応し、持続的な接続（一度確立されたTCP接続、複数の要求を送信）し、技術パイプライン HTTPリクエストが後にTCP接続を確立するために、複数の非同期要求を開始することができるように、（非同期送信要求）。

この伝統的なモデルは、すなわち、サーバに常にブラウザ要求への必要性を明らかに不利益をもたらしますが、それぞれの時間は、HTTPリクエストは、データのみを真に効果的であることがよく、長い伝送リクエストヘッダフィールドをもたらします小さな割合は、（クッキーフィールドなど）、サーバーは明らかに、帯域幅および他のリソースを無駄にします。

友人は、Ajaxは、代わりに3秒の期間として、伝送時間を増やすことができると思うかもしれません。しかし、長い間、プロジェクトのための比較的高いリアルタイム要件は、ページが遅すぎるデータを更新します。

彗星（サーバープッシュ）

サーバへのデータ取得のための比較的新しい技術は、ポーリング彗星、サービス側プッシュです。サーバは、クライアントがHTTPリクエストを送信するプッシュすることです後に簡単に言えば、サーバは、積極的にクライアントにデータをプッシュすることができます。Ajaxの長いポーリングとHTTPストリーミング：彗星は、2つの方法で達成しました。

Ajaxのロングポーリング（アヤックスロングポーリング）

Ajaxのロングポーリング自体は本当のプッシュではありません。ポーリングは、長い短いポーリングの変種です。クライアント上のサーバーにHTTP要求の後、サーバは常に即座に応答しない：サーバーが最新のデータを取得すると、データがクライアント端末に送信されます。データが更新されていない場合、サーバーは、この接続を維持する、更新データを待って、クライアントへのデータの送信が終了する前に。サーバーのデータを長期間更新されていない場合はもちろん、一定期間後に、要求がタイムアウトします。クライアントが受信した後、タイムアウトメッセージは、サーバーへのHTTP要求を再送信します。

つまり、サーバー上でのみ更新されますデータは、データがクライアントに送信されます。この方法では欠点もあります。サーバーは、クライアントへの送信データにイニシアチブを取るが、それでも繰り返し（HTTPリクエストあまり短いポーリングの数よりも）要求を発行する必要があります。することができますが、

ショートとロングポーリングポーリング同じポイントクライアントがサーバーへのHTTP要求を開始する必要があることは、異なっどのようにサーバーの応答で：即時短いポーリング応答サーバにかかわらず、データが有効であるかどうかの、データの更新が長いポーリング応答を待つことです。

HTTP流

異なり、HTTPポーリング技術をストリーミング、HTTPストリーミングに一度だけTCPコネクションを確立するために HTTP通信3ウェイハンドシェイクの後、クライアントが開始サーバーへのHTTPリクエスト、およびサーバは、クライアントへの接続のオープン、定期的に送信データを保持。明確にクライアントにサーバーから切断の非存在下における双方がデータを送信し続けます。データがサーバーに更新されていない場合、つまり、サーバは応答を返しますが、接続されて残っていない。データが更新されている場合、それはすぐにクライアントにデータを送信します。この時点では何度も何度もHTTPリクエスト、プロセスを開始します。

JSにおいて、3は、HTTPストリーミングreadystatechangeイベントリスナーとのreadyStateの検出値場合に達成することができます。サーバから受信したデータでは、定期的にreadyStateの値が3になります。値はreadyStateの3になると、responseTextプロパティには、受信したすべてのデータを保存します。この時点で、我々は、任意の場所から最新のデータを取得するために開始することを決めた、以前に受信したデータを比較する必要があります。次のようにHTTP XHRオブジェクトによってやり方をストリーミング：

httpStream =（URLは、プロセッサ、完成）=> {せ
  てみましょうXHR =新しいXMLHttpRequestを（）
  = 0受信しましょう
  （ 'get'が、URL真）xhr.open 
  => {）（、xhr.addEvetntListener（ 'readystatechange'を
    聞かせて結果
    IF（xhr.readyState === 3）{ 
      結果= xhr.responseText.slice（受信）
      受信+ = result.length 
      プロセッサ（結果）
    }他（xhr.readyState === 4）{場合
      xhr.responseText（終了）
    } 
  }）
}

限りのreadyStateが3であるとして、そして最新のデータを取得するにはresponseTextに分離しました。ここで受信文字を処理されたレコードの数を示します。最新のデータは、プロセッサのコールバック関数によって処理されます。readyStateのが4である場合、完全取得を表すデータは、それがxhr.responseTextコールバック処理に直接渡され終了することができます。

次のように呼び出します。

httpStream（URL、データ=> { 
  にconsole.log（データ）
}、finishedData => { 
  にconsole.log（データ）
}）

少し要約を行うには、ストリーミング（ロングとショート）ポーリングとHTTPのための

従来のポーリング技術（Ajaxのポーリング短い）、サーバにHTTPリクエストを送信するクライアントであるにかかわらず、データが更新されているかどうかの、サーバーがデータを送信します。要求が応答に対応します。
サーバープッシュ技術（Ajaxのロングポーリング）は、短いポーリング変異体は、クライアントは、サーバーへのHTTPリクエストを送信しているそうでない場合は、サーバーの遺骨が接続されて、データのみの更新データ送信後まで待つように。そして、次のHTTP要求、応答に対応する要求を開始します。
サーバープッシュ（HTTPストリーミング）、クライアントを開始一度だけHTTPリクエスト、サーバーに接続されている状態では、データの更新後、サーバーがデータを送信、または接続されたままになります。このとき、requset応答の複数に相当します。
短いポーリング、ロングポーリング、またはHTTPストリームかどうか、という点で同じことが、クライアントへのHTTP要求を開始するために必要とされています。

HTML5は、サーバープッシュを実装します

（結果更新イベント、チャットルーム、等を達成するために）サーバプッシュの重要性のため、二つのインターフェース、SSEとのWebSocketを達成するためにHTML5サーバー側のプッシュ。

SSE

SSE（サーバ送信Eevents、サーバがイベントを送信する）がサーバへの一方向の接続を作成するために使用され、サーバは、この接続を介してデータの任意の数を送信することができます。SSEは、次の要件を達成しています

サーバの応答のMIMEタイプはtext /イベント・ストリームでなければなりません。
指定した出力形式に従わなければなりません。

使い方は以下のように、実際には、使用にSSEは、比較的単純な後のサーバープッシュを、理解しています

//のEventSourceが受け取るパラメータは、同種である必要があります。
// event.dataオブジェクトでサーバから受信し、記憶されたイベントリスナメッセージのメッセージを使用します。
EventSource =新しい新しいソースLET（ 'のindex.php'）
source.onmessage = E => { 
  にconsole.log（e.data）
}

SSEはIE、上記ios4.0でサポートされている、android4.4以上SSEをサポートしていません。

WebSocketを

...以前に、そして最終的にはWebSocketのに非常に長いために道を開く:)読むために忍耐を気にしないすべての私たちの友人に感謝。

簡単に述べると、のWebSocketは、アプリケーション層としてHTTPプロトコルとプロトコルであり、TCP / IPプロトコルのサブセットです。HTTPプロトコルは、片方向通信プロトコルであるだけで、クライアントがHTTPリクエストを送信し、サーバーはデータを返します。WebSocketプロトコルは、接続が確立された後、クライアントとサーバができ、双方向通信プロトコルである率先して相互にデータを送受信します。接続が確立された後、前提を確立のWebSocketプロトコルは、HTTPプロトコルを必要とし、持続的な接続上の双方向通信は、HTTPプロトコルとは何の関係もありません。

WebSocketのプロトコルの目標は、別の永続的な接続で全二重の双方向通信を提供することです。クライアントとサーバが相互にデータを送受信するためのイニシアチブを取ることができます。あなたはJSでのWebSocketを作成した後、要求を開始するためにブラウザに送信されたHTTPリクエストがあるでしょう。HTTPのアップグレードを使用して接続を確立するために、サーバーの応答を取得した後、HTTPプロトコル用WebSocketプロトコルを変換します。それだけで正しく動作するにはこれらのブラウザに特殊なプロトコルをサポートし、WebSocketを達成することはできません標準のHTTPプロトコルを使用して、あります。

、慎重に読ん上の段落を覚えておいてください。:)

WebScoketは、カスタムプロトコルを使用しているため、HTTPプロトコルとURLが若干異なっているので。暗号化されていない接続WS：//、httpの代わりに：//。暗号化された接続のWSS：//、代わりにhttps：//で。

JavaScriptは比較的単純なWebScoket契約書を使用して達成され、以下はWebSocketのAPIです

//オープンのWebSocket、URLのパラメータが制限同一生成元ポリシーを渡されていません。
WebSocketを=新しい新しいのWebSocket LET（URL）が

//プレーンテキストの文字列データを送信、オープンイベントをリッスン（オブジェクトが直列化されなければならない場合。）URLが成功のWebSocketを設立したとき。
= websocket.onopen（）=> { 
  IF（websocket.readyState === WebSocket.OPEN）{ 
    websocket.send（ 'Hello Worldの'）
  } 
} 

//イベントリスニングメッセージ、サーバ応答データを受信します。返されたデータは、イベントオブジェクトに格納されています。
= E = websocket.onmessage> { 
  せてデータ= e.data 
  にconsole.logは（データ）
} 

エラーが発生したとき//監視エラーイベントがトリガされ、接続を維持することができません。
= websocket.onerror（）=> { 
  にconsole.log（ 'エラー用WebSocket接続!!'）
} 

接続が閉じられたとき//近いイベントリスナーが、トリガされます。唯一のイベントオブジェクトのクローズイベントは、追加情報があります。閉じた状態は、情報を通して見ることができ
websocket.onclose = E => { 
  letの=クリーン//シャットe.wasCleanです 
  LETコード= e.code //サーバは、ステータスコード値を返します。
  サーバから返された理由= e.reason //メッセージましょう。
}

あなたは、各イベントのイベントハンドラをバインドするDOM0レベルの構文を使用する必要がありますので注意、WebScoket構文は、イベントハンドラをバインドDOM2イベントはサポートされていません。

//正しいです！
websocket.onerror =（）=> {} 
//エラー！
websocket.addEventListener（ 'エラー'、（）=> {}）

WebSocketは、HTTP / 1.1プロトコルによって、ステータスコード101をハンドシェイク、TCP / IPプロトコルのサブセットであるアプリケーション層プロトコルです。言い換えれば、必要性は、サーバー上の101ステータスコードを返し、HTTPプロトコルを用いてのWebSocketプロトコルを確立するには、全二重双方向通信、および関係なく、どのようなHTTPプロトコルをWebSocketをすることができます。

参考ウィキ例のハンドシェイクプロトコル：とフィールドのいくつかを説明します。

接続：接続をアップグレードするように設定する必要があり、それはクライアントの要望をアップグレードするために接続するためにあることを示し

アップグレード：アップグレードは、のWebSocketに設定エクスプレスサーバの応答を取得した後、のWebSocketプロトコルのHTTPプロトコル変換（アップグレード）をアップグレードするためにHTTPを使用しなければなりません。

SEC-WebSocketのキー：ランダムな文字列を、それがプロトコルを確認するために使用されるHTTPプロトコル用WebSocketプロトコルではありません

SEC-のWebSocket-バージョン：表示のバージョンのWebSocket。

Sec-WebSocket-Accept:根据Sec-WebSocket-Accept和特殊字符串计算。验证协议是否为WebSocket协议。

Sec-WebSocket-Location:与Host字段对应，表示请求WebSocket协议的地址。

HTTP/1.1 101 Switching Protocols:101状态码表示升级协议，在返回101状态码后，HTTP协议完成工作，转换为WebSocket协议。此时就可以进行全双工双向通信了。

WebSocket协议的浏览器兼容性较好。

转载地址：https://www.cnblogs.com/unclekeith/p/8087182.html