Azure Application Gateway now supports HTTP/3 QUIC. As part of private preview, Application Gateway users can create HTTP/3 enabled Listeners which can support either of HTTP/1.1 or HTTP/2 along with HTTP/3.
Note: HTTP/3, if enabled on one listener, will be available on that listener only.
If some of your clients do not support HTTP/3, there’s no panic. They will still be able to communicate with HTTP/3 enabled listeners using previous HTTP versions.
Why should HTTP/3 with Application Gateway be used?
HTTP/3 is the latest version of the Hypertext Transfer Protocol built on the top of QUIC which operates over UDP. It represents a significant leap forward in terms of user experience, efficiency, and security.
Here are some compelling reasons why migrating to HTTP/3 could greatly benefit your organization:
- Faster Web Page Loading (~200ms advantage): If you run a website or web application, implementing HTTP/3 can lead to faster page load times and improved user experiences. HTTP/3's reduced connection establishment latency and multiplexing capabilities help deliver resources more efficiently. Table below shows latency numbers of different HTTP versions.
|
|
HTTPS (TCP+TLS) |
QUIC 1-RTT |
QUIC 0-RTT* |
|
First time connection |
300ms |
100ms |
100ms |
|
Repeat Connection |
200ms |
50ms |
0ms |
*0-RTT comes with its share of security risks and is not part of the private preview
- Enhanced Web Application Performance: Applications that make use of multiple resources, like images, scripts, and stylesheets, can benefit from HTTP/3's multiplexing and concurrent stream support.
- Mobile Applications: If you develop mobile apps, integrating HTTP/3 can enhance data transfer speed and responsiveness, which is especially important on mobile networks where latency can be higher.
- Reducing HOL Blocking: HTTP/3's use of QUIC helps mitigate head-of-line blocking, where the delay of one resource can block the delivery of others. This is especially advantageous for applications that require efficient resource loading.
- Security: HTTP/3's integration with QUIC provides improved security features by design, reducing the risk of certain types of attacks compared to previous versions of HTTP.
Presently, 26.5% of the internet traffic is on HTTP/3 and there has been a steady increase in the adoption compared to HTTP/2 which has seen a decreasing trend (by ~10% in the last 12 months) owing to some of its demerits (explained in the sections later).
How should HTTP/3 with Application Gateway be enabled?
- Prerequisite: You have an existing Application Gateway resource on standard_v2 SKU only.
- Please reach out to us @ quicforappgw@microsoft.com with the Resource URI on which you want the HTTP/3 feature enabled and we'll take you along with the next steps.
What all HTTP/3 features are supported in private preview?
- HTTP/3 will be supported only in the front leg of the connection and backends will continue to be HTTP1.1.
- Application Gateway will support client-initiated connection migration (explained below)
- Application Gateway will support PMTU discovery.
- Application Gateway can advertise support for HTTP/3 via alt-svc header as part of HTTP1/2 response. (Image below explains the flow)
What is HTTP/3 & QUIC?
TCP (Transmission Control Protocol) (RFC793) has been the most widely used transport layer protocol since its inception. But, with the advent of more real time applications, the evolution of the edge, and an ever increasing need to reduce latency and congestion, using TCP is becoming untenable. UDP (User Datagram Protocol) (RFC768) was always seen as an alternative to TCP especially in instances where connectionless-less-reliable transmission was okey-dokey! But UDP suffered with the implementation of congestion control.
TLS (Transport Layer Security) (RFC8446) adds another layer over TCP after the 3-way handshake for TLS negotiation to establish session key and session data encryption. Though the combination provides reliability and security, increased connection establishment has made application developers smirk than smile.
QUIC (Quick UDP Internet Connections) (RFC9000) attempts to bridge these UDP gaps by inducing the TCP niceties and attempts to reduce the TCP ossification in the network. Put in brief, TCP encapsulated and encrypted in a UDP payload is QUIC. It appears like a bidirectional concealed UDP packet sequence to the external network. To the endpoints, it provides an advantage over TCP by deliberately concealing the transport parameters from the network and by shifting the responsibility of the flow control and the encryption service to the application layer from the transport layer.
Pre-HTTP/3 protocols:
HTTP/1.1 and HTTP/2 are done over TCP.
HTTP/1.x versions have slow response times and never satisfy faster-load-times hungry webpages. HTTP/1.1, being a textual protocol, does a below average job in resource prioritization by transmitting the request and response headers as plain text. Without multiplexing capabilities, network requests are served in an ordered and blocking manner. With this approach, HTTP/1.1 suffers from HTTP Head of Line (HOL) blocking where the client waits for the previous requests to be serviced before sending another resulting in the subsequent blocked requests on a single TCP connection. Imagine a webpage needing multiple resources to load (Images, CSS, HTML files, Js files etc) the complete page!
To overcome all these HTTP/1.1 limitations, HTTP/2 was brought in. It introduced header field compression by binary framing layer and creating a stream for communication reducing the amount of data in the header. Concurrent exchanges on the same connection by interleaving request and response messages and efficient coding of HTTP header fields. Prioritization of requests allowed more important requests complete quicker thus improving performance.
HTTP/2 protocol communication involved binary encoded frames that carried data mapped to messages (request/response) in a stream which contained identifiers and priority information multiplexed in a single TCP connection. Figure-1 shows the flow of protocol communication in HTTP/2.
All these enhancements mean lesser no. of TCP connections, longer-lived connections, less competition with other flows leading to better network utilization.
By allowing multiple HTTP requests over a single TCP connection, HTTP/2 resolved HTTP HOL blocking issue but created the TCP HOL blocking issue. In the event of a network blip like network congestion, unavailability of network or change of a cell in a mobile network which might lead to loss of a packet throwing a TCP connection into a tizzy as it ensures that the order of packets transmitted and received are same. A loss of one packet will mean everything stops until the lost packet is retransmitted. In the case of multiple requests multiplexed onto a single TCP connection, all the requests are blocked although the “lost packet” in real impacts only one request.
With increasing no. of mobile friendly apps, increase in the usage of cellular networks, and, in countries with not so good networks and high chances of network blips, such an issue can cause interruption to services.
Enter QUIC based HTTP/3:
HTTP/3 is based on QUIC. It is designed to be faster than TCP with lower latency, lesser overhead during connection establishment and quicker data transfer over the established connection. QUIC is based on UDP and offers 0-RTT and 1-RTT handshakes compared to 3-way handshakes of TCP. This is possible as it supports additional streams.
HTTP/3 retains all the niceties of HTTP/2 like server push mechanism, multiplexing of requests over single connection via streams, resource prioritization. It ensures the issue of TCP HOL blocking is resolved. “Lost packets” along the way will not interrupt the data transfer. QUIC sees to it that transferring other data is uninterrupted while the issue of the “lost packet” is being resolved.
QUIC based HTTP/3 features and use-cases:
Faster connection establishment
The regular 3-way handshake gives way to the 1-RTT and 0-RTT handshakes based on QUIC which will lead to a drop in the connection establishment by 66%-95%.
The 1-RTT and the 0-RTT connection establishment helps in the improvement of page load times in web browsing immensely. Instant messaging applications, voice assistants, transactional systems (financial transactions, online purchases) benefit from quick connection establishment. In these scenarios, 1-RTT connection establishment can make a noticeable difference in reducing initial delays and enhancing overall user satisfaction.
Financial institutions will find a wide range of benefits due the low latency with their mobile apps, online banking portals, provide customers with real-time notifications, effective API integration and many such use cases.
Independent HTTP Streams (no TCP HOL Blocking)
TCP HOL blocking occurs when a single delayed or lost packet holds up the delivery of subsequent packets, impacting overall communication efficiency. Avoiding TCP HOL blocking can offer significant advantages in real-life scenarios where minimizing latency, improving responsiveness, and optimizing data transmission are crucial. Removing unnecessary bottlenecks and making communication smoother results in happy customers.
Web browsing without HOL blocking will help in fetching multiple resources in the page leading to quicker page loading times and thus providing the users with a rich browsing experience.
Without HOL blocking, messages in an instant messaging application are delivered promptly without being held up providing the end user a fluid experience.
IoT devices that transmit sensor data and updates will be able to deliver all the necessary data without being delayed by a single lost or slow packet, ensuring timely and accurate reporting.
Avoiding HOL blocking in financial transactions ensures that data related to transactions is transmitted without unnecessary delays, contributing to real-time processing and confirmations without which CSAT is impacted vastly.
Connection Migration
Customers are always on the move. Especially with the ever-improving cellular networks, they are seldom stuck to a single network or a cell in the network. This nature of being on the move constantly will mean constant registration with the network and establishing connections frequently and deriving data from different servers. In the traditional HTTP and TCP method, this would lead to several drops in the connectivity. But that is a thing of the past with QUIC and HTTP/3.
The QUIC-HTTP/3 combine provides users with a Connection Migration feature. During the QUIC connection establishment, the server provides the client with a set of Connection IDs (CID) as part of the QUIC header. Using this CID, the client can retain an existing connection despite moving networks and attaining new IP addresses.
With the help of the connection migration, uninterrupted web browsing would be possible for users. IoT devices’ that need to maintain continuous communication will find the connection migration extremely useful. Users moving from private to public WiFi networks at malls, airports and other public places will be provided with seamless app experience.
How to sign up?
https://forms.office.com/r/iGeYgrmydA