Live data from Hacker News

Hello HTTP/2, Goodbye SPDY

blog.chromium.org

91–100 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#91
Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase.

Am I missing something? Do some people have so many cookies that this makes a difference or something?

Re: Hello HTTP/2, Goodbye SPDY

#92
post #71

Earlier quoted context omitted.

That's so lame. It's so easy to set up a new website today, it's going to be a huge burden in the future. Some of us still make websites for fun, not as businesses. I guess I have to buy a cheap ssl certificate from some sleezy website every time I feel creative.

I'm puzzled, did you miss the announcement? The EFF, Mozilla, and others are creating a CA that will give free certs to everyone: https://letsencrypt.org/

It's not live yet.

Re: Hello HTTP/2, Goodbye SPDY

#93
post #89

Earlier quoted context omitted.

> that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons. What Google is doing with PNaCl is the standards process. Standards start life by being not-standards that someone shipped and enough people liked to make it into a standard. There is nothing wrong here, nothing whatsoever. This is exactly how the process should work. Design-by-committee stan…

While I agree with you that competition is crucial, and without experimentation we will get nowhere, it is worth remembering that IE6 and all of its specific behaviors "won" through "raw competition". Often things win not through fair competition. For example, WebSQL "won" on mobile because WebKit won on mobile, and WebKit happened to have WebSQL. If WebKit had had, say, the Audio Data API (which it did not), then th…

> it is worth remembering that IE6 and all of its specific behaviors "won" through "raw competition".

It is worth noting that the findings in the antitrust actions in the US over Microsoft's illegal and anti-competitive behavior in establishing IE's dominance indicate that that claim is, at best, misleading.

Re: Hello HTTP/2, Goodbye SPDY

#94
post #91

Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase. Am I missing something? Do some people have so many cookies that this makes a difference or something?

As far as I can tell, the compression is separate for the headers, does not use deflate, and (most importantly) is over the entire session, not just one request.

This would benefit from the fact that in one request headers are not repeated, but over multiple requests they certainly are.

http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-head...

Re: Hello HTTP/2, Goodbye SPDY

#95
post #52

Earlier quoted context omitted.

> This attitude is exactly how you make sure that nothing ever changes or improves. On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.

I think you're confusing quantity as being the end result. The quantity is about experimentation. The quality comes as the winning products are refined over time; the low quality products never gain mass traction and are discarded. That's exactly how it should work. These things are complimentary, not mutually exclusive. That process is how innovation happens quickly. It's also how you frequently discover new things…

"Low quality products never gain mass traction and are discarded" Yet we're still kicking IPv6

Re: Hello HTTP/2, Goodbye SPDY

#96

Does anyone know if Cloudflare has plans to implement HTTP/2? RIght now they support SPDY. I found the answer from their blog: "Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical)."

We've been talking about it. I think it's just a question of when.

Re: Hello HTTP/2, Goodbye SPDY

#97
post #91

Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase. Am I missing something? Do some people have so many cookies that this makes a difference or something?

The header compression in HTTP 2.0 isn't based on gzip or something like that. The CRIME attack pretty much killed those approaches dead. It's more akin to differential updates for header during the lifetime of the connection. So if you request a lot of files with fairly similar headers you'll effectively only have to transmit the bulk of the header once while the other request will efficiently re-use the previously transmitted fields.

So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection.

Re: Hello HTTP/2, Goodbye SPDY

#98
post #52

Earlier quoted context omitted.

> This attitude is exactly how you make sure that nothing ever changes or improves. On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.

I think you're confusing quantity as being the end result. The quantity is about experimentation. The quality comes as the winning products are refined over time; the low quality products never gain mass traction and are discarded. That's exactly how it should work. These things are complimentary, not mutually exclusive. That process is how innovation happens quickly. It's also how you frequently discover new things…

Playing Devil's advocate, wasn't SPDY the experimentation part? Why the need for HTTP/2?

Re: Hello HTTP/2, Goodbye SPDY

#99
post #58

Earlier quoted context omitted.

Not really a fair benchmark. It's making tons of requests with tiny payloads, so that most browsers will hit a connection limit and requests will be queued up. Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript. On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)

Many of the sites I visit frequently are exactly like that: tons of requests with tiny payloads. The nytimes.com homepage makes 100+ requests to tiny images. Same thing for the yahoo.com homepage. An ebay.com listing page makes many requests to small thumbnails of items on sale. And so on... This makes it a perfectly fair benchmark IMHO.

I don't know how you're assessing those pages, but bear in mind that

- Counting images can be misleading, since well-optimized sites use spritesheets or data URIs.

- If you're using something like Chrome's dev console to view requests, a lot of them are non-essential requests which are intentionally made after the page is functional.

- HTTP connection caps are per host. The benchmark is making hundreds of requests to one host, whereas a real page might make a dozen requests to the main server, a dozen to some CDN for static files, and a dozen to miscellaneous third parties.

- The benchmark is simulating an uncached experience; with a realistic blend of cached/uncached, HTTP 1 vs 2 performance would be much more comparable.

HTTP/2 is an improvement but if people expect a "5-15X" difference, they're in for a big disappointment.

Re: Hello HTTP/2, Goodbye SPDY

#100

Earlier quoted context omitted.

I'm puzzled, did you miss the announcement? The EFF, Mozilla, and others are creating a CA that will give free certs to everyone: https://letsencrypt.org/

It's not live yet.

Neither is HTTP/2, and much less is HTTP/1.1 deprecated, so I don't see the problem.
Post reply on HN