https://nalar.dev/tags/tcp/ Recent content in TCP on Nalar Hugo en-us Wed, 16 Sep 2026 00:00:00 +0700 https://nalar.dev/tcp-keepalive-probes-test-idle-connections/ Wed, 16 Sep 2026 00:00:00 +0700 https://nalar.dev/tcp-keepalive-probes-test-idle-connections/ <p>A TCP connection can remain established while carrying no application data. That is valid behavior: an open connection does not need a continuous stream of packets to remain a TCP connection.</p> <p>Silence creates a practical problem when one endpoint disappears without completing the normal close sequence. A machine can lose power, a network path can fail, or state in an intermediate device can vanish. If the surviving endpoint has no data to send, ordinary retransmission logic has nothing to act on.</p> https://nalar.dev/half-open-tcp-connections-hide-peer-failure-until-traffic-resumes/ Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/half-open-tcp-connections-hide-peer-failure-until-traffic-resumes/ <p>A TCP socket can remain in the established state on one host after the peer has become unreachable or has lost all connection state. No contradiction exists in that state: TCP endpoints maintain local protocol state, and a silent network failure does not automatically deliver evidence that the peer is gone.</p> <p>This creates a boundary between connection state and peer liveness. An established socket records what the local TCP implementation currently knows about a byte-stream association. It is not a continuously refreshed assertion that the remote process, host, route, and intervening network are all operational.</p> https://nalar.dev/happy-eyeballs-races-ipv6-and-ipv4-connections/ Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/happy-eyeballs-races-ipv6-and-ipv4-connections/ <p>A device on a dual-stack network can often reach the same service over both IPv6 and IPv4. DNS may return <code>AAAA</code> records for IPv6 addresses and <code>A</code> records for IPv4 addresses, leaving the client with several possible routes to the destination.</p> <p>Preferring IPv6 and waiting for a complete failure before trying IPv4 sounds orderly, but it can create a visible pause when the IPv6 path is broken or unusually slow. The reverse ordering can hide IPv6 even when it offers a healthy path. Happy Eyeballs avoids both extremes by giving preferred connection attempts a short head start while allowing another address family to compete soon afterward.</p> https://nalar.dev/path-mtu-discovery-finds-the-largest-packet-a-route-can-carry/ Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/path-mtu-discovery-finds-the-largest-packet-a-route-can-carry/ <p>A host can know the maximum transmission unit of its own network interface without knowing the smallest limit farther along a route. Ethernet might accept one packet size while a tunnel, access link, or other intermediate network accepts less.</p> <p>Path MTU Discovery, commonly shortened to PMTUD, lets an endpoint adapt to that route-level limit. The mechanism matters because an IP packet that fits the sender&rsquo;s local link can still be too large for a later hop.</p> https://nalar.dev/tcp-delayed-ack-reduces-acknowledgment-traffic/ Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/tcp-delayed-ack-reduces-acknowledgment-traffic/ <h1 id="tcp-delayed-ack-reduces-acknowledgment-traffic">TCP Delayed ACK Reduces Acknowledgment Traffic</h1> <p>TCP acknowledgments provide essential feedback, but sending a separate ACK for every incoming data segment is not always necessary. A receiver can briefly defer an acknowledgment so that one ACK covers more than one segment. This behavior is known as delayed acknowledgment, or delayed ACK.</p> <p>The mechanism reduces packet processing and reverse-path traffic during steady data transfer. It also introduces a timing tradeoff: if another segment does not arrive soon enough, the receiver eventually has to send the pending ACK on its own.</p> https://nalar.dev/tcp-half-close-separates-the-two-stream-directions/ Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/tcp-half-close-separates-the-two-stream-directions/ <p>A TCP peer can reach end-of-stream on incoming data while its outgoing stream remains usable. The event is directional: a FIN closes one side&rsquo;s sending direction after previously queued bytes, but it does not require the opposite direction to close at the same instant.</p> <p>That property is easy to hide behind APIs that expose a connection as one object with a single <code>close</code> operation. At the protocol boundary, however, TCP carries two byte streams in opposite directions. A half-close makes the distinction visible and gives application protocols a useful signal: one participant can state that its request body is complete while still accepting a response.</p> https://nalar.dev/tcp-nagle-algorithm-batches-small-writes/ Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/tcp-nagle-algorithm-batches-small-writes/ <p>Applications can hand TCP data in pieces much smaller than the network&rsquo;s practical segment size. A terminal session, control protocol, or interactive service might produce only a few bytes at a time.</p> <p>Sending every tiny write immediately can create a stream of packets whose headers are much larger than their payloads. The Nagle algorithm reduces that pattern by limiting how aggressively a TCP sender emits new small segments while earlier data is still awaiting acknowledgment.</p> https://nalar.dev/tcp-window-scaling-expands-receive-capacity/ Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/tcp-window-scaling-expands-receive-capacity/ <p>A TCP connection can have plenty of bandwidth available and still transfer data below the path&rsquo;s capacity. One limit can come from flow control: the receiver tells the sender how much additional data it is prepared to accept, and the sender must respect that boundary.</p> <p>The original TCP header allocates 16 bits to the advertised receive window. That field can represent at most 65,535 bytes directly. TCP window scaling extends its effective range by negotiating a multiplier during connection setup, making much larger receive windows possible without changing the size of the header field.</p> https://nalar.dev/tcp-fast-open-sends-data-during-connection-setup/ Mon, 14 Sep 2026 00:00:00 +0700 https://nalar.dev/tcp-fast-open-sends-data-during-connection-setup/ <p>A conventional TCP connection separates setup from application traffic. The client sends a SYN, the server replies with SYN-ACK, and the client completes the three-way handshake with an ACK. Application data normally follows after that exchange has established the connection.</p> <p>For short transactions, that setup time can be a meaningful part of the total delay. A request may contain only a few hundred bytes, yet it still waits for a network round trip before the server can receive it through the established connection.</p> https://nalar.dev/tcp-keepalive-probes-detect-dead-idle-connections/ Mon, 14 Sep 2026 00:00:00 +0700 https://nalar.dev/tcp-keepalive-probes-detect-dead-idle-connections/ <p>A TCP connection can remain established even when no application data is moving. That is useful for database sessions, remote shells, messaging links, and other services that may stay quiet for long periods.</p> <p>Silence also creates an awkward case. A peer can lose power, move to another network, or disappear behind a failed path without sending a TCP FIN or RST. The other endpoint may retain an established connection because it has received no packet proving that the path is gone.</p>