View source for The Future "Web on Speed"

==Motivation==

The advent of [https://tools.ietf.org/html/rfc8446 TLS1.3], of [https://tools.ietf.org/html/rfc7540 HTTP/2], and of [https://netdevconf.org/1.2/papers/ktls.pdf 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 [https://tools.ietf.org/html/rfc1945 RFC1945], which then was updated to version ''HTTP/1.1'' in 1999 in [https://tools.ietf.org/html/rfc2616 RFC2616] (even though it was first proposed in 1997 [https://tools.ietf.org/html/rfc2068]).  As of May 2015 ''HTTP/2'' is specified in the above mentioned RFC7540.

The specification allows for two modes
* ''h2'' (''HTTP/2'' over ''TLS''),
* ''h2c'' (''HTTP/2'' over ''TCP'') 
and it also defines 10 frame types:
* HEADERS,
* CONTINUATION,
* SETTINGS,
* PRIORITY,
* PUSH_PROMISE,
* DATA,
* WINDOW_UPDATE,
* PING,
* GOAWAY,
* RST_STREAM.

====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:

 {| class="wikitable"
|-
! 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''. However, if configured incorrectly, use of ''HTTP/2'' might actually increase network usage, as possibly too much of the content is pushed automatically (especially: if the server push does in fact not take the client side caches into account).

====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 (see also: delayed ACK's in ''TCP'').
* 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.

====Future proofing====
Even though, there are several points in which the specification falls considerably short of the promised improvements on previous versions, it is required by design, that all ''HTTP/2'' implementations willing to communicate using ''TLS 1.2'' (or greater) to include support of the
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
''TLS'' mode using P-256ec. This mode is mandated by both the new ''TLS 1.3'' version and ''KTLS'' as currently included in the ''Linux'' kernel. The German ''BSI'' is explicitly recommending use of this cipher suite up until 2025+ in its [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf;jsessionid=C73C09A84ECE395D5077EA87768F3A0F.1_cid341?__blob=publicationFile&v=7  TR-02102-2] document (as of Jan. 2019).

==KTLS==
With Linux kernel 4.13 (3.9.2017) ''Linux Kernel Transport Layer Security'' (or ''KTLS'' for short) was first introduced. In Kernel 4.17 (3.6.2018) ''KTLS'' was significantly updated by adding the so far missing ''TLS'' decryption.
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 [https://www.openssl.org/ 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 [https://netdevconf.org/1.2/papers/ktls.pdf paper] by Facebook's Dave Watson reported a '''7%''' reduction in CPU resources.

Netflix Inc., who have done similar changes for [https://www.freebsd.org/ 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. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.737.6630&rep=rep1&type=pdf] 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%. [https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf]