Skip to content

Archive

TCP

23 articles
Tech 23 Sep 2026 5 min read

TCP Keepalive Probes Detect Silent Dead Peers

An established TCP connection can remain quiet for a long time. Silence alone does not mean either endpoint has failed: an application may simply have no data to exchange. That property is useful for long-lived sessions, but it also creates an operational problem when a peer disappears without sending FIN or RST. A machine can lose power, a network path can fail, or state in an intermediate device can vanish. The surviving endpoint may retain a socket that still appears established because no packet has arrived to prove otherwise. TCP keepalive provides an optional mechanism for testing such idle connections.

Tech 22 Sep 2026 6 min read

TCP TIME_WAIT Keeps Closed Connections Distinct from Delayed Segments

A TCP connection can finish exchanging application data and still leave a socket record behind. The familiar TIME_WAIT state is part of TCP’s close machinery, not evidence that a process forgot to close a descriptor. The endpoint that performs the active close commonly enters TIME_WAIT after the closing handshake. It keeps enough state for a bounded interval so late segments from the old connection cannot be confused with traffic from a later connection using the same endpoint identity.

Tech 22 Sep 2026 6 min read

Linux TCP Receive Autotuning Expands Buffer Capacity with Flow Demand

A TCP receiver can accept data only while it has room to hold bytes that the application has not consumed. On Linux, that capacity does not have to remain fixed at the small amount available when a connection starts. Receive autotuning can enlarge the socket’s receive buffer as the connection develops, subject to system limits and the state of the flow. That behavior matters most when a connection carries sustained traffic across a path with a sizable bandwidth-delay product. A receiver with too little usable window can constrain the sender even when the network and sender could carry more data. Extra receive capacity gives TCP room to keep data in flight while the application drains the socket.

Linux 17 Sep 2026 5 min read

TCP_NODELAY Disables Nagle Coalescing on a Socket

A TCP socket can hold a small write instead of transmitting it immediately when earlier data remains unacknowledged. This behavior comes from Nagle coalescing: it limits the stream of small TCP segments by allowing outstanding data to influence transmission of newly queued bytes. On Linux, setting TCP_NODELAY disables that coalescing rule for the socket. Small writes become eligible for prompt transmission, subject to the rest of the TCP stack, congestion control, flow control, queue state, and device scheduling.

Software Engineering 17 Sep 2026 6 min read

SO_REUSEPORT Moves TCP Connection Distribution Into the Kernel

With SO_REUSEPORT, several Linux TCP sockets can listen on the same local address and port at the same time. Incoming connections are assigned to a member of that reuseport group before an application calls accept(). The application no longer needs one shared listening socket as the sole handoff point between the network stack and multiple workers. That changes more than bind eligibility. It moves connection distribution into the kernel and gives each listener its own socket identity and accept path. The resulting architecture has different queueing, lifecycle, and routing properties from a design in which many workers compete on one listening socket.

Software Engineering 17 Sep 2026 4 min read

SO_REUSEPORT Forms Kernel-Selected Socket Groups

Multiple Linux sockets can bind the same local address when every participating socket enables SO_REUSEPORT before bind(). Incoming traffic is then assigned to a member of the resulting reuseport group rather than delivered to every socket. The shared address is therefore a kernel selection boundary, not a broadcast endpoint. This behavior supports independent receive or accept loops without forcing all work through one listening descriptor. It also creates a distinct operational property: group membership and the selection policy determine which socket receives a packet or connection.

Linux 17 Sep 2026 6 min read

SO_REUSEPORT Distributes Traffic Across Socket Groups

SO_REUSEPORT changes a local endpoint from a single-socket binding into a socket group. On Linux, multiple TCP or UDP sockets can bind the same local address when every participating socket enables the option before bind() and the bind credentials satisfy the kernel’s reuse rules. That behavior is distinct from merely relaxing address-conflict checks. Incoming traffic must also be assigned to one member of the group. The resulting selection boundary affects listener architecture, queue isolation, process restarts, UDP flow placement, and any design that assumes a port maps to exactly one socket.

Tech 16 Sep 2026 6 min read

TCP Window Scaling Expands the Receive Window for Fast Long Paths

TCP flow control limits how much data a sender may have outstanding according to the receiving endpoint’s available buffer space. The receiver advertises that limit in the TCP Window field so the sender does not deliver data faster than the receiving stack can accept it. The Window field in the TCP header is 16 bits wide. Without an extension, its largest value is 65,535 bytes. That ceiling can be too small on a path that carries data quickly but has a substantial round-trip time.

