WebSocket vs HTTP

HTTPの解説

まずHTTPについて理解していきます。HTTPはデジタル通信で最も広く使われるリクエスト・レスポンスプロトコルです。初版は1989年にティム・バーナーズ＝リーによって公開されました。当初のHTTPは基本的なもので、機能も限定的でしたが、すぐに改良され、ブラウザとサーバ間で大規模な通信を支えるまでに発展しました。HTTPは一方向のプロトコルで、一度に一方のみが通信を行います。 

クライアントはリクエストを送信または転送し、サーバが適切で独自のレスポンスを返せるようにします。 

HTTPの主な特徴は以下の通りです：

• 状態を持たない 
• SCTPやTCPなど、コネクション指向のプロトコル上で動作可能 
• メッセージはASCIIでエンコードされる
• HTTPリクエストの主要な要素は、HTTPバージョン、メソッド、ヘッダー、ホスト情報、そしてメッセージである

HTTPワーキンググループが世界中のHTTPの利用管理を担当し、すべてのバージョンと改訂を記録しています。 

次に、主要なHTTPバージョンについて解説します。 

‍

HTTP/1.1

初期のバージョンであるHTTP/1.1は、基本的なHTTPプロトコルよりも大幅に進化しました。最も広く支持され、多くのブラウザやサーバで動作します。パイプライン化や統一接続、新しいリクエスト・レスポンス用のヘッダー、即時の動的通信を可能にすることで、旧来のHTTPから大きく改善されました。  

主なHTTP/1.1のヘッダーは次のとおりです：

• Keep-Alive ヘッダー

これは最初のHTTPヘッダーで、複数のホスト間で連続したデータ伝送を確立する役割を持ちます。 

この方式により、アクティブな接続を利用して複数のリクエストを送ることができ、初回のTCP 3ウェイハンドシェイク後も接続が維持されるため、リクエストの遅延が軽減され、処理速度が向上します。 

このヘッダーの採用により、各レスポンスごとに新たな接続を開始する必要がなくなりました。これがHTTPの持続的な接続とWebSocketの動作方法の違いです。

• Upgrade ヘッダー

既存の通信方式を拡張する必要がある場合に有用です。WebSocketがその実例です。

‍

‍

HTTPポーリング

HTTPポーリングは、従来のリクエスト・レスポンス方式を高度化したもので、クライアントがポーリングを利用してサーバが情報を持っているか確認する仕組みです。RESTful APIでよく使用されます。

様々な方法の中で、ロングポーリングが選ばれるのは、最新のデータが受信次第送信されるためです。通信回線を長く開いたままにします。一方、ショートポーリングはAJAXタイマーを使い、一定間隔でクライアントからのリクエストを確認します。

この仕組みでは、サーバが即時の応答を返します。新しいリクエストがない場合、空またはヌルの応答が返されます。HTTPロングポーリングとWebSocketでは、後者のほうがオーバーヘッドが少ない点が重要です。

‍

HTTPストリーミング

HTTPストリーミングは、データをプッシュする方式に基づいています。クライアントとサーバ間で単一のHTTP接続を通してデータを送受信し、データの経路は長時間にわたって遮られません。

これにより、どのような状況でもデータ伝送が保証され、連続的なデータ配信が簡単に実現できます。そのため、WebSocketの代替手段として適していますが、中間者や不正な第三者によって接続が妨害されたり盗聴されたりするリスクもあります。 

このことから、HTTPストリーミングとWebSocketを比較すると、HTTPストリーミングは即時のアクセス性を維持できない一方、WebSocketは継続的なリクエストがあっても即時性を実現します。 

‍

HTTP/2

HTTP/2は実験の結果として誕生した、SPDYの進化版です。初心者向けに説明すると、SPDYはGoogleが2009年に試みたプロトコルであり、2015年にはHTTPワーキンググループによって見直され、HTTP/2.0として正式に認められました。サーバープッシュとも呼ばれます。

SNSやシングルページアプリで用いられ、サーバがスクリプト、スタイルシート、メディアなどの資産を事前にクライアントのキャッシュへ積極的にプッシュする仕組みです。

