Google Cloud Platform Blog: Full Speed Ahead with HTTP/2 on Google Cloud Platform

Full Speed Ahead with HTTP/2 on Google Cloud Platform

2015年10月8日星期四

Performance is a feature. For many Google applications it is the feature that makes everything else possible—instant text and voice search, directions, translations, and more. The platforms and infrastructure teams at Google are always on the leading edge of development and deployment of new performance best practices. These best practices, in turn, benefit your applications running on Google Cloud Platform.
One great example of Cloud Platform leveraging technology improvements in the Google infrastructure is support for SPDY and HTTP/2. The Google Chrome team began experimenting with SPDY back in 2009 and Google servers were the first to support it. SPDY proved to deliver significant performance benefits and helped shape the development of the HTTP/2 protocol. Now, with HTTP/2 finalized (RFC 7540, RFC 7541) and rapidly gaining client adoption, Google servers are, once again, leading the way by being among the first to offer full HTTP/2 support.
HTTP/2 on Google Cloud Platform We’re not breaking any news here, because Google Cloud Platform support for SPDY has been enabled for many years, and support for its successor (HTTP/2) was enabled earlier this year. Many performance-conscious developers are already leveraging the performance benefits of the HTTP/2 protocol in their applications, and so should you! Here’s what you need to know:

Your application must run over HTTPS. Support for the HTTP/2 protocol is automatically negotiated as part of the TLS handshake via ALPN.

The server terminating the secure HTTPS connection must support ALPN and HTTP/2 protocols. If either side does not support the new HTTP/2 protocol then they fallback to HTTP/1.1.

If your application is already running over HTTPS, and the secure session is terminated by one of Google servers, then—good news—you’re already HTTP/2 enabled! Let’s take a peek under the hood to see how this works.

Google Cloud Storage Consider a scenario in which you upload a file into Google Cloud Storage and get an HTTPS link for the resource, which you then reference or share with others. When the resource is fetched, the client and Google server negotiate the TLS session and HTTP/2 protocol support. If the client supports HTTP/2 then the Google servers automatically selects it; otherwise the Google servers fallback to HTTP/1.1. In short, just upload a file and provide an HTTPS link to it and your job is done.
Google App Engine Both in its original incarnation and Managed VM configurations, Google App Engine servers are responsible for negotiating and terminating the TLS tunnel. As long as your application is being served over HTTPS, the Google servers automatically negotiate HTTP/2 on your behalf.
Each HTTP/2 stream is then translated into an HTTP/1.1 request and routed to your application. As a result, no modifications are required within your application to enable HTTP/2. Simply direct your traffic through HTTPS and all capable visitors will be automatically served over HTTP/2.
Google Compute Engine and Google Container Engine If you’re running a virtual machine, or an entire cluster, via Google Compute Engine or Google Container Engine, then you have multiple options for where and how the inbound connections are routed:

You can expose the virtual instance directly, in which case you must set up and manage the necessary infrastructure to terminate the TLS tunnel, negotiate HTTP/2, and process the HTTP/2 session—see the HTTP/2 wiki for a list of open source servers.

You can use a network load balancer to distribute inbound TCP connections to one of multiple servers, which then have to terminate the TLS tunnel and negotiate HTTP/2—the same as with exposing the virtual instance directly.

You can use an HTTPS load balancer, which terminates the TLS tunnel and negotiate HTTP/2 on your behalf. The load balancer translates inbound HTTP/2 streams into HTTP/1.1 requests and forwards them to one of your servers—same as Google App Engine. This is the quickest and easiest way to enable HTTP/2 for your Compute/Container-powered application.

There shouldn’t be any surprises with any of the above. To enable HTTP/2, you need to enable HTTPS, and then either let one of the Google servers terminate it and do all the heavy lifting on your behalf, or route the connection to one of your HTTP/2 capable servers.
Note: There is much more to be said about the benefits and optimization strategies for HTTP/2—it’s a big and important upgrade—but that’s outside of scope of this post. If you’re curious, however, check out the free chapters on HTTP/2 and HTTP/2 optimization strategies in High Performance Browser Networking (O’Reilly). A QUIC peek into the future The Google Chrome and platform teams continue to innovate by experimenting with QUIC, a UDP-based transport for HTTP/2, which enables faster 0-RTT secure handshakes, improved congestion control, loss recovery, and other mechanisms that promise to further improve performance:
The data shows that 75% percent of connections can take advantage of QUIC’s zero-round-trip feature. QUIC outshines TCP under poor network conditions, shaving a full second off the Google Search page load time for the slowest 1% of connections. These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.
- from A QUIC update on Google’s experimental transport
And speaking of being on the leading edge of performance—Many applications powered by App Engine are already speaking QUIC to capable Chrome clients, and we’re hard at work to bring QUIC to all other products as well. As with HTTP/2, the Google servers terminate the UDP flow and translate the QUIC protocol to HTTP/1.1 requests, enabling a transparent performance upgrade to millions of existing applications running on Google Cloud Platform.
Tip: To quickly and easily see what protocol is negotiated, install the HTTP/2 indicator extension for Google Chrome. A blue bolt indicates HTTP/2; a red bolt indicates QUIC. - Posted by Mark Mandel, Google Cloud Platform Developer Advocate and Ilya Grigorik, Internet Plumber.

Google Cloud Platform Blog

Full Speed Ahead with HTTP/2 on Google Cloud Platform

Free Trial

GCP Blogs

Popular Posts

标签

Feed

Subscribe by email

Company-wide

Products

Developers