Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Love QUIC and HTTP/3

fastly.com

Post reply on HN
Print view View original

11–20 of 116 posts

Re: Why We Love QUIC and HTTP/3

#11

Post by lclarkmichalek »

kijin wrote: post #10
cdmckay wrote: post #8

Earlier quoted context omitted.

The article mentions gives an example of why it’s difficult to improve TCP further. TCP Fast Open was standardized 8 years ago and is barely used. This is because updating TCP requires kernel updates, which just isn’t going to happen on most mobile devices. Thus, moving the protocol to userspace makes a lot of sense.

That doesn't sound like a particularly convincing reason. In order for mobile devices to benefit from HTTP/3, commonly used HTTP client libraries will have to be updated. Which usually happens on a similar timescale as kernel updates anyway.

Much easier to update an app and its HTTP library than mobile device kernels. Particularly given how a large proportion of mobile devices are unsupported and won't get kernel upgrades any more.

Re: Why We Love QUIC and HTTP/3

#12

Post by cdmckay »

kijin wrote: post #10
cdmckay wrote: post #8

Earlier quoted context omitted.

The article mentions gives an example of why it’s difficult to improve TCP further. TCP Fast Open was standardized 8 years ago and is barely used. This is because updating TCP requires kernel updates, which just isn’t going to happen on most mobile devices. Thus, moving the protocol to userspace makes a lot of sense.

That doesn't sound like a particularly convincing reason. In order for mobile devices to benefit from HTTP/3, commonly used HTTP client libraries will have to be updated. Which usually happens on a similar timescale as kernel updates anyway.

An app can control which HTTP library it’s using and even bypass the built in one on the mobile device. That’s not possible in the case of TCP.

So no, it’s not the same.

Another issue they mention in the article is middleboxes, which basically will never be upgraded, and will never support new TCP features.

Re: Why We Love QUIC and HTTP/3

#13

Post by michaelt »

lclarkmichalek wrote: post #11
kijin wrote: post #10

Earlier quoted context omitted.

That doesn't sound like a particularly convincing reason. In order for mobile devices to benefit from HTTP/3, commonly used HTTP client libraries will have to be updated. Which usually happens on a similar timescale as kernel updates anyway.

Much easier to update an app and its HTTP library than mobile device kernels. Particularly given how a large proportion of mobile devices are unsupported and won't get kernel upgrades any more.

The thing is, there are two possible extremes:

1. Our design is complete, error-free and designed to stand the tests of time. It will be in common use, largely unchanged, in 40 years time. The TCP of the 2010s. There is widespread industry support. We want to move to the application layer to ease the initial roll-out.

2. Our design will need to change every few years, even we authors don't think it's finished. This is a Google-only project and most vendors are refusing to support it as they think it's badly designed crap. The ActiveX of the 2010s. We want to move to the application layer so we can force it through without anyone else's support.

Where are we on the spectrum between those two options? I don't know.

Re: Why We Love QUIC and HTTP/3

#14

Post by carnagii »

ioquatix wrote: post #2

aka let's just put everything in the application layer because solving it at the protocol layer is too difficult.

It is not necessarily bad. Moving complex stuff to user space can be good sometimes. There are things this would break like splice but also allows much tighter integration with applications because you can get and set state without system calls. As you layer on more complex app level adaptations to connection failures having it in user space means the client has the same capabilities irregardless of platform which is important so that both client and server can make mutual complimentary adaptations to the same conditions. This stuff is not really needed for web, it is mostly video conferencing type stuff that gets the biggest benefit. Googs new game service for instance.

Re: Why We Love QUIC and HTTP/3

#15

Post by yardstick »

ralphm wrote: post #6
ioquatix wrote: post #2

aka let's just put everything in the application layer because solving it at the protocol layer is too difficult.

Is this not a valid approach then? The issues of ossification and strict allowance for just known protocols appear to be big enough to cause things like SCTP to not have a viable, widespread use in their future.

I believe that we will see ossification of QUIC eventually too. TCP has been around for decades, anything around that long is going to have issues rolling out new changes in a backwards compatible way. TLS 1.3 and the lengths it had to go to with backwards compatibility with middleboxes is another good example.

I hope that QUIC has used these lessons from TCP and TLS to make changes in the future as easy and effective as possible, but I’m sure it’ll still have its limits.

Re: Why We Love QUIC and HTTP/3

#16

Post by daurnimator »

cdmckay wrote: post #8
ioquatix wrote: post #2

aka let's just put everything in the application layer because solving it at the protocol layer is too difficult.

The article mentions gives an example of why it’s difficult to improve TCP further. TCP Fast Open was standardized 8 years ago and is barely used. This is because updating TCP requires kernel updates, which just isn’t going to happen on most mobile devices. Thus, moving the protocol to userspace makes a lot of sense.

I think TCP fast open is a bad example for this. None of the common socket libraries that I know (never mind http libraries) have gained support for TCP fast open yet.

Re: Why We Love QUIC and HTTP/3

#17

Post by tyingq »

Hopefully vendors like Forcepoint are trying to keep up. The first rollout of QUIC worked terribly in a lot of corporate environments because these MITM content filtering solutions didn't pay attention.

Re: Why We Love QUIC and HTTP/3

#18

Post by zamadatix »

cdmckay wrote: post #8
ioquatix wrote: post #2

aka let's just put everything in the application layer because solving it at the protocol layer is too difficult.

The article mentions gives an example of why it’s difficult to improve TCP further. TCP Fast Open was standardized 8 years ago and is barely used. This is because updating TCP requires kernel updates, which just isn’t going to happen on most mobile devices. Thus, moving the protocol to userspace makes a lot of sense.

> Thus, moving the protocol to userspace makes a lot of sense.

Raw IP sockets are accessible from the same userspace facing APIs as e.g. UDP sockets and don't require climbing up the stack. Unfortunately operating systems started to consider custom protocol implementations security risks but rather than reverse that thinking we've just continued to abstract up past it.

In reality I think "where it is implemented in code" was a small portion of QUICs design choices compared to "IPv4 NAT & external firewalling has ossified protocols" which is a similar story of "just abstact up to avoid the issues". Unfortunately in that case I don't think abstracting up isn't as permanent a solution as it was on the OS side.

Re: Why We Love QUIC and HTTP/3

#19

Post by zzzcpan »

tyingq wrote: post #17

Hopefully vendors like Forcepoint are trying to keep up. The first rollout of QUIC worked terribly in a lot of corporate environments because these MITM content filtering solutions didn't pay attention.

What reason MITM solutions have to support more client protocols that terminate on a local network?

Re: Why We Love QUIC and HTTP/3

#20

Post by tyingq »

zzzcpan wrote: post #19
tyingq wrote: post #17

Hopefully vendors like Forcepoint are trying to keep up. The first rollout of QUIC worked terribly in a lot of corporate environments because these MITM content filtering solutions didn't pay attention.

What reason MITM solutions have to support more client protocols that terminate on a local network?

If it just drops QUIC requests, then the browser has to do 2 parallel requests, one HTTP, one QUIC, and pick the winner. I believe that's what Chrome does now.
Post reply on HN