from Hacker News

HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

by pgjones on 1/25/19, 1:50 PM with 52 comments

• by skywhopper on 1/25/19, 2:29 PM

  Actually, no. HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools. It also can't be supported by a lot of old software without some additional layer of indirection. This may or may not be important to you, but it is a thing that HTTP/2 cannot do.

• by mankyd on 1/25/19, 2:02 PM

  One important difference: HTTP/2 requires* encryption. This makes getting up and running for local development and small deployments more difficult.

  * https://http2.github.io/faq/#does-http2-require-encryption "[...] currently no browser supports HTTP/2 unencrypted."

• by jabart on 1/25/19, 2:22 PM

  Yes and no, because it is complicated. This is a fairly naive example of HTTP/2 to illustrate a point, while most websites I am called in on to optimize the load time are not built like this. This example only shaved off around 60ms for 20 requests, if your website has 20 requests to load, you have ads or you have a resource problem.

  HTTP/2 spec says it should not share a connection across a host/port combo, any content you have loaded on a CDN, or a your own cdn.mydomain.com will be a separate connection. The reason CDNs are faster is because they are closer(lower latency) or it is common and already cached in your browser.

  HTTP/2 still suffers from latency and TCP Window sizes, so no your 8mb website will still be slow after you enable HTTP/2, you still have to push 8mb out to the client. If you have a site loading over 80 resources, concat and minify that first before asking your server admin to turn on HTTP/2.

  HTTP/1 clients gets around some network latency issues by issuing more than one TCP socket, just like SFTP clients using more than one thread. Because it is hard to overload a single socket when your latency for your ACK packets is 200ms+. If this wasn't true, Google would not be spending the time on a UDP based version of HTTP. HTTP/2

  Overall, lower you content size, lower the number of requests it takes to load your initial website, THEN turn on HTTP/2.

• by rqs on 1/25/19, 2:41 PM

  I rather believe HTTP/2 will die when HTTP/3 is available.

  After all HTTP/1 is very simple to implement and already widely used and optimized. It is usable for most of cases. Plus, maybe in the future, CDN can serve HTTP/2 to client while use HTTP/1 to read the source.

  And currently web browsers still need to send Upgrade request in HTTP/1 to know whether or not a unknown HTTP server supports HTTP/2. I guess this will still be true after HTTP/3 comes out (alt-svc).

• by bpicolo on 1/25/19, 2:05 PM

  Aha, this article is by the creator of Quart[0]! I'm a big fan - one of my favorite new python packages. It's essentially a super zippy, flask-compatible asyncio python server. I switched a flask app over recently and saw an immediate 10-20x throughput gain (the app is entirely io-bound). pgjones was a pleasure to work with when I had a few issues and had to contribute a few compat fixes as well. Thanks for the awesome package!

  [0]: https://gitlab.com/pgjones/quart/

• by rando231 on 1/25/19, 2:57 PM

  This can't be true, can it?

  I was under the impression that HTTP/2 used a persistent connection w/ multiplexing. This seems like it would be very nice in a web-browser to front-end situation, but what about for internal service calls? Seems like persistent connection between services would mess w/ common load balancing schemes.

• by altmind on 1/26/19, 6:43 AM

  Time will show what unknown challenges and problems http/2 carries. So far, the protocol is studied mostly by google(and less by cloudflare), there is limited research by independent parties.

  From the article, i see that the author heavily relies on the chrome devtools to demonstrate the performance benefit, relying on chrome connection statuses.

  My spdy and http/2 tests in 2016 did not show much imrovment in perceived load speed for our e-commerce site. optimizing delivery(for us - caching the pre-rendered javascript components and pre-loading some ajax) yield better results. ymmv.

• by atemerev on 1/25/19, 3:09 PM

  So, Websockets over HTTP/2 are only available in latest Firefox (or experimentally in Chrome, if you manually turn on a flag for it). Almost no servers support HTTP/2 Websockets, too.

  Sorry, it is a little too early to switch.

• by peterwwillis on 1/25/19, 3:36 PM

  If you want HTTP/2 to succeed, you're going to have to start making little wins. Find a tiny, easy market and get them to use it. Then find a giant customer (Google never counts) and get them to use it. If it seems more complicated, nobody's going to pick it up unless they have to.

  The alternative is to create big sexy splash pages, create a lots of hype, and lie to people about how easy it is to implement. When they're finally caught up in the complexity of implementation, it'll be too late to back out.

• by commandlinefan on 1/25/19, 2:55 PM

  Same can be said about IPv6 - and could have been said about IPv6 20 years ago. Still waiting...

• by antoinevg on 1/25/19, 3:23 PM

  Speed. It is not everything.

• by xena on 1/25/19, 3:15 PM

  Except websockets.

• by est on 1/25/19, 1:55 PM

  but can h2 do websocket?