5 ms·

Node.js: Initial experimental implementation of HTTP/2

146 points by andrewbarba 9y ago

BinaryIdiot 9y ago
I'm curious what will happen with the existing `http2` module. Will the http2 support get rolled into `http` or will `http2` remain separate and simply overshadow the npm module? Also, is there a roadmap between what they expect that needs to be done to take it from where it is today to non-experimental, production ready? Granted I'm sure testing and bug squishing is part of it but I'm curious to know if there are specific goals they want to accomplish before final exposure. Nice job all around on an initial release! I'll definitely take some time to play with it over the weekend :)
- simlevesque 9y ago
  > will `http2` remain separate That's how it is with the `https` module so I bet that's what will happen.
  - BinaryIdiot 9y ago
    Oh good point I actually forgot `https` was separate. Forgive my ignorance but how does SSL work with http2? Will there also be an https2? I haven't actually played with http2 yet and this gives me a good excuse to.
    - reificator 9y ago
      HTTP 2 has a defacto requirement of SSL to function. Technically, it's not required by the standard. However every existing implementation does require it, with several vendors claiming they will never support HTTP 2 without encryption.
      - daurnimator 9y ago
        > However every existing implementation does require it lua-http does not. https://github.com/daurnimator/lua-http/ https://github.com/daurnimator/lua-http/ Though the client won't auto negotiate http2 without TLS (yet... https://github.com/daurnimator/lua-http/blob/0b54603bfc132dcb9add76a61d3b50b4439031b2/http/client.lua#L73 https://github.com/daurnimator/lua-http/blob/0b54603bfc132dc...), you have to tell it to do so explicitly.
        reificator 9y ago
        I was debating putting in a disclaimer that I don't know all the existing implementations, but I was posting from my phone so I skipped it. Thanks for both links, that's good information.
      - manojlds 9y ago
        Every browser vendor I suppose, not every client.
      - Matthias247 9y ago
        If you insert "browser" between "existing" and "implementation" then it's correct. Most libraries also support unencrypted HTTP/2. E.g. nghttp2 (as used here in node.js, and also used by others like apache and curl) supports unencrypted connections. My own library for C# (https://github.com/Matthias247/http2dotnet https://github.com/Matthias247/http2dotnet) does too. The Go library might be a little bit of a special case, as it actually supports it, but the required functions are (or at least were) not exposed in the standard libraries http package. They should however be available in the x/net/http2 package.
        reificator 9y ago
        Yep, I was typing on my phone and left out the "that I know of" disclaimer. Good info, and thanks for the link.
      - BinaryIdiot 9y ago
        Oh good to know. I need to read up more on this. Thanks!
- tannhaeuser 9y ago
  There's also the 'spdy' module for http2 despite the name. It's what express.js supports for HTTP/2. [1]: https://github.com/expressjs/express/issues/2364 https://github.com/expressjs/express/issues/2364
  - gbuk2013 9y ago
    I tried that before but it is very slow compared to native https module [1] In the end though I added Nginx to my app container to be an HTTPS2 proxy and to serve static files instead - much better performance :) [1] https://github.com/spdy-http2/node-spdy/issues/304 https://github.com/spdy-http2/node-spdy/issues/304
    - tannhaeuser 9y ago
      Yes, but that kind of setup doesn't give you HTTP/2 server push so gives you hardly any benefit over HTTP/1.1, does it?
      - gbuk2013 9y ago
        I was interested in multiplexing and I got that, as well as a big increase in performance serving static content.
      - spankalee 9y ago
        You can push by sending Link/preload headers, which will be turned into requests by the proxy.
      - coldtea 9y ago
        Push is hardly the biggest benefit of HTTP/2 over HTTP/1.
trevyn 9y ago
Mmmmm... I'd rather see QUIC support -- A lot of Google -> Chrome traffic is served via QUIC, and Google, until very recently, had the only production-ready QUIC server. (Apparently Litespeed just added QUIC last month.)
- Matthias247 9y ago
  QUIC has not yet been fully standardized. If you integrate a current draft you risk that your claimed QUIC support is broken 1 year from now. Google risks that, because they control all parts of the system (services & brower). However I generally agree that HTTP/2 might only be short-term milestone on the way to HTTP over QUIC, as only this really fixes head-of-line blocking and therefore maybe justifies the increased implementation complexity better than HTTP/2.

