WebSocket についてはぜんぜん調べたことなくて、HTTP の上に構築された双方向通信プロトコルやろ、とか思ってました。 Golang で WebSocket サーバを作ったのがきっかけで、きちんと WebSocket の仕様を調べてみたところ、その理解が根底から覆されました。

RFC 6455 - The WebSocket Protocol とキャプチャ結果をもとにして、ちょっと WebSocket を追ってみます。

WebSocket 概観

WebSocket は、TCP の上でブラウザベースの双方向通信を実現しようというプロトコルです。

テキストとバイナリ転送の双方に対応しており、これらの情報は「フレーム」という単位でやりとりされます。

このフレームにはデータフレームと制御フレームがあります。データフレームがテキストやバイナリデータを転送するフレームで、制御フレームが Close やら Ping/Pong といったことをエンドポイント(クライアント/サーバ) に指示するためのフレームです。

フレームってことはその長さには限界もありますし、データがクソ長いときのために、フレーム自体はフラグメンテーションをサポートしています。つまり、クソ長いデータは複数フレームに分割されることになります。

プロトコルデータは以下のようになります。(RFC 6455 - The WebSocket Protocol より引用)

    0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+

で、ここまでの話に HTTP は登場していません。

ではどこに HTTP が関わっているかというと、通信開始時のブラウザ・サーバ間のハンドシェークです。最初から TCP の上で HTTP とは完全に別のプロトコルを設計しようと思えばできたでしょうが、HTTP の世界がここまで広がってきている中で、HTTP に対応した NW 機器、サーバには相応の投資がされています。これらを活用した上で、なんとかして双方向通信を実現しようとしようというのが WebSocket になります。

ハンドシェーク

gorilla/websocket を使って WebSocket サーバを構築し、実際の通信をキャプチャしてみました。

大まかな流れで言えば、ハンドシェークはブラウザ(クライアント)から開始され、

いくつかのヘッダを伴う HTTP/1.1 GET でクライアントからサーバにハンドシェークを開始
サーバから、やはりいくつかのヘッダを伴うステータス 101 Switching Protocols を返却

を経て、WebSocket コネクションが確立し「OPEN」状態になります。この「OPEN」な状態になれば、互いにデータを送受信できるようになります。

開始

まず、ハンドシェークは、ブラウザ(クライアント)から開始されます。以下が実際のハンドシェークの開始です。

f:id:kiririmode:20180502135429p:plain

ハンドシェークは、HTTP/1.1 の GET リクエストに、複数の WebSocket 用ヘッダを組み合わせたものになります。ブラウザからの WebSocket 通信を前提にした場合、必須ヘッダは以下になります。value まで書いたものは固定値です。

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Host
Sec-WebSocket-Key
Origin

Host や Origin は HTTP/1.1 だとお馴染ですが、Sec-WebSocket-Key はコネクションごとに払出すランダムな 16 byte 値(を base64 でエンコードしたもの)です。この Sec-WebSocket-Key をサーバが読み取り、サーバはクライアントに「コネクション確立を受け付ける」ことを通知するため、ちょっとした加工を経てクライアントに Sec-WebSocket-Accept ヘッダとして送り返します。

Origin ヘッダについては、サーバ側での妥当性検証に使われることがありまして、例えば gorilla/websocket ではデフォルトでは CheckSameOrigin が適用されます。

// checkSameOrigin returns true if the origin is not set or is equal to the request host.
func checkSameOrigin(r *http.Request) bool {
    origin := r.Header["Origin"]
    if len(origin) == 0 {
        return true
    }
    u, err := url.Parse(origin[0])
    if err != nil {
        return false
    }
    return equalASCIIFold(u.Host, r.Host)
}