TCP Normally Established the Connection Before the Real Exchange Began
Much of the information traveling across computer networks depends on TCP, a protocol designed to provide reliable communication between two endpoints.
Before ordinary application data could begin flowing through a new TCP connection, the two sides traditionally performed a short exchange to establish that connection. This process allowed each endpoint to confirm that the other was reachable and prepare the state needed for reliable communication.
The exchange was extremely fast on a nearby network. Across greater distances, however, even a few additional trips between two systems could become noticeable.
Distance Turned Tiny Delays Into Real Waiting
A protocol exchange that consumed almost no noticeable time across a local network could take considerably longer when packets had to travel across distant networks before returning.
Both Computers Had to Agree That the Connection Existed
The traditional TCP connection begins with a sequence commonly called the three-way handshake.
One endpoint sends a SYN packet requesting a connection. The receiving system responds with a SYN-ACK, acknowledging the request and presenting its own synchronization information. The initiating system then returns an ACK confirming the exchange.
Only after this relationship was established would an ordinary TCP conversation proceed with application data in the conventional manner.
Reliability Had a Setup Cost
The handshake established important connection state, but the time spent completing it occurred before the useful application exchange could fully get underway.
Network Speed Was Not Only About Bandwidth
A fast network connection is often described by how many bits it can transfer each second. That measurement is important, but it does not describe how long an individual packet takes to travel from one endpoint to another.
Latency measures that delay. A connection can have enormous bandwidth and still require a noticeable amount of time for information to make a round trip between distant systems.
When a protocol requires several exchanges before useful work begins, latency can affect responsiveness even when plenty of bandwidth is available.
A Wide Pipe Could Still Be a Long Pipe
High bandwidth determined how much information could move, while latency influenced how quickly an exchange involving back-and-forth communication could progress.
Useful Data Could Accompany the Connection Setup
Windows Server 2016 implemented TCP Fast Open as part of its TCP performance improvements.
The technology reduced the amount of waiting associated with establishing certain TCP connections by allowing data to be exchanged earlier in the connection process when the required Fast Open information was already available.
Instead of treating connection establishment and useful data transfer as completely separate stages every time, TCP Fast Open could overlap part of that work.
The First Exchange Could Do More Work
Reducing the amount of preliminary waiting was particularly valuable for short network transactions where connection setup represented a meaningful portion of the total time.
Fast Open Needed Information From an Earlier Connection
TCP Fast Open uses a special cookie mechanism to help a server recognize that a client has previously completed the necessary exchange.
During an earlier connection, the server can provide the client with a Fast Open cookie. On a later connection, the client can return that information as part of the request.
The server can validate the cookie and, when conditions permit, accept application data earlier instead of forcing the client to wait through the entire conventional setup sequence before useful data begins moving.
The Shortcut Had to Be Earned First
The first encounter still established the information needed for later Fast Open connections, allowing subsequent exchanges with the same service to benefit from the reduced setup delay.
A Small Request Could Spend Much of Its Life Just Getting Started
Long-running connections eventually transfer enough information that the initial handshake represents only a tiny fraction of their total lifetime.
Short transactions are different. If a client connects, requests a small amount of information, receives a response, and disconnects, the setup delay can represent a substantial portion of the entire operation.
Reducing that preliminary delay can therefore improve perceived responsiveness even though the maximum bandwidth of the network has not changed.
Faster Did Not Necessarily Mean More Megabits
A network operation could finish sooner because less time was spent waiting between protocol steps, not because the physical connection transferred bits at a higher maximum rate.
A New Connection Could Put More Data Into Its First Burst
TCP also controls how aggressively a sender introduces data into a network. Sending too much too quickly can contribute to congestion, so TCP begins cautiously and adjusts its behavior according to network conditions.
Windows Server 2016 increased the default Initial Congestion Window from four segments to ten.
This allowed a new connection to place a larger amount of information into its initial transmission before waiting for acknowledgments, which could help small transfers complete with fewer rounds of communication.
The Connection Could Begin With a Larger First Step
Increasing the initial window allowed more data to be sent early in the conversation while TCP continued using its congestion-control mechanisms as the connection progressed.
Starting Earlier and Sending More Were Not the Same Optimization
TCP Fast Open reduced part of the delay associated with establishing a connection. The larger Initial Congestion Window affected how much information could be transmitted during the early stages of that connection.
These changes attacked different sources of waiting.
One attempted to reduce the time before useful data could begin moving, while the other allowed the sender to move a larger initial amount once transmission was underway.
Several Small Delays Could Add Together
Network responsiveness improved not through one enormous change but by reducing different forms of waiting that occurred during the beginning of a TCP exchange.
A Missing Packet Could Stall Progress Even After the Connection Was Established
Networks do not deliver every packet perfectly. Congestion, wireless interference, overloaded equipment, faulty links, and other conditions can cause information to disappear before reaching its destination.
TCP is designed to recover from such losses, but recovery itself takes time. If the sender waits too long before realizing that information is missing, the connection can pause unnecessarily.
Improving the way TCP detects and responds to loss can therefore make a connection feel faster without changing the underlying network hardware.
Bandwidth Could Not Help a Packet That Never Arrived
Efficient recovery depended on recognizing missing information quickly enough to retransmit it without introducing avoidable delays into the application using the connection.
The Last Lost Packet Could Otherwise Cause a Long Pause
Packet loss near the tail of a transmission can be troublesome because there may not be enough later traffic to produce the duplicate acknowledgments traditionally used to trigger fast retransmission.
Without another signal, TCP may have to wait for a retransmission timeout before trying again.
Windows Server 2016 implemented TCP Tail Loss Probe to help convert some of those timeout situations into faster recovery events.
The End of the Transfer Needed Special Attention
When little additional data remained to generate clues about a loss, probing could help TCP discover the problem without simply waiting for a longer timeout to expire.
Timing Could Reveal Which Packet Was Probably Missing
Windows Server 2016 also implemented Recent Acknowledgment, commonly called RACK, as another improvement to TCP loss recovery.
RACK uses timing information from acknowledged packets to help determine when an earlier packet is likely to have been lost.
This provided TCP with additional evidence for making retransmission decisions rather than depending entirely on older patterns of acknowledgment behavior.
Acknowledgments Revealed More Than Successful Delivery
The timing of packets that did arrive could help the sender infer that another packet had probably failed to reach its destination.
Many Online Tasks Were Collections of Small Exchanges
Web services and network applications frequently perform numerous short transactions rather than one uninterrupted bulk transfer.
A page or application may contact multiple services, request small objects, establish additional connections, and wait for responses before deciding what to do next.
In workloads like these, shaving delay from connection establishment and loss recovery can matter repeatedly during a single user interaction.
Milliseconds Could Be Paid More Than Once
A small protocol delay becomes more important when an application encounters it repeatedly while assembling the information required to complete one visible task.
A Fast Application Could Still Wait on the Network Protocol
Server performance is often discussed in terms of processor speed, memory, storage, and application efficiency. Networking adds another layer whose behavior can influence how quickly users receive the result of all that computing work.
A server may generate a response immediately but still depend on connection establishment, congestion control, packet delivery, acknowledgments, and recovery before that response reaches the client.
Improving the transport protocol therefore complemented improvements elsewhere in the system.
Performance Continued After the Application Finished
Producing a result quickly was only useful if the networking stack could deliver that result without introducing unnecessary waiting of its own.
A Decades-Old Protocol Could Continue Learning New Tricks
TCP had already carried network traffic for decades by the time Windows Server 2016 arrived. Its age did not mean every performance problem had been permanently solved.
Internet workloads changed, networks became faster, servers handled greater numbers of connections, and users became increasingly sensitive to delays in interactive services.
TCP Fast Open, the larger initial congestion window, Tail Loss Probe, and RACK demonstrated how an established protocol could continue adapting to those conditions without abandoning the reliable communication model that made TCP so widely useful.
Making a network faster did not always require moving bits faster; sometimes it meant spending less time waiting before the next bits were allowed to move.
Windows Server 2016 Reduced Several Delays Hidden Inside TCP
The TCP improvements in Windows Server 2016 addressed several different moments where a network connection could spend time waiting. TCP Fast Open reduced connection-establishment delay in supported situations, while the larger Initial Congestion Window allowed more information to move during the beginning of a transfer.
Tail Loss Probe and RACK approached the problem from another direction by improving recovery when packets disappeared. Instead of allowing certain losses to produce unnecessarily long pauses, TCP gained additional mechanisms for recognizing and responding to missing data.
None of these features changed the fundamental purpose of TCP. They refined how efficiently the protocol reached that purpose. A connection could begin useful work sooner, transfer more information early, and recover more intelligently when something went wrong, reducing delays that users could experience even on networks whose raw bandwidth had not changed at all.
