フロントエンド通信プロトコルの競合: WebSocket と HTTP

リアルタイムアプリケーションでは、情報が利用可能になるとすぐにサーバーから情報を取得する必要があることは言うまでもありません。そして基本的に、従来の HTTP 请求/响应スキーマは機能しません。サーバーは、コンシューマが更新を要求しない限り、または要求するまで、新しいデータに関係なく沈黙を保つためです。

请求/响应この制限により、開発者がより動的なリアルタイム Web のニーズにモデルを適応させようとする際に、さまざまなハッキングや回避策 (そのうちのいくつかは公式に広く採用されるようになりました) が生まれました。

Cometから HTTP ロングポーリングに至るまで、これらすべての技術とアプローチには共通点が 1 つあります。それは、本質的に、真のリアルタイム (イベント駆動型) データ交換/通信の錯覚を生み出し始めるため、サーバーに新しいデータが含まれるときであるということです。データを送信すると、応答が送信されます。

HTTP はイベント駆動型のプロトコルではないため、真のリアルタイムではありませんが、これらのメソッドは、Gmail チャットなどの特定の使用例では実際に非常に効果的です。ただし、低遅延アプリケーションや大規模アプリケーションでは、主に HTTP に関連する処理要件が原因で問題が発生します。

つまり、HTTP では、常に更新を要求 (そして応答を取得) する必要があるため、非常にリソースを消費します。クライアントは接続を確立し、更新を要求し、サーバーから応答を取得し、その後接続を閉じます。このプロセスが何千もの同時ユーザーによって際限なく繰り返され、サーバーに非常に負担がかかることを想像してください。

これらの問題が最終的に開発者のMichael Carter と Ian Hickson を WebSocket の開発へと導きました。WebSocket は基本的にデバイスの TCP/IP スタック上に構築された薄いトランスポート層です。その目的は、本質的に TCP 通信層をできる限りネイティブに近いものとして Web アプリケーションに提供し、セキュリティベースの複雑さやその他の懸念事項を取り除くために一部の抽象化を禁止することです。

この記事では、リアルタイムアプリケーションで HTTP モード 请求/响应 の制限を回避するために使用される手法のいくつか、各手法に関連する問題のいくつか、および WebSocket がこれらの問題の解決にどのように役立つかを見ていきます。

HTTP

HTTP は本質的に客户端-服务器コンピューティングモデルのプロトコルであり请求/响应、World Wide Web の主要な通信手段です。1989 年にTim Berners-Leeによってアプリケーションプロトコルとして提案された元のバージョンは非常に制限されており、より広範囲のブラウザーとサーバーの機能をサポートするためにすぐに改訂されました。

HTTP/1.0 は正式な仕様またはインターネット標準とはみなされていませんが、これらの変更は 1996 年に HTTP Working Group によって最終的に HTTP/1.0 として文書化されました ( RFC 1945 )。

HTTP/1.1

Web ブラウザーとサーバーで最も広くサポートされているバージョンである HTTP/1.1 の登場は、永続的なパイプ接続から新しいリクエスト/レスポンスヘッダーフィールドに至るまで、いくつかの非常に重要な最適化と拡張機能を実装したため、大きな前進となりました。その主なものは、より動的なライブ Web に貢献する多くの改善の基礎となる 2 つのヘッダーです。

Keep-Alive 标头: ホスト間の永続的な通信をセットアップするために使用されます。つまり、複数のリクエストに対して接続を再利用できるため、リクエストの待ち時間が大幅に短縮され、クライアントは最初のリクエストを送信した後に TCP ハンドシェイク (3 ウェイハンドシェイク) 接続を再ネゴシエートする必要がなくなります。もう 1 つのプラスの副作用は、TCP のスロースタートメカニズムにより、時間が経つにつれて接続が速くなるということです。HTTP/1.1 より前は、要求と応答のペアごとに新しい接続を開く必要がありました。

Upgrade 头: 接続を拡張プロトコルモード (WebSocket など) にアップグレードするために使用されます。

HTTPポーリング

HTTP ポーリングは、古典的な要求/応答メカニズムの進歩を表しており、ポーリングには多くのバージョンがありますが、いずれにしても、リアルタイム WEB プログラムに適しているのはロングポーリングだけです。

たとえば、HTTP ショートポーリングでは、AJAX ベースのタイマーを使用して、クライアントデバイスが一定の間隔でサーバーリクエストを送信するようにします。ただし、サーバーは、接続を閉じる前に、新しいデータを提供するか、新しいデータのない「空の」応答を送信することによって、各リクエストに即座に応答します。したがって、新しいデータが利用可能になるとすぐにクライアントが応答する必要があるリアルタイムアプリケーションでは、これはあまり役に立ちません。

