HTTP と WebSocket

デジタル世界全体の基盤は、機械間の通信です。認可されたクライアントがリクエストを作成し、それをサーバーが受信、解釈し、適切なレスポンスを提供します。これは、普通の人々にとってのデジタル通信の共通の理解です。しかし、舞台裏では、作業は複雑で面倒です。

アプリケーション開発者は、このクライアントサーバー通信が正しく機能することを保証するために多くの作業を行う必要があります。適切な通信プロトコルを選択することは、これらのタスクの1つです。開発者が有効な通信プロトコルを選択しようとすると、HTTP と WebSocket の2つの一般的な概念に直面します。

これら二つを明確にし、それらの類似点、機能、およびその他の側面を理解することは、実際のニーズに基づいて正しい選択を保証するために重要です。

HTTP の紹介#

まず、HTTP について理解しましょう。おそらく、デジタル通信分野で最も一般的に使用されているプロトコルです。HTTP の最初のバージョンは1989年に公開され、機能とアプリケーションの範囲は限定されていました。しかし、それはすぐに改善され、アップグレードされて、ブラウザとサーバー間の大規模な通信をサポートするようになりました。

HTTP は一方向のプロトコルであり、任意の時点で通信の一方の側だけが情報を送信または受信できます。クライアントがサーバーにリクエストを送信するとき、このリクエストは HTTP または HTTPS の形式で送信され、サーバーはリクエストを受信した後、対応する一意のレスポンスをクライアントに送信します。各 HTTP または HTTPS リクエストは、サーバーとの新しい接続を確立し、レスポンスを受信した後、自動的に接続を終了します。

HTTP の主な特徴には以下が含まれます：

• ステートレス
• 接続指向のプロトコル（SCTP や TCP など）に基づいて動作可能
• 情報は ASCII でエンコード
• HTTP リクエストの主なコンポーネントには HTTP バージョン（HTTP/1.1、HTTP/2、HTTP/3）、メソッド、HTTP ヘッダー、ホスト情報、およびメッセージが含まれる

WebSocket とは？#

WebSocket は、クライアントとサーバー間のリアルタイム双方向通信を実現できる通信プロトコルです。

WebSocket はウェブアプリケーションでリアルタイム双方向通信チャネルを作成するためのプロトコルです。従来の HTTP リクエスト（通常、1 リクエストに対して 1 レスポンス）とは異なり、WebSocket は持続接続を確立でき、サーバーがクライアントにリアルタイムでデータをプッシュしながら、クライアントからもデータを受け取ることができます。従来のポーリングと比較して、WebSocket はネットワークトラフィックと待ち時間を大幅に削減し、データ伝送の効率とスピードを向上させます。リアルタイムなウェブアプリケーションやオンラインゲームの開発に特に適しています。

WebSocket の主な特徴には以下が含まれます：

• 持続的な TCP 接続に基づき、クライアントまたはサーバーが終了リクエストを開始するまで開いたまま
• HTTP プロトコルに基づいて構築されており、すべての WebSocket リクエストは標準の HTTP プロトコルを介して送信され、次に特定のヘッダー情報としてサーバー側でアップグレードとして識別
• WebSocket プロトコルはフレーム（データパケット）に基づいており、完全なデータパケットは複数のフレームに分割でき、各フレームにはデータとヘッダー情報の一部を含む

HTTP と WebSocket の関係#

上記の紹介から、HTTP および WebSocket プロトコルの両方が：

• データ伝送に TCP プロトコルを使用
• クライアントとサーバー間の通信に使用される

以下の表を通じて、HTTP と WebSocket の違いをより直感的に示すことができます。

HTTP	WebSocket
各リクエストに対して新しい接続を確立（HTTP の長時間接続を使用しない場合、例：HTTP/1.1 Keep-Alive）、通信終了後に接続を閉じます	初期ハンドシェイクの成功後に接続が開いたまま、積極的に閉じるかエラーが発生しない限り
一方向通信モード、クライアントがリクエストを送信し、サーバーがレスポンスを返し、新しい通信ごとに接続を再確立する必要があります	双方向通信モード、接続を確立した後、クライアントとサーバーは再接続することなく随時データを送信できる
各通信は完全なリクエストとレスポンスヘッダーを送信する必要があるため、頻繁な短いメッセージ通信に対するオーバーヘッドが大きいです	接続が確立された後、データ伝送はより軽量で、毎回ヘッダー情報を伝送する必要がないため、高頻度、低待ち時間の通信要求に適しています
主に比較的安定したデータの伝送に使用されます	主にリアルタイムデータの伝送に使用されます
各リクエストに対して接続を再確立し、ヘッダーを通じて必要な情報を運ぶ必要があるため、帯域幅使用効率と応答速度に影響を与える	継続的な接続は、各リクエストに対して接続を確立し必要な情報を省略するステップを排除するため、より低い待ち時間とより高い帯域幅使用効率をもたらします
頻繁なリクエストがパフォーマンスに影響を与える	頻繁なリクエストがパフォーマンスに影響を与えない

どのプロトコルを使用するかの選択方法#

前のセクションでの HTTP と WebSocket の利点と欠点の比較を基に、使用シナリオを 2 つの異なる次元から評価できます：

1. データが急速に変化するか、ビジネスがリアルタイムデータに依存しているかどうか
2. 頻繁な双方向通信が関与しているかどうか

例えば、ジャックが各ユーザーがチャットパートナーからリアルタイムでビデオデータを受信し、自分のビデオストリームデータを相手に送信する必要があるビデオチャットアプリケーションを構築したい場合、WebSocket が最良の選択です。

Logto の管理コンソールは、ユーザーが構成を変更した時にのみ状態を変更するため、現在のログインユーザーのリソース使用状況を頻繁に取得する必要はありません。ユーザーがリソースを操作する際にタイムリーにリソースステータスを再取得する必要があります。この視点から、HTTP は Logto Admin Console の使用シナリオに非常に適しています。同様に、ほとんどのクラウドサービスダッシュボードにとって、HTTP をダッシュボードとサーバー間の通信プロトコルとして選択できます。