San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
閉じる
プライバシー設定
ウェブサイト運営に必要なCookieや類似技術を使用しています。追加のCookieは貴社の同意がある場合のみ利用されます。同意は「Agree」をクリックすることでいただけます。どのデータが収集され、どのようにパートナーと共有されているかの詳細は、Cookieポリシープライバシーポリシーをご確認ください。
Cookieは、貴社デバイスの特性や、IPアドレス、閲覧履歴、位置情報、固有識別子などの特定の個人情報を取得、解析、保存するために使用されます。これらのデータは様々な目的で利用されます。分析Cookieによりパフォーマンスを評価し、オンライン体験やキャンペーンの効果向上に役立てます。パーソナライズCookieは、利用状況に応じた情報やサポートを通じ、貴社専用の体験を提供します。広告Cookieは、第三者が貴社のデータをもとにオーディエンスリストを作成し、ソーシャルメディアやネット上でのターゲット広告に使用します。貴社は各ページ下部のリンクから、いつでも同意の許可、拒否、または撤回が可能です。
ご送信ありがとうございます。内容を受け付けました。
申し訳ありません。フォーム送信時にエラーが発生しました。
/
/
API Security

WebSocketプロトコル

WebSocketを使うことで、従来のAPIプロトコルよりも高速で負担の少ないリアルタイムアプリが作成できます。ハイエンドな通信プロトコルとも呼ばれるWebSocketは、クライアントとサーバ間の通信確立に必要です。本記事では、WebSocketの概要、動作原理、そして対策すべきセキュリティ課題について解説します。

WebSocketプロトコル

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

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

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

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

websocket work scheme

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

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

WebSocketを使用すべき場合:

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

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

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

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

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

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

ゲームアプリの開発では、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 vs 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プロトコルのバージョンを示しています。 

  1. レスポンス

レスポンスヘッダーの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もぜひご検討ください。

FAQ

Open
WebSocketではどのような種類のデータを送信できますか?
Open
WebSockets利用時に注意すべきセキュリティのポイントは何ですか?
Open
WebSocketの代替手段にはどんなものがあるか?
Open
WebSocketは他の即時通信プロトコルとどう比べる?
Open
WebSocketsはモバイルアプリで使える?

参考資料

WebSocket - Wikipedia

Using WebSockets - Google

最新情報を購読

更新日:
February 25, 2025
学習目標
最新情報を購読
購読
関連トピック