Comment by luizfelberti | Hacker News Reader

Comment by luizfelberti | Hacker News Reader

Parent Full thread

Not aware of benchmarks, but specification-wise I consider HTTP2 to be a regression.

Sure there are good things about it, and many great enhancements, but the larger mechanic of the protocol (the most important part really) has been significantly worsened. I'd rate them as follows:

HTTP3 > HTTP1.1 > HTTP2

QUIC is an amazing protocol, I have no complaints about it, and I'm very happy they decided to go with it for HTTP3. However the decision to make HTTP2 traffic go all through a single TCP socket is horrible, and makes the protocol very brittle under even the slightest network decay or packet loss. Any level of head-of-line blocking severely degrades the entire stream, even for unrelated requests.

Sure it CAN work better than HTTP1.1 under ideal network conditions, but any network degradation is severely amplified, to a point where even for traffic within a datacenter can amplify network distruption and cause an outage.

HTTP3 however is a refinement on those ideas, and gets pretty much everything right afaik.

I wish they would target a real issues of http. For example adding a proper session support and getting rid of cookies.

Do you seriously expect Google and Cloudflate to make basic web development easier when they are making tons of money by "managing" its complexity for others? It's in their best interest to make hosting your own content or using smaller hosting providers absolute hell. Just like it's in Google's best interest to make browsers so complex that other browser devs just give up and Chrome derivatives become the only choice.

I'm predicting that eventually Google will start deranking HTTP 1.1 websites.

I have no idea how cookies are supposed to having an impact on hosting in Google's cloud vs your own hardware, or why Google would care about people where something like that is in any way significant.

>I have no idea how cookies are supposed to having an impact on hosting in Google's cloud vs your own hardware

You do not see how lack of built-in authentication increases complexity of implementing your own website as opposed to "outsourcing" stuff to Gmail, Google Docs and so on? You don't see the zillion "sign in with Google" buttons all over the web? You don't see how cookies are abused for tracking, which benefits Google orders of magnitude more than it would a smaller company?

Do you even know what "sign in with Google" means?

It's in no way easier than adding keycloak authentication for example, which is another (selfhosted) external authentication solution.

Social auth isnt there to make authentication easier for the website owner. He still has to do everything he'd have to do if he didn't use it.

It's there for the users, do they don't need to remember a bazillion passwords

The reality is that Google is working as hard on getting rid of cookies as any organization on the Internet.

What you're saying:

Google, a multi-billion dollar corporation that owns most of the browser and search market share, a company that dictates the next transport-layer protocol we will use - this company struggles to design a session-handling mechanism that would out-compete an ugly hack that Netscape ductaped to HTTP in mid-90s.

Correct.

how session support is different from cookie?

Session support is what cookies were supposed to solve, a proper support would make things simpler and not allow to abuse cookies for other things.

Could upu clarify what you mean with proper support for sessions?

I think phk said it[1] best

[1] https://varnish-cache.org/docs/trunk/phk/http20.html#beating...

I suppose you'd rather they'd have named the headers "Session-Id" and "Set-Session-Id"?

And how would you not allow to abuse this session system? Would you make it more 'transactional' than cookies or what?

Out of curiosity, what benefit would getting rid of cookies have? And what would be a better way to implement a similar feature?

Better privacy, simplicity etc.

Cookies were a hack to add sessions on top of http.

I don't understand how moving to another session system would be a benefit. What kind of thing are you proposing here?

PHK mentioned it[1] when http/2 was being discussed. I pretty much agree with his opinion about it.

[1] https://varnish-cache.org/docs/trunk/phk/http20.html#beating...

The whole idea of HTTP and it's huge win over other server protocols was that it moved session support from the server to the client. You are talking nonsense here. cookies were needed for session persistency eventually.

When QUIC just came out, early comments said that it makes CPU usage much higher. Is it still the same case today?

Almost certainly, but I cannot confirm without benchmarks.

HTTP1/2 = TCP, which has dedicated hardware to offload major parts of the protocol overhead.

QUIC = UDP, but re-implements some features of TCP in software, leaving the CPU to handle things it didn't have to before.

Over time, especially with HTTP/3 adoption, wouldn't we expect QUIC to get hardware support like TCP, leaving this as a transitional issue?

TCP hardware acceleration is generally pretty minimal. The common features are checksum offload and segmentation offload. Checksum offload should generally work for UDP, and I believe that a good UDP implementation can get much of the benefit of segmentation offloading.

As a rule, discussion of CPU usage of network protocols aren't important for 99% of the people. IO performance is the dominant metric.

I'm not sure that follows. Higher CPU usage isn't undesirable because it slows things down (although it may), it prevents battery powered devices working efficiently. Plucking a figure from the air, if QUIC knocks 10% off the battery life of mobiles, that's a hard sell.

Network usage of CPU is tippically well bellow rounding error on a usual system. That's different if you are talking about a static assets CDN or if you are designing networking equipment, but for usual applications, no, it won't make a difference on the battery life of your mobile, page rendering will, not network.

Large percentage of mobile device power consumption is from radio use. Personal tests of phones in airplane mode and without airplane mode show even network keepalive consumes a fair amount of energy.

I plan on purchasing the book as reviewed by this blog post: https://petewarden.com/2015/10/08/smartphone-energy-consumpt...

Sure but if HTTP/3 adds significant processor overhead compared to prior versions and the user isn't getting a noticeable benefit from this cost, they're not going to like it and it sort of seems like a pointless waste of effort.

I have an idea: maybe software engineers and tech managers could take a bit longer to do things, so that they don't have to rush to fix them later. Because it's exactly what HTTP/3 sounds: a rushed fix for the HTTP/2 screw up.

> Because it's exactly what HTTP/3 sounds: a rushed fix for the HTTP/2 screw up.

Wasn't Google already publishing and promoting QUIC before SPDY got adopted as the basis for HTTP/2? SPDY was more conservative because it didn't replace TCP, QUIC wasn't a fix for SPDY being broken, it was a concurrent and less conservative effort poo.

Missed the edit window, I have no idea how “poo” got there.

I think you should look into the histories of HTTP/2 and HTTP/3 before making such claims. These were both in development and deployment as proprietary protocols used by Google (in Chrome and other things) for nearly 10 years before being officially ratified.

Reply on news.ycombinator.com