HTTP/3 is the newest member of the HTTP protocol family and is meant to replace its predecessors 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 originally born as "HTTP over QUIC" and was based on UDP as an experimental protocol. Initially, HTTP over QUIC was considered a potential successor to HTTP/2, and since January 2020, the project has officially 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 transmission. 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 progressing slowly, an immediate boost in HTTP/3 support is not to be expected.
In November 2018, just three years after the introduction of the HTTP/2 standard, the Internet Engineering 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 recognized the signs of the times and designed a web protocol that offers faster data transmission, more security, and more effective connections. As early as 2012, Google developed the actual successor to HTTP/2, called QUIC (Quick UDP Internet Connections), and implemented it as HTTP over QUIC in numerous products.
However, HTTP/3 now combines the advantages of the existing transfer protocols HTTP/2 and HTTP over QUIC in one standard for faster and more stable data transmission. According to the plan, HTTP/3 is to replace the TCP-based HTTP/2 with the QUIC or UDP-based approach.
To understand what HTTP/3 involves, you first need to understand the functions of QUIC, UDP, and HTTP/2. HTTP/3 is basically an amalgam of these components. 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 transmission protocol on the internet. TCP processes connections via multi-level handshakes and transmits data packets chronologically. TCP does not resume transmission until a packet has been successfully transmitted. The transmission is secured via Acks, meaning order and delivery confirmations and test numbers. Data transmitted via TCP contains a header with parameters that help sender processes to connect with the recipient's peer processes.
TCP is very reliable in terms of complete data transmission, but is associated with data congestion and loading times, since all transmissions stop until a lost data packet has been successfully transmitted. With HTTP/2, the internet protocol family is reaching its limits, as data transmission cannot be accelerated without new protocols.
Google, therefore, proactively developed its own transfer protocol QUIC. QUIC circumvents TCP load congestion by using datagram-based and connectionless UDP transmission. UDP works like TCP on the transport layer, but foregoes receiver-sender confirmations. Other streams do not have to wait for the previous one to transmit. Round trips between client and server are significantly shortened. The IETF recognized the advantages of the new protocol and introduced 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 difference is in the type of data transmission and the presence of integrated encryption.
Running the HTTP/2 protocol over QUIC required specific functional adjustments, which, via the experimental 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 encryption at the TCP level and automatically uses TLS 1.3 encryption. HTTP/3 can, therefore, only be used if encryption exists.
Other new features are a constant connection if the network changes during the transfer (on the client or server side), a significantly reduced number of data packets, since packet transfer runs over parallel streams, and a "forward error correction," meaning an error correction that is already done at the QUIC level.
The advantages of HTTP/3 are better transmission speed, shorter loading times, and a more stable connection. Building on UDP, HTTP/3 bypasses the weak points of TCP and uses all the advantages of HTTP/2 and HTTP over QUIC.
While HTTP/2 uses multiplexing, meaning the simultaneous downloading of data, the second HTTP version still suffers from head-of-line blocking. These are digital bottlenecks 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 successful transmission, but continues the loading process.
HTTP/3 does not use introductory handshakes to check the security of a connection. Instead of submitting security inquiries to the higher-level TLS layer, encryption takes place directly via the transfer protocol. HTTP/3 reduces the round trip time when establishing a connection from two passes to only one.
HTTP/3 is no longer bound to IP addresses for a successful download, but uses individual connection IDs, which enable constant downloading even when changing networks.
Especially for mobile phone users, HTTP/3 should enable more comfortable surfing on a more stable, more flexible, and faster connection.
Below is a brief summary of the similarities and differences to be expected when comparing HTTP/2 and HTTP/3:
Differences:
Similarities:
For a long time, HTTP/2 was considered an effective and reliable transfer protocol. You can find out how it made connections safer and faster until being replaced by HTTP/3 in our separate article on HTTP/2.
Many critics of HTTP/3 point out that the third version comes too early after the HTTP/2 protocol, and that UDP is regarded skeptically as a network protocol. In addition, users in particular benefit from the new HTTP protocol. Providers, on the other hand, face a number of challenges when switching from TCP and TLS to UDP and QUIC.
Since security checks and encryption 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 thoroughly examined due to the lack of TLS authentication. Application and data security is therefore the central point of criticism from internet providers. Thanks to clear request-response regulation, TCP was considered a reliable and connection-oriented protocol. Since QUIC takes care of many intermediate steps itself, there are fears that the control options of providers will be limited by HTTP/3, and that more malware could be introduced into the data stream.
Since the increasing 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.
404, 302, 503 – short number combinations with great significance. Users encounter server status reports time and time again and if you know how to interpret them you can act accordingly. Knowledge of HTTP codes is even more relevant for website owners. With the right know-how you can vastly improve user experience on your homepage, which will have an effect on the search engine ranking.
The Domain Name System (DNS) is considered “the phone book of the Internet”. You can use it to find the right IP address for each URL. However, the system traditionally works without any encryption. Virtually anyone can listen in when you send a request. Not only is this slightly worrying, but it can also be dangerous. DNS over HTTPS tries to close the decade-old security gap.
SSL and TLS are two encryption protocols that are frequently used in email programs and browsers. Have you ever wondered which one you should choose when you are prompted to pick one when configuring an email client, for example? Here, you will learn what the differences between SSL and TLS are and why only one of them is still viable today.
In addition to the actual data that users see in a browser, a browser and server exchange more information in the background than meets the eye. In this article you will learn what a browser’s request and the server's response in the HTTP request and response headers say, what the HTTP fields mean and how you can read them yourself if you are interested.
Provide powerful and reliable service to your clients with a web hosting package from IONOS.
