WebSocketのhandshake、frame、接続ライフサイクル

WebSocketは1つの接続上でクライアントとサーバーが双方向にメッセージを交換するプロトコルです。RFC 6455はHTTP/1.1 Upgrade handshake後にTCP上でframeを送る方式を定めます。ブラウザーはスクリプトのOriginを送り、サーバーは許可対象を確認できますが、Originだけでは利用者認証や認可になりません。ブラウザーから送るframeはmaskされます。data frameはtext・binary messageを運び、control frameはping、pong、closeに使われます。frame境界は通信形式であり、アプリケーションの永続ログや再生位置ではありません。

専門家の視点：長時間接続も切断される

Cloudflareのネットワーク文書は同社のproxy・load balancer製品上で、idle WebSocketが閉じられることや、再接続先が別originとなる場合にsession affinityが必要なことを説明しています。これは製品固有の運用情報で、すべてのWebSocketに共通するtimeoutではありません。RFC 6455は再接続、メッセージ保存、復旧を定義しません。deploy、携帯回線の切り替え、proxyのidle policy、server再起動でも接続は終了し得ます。heartbeatは一部のidle closeを検出・回避する助けになりますが、接続維持や配送を保証しません。両端と中継機器の条件に合わせて設定します。

アプリケーション上の意味は別途設計する

仕様が定めるのはframe、ping/pong、close handshakeです。業務イベントのschema、再接続後の順序、retry、重複排除、認可はアプリケーション側の責任です。TCPは生きている接続内のbyte順を保ちますが、再接続後の論理順序や重複防止にはsequence IDとacknowledgementが必要です。圧縮extensionを使う場合はCPU・メモリ負荷と圧縮に関係するリスクを評価します。messageサイズと接続ごとのbufferを制限し、受信側より送信側が速い場合のbackpressureを決めてください。

セキュリティ、拡張、配備時の確認

wss:はTLSで通信経路を保護しますが、message検証や操作ごとの認可を代替しません。サーバーはブラウザーの許可Originを検証し、cookie認証ではcross-site WebSocket hijackingを考慮します。必要に応じてidentity、session期限、subscription権限を再確認します。長時間接続は確立時に振り分けられ、messageごとに負荷分散されません。接続数、file descriptor、memory、graceful drain、再接続集中を容量計画に含めます。Cloudflareのidle・affinity動作は同社の経路固有です。CDN、proxy、originを通した実環境でidle、ping/pong、大きなmessage、backpressure、再接続を試験してください。

参考資料