The server doesn't support keep-alive, and it doesn't support pipelining. It seems to be built by design to have the worst possible performance for HTTP/1.1.
Whatever problems pipelining may or may not have, a benchmark like this one loading a bunch of small static images is what it is designed for. I can see how some small-timey Go implementation would not have an actual HTTP/1.1 server, but for Google to come out with HTTP/2 without even having tested against pipelining is just pitiful.
These Google people seem hellbent on not ever having a fair comparison.
Pipelining works fine. It's on in mobile Safari, and neither Google nor Mozilla found what software it didn't work on (so probably Superfish and other malware). If you use Firefox it's still a great way to speed up normal page loads since HTTP/2 isn't used for unencrypted data.
$ curl https://http2.golang.org/ -v
* Hostname was NOT found in DNS cache
* Trying 130.211.116.44...
* Connected to http2.golang.org (130.211.116.44) port 443 (#0)
Hangs at this point for me -- anyone else having issues?
Seems ok for me now-- maybe some temporary hiccup. Worth noting curl doesn't support HTTP/2, but I was experiencing the same delay in chrome w/SPDY too.
Down for me too. I'm guessing due to load. It's also reported as being down based on an https checker [1], but I don't know if it would correctly handle http2 so this may always give a false positive.
One can build a http2/SPDY demo fairly easily these days. I co-wrote a SPDY library[0] that has been used in production for streaming video across the interweb to mobile devices to great success.
There is a simple server created with the library in a few lines. Try it out.
The library was built "the Go way" with the idea to support http2 as soon as it was final and we're looking to do that soon!
I thought this has something to do with browsers returning their own internal 404 page if the content was less than 1kb? Something to do with that being the max size of error pages on old webservers, which browsers wanted to replace.
> I didn't know that HTTP2 supports streaming data
It's not specific to HTTP2, and is in fact possible since the server doesn't send a Content-Length so the client doesn't know when the server is done. Think of it not as streaming, but as a really slow and consistent huge response. HTTP2 just makes it smoother (remember: HTTP2 doesn't change semantics, it only changes how things are represented on the wire)
29 comments
[ 0.26 ms ] story [ 75.8 ms ] threadhttps://http2.golang.org/gophertiles
EDIT: ok found it and it's striking, the difference is even more than 1 sec (total loading time)
Whatever problems pipelining may or may not have, a benchmark like this one loading a bunch of small static images is what it is designed for. I can see how some small-timey Go implementation would not have an actual HTTP/1.1 server, but for Google to come out with HTTP/2 without even having tested against pipelining is just pitiful.
These Google people seem hellbent on not ever having a fair comparison.
http://www.guypo.com/http-pipelining-big-in-mobile/
Hangs at this point for me -- anyone else having issues?
1 = http://https.downforeveryone.com/check.php?url=http2.golang....
There is a simple server created with the library in a few lines. Try it out.
The library was built "the Go way" with the idea to support http2 as soon as it was final and we're looking to do that soon!
[0] https://github.com/amahi/spdy/
Well behaved browsers should not do that if Content-Type header is set.
I've also seen simple dashboards that do this, displaying one line at a time as data comes in, simply never closing the connection.
It's not specific to HTTP2, and is in fact possible since the server doesn't send a Content-Length so the client doesn't know when the server is done. Think of it not as streaming, but as a really slow and consistent huge response. HTTP2 just makes it smoother (remember: HTTP2 doesn't change semantics, it only changes how things are represented on the wire)
Now, the way the demo server uses that is a bit rough; there is a specification for that in the form of Server-Sent events (https://developer.mozilla.org/en-US/docs/Server-sent_events/...).