HTTP/3: the next Hypertext Transfer Protocol explained simply

HTTP/3 is the newest member of the HTTP protocol family and is meant to replace its pre­de­cessors HTTP/1, HTTP/2, and HTTP over QUIC. HTTP/3 is still being developed, but it is already supported by Google Chrome, Microsoft Edge, Firefox, and, since April 2020, also by Safari.

The third version of the HTTP standard was ori­gin­ally born as "HTTP over QUIC" and was based on UDP as an ex­per­i­ment­al protocol. Initially, HTTP over QUIC was con­sidered a potential successor to HTTP/2, and since January 2020, the project has of­fi­cially been known as HTTP/3. It remains to be seen how quickly the new standard can assert itself. In any case, HTTP/3 promises shorter loading times and more security thanks to UDP-supported data trans­mis­sion. However, if you consider that, for example, HTTP/2 has been supported by 80 percent of all browsers since its release in 2015, but its use by providers is still pro­gress­ing slowly, an immediate boost in HTTP/3 support is not to be expected.

In November 2018, just three years after the in­tro­duc­tion of the HTTP/2 standard, the Internet En­gin­eer­ing Task Force (IETF) published the new hypertext transfer protocol standard HTTP/3. But the IETF did not reinvent the Hypertext Transfer Protocol with HTTP/3: It only re­cog­nised the signs of the times and designed a web protocol that offers faster data trans­mis­sion, more security, and more effective con­nec­tions. As early as 2012, Google developed the actual successor to HTTP/2, called QUIC (Quick UDP Internet Con­nec­tions), and im­ple­men­ted it as HTTP over QUIC in numerous products.

However, HTTP/3 now combines the ad­vant­ages of the existing transfer protocols HTTP/2 and HTTP over QUIC in one standard for faster and more stable data trans­mis­sion. According to the plan, HTTP/3 is to replace the TCP-based HTTP/2 with the QUIC or UDP-based approach.

To un­der­stand what HTTP/3 involves, you first need to un­der­stand the functions of QUIC, UDP, and HTTP/2. HTTP/3 is basically an amalgam of these com­pon­ents. The name HTTP over QUIC already indicates that the data transfer takes place over UDP instead of over TCP.

HTTP/2 uses TCP which is the most common trans­mis­sion protocol on the internet. TCP processes con­nec­tions via multi-level hand­shakes and transmits data packets chro­no­lo­gic­ally. TCP does not resume trans­mis­sion until a packet has been suc­cess­fully trans­mit­ted. The trans­mis­sion is secured via Acks, meaning order and delivery con­firm­a­tions and test numbers. Data trans­mit­ted via TCP contains a header with para­met­ers that help sender processes to connect with the re­cip­i­ent's peer processes.

TCP is very reliable in terms of complete data trans­mis­sion, but is as­so­ci­ated with data con­ges­tion and loading times, since all trans­mis­sions stop until a lost data packet has been suc­cess­fully trans­mit­ted. With HTTP/2, the internet protocol family is reaching its limits, as data trans­mis­sion cannot be ac­cel­er­ated without new protocols.

Google, therefore, pro­act­ively developed its own transfer protocol QUIC. QUIC cir­cum­vents TCP load con­ges­tion by using datagram-based and con­nec­tion­less UDP trans­mis­sion. UDP works like TCP on the transport layer, but foregoes receiver-sender con­firm­a­tions. Other streams do not have to wait for the previous one to transmit. Round trips between client and server are sig­ni­fic­antly shortened. The IETF re­cog­nised the ad­vant­ages of the new protocol and in­tro­duced it in 2018 as the HTTP/2 successor version HTTP over QUIC.

In principle, the HTTP transport protocol remains the same. It also consists of a header and body, and uses verbs, cookies, and caching. The dif­fer­ence is in the type of data trans­mis­sion and the presence of in­teg­rated en­cryp­tion.

Running the HTTP/2 protocol over QUIC required specific func­tion­al ad­just­ments, which, via the ex­per­i­ment­al HTTP over QUIC, led to the emergence of HTTP/3.

