Authors: Gabriel Montenegro, Daniel Havey
Share On: Twitter Share On: LinkedIn
This blog is part of a series for the Top 10 Networking Features in Windows Server 2019!
— Click HERE to see the other blogs in this series.
Look for the Try it out sections then give us some feedback in the comments!
Don’t forget to tune in next week for the next feature in our Top 10 list!
The Internet is part of our daily lives both at work and at home, in the enterprise and in the cloud. We are committed to making your Internet experience faster and safer, and in this blog, we discuss how the features in Windows Server 2019 brings those goals closer to reality. To do this we:
- Improved coalescing of connections to deliver an uninterrupted and properly encrypted browsing experience.
- Upgraded HTTP/2’s server-side cipher suite negotiation for automatic mitigation of connection failures and ease of deployment.
- Changed our default TCP congestion provider to Cubic to give you more throughput!
HTTP/2 for a faster and safer Web
We originally added support for HTTP/2 (RFC 7540) in Windows Server 2016 (and Windows 10) in the native HTTP server (in particular, http.sys, the kernel component for the HTTP server and IIS). Now, Windows Server 2019 delivers performance and security benefits to your web site deployments with HTTP/2.
For a clear illustration of HTTP/2 performance gains over HTTP/1.1, checkout this demo: https://http2.akamai.com/demo or play the video below:
HTTP/2 Refresher
HTTP/2 increments the HTTP protocol version for the first time in well over a decade – version 1.1 (RFC 2616) was published in 1999! As befits a major protocol version, the new version was not bumped from 1.1 to 1.2, but from 1.1. to 2. HTTP/2 brings some radical improvements for web site performance based on features such as:
Multiplexing
HTTP is the best-known and most deployed protocol in the internet – It is the basis of the web. Nevertheless, by itself it cannot accomplish anything! To exchange data, HTTP depends on the services of the “transport layer.”
HTTP/2 and HTTP/1.1 have a radically different use of this underlying transport layer:
- HTTP/1.1: Each request required a dedicated TCP (and TLS, when using HTTPS) connection potentially imposing several round trips to establish that connection.
- HTTP/2: HTTP/2 shares a single TCP connection across many requests to the same web site. This is called multiplexing.
With HTTP/2’s multiplexing capability, only the first request incurs the roundtrips required to establish the connection. Subsequent associated requests (more information under Coalescing section below) require no connection establishment and immediately send HTTP data (A.K.A. 0-RTT). The picture below contrasts how HTTP/1.1 and HTTP/2 use the transport layer.
Header Compression
HTTP exchanges typically employ many HTTP headers – Sometimes these headers represent much more data than the actual payload. Recognizing this problem, HTTP/2 uses HPACK, a compression scheme built explicitly for HTTP Header compression. This drastically reduces the amount of data that needs to be exchanged between client and server which may also save on round-trip times.
HTTP/2 Improvements in Windows Server 2019
Connection Coalescing
Windows Server 2019 extends the benefits of HTTP/2 to domains designed for HTTP/1.1 by applying connection coalescing to mitigate sharding. In HTTP/1.1 sharding is when a given domain is made to appear as different domains to force more independent TCP connections. This is an artificial method of creating parallelism that is no longer required in HTTP/2, but sharding and websites designed for HTTP/1.1 will remain for a long time.
To mitigate sharding, Windows Server 2019 also enables connection coalescing on both Edge and the HTTP server. With coalescing, domains like a.bing.com and b.bing.com will end up sharing a single TCP connection if their certificate matches. Without coalescing, sites like a.bing.com and b.bing.com would require separate TCP connections.
Security Improvements
Windows Server 2019 automatically fixes potential connection failures with HTTP/2! To understand why connection failures may arise, let’s remember that HTTP/2 requires at least version 1.2 of TLS with modern and secure cipher suites while blacklisting others. Unfortunately, this security requirement can lead to brittle HTTP/2 negotiations. If so, users of your web site may be unable to connect until the web server administrator fixes the SSL cipher suite ordering.
With Windows Server 2019, this is resolved without any intervention from the administrator, so users don’t encounter connection failures.
Here are some details of what we did:
- These failure modes can arise if the default SSL cipher suite ordering in Windows Server 2016 is changed incorrectly: if any of the cipher suites blacklisted by HTTP/2 appears before those allowed by HTTP/2, Firefox and Chrome abort the connection (as allowed, but not recommended by HTTP/2). Chrome shows ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY, and Firefox, NS_ERROR_NET_INADEQUATE_SECURITY.
- Even though correct ordering of the SSL cipher suites (as assured by the default ordering in Windows) avoids this problem, in Windows Server 2019 we have improved the robustness of the cipher suite negotiation mechanism to be impervious to the ordering of the SSL cipher suites. Of course, the list must still include cipher suites allowed by HTTP/2, but they no longer need to necessarily appear at the beginning of the list before any blacklisted ones.
This reduces the operational complexity of HTTP/2 deployment, enabling customers to more readily reap its benefits including the higher-grade cipher suites required by HTTP/2.
Windows TCP goes Cubic!
Many of you already are aware of our march towards lower latency, higher throughput transports with pluggable congestion control providers. These regulate TCP senders, so they apply equally to both client and server. Our congestion control providers are: New-Reno, Compound TCP, Cubic and LEDBAT. So, what is the big news? Cubic is now the default congestion control provider going forward. How do you know? Open up a PowerShell window and run this command:
PS C:WINDOWSsystem32> Get-NetTCPSetting | Select SettingName, CongestionProvider
SettingName CongestionProvider
———– ——————
Automatic
InternetCustom CUBIC
DatacenterCustom CUBIC
Compat NewReno
Datacenter CUBIC
Internet CUBIC
See? Cubic, cubic everywhere (except the compatibility template)!
So, why should you care that the new default is Cubic? Because Cubic is faster and fairer for the end-user. Cubic is especially well suited for high bandwidth, high latency links where Standard TCP tends to perform poorly. If you are an admin and have a need to send a significant amount of data over a high bandwidth, high latency (long distance) link, you will like the benefits that Cubic brings.
“We’ve got a ton of data that shows CUBIC moves our mean throughput, in MB/s on coast-to-coast transfers at ~70ms RTT a full 40MB/s relative to CTCP. It’s an exciting shift in throughput that we feel is going to grant us the recovery head room to reach our goals.”
– Engineer at a very large Microsoft service
Why is Cubic faster on high speed long distance network links? It’s all in the sending window curves. Figure 1 (below) shows how the data sending rate (throughput) changes over time. The blue line is standard TCP (New Reno) and the red line is Cubic.
The left side of the graph shows the connection start-up (slowstart) phase. TCP start-up is not affected by congestion control algorithms so this part of the curves are identical. After start-up phase is completed the connections goes into congestion avoidance phase. Notice that the Cubic curve spends more of its time near the network saturation point than standard TCP. This is why Cubic is faster because its congestion window curve is exponential rather than linear like standard TCP.
Figure 1 — New Reno vs Cubic TCP Congestion Window Curves
Okay, enough theory. Let’s see some data! In Figure 2, we see an experiment where we sent data across the continental United States in 250 MB chunks overnight. We binned and sorted the data into a Pareto chart (without the line graph for clarity). On the left we see Cubic and on the right we see Compound (the default congestion provider prior to Windows server 2019). Cubic is consistently reaching higher throughputs than Compound.
Bottom line: Cubic gets more throughput.
Figure 2 — Cubic Throughput vs Compound TCP Throughput
Conclusion
At the Windows Core Networking team, we are excited to deliver Windows Server 2019’s improvements in (1) the HTTP server’s ease of deployment and performance of HTTP/2, and (2) TCP congestion control. The world just got faster and safer for consumers and server administrators and all you need to do is run Windows.
Thanks for reading,
Daniel Havey and Gabriel Montenegro
Leave a Reply