HTTP/3: Prepare your network for the most important transport change in decades

The foundation of the internet is the HTTP protocol. The Hypertext Transfer Protocol (HTTP) functions as an application layer to simplify data transfer, resource retrieval, RESTful exchanges, and browser-to-server communication. To authenticate the communicating endpoints and to secure the application data that is passed over the internet, authentication and encryption is mandatory. Hence, HTTPS became the de-facto standard for HTTP communications. The most recent version of the HTTP protocol, HTTP/3, is built on top of HTTP/2. By enhancing user experience, reducing the effects of packet loss without head-of-line blocking, accelerating (HTTPS) handshake process, and enabling encryption by default, HTTP/3 is intended to alleviate some of the performance difficulties inherent with HTTP/2.

QUIC is one of the primary distinctions in HTTP/3. Quick UDP Internet Connections (QUIC), proposed by Google and finally adopted by the IETF as RFC 9000, after various draft versions, serves as the foundation of HTTP/3. According to Cloudflare, QUIC implementation establishes encrypted connections at the transport layer, condensing handshakes into a single step and encrypting the information that is passed between connections.

HTTPS stack: Old vs new

With the various draft versions, HTTP/3 popularity has been slowly increasing, and the most recent data indicates that HTTP/3 is used by around 25.1 percent of all websites (source: https://w3techs.com/technologies/details/ce-http3). As IETF publishes HTTP/3 as RFC (RFC 9114) on June 6, 2022, we can very well assume that it's adoptability will increase over the next few years. With around 80 percent of the network traffic using HTTP (HTTP, HTTPS, HTTP/2 combined), which obviously uses TCP, HTTP/3, natively built on top of UDP, is a major paradigm shift that existing networks, devices, and endpoints need to adopt.

Top challenges with HTTP/3 traffic

As QUIC and therefore HTTP/3 is based on UDP, there will be a widespread impact on infrastructure and architecture. Most security systems are unfamiliar with scrutinizing the content sent on top of UDP. The following summarizes the top challenges for HTTP/3 adoption:

1. Network devices' software that are designed to support QUIC and HTTP/3 is still new and evolving at a rapid pace. All the network devices will be impacted because of the following:
   • Pass through performance - Network devices that have long been optimized for TCP traffic will now need to be optimized for UDP traffic. Also, QUIC's inherent property of encrypting all communications, may need vendors to revisit their published performance numbers.
   • Functionality - Devices need to be HTTP/3 and QUIC aware.
   • Traffic inspection - Devices should be capable of inspecting HTTP/3 data for security purposes.
2. Transit providers between networks (or, in certain cases, even ISPs) can use CGNATs and various content aware middleboxes that generally are hostile to UDP traffic. With all existing HTTP communications over TCP changing to UDP, around 85% of the network traffic (contributed by HTTP) will switch from TCP to UDP. Configuration adjustments in the middleboxes are necessary to unleash the full advantages of QUIC.
3. Activation of QUIC for many server operators is challenging. It is not just toggling a button to enable HTTP/3 support.
4. Large networks like Enterprises are immensely impacted as well. Parameters like performance, security, QoE and scalability needs to benchmarked with QUIC traffic.
5. Full blown client (browser) support and just not an experimental option for the user to enable. With the release of IETF QUIC and HTTP/3 version, it is expected that more clients (browser) will now support QUIC and HTTP/3. Hence Content Delivery Network (CDN) Service Providers need to re-test their service-level agreement (SLA) in this new paradigm.

Validate your networks and devices with HTTP/3

Now that we have a good understanding of how HTTP/3 operates and what its effects are across the network, let us concentrate on validating our network with HTTP/3 traffic. Below are some of the Key Performance Indicators (KPIs):

• Performance benchmarking for HTTP/3 servers and Application Delivery Controllers (ADC), SLB, NGFW, IDS/IPS, proxies and network monitoring devices including maximum connections/sec, transactions/sec, concurrent connections and throughput.
  • Zero-RTT vs 1-RTT performance.
• HTTP/3 latency measurement parameters like Time to establish a QUIC connection, time to first byte (TTFB), time to last byte (TTLB), QUIC connection failures, HTTP failures which translates to the latency in the network needs to be measured.
• Performance benchmarking with different TLS 1.3 ciphers like -
  • AES-GCM, CHACHA-POLY and CCM ciphers.
  • Various EC groups.
  • Both with EC and RSA certificates and keys.
• Security and vulnerability testing by HTTP/3 connection interception and traffic inspection.
• Seamless Connection migration support while switching across networks.

HTTP/3 Test Topologies

HTTP/3 opens different scenarios for testing the traffic initiator, responder, and the devices in between, including various devices and middle boxes. Let's do a high-level overview of the various topologies.

Topology 1: HTTP/3 at both ends with DUT in between

In this topology, we have a DUT between the HTTP/3 client and server (HTTP/3 client, server can be emulated by IxLoad). The DUT is HTTP/3 aware. It can intercept the HTTP/3 traffic.

Test traffic originating from an HTTP/3 client passes through an Application Delivery controller (ADC)/ SLB, NGFW, IDS/IPS, proxies and network monitoring devices, and goes to the HTTP/3 server. IxLoad can simulate both the HTTP/3 client and the HTTP/3 server.

This test can determine the following:

• Analyze the performance and scalability impact on the DUT while for HTTP/3 traffic compared to the traditional HTTP 1.x/2 TCP based traffic.
• Measure the latency and delay in the network for handling HTTP/3 / QUIC connections instead of traditional TCP traffic.
• Observe the resiliency of the DUT for application mixes combined with HTTP, HTTP/2, HTTP/3, and other application mix.
• Cover the DPI engine's performance with HTTP/3 packets, as all modern DUTs can intercept and decrypt the encrypted packets.

Topology 2: HTTP/3 client against HTTP 1.x or 2.0 server (downgrade the HTTP version)

In this topology, we have a DUT between the HTTP/3 client and HTTP/1.x or HTTP/2 server (HTTP client, server can be emulated by IxLoad).

Similar to Topology 1, except that the responder supports HTTP/1.x and/or HTTP/2. The DUT establishes the TCP connection with the responder and sends the HTTP/3 payload over HTTP/1.x or HTTP/2. Additionally, the DUT may choose to send the payload as clear text or encrypted. The response path follows the reverse pattern.

The metrics of the test remains the same as mentioned earlier.

Topology 3: Stream-based Load Balancing

In this topology, the DUT between the HTTP/3 client and HTTP/1.x or HTTP/2 server (HTTP client, server can be emulated by IxLoad) can do stream-based load balancing.

The Load Balancer in between the client and server, may do a stream-based load balancing instead of connection-based. In which case, the Load Balancer sends specific streams to specific servers at the backend. Thus, connections behind the Load Balancer may be over HTTP/1 to facilitate the parallel processing of the requests. The individual responses are collated by the Load Balancer and sent over to the client over HTTP/3.

This test can determine the following:

• Because considerable processing is involved in the Load Balancer, Connection rate, Transaction rate, Throughput, and Concurrent Connections are the key parameters to test.
• Latency parameters like Time to establish QUIC connection, time to first byte (TTFB), and time to last byte (TTLB) between request and responses are also important.

Topology 4: Scalability and performance of HTTP/3 server

The simplest topology in which the HTTP/3 client/server is tested with the other end is mimicked by using IxLoad HTTP/3.

Test traffic originating from an HTTP/3 client hits an HTTP/3 server. This scenario would be useful to benchmark the performance of HTTP/3 servers before making them available into production.

Keysight's IxLoad introduces HTTP/3 over IETF QUIC (RFC 9000)

Keysight's IxLoad provides a comprehensive solution to test HTTP/3, with IxLoad client and IxLoad server, for both functional and performance testing. IxLoad supports fully stateful HTTP/3 traffic.
In IxLoad, HTTP/3 client and server is implemented as a new plugin with GET, PUT, and POST commands along with generic commands like Loop. It can co-exist with other apps like HTTP 1.x/ 2.0, enabling end users to generate a mix of TCP and UDP traffic from the same test port. IxLoad HTTP/3 implementation can be used for both one-arm (simulating either the HTTP/3 client or the HTTP/3 server with IxLoad) or two-arm testing (IxLoad HTTP/3 client and server are the test endpoints).

We will demonstrate a sample configuration where IxLoad can be used for benchmarking CPS (connections per second) performance for an NGFW device as described in Topology 1 earlier.

IxLoad HTTP/3 client configuration

• Add an HTTP3 client activity and HTTP3 server activity.
• Add an HTTP3 command. One HTTP3 command can be treated equivalent to one QUIC connection.
• Configure the Methods (GET/POST/PUT) in a Method Profile for the connection.
• Configure the number of streams as per the required parallelism of HTTP/3 methods that are defined in the Method Profile.
• The HTTP3 client activity sends requests to the DUT, which sends the request to one of the available HTTP/3 servers behind the DUT.

IxLoad server configuration

Configure the IxLoad HTTP/3 server specific settings like Maximum number of configurable streams and web pages.

That completes our configuration!

Result analysis and statistics

IxLoad provides comprehensive set of statistics to help understand and interpret the result of the run, both for HTTP/3 and QUIC. The following are some of the important statistics:

• Has the test objective been achieved? Check the Objectives view.
  • Simulated Users
  • Concurrent Connections
  • Connections/Second
  • Connection Attempts/Second
  • Transactions/Second
  • Throughput
• Number of HTTP/3 requests successful or failed? Check the Transactions view.
  • Requests Sent
  • Requests Successful
  • Requests Failed

All the preceding statistics are available in cumulative and rate-based view.

• How many QUIC packets are exchanged? Check the QUIC Stats view.
  • Packets Sent
  • Packets Received
• QUIC frames exchanged-refer to the QUIC Frames view.
  • Crypto Frames Sent
  • Crypto Frames Received
  • Handshake Done Frames Received
  • Stream Frames Sent
  • Stream Frames Received
  • Application Close Frames Sent
  • Application Close Frames Received
  • Transport Close Frames Sent
  • Transport Close Frames Received
• Latency views
  • Connect Time (µs)
  • Time to First Byte (TTFB) (µs)
  • Time to First Byte (TTLB) (µs)

All these statistics are further supplemented by more granular and per user drill down views.

[Link]

Next Steps

Performance, functionality, and QoE are all key components that need to be validated regardless of the embraced technology, selected network design, or even development phase. During a paradigm shift, getting all these components right is a real balancing act that you can master only through a systematic and robust test strategy and with a trusted partner. Your ability to validate with real-world traffic across the stack - spanning networking protocols, services, applications, and cybersecurity - offers a competitive advantage. That is true whether you are conducting proof of concepts, planning and design validation, or continuously testing into production.

Keysight's network, applications, and security test products ensure that your test results are meaningful and deliver the right insights.

Start testing your devices and networks with HTTP/3 traffic by using the IXLOAD - 9.22 release.

Learn more about how to use IxLoad in https://www.keysight.com/in/en/assets/7019-0052/application-notes/Application-Delivery.pdf.

For more information, visit our website https://www.keysight.com/in/en/products/network-test/protocol-load-test/ixload.html.

For more technical details on QUIC and HTTP/3 please visit our blogs on Road To QUIC and Looking Into QUIC Packets in your Network.