この方式では、TCP上でデータがバイナリコードとして送受信され、多数の並列リクエストとレスポンスが可能となります。ただし、HTTP/2はすべてのブラウザに対応しているわけではなく、プロキシやホストを使用している場合、プッシュ情報の選択で問題が生じることがあります。HTTP 2.0とWebSocketの違いとして、WebSocketは完全に標準化されている点が挙げられます。 

‍

HTTP/3

最新のHTTPバージョンの一つであるHTTP/3は、2018年に登場し、すぐに普及しました。デバイスの種類に関係なく、安全で信頼性の高い接続の確立を目指し、Web3の支援にもなる設計です。

HTTP/2.0のデータ伝送上の問題は、UDPを用いることでHTTP/3で解決されました。以前のHTTPはTCPを使用していましたが、HTTP/3ではUDPが採用され、あらゆる伝送問題が改善されました。 

UDPの使用により、遅延が大幅に軽減され、相対的なオーバーヘッドも減少します。そのため、時間に敏感なアプリに適しています。しかし、トランスポート層の問題やデータ整合性の課題、完全な標準化がされていないといった欠点も残ります。 

‍

HTTPの長所と短所

HTTPには長所と短所が存在し、それぞれ一長一短です。これらを理解することは、後々のトラブル回避に重要です。

HTTPの利点は次のとおりです：

• IPアドレスの認識が迅速に行える
• プラグインや拡張のダウンロードが可能になる
• データの傍受リスクが低い
• HTTPページはネット上に保存されるため、迅速なコンテンツアップロードが可能

しかし、HTTPには避けられない短所もあります。

• ハッカーがリクエストを傍受できるため、APIのセキュリティが弱くなります。データを守るにはAPIセキュリティプラットフォームの利用が望ましいです。
• オーバーヘッドと遅延が大きい
• リアルタイムデータの取得ができないため、IoTデバイスには適していない

‍

WebSocketの解説

API通信専用に設計されたこのプロトコルは双方向通信を可能にし、即時のデータ取得が実現できます。TCP上に構築されたWebSocketは、クライアントへリアルタイムにデータをプッシュし、HTTPポート443や80を使用する際にプロキシもサポートします.

WebSocketの長所と短所

このプロトコルの利点と欠点を確認してみましょう。WebSocketを利用するメリットは以下の通りです：

• 低オーバーヘッドで高速な接続
• リクエスト・レスポンスを即時にストリーミング可能
• 高効率かつ低遅延
• 端から端までデュプレックス接続をサポート
• ロングポーリングに最適

しかし、WebSocketには以下のような欠点もあります：

• ブラウザがHTML5に完全対応していない場合、動作しない
• エッジキャッシングに対応していない
• 大規模な動的相互作用が不要な場合、システムが複雑になりがち

WebSocketを使う場合と使わない場合

適切な利用シーンを理解すれば、WebSocketはクライアントとサーバー間のデジタル通信を最適化できます。API間の接続にWebSocketを採用するのは、次の用途に向いています：

• リアルタイムアプリ: 連続したデータ配信が求められる場合、WebSocketは接続が継続する限り途切れなくデータを送信でき、即時性が向上します。
• ‍ゲーミングアプリ: UIに影響を与えず連続的なデータ配信が求められる場合に適しています。
• ‍チャットアプリ: 迅速なデータ交換が必要な場合、例えばWhatsAppは迅速なメッセージ配信のためにWebSocketを利用しています。

上記の内容から、WebSocketが非常に有用だと考えられるかもしれません。確かに有用ですが、常に最適とは言えません。リアルタイムデータの取得が不要で、長時間の接続維持が求められない場合は、HTTPを採用するのが賢明です。 

HTTPとWebSocketの接続（表）

WebSocket vs HTTP 比較表

‍

結論

APIに最適なプロトコルの選択は、開発者にとって非常に重要な判断事項です。 

選ぶプロトコルによってAPIセキュリティも左右されるため、賢く選択することが求められます。HTTPとWebSocketは、ともに広く利用されるAPI通信プロトコルであり、各々が異なる利点を持っています。 

選定前に、開発の目的を明確にすることが大切です。例えば、アプリが静的なデータの取得を主とするならHTTPを、データの更新や即時アップロードが必要ならWebSocketを採用してください。開発目標に沿った選択を行ってください。