<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>tcp on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/tags/tcp/</link><description>Recent content in tcp on Ikoma's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 01 Sep 2026 20:56:28 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/tags/tcp/index.xml" rel="self" type="application/rss+xml"/><item><title>Two write() Calls Can Stall a TCP Connection for 40 ms</title><link>https://blog.yusukeikoma.com/posts/two-small-writes-nagle-delayed-ack/</link><pubDate>Tue, 01 Sep 2026 20:56:28 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/two-small-writes-nagle-delayed-ack/</guid><description>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&amp;rsquo;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.</description></item><item><title>A Dead TCP Peer Goes Unnoticed for 15 Minutes on Writes, Forever on Reads</title><link>https://blog.yusukeikoma.com/posts/tcp-half-open-connection-detection/</link><pubDate>Sun, 23 Aug 2026 15:09:06 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/tcp-half-open-connection-detection/</guid><description>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.</description></item></channel></rss>