HTTP/2 is Done

Forum Moderators: phranque

Message Too Old, No Replies

HTTP/2 is Done

IESG has formally approved the HTTP/2 and HPACK specifications

bill

4:14 am on Feb 18, 2015 (gmt 0)

http://thenextweb.com/insider/2015/02/18/http2-first-major-update-http-sixteen-years-finalized/ [thenextweb.com]

HTTP/2, the first update to HTTP in 16 years, has been finalized

Today, the next major version of HTTP took a big step toward becoming a reality; it’s been officially finalized and now moves towards being fully standardized.
...
HTTP/2 is a huge deal; it’s the next big version of the Hypertext Transfer Protocol, marking the largest change since 1999 when HTTP 1.1 was adopted.

lucy24

4:56 am on Feb 18, 2015 (gmt 0)

It should be a relatively short time before the standard is passed through the Request-For-Comments Editor and published for use in its final form.

Well, I hope someone tells us when it comes into actual use, since I do not even want to think about how many functions I've currently got using the locution

HTTP/1\.[01]

Google announced just a few days ago that it plans to switch fully to HTTP/2 in Chrome.

Well, ###, it would never have occurred to me that this is browser-dependent. I'd have assumed it was the ISP making the decision.

phranque

5:12 am on Feb 18, 2015 (gmt 0)

it would never have occurred to me that this is browser-dependent. I'd have assumed it was the ISP making the decision.

"GET / HTTP/1.1" is a typical HTTP GET request sent by the user agent...
(note the HTTP version specification supplied by the browser)

bill

6:22 am on Feb 18, 2015 (gmt 0)

Google announced just a few days ago that it plans to switch fully to HTTP/2 in Chrome

That might have something to do with Google dropping SPDY for HTTP 2.0 in Chrome [webmasterworld.com]

lucy24

7:07 am on Feb 18, 2015 (gmt 0)

note the HTTP version specification supplied by the browser

I see the version specification, fer hevvins sakes. That's why I have all those "HTTP/1\.[01]" rules. What I don't see is how I was supposed to know that the exact version number --as opposed to the general method, such as HTTP vs. FTP-- is supplied by the browser. Among humans, I've always associated 1.0 with proxies. (I used to think satellite, but this doesn't seem to be the case.)

Google dropping SPDY for HTTP 2.0 in Chrome

There's a good deal of blahblah about that in the article linked from the OP too. On a scale of earth-shakingness, I was thinking it's roughly on a level with MSIE abandoning the Conditional Comment.

engine

11:33 am on Feb 18, 2015 (gmt 0)

System: The following message was spliced on to this thread from: http://www.webmasterworld.com/website_technology/4737396.htm [webmasterworld.com] by engine - 12:59 pm on Feb 18, 2015 (utc 0)

HTTP/2 and HPACK specification is now formally approved and now heading to the RFC Editor, according to news from the Chair of the IETF HTTP Working Group, Mark Nottingham.

Watch the IETF blog for more information when it becomes available.
[ietf.org...]

What is HTTP/2 [http2.github.io...]

graeme_p

1:51 pm on Feb 18, 2015 (gmt 0)

Does that mean that Chrome will not work with HTTP 1.1 servers? That means every single site we serve must have an certificate? Certificate issuers are going to make a fortune - and small personal sites on their own domains will become a rarity.

graeme_p

1:53 pm on Feb 18, 2015 (gmt 0)

Looks like I may be wrong about that. Not sure what to make of this:

No. After extensive discussion, the Working Group did not have consensus to require the use of encryption (e.g., TLS) for the new protocol.

However, some implementations have stated that they will only support HTTP/2 when it is used over an encrypted connection

brotherhood of LAN

2:26 am on Feb 19, 2015 (gmt 0)

>HTTP/1\.[01]

Indeed. I can think of a few pieces of software I use that may not work as well when HTTP 2 is out in the wild.

lucy24

4:40 am on Feb 19, 2015 (gmt 0)

I don't suppose the People In Charge would take kindly to it if we drummed our heels and screamed You've broken my Regular Expression! though I do note that they explicitly chose to go with /2 alone instead of /2.0

:: vague mental association with <!DOCTYPE HTML> ::

robzilla

2:12 pm on Feb 19, 2015 (gmt 0)

Does that mean that Chrome will not work with HTTP 1.1 servers? That means every single site we serve must have an certificate? Certificate issuers are going to make a fortune - and small personal sites on their own domains will become a rarity.

No, browsers are adding support for HTTP2. It's an additional protocol, as it were. HTTP 1(.1) will, of course, continue to be supported for at least another decade or so.

If you have scripts that depend on HTTP1, you'll either have to rewrite them or disable HTTP2 support in your web server software. Clients who have HTTP2-capable browsers will simply fall back to HTTP1 if your server doesn't support it, but then obviously won't be able to benefit from the advantages HTTP2 has to offer.

