概要

• クライアントからサーバにTCP接続してhandshakeする
• handshakeのリクエスト/レスポンスのやりとりはHTTPそのもの
• クライアントはリクエストボディで8バイトのランダム文字列(challenge)を送る
• サーバは16バイトのresponse文字列を返す
• handshake後、TCP接続は張りっぱなしにする
• handshake後のTCP接続上、双方向にデータを送信可能
• テキストデータは 0x00 で始まり 0xff で終了するフレーム単位
• テキストデータの文字コードはUTF8
• バイナリデータも送れる(タイプと長さを最初に送る)
• URLは ws:// or wss://
• 紳士的な切断は 0xff 0x00 を送って、0xff 0x00 を受信してからTCPレベルで切断

考察

TCP上の通信プロトコルの定石はTLV(type,length,value)の三つ組によるデータ送信です。

最初に型情報、次にデータ長、最後にデータを送ります。TCP接続を張ったままデータをだらだらと送り続けるプロトコルではこのスタイルが一般的です。データ長を最初に送ってその長さ分のデータを送るスタイルは受信側に優しいプロトコルです。最初にどのぐらいのデータを読めばいいかわかるのでプログラミング(特にメモリ確保)が簡単になります。読み取りの終端処理もデータの中身をパースすることなく行えます。ただし、送信側は、データの全長がわかるまで送信を開始できない欠点があります。ちなみに、HTTP1.1では、全長がわかる前にデータ送信したい要求のためにChunked Transfer Codingを使えます。

WebSocketの一般的なデータ送信は0x00で始まり0xffで終端するUTF8文字列です。一見、TLVっぽくありません。ただ、プロトコル上はTLVです。0x00はUTF8(0xff終端)のデータ型(frame type)を示すバイトという扱いです。先頭バイトのhigh-orderビットが立っている場合、後続に長さ情報が続くframe typeを意味します。high-orderビットが立っているバイトが続く限り、それらはデータ長を示します。データ長を示すバイト(high-orderビットを除く7ビットずつ)の終端はhigh-orderビットの立たないバイトです。データ長の後にはデータが続きます。受信側はデータ長だけバイト列を読み込みます。プロトコル上、ただのバイト列なのでバイナリデータも送れます。

通常用途では0x00(frame type)でUTF8文字列を送ることが多いと思います。文字列のフォーマットはJSONが良いでしょう。JSONであれば型情報も含めて構造データを送受信できるからです。

handshakeの具体例

GET /demo HTTP/1.1
Host: example.com
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key1: 18x 6]8vM;54 *(5:  {   U1]8  z [  8
Sec-WebSocket-Key2: 1_ tx7X d  <  nw  334J702) 7]o}` 0
Sec-WebSocket-Protocol: sample                    ...アプリが使うことを想定したヘッダ
Origin: http://example.com

Tm[K T2u


HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Location: ws://example.com/demo
Sec-WebSocket-Protocol: sample

fQJ,fN/4F4!~K~MH

不思議なchallenge-response処理

handshakeリクエストヘッダの例

Sec-WebSocket-Key1: 18x 6]8vM;54 *(5:  {   U1]8  z [  8
Sec-WebSocket-Key2: 1_ tx7X d  <  nw  334J702) 7]o}` 0

ヘッダ値から数字部分のみ取り出し

1868545188
173347027

ヘッダ値の空白文字を数える

12
10

除算

155712099
173347027

16バイトデータ生成

ふたつの数値を32bit big-endianにエンコーディング

09 47 FA 63
0a 55 10 d3

リクエストボディの8バイトと連結して16バイト生成

Tm[K T2u
=> 54 6d 5b 4b 20 54 32 75

# 16バイトを書き込んだファイルのmd5値
$ md5sum /tmp/dat
66514a2c664e2f344634217e4b7e4d48  /tmp/dat

16バイトデータのMD5をresponseのボディで送る

fQJ,fN/4F4!~K~MH

# 確認
$ echo 'fQJ,fN/4F4!~K~MH'|od -t x1
0000000 66 51 4a 2c 66 4e 2f 34 46 34 21 7e 4b 7e 4d 48

これは一体何なんでしょうか?

普通のchallenge-responseは共有する秘密情報(普通はユーザのパスワード)を使って認証をします。WebSocketのchallenge-responseにそんなものはありません。処理はムダに複雑です(空白の数を数えるとか)。アルゴリズム的に計算量が爆発するという意味での複雑さには意味がありますが、単に計算が面倒という意味の複雑さはセキュリティ的な強度には無関係です。手作業の計算がいくら面倒だろうと、計算するコードを書いてしまえばおしまいだからです。

結局、これは何を守っているのでしょう。