Working Group Last Call: QUIC protocol drafts

Re:Working Group Last Call: QUIC protocol drafts by cryptonector on Wednesday June 10, 2020 @11:08AM (#23477868)

HTTP/2 and HTTP/3 do not change the semantics of HTTP. That means you can run reverse proxies to server HTTP/1 services as /2 and/or /3 and vice-versa. As a result the transition will be a lot easier than the transition to IPv6. I expect that the transition in corporate networks will be faster -- the opposite of the IPv6 case -- because there is a lot of appeal to HTTP/3.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by the_duke on Wednesday June 10, 2020 @11:14AM (#23477951)

> because there is a lot of appeal to HTTP/3

I thought the primary appeal of HTTP/3 is for mobile clients, and bad connections in general, because it circumvents TCP head of line blocking and connections can persist across networks.

That doesn't feel terribly relevant in corporate networks.

(not disputing that it's not comparable to the v6 transition)

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by cptskippy on Wednesday June 10, 2020 @12:04PM (#23478638)

His claim of corporate appeal is completely unsubstantiated and I think when he says corporate he isn't referring to enterprise.

Enterprises largely won't give two shits about HTTP/3.

Just last week I took ownership of another department's decade old app written in VB.NET WinForms. The former dev team was putting the finishing touches on the C# WebForms refactor. It's been interesting taking a step back in time to Dev practices from 2008.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by cryptonector on Wednesday June 10, 2020 @12:15PM (#23478797)

The appeal of H3 is smaller memory footprint.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by npiit on Wednesday June 10, 2020 @11:50AM (#23478452)

The transition will be faster because of that a big chunck of the internet is gatewayed through a few big players (e.g. Cloudflare, AWS, CDNs, the new wave of static deployment services like Netlify and Zeit.co, big websites like google, facebook, netflix, etc...)

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by user5994461 on Wednesday June 10, 2020 @11:46AM (#23478403)

You realize that HTTP/2 is still nowhere near to being adopted by corporations? It's really far fetched to plan HTTP/3 and expect any adoption.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by uluyol on Wednesday June 10, 2020 @03:31PM (#23481079)

Most _domains_ may not support HTTP/3, but I fully expect that within a few years most _traffic_ will be HTTP/3.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by tialaramex on Wednesday June 10, 2020 @01:28PM (#23479716)

Qualys' "SSL Pulse" says 47.1% of surveyed sites offered HTTP/2 and about 30% of surveyed sites offer TLS 1.3

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.

[ Parent | on HN ]

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

[ Parent | on HN ]

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

[ Parent | on HN ]

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

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by shrdlu2 on Wednesday June 10, 2020 @03:47PM (#23481233)

In fact AWS ALB does not even support HTTP/2 on the backends which is really annoying.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by cryptonector on Wednesday June 10, 2020 @12:14PM (#23478787)

The fact that UDP involves much smaller PCBs than TCP alone will drive adoption of HTTP/3 because it will free up a fair bit of memory.

More availability of HTTP version gateways in load balancers and other reverse proxies is all that's needed, and that's coming along.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by moreati on Wednesday June 10, 2020 @04:58PM (#23482031)

Protocol Control Block for anyone else wondering https://www.oreilly.com/library/view/tcpip-illustrated/02016...

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by the8472 on Wednesday June 10, 2020 @06:09PM (#23482750)

You still need to keep your unacknowledged data buffered somewhere. If the kernel isn't holding it then it's in userspace.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by microcolonel on Wednesday June 10, 2020 @01:07PM (#23479468)

More specifically no PCB, for UDP itself.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by cryptonector on Wednesday June 10, 2020 @06:10PM (#23482755)

It's not nil. For "connected" UDP sockets, it's smaller than TCP's, but not nil because, well, buffers. And for non-connected UDP sockets there's still buffers. The main thing is that you can have much less buffer space because you might always be willing to drop packets. Ultimately you can have much lower memory pressure from those buffers and the smaller PCBs.

[ Parent | on HN ]

Re:Working Group Last Call: QUIC protocol drafts by awirth on Wednesday June 10, 2020 @06:41PM (#23483035)

This is only mostly true, they do subtly change some semantics.

As a motivational example, it is possible to encode a colon in a header name in http2 but not in http1.1, and this does not violate the RFC which only blacklists "\0\r\n".

[ Parent | on HN ]