HTTP/3: the past, the present, and the future

Re:HTTP/3: the past, the present, and the future by luizfelberti on Thursday September 26, 2019 @01:29PM (#21083228)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by takeda on Thursday September 26, 2019 @01:43PM (#21083355)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by romaniv on Thursday September 26, 2019 @02:01PM (#21083554)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by IfOnlyYouKnew on Thursday September 26, 2019 @04:14PM (#21085028)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by gambler on Thursday September 26, 2019 @04:42PM (#21085308)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by y4mi on Friday September 27, 2019 @06:52AM (#21090464)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by tptacek on Friday September 27, 2019 @12:16AM (#21088354)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by gambler on Friday September 27, 2019 @10:01AM (#21092083)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by tptacek on Friday September 27, 2019 @12:17PM (#21093568)

Correct.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by rurban on Thursday September 26, 2019 @06:53PM (#21086480)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by beetheking on Thursday September 26, 2019 @04:19PM (#21085065)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by takeda on Thursday September 26, 2019 @04:32PM (#21085210)

Better privacy, simplicity etc.

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by krferriter on Thursday September 26, 2019 @09:52PM (#21087670)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by takeda on Friday September 27, 2019 @12:20PM (#21093592)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by vbezhenar on Thursday September 26, 2019 @04:19PM (#21085064)

how session support is different from cookie?

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by takeda on Thursday September 26, 2019 @04:37PM (#21085254)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by zeroimpl on Thursday September 26, 2019 @08:03PM (#21087045)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by thecopy on Thursday September 26, 2019 @04:56PM (#21085448)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by takeda on Friday September 27, 2019 @12:19PM (#21093582)

I think phk said it[1] best

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by lone_haxx0r on Thursday September 26, 2019 @10:01PM (#21087731)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by forgot-my-pw on Thursday September 26, 2019 @01:55PM (#21083489)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by hanakuso on Thursday September 26, 2019 @03:36PM (#21084645)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by dragonwriter on Thursday September 26, 2019 @07:13PM (#21086651)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by amluto on Thursday September 26, 2019 @08:14PM (#21087111)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by marcosdumay on Thursday September 26, 2019 @03:51PM (#21084793)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by mnem on Thursday September 26, 2019 @04:00PM (#21084881)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by ryacko on Thursday September 26, 2019 @06:10PM (#21086119)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by krferriter on Thursday September 26, 2019 @10:03PM (#21087744)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by marcosdumay on Thursday September 26, 2019 @05:19PM (#21085665)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by _klm7 on Thursday September 26, 2019 @06:08PM (#21086107)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by zamadatix on Thursday September 26, 2019 @07:18PM (#21086699)

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.

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by dragonwriter on Thursday September 26, 2019 @07:12PM (#21086637)

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

[ Parent | on HN ]

Re:HTTP/3: the past, the present, and the future by dragonwriter on Thursday September 26, 2019 @10:44PM (#21087945)

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

[ Parent | on HN ]