Should you choose to rewrite the scripts, keep in mind that HTTP/2 will shortly be followed by HTTP/3, HTTP/4, etc. (and there's not likely going to be a HTTP/2.1).

Nutterum

2:44 pm on Feb 19, 2015 (gmt 0)

I have a question that might not be easy to answer.

Can you point 5 benefits of http 2 that are easy to digested by not technically savvy person.

Thank you for your comments in advance.

lucy24

7:20 pm on Feb 19, 2015 (gmt 0)

continue to be supported for at least another decade or so

If not "in perpetuity". After 16 years we still get requests for HTTP/1.0.

graeme_p

4:56 am on Feb 20, 2015 (gmt 0)

@robzilla, ah, yes, after reading the linked articles properly I see that they are dropping support for SPDY in favour of HTTP/2, leaving HTTP/1.1 support unchanged.

People who invested (time or money) in SPDY support will have wasted it - and learned to be less eager about being early adopters.

robzilla

8:58 am on Feb 20, 2015 (gmt 0)

People who invested (time or money) in SPDY support will have wasted it - and learned to be less eager about being early adopters.

The early adopters have certainly benefited from SPDY, which may seem new but has in fact been around for about 3 years. With browser support ending in 2016, that's still ~4 years of improved performance; definitely not a wasted effort in my book. The late adopters may regret having waited, but then again it'll probably be a while before HTTP/2 is supported by the popular web servers and most users' web browsers (and there will be bugs). I'll probably stick to SPDY for at least the next ~6 months.

bwnbwn

3:55 pm on Feb 20, 2015 (gmt 0)

Interesting read on this topic.
Google executive Vint Cerf says our data may well vanish

Internet Guru: 'Digital Dark Ages' May Be Coming from

Robert Charlton

5:53 am on Feb 23, 2015 (gmt 0)

Vint Cerf wasn't talking particularly about security and this specific protocol change, though... albeit it's possible that changing internet protocols will eventually become a part of kinds of changes he's discussing.

He was talking about the rapid changes in technology that are making old formats obsolete and inaccessible. This includes changes in hardware, software, file formats, operating systems, and programing languages. Here's a link to the original BBC interview...

Google's Vint Cerf warns of 'digital Dark Age'
[bbc.com...]

The rate of change is becoming a major time suck. Worth noting, btw, that digital data is not archival. That's a whole other issue... and really should be another discussion.

mattur

4:13 pm on Mar 31, 2015 (gmt 0)

Can you point 5 benefits of http 2 that are easy to digested by not technically savvy person.

There's one main benefit: it makes websites faster, by using the network connection more efficiently.

Kendo

10:00 pm on Mar 31, 2015 (gmt 0)

it makes websites faster, by using the network connection more efficiently.

How?

mattur

1:25 pm on Apr 2, 2015 (gmt 0)

Due to the overhead involved in creating and sending HTTP/1 requests we adopt workaround measures like inlining fonts, concatenating CSS, image spriting, etc to reduce the number of requests required to load a page.

HTTP/2 uses multiplexing to send multiple resources simultaneously over one connection, and avoiding slow resources blocking other resources, so pages load faster. It also adds header compression, making the requests and response headers smaller, minimising their impact on bandwidth.

There's a HTTP/1 vs HTTP/2 demo page here, demonstrating the difference when loading lots of small images (the HTTP2 version is about 3-4 times faster for me in Chrome, Firefox and IE):
[http2.akamai.com...]

Further reading:
[http2.github.io...]

Kendo

8:48 pm on Apr 2, 2015 (gmt 0)

HTTP/1 vs HTTP/2 demo here: https://http2.akamai.com/demo [http2.akamai.com]

This is a cheap trick... it displays images loading via HTTP/1 that first needed to be downloaded and then it displays the SAME images "supposedly" downloaded again via HTTP/2.

Where is the dupe? The second set of images are identical and NOT downloaded at all but instead delivered from cache because they were already downloaded for use in the first example.

[edited by: phranque at 9:13 pm (utc) on Apr 3, 2015]
[edit reason] fixed quoting [/edit]

mattur

10:50 pm on Apr 2, 2015 (gmt 0)

The two sets of images are coming from different servers, so the second set of images - which are exactly the same for comparison purposes - are obviously not in the cache.

You can examine the response headers (HTTP1 for the first set of images, HTTP2 for the second set) in your browser's devtools, LiveHttpHeaders etc.

So no, this is not a "cheap trick", but it's interesting the HTTP2 version was fast enough to fool you into thinking it was.

Kendo

1:34 am on Apr 3, 2015 (gmt 0)

Ok, so I did overlook the different URLs. So may false claims to contend with such as Chrome's claim of being a faster browser when in fact it depends on cache retention.

I see that the 2 sites are on the same server so there is no guarantee that the image resources are different or that there is no server-side throttling behind the scenes.

But I'll have to keep HTTP/2 in mind whenever I display a single image spliced into 300+ parts.

Ping tests on both domains were inconsistent so any speed contest will be unreliable unless you still want to compare latency when it fluctuates 50-100%.

I am not saying that cannot be an improvement. Just not convinced of any advantage that will have a great impact... if a user is downloading a single media resource it is still a single file download and governed by fluctuating server resources and their internet connection, ie: who/what else is sharing those resources at the time.

mattur

2:24 pm on Apr 3, 2015 (gmt 0)

But I'll have to keep HTTP/2 in mind whenever I display a single image spliced into 300+ parts.

Sorry, this is nonsense. HTTP2 will speed up all websites, with significant increases in speed for any page that uses more than 8 resources (images, CSS, fonts, js), since browsers only make up to 8 simultaneous HTTP1 requests, and queue subsequent requests until one of those 8 connections completes. You can see the staggered groups of 8 resources loading in the network panel of browsers' devtools.

As you've just demonstrated, by wrongly guessing the HTTP2 demo above was coming from the cache, the speed increase is significant, particularly for pages with lots of resources. Even relatively simple pages use more than 8 requests e.g. the WebmasterWorld homepage makes 23 requests. Header compression will also make pages with fewer than 8 resources faster. Using HTTP2 as it becomes widely available really is a no-brainer.

HTTP/2 is Done

IESG has formally approved the HTTP/2 and HPACK specifications

bill

lucy24

phranque

bill

lucy24

engine

graeme_p

graeme_p

brotherhood of LAN

lucy24

robzilla

Nutterum

lucy24

graeme_p

robzilla

bwnbwn

Robert Charlton

mattur

Kendo

mattur

Kendo

mattur

Kendo

mattur

Join The Conversation

Moderators and Top Contributors

Hot Threads This Week