https://blog.yusukeikoma.com/tags/networking/Recent content in networking on Ikoma's BlogHugoen-usMon, 05 Oct 2026 13:20:23 +0900https://blog.yusukeikoma.com/posts/udp-connect-local-ip/Mon, 05 Oct 2026 13:20:23 +0900https://blog.yusukeikoma.com/posts/udp-connect-local-ip/A machine with Wi-Fi, a VPN and a container bridge has several addresses, and a hostname lookup can return the wrong one. Connecting a UDP socket to a destination makes the kernel pick the source address it would use, and getsockname() reads it back without a single packet being sent. Checked on Linux with three interfaces: five destinations, five answers, no IPv4 or ARP frames on the wire.https://blog.yusukeikoma.com/posts/http2-timeout-stream-vs-connection/Tue, 08 Sep 2026 12:56:00 +0900https://blog.yusukeikoma.com/posts/http2-timeout-stream-vs-connection/A request deadline fired on a connection that carries many requests at once. Do you close the connection, or only the request? In a small Node lab, closing the HTTP/2 session failed two innocent requests, while cancelling only the stream let them finish on the same TCP connection. The same lab shows the one case where cancelling is not enough: a lost packet stalls every stream on a TCP connection, and a connection-level PING is the right way to tell.https://blog.yusukeikoma.com/posts/websocket-bufferedamount-backpressure/Sun, 06 Sep 2026 20:54:24 +0900https://blog.yusukeikoma.com/posts/websocket-bufferedamount-backpressure/WebSocket send() never waits, and bufferedAmount only sees the part of the path that is in your own process. In a small lab, a sender that politely waited for bufferedAmount to drain still let a slow consumer queue nearly all 400 messages in its own memory, while a credit window of 8 kept the backlog at 8. This post goes through four common beliefs about send(), bufferedAmount, message size and backpressure, tests each one, and ends with a table for choosing between them.https://blog.yusukeikoma.com/posts/two-small-writes-nagle-delayed-ack/Tue, 01 Sep 2026 20:56:28 +0900https://blog.yusukeikoma.com/posts/two-small-writes-nagle-delayed-ack/Send a header and a body as two small write() calls, then wait for a reply, and every round trip can stall for about 40 ms on an idle machine with an idle network. Neither Nagle’s algorithm nor delayed ACK is a bug; together they deadlock until a timer fires. This post predicts the stall, reproduces it with a 50-line script, reads it off a packet trace, and compares the four ways out.https://blog.yusukeikoma.com/posts/tcp-half-open-connection-detection/Sun, 23 Aug 2026 15:09:06 +0900https://blog.yusukeikoma.com/posts/tcp-half-open-connection-detection/TCP never tells you that the peer is gone. A reader blocks forever, a writer keeps retransmitting for a quarter of an hour, and SO_KEEPALIVE does nothing while data is unacknowledged. This post builds a one-file Linux lab with no root, climbs a ladder of mechanisms (nothing, keepalive, TCP_USER_TIMEOUT, an application heartbeat), measures how long each takes to notice, and shows where NAT and the RFCs fit in.https://blog.yusukeikoma.com/posts/websocket-reauthentication-on-long-lived-connections/Fri, 21 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/posts/websocket-reauthentication-on-long-lived-connections/After the 101 response, no request carries credentials: the server remembers a verdict, not the evidence. This article follows one token through a browser handshake, shows what a page can and cannot see, and compares three ways to renew it (reconnect, in-band, out-of-band) with a runnable server, tests, and a headless-Chrome check.https://blog.yusukeikoma.com/posts/resident-agent-behind-nat/Mon, 03 Aug 2026 19:03:09 +0900https://blog.yusukeikoma.com/posts/resident-agent-behind-nat/Designing a resident agent behind NAT with outbound connections, separate liveness checks, and on-demand SSH sessions for interactive access.