How HTTP communication is evolving

HTTP is used to communicate with the server when visiting a website. HTTP/3 is this new version of HTTP. How will the HTTP communication problem so far be solved in HTTP/3?

The world’s first webpage appeared in late 1990, and HTTP/0.9 appeared in 1991, the following year. At the time, it was a simple thing to simply download a specific document from a server. In 1996, HTTP/1.0, which updated the expanded function, such as responding to uploading, is formulated. This is the prototype of today’s HTTP communication. In HTTP/1.0, it is a specification to create a new TCP connection on every request, so the handshake delay becomes an issue.

In order to solve this problem, HTTP/1.0 is released, and HTTP/1.1, which is modified half a year later, is formulated. HTTP/1.1 introduces keepalive, allowing multiple requests to be handled as a single connection. HTTP/1.1 has been supporting web communication for a long time, and although the next version, HTTP/2, became an official specification in 2015, there are many sites that communicate with HTTP/1.1 even after the establishment of HTTP/2.

HTTP/1.1 has been around for over 20 years since its advent, but in the meantime, websites have evolved significantly. The resources required to display images, JavaScript, and CSS have increased significantly compared to the time when HTTP/1.1 appeared. Therefore, the browser can easily view the web site and it is necessary to make many connections at the same time. However, in HTTP/1.1, there is only one request that can be made at a time. There was a limitation that in order to perform multiple requests, you have to wait for the previous request to finish. To make simultaneous connections, I had to make multiple HTTP/1.1 connections.

HTTP/1.1 has the feature of maintaining a connection and allowing multiple resources to be downloaded on a single connection, but establishing multiple HTTP/1.1 connections will result in a handshake on each connection and the original HTTP/1.0 state.

With the advent of HTTP/2 in 2015, multiple resources can be downloaded simultaneously over a single connection. With the advent of HTTP/2, it becomes possible to use a single TCP connection efficiently. But this time, the problem was that this communication was taking place over TCP. TCP is a protocol for transmitting all data in the correct order. When a part of a TCP packet is disconnected from the network, it blocks subsequent packets until the packet is retransmitted. For reasons of organizing requests for other resources into one TCP connection, if a packet loss for a request for a resource occurs, all requests for other resources using the same TCP connection are interrupted.

For this reason, a new protocol called QUIC was developed in HTTP/3 and used instead of TCP. In theory, QUIC is good to make as a transport protocol with TCP and UDP, but to spread a new transport protocol, it takes time and effort to change all current network equipment. For this problem, QUIC is implemented using UDP.

Not only does QUIC flow without blocking multiple requests, but the handshake at the start of communication is also shortening. Until now, TCP or TLS handshake has been performed separately, but if you use QUIC, you can reduce the number of communication with the server by combining connection authentication and encryption.

HTTP/3 connections are only available on Chrome Canary for developers right now, and their servers are limited. However, as it spreads in the future, you will be able to view more comfortable websites. Related information can be found here .