HTTP/3 - new version of the protocol

What is HTTP?

HTTP (Hypertext Transfer Protocol) is a universal hypertext transfer protocol. Absolutely all text data on all sites on the web is transmitted via HTTP.

More than thirty years ago was released version HTTP/0.9. It used only the GET-method and had no service headers. In May 1996 came HTTP/1.0. This version included new methods, headers, and caching.

HTTP/1.1 was introduced three years later in 1999. The protocol was augmented with keep-alive, and made a major and significant change that affected the entire development of the web - the Host header. Thanks to this, we can now allow for shared hosting, and place multiple domains on the same IP.

In February 2015, a new protocol standard came out - HTTP/2, which was based on the application layer protocol for web content transfer SPDY. The HTTP/2 protocol became binary, header compression (HPACK), multiplexing and resource prioritization were introduced, as well as the option to cancel downloads and Server Push. The multiplexing feature made it possible to send multiple files at once.

Since the release of HTTP/2 all its users expected significant changes in the speed of sites, but in practice it turned out that most of the protocol innovations were not made quite correctly. Management of threads and priorities, as well as Server Push technology for sending resources to clients were not as efficient and productive as the developers wanted.

What's the difference between HTTP/3 and the previous protocols HTTP/1.1 and HTTP/2?

The HTTP/2 protocol was developed with the goal of maximizing downloads of web resources, primarily related to the visual layout of the site. The HTTP/3 protocol has significantly advanced in this direction - it establishes a connection between the server and the client even faster through the QUIC protocol. The essence of the latter is to combine transport and cryptographic "handshakes" into one.
As a result, we save the cycle of reception-transmission due to which the connection is established more quickly and the download speed of the site elements increases.

The difference between HTTP/3 and the previous HTTP/1.1 and HTTP/2 versions?

HTTP/1.1 and HTTP/2 protocols use a TCP connection, while HTTP/3 works with the QUIC protocol which uses a UDP connection.

What exactly is the difference between the two?

TCP requires a confirmation of delivery, namely a response from the client to whom the data packet is delivered. To that end, a connection must be established in advance.
For UDP there is no need to be connected in advance and data packets are delivered many times faster.
Recently, the TCP protocol has been virtually unchanged. We have a significant increase in data transfer rate at the physical level, but the stability of the connection this time has not added. In search of an alternative the developers have stopped the attention on UDP. To guarantee and optimize the packets delivery the TCP uses lots of parameters, while UDP only involves the destination and the receiving ports, data length and checksum. UDP doesn't require a "handshake" to establish a connection and doesn't have the head-of-line effect mentioned below. In other words, it is an easier and faster protocol compared to TCP.


When using HTTP/1.1, a separate connection is required for each site element. The multiplexing method in HTTP/2 allows all site elements to be downloaded with just one TCP connection between the browser and the server.
HTTP/3 also uses a multiplexing method using the UDP protocol for even faster site loading speeds. It sends multiple streams of data simultaneously to compensate for streams that were lost on the way to the client.


In HTTP/2, compared to HTTP/1.1, page element headers are sent compressed. This is to allow the network link to accommodate auxiliary information during transmission.

In HTTP/3, for even more optimization, QUIC uses simplified headers and specialized small packets to transmit additional information.
Greater security for users

HTTP/3 has done away with the definition of plaintext and built the TLS security protocol directly into QUIC, so that the data is always encrypted. Data interception in this case is difficult and there is almost no chance of doing so.
Built-in encryption also speeds up HTTP/3 itself. In normal HTTPS, the three-way TCP handshake has to end at the transport layer, and happens before any real data is sent between the client and the server. QUIC, on the other hand, combines the two handshakes so that they occur simultaneously. The client and server confirm that the connection is open and simultaneously generate TLS encryption keys.


A significant increase in site download speed for users is achieved by prioritizing content downloads. A separate thread exists with its own priority, so in the case of a long page, the top fragment will be loaded first.

Packet loss

One of the current problems is Packet Loss. 3G, 4G, LTE wireless technologies are more often used on the street, where there are signal re-reflections, which leads to regular packet loss.  In addition, there is no guarantee that packets sent in a certain order will arrive that way - they can swap places during the reception phase.
Another problem with wireless transmissions is the random delay between packets. Because of these delays the quality of the connection suffers, and it is possible that the client does not know for sure if a packet was received and therefore the data is requested again.
All this leads to such an unpleasant phenomenon as head-of-line blocking.

For example, we send some data to the TCP channel, and if one packet is lost, we receive nothing on the output. In this case TCP either queries the packet or some time passes and the data is sent again. However, until the data is retrieved, we cannot access the files already in the buffer on our computer.

The head-of-line problem is solved in QUIC in the following way. Unlike TCP, where file transfers are one thread, QUIC uses separate threads. The loss of a single packet in TCP makes the whole thread useless and discarded. In QUIC, if an individual packet is lost, we still get a number of successful threads to work with (and one incomplete thread that can be re-requested separately).

HTTP/3 efficiency

HTTP/3 is noticeably faster and allows you to use the full width of the communication channel. The updated protocol has less service information and, consequently, the connection is faster. This is well noticeable when transferring a large number of small files. Example: Twitch, Youtube. The connection is more stable and does not break.  Downloading files via Wifi and mobile network will continue when reconnecting.

There are also disadvantages, since the entire implementation of the protocol is not done at the kernel, hardware and network level, but at the User Space level. It is vulnerable to DDOS-attacks and flood attacks.

All of these methods can significantly save network and server resources, as well as eliminate delays required when establishing connections when working with sites.
  • 28
    August 2022 г