この制限が HTTP ロングポーリングの開発につながりました。HTTP ロングポーリングは、本質的にサーバープッシュの機能をエミュレートするために設計された技術です。

基本的にロングポーリングは、サーバーがクライアントの接続を可能な限り長く (通常は 20 秒) 開いたままにし、データが利用可能になるかタイムアウトしきい値に達した後にのみ応答を送信する手法です。

ロングポーリングの主な利点は、理論上、新しい情報が利用可能になるとすぐにクライアントに送信されることです。ただし、欠点は、HTTP リクエストの処理に追加のオーバーヘッドがかかることです。

HTTPストリーミング

HTTP ストリーミングは、Web サーバーが無期限に開かれた単一の HTTP 接続を介してクライアントにデータを継続的に送信できるようにするプッシュデータ転送技術です。基本的に、クライアントは HTTP リクエストを発行し、サーバーは不定の長さの応答を発行します。

ただし、HTTP ストリーミングはパフォーマンスが高く、使いやすく、WebSocket の有力な代替手段ではありますが、制限もあります。リアルタイムの観点から見ると、主な問題は、仲介者が (タイムアウトによって、または単に「ラウンドロビン方式」で複数の要求を処理するために) 接続を中断する可能性があるため、リアルタイム性が常に保証されているわけではないことです。

HTTP/2.0

HTTP/2.0 は、2009 年に Google によって最初に発表された実験プロトコルである SPDY から進化しました。2015 年までに、HTTP ワーキンググループは SPDY 仕様を出発点として、標準案として HTTP/2.0 を公開しました。

これは基本的に Web 通信速度の向上を目的としたパフォーマンスアップデートであり、主に次の 2 つの便利な機能を備えています。

多重化: データをクリアテキストで送信する代わりに、データはバイナリとしてエンコードされてフレーム内にカプセル化され、単一の TCP 接続上でストリームと呼ばれる双方向チャネルに沿って多重化できます。これにより、多くの並列リクエスト/レスポンスが同時に発生することが可能になります。
サーバープッシュ: サーバープッシュは、クライアントが応答を要求する前に、サーバーが HTTP/2 準拠のクライアントに応答を送信できるようにするパフォーマンス機能です。これは、元のリクエストを完全に処理するためにクライアントがレスポンスを「プッシュ」する必要があることをサーバーが認識している場合に便利です。

これらの進歩にもかかわらず、モバイルデバイスの多用による今日のインターネットトラフィックの爆発的な増加により、特にリアルタイムアプリケーションとそのユーザーの需要が増大しているため、HTTP/2.0 がスムーズで透過的な Web ブラウジングエクスペリエンスを提供することが困難になっています。

アドバンテージ

すべてのブラウザは、SSL 証明書をインストールすることにより、HTTPS 経由の HTTP/2 プロトコルをサポートします。
HTTP/2 を使用すると、クライアントは単一の TCP 接続を介してすべてのリクエストを同時に送信できるため、理論的にはクライアントはリソースをより速く読み込むことができます。
TCP は信頼性が高く安定した接続プロトコルです。

欠点がある

リクエストが同時に発生すると、サーバーの負荷が増加します。HTTP/2 サーバーはリクエストを大量のバッチで受信する可能性があるため、リクエストがタイムアウトになる可能性があります。サーバー負荷のスパイクの問題は、ロードバランサーまたはプロキシサーバーを使用して転送リクエストを制限することで解決できます。
HTTP/2 優先順位に対するサーバーのサポートは未熟です。ソフトウェアサポートはまだ進化しており、一部の CDN またはロードバランサーは優先順位を正しくサポートしていない可能性があります。
HTTP/2 プッシュ機能を正しく理解するのは難しい場合があります。
HTTP/2 は HTTP の先頭から末尾までのブロック問題を解決しますが、TCP レベルでのブロックは依然として問題を引き起こす可能性があります。

HTTP/3.0

HTTP/3.0 は、2018 年から開発が進められている HTTP の新しいバージョンであり、まだドラフト標準ですが、Chrome などの一部のブラウザーはすでにサポートしています。

HTTP/3 の目標は、HTTP/2 のトランスポート関連の問題を解決することで、あらゆる形式のデバイスに高速で信頼性が高く安全な Web 接続を提供することです。これを行うために、QUIC と呼ばれる別のトランスポート層ネットワーキングプロトコルが使用されます。これは、他の以前のバージョンのような TCP ではなく、ユーザーデータグラムプロトコル (UDP) 上で実行されます。

