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

31–40 of 62 posts

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

#31

Post by Kalium »

eeeeeeeeeeeee wrote: post #22
skywhopper wrote: post #16

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.

I'm not sure why you're being downvoted. The financial/resource burden of learning new technologies should be considered and weighed against the advantages it delivers over the old technology.

You're right! Technology should under no circumstances by adopted blindly. Costs and opportunities should always be weighed carefully.

Given that TLS is mention in-line as also breaking this point, I think it perhaps possible that some readers might be of the opinion that the decision-making process you call for has already been conducted. Since TLS breaks the standard of "it is human-eyeball-friendly with telnet/netcat", HTTP/2 is little different in the minds of many.

Your caution is right and apt. The history of computing is littered with technologies that were unready, unsuitable, or otherwise not fit for purpose when adopted.

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

#32

Post by jabart »

acdha wrote: post #19
jabart wrote: post #15

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

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 is not a performance de-optimization. If you have 8mb of JS, sure you should break that up, but you have 8mb of JS and that is your first true problem. I aim for about 400kb or less of JS, on a marketing website it may change once a quarter, so I really don't care and they are all first time users anyway. For a web application, I also don't care because if they are mobile they need that in one request, gziped to like 40kb, so the hours it would take to optimize for the single byte changed is still a performance budget of 80ms.

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

#33

Post by rando231 »

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.

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

#34

Post by jabart »

eeeeeeeeeeeee wrote: post #17
jabart wrote: post #15

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

Yep. I haven't seen more recent studies on this, but I do remember a lot of use cases and benchmarks I read where if your user base was on high-latency or unreliable internet connections (packet loss, even minor), HTTP/2 would be slower than 1. Here is a good summary of the issue: https://www.twilio.com/blog/2017/10/http2-issues.html Like you mentioned, HTTP is slowly moving towards UDP instead of TCP (QUIC protocol)…

These are really great documents to reference, thank you for posting them. I'm going to send them to a few dev teams I work with to share the knowledge.

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

#35

Post by muthdra »

crankylinuxuser wrote: post #12
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."

I'm guessing they're not carving out a niche for self-signed certs? I think that would have been a fair balance, of setting a "this is a self-signed cert" instead of the current "YoUr WeBsIte IS UNSECURED" (which isn't actually true). Accepting and indicating self signed would also be handy in Tor's onion sites, since the only companies that will issue certs require EV2 and all your info and a pile of money. And Onio…

Dude, we don't use certs because we think they're cute. We use certs to guarantee cross-checking validation of resources. If you make me a certificate for your own website, I don't care how beautiful that cert is, it is also useless for cross-checking.

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

#36

Post by crankylinuxuser »

pilif wrote: post #20
crankylinuxuser wrote: post #12

Earlier quoted context omitted.

I'm guessing they're not carving out a niche for self-signed certs? I think that would have been a fair balance, of setting a "this is a self-signed cert" instead of the current "YoUr WeBsIte IS UNSECURED" (which isn't actually true). Accepting and indicating self signed would also be handy in Tor's onion sites, since the only companies that will issue certs require EV2 and all your info and a pile of money. And Onio…

> (which isn't actually true) how would I discern your self-signed certificate from the one served by the person arp-spoofing the gateway in a Starbucks?

No cert chain for starters. The better answer here is some sort of "self signed standard data" for non-CA certs. But right now, testing in a NAT using HTTP2 is a ugly nonstarter.

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

#38

Post by bastawhiz »

rando231 wrote: post #33

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.

There's nothing stopping you from having one connection per request with HTTP/2. You could build your software to simply have the same behavior as HTTP/1.1 with keep-alive

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

#39

Post by pilif »

crankylinuxuser wrote: post #36
pilif wrote: post #20

Earlier quoted context omitted.

> (which isn't actually true) how would I discern your self-signed certificate from the one served by the person arp-spoofing the gateway in a Starbucks?

No cert chain for starters. The better answer here is some sort of "self signed standard data" for non-CA certs. But right now, testing in a NAT using HTTP2 is a ugly nonstarter.

> No cert chain for starters.

why would the person who arp-spoofs the gateway in the Starbucks not be able to fetch your self-signed cert chain and mint their own matching chain with the exact same metadata (but of course differing keys)?

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

#40

Post by skywhopper »

acdha wrote: post #26
skywhopper wrote: post #16

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.

> 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?
Post reply on HN