HTTP/3: Enabling a faster and secure internet
Mar 10, 2022by, Alfas Hakeem P
HTTP/3 is the latest version of Transport Protocol for Web Communications. It is developed by the Internet Engineering Task Force(IETF)’s QUIC Working Group and as on June 11 2021, it is an Internet Draft i.e. it is not yet an Internet Standard and hence is supported by almost all modern web browsers but disabled by default.
Let’s briefly look at the history of HTTP
HTTP was initially developed by Tim Berners Lee and his team at the CERN Laboratory, in the early 1990s with the earliest version being called HTTP/0.9. Then HTTP/1.0 was introduced with the main feature of HTTP headers, which supported metadata transmission for both request and responses. Few months after HTTP/1.0 was introduced HTTP/1.1 was also introduced, which is considered as the first standardized HTTP version, which had many new features that provided more flexibility and control in transmitting data, such as reuse of connection to save loading time, allowing multiple requests to be send without having to wait for previous request to be fully recieved, enabling more control over type, encoding,language of the content transmitted etc.Later on Secure Socket Layer(SSL) and its successor Transport Layer Security(TLS) protocol was also introduced on top of TCP/IP stack which lead to HTTPS(secure), for security over information of data exchanged between client and server. TLS was introduced in 1999 by the IETF. HTTP/1.1 has undergone few revisions over the years and hence is very stable and is still used by about 30% of the websites on the World Wide Web.
Then in 2015, HTTP/2 was introduced by the IETF, which used the SPDY protocol developed by Google for improving the web page latency. The major difference between HTTP/1.1 and HTTP/2 was that the latter send messages in binary format through a Binary Framing Layer within the Application layer of the OSI stack, as opposed to sending requests and responses as text data in HTTP/1.1.
Another improvement in HTTP/2 was solving the inefficient use of TCP connections. HTTP/1.1 had several parallel TCP connections made for each request/response. This led to a problem called the HTTP Head of Line Blocking(HOLB) which is due to the fact that a client can have only around 6 connections per hostname,so since the TCP connections were limited, if there were several hundred requests it could get delayed if one of the ‘head of the line’ requests were slow. Another solution implemented was to use a ‘keep-alive’ connection method for reusing a TCP connection inorder to reduce the latency of creating new TCP connections and the initial slow start period. But it only allowed a single request/response exchange at any given time. Inorder to overcome this, HTTP/2 used something called ‘streams’ that allowed concurrent,bi-directional multiplexing of requests thereby reusing the same TCP connection and transmit data in streams.
So this solved the issue of HTTP HOLB, but only partially. Suppose there was some packet loss in one of the the stream, due to network congestion, the TCP is not sure if the sending the rest of the unaffected data will be processed properly by the receiver, so its resends that stream and the rest of the streams will have to wait.This causes some latency, and this is where HTTP/3 offers a solution. Instead of using the TCP protocol which was used until now, it is completely replaced by UDP. The advantage of this is UDP will use the same principle of re-using a single connection as in HTTP/2 but each request/response can be sent as separate streams, which means even if data loss happens in a particular stream, the other streams don’t get affected and are transmitted successfully, hence solving the HOLB in HTTP/2. It also ensures security by using the TLS protocol,but it is faster than TCP-TLS as the UDP completes the initial handshake in one exchange as compared to the 3-message exchange in TCP.
If you would like to know more about our services regarding HTTP3, click here.
Disclaimer: The opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Dexlock.