Live data from Hacker News

HTTP/2 technology demo

http2demo.io

31–40 of 100 posts

Re: HTTP/2 technology demo

#31
post #25

It is a real world demo though? Similar to many of the other demo's of HTTP/2 (Gopher Tile, Akamai) it's written in a way that presents HTTP/1.x in the worst light and manages to screw things up even more. HTTP/1.1 is really latency prone so when you have a demo that uses lots of smalls requests that don't fill up the congestion window you run into a couple of problems. 1. The browser can only use a limited number of…

Regarding #4 isn't this a bit cheating, who doesn't use keep-alive. Also what about request pipelining? Doesn't that basically do the sane thing what http/2 is doing?

From memory request pipelining is disabled in most browsers as many intermediaries (proxies etc) screw it up, it's still vulnerable to head-of-line blocking even when it's enabled.

You'd be surprised how many servers don't have keep-alive enabled, it's much more common than I'd like.

I'm a great fan of HTTP/2 but I'd like to see realistic tests!

Re: HTTP/2 technology demo

#32
post #17

The test is a lie. While I don't doubt improvements in http/2, this test uses "Connection: close" on the http/1.1 test, which means for each tile there needs to be a tcp connect and TLS handshake. This is not representative of real world. In http/2 the "Connection: close" header is meaningless and all the tiles come from the same connection.

Playing the devil's advocate; "Connection: close" merely exaggerates the underlying issue.

That being said, the comparison would have definitely been fairer with keep-alive and having to resort to a trick like this makes me wonder how much faith they have in their own product.

Re: HTTP/2 technology demo

#33
This demo could be possibly even faster if using HTTP/2.0 Server Push.

Btw, note that if you're looking into supporting HTTP/2.0 on your own then with nginx there's still some waiting left: https://www.nginx.com/blog/early-alpha-patch-http2/ And there's no plan to support server push with the first production release. So NGINX users will have to keep using SPDY.

AFAIK the latest plan with SPDY is to remove it from Chrome browser in early 2016 so nginx has to make sure to deliver before that...

Re: HTTP/2 technology demo

#34
post #32
post #17

The test is a lie. While I don't doubt improvements in http/2, this test uses "Connection: close" on the http/1.1 test, which means for each tile there needs to be a tcp connect and TLS handshake. This is not representative of real world. In http/2 the "Connection: close" header is meaningless and all the tiles come from the same connection.

Playing the devil's advocate; "Connection: close" merely exaggerates the underlying issue. That being said, the comparison would have definitely been fairer with keep-alive and having to resort to a trick like this makes me wonder how much faith they have in their own product.

concurrency is not impacted by this, but its affects window scaling, and 2 - 4 extra round trips per request for the connection setup.

Re: HTTP/2 technology demo

#35
post #34
post #32

Earlier quoted context omitted.

Playing the devil's advocate; "Connection: close" merely exaggerates the underlying issue. That being said, the comparison would have definitely been fairer with keep-alive and having to resort to a trick like this makes me wonder how much faith they have in their own product.

concurrency is not impacted by this, but its affects window scaling, and 2 - 4 extra round trips per request for the connection setup.

> concurrency is not impacted by this

You're right. Watched it closely a second time and there's definitely concurrency.

Re: HTTP/2 technology demo

#37
post #25

It is a real world demo though? Similar to many of the other demo's of HTTP/2 (Gopher Tile, Akamai) it's written in a way that presents HTTP/1.x in the worst light and manages to screw things up even more. HTTP/1.1 is really latency prone so when you have a demo that uses lots of smalls requests that don't fill up the congestion window you run into a couple of problems. 1. The browser can only use a limited number of…

Regarding #4 isn't this a bit cheating, who doesn't use keep-alive. Also what about request pipelining? Doesn't that basically do the sane thing what http/2 is doing?

Are there any browsers that have pipelining turned on by default ?

Re: HTTP/2 technology demo

#38
post #25

Earlier quoted context omitted.

Regarding #4 isn't this a bit cheating, who doesn't use keep-alive. Also what about request pipelining? Doesn't that basically do the sane thing what http/2 is doing?

From memory request pipelining is disabled in most browsers as many intermediaries (proxies etc) screw it up, it's still vulnerable to head-of-line blocking even when it's enabled. You'd be surprised how many servers don't have keep-alive enabled, it's much more common than I'd like. I'm a great fan of HTTP/2 but I'd like to see realistic tests!

Yup, and clients also mess it up, especially when it comes to pipelining. Should also not forget about TLS session resumption. I've seen it boost server performance over 10x, TLS session negotiation is CPU bound.

Re: HTTP/2 technology demo

#39

Cheaper and faster than AWS Cloudfront with free custom SSL. So what is the catch? One issue is our data is on S3 and I believe that any outgoing S3 traffic to this CDN would be slow and cost money, but S3 to CloudFront is is likely prioritized and free.

Outgoing traffic from S3 has no bandwidth cost associated with it.
Post reply on HN