6 ms·
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
by luizfelberti 7y ago
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.
- takeda 7y agoI wish they would target a real issues of http. For example adding a proper session support and getting rid of cookies.
- romaniv 7y agoDo 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.
- IfOnlyYouKnew 7y agoI 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.
- gambler 7y ago>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?
- y4mi 7y agoDo 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
- tptacek 7y agoThe reality is that Google is working as hard on getting rid of cookies as any organization on the Internet.
- gambler 7y agoWhat 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.
- tptacek 7y agoCorrect.
- vbezhenar 7y agohow session support is different from cookie?
- takeda 7y agoSession support is what cookies were supposed to solve, a proper support would make things simpler and not allow to abuse cookies for other things.
- thecopy 7y agoCould upu clarify what you mean with proper support for sessions?
- takeda 7y agoI think phk said it[1] best [1] https://varnish-cache.org/docs/trunk/phk/http20.html#beating-http-1-1 https://varnish-cache.org/docs/trunk/phk/http20.html#beating...
- zeroimpl 7y agoI suppose you'd rather they'd have named the headers "Session-Id" and "Set-Session-Id"?
- lone_haxx0r 7y agoAnd how would you not allow to abuse this session system? Would you make it more 'transactional' than cookies or what?
- beetheking 7y agoOut of curiosity, what benefit would getting rid of cookies have? And what would be a better way to implement a similar feature?
- takeda 7y agoBetter privacy, simplicity etc. Cookies were a hack to add sessions on top of http.
- krferriter 7y agoI don't understand how moving to another session system would be a benefit. What kind of thing are you proposing here?
- takeda 7y agoPHK 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-http-1-1 https://varnish-cache.org/docs/trunk/phk/http20.html#beating...
- rurban 7y agoThe 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.
- forgot-my-pw 7y agoWhen QUIC just came out, early comments said that it makes CPU usage much higher. Is it still the same case today?
- hanakuso 7y agoAlmost 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.
- dragonwriter 7y agoOver time, especially with HTTP/3 adoption, wouldn't we expect QUIC to get hardware support like TCP, leaving this as a transitional issue?
- amluto 7y agoTCP 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.
- marcosdumay 7y agoAs a rule, discussion of CPU usage of network protocols aren't important for 99% of the people. IO performance is the dominant metric.
- mnem 7y agoI'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.
- 7y ago
- Vesuvium 7y agoI 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.
- dragonwriter 7y ago> 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.
- dragonwriter 7y agoMissed the edit window, I have no idea how “poo” got there.
- zamadatix 7y agoI 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.