Full Speed Ahead with HTTP/2 on Google Cloud Platform

byUnknown -
0
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:

  1. Your application must run over HTTPS. Support for the HTTP/2 protocol is automatically negotiated as part of the TLS handshake via ALPN.
  2. 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.
HTTP-2 Flowchart - Remove Server Push (v3).png

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:

  1. 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.
  2. 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.
  3. 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.


Tags

You may like these posts

Thank you for reaching out to us. We are happy to receive your opinion and request. If you need advert or sponsored post, We’re excited you’re considering advertising or sponsoring a post on our blog. Your support is what keeps us going. With the current trend, it’s very obvious content marketing is the way to go. Banner advertising and trying to get customers through Google Adwords may get you customers but it has been proven beyond doubt that Content Marketing has more lasting benefits.
We offer majorly two types of advertising:
1. Sponsored Posts: If you are really interested in publishing a sponsored post or a press release, video content, advertorial or any other kind of sponsored post, then you are at the right place.
WHAT KIND OF SPONSORED POSTS DO WE ACCEPT?
Generally, a sponsored post can be any of the following:
Press release
Advertorial
Video content
Article
Interview
This kind of post is usually written to promote you or your business. However, we do prefer posts that naturally flow with the site’s general content. This means we can also promote artists, songs, cosmetic products and things that you love of all products or services.
DURATION & BONUSES
Every sponsored article will remain live on the site as long as this website exists. The duration is indefinite! Again, we will share your post on our social media channels and our email subscribers too will get to read your article. You’re exposing your article to our: Twitter followers, Facebook fans and other social networks.

We will also try as much as possible to optimize your post for search engines as well.

Submission of Materials : Sponsored post should be well written in English language and all materials must be delivered via electronic medium. All sponsored posts must be delivered via electronic version, either on disk or e-mail on Microsoft Word unless otherwise noted.
PRICING
The price largely depends on if you’re writing the content or we’re to do that. But if your are writing the content, it is $60 per article.

2. Banner Advertising: We also offer banner advertising in various sizes and of course, our prices are flexible. you may choose to for the weekly rate or simply buy your desired number of impressions.

Technical Details And Pricing
Banner Size 300 X 250 pixels : Appears on the home page and below all pages on the site.
Banner Size 728 X 90 pixels: Appears on the top right Corner of the homepage and all pages on the site.
Large rectangle Banner Size (336x280) : Appears on the home page and below all pages on the site.
Small square (200x200) : Appears on the right side of the home page and all pages on the site.
Half page (300x600) : Appears on the right side of the home page and all pages on the site.
Portrait (300x1050) : Appears on the right side of the home page and all pages on the site.
Billboard (970x250) : Appears on the home page.

Submission of Materials : Banner ads can be in jpeg, jpg and gif format. All materials must be deliverd via electronic medium. All ads must be delivered via electronic version, either on disk or e-mail in the ordered pixel dimensions unless otherwise noted.
For advertising offers, send an email with your name,company, website, country and advert or sponsored post you want to appear on our website to omodjk(at)gmail(dot)com

Normally, we should respond within 48 hours.

Previous Post Next Post

Ad — After Posts / Before Footer

                     Copyright Notice

All rights reserved. This material, and other digital contents on this website, may not be reproduced, published, rewritten or redistributed in whole or in part without prior express written permission from Alexa News Network Limited (Alexa.ng). 

نموذج الاتصال