Written by Ramón Saquete
Índice
In 2015 we announced the release of the HTTP/2 protocol standard. Only 5 years later, we can already analyze the upcoming implementation of the HTTP/3 protocol and the QUIC protocol on which it relies. According to Google, it will improve performance by 8% to 15%.
HTTP/2 brought performance improvements and the ability of the server to send unsolicited files with server push transfers, although it is still difficult to find hosting services that allow the latter.
Since it took 15 years from the definition of the HTTP/1.1 standard to HTTP/2 and only 5 or 6 years from HTTP/2 to HTTP/3, there will not be enough time for HTTP/2 to completely replace HTTP/1.1, so the laggards will move directly to HTTP/3. Among these laggards, we can include the Google spider (Googlebot), which continues to index only with HTTP/1.1 when it should take advantage of the speed of HTTP/2 if the crawled web server allows it.
The reason you should make this change is that many sites have discarded the domain sharding optimization technique, which is counterproductive with HTTP/2 and HTTP/3, but made sense under HTTP/1.1.
The following graph shows that HTTP/2 usage has not yet reached 50%, with a current growth rate of approximately 10% per year:
What is QUIC?
QUIC stands for Quick UDP Internet Connections and Quick UDP Internet Connections protocol and is much more important than HTTP/3 since breaks with the foundations of the Internet by reinventing the layered architecture of the TCP/IP model, taking over the TCP transport layer protocol functions and the TLS security layer functions. This is a radical change because since the Internet was invented in the 70s and 80s, its only transport protocols have been TCP and UDP.
In order to be able to QUIC implementation without having to change all the Internet network devices, this is based on the UDP transport protocol, as its name suggests, although this does not prevent there being problems in the regulation of QUIC traffic that have not yet been resolved and which are the main reason why the protocol is still in the experimental phase. So despite using UDP, many routers and firewalls will have to adapt to this new protocol.
How does it work?
Visually, the protocol stack would look like the following image, in which we have assigned colors to the different functions of each protocol. Thus, we see how QUIC assumes the following functions:
- Functions of the security layer: guarantees that no one modifies the data, that no one sees it and the identity of the company offering the service.
- TCP transport layer functions: error detection and correction and congestion control.
- Transport functions that had been included in HTTP/2: HTTP/2 included the multiplexing and flow prioritization functions, which are transport functions. By taking over QUIC these functions are removed from HTTP/2, giving rise to HTTP/3.
TCP is a connection-oriented protocol that ensures that data arrives error-free at the destination. The UDP protocol, on the other hand, is a transport protocol used for fast communications, without establishing a connection and through which data can arrive with errors. The latter is used in applications such as video streaming, where it is more important to receive the image in real time than for a piece of a frame to fail. But in a website we do need reliable data. So QUIC performs the functions that TCP did that UDP does not. In addition, it does so more efficiently, achieving reliable, secure data at higher speeds. The function performed by UDP is simply to chunk the information into packets called datagrams.
QUIC will initially be used only with the HTTP/3 application protocol, but it is likely that other application protocols will rely on QUIC in the future.
Since in practice HTTP/2 is forced to work over TLS, it cannot be used if the website does not have HTTPS. The same is true for HTTP/3 which, being forced to run on top of QUIC, cannot be used on a website that does not have HTTPS.
With HTTP/3 and QUIC speed improvement will not be as noticeable as from HTTP/1.1 to HTTP/2 but will be an improvement especially in situations where transmission errors occur. This is very important considering that cell phones are the preferred means of navigation for users and that coverage conditions are not always the best. But let’s take a closer look at the features.
QUIC protocol characteristics:
- Multiplexing and improved error handling HTTP/2: like HTTP/2, it allowed all web files to be sent multiplexed in a single TCP connection, HTTP/3 allows sending several multiplexed files over QUIC, with one connection per file. With HTTP/2, an error in one packet caused all other packets to be discarded until the server retransmitted the packet with the error. On the other hand, with HTTP/3 and QUIC, packets can still be received, even if some have arrived with errors. This defect, which could make HTTP/2 slower than HTTP/1.1 with a high error rate, does not occur with HTTP/3.
- QUIC avoids slow TCP startup and controls network congestion better: the TCP protocol uses a sliding window algorithm to control the amount of data sent and not saturate the network. This algorithm initially increases the amount of data sent little by little, so that the first bytes are downloaded more slowly. QUIC uses a smarter algorithm that lacks this slow start.
- QUIC uses the HTTP/2 priority mechanism, allowing to have several flows with different priorities.
- Fewer round-trip cycles and higher network utilization. The server, unlike TCP, is not able to does not need to wait for packet receipt confirmations from the client for the server to send the next packets. At the time of establish an encrypted connection, requires only one round-trip cycle, unlike TCP + TLS which may require up to 3. In addition, to establish multiple connections, once the first one has been established, QUIC only needs one one-way trip to do so. As the packets have to make fewer trips, the latency time will be less affected, so the margin for improvement when using a CDN will be smaller.
- QUIC requires less use of CPhttps://www.humanlevel.com/blog/seo/cdn-cuando-y-como-utilizar-uno.htmlU, which translates into small battery savings on cell phones.
- QUIC enables connection migration: this allows connections to be reused when you disconnect from one network and connect to another. For example, when you switch from 4G to WiFi or from one WiFi to another.
Brief history of QUIC
QUIC started being developed by Jim Roskind at Google in 2012. Initially it used a proprietary encryption solution and was intended to work only with a different version of HTTP/2 than the official one. However, when the work was presented as a draft in 2015 to the IETF (the Internet Engineering Task Force defines Internet standards) and started to be developed by a working group within it, its cipher was changed to the one used by TLS 1.3 and theoretically now supports any application protocol. Therefore, the original version is now called gQUIC.
During the development of QUIC, the specification has been called HTTP/2 over QUIC when in fact it was not really HTTP/2, but a different version of the protocol which, apart from delegating multiplexing to QUIC, redefines its syntaxes, so that finally it was decided to rename the specification to HTTP/3. The term is sometimes used to refer to both the new HTTP protocol and QUIC.
Current HTTP/3 usage
Regarding web services: Google implements it in YouTube, Gmail and the search engine. In Facebook it is implemented only in some parts.
As for hosting services: the pioneers in offering HTTP/3 are CloudFlare’s CDN (in beta testing phase) and SiteGround’s hosting.
In browsers, it is currently supported by Chromium, Firefox, Opera and Chrome but, being an experimental protocol, it is not enabled by default in some of them.
For HTTP/3 to work, both the client and server must support it and have a compatible implementation of the protocol: remember that this is experimental and the specification is in a draft state that may change, so it would not be uncommon for some client-server implementations not to be compatible with each other.
How do I know if a website uses HTTP/3?
To check whether a website uses HTTP/3, you can use one of these online tools: HTTP/3 Test or HTTP/3 Check.
It can also be checked from browsers that already support it.
HTTP/3 is enabled in Chrome from chrome://flags/#enable-quic, in Opera from opera://flags/#enable-quic and in Firefox by typing in the about:config bar, and then enabling the network.http.http3.enabled property. Then we restart the browser and we can see in the network window the HTTP/3 protocol if the client and the server are using the same version of the protocol. In the following Firefox screenshot you can see an example:
Conclusion
HTTP/3 and QUIC will reduce the time we spend waiting for web pages to load and, when it is finally standardized, it will be a priority to have it to give users a good performance against the competition. But, for the time being, we will have to wait for the problems to be solved for its implementation and for browsers and web services to implement the definitive version.
