PD試験（仮称）システム区分 サンプル問4（WebSocketのハンドシェイク）の解説

この問題で問われていること：WebSocketの仕様の知識

IPAは出題趣旨で、この問題を、WebSocket通信を利用したシステム間連携における「プロトコルの仕様やハンドシェイクの仕組みなど」を理解し、リアルタイム通信に活用する能力を評価するものとしています。

サンプル問題の6問のうち、知識だけで答えが決まるのはこの問題です。本文から推理して埋める空欄はほとんどなく、WebSocketの仕様（RFC 6455）を知っているかどうかで決まります。そのかわり、知っていれば1〜2分で解けます。

仕様と照らす：4つの空欄の根拠

4つとも正しいのはアです。

空欄ごとの考え方：切り替えのHTTPと、認証にならない検証

a・b：「切り替え」のHTTP

WebSocketは、最初にHTTPのリクエストを送り、それをWebSocketに切り替える（アップグレードする）ことで始まります。

• Connectionヘッダには「この接続を切り替えたい」という指示としてUpgradeを書きます。
• Upgradeヘッダに、切り替え先のプロトコル名websocketを書きます。

図1のリクエストも、まさにこの組合せ（Upgrade: websocketとConnection: Upgrade）です。応答も同じ組合せを返すので、aは（一）です。（二）の「Connection: websocket」は、2つのヘッダの役割を取り違えています。

bのステータスコードは、プロトコルの切り替えを表す101 Switching Protocolsです。通常の成功を表す200を返すと、HTTPのまま応答が終わったことになり、WebSocketは始まりません。

c：なぜSHA-1なのか

Sec-WebSocket-Acceptの値は、クライアントが送ったSec-WebSocket-Key（16バイトの乱数をBase64にした文字列）に、仕様で決められた固定のGUID「258EAFA5-E914-47DA-95CA-C5AB0DC85B11」を連結し、SHA-1でハッシュしてBase64にしたものです。

SHA-1は、電子署名などの暗号用途では使わないことが推奨されるようになりました。そのため、SHA-2を選びたくなるかもしれません。しかし、ここでのハッシュは秘密を守るためのものではなく、「仕様どおりに計算できた」ことを示すためのものです。RFC 6455はSHA-1のまま使われています。

d：「なりすましでない」ではない理由

一番のひっかけはdです。計算に使うのは、クライアント自身が送った値と、仕様に公開されている固定のGUIDだけです。秘密の値を使っていないので、誰でも同じ値を計算できます。したがって、Sec-WebSocket-Acceptを検証しても、相手が本物かどうか（なりすましでないか）は分かりません。

確認できるのは、相手がWebSocketのハンドシェイクを理解して、受け入れたことです。相手の正当性は、図1の冒頭にあるTLSのサーバ証明書の検証で確かめます。

時間をかけないコツ：「101」だけで候補が半分になる

解く時間の目安は3分ほどです（当サイトの推測）。知識の問題は、迷う時間を減らすことが一番の時間短縮です。

確実に分かる空欄から解答群を絞ります。たとえば「101」だけを知っていれば、10個の候補が5個（ア・イ・ウ・カ・キ）に減ります。さらに「Connection: Upgrade」を知っていれば3個（ア・イ・ウ）になり、残りはcとdの判断だけです。

システム間連携として読み直す：切断と認証

本文のA社は、取引先システムと「刻々と変化する原価情報や，注文情報」をやり取りしています。WebSocketを選んだ理由はリアルタイム性ですが、システム間連携としては、ほかにも決めておくことがあります。

WebSocketは接続を張り続ける方式なので、ネットワークの瞬断や相手の再起動で接続が切れます。再接続の手順と、切れている間に失われたメッセージをどう補うかを決めておかないと、注文情報が欠けるおそれがあります。

相手の認証も別に用意します。dで見たとおり、ハンドシェイクは相手の認証になりません。取引先との連携では、TLSのサーバ証明書の検証に加えて、接続時のトークンなどで、どの取引先からの接続かを確かめる仕組みが要ります。