WebSocketプロトコル

WebSocketはどのように機能する？

一般的な定義では、WebSocketは主にクライアントとサーバの通信に使われる双方向プロトコルです。クライアントとサーバの間で、行き来する通信が可能となります。 

WebSocketで確立された接続は、参加者のいずれかが切断するまで維持されます。一方が接続を終了すると、もう一方は自動的に通信ができなくなります。

接続を開始するには、WebSocketはHTTPのサポートを必要とします。その役割は、シームレスなデータ配信や各種非同期トラフィックにおいて、現代のウェブアプリ開発の基盤となっています。 

WebSocketは何故必要で、どんな場合に避けるべきか？

WebSocketはクライアントとサーバの通信に欠かせないツールです。最大限の効果を得るためには、その特性を理解し、適さないケースは避ける必要があります。詳しくは次のセクションで説明します。

WebSocketを使用すべき場合:

1. ‍リアルタイムウェブアプリを開発している場合
   

WebSocketの最も一般的な利用は、クライアント側でデータを継続的に表示するリアルタイムアプリの開発です。バックエンドサーバから常にデータを送るため、既に確立された接続で途切れることなくデータを送受信できます。この仕組みは、データ伝送を迅速にし、アプリのパフォーマンスを向上させます。 

実例として、ビットコイントレーディングサイトでは、バックエンドサーバからクライアントへのデータ処理にWebSocketが活用されています。

2. ‍チャットアプリを作成している場合
   

チャットアプリの開発では、一度限りのデータ交換やメッセージの配信などにWebSocketが利用されます。同じ接続を介してメッセージの送受信を行うため、通信が簡単かつ迅速になります。

3. ‍ゲームアプリを開発している場合
   

ゲームアプリの開発では、UIの更新を行わずにサーバが連続でデータを受信することが求められます。WebSocketは、ゲームのUIに影響を与えることなく、この要求を満たします。

WebSocketの利用シーンが明確になったところで、使用を控えるべきケースも理解し、運用上のトラブルを避けるようご注意ください。

古いデータの取得や一度限りの処理が必要な場合は、WebSocketではなくHTTPプロトコルを選ぶのが適切です。

WebSocket vs HTTP

HTTPとWebSocketはどちらもアプリの通信に利用されるため、どちらを使うべきか迷うことがあります。下記の説明を参考に、それぞれの特徴を理解してください。

前述の通り、WebSocketはフレーム化された双方向プロトコルです。一方、HTTPはTCP上で動作する一方向プロトコルです。

WebSocketは連続的なデータ送信をサポートするため、主にリアルタイムアプリの開発に用いられます。HTTPはステートレスで、RESTfulやSOAPアプリの開発に使用されます。SOAPもHTTPを使うことがありますが、RESTが広く採用されています。

WebSocketは双方で通信を行うため、高速です。HTTPは接続が一方向であるため、WebSocketよりもやや遅くなります。

WebSocketは統一されたTCP接続を使い、いずれかが接続を終了するまで維持されます。一方、HTTPは各リクエストごとに別個の接続を確立し、リクエスト完了後に自動で切断されます。 

WebSocket接続はどのように確立されるか？ 

プロセスは、wsまたはwssという新しいスキームを用いるWebSocketハンドシェイクから始まります。簡単に言えば、これらはそれぞれHTTPおよび安全なHTTP（HTTPS）に相当します。

このスキームを使い、サーバとクライアントは標準のWebSocket接続プロトコルに従います。WebSocket接続の確立は、Connection: Upgrade、Upgrade: WebSocket、Sec-WebSocket-Keyなどのヘッダーを含むHTTPリクエストのアップグレードから始まります。 

接続確立の流れは以下の通りです。

1. リクエスト
   

Connection: Upgrade ヘッダーはWebSocketハンドシェイクを示し、Sec-WebSocket-Key はBase64でエンコードされたランダムな値を示します。この値は各ハンドシェイクごとに生成されます。他のキー関連のヘッダーもリクエストに含まれます。

これらのヘッダーを組み合わせると、以下のようなHTTP GETリクエストが形成されます。

GET ws://websocketexample.com:8181/ HTTP/1.1
Host: localhost:8181
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: b6gjhT32u488lpuRwKaOWs==

参考までに、Sec-WebSocket-Versionはクライアントが使用するWebSocketプロトコルのバージョンを示しています。 

2. レスポンス
   

レスポンスヘッダーのSec-WebSocket-Acceptには、リクエストヘッダーのSec-WebSocket-Keyで送信された値の要素が含まれています。これは特定のプロトコル仕様に基づいており、不正な情報を防ぐために広く利用されています。つまり、APIのセキュリティを強化し、設定ミスによるトラブルを防止します。 

リクエストが成功すると、以下のようなレスポンスが返されます。

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: rG8wsswmHTJ85lJgAE3M5RTmcCE=

WebSocketプロトコル

WebSocketプロトコルは、各データごとに異なる断片を含むフレーム型プロトコルです。正しく機能するために、フレームタイプ、データ部分、ペイロードの長さなどが用いられます。詳細を理解するには、その構成要素を把握することが重要です。主な要素は以下の通りです。

• Fin Bit はWebSocketの基本ビットで、接続開始時に自動的に生成されます。 
• ‍RSV1, RSV2, RSV3 Bits は、将来のために予約されたビットです。 
• ‍Opcode は各フレームに含まれ、ペイロードデータの解釈方法を示します。一般的なopcode値には 0x00、0x0、0x02、0x0a、0x08 などがあります。 
• ‍Mask bit は、ビットが1に設定されたときに有効となります。 
  

WebSocketでは、全てのペイロードデータに対してクライアントが選んだランダムキーの使用が求められます。マスキングキーは、ペイロードデータと組み合わせてXOR演算を行うことで、データの送受信を補助します。これにより、キャッシュの誤解釈や毒化を防ぎ、APIのセキュリティ向上に寄与します。 

それでは、主要な構成要素を詳しく見ていきましょう:

Payload len

これはWebSocketにおけるペイロードデータ全体の長さを表します。エンコードされたデータ長が126バイト未満の場合、Payload lenが表示され、126バイトを超える場合は追加のフィールドで長さが示されます。 

Masking-key

クライアントがサーバへ送信する各フレームは、32ビットの値でマスクされます。マスクビットが1の場合にMasking-keyが付与され、0の場合はゼロとなります。 

Payload data

任意のアプリデータや拡張データがPayload dataとして扱われます。これらのデータは、クライアントとサーバ間の交渉や初期のWebSocketハンドシェイクに利用されます。 

‍

結論

WebSocketは、サーバに問い合わせることなく、クライアントとサーバ間で双方向の対話型通信を実現し、速度向上と高度な機能を提供します。しかし、いかなるアプリでも同様に、WebSocketの利用には慎重なプログラミングと実行時保護が求められ、特有の脅威に備える必要があります。このAPIの多層防御戦略は、従来の方法に比べ、利用者と組織双方の保護力を高めます。

さらにセキュリティも重要です。Wallarmの信頼できるソリューションであるAPI Security Platformもぜひご検討ください。