The Future "Web on Speed"
Motivation
The advent of TLS1.3, of HTTP/2, and of KTLS begs the questions:
- Where does the standardization lead?
- Are there already working implementations?
- Does this mean faster and more secure web browsing for all?
This article will mainly talk about HTTP/2 and in part about KTLS.
HTTP/2
HTTP is a widely used application-level protocol in the web and was used since 1990. So far three versions exist: HTTP/1.0 as described in RFC1945 and was updated to version HTTP/1.1 in 1999 in RFC2616 (though it was first proposed in 1997 [1]). As of May 2015 HTTP/2 is specified in the above mentioned RFC7540.
Promises
The new HTTP version addresses a number of issues present in previous versions:
- Multiplexing of streams is now possible in one connection
- Prioritization of streams allows for faster handling of more important requests
- Upgrade mechanism allows for older systems in the network that do not understand HTTP/2
- Compression of verbose header fields is possible
- Use of binary message framing further minimizes network usage
- Speculative server push mode for reduced need of inlined content and increased cacheablity
Implementations
As of approximately mid-2015, many consumer products offer support for HTTP/2 in their respective implementations. The following table gives an overview of tools that include support; it does not claim to be complete:
| Browser Software | Server-side Software | CDN's |
|---|---|---|
| Chromium | Apache | Akamai |
| Edge (and Internet Explorer) | H2O | AWS |
| Firefox | Microsoft Server | Microsoft Azure |
| Opera | nginx | Cloudflare |
| Safari | SuaveIO | Fastly |
It is notable, that while h2c for unencrypted traffic is specified, all major browsers implement only the h2. Thus encrypted traffic is the de facto standard when using HTTP/2.
KTLS
With Linux kernel 4.13 (3.9.2017) Kernel TLS was first introduced. In Kernel 4.17 (3.6.2018) KTLS was completed by adding the so far missing decryption side of things.
It promises fewer context switches and file copies to be necessary for the encryption process, than when done entirely by user-space libraries (such as OpenSSL). It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original paper by Facebook's Dave Watson reported a 7% reduction in CPU resources.
Netflix Inc., who have done similar changes for FreeBSD during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70%. The immediate change for a similar approach as KTLS only resulted in a 5.88% speed increase. [2] Within a year however, they managed to reach a 247.06% speed increase on the baseline OpenSSL traffic, and using highly optimized libraries even managed to increase that percentage to 320.59%. [3]