WebSocket は、HTML5 が提供し始めた、単一の TCP 接続で全二重通信を行うためのプロトコルです。 WebSocket 通信プロトコルは、2011 年に IETF によって標準 RFC 6455 として指定され、RFC7936 によって補足されました。 WebSocket API も W3C によって標準として指定されています。
WebSocket を使用すると、クライアントとサーバー間のデータ交換が簡単になり、サーバーがアクティブにデータをクライアントにプッシュできるようになります。 WebSocket API では、ブラウザとサーバーはハンドシェイクを完了するだけでよく、双方向データ送信のために両者の間に永続的な接続を直接作成できます。
背景
プッシュ技術を実装するために、多くの Web サイトではポーリング技術が使用されています。ポーリングとは、ブラウザが特定の時間間隔 (1 秒ごとなど) でサーバーに HTTP リクエストを発行し、サーバーが最新のデータをクライアントのブラウザに返すことです。この従来のモデルには明らかな欠点があります。つまり、ブラウザはサーバーにリクエストを継続的に送信する必要があります。ただし、HTTP リクエストには長いヘッダーが含まれる可能性があり、実際の有効なデータはその一部にすぎない可能性があり、これは明らかに無駄です。大量の帯域幅とその他のリソース。
ポーリングのための比較的新しいテクノロジーは Comet です。このテクノロジーは双方向に通信できますが、それでも繰り返しリクエストが必要です。さらに、Comet では、一般的に使用される長いリンクもサーバー リソースを消費します。
この場合、HTML5 は WebSocket プロトコルを定義します。これにより、サーバーのリソースと帯域幅がより節約され、よりリアルタイムな通信が可能になります。
利点
● 制御のオーバーヘッドが少ない。接続の作成後にサーバーとクライアントの間でデータが交換される場合、プロトコル制御に使用されるパケット ヘッダーは比較的小さいです。拡張機能を使用しない場合、サーバーからクライアントへのコンテンツの場合、このヘッダーのサイズは (パケット長に関連して) 2 ~ 10 バイトになります。クライアントからサーバーへのコンテンツの場合、このヘッダーには 4 バイトのマスクを追加する必要があります。毎回完全なヘッダーを送信する HTTP リクエストと比較して、このオーバーヘッドは大幅に削減されます。
● リアルタイムパフォーマンスが強化されました。プロトコルは全二重であるため、サーバーはいつでもプロアクティブにデータをクライアントに送信できます。サーバーが応答する前にクライアントがリクエストを開始するのを待つ必要がある HTTP リクエストと比較すると、Comet などの同様の長いポーリング方法と比較しても遅延が大幅に少なく、短期間により多くの回数データを配信できます。時間。
●つながりを保ちましょう。 HTTP とは異なり、Websocket は最初に接続を作成する必要があるため、ステートフル プロトコルとなり、その後の通信中に一部の状態情報が省略される可能性があります。 HTTP リクエストでは、各リクエストにステータス情報 (ID 認証など) を含める必要がある場合があります。
●バイナリサポートの改善。 Websocket はバイナリ フレームを定義しており、HTTP よりも簡単にバイナリ コンテンツを処理できます。
●拡張対応可能。 Websocket は拡張機能を定義しており、ユーザーはプロトコルを拡張して、カスタマイズされたサブプロトコルを実装できます。たとえば、一部のブラウザは圧縮などをサポートしています。
●圧縮効果が向上します。 HTTP 圧縮と比較して、適切な拡張サポートを備えた Websocket は、以前のコンテンツのコンテキストを継承し、同様のデータを送信する際の圧縮率を大幅に向上させることができます。
関連知識の詳細については、PHP 中国語 Web サイト をご覧ください。 !