11–20 of 100 posts
Hm, HTTP/1.1 at 15.5s, HTTP/2 at 23.72s Yeah, I "can see the difference clearly", but I don't think it is the kind of difference they expected or intended. Edit: Firefox 40 on Windows 7 at work. Will try at home as well. Oddly enough, the Akamai demo someone else posted gives me 18.47s for HTTP/1.1 and 2.24s for HTTP/2.
HTTP1 - 3.13s
HTTP2 - 0.54s
My wget implementation does not suppot http/2
HTTP Server:
$ time wget https://1153288396.rsc.cdn77.org/http2/tiles_final/tile_18.png
[...]
real 1.038 user 0.038 sys 0.007 pcpu 5.37
$ time wget https://1906714720.rsc.cdn77.org/http2/tiles_final/tile_18.png
[...]
real 0.539 user 0.045 sys 0.009 pcpu 10.01
We should also consider the fact that this is cherry picking the worst trait of HTTP/1.1 and that's that it's latency sensitive.
A demo with a real webpage of large assets would be a better example.
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 connections to a host, so once these are in use the other requests queue behind waiting to a connection to become free.
2. Even when one becomes free, we've got the request / response latency before the browser sees an images bytes
3. If the response doesn't fill the congestion window i.e. it's a small file, then there's spare capacity that's not being used i.e. packets we could have send it the round trip that didn't.
4. In this demo the server sends connection: close so forces the browser to open a new TCP connection and negotiate TLS for each of the tiles, so the congestion window won't grow either.
Yes, HTTP/2 is faster, because it can send multiple requests at the same time to overcome latency, the server can fill the congestion window, and the window will grow.
But are our web pages build of tiny image tiles, or a greater variety of image and resources sizes?
EDIT: They've now enabled keep-alive which makes the HTTP/1.1 test much faster than it was
6.41s HTTP/1.1 vs 2.51s HTTP/2 on FF42. Very nice! (Although when HTTP2 is going the FPS drops quite a bit.) Can someone explain what exactly HTTP2 is doing differently to achieve such an improvement?
In http/2 the "Connection: close" header is meaningless and all the tiles come from the same connection.
Hm, HTTP/1.1 at 15.5s, HTTP/2 at 23.72s Yeah, I "can see the difference clearly", but I don't think it is the kind of difference they expected or intended. Edit: Firefox 40 on Windows 7 at work. Will try at home as well. Oddly enough, the Akamai demo someone else posted gives me 18.47s for HTTP/1.1 and 2.24s for HTTP/2.
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…
This is a copy of the Akamai's http2 demo: http://http2.akamai.com