Tech 16 Sep 2026 6 min read

TCP TIME-WAIT Preserves Closed Connection State

A TCP endpoint can finish an application’s close operation while the protocol still retains state for that connection. After an active close completes its FIN exchange, the endpoint normally enters TIME-WAIT instead of discarding the connection record immediately. That retained state has two jobs. It leaves the endpoint able to acknowledge a retransmitted final FIN, and it separates a closed connection from a later incarnation that could use the same local and remote addresses and ports.

Software Engineering 16 Sep 2026 5 min read

TCP TIME-WAIT Delays Four-Tuple Reuse

A TCP endpoint that performs the active close can keep the closed connection in TIME-WAIT after the final ACK has been sent. The application-visible stream is finished, yet the transport retains state for a bounded interval before permitting unrestricted reuse of the same connection identity. That retention is not leftover application state. It protects the protocol boundary between one connection incarnation and a later connection that could otherwise use the same source address, source port, destination address, and destination port.

Tech 16 Sep 2026 6 min read

TCP Keepalive Probes Test Idle Connections

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. 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.

Tech 16 Sep 2026 5 min read

Nagle Algorithm Batches Small TCP Writes

TCP applications can issue writes much smaller than the network’s maximum segment size. Sending every tiny write as a separate segment can consume disproportionate header and processing overhead. The Nagle algorithm limits that pattern by allowing one small segment to remain in flight while later small writes wait for an acknowledgment or enough queued data to form a larger segment. This behavior reduces streams of tiny TCP segments. It can also add latency when an application expects each small write to leave immediately.

Linux 16 Sep 2026 5 min read

Linux TCP TIME_WAIT Retains Closed Connection State

A TCP socket can disappear from an application while the kernel still retains state for the closed connection. On Linux, the endpoint that completes the active close commonly enters TIME_WAIT, keeping enough protocol state to protect a later connection from delayed segments associated with the old one. This state is not evidence that a process forgot to close a file descriptor. The application-visible socket can already be gone. TIME_WAIT belongs to TCP’s connection-lifecycle machinery and persists independently of the process that initiated the close.

Linux 16 Sep 2026 4 min read

Linux TCP Autocorking Coalesces Consecutive Small Writes

A small TCP write does not always trigger an immediate packet transmission on Linux. With TCP autocorking enabled, the stack can defer a new small send when an earlier packet from the same flow is still waiting in a qdisc or device transmit queue, giving a following write a chance to join the pending data. The mechanism targets packet count rather than application-visible buffering semantics. A successful write() or sendmsg() still reports bytes accepted by the socket; autocorking influences when queued bytes advance into transmission.

Tech 15 Sep 2026 7 min read

TCP Window Scaling Expands Receive Capacity

A TCP connection can have plenty of bandwidth available and still transfer data below the path’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. 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.

Tech 15 Sep 2026 5 min read

TCP Nagle Algorithm Batches Small Writes

Applications can hand TCP data in pieces much smaller than the network’s practical segment size. A terminal session, control protocol, or interactive service might produce only a few bytes at a time. 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.

Software Engineering 15 Sep 2026 7 min read

TCP Half-Close Separates the Two Stream Directions

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’s sending direction after previously queued bytes, but it does not require the opposite direction to close at the same instant. That property is easy to hide behind APIs that expose a connection as one object with a single close 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.

Tech 15 Sep 2026 7 min read

TCP Delayed ACK Reduces Acknowledgment Traffic

TCP Delayed ACK Reduces Acknowledgment Traffic 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. 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.

Tech 15 Sep 2026 5 min read

Path MTU Discovery Finds the Largest Packet a Route Can Carry

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. 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’s local link can still be too large for a later hop.

Tech 15 Sep 2026 6 min read

Happy Eyeballs Races IPv6 and IPv4 Connections

A device on a dual-stack network can often reach the same service over both IPv6 and IPv4. DNS may return AAAA records for IPv6 addresses and A records for IPv4 addresses, leaving the client with several possible routes to the destination. 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.

Software Engineering 15 Sep 2026 6 min read

Half-Open TCP Connections Hide Peer Failure Until Traffic Resumes

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. 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.

Tech 14 Sep 2026 6 min read

TCP Keepalive Probes Detect Dead Idle Connections

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. 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.

Tech 14 Sep 2026 6 min read

TCP Fast Open Sends Data During Connection Setup

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. 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.