Re:Working Group Last Call: QUIC protocol drafts
by user5994461 on Wednesday June 10, 2020 @01:51PM
(#23479973)
Because 47% of sites run on Cloudflare or similar CDN that started enabling HTTP/2 for non-paying customers.
The application servers running the site do not accept HTTP/2 and most likely can't support it at all (we're a python shop and none of the web frameworks we use could do HTTP/2 when we looked into it).
Re:Working Group Last Call: QUIC protocol drafts
by dathinab on Wednesday June 10, 2020 @02:29PM
(#23480448)
But exactly that's the point. It can be handled transparently in a much easier way then the Ipv6 switch. (Because IPv6 is so much more different then just IPv4 + more addresses, and worse, many people don't realize it and treat it as IPv4 with more addresses which resulted in many problems).
Re:Working Group Last Call: QUIC protocol drafts
by amaccuish on Wednesday June 10, 2020 @01:59PM
(#23480075)
For HTTP/2 at least, I think the main benefit in terms of performance applies to the "last hop", so you still get a more reliable experience even if the connection between the CDN/proxy and app server is http/1.1
Re:Working Group Last Call: QUIC protocol drafts
by dathinab on Wednesday June 10, 2020 @02:34PM
(#23480493)
True, through many web-sites don't have to care about the performance difference.
But for companies like CloudFlare or Googl HTTP/2 means less traffic overhead (multiplexing+header compression) and can save them a lot of bandwidth (aka. money) with that.
Re:Working Group Last Call: QUIC protocol drafts
by secondcoming on Wednesday June 10, 2020 @02:54PM
(#23480691)
Exactly. AWS and GCP load balancers accept HTTP/2 but allow for those requests to be forward to backend instances as HTTP/1 because of this.
Increasingly "corporations" out-source this problem to specialists who are only too pleased to use newer technologies with better performance and collect the same money.