WebSocket対HTTP通信プロトコル
WebSocket対HTTPの要約
食べ物の注文から事実の検索、オンラインでの医師との会話まで、インターネットでの日常的な活動の多くは、WebSocket または HTTP 通信プロトコルによって実現されています。開発者としてアプリを構築するとき、次の通信プロトコルのうちどれを使用する必要がありますか? WebSocket と HTTP を比較した場合の違いは何ですか?簡単に言うと、全二重通信プロトコルである WebSocket は比較的新しく、< などのリアルタイム アプリケーションに適しています。 i=3>アプリ内チャット、通知、音声、またはビデオ通話。一方、半二重通信プロトコルである HTTP は以前から存在しており、登場以来 Web サイトの基礎となってきました。
この比較では、これら 2 つの通信プロトコル、その類似点と相違点について詳しく学び、どちらを選択すべきかを理解します。飛び込んでみましょう！
WebSocket接続について
WebSocket プロトコルは、クライアントとサーバーが全二重チャネルで通信する方法を記述します。つまり、クライアントとサーバーの両方が、存続期間の長い接続を介して同時にデータを送受信できます。このタイプの通信は HTTP ポーリングよりもオーバーヘッドが少ないため、アプリケーションにリアルタイム機能においていくつかの利点をもたらします。
WebSocket接続の利点
双方向通信
接続の両側がいつでもメッセージを送信できるため、WebSocket 接続は、大量のデータを迅速に送受信する必要がある場合に最適な選択肢です。
複数のクライアントを接続する単純なチャット ルームを想像してください。 WebSocket サーバーが会話を管理すると、クライアントはサーバーにメッセージを送信し、サーバーはそれを接続されている他のすべてのクライアントに即座に中継します。ユーザーに関する限り、リアルタイムで互いにメッセージを送信できます。
これは、次のような単純なバージョンです。
待ち時間の短縮
比較的高頻度でデータを取得する HTTP 接続の一般的なパターンはポーリングで、クライアントは定期的に新しいサーバー データをリクエストします。おそらく、この通信方法の最大の欠点は遅延です。頻繁なリクエストまたは長時間実行されるリクエストと、高い遅延の間で妥協する必要があります。
WebSocket 接続を使用すると、データは利用可能になるとすぐに送信されます。クライアントはそれをリクエストし続ける必要はありません。その結果、オーバーヘッドとネットワーク トラフィックの一部が軽減され、遅延が大幅に短縮されます。
WebSocket と HTTP の通信図
永続的な接続
従来の HTTP 接続では、クライアントがリクエストを作成し、サーバーがその応答を送信した後、接続が閉じられます。クライアントがさらにデータを必要とする場合は、新しい接続を開く必要があります。
HTTP/1.1 では TCP/IP 接続の再利用を可能にする永続的な接続が導入されましたが、このメンタル モデルは依然として役に立ち、ほぼ正確であることに注意してください。
WebSocket 接続を使用すると、クライアントはサーバーとのすべての WebSocket 通信に対して単一の接続を開いて使用できます。この永続的な接続により、低遅延の双方向メッセージが可能になります。
この WebSocket 接続はステートフルにすることもできます。 HTTP 接続はステートレスです。つまり、各リクエストは分離して処理され、その前に行われたリクエストに関する情報は保持されません。一方、WebSocket は、永続的な接続のおかげでステートフルです。
アプリケーションがステートフル機能を利用するかどうかは、開発者と WebSocket 接続の使用方法に完全に依存します。
HTTP接続について
HTTP プロトコルは、リクエスト/レスポンス プロトコルとして設計されました。ブラウザなどのクライアントは Web サーバーにリクエストを送信し、Web サーバーは には、HTML や CSS ファイルなど、リクエストに対応するリソースが含まれます。 HTTP 接続が開いている間は半二重のみです。つまり、通信は一方向のみになります。応答を受信すると、多くの場合、接続は閉じられます。
HTTP/1.1 では、TCP/IP 接続を再利用する永続的接続が導入され、パフォーマンスがある程度向上しました。ただし、これらの永続的な接続の詳細はサーバーごとに異なり、ほとんどの場合、非アクティブ タイムアウトに基づいて最終的に閉じられます。したがって、これは HTTP 接続機能への歓迎すべき追加ですが、それでも WebSocket 接続と直接比較することはできません。
HTTP プロトコルは、その目的であるリクエストに応答するという目的において非常に優れています。ただし、チャット や ライブ イベントなどのリアルタイム通信のユースケースを処理するようには構築されていません。ストリーミング、今日人々が期待しているものです。
それでも、HTTP には WebSocket プロトコルに比べていくつかの利点があります。
HTTP接続の利点
シンプルさと遍在性
HTTP 接続の持続力は、広く普及していることと、簡単にアクセスできることから生まれています。 HTTP の 3 つのメジャー バージョンの間では、事実上すべての Web サーバーと Web ブラウザが何らかの形式でプロトコルを利用できます。
HTTP/1.1。 サイトの約 35% は依然として HTTP/1.1 以下を使用しています。
HTTP/2。 全サイトの 39.3% で使用されています。
HTTP/3。 全サイトの 25.7% で使用されています。
ステートレスな性質とキャッシュのサポート
HTTP リクエストはステートレスで自己完結型であるため、特に静的なコンテンツやアセットを扱う場合、レスポンスをキャッシュすると Web サイトのパフォーマンスが向上する可能性があります。キャッシュはさまざまなレベルで実行できます。
ブラウザの場合: これにより、サーバーに接続する必要がまったくなくなります。
エッジ: これは、CDN と同様に、ユーザーの地理的位置に近いサーバーを使用します。 .
サーバー上: これにより、結果が毎回同じ場合、サーバーはコストのかかる再計算を回避できます。
WebSocket メッセージはステートフルであり、通常はコンテキスト依存であるため、HTTP 応答ほど簡単にキャッシュすることはできません。これらのメッセージは頻繁に変更されるため、ほとんどの場合、キャッシュは役に立ちません。
堅牢なセキュリティメカニズム
HTTP プロトコルは広く普及しているということは、HTTP プロトコルがセキュリティ体制を改善するための複数の取り組みの対象となってきたことを意味します。
HTTPS
元の HTTP プロトコルには、重要な点が 1 つ欠けています。それは、要求メッセージと応答メッセージが暗号化されていないため、悪意のある攻撃者が比較的簡単に傍受して読み取ることができるということです。
この問題は、Transport Layer Security (TLS) または Secure Sockets Layer (SSL) を使用して要求と応答を暗号化する HTTP の変種である HTTPS によって軽減されます。悪意のある攻撃者はパケットを傍受できる可能性がありますが、この暗号化のおかげでその内容を読み取ることはできません。
HTTP の厳格なトランスポート セキュリティ
もう 1 つの HTTP 関連のセキュリティ メカニズムは、HTTP Strict Transport Security (HSTS) です。 HSTS を使用すると、サーバーはMITM 攻撃、プロトコル ダウングレード攻撃などの一般的なセキュリティ問題を防ぐためのポリシーを指定できます。 a>。Cookie ハイジャック、
サイトは、次のように HTTPS 接続経由で適切なヘッダーを返すことで HSTS を利用できます。
正しく構成されている場合、HSTS は、ユーザーが標準の HTTP リンクをクリックした場合でも、ブラウザーが常にサイトの HTTPS バリアントを要求するようにします。その結果、ユーザーは、簡単に軽減できる多くの攻撃からユーザーを保護するセキュリティ層を手に入れることができます。
WebSocket対HTTP: 適切なプロトコルを選択する
WebSocket または HTTP プロトコルを使用する前に、何を構築しているのか、そしてその理由を検討してください。各通信プロトコルは、通常他の通信プロトコルでは劣るいくつかの領域で優れていることに注意してください。
WebSocket 接続と HTTP 接続の間の技術的なトレードオフ
これら 2 つの通信プロトコル間の技術的なトレードオフを理解すると、どちらがプロジェクトに最適であるかがわかります。
接続のセットアップと管理
時間の経過とともに接続をどのように確立し、管理する必要があるかを検討してください。
WebSocket の場合、永続的な接続はクライアントとサーバー間のハンドシェイクによって確立されます。メッセージ間に大幅な遅延がある場合でも、セッション中は開いたままになります。
HTTP では、ハンドシェイクによって接続が確立され、要求と応答のサイクルに使用されます。 HTTP/1.1 では、同じ TCP/IP 接続を複数の要求と応答のペアに再利用できるため、オーバーヘッドが削減され、遅延が改善されますが、WebSocket ほどではありません。接続は、数秒から数分の範囲の比較的短い時間内に閉じられます。
データの送信とエンコード
データをどのように送信するかを検討してください。
WebSocket 接続では全二重双方向通信が使用され、接続のどちらの側でも必要に応じていつでもメッセージを送信できます。 HTTP 接続では半二重通信が使用されます。一度に通信できるのは 1 者だけであり、サーバーのメッセージは常にクライアントからのリクエストに応答します。
WebSocket と HTTP はどちらも、バイナリ エンコードされたデータだけでなく、JSON、XML、プレーン テキストなどのテキスト ベースの形式でエンコードされたデータを送信できます。
エラー処理と回復
どのエラー処理方法がユーザーにとって最も影響が少ないかを検討してください。
WebSocket 接続は、アプリケーション コードのエラーなど、さまざまな理由で失敗する可能性があります。クライアントには、リッスンできるエラー イベントが送信され、このリスナーでエラーを適切に処理できます。ただし、WebSocket サーバーがアプリケーション コード内で実行されている場合、アプリケーション レベルでの致命的なエラーは、アプリが適切なエラー処理を実装する能力に劇的な影響を与える可能性があります。
HTTP 接続でも同様の状況が発生する可能性はもちろんありますが、エラー処理に関しては、特定の一般的なアーキテクチャが利点をもたらします。 HTTP では、リクエストが成功したかどうかを大まかに示すためにサーバーが応答できるステータス コードの範囲を指定します。 4xx と 5xx の範囲は、それぞれクライアント エラーとサーバー エラー用に予約されています。
リクエストが Web サーバーとしての NGINX と PHP を通じて処理される Web アプリケーションを考えてみましょう。 a> を動的バックエンド言語として使用します。アプリケーション ロジック内の何かが致命的なエラーまたはプロセスの終了を引き起こしたとします。これは、クライアントに応答を提供する NGINX の機能には影響しません。これは、HTTP 503 - サービスが利用できません メッセージである可能性が高くなります。
もちろん、この分離はアプリケーションのアーキテクチャによって異なります。 Node.js Express アプリなど、アプリケーションと Web サーバーが同じプロセス内で一緒に実装されている同様の状況を考えてみましょう。ここで致命的なエラーが発生すると、Web サーバーも終了し、クライアントが受け取るエラーの有用性が制限されます。
スケーラビリティ
アプリケーションのリソース消費のニーズを考慮してください。
WebSocket 接続は、その動作が非常に効率的になるように設計されています。これらはイベント駆動型であり、メッセージを送信する必要がある場合にのみメッセージが送信されます。
HTTP 接続は、ロング ポーリングを通じてリアルタイム機能に似た機能を実現できます。このポーリングでは、リクエストが送信され、何かが発生するまでオープンされたままになります。と応答します。リアルタイム通信のこの大まかな近似には、特に大規模な場合にいくつかの制限があります。 HTTP リクエストは無期限にオープンしたままにすることはできません。つまり、クライアントは定期的に新しいロング ポーリング リクエストをオープンする必要があります。時間の経過とともに、これらの存続期間の長い HTTP リクエストをすべて処理するオーバーヘッドが増加します。
HTTP ストリーミングでは、接続は無期限に開いたままになり、継続的なデータ ストリームが容易になります。これは概念的には WebSocket に似ていますが、依然として HTTP 経由で実行され、依然として一方向です。クライアントは HTTP ストリーミング経由でサーバーにメッセージを送信できません。
WebSocket 接続と HTTP 接続のパフォーマンスに関する考慮事項
アプリケーションのパフォーマンスの期待を考慮してください。
永続的な接続のおかげで、WebSocket はオーバーヘッドと遅延が削減されるという利点があります。これにより、パフォーマンスが向上し、リアルタイム更新が高速化され、HTTP3 ウェイ ハンドシェイクや HTTP 固有のアプリケーションなどに費やされる処理能力が削減されます。受信リクエストと認証/認可を管理するためのコード
HTTP は通常、セッションの存続期間中に複数の接続を処理する必要があるため、当然、WebSocket と比較してより多くの時間とリソースを費やします。
WebSocket 接続と HTTP 接続のセキュリティ
どれがセキュリティを確保するのが最も簡単かを検討してください。
WebSocket 接続と HTTP 接続は、セキュリティに関する考慮事項に関して似ています。どちらにも安全でない亜種と安全な亜種があり、適切に保護されていない場合、どちらもいくつかの一般的な攻撃の犠牲になる可能性があります。 HTTP および に対するクロスサイト スクリプティング攻撃など、各プロトコルに特有の注意が必要な攻撃もあります。 =3>WebSocket に対するクロスサイト WebSocket ハイジャック。
ただし、これらを適切に構成し、TLS 暗号化を使用すると、ほとんどの脅威を軽減でき、両方のプロトコルを十分に安全にすることができます。
通信プロトコルへのハイブリッド アプローチ
通常、システム内で両方のプロトコルの利点を生かして両方のプロトコルを使用することをお勧めします。つまり、ほとんどの標準 Web トラフィックには HTTP 接続を使用し、通知 などのリアルタイム通信が必要なものには WebSocket 接続を使用します。 a>。ビデオ通話、またはメッセージング/チャット
補完的または代替テクノロジーの評価を検討することもできます。結局のところ、リアルタイム通信に関して言えば、WebSocket と HTTP だけが選択肢ではありません。 WebRTC は WebSocket に似ていますが、主な違いはピアツーピア接続 サーバーに依存せずに実行できます。これはビデオ通話の場合に特に役立ち、サーバーに負荷をかけることなく参加者が直接通信できるようになります。
安全でスケーラブルかつ信頼性のあるアプリ内通信のための通信プロトコル
これで、WebSocket と HTTP 通信プロトコルがどのように使用されるかをしっかりと理解できたはずです。それらの長所と短所を見て、そのトレードオフを理解できるようになりました。
幸いなことに、どちらかを選択する必要はありません。 2 つの通信プロトコルは一緒に使用することができ、多くの場合、一緒に使用する必要があり、それぞれが最適な機能を実行できるようになります。アプリケーションにリアルタイム通信およびストリーミング機能を実装する必要がある場合は、Sendbird を確認してください。 Sendbird の API とクライアント SDK は、アプリ内チャット、通話ライブ ストリーミング。 Sendbird のチャット サービスは、チャット システムの長期にわたる成長と維持に伴う問題 (大規模かつリアルタイムで確実かつ安全に実行するなど) を抽象化します。これは、アプリケーションの中核的な部分に集中できることを意味します。
試してみますか?無料でサインアップします。契約やクレジット カードは必要ありません。
アプリ内コミュニケーションの構築を楽しみましょう! 📱