146 points by andrewbarba 9y ago

I'm curious what will happen with the existing `http2` module. Will the http2 support get rolled into `http` or will `http2` remain separate and simply overshadow the npm module? Also, is there a roadmap between what they expect that needs to be done to take it from where it is today to non-experimental, production ready? Granted I'm sure testing and bug squishing is part of it but I'm curious to know if there are specific goals they want to accomplish before final exposure. Nice job all around on an initial release! I'll definitely take some time to play with it over the weekend :)

simlevesque 9y ago
> will `http2` remain separate That's how it is with the `https` module so I bet that's what will happen.
- BinaryIdiot 9y ago
  Oh good point I actually forgot `https` was separate. Forgive my ignorance but how does SSL work with http2? Will there also be an https2? I haven't actually played with http2 yet and this gives me a good excuse to.
  - reificator 9y ago
    HTTP 2 has a defacto requirement of SSL to function. Technically, it's not required by the standard. However every existing implementation does require it, with several vendors claiming they will never support HTTP 2 without encryption.
    - daurnimator 9y ago
      > However every existing implementation does require it lua-http does not. https://github.com/daurnimator/lua-http/ https://github.com/daurnimator/lua-http/ Though the client won't auto negotiate http2 without TLS (yet... https://github.com/daurnimator/lua-http/blob/0b54603bfc132dcb9add76a61d3b50b4439031b2/http/client.lua#L73 https://github.com/daurnimator/lua-http/blob/0b54603bfc132dc...), you have to tell it to do so explicitly.
      - reificator 9y ago
        I was debating putting in a disclaimer that I don't know all the existing implementations, but I was posting from my phone so I skipped it. Thanks for both links, that's good information.
    - manojlds 9y ago
      Every browser vendor I suppose, not every client.
    - Matthias247 9y ago
      If you insert "browser" between "existing" and "implementation" then it's correct. Most libraries also support unencrypted HTTP/2. E.g. nghttp2 (as used here in node.js, and also used by others like apache and curl) supports unencrypted connections. My own library for C# (https://github.com/Matthias247/http2dotnet https://github.com/Matthias247/http2dotnet) does too. The Go library might be a little bit of a special case, as it actually supports it, but the required functions are (or at least were) not exposed in the standard libraries http package. They should however be available in the x/net/http2 package.
      - reificator 9y ago
        Yep, I was typing on my phone and left out the "that I know of" disclaimer. Good info, and thanks for the link.
    - BinaryIdiot 9y ago
      Oh good to know. I need to read up more on this. Thanks!
tannhaeuser 9y ago
There's also the 'spdy' module for http2 despite the name. It's what express.js supports for HTTP/2. [1]: https://github.com/expressjs/express/issues/2364 https://github.com/expressjs/express/issues/2364
- gbuk2013 9y ago
  I tried that before but it is very slow compared to native https module [1] In the end though I added Nginx to my app container to be an HTTPS2 proxy and to serve static files instead - much better performance :) [1] https://github.com/spdy-http2/node-spdy/issues/304 https://github.com/spdy-http2/node-spdy/issues/304
  - tannhaeuser 9y ago
    Yes, but that kind of setup doesn't give you HTTP/2 server push so gives you hardly any benefit over HTTP/1.1, does it?
    - gbuk2013 9y ago
      I was interested in multiplexing and I got that, as well as a big increase in performance serving static content.
    - spankalee 9y ago
      You can push by sending Link/preload headers, which will be turned into requests by the proxy.
    - coldtea 9y ago
      Push is hardly the biggest benefit of HTTP/2 over HTTP/1.

trevyn 9y ago

Mmmmm... I'd rather see QUIC support -- A lot of Google -> Chrome traffic is served via QUIC, and Google, until very recently, had the only production-ready QUIC server. (Apparently Litespeed just added QUIC last month.)

Matthias247 9y ago
QUIC has not yet been fully standardized. If you integrate a current draft you risk that your claimed QUIC support is broken 1 year from now. Google risks that, because they control all parts of the system (services & brower). However I generally agree that HTTP/2 might only be short-term milestone on the way to HTTP over QUIC, as only this really fixes head-of-line blocking and therefore maybe justifies the increased implementation complexity better than HTTP/2.