For more than 20 years, we have been viewing web pages through the HTTP protocol. Most users do not think about what it is and how it works. Others know that beneath HTTP lies TLS, and underneath that is TCP, with IP below it, and so on. And then there are the heretics who believe that TCP is outdated and long for something faster, more reliable, and secure. In their quest to invent the perfect new protocol, they’ve reverted to technologies from the 1980s, trying to build their brave new world on them.
A Bit of History: HTTP/1.1
In 1997, the text information exchange protocol HTTP version 1.1 received its RFC. At that time, the protocol had already been used by browsers for several years, and the new standard lasted another fifteen. The protocol operated solely on a request-response principle and was mainly intended for transmitting text information.
HTTP was designed to operate over the TCP protocol, which guarantees reliable delivery of packets to the recipient. TCP’s operation is based on establishing and maintaining a reliable connection between endpoints and segmenting traffic. Segments have their own sequence number and checksum. If any segment fails to arrive or arrives with an incorrect checksum, the transmission stops until the lost segment is recovered.
In HTTP/1.0, the TCP connection was closed after each request. This was highly inefficient since establishing a TCP connection (3-Way-Handshake) is not a quick process. HTTP/1.1 introduced the keep-alive mechanism, allowing the reuse of a single connection for multiple requests. However, since it can easily become a bottleneck, various implementations of HTTP/1.1 allow multiple TCP connections to a single host. For instance, Chrome and the latest versions of Firefox permit up to six connections.
Encryption was also intended to be handled by other protocols, and for this, the TLS protocol was utilized on top of TCP. TLS effectively protected data but further increased the time needed to establish a connection. As a result, the handshake process looked like this:
Cloudflare Illustration
Thus, HTTP/1.1 had a number of issues:
- Slow connection establishment.
- Data is transmitted in text form, which means that transmitting images, videos, and other non-text information is inefficient.
- One TCP connection is used for a single request, meaning that other requests must either find another connection or wait for the current request to release it.
- Only the pull model is supported. The standard does not include anything about server-push.
- Headers are transmitted as text.
If server-push is somewhat implemented using the WebSocket protocol, then the other issues had to be addressed more radically.
A bit of modernity: HTTP/2
In 2012, work began on the SPDY protocol (pronounced 'speedy') at Google. This protocol was designed to solve the main issues of HTTP/1.1 while maintaining backward compatibility. In 2015, the IETF working group presented the HTTP/2 specification based on the SPDY protocol. Here are the differences in HTTP/2:
- Binary serialization.
- Multiplexing multiple HTTP requests into a single TCP connection.
- Server-push out of the box (without WebSocket).
The protocol represented a significant step forward. It greatly and does not require creating multiple TCP connections: all requests to a single host are multiplexed into one. This means that one connection contains several so-called streams, each with its own ID. A bonus feature is the built-in server-push.
However, multiplexing leads to another fundamental problem. Imagine that we are asynchronously making 5 requests to one server. With HTTP/2, all these requests will be executed within a single TCP connection, meaning that if one segment of any request is lost or arrives incorrectly, the transmission of all requests and responses will stop until the lost segment is recovered. Obviously, the worse the connection quality, the slower HTTP/2 performs. , in conditions where lost packets make up 2% of all traffic, HTTP/1.1 in the browser performs better than HTTP/2 by opening 6 connections instead of one.
This issue is called 'head-of-line blocking' and, unfortunately, it is not possible to solve it using TCP.
Illustration by Daniel Steinberg
As a result, the developers of the HTTP/2 standard have done an immense amount of work and accomplished almost everything possible at the application layer of the OSI model. It's time to delve into the transport layer and invent a new transport protocol.
We need a new protocol: UDP vs TCP
It quickly became clear that implementing an entirely new transport layer protocol is an insurmountable task in today's reality. The thing is, hardware devices and middle-boxes (routers, firewalls, NAT servers...) are familiar with the transport layer, and teaching them something new is a very challenging task. Furthermore, support for transport protocols is embedded in the operating system kernels, and those kernels don't change very willingly.
At this point, one might want to throw up their hands and say, 'Sure, we’ll invent a new HTTP/3 with playing cards and courtesans, but it will take 10-15 years to implement (about the time it will take to replace most hardware),' but there’s another, less obvious option: to use the UDP protocol. Yes, the very protocol that we used to throw files around in local networks back in the late nineties and early naughts. Almost all current hardware can work with it.
What are the advantages of UDP compared to TCP? Primarily, the fact that we don't have a transport layer session known to the hardware. This allows us to define the session ourselves at the endpoints and resolve conflicts there. In other words, we are not restricted to one or several sessions (as in TCP), but can create as many as we need. Secondly, data transmission via UDP occurs faster than via TCP. Thus, in theory, we can break today's speed ceiling achieved in HTTP/2.
However, UDP does not guarantee the reliability of data transmission. Essentially, we are just sending packets, hoping they will be received on the other end. Didn't receive them? Well, tough luck... This was sufficient for transmitting adult videos, but for more serious matters, reliability is needed, which means we'll have to add something on top of UDP.
As with HTTP/2, work on creating a new protocol began at Google in 2012, roughly at the same time the work on SPDY started. In 2013, Jim Roskind presented to the wider public In 2015, an Internet Draft was submitted for standardization to the IETF. By that time, the protocol developed by Roskind at Google differed significantly from the one proposed for standardization, which led to the Google version being referred to as gQUIC.
What is QUIC
Firstly, as already mentioned, it is a wrapper over UDP. A QUIC connection is established over UDP, where multiple streams can exist, similar to HTTP/2. These streams exist only at the endpoints and are managed independently. If a packet loss occurs in one stream, it does not affect the others.
Illustration by Daniel Steinberg
Secondly, encryption is now integrated into the protocol rather than being a separate layer. This allows for the establishment of connections and the exchange of public keys in a single handshake, as well as the use of the clever 0-RTT handshake mechanism to avoid delays during the handshake process. Additionally, individual data packets can now be encrypted. This enables the decryption of received packets independently, without waiting for the complete reception of data from a stream. Such operational mode was impossible in TCP, as TLS and TCP operated independently, and TLS couldn't know how the data would be fragmented by TCP. Consequently, it couldn't prepare its segments to align with TCP segments one-to-one for independent decryption. All these improvements allow QUIC to reduce latency compared to TCP.
Thirdly, the concept of lightweight streams allows the disconnection of the connection from the client's IP address. This is important, for instance, when a client switches from one Wi-Fi access point to another, changing their IP. In this case, using TCP involves a lengthy process where existing TCP connections time out and new connections are created with the new IP. With QUIC, the client simply continues sending packets to the server from the new IP using the old stream ID. Since the stream ID is now unique and not reused, the server understands that the client has changed IP, resends lost packets, and continues communication at the new address.
Fourthly, QUIC is implemented at the application level rather than the operating system level. On one hand, this allows for quicker changes to the protocol, as updating just involves refreshing the library instead of waiting for a new OS version. On the other hand, this leads to a significant increase in CPU consumption.
Lastly, let's talk about headers. Header compression is one of the areas where QUIC and gQUIC differ. I don't see the point in spending too much time on this; I'll just mention that in the version submitted for standardization, header compression was made as similar as possible to header compression in HTTP/2. You can read more about it. .
How much faster is it?
That's a complicated question. The thing is, since we don't have a standard yet, there's not much to measure. Perhaps the only statistical data we have is from Google, which has been using gQUIC since 2013 and reported to the IETF in 2016 In 2017, a group of researchers led by Arash Molavi Kakhki published
a study on the performance of gQUIC compared to TCP. The study revealed several weaknesses in gQUIC, such as its instability to packet reordering, unfairness in channel bandwidth, and slower transmission of small (up to 10 kB) objects. However, this last issue can be mitigated through the use of 0-RTT. In all other cases examined, gQUIC demonstrated a speed increase compared to TCP. It’s difficult to provide specific figures. It’s better to read
the study itself or .
A little about the future: what about HTTP/3?
A Bit of the Future: What About HTTP/3?
Here everything is crystal clear: the API will not change at all. It will remain exactly the same as it was in HTTP/2. If the API stays the same, the transition to HTTP/3 will be based on using a new version of the library that supports transport over QUIC on the backend. However, we will still have to maintain a fallback to older versions of HTTP for quite some time, as the internet is not ready for a complete transition to UDP.
Who already supports
Here existing QUIC implementations. Despite the lack of a standard, the list is quite decent.
No browser currently supports QUIC in production releases. Recently, there was information that Chrome enabled HTTP/3 support, but only in the Canary version.
Among backends, only and , but currently experimentally. NGINX announced in late spring 2019 , that they started working on HTTP/3 support, but it is not yet finished.
What problems exist
We live in a real world where no major technology can go mainstream without facing resistance, and QUIC is no exception.
The most important thing is to explain to the browser that "https://" no longer necessarily points to TCP port 443. There might not even be TCP. This is where the Alt-Svc header comes into play. It allows you to inform the browser that this website is also available over a specified protocol at a given address. In theory, it should work like clockwork, but in practice, we might encounter situations where UDP might be blocked by a firewall to prevent DDoS attacks.
But even if UDP is not blocked, the client may be behind a NAT router configured to maintain TCP sessions by IP address, and since we are using UDP, which does not have a hardware session, NAT will not maintain the connection, and the QUIC session .
All these problems are related to the fact that UDP has not previously been used for internet content transmission, and hardware manufacturers could not foresee that this would happen someday. Similarly, administrators do not quite understand how to properly configure their networks for QUIC. This situation will gradually change, and in any case, such changes will take less time than the introduction of a new transport layer protocol.
Furthermore, as previously described, QUIC significantly increases CPU usage. Daniel Stenberg the increase in CPU usage by up to three times.
When will HTTP/3
Standard By May 2020, given that there are still documents planned for July 2019 that remain unfinished, it can be said that the date will most likely be postponed.
Google has been using its implementation of gQUIC since 2013. If you look at the HTTP request sent to the Google search engine, you can see this:
Conclusions
Currently, QUIC appears to be a rather raw but highly promising technology. Considering that over the past 20 years, all transport layer protocol optimizations have mainly focused on TCP, QUIC, which often outperforms in performance, already looks quite impressive.
However, there are still unresolved issues that need to be addressed in the coming years. The process may take longer due to the involvement of hardware that no one likes to update, but nonetheless all problems appear to be quite solvable, and sooner or later we will all have HTTP/3.
The future is just around the corner!
Source: habr.com