ただし、HTTP/3 には次のような潜在的な問題がいくつか発生し始めています。

トランスポート層への影響: HTTP/3 への移行には、アプリケーション層だけでなく、基礎となるトランスポート層の変更も伴います。したがって、HTTP/3 の導入は、以前のバージョンよりも困難です。
信頼性とデータの整合性の問題: UDP はパケットが順番に到着することを保証しないため、通常、パケット損失が許容されるアプリケーションに適しています。実際、パケットが到着することは保証されないため、アプリケーションインスタンスにとってデータの整合性が重要であり、HTTP/3 を使用している場合は、メッセージの順序付けと完全な到着を保証するメカニズムを組み込む必要があります。

アドバンテージ

UDP 上で動作する新しい (異なる) トランスポートプロトコル QUIC の導入は、理論上および現在実験中のレイテンシーの削減を意味します。
UDP はプロトコルスタックでエラーチェックと修正を実行しないため、アプリケーションでこれらが必要ない、または実行されないユースケースに適しています。UDP は、パケットの再送信を待つことができないリアルタイムシステムなど、時間に敏感なアプリケーションでよく使用されるため、一部のパケットのドロップは許容されます。

欠点がある

トランスポート層への影響: HTTP/3 への移行には、アプリケーション層だけでなく、基礎となるトランスポート層の変更も伴います。したがって、HTTP/3 の導入は、以前のバージョンよりも困難です。
信頼性の問題: UDP アプリケーションは信頼性に欠ける傾向があり、ある程度のパケット損失、並べ替え、エラー、または重複が発生することを受け入れる必要があります。メッセージを受信したことをリアルタイムで確認するなど、必要なハンドシェイクを提供するかどうかは、エンドユーザーアプリケーション次第です。
HTTP/3 はまだ完全には標準化されていません。

Webソケット

WebSocket の詳細については、「深層学習 WebSocket の概念と実践」を参照してください。

WebSocket を使用すると、サーバーとクライアントは、以前のリクエストに関係なく、いつでもメッセージをプッシュできます。WebSocket を使用する大きな利点は、ほぼすべてのブラウザが WebSocket をサポートしていることです。

WebSocket は HTTP の問題のいくつかを解決します。

双方向プロトコル: クライアント/サーバーは相互にメッセージを送信できます (HTTP では、リクエストは常にクライアントによって開始され、応答はサーバーによって処理されます)。
全二重通信: クライアントとサーバーは同時に独立して相互に通信できます。
単一 TCP 接続: 最初に HTTP 接続をアップグレードした後、クライアントとサーバーは WebSocket 接続のライフサイクル全体を通じて同じ TCP 接続 (永続的な接続) を介して通信するため、サーバーのリソースと帯域幅が非常に節約されます。

アドバンテージ

WebSocket はイベント駆動型のプロトコルであるため、真のリアルタイム通信に使用できます。HTTP (常に更新を要求する必要がある) とは異なり、WebSocket では更新が利用可能になるとすぐに送信されます。
WebSocket は、HTTP要求/応答ベースのアプローチに伴う遅延の問題を排除しながら、単一の永続的な接続を開いたままにします。
通常、WebSocket は XMLHttpRequest を使用しないため、サーバーから詳細情報を取得する必要があるたびにヘッダーが送信されることはありません。これにより、サーバーに送信されるデータ負荷が軽減されます。

欠点がある

接続が切断された場合、WebSocket は自動的に回復しませんが、これはアプリケーション開発で実装する必要があるメカニズムであり、クライアント側のオープンソースライブラリが多数存在する理由の 1 つでもあります。
2011 より古いブラウザは WebSocket 接続をサポートできませんが、現在では無視できるほどです。

要約する

一般に、リアルタイムの継続的な通信のコンテキストでは、WebSocket がより良い選択肢となります。

HTTP ベースのテクノロジはサーバー上のリソースをより多く消費する傾向がありますが、WebSocket はサーバー上の占有面積が非常に小さいです。同時に、ロングポーリングなどの方法では、サーバーとデバイスの間で複数のホップが必要になり、これらのゲートウェイでは、接続を開いたままにしておくことができる時間について異なる制限が設定されることがよくあります。

プロジェクト内で長時間の接続、継続的な更新、およびリアルタイムのデータ対話が必要な場合は、WebSocket の構築を優先する必要があります。