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, which then was updated to version HTTP/1.1 in 1999 in RFC2616 (even 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 only implement the h2 protocol part . Thus encrypted traffic is the de facto standard when using HTTP/2.

Also of note is the fact, that when used in combination with TLS the header field compression is explicitly disabled by protocol design for security reasons. However, the binary nature of of the headers compared to the verbose textual format employed by previous HTTP versions still provides a significant reduction in bandwidth used by the new protocol version.

Server-side

HTTP/2 comes in two flavours — client-side and server-side. In order to handle the stream-multiplexing proposed in the RFC, servers will need to spawn new worker threads to facilitate these changes. While almost no commercial consumer Browser provides it, many server implementations do indeed offer h2c, enabling server-to-sever communication using HTTP/2 that are therefore not encrypted. Many server-side implementations can be configured so that they as well only support h2. If such a configuration is employed, the h2Direct preamble check may be disabled by that server, as by design it is only required for h2c-connections.

Of note is the fact, that h2Push (speculative server push mode) is generally enabled by default in most implementations.

For example: in Apace resources may be marked for speculative server push by simply adding the following to the mod_headers:

<Location $/path/to/resource/$>
    Header add Link "</file/to/preload.css>; rel=preload"
</Location>

In H2O servers the feature is similarly on by default. H2O does improve on the speculative push a bit, by employing a feature called CASPer (Cache-Aware Server-Push). This feature tracks the clients cache states and the presence of resources in them by way of cookies. If a resource marked as preload is not present within the clients' cache push the resources specified with the link header.

Generally, it is advised by software providers to push contents which were previously inlined in HTTP/1.1.

Possible shortcommings in the RFC

• Possible Head-Of-Line-Blocking issues are not handled by the RFC and must be dealt with by the implementation. This might lead to inconsistent behaviour regarding this issue.
• In the RFC the Window-Update message seems to be used a bit excessively for the specified goal of reducing/minimizing network usage. A delayed (i.e. aggregated) Window-Update message might be advantageous to further reduce network traffic.
• Cipher spec renegotiation is disabled, which might lead to long lived connections that actually stall due to limitations on the number of possible messages using that cipher. This in turn might lead fallbacks to HTTP/1.1.
• The designed backward compatibility allows for selection of possibly blacklisted cipher-suites, should the application protocol and the cipher-suite be selected independent of one another.
• Further security considerations can be found in RFC 7540 in section 10.

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]