The most important new feature of the third edition of HTTP is the exclusive use of HTTPS URLs. Any older, unsecured URL is marked as not secure or not encrypted. By using QUIC and UDP, HTTP/3 bypasses the step of TSL en­cryp­tion at the TCP level and auto­mat­ic­ally uses TLS 1.3 en­cryp­tion. HTTP/3 can, therefore, only be used if en­cryp­tion exists.

Other new features are a constant con­nec­tion if the network changes during the transfer (on the client or server side), a sig­ni­fic­antly reduced number of data packets, since packet transfer runs over parallel streams, and a "forward error cor­rec­tion," meaning an error cor­rec­tion that is already done at the QUIC level.

The ad­vant­ages of HTTP/3 are better trans­mis­sion speed, shorter loading times, and a more stable con­nec­tion. Building on UDP, HTTP/3 bypasses the weak points of TCP and uses all the ad­vant­ages of HTTP/2 and HTTP over QUIC.

While HTTP/2 uses mul­ti­plex­ing, meaning the sim­ul­tan­eous down­load­ing of data, the second HTTP version still suffers from head-of-line blocking. These are digital bot­tle­necks that ensure that all streams stop when a packet is lost on a stream. Through the use of UDP, HTTP/3 does not wait for suc­cess­ful trans­mis­sion, but continues the loading process.

HTTP/3 does not use in­tro­duct­ory hand­shakes to check the security of a con­nec­tion. Instead of sub­mit­ting security inquiries to the higher-level TLS layer, en­cryp­tion takes place directly via the transfer protocol. HTTP/3 reduces the round trip time when es­tab­lish­ing a con­nec­tion from two passes to only one.

HTTP/3 is no longer bound to IP addresses for a suc­cess­ful download, but uses in­di­vidu­al con­nec­tion IDs, which enable constant down­load­ing even when changing networks.

Es­pe­cially for mobile phone users, HTTP/3 should enable more com­fort­able surfing on a more stable, more flexible, and faster con­nec­tion.

Below is a brief summary of the sim­il­ar­it­ies and dif­fer­ences to be expected when comparing HTTP/2 and HTTP/3:

Dif­fer­ences:

• In contrast to HTTP/2, HTTP/3 builds on UDP instead of TCP.
• Through in­teg­rated TLS 1.3 en­cryp­tion, HTTP/3 foregoes an ad­di­tion­al en­cryp­tion request (hand­shakes) at the TLS level, and thus avoids un­ne­ces­sary security queries.
• In contrast to HTTP/2, HTTP/3 only supports encrypted con­nec­tions due to the in­teg­rated TSL 1.3 en­cryp­tion.

Sim­il­ar­it­ies:

• Both protocols use header com­pres­sion, but HTTP/3 uses QPack to resolve HTTP/2 HPAck com­pres­sion, which is tied to a packet order.
• Like HTTP/2 Server Pushes, HTTP/3 supports the ac­cel­er­ated sending of CSS and JavaS­cript data that a browser requires to display a page in any case.
• Both protocols use request/response mul­ti­plex­ing, meaning the parallel streaming of data from different resources.
• With both protocols, stream pri­or­it­isa­tion ensures that page content is loaded with priority, without waiting for further requests to be completed.

Many critics of HTTP/3 point out that the third version comes too early after the HTTP/2 protocol, and that UDP is regarded scep­tic­ally as a network protocol. In addition, users in par­tic­u­lar benefit from the new HTTP protocol. Providers, on the other hand, face a number of chal­lenges when switching from TCP and TLS to UDP and QUIC.

Since security checks and en­cryp­tion no longer take place via TLS, but directly via UDP – and UDP is meant to deliver as many packets as quickly as possible – providers fear that data traffic will no longer be thor­oughly examined due to the lack of TLS au­then­tic­a­tion. Ap­plic­a­tion and data security is therefore the central point of criticism from internet providers. Thanks to clear request-response reg­u­la­tion, TCP was con­sidered a reliable and con­nec­tion-oriented protocol. Since QUIC takes care of many in­ter­me­di­ate steps itself, there are fears that the control options of providers will be limited by HTTP/3, and that more malware could be in­tro­duced into the data stream.

Since the in­creas­ing range of media data, such as images, videos, and other social media elements, requires faster data transfers, it remains in the interests of users to hope that there will soon be movement in the internet protocol family, and that providers can keep up with the ever-faster changing internet.