https://blog.yusukeikoma.com/ja/tags/websocket/Recent content in websocket on Ikoma's BlogHugoja-jpTue, 22 Sep 2026 13:39:45 +0900https://blog.yusukeikoma.com/ja/posts/durable-objects-websocket-hibernation/Tue, 22 Sep 2026 13:39:45 +0900https://blog.yusukeikoma.com/ja/posts/durable-objects-websocket-hibernation/CloudflareのドキュメントはWebSocket Hibernationについて、接続は維持され、メモリ上の状態は破棄される、と書いています。この記事では小さなDurable Objectをローカルのworkerdで動かし、それが具体的に何を意味するかを観察します。ソケットはOPENのまま、次のメッセージでコンストラクターが再実行され、クラスのフィールドは初期化され、アタッチメントはserializeしたものだけが残り、保留中のタイマーや標準のWebSocket APIを使うとハイバネーションがひそかに無効になります。本番の挙動や課金は試していません。https://blog.yusukeikoma.com/ja/posts/mobile-os-background-sockets/Sat, 12 Sep 2026 14:18:24 +0900https://blog.yusukeikoma.com/ja/posts/mobile-os-background-sockets/AppleとAndroidの公式ドキュメントには、バックグラウンドのアプリは一時停止され、ネットワークが止められ、既存の接続が閉じられうると書かれています。つまり、フォアグラウンドに戻ったときの readyState === OPEN は、最後に処理したイベントの記憶にすぎません。この記事では、その記述から「確認する、作り直す、取りこぼしを取り戻す」という小さなルーチンを導き、Linux上の凍結プロセスという代役で動かします。実機では試していない点も、はっきり書きます。https://blog.yusukeikoma.com/ja/posts/websocket-origin-check-is-not-authentication/Thu, 10 Sep 2026 11:23:25 +0900https://blog.yusukeikoma.com/ja/posts/websocket-origin-check-is-not-authentication/WebSocket のハンドシェイクにある Origin ヘッダーは、ブラウザが付けるもので、それ以外のクライアントは好きな値を送れます。許可リストが守るのは、Cookie 認証のブラウザセッションが他のサイトから使われることで、接続してきた相手が誰かは証明しません。動くサーバー、実ブラウザでの攻撃、そこから導かれるハンドシェイクの規則を示します。https://blog.yusukeikoma.com/ja/posts/websocket-bufferedamount-backpressure/Sun, 06 Sep 2026 20:54:24 +0900https://blog.yusukeikoma.com/ja/posts/websocket-bufferedamount-backpressure/WebSocketのsend()は待ってくれず、bufferedAmountが見ているのは自分のプロセスの中の待ち行列だけです。小さな実験では、bufferedAmountが減るのを待ってから送る送信側でも、受信側のメモリには、400件のほぼ全部が溜まりました。受信側が処理済みを返す「クレジット窓」(8件)なら、溜まるのは8件で止まりました。send()、bufferedAmount、メッセージサイズ、バックプレッシャーについてよくある4つの思い込みを実際に試し、使い分けの表にまとめます。https://blog.yusukeikoma.com/ja/posts/websocket-reauthentication-on-long-lived-connections/Fri, 21 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/ja/posts/websocket-reauthentication-on-long-lived-connections/101 レスポンスのあと、どのリクエストにも認証情報は載りません。サーバーが覚えているのは証拠ではなく判定結果だけです。1つのトークンをブラウザのハンドシェイクから追いかけ、ページから何が見えて何が見えないかを確かめたうえで、再接続・帯域内(in-band)・帯域外(out-of-band)の3つの更新方法を、動くサーバーとテストとヘッドレス Chrome の確認つきで比べます。https://blog.yusukeikoma.com/ja/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/Thu, 20 Aug 2026 18:03:49 +0900https://blog.yusukeikoma.com/ja/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/メッセージ単位で課金されるリレー越しに、モバイルクライアントがタイマー駆動のポーリングから共有の変更通知へ移った経緯を扱います。難しいのはストリームそのものではなく、保険のポーリングをいつ止めてよいかを正直に決めることです。https://blog.yusukeikoma.com/ja/posts/batching-and-bounded-frames-on-a-metered-relay/Wed, 19 Aug 2026 12:47:53 +0900https://blog.yusukeikoma.com/ja/posts/batching-and-bounded-frames-on-a-metered-relay/WebSocket のメッセージごとに課金され、フレームにも上限がある環境では、独立したフラッシュ条件を持つバッチ送信、上限より低い単一フレームのしきい値、上限付きの分割、混在バージョンのロールアウトを生き延びる能力フラグが必要です。難所は、終了時の順序と、ワイヤ上から消えるゼロ値です。https://blog.yusukeikoma.com/ja/posts/liveness-without-pings-and-idle-sleep/Tue, 18 Aug 2026 22:41:09 +0900https://blog.yusukeikoma.com/ja/posts/liveness-without-pings-and-idle-sleep/一定間隔の keepalive は、接続が忙しいときでも双方向に1メッセージずつ使います。受信したフレームをすべて生存の証拠として扱い、静かな接続だけを確認し、既存のハートビートで待機中のホストに切断してよいかを伝えれば、その大半を減らせます。代償は、上限のある復帰の遅延です。https://blog.yusukeikoma.com/ja/posts/when-the-close-event-never-comes/Mon, 17 Aug 2026 17:27:04 +0900https://blog.yusukeikoma.com/ja/posts/when-the-close-event-never-comes/自分のソケットの close イベントを待ってから後始末するクライアントは、そのイベントが届かないと、黙って止まることがあります。接続を終えると決めた時点で状態を確定させ、後始末を冪等にし、イベントは自分が始めていない切断のために残します。