History of the Internet

Why TCP Sequence Numbers Return to Zero

In TCP, zero does not always come before a large number. After sequence position 4,294,967,295, the next position is zero. The protocol keeps acknowledgments, windows and retransmission decisions coherent by treating the 32-bit sequence space as a ring and comparing positions with modular arithmetic.

Number That Made TCP Flow Control Move

The Number That Made TCP Flow Control Move

TCP did not put a receiver's memory size into every segment. It put a moving allowance into the header: a count of how many data octets the sender of that segment was then willing to accept, beginning at the acknowledgment frontier. That pairing turned flow control into a continuously renewed boundary in sequence space.

Handle Was the Same. The Credential Could Be Different: RFC 1509

The Handle Was the Same. The Credential Could Be Different: RFC 1509

Two programs present the same pointer-sized value to a security service. One reaches Alice’s credential. The other may reach Bob’s—or nothing at all. No bit in the value has changed. The caller has. RFC 1509 made this possible on purpose, because its handle was never the credential and was never meant to carry authority beyond the local system that resolved it.

Bits TCP Kept for the Future

The Bits TCP Kept for the Future

Six quiet positions in TCP's 1981 header carried no immediate function. Their importance lay in the discipline around that emptiness: send them as zero, leave them available, and let a later standard define meaning without moving the boundary of the base header. Two decades later, Explicit Congestion Notification turned two of those positions into a conversation between receiver and sender.

Bit That Made TCP’s Acknowledgment Number Mean Something

The Bit That Made TCP’s Acknowledgment Number Mean Something

Every TCP segment reserves 32 bits for an acknowledgment number, but the number is not automatically evidence. One control bit decides whether those bits describe the next sequence number the sender expects—or are simply not significant at all.

Number That Told TCP Where Data Began: Data Offset

The Number That Told TCP Where Data Began: Data Offset

TCP's header can grow when options are present, so the first application byte cannot live at one fixed position. A four-bit field solves the ambiguity: Data Offset counts the complete header in 32-bit words. Options may end early and padding may remain, but the encoded boundary—not an option marker—tells the receiver where data actually begins.

Header That Was Never Sent: Why TCP Checksums IP Addresses

The Header That Was Never Sent: Why TCP Checksums IP Addresses

TCP validates more than the bytes in its own segment. Before calculating or checking the mandatory checksum, each endpoint conceptually places selected IP fields in front of the TCP header: the source and destination addresses, protocol identity and TCP length. This pseudo-header is never transmitted as TCP data. It is reconstructed at both ends so the segment's integrity evidence includes where it was meant to go.

Two Flags That Took Up Space: Why TCP Counts SYN and FIN

The Two Flags That Took Up Space: Why TCP Counts SYN and FIN

TCP numbers bytes, yet two control events also advance its sequence space. SYN stands before the first data octet and FIN stands after the last, giving connection opening and closing the same acknowledgment and retransmission protection as the stream without turning either flag into application data.

Push That Was Never a Message Boundary: TCP's PSH Flag

The Push That Was Never a Message Boundary: TCP's PSH Flag

An application asks TCP to push a buffer because waiting for later data could stall the exchange. TCP marks the last segment it creates from that buffer with PSH. Yet the mark does not turn that segment into a message: the sender's write, the packets on the wire, the receiver's buffers and the application's reads may all end at different places.

Connection One Side Forgot: TCP's Half-Open Reset

The Connection One Side Forgot: TCP's Half-Open Reset

A TCP connection can look alive from one endpoint and already be gone from the other. The classic specifications called that split a half-open connection. Their recovery examples turn the next packet into a test of shared memory: sequence expectations collide, a reset makes the disagreement explicit, and the stale connection gives way to a new handshake.

When Both Sides Knocked at Once: TCP's Simultaneous Open

The standard picture of TCP begins with a client knocking and a server listening. The protocol itself has never required that casting. Its original 1981 specification described what happens when two endpoints knock at once: their SYN segments cross, each side becomes both initiator and responder, and one connection emerges from a handshake whose symmetry is easy to overlook.

Host That Had to Wait Before Speaking: TCP's Quiet Time After Restart

The Host That Had to Wait Before Speaking: TCP's Quiet Time After Restart

A restarted machine may look clean precisely because it has forgotten too much. TCP's original quiet-time rule addressed that paradox: if a host lost the sequence numbers used before a crash, it was told to emit nothing for one maximum segment lifetime. Silence was not a repair delay. It was a substitute for missing history, giving old packets time to disappear before the host reused their numerical territory.

Reset That Ended Waiting Too Soon: TCP's TIME-WAIT Assassination Hazard

The Reset That Ended Waiting Too Soon: TCP's TIME-WAIT Assassination Hazard

TIME-WAIT looks passive: a closed connection remains in a table while a clock runs down. In 1992, RFC 1337 showed that the state could be destroyed by active protocol behavior. One old segment provoked an acknowledgment; that acknowledgment provoked a reset; the reset erased the guard intended to contain old segments. The lesson was not simply to wait longer. It was to distinguish evidence that a new connection is safe from a packet sequence that merely deletes the old state.

Deadline That Was Not a Retransmission Timer: TCP User Timeout

The Deadline That Was Not a Retransmission Timer: TCP User Timeout

TCP can decide to retransmit a segment and still decide, on a different clock, that the connection has waited too long. The first decision schedules another attempt. The second ends the connection. RFC 5482 made that persistence preference visible to a peer without turning it into a remote command.

Offer That Was Not a Negotiation: How TCP MSS Bounded Each Direction

The Offer That Was Not a Negotiation: How TCP MSS Bounded Each Direction

Each side of a TCP connection can place a four-byte option in its opening SYN. The number does not settle a shared packet size. It says how much TCP data the option's sender is prepared to receive in one segment—a directional boundary that the other endpoint must combine with facts from its own path.

Handshake That Had to Remember Its Previous Handshake: How RFC 5746 Bound TLS Renegotiation

The Handshake That Had to Remember Its Previous Handshake: How RFC 5746 Bound TLS Renegotiation

A TLS handshake could authenticate its own conclusion while saying nothing cryptographic about the bytes that came before it on the same connection. RFC 5746 repaired that gap by requiring every renegotiation to carry evidence from the immediately previous handshake.

Neighbor That Stayed in the Cache After It Became Unreachable: How RFC 7048 Separated Failover from Forgetting

The Neighbor That Stayed in the Cache After It Became Unreachable: How RFC 7048 Separated Failover from Forgetting

IPv6 Neighbor Discovery once treated the last unanswered unicast probe as both a warning to seek another path and a reason to erase the path it already knew. RFC 7048 split those decisions: a neighbor could become officially unreachable without its final link-layer address being immediately forgotten.

Address That Spoke Before It Was Proven Unique: How Optimistic DAD Bounded Early Use

The Address That Spoke Before It Was Proven Unique: How Optimistic DAD Bounded Early Use

A newly attached IPv6 host used to wait for a uniqueness test before speaking. RFC 4429 shortened that silence without pretending the test had already passed: the address could carry traffic, but not yet exercise the Neighbor Discovery powers of an uncontested owner.

Clock Moved Only for Useful News: How TCP Tied Its Timer to New Acknowledgment

The Clock Moved Only for Useful News: How TCP Tied Its Timer to New Acknowledgment

An acknowledgment can arrive without changing what a TCP sender knows. RFC 6298 made that distinction control the retransmission clock: progress receives a fresh interval, repetition does not.

Old Mean Had to Move Last: How TCP Kept Its Timeout Variance Honest

The Old Mean Had to Move Last: How TCP Kept Its Timeout Variance Honest

A new round-trip measurement does two jobs inside TCP: it changes the expected delay and tests how wrong that expectation was. RFC 6298 fixed the order so the sample could not soften its own surprise before variance was recorded.