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

51–60 of 62 posts

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

#51

Post by protonfish »

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.

Hopefully we all agree that maintainability is the most important quality of code (after successfully performing the feature that it was meant to implement.) Writing readable, modular code is key to getting the most out of developer time and preventing bugs. With that in mind HTTP/2 is a huge step backwards.

And for what? Slightly faster speeds? This is a non-problem. When I see a slow site and view the network performance to discover why (using tools that would most likely not work under HTTP/2) here is what I inevitably see:

* Massive video and JavaScript for ads

* JavaScript tracking code

* Massive HTTP headers with unnecessary cookies

* Unnecessary, bloated JavaScript libraries

* Unnecessary, bloated CSS files

* Gratuitous unoptimized images

* No attempt at optimizing HTTP caching settings

* No attempt at HTTP compression (gzip)

These will still be the main bottlenecks with HTTP/2.

HTTP/2 solves no problem and makes network application development more difficult by making the network calls opaque and gratuitously complex.

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

#52

Post by zzzcpan »

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…

If bundling everything and rendering on the backend doesn't provide a better user experience than breaking everything and loading asynchronously, your website is already too fat and you should focus on fixing that first. The things that shouldn't be bundled are content images, and they don't block rendering.

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

#53

Post by jabart »

acdha wrote: post #44
jabart wrote: post #32

Earlier quoted context omitted.

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

Those DNS lookup times for Azure are in fact terrible, no DNS query should take 400ms. You can pre-lookup DNS using html header tags, but nothing fixes a slow DNS query like that, that is a failure of the Azure Edge DNS servers.

I do real browser testing, and have Real User Monitoring setup to prove the results. Page load times from 600ms to 1.2s reported from the clients browser. I measure and test our app on 3g connection including the high packet loss 4g signal I get at my house. The point of my comment was that HTTP2 is not a fix all issues with performance on a site. The Webpagetest result would not have loaded in 2 seconds if they switched to HTTP2. Its 400 resources is what is slowing it down, not http/1.

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

#54

Post by crankylinuxuser »

pilif wrote: post #39
crankylinuxuser wrote: post #36

Earlier quoted context omitted.

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)?

Then what's your proposal for NATted, self-contained (no gateway), and Tor Onion networks?

Sure, if I have a public IP and DNS records pointing towards it, I'm served by LE or a multitude other vendors. But that's a small number of machines on any network.

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

#55

Post by acdha »

jabart wrote: post #53
acdha wrote: post #44

Earlier quoted context omitted.

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

Those DNS lookup times for Azure are in fact terrible, no DNS query should take 400ms. You can pre-lookup DNS using html header tags, but nothing fixes a slow DNS query like that, that is a failure of the Azure Edge DNS servers. I do real browser testing, and have Real User Monitoring setup to prove the results. Page load times from 600ms to 1.2s reported from the clients browser. I measure and test our app on 3g con…

Look at the times for Google where they loaded jQuery: because it's using an external CDN, the initial connection time (80ms) is greater than the total transfer time (69ms) on a relatively fast connection. It would be faster to serve it from your own server and then you also don't have to deal with things like SRI to maintain the same level of security.

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

#56

Post by acdha »

commandlinefan wrote: post #30

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

That's a tricky comparison because using IPv6 required updates to the client, server, and every box in between whereas HTTP/2 only requires the endpoints to be updated and has a graceful degradation path in most cases. Unsurprisingly, it's already far more common than IPv6 because you don't have to go to every enterprise on the planet and tell them to fix things even their network team is afraid to touch.

In contrast, HTTP/2 rapidly hit much higher numbers thanks to Firefox and Chrome shipping support via automatic updates. When CloudFlare deprecated SPDY about a year ago they were already seeing adoption numbers just under 70%:

https://blog.cloudflare.com/deprecating-spdy/

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

#57

Post by hultner »

pgjones wrote: post #8
bpicolo wrote: post #7

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

Wow, any chance you could write up the throughput gain? It would be great to see some real production numbers. Thanks for the comments.

I’ve looked at quart and it looks interesting but is there much point to running an async webserver for APIs mainly reliant on db-access if we use SQLAlchemy for database connections?

I’m under the impression that since the db stuff still is sync/blocking we won’t win much by running an asgi server instead of WSGI.

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

#58

Post by altmind »

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.

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

#59

Post by bpicolo »

hultner wrote: post #57
pgjones wrote: post #8

Earlier quoted context omitted.

Wow, any chance you could write up the throughput gain? It would be great to see some real production numbers. Thanks for the comments.

I’ve looked at quart and it looks interesting but is there much point to running an async webserver for APIs mainly reliant on db-access if we use SQLAlchemy for database connections? I’m under the impression that since the db stuff still is sync/blocking we won’t win much by running an asgi server instead of WSGI.

Give peewee-async as shot if you'd like async DB access as well.

https://peewee-async.readthedocs.io/en/latest/

Looks like Gino is a new project trying to bake asyncio ORM on top of sqlalchemy core: https://github.com/fantix/gino

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

#60

Post by nybble41 »

crankylinuxuser wrote: post #54
pilif wrote: post #39

Earlier quoted context omitted.

> 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)?

Then what's your proposal for NATted, self-contained (no gateway), and Tor Onion networks? Sure, if I have a public IP and DNS records pointing towards it, I'm served by LE or a multitude other vendors. But that's a small number of machines on any network.

If you have a public DNS entry then you can get a certificate from Let's Encrypt using the DNS verification method, even if the name points to a private IP address. DANE would also be an option if it (and DNSSEC) were more widely implemented.

Local name resolution (mDNS) could take a page from what Tor already does and encode the public key fingerprint into the domain name. If the key uniquely matches the domain (perhaps just the first part, e.g. b32-key-hash.friendly-name.local) then you automatically get the equivalent of domain validation. While, by itself, this doesn't prove that you're connected to the right domain, by bookmarking the page and visiting it only through that bookmark you would get the equivalent of trust-on-first-use. Browsers would just need to recognize this form of domain name and validate the key against the embedded hash instead of an external CA.

Post reply on HN