Webリアルタイム通信

HTTPには非接続性があり、サーバがクライアントからの要求に応答すると、確立された接続が切断されます.これは、サーバが接続を維持するために必要なリソースを削減すれば、より多くの接続を実現できるためです.より多くのユーザーと連絡を保つためには、1つのクライアントと継続的に接続し、サーバリソースを消費するよりも、できるだけ多くのクライアント要求を単発的に処理して、より多くのユーザーと連絡を保つことがより効果的です.
従って、HTTPは双方向通信(フルデュプレクス)ではなく、要求・応答形式の一方向通信(ハーフデュプレクス)モードである.これは,HTTPを使用すると双方向通信のように相互間が接続され続けるわけではないので,通信のたびに大量のメタデータ,すなわちHeaderが送信されることを意味する.しかし、ストリーミングビデオ、配信状況など、複数のWebサービスからリアルタイムで情報を受信するサービスは、必ずよく使用されます.このとき、Pushアラームなどのリアルタイムで変化するデータを受信するには、次の方法を採用します.

Polling

バスカード端末、オペレーティングシステム(キーボード、マウスなどの入力装置)など、他のプログラムまたは装置がどのような状態にあるかをプログラムまたは装置上で継続的に検査するための伝送制御方式.これは、クライアントとサーバがリアルタイム通信を行っているように感じられるように、クライアントが一定時間間隔で要求を継続することを意味する.HTTP通信では、サーバがクライアント要求を受信するまで、必要な時間に応答してはいけないからである.
ただし、クライアントが一定時間ごとにリクエストを送信するため、ポーリング方式ではリアルタイム性を保証することは難しい.リアルタイム性を保つために時間間隔を短くしても、HTTPは単発的な通信であるため、付加的なヘッダが多く、各リクエストや応答が重複して送信され、サーバに負荷がかかります.

Long Polling

ポーリングのようにサーバに無限に要求を送信するのは同じです.ただし、long pollingの場合、リクエストは一定時間おきに送信されず、サーバがタイムアウトするまで待機します.タイムアウト前にサーバからデータを送信すると、クライアントは応答を受信し、要求を再送信します.送信するデータがなくtime-outになった場合、クライアントはリクエストを再送信します.
long pollingは、変更されたデータが発生した場合にのみ応答するため、ポーリングに比べてサーバの負荷が少なく、リアルタイム性も高い.しかし、httpの一方向メッセージ交換ルールが実現されるため、データが頻繁に変更される場合(e.g.複数のユーザが大量のチャットを送信する)には、ヘッダを含む要求が大量に送信される必要がある.したがって,ロングポーリング方式もHTTPプロトコルの限界を示している.

Web Socket

これは、「ネットワーク環境でクライアントとサーバに確立された接続ポイント」を意味し、プログラムがネットワークからデータを送受信できるようにします.
Webソケット(WebSocket)は、HTTP内で個別に定義された双方向接続のためのプロトコル(HTTPの一方向接続ではなく)の接続部分である.Webソケットは、HTTPと同様にOSI 7層の7番目のアプリケーション層に属するTCPベースのプロトコルである.HTTPポート80(ws)および443(wws)上で動作するように設計されている.(wsはhttpに代わり、同様にwssはhttpに代わります.)Webソケットは、クライアントによって要求を最初に受信するのではなく、標準化されたサーバによってコンテンツをクライアントに送信する方法で提供され、接続を維持したままメッセージを返信することができ、現実的なコミュニケーションを実現します.
Websocketプロトコル(ws,wss)は、多くのブラウザ(2020年基準90%のブラウザ)でサポートされており、オンラインゲームや株式取引システムなどのデータ交換を継続する必要があるリアルタイムサービスでよく使用されています.(wssプロトコルは、セキュリティと信頼性の面で使用することを推奨します.)

WebSocket Handshake

WebソケットはHTTPプロトコルと互換性があるため、Webソケットの手動モデリング中にHTTP upgradeヘッダを使用してHTTP内のWebソケットプロトコルに変更します.手動Shakeプロシージャは、ブラウザが「Upgrade:WebSocket」ヘッダーなどとともにランダムに生成した鍵をサーバに送信し、Webサーバはその鍵に基づいてトークンを生成し、ブラウザに返す.

握手:正常な通信が開始される前に、双方が条件について合意した情報交換プロセス

ハンドリクエスト

HTTP 1.1リクエスト、Webソケットプロトコルアップグレード:WebSocketリクエスト

要求ヘッダは、スロットバージョンやスロットキー情報等の

を含む.

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

ハンドレスポンス

http 1.1からWebSocketへのプロトコルアップグレードが成功すると、HTTP Status 101応答

が送信される.

接続が正常である場合、サーバとクライアントとの間にWebSocket接続が確立され、HTTP接続

が一定時間後に自動的に切断する.

Socket.IO

ブラウザとサーバ間のイベントベースのリアルタイム双方向通信を可能にするJavaScriptライブラリで、クライアントとサーバの2つの部分から構成されています.ブラウザで実行されるクライアント・ライブラリとノードの詳細を説明します.jsサーバエンドライブラリは2つの部分から構成されています.Socket.IOはWebSocketだけでなく、WebSocketが使えないブラウザでHTTP Long Poling技術を使うなど、様々な技術を組み合わせて抽象化し、リアルタイム通信をより容易に実現することができる.
このため、WebSocketプロトコルを使用することなくSocketを実行できます.IOでは、HTTP Long Polingのような方式でリアルタイム通信が可能です.これはSocketですこれは、IO転送時にWebSocket手描き用のタイトルに加えて、追加のメタデータが追加されることを意味する.
WebSocket = Protocol, Socket.IO = LIbrary
WebSocket Client - WebSocket Server
Socket.IO Client - Socket.IO Server
したがって、WebSocketクライアントはSocketです.IOサーバに接続できません.Socket.IOクライアントもWebSocketサーバに接続できません.Socket.IOで通信するためには、クライアントもサーバもsocketが必要です.IOを使うべきです.

信頼性:Webソケット接続が成立しない場合、HTTPロングポーリングに取って代わられる.

自動再接続:接続解除時に自動的に再接続されます.

パケット・バッファ:デフォルトでは、ソケットが接続されていない間に発生したすべてのイベントは、再接続するまでバッファされます.

アカウント:要求応答としてAPIを使用する場合は、emit()の最後のパラメータにコールバックを渡すことができます.このコールバックは、相手がイベントを承認したときに呼び出されます.

// server-side
io.on("connection", (socket) => {
  socket.on("update item", (arg1, arg2, callback) => {
    console.log(arg1); // 1
    console.log(arg2); // { name: "updated" }
    callback({
      status: "ok"
    });
  });
});

// client-side
socket.emit("update item", "1", { name: "updated" }, (response) => {
  console.log(response.status); // ok
});

スタジオ:名前空間のサブコンセプトで、すべてのクライアントまたはクライアントのサブセットにブロードキャストできます.(e.g.発信室)

Namespace:ルームに接続する前に接続し、Namespaceで区別できます.

スロット接続手順3:Socket→Namespace→Room

は、「優先ソケット」フェーズで現在接続されているソケットを区別することができる.

Namespaceは、ソケットが接続されているNamespaceでソケットを区別できます.

最後に、スタジオは接続されたSocketと通信することができ、これらのSocketは同じNamespaceであり、同じSocketである.