Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

41–50 of 62 posts

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

#42

Post by acdha »

skywhopper wrote: post #40
acdha wrote: post #26

Earlier quoted context omitted.

> HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools This is, of course, why we also don't use chunked encoding and compression with HTTP 1 rather than writing better tools. I mean, you even have the example in that sentence about how the solution for using TLS was not to say “it doesn't work with telnet” but to use s_client, ncat, socat, etc. > It al…

How is HTTP/1.1 holding anything back?

HTTP 1 has a fixed feature set and a lot of warts. Nobody is working on HTTP 1.2, etc. so the only way anything is going to get better will be in the HTTP/2 series of development. At some point we need to ask whether skimping on maintenance is actually better than getting those improvements.

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

#44

Post by acdha »

jabart wrote: post #32
acdha wrote: post #19

Earlier quoted context omitted.

You have some IE6/HTTP 1 tuning advice which is no longer necessary in there. > The reason CDNs are faster is because they are closer(lower latency) or it is common and already cached in your browser. Shared CDN hit rates tend to be rather low and usually slower than self-hosting unless you're requesting a LOT of resources because the DNS + TLS setup overhead are greater than the eventual savings. Opening multiple co…

Most of my tests on CDNs show they are faster unless the server is hosted in Chicago for me. I have put anycast SSL termination in front of sites before that have also decreased the ssl connection handshake, which barely beats CloudFront or CloudFlare on a decent day. If I had the money I could use Akamai which I know my ISP has before it even hits the internet, no way I could make my web server faster than that. It…

> Most of my tests on CDNs show they are faster unless the server is hosted in Chicago for me.

For you, with warmed caches. The problem is that most users aren't you and so when they follow a link to example.com their client makes that first DNS request for example.com, starts the connection and TLS handshake, etc. and then sees a request for e.g. cdnjs.com and does that same work again for a different hostname. If (in that example) you were hosting your site on CloudFlare you'd have the same work for the first connection but not the second because it'd already have an open connection by the time your HTML told the client it needed your CSS, JS, etc.

Here's an example: check out https://www.webpagetest.org/result/190125_F0_a1a180631ecebd8... and notice how often you see “DNS Lookup” and ”Initial Connection” times which are a significant chunk of the total request time — and ask yourself whether it would be better for the render-blocking resources to have those times be zero. Especially measure how that works on a cellular or flaky WiFi connection, which is closer to what most people experience in the real world.

As to the gigantic bundle of JavaScript, do some real browser testing and ask whether it's better to wait for the entire resource to be loaded before any code runs — and to repeat that entire transfer every time one byte changes — or only block on the portions needed to render the page. Yes, having 8MB of JavaScript is too much in aggregate but the solution is to use less and use it more intelligently, not slap it all into a big ball of mud.

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

#46

Post by [deleted] »

kevin_b_er wrote: post #28
mankyd wrote: post #5

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."

As such, we know this statement to be false: "With WebSocket HTTP/2 support there is nothing that HTTP/1.1 can do that HTTP/2 cannot"

[deleted]

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

#47

Post by rqs »

pmalynin wrote: post #29
rqs wrote: post #27

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 wil…

Actually HTTP2 upgrade isn’t done with an “Upgrade:” request, but rather with TLS protocol negotiation.

Oh silly me. I've implemented my own HTTP/2 server according to RFC 7540[0]. I forgot in the real world web browsers just send "h2" TLS-ALPN.

[0] https://tools.ietf.org/html/rfc7540#section-3.2

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

#48

Post by peterwwillis »

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.

Post reply on HN