WebSocketWebSocket

WebSocketとは、Webページを開くブラウザと、その接続先でデータをやり取りするサーバーとの間で、1本の接続を保ち、双方が好きなときに情報を送れる通信の仕組みである。

たとえば、2人がFigmaで同じデザインファイルを編集する場面とする。FigmaのWebページはサーバーとWebSocketでつながり、自分が加えた変更を送るとともに、相手の変更を受け取る。接続後は、両方向に変更を送り合い、ファイルの内容をそろえていく。

従来は、ブラウザがサーバーに更新の有無を繰り返し問い合わせ、自分の変更は別の通信で送っていた。WebSocketでは、変更を送るときも受け取るときも、同じ接続を使える。

最初に取り決めて変更を送り合う

FigmaのようにWebSocketを使って変更を送り合う場合、通信は次のように進む。

• 通信方式の切り替えを取り決める：ブラウザは、Webで情報をやり取りするためのHTTPという通信方式を使い、WebSocketへの切り替えを求める。サーバーが応じると、切り替えの取り決めが済む。この取り決めを「ハンドシェイク」という。
• 1本の接続を保つ：取り決めのあとも接続を開いたままにし、情報を送るときと受け取るときの両方に使う。
• 双方から変更を送る：ブラウザもサーバーも、相手からの問い合わせを待たずにデータを送る。これにより、自分の変更を送り、相手の変更を受け取れる。

送るデータには、ひとまとまりのメッセージがどこで終わるかを示す情報が付く。WebSocketは、この区切りを示す情報を最小限にする方針で設計されている。

接続を保つ様子は、一度つないだあと、お互いが好きなときに話せる電話にたとえられる。ただし電話とは異なり、最初にHTTPで通信方式の切り替えを取り決める。

語源・提唱者

2008年6月、Michaelマイケル Carterカーター が主導した議論から、WebSocketと呼ばれる最初の版が生まれた。WebSocketという名前を付けたのは、Ianイアン Hicksonヒクソン とカーター氏である。

この技術が目指したのは、ブラウザとサーバーが情報を送り合うために、複数のHTTP接続を開かずに済むようにすることである。通信の取り決めは、2011年に仕様書「RFC 6455」として標準化された。

送るときも受け取るときも同じ接続

従来の方式では、1つのブラウザとのやり取りに複数の接続が必要だった。ブラウザ側のプログラムは、送信用と受信用の接続の対応を管理しなければならなかった。また、ブラウザから送るメッセージには、毎回HTTPで通信するための付随情報が付いていた。

WebSocketでは、Figmaの例のように、同じ接続で変更を送り合える。送信用と受信用に複数のHTTP接続を開く方式に頼らずに済む。

ただし、ブラウザのWebSocketには、受け取ったメッセージを処理しきれないときに、相手が送る量を抑える「バックプレッシャー」という仕組みがない。処理できる速さを超えてメッセージが届くと、処理待ちのデータで端末のメモリを使い果たしたり、端末が処理にかかりきりになって応答しなくなったりする。

変更が重なったときの扱いを決める

共同編集機能を設計するときは、変更を届ける方法とは別に、同じ値への変更が重なったときに、どちらを残すかを決める。Figmaでは、2人が同じ物の同じ性質を変えると変更が衝突し、サーバーが受け取った順番で最後の値が残る。これはFigmaが採用しているルールであり、WebSocket自体が編集結果を決めるわけではない。

自分の仕事で共同編集機能の仕様を作るなら、この事例を基に、次の点を確認する。

• 同じ値への変更：複数人が同じ物の同じ値を変えたとき、どの値を残すかを決める。
• 受け取りと処理の速さ：変更が届く速さに、端末の処理が追いつくかを確認する。
• 別の通信手段：受け取り側の処理に合わせて送り手を抑える必要がある場合は、別の通信手段であるWebTransportの利用を検討する。

これらは、Figmaの事例とWebSocketの制約を、仕様づくりに当てはめた手順である。

関連用語

• ポーリング
• サーバー送信イベント
• WebTransport