https://blog.yusukeikoma.com/ja/tags/networking/Recent content in networking on Ikoma's BlogHugoja-jpMon, 05 Oct 2026 13:20:23 +0900https://blog.yusukeikoma.com/ja/posts/udp-connect-local-ip/Mon, 05 Oct 2026 13:20:23 +0900https://blog.yusukeikoma.com/ja/posts/udp-connect-local-ip/Wi-Fi、VPN、コンテナのブリッジがあるマシンにはアドレスが複数あり、ホスト名の解決では間違ったものが返ることがあります。UDPソケットを宛先にconnectすると、カーネルがその宛先に使う送信元アドレスを決め、getsockname()でパケットを1つも送らずに読み出せます。Linuxで3つのインターフェースを使って確かめ、5つの宛先に対して5つの答えが得られ、IPv4とARPのフレームは流れませんでした。https://blog.yusukeikoma.com/ja/posts/http2-timeout-stream-vs-connection/Tue, 08 Sep 2026 12:56:00 +0900https://blog.yusukeikoma.com/ja/posts/http2-timeout-stream-vs-connection/たくさんのリクエストを同時に流している1本の接続で、1つのリクエストの期限が来たとき、接続ごと閉じるべきか、そのリクエストだけを閉じるべきか。小さなNodeの実験では、HTTP/2のセッションを閉じると無関係な2本が失敗し、ストリームだけをキャンセルすると同じTCP接続のまま2本とも完了しました。ただし、TCPの1パケットの遅れは接続上の全ストリームを止めます。その場合に接続の生死を確かめる方法として、PINGを使った確認も試します。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/two-small-writes-nagle-delayed-ack/Tue, 01 Sep 2026 20:56:28 +0900https://blog.yusukeikoma.com/ja/posts/two-small-writes-nagle-delayed-ack/ヘッダーと本文を小さな write() 2回に分けて送り、返事を待つと、CPUもネットワークも空いているのに、1往復ごとに約40ms止まることがあります。Nagleアルゴリズムも遅延ACKも、単体では正しい仕様です。2つが組み合わさると、タイマーが切れるまで互いに待ち合ってしまいます。この記事では、停止を予想し、50行のスクリプトで再現し、パケットトレースで確かめ、4つの対処を比べます。https://blog.yusukeikoma.com/ja/posts/tcp-half-open-connection-detection/Sun, 23 Aug 2026 15:09:06 +0900https://blog.yusukeikoma.com/ja/posts/tcp-half-open-connection-detection/TCP は、相手がいなくなったことを教えてくれません。読み取り側は永遠にブロックし、書き込み側は十数分も再送を続け、SO_KEEPALIVE は未確認のデータがあるあいだ何もしません。この記事では、root 不要の1ファイルの Linux 実験環境を作り、何もしない、keepalive、TCP_USER_TIMEOUT、アプリケーションのハートビートという順に仕組みを積み上げて、気づくまでの時間を測ります。NAT と RFC がどこに関わるかも整理します。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/resident-agent-behind-nat/Mon, 03 Aug 2026 19:03:09 +0900https://blog.yusukeikoma.com/ja/posts/resident-agent-behind-nat/NAT 配下の常駐エージェントを、外向き接続・独立した生存確認・必要時の SSH セッションで設計する方法を説明します。