Hypertext Transfer Protocol or HTTP is used to exchange data on the world wide web or the internet as we call it.
From its advent, HTTP was always associated with a number next to it, denoting the version. The most commonly used version is 1.1 and then came 2.0 but the most recent version which boasts significant speed and performance improvement is HTTP/3. In this article, we will explore a few topics related to the advent of HTTP and the improvements that were made later on.
Topics covered
What is HTTP/1.1? Was it the first version of HTTP?
What changes were made in HTTP/2?
What changes would be part of HTTP/3?
In a previous article, we discussed the basics of HTTP and the TCP/IP model. It’s a short and interesting read to quickly brush up on HTTP basics.
What is HTTP/1.1? Was it the first version of HTTP?
1.1 was not the first released version of HTTP even though that was the most adapted one. HTTP 0.9 and 1.0 were released before 1.1 and posed a serious challenge. The connection established for communication would get terminated immediately after the response was sent back to the client.
This issue was later fixed in 1.1 when the connection was kept alive for multiple requests and responses. As a result of this, multiple requests were made possible to be sent over HTTP to the server.
The biggest challenge with HTTP/1.1 was still with respect to the head-of-line blocking problem.
What is the head-of-line blocking problem?
HTTP 1.1 requires the responses in order.
If request one is awaiting a response that is either delayed or lost then request 2 will get blocked. This is a head-of-line blocking problem.
What changes were made in HTTP/2?
HTTP/2 resolved the above-mentioned line of blocking problem by multiplexing requests over the same TCP connection. Remember HTTP is an application-level protocol that sits above the transport layer in both OSI and TCP/IP models.
The solution provided by HTTP/2 to resolve the head-of-line blocking issue was introduced in the application layer. As a result, the head of the line issue was not fully addressed as at the transport layer TCP performs an error check and that could again result in congestion if one data packet is delayed or missed.
Another capability of HTTP/2 is that a large number of requests can be made using one TCP connection. In the previous versions, only a limited number of connections were possible.
Security is also embedded into HTTP/2 by requiring all connections to use TLS.
What changes would be part of HTTP/3?
Both HTTP/1.1 and HTTP/2 followed the TCP/IP model but not HTTP/3.
To address the head of line blocking introduced by using TCP protocol, HTTP/3 adopted UDP.
UDP is a connectionless protocol which makes it fire and forget protocol. Unlike TCP, which requires a handshake to establish connection and acknowledgment for data received, UDP sends the data packet to the destination and forgets about it. This addresses the speed concern that prevailed in the previous HTTP versions.
By using UDP alone, we would have lost the biggest benefit that TCP offers- fault tolerance. As most applications require reliable transmission of data, fault tolerance is a required feature in communication.
To address this issue, the HTTP/3 model alters the existing TCP/IP and OSI models by introducing QUIC in the application layer.
QUIC provides the fault tolerance to HTTP that UDP cannot provide. The UDP / QUIC combination thus provides the speed and fault tolerance that's needed for internet communications.
Coming back to the original question — Why did HTTP drop TCP? Because of the need for speed. UDP provides the speed that TCP cannot and QUIC ensures fault tolerance that UDP cannot provide otherwise.
Conclusion
All major browsers support HTTP/3 as of today but server-side adoption is yet to pick up. Facebook and Google servers are some early adopters of the HTTP/3 protocol. More servers are expected to adopt this protocol in the coming years.