7 ms·

Go HTTP2 demo

140 points by antouank 12y ago

kid0m4n 12y ago
This is actually pretty impressive! https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles
- pests 12y ago
  Noticed that one too. The difference between 1s latency is huge between HTTP/1 and HTTP/2!
  - bonn1 12y ago
    Where do you see 1sec latency difference? EDIT: ok found it and it's striking, the difference is even more than 1 sec (total loading time)
  - bsdetector 12y ago
    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.
    - pkulak 12y ago
      Your browser wouldn't even use pipelining if it was supported. The reason HTTP/2 exists is because pipeling ended up not being a solution.
      - bsdetector 12y ago
        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.
    - bgentry 12y ago
      Pretty sure the demo server supports keep-alive, just as all Go net/http servers do by default: https://github.com/bradfitz/http2/blob/master/h2demo/h2demo.go https://github.com/bradfitz/http2/blob/master/h2demo/h2demo....
      - bsdetector 12y ago
        There's no "Connection: keep-alive" in the response header. If they purposely turned it off that's even worse.
        lucian1900 12y ago
        That's because it's the default in HTTP 1.1. The server would need to send "Connection: close" to disable keep-alive.
        bsdetector 12y ago
        Apparently "connection: keep-alive" is needed to enable pipelining in the browsers: http://www.guypo.com/http-pipelining-big-in-mobile/ http://www.guypo.com/http-pipelining-big-in-mobile/
- glittershark 12y ago
  The comparison there had me literally jumping up and down in my seat.
martin_ 12y ago
$ curl https://http2.golang.org/ 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?
- deleted 12y ago
  [deleted]
- martin_ 12y ago
  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.
  - nindalf 12y ago
    The latest version of curl does support HTTP/2, I believe.
- charonn0 12y ago
  I experienced a significant connection delay. I assume it's due to the traffic surge from HN.
WestCoastJustin 12y ago
Related to "Hacking with Andrew and Brad: an HTTP/2 client in Go" @ https://news.ycombinator.com/item?id=9112344 https://news.ycombinator.com/item?id=9112344
daretorant 12y ago
Down for me... :/
- carbocation 12y ago
  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. 1 = http://https.downforeveryone.com/check.php?url=http2.golang.org/ http://https.downforeveryone.com/check.php?url=http2.golang....
cpg 12y ago
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! [0] https://github.com/amahi/spdy/ https://github.com/amahi/spdy/
nodesocket 12y ago
I didn't know that HTTP2 supports streaming data. How is this done? It is not a websocket connection. /clockstream streams the current time every second And why does it require ~1KB of junk to force browsers to start rendering immediately?
- shurcooL 12y ago
  Some browsers will try to guess the content type from first few bytes, so they won't start showing anything until enough bytes have been received. Well behaved browsers should not do that if Content-Type header is set.
  - pests 12y ago
    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.
    - thekos 12y ago
      Yep. Here's the code from nginx: https://github.com/nginx/nginx/blob/master/src/http/ngx_http_special_response.c#L35 https://github.com/nginx/nginx/blob/master/src/http/ngx_http...
      - pests 12y ago
        Thanks! I knew I read about that years and years ago but wasn't sure if it was still true.
- donatj 12y ago
  You can do this with HTTP1 actually. Its how motion jpeg works. I've actually got a little mjpeg php script here - https://github.com/donatj/mjpeg-php/blob/master/mjpeg.php https://github.com/donatj/mjpeg-php/blob/master/mjpeg.php Just flush every frame and you're golden. I've also seen simple dashboards that do this, displaying one line at a time as data comes in, simply never closing the connection.
bonn1 12y ago
Hijacking the thread: Anyone made already experiences with HTTP2, Node, Express and Nginx together?

Go HTTP2 demo

140 points by antouank 12y ago

kid0m4n 12y ago

This is actually pretty impressive! https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles

pests 12y ago
Noticed that one too. The difference between 1s latency is huge between HTTP/1 and HTTP/2!
- bonn1 12y ago
  Where do you see 1sec latency difference? EDIT: ok found it and it's striking, the difference is even more than 1 sec (total loading time)
- bsdetector 12y ago
  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.
  - pkulak 12y ago
    Your browser wouldn't even use pipelining if it was supported. The reason HTTP/2 exists is because pipeling ended up not being a solution.
    - bsdetector 12y ago
      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.
  - bgentry 12y ago
    Pretty sure the demo server supports keep-alive, just as all Go net/http servers do by default: https://github.com/bradfitz/http2/blob/master/h2demo/h2demo.go https://github.com/bradfitz/http2/blob/master/h2demo/h2demo....
    - bsdetector 12y ago
      There's no "Connection: keep-alive" in the response header. If they purposely turned it off that's even worse.
      - lucian1900 12y ago
        That's because it's the default in HTTP 1.1. The server would need to send "Connection: close" to disable keep-alive.
        bsdetector 12y ago
        Apparently "connection: keep-alive" is needed to enable pipelining in the browsers: http://www.guypo.com/http-pipelining-big-in-mobile/ http://www.guypo.com/http-pipelining-big-in-mobile/
glittershark 12y ago
The comparison there had me literally jumping up and down in my seat.

martin_ 12y ago

$ curl https://http2.golang.org/ 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?

deleted 12y ago
[deleted]
martin_ 12y ago
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.
- nindalf 12y ago
  The latest version of curl does support HTTP/2, I believe.
charonn0 12y ago
I experienced a significant connection delay. I assume it's due to the traffic surge from HN.

WestCoastJustin 12y ago

Related to "Hacking with Andrew and Brad: an HTTP/2 client in Go" @ https://news.ycombinator.com/item?id=9112344 https://news.ycombinator.com/item?id=9112344

daretorant 12y ago

Down for me... :/

carbocation 12y ago
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. 1 = http://https.downforeveryone.com/check.php?url=http2.golang.org/ http://https.downforeveryone.com/check.php?url=http2.golang....

cpg 12y ago

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! [0] https://github.com/amahi/spdy/ https://github.com/amahi/spdy/

nodesocket 12y ago

I didn't know that HTTP2 supports streaming data. How is this done? It is not a websocket connection. /clockstream streams the current time every second And why does it require ~1KB of junk to force browsers to start rendering immediately?

shurcooL 12y ago
Some browsers will try to guess the content type from first few bytes, so they won't start showing anything until enough bytes have been received. Well behaved browsers should not do that if Content-Type header is set.
- pests 12y ago
  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.
  - thekos 12y ago
    Yep. Here's the code from nginx: https://github.com/nginx/nginx/blob/master/src/http/ngx_http_special_response.c#L35 https://github.com/nginx/nginx/blob/master/src/http/ngx_http...
    - pests 12y ago
      Thanks! I knew I read about that years and years ago but wasn't sure if it was still true.
donatj 12y ago
You can do this with HTTP1 actually. Its how motion jpeg works. I've actually got a little mjpeg php script here - https://github.com/donatj/mjpeg-php/blob/master/mjpeg.php https://github.com/donatj/mjpeg-php/blob/master/mjpeg.php Just flush every frame and you're golden. I've also seen simple dashboards that do this, displaying one line at a time as data comes in, simply never closing the connection.

bonn1 12y ago

Hijacking the thread: Anyone made already experiences with HTTP2, Node, Express and Nginx together?