Announcing HTTP/2 and HTTP/3 Residential Network Support

Last week we announced our experimental residential network where we were testing out support for TLS. This week, we're pushing HTTP/2 and HTTP/3 to this network. Simply set your proxy string to beta.residential.pingproxies.com and your scheme to HTTPS and your client will automatically take advantage of these protocols through ALPN

Now, why should you care about these protocols? HTTP/1.1 has been getting the job done for years after all….

Simply put, HTTP/1.1 is not fit for the modern web. Every page loads tens (or even hundreds!) of resources from many different domains and having to form a new connection for every single resource is slow, especially with browsers only allowing a few connections to be open at a time. HTTP/2 and HTTP/3 introduce multiplexing, allowing you to send multiple requests over a single connection, increasing your throughput and concurrency.

HTTP/2 can improve performance by up to 40% in optimised use cases. In situations where HTTP/2 is not optimal, it still won't hurt your performance. It's an entirely cost-free performance boost!

As for HTTP/3, the performance benefits are similar - possibly even greater - but it is harder to use. Very few providers support proxying HTTP/3 - we're one of the first - so there are few clients that support it. Our support here is less for existing use-cases and more to enable our customers to experiment with new ones.

With both protocol versions, our residential network only supports the CONNECT method. In the future, when we roll this out to our datacenter and ISP network, we will support acting as a "man-in-the-middle" along with the CONNECT-IP and CONNECT-UDP methods to allow proxying of arbitrary IP and UDP traffic much like CONNECT does for TCP. This will open the door for tunneling QUIC traffic for example.

Using with CURL

If you want to test HTTP/2 using curl you can use the following command

curl  --proxy-http" -U USER:PASS -x https://beta.residential.pingproxies.com:8306 YOUR-TARGET

Demonstrating HTTP/3 is a lot harder as even CURL does not support CONNECT tunnels via HTTP/3 yet. In the coming days we will release blogs and videos showing how to use HTTP/3 with our network.

Tech Talk

HTTP/2

HTTP/1.1 is still the default protocol of the web. Any client you are using will use HTTP/1.1 by default. As such you need a way to turn your HTTP/1.1 connections into HTTP/2 connections and you have three ways to do this.

1. HTTP/2 Prior Knowledge. Just assume the proxy speaks HTTP/2.
2. HTTP/2 Protocol Upgrade. Ask the proxy if it can speak HTTP/2.
3. ALPN. Ask the proxy if it can speak HTTP/2 whilst performing the TLS handshake.

We support options 1 (prior knowledge) and 3 (ALPN). We deliberately choose not to support a protocol upgrade from a HTTP/1.1 connection for security reasons; HTTP/1.1 upgrades can allow you to upgrade to cleartext HTTP/2 without knowing that you have done so. We believe TLS should be used everywhere and so we wish to encourage you to use it.

You can do cleartext HTTP/2 if you really want, but only if you explicitly opt-in to doing so using prior knowledge.

HTTP/3

HTTP/3 is supported by very few other providers and very few clients. We're using a HTTP/3 library which is still in its infancy and has many rough edges. As such, we expect that you will encounter some issues and we encourage you to report them to our support team. We will endeavour to fix these issues for all customers and push those changes to the upstream library for the wider OSS community to benefit.

Additionally, If you have a legitimate use case for HTTP/3 proxies, we'd be very interested in hearing it and working with you to support it. Reach out to our support team in either of these cases.

In the near future we will support the extensions to HTTP/3 that the MASQUE working group have developed: CONNECT-IP and CONNECT-UDP. We already have patches in development for the big Rust libraries which will add support for CONNECT-UDP across all HTTP versions

We’ve always been committed to continuous innovation, right down to the lowest levels of our stack. This update is a clear example of that commitment, and part of our ongoing effort to stay on the cutting edge of protocol technology.

Over the next few months, we’ll be rolling this support out to our production networks once testing on the residential beta is complete. We’ll share updates as we make progress so you can take advantage of these capabilities as soon as they’re generally available.

Conclusion

Here at Ping we have committed to continuously innovating in all areas of proxying including at the lowest levels of our stack. This announcement is evidence of that and we have many more features to be released in the next few months to further prove this point.

As for these protocols, we hope to have them rolled out to our production network after a month or two of lighter testing on this experimental network. We’ll make sure to inform all of our customers when that happens.