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

21–30 of 116 posts

Re: Why We Love QUIC and HTTP/3

#21

Post by bdonlan »

zamadatix wrote: post #18
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.

> 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 c…

Raw sockets don't really allow for multiple applications to use the same custom protocol. If, for example, chrome and firefox were both running, which gets packets destined for the QUIC transport protocol? The kernel wouldn't know; without the UDP header it can't distinguish flows.

Likewise NAT devices typically support UDP flows today due to their prevalence in games, but if you introduce a new transport protocol at the IP layer, they wouldn't be able to identify which flow (and therefore which NATed endpoint) the packet is destined for.

Re: Why We Love QUIC and HTTP/3

#22

Post by jabl »

felixhandte wrote: post #9

This is a timely post, since IETF 104 is happening this week in Prague[1]. The QUIC working group will be meeting on Tuesday and Wednesday to make progress on standardization[2]. [1] https://datatracker.ietf.org/meeting/104/agenda.html [2] https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

What about QUIC and L4S / TCP Prague? Are people working on something equivalent for QUIC as well, or are they reimplementing TCP Reno in QUIC?

Re: Why We Love QUIC and HTTP/3

#23

Post by chrisweekly »

michaelt wrote: post #13
lclarkmichalek wrote: post #11

Earlier quoted context omitted.

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 i…

Great question!

Re: Why We Love QUIC and HTTP/3

#24

Post by zzzcpan »

tyingq wrote: post #20
zzzcpan wrote: post #19

Earlier quoted context omitted.

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.

So, no reason then. That overhead is like microseconds and you can disable it if it bothers you (you have to configure web browsers for MITM anyway).

I actually disable QUIC myself, because I've noticed it slows everything down too much on some home routers.

Re: Why We Love QUIC and HTTP/3

#25

Post by windexh8er »

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.

It will be interesting because it's a problem for all middleboxes that do any sort of deep packet inspection. Most of the devices that fall into this category today leverage many performance gains made by the assumption that 1) the majority of network layer traffic is TCP and 2) they have access to certain levels of metadata for free.

Things are changing and getting a lot more difficult with HTTP/3 (IETF QUIC) and TLS1.3. Many vendors are claiming TLS1.3 support today, but the interesting thing is nobody is talking about the dismal performance implications it has on packet processing. With TLS1.3 and without HTTP/3 all sessions must use PFS for transform selection. And on top of it with 0RTT if a client gets to the server before the middlebox does - then, I believe, it becomes a failure scenario at the end user experience. Security vendors like Fortinet, Forcepoint, Palo Alto Networks and Cisco are all up against the wall long term. Consider they sell these devices for millions of dollars per device in larger variations. Now we're moving back to taking a device that claims tens to hundreds of gigabits of deep packet processing to, hundreds? They won't share the performance impact with customers - because that will impact financials, which will flow down to stock price, etc, etc. I feel as though companies that bank on the middlebox (ie NGFW) know of the impending apocalypse but are choosing, collectively, to stay quiet. Cisco did have an article that indirectly admitted this but only in context of TLS1.3 and not HTTP/3 [0].

What is the general consensus of others as we see HTTP/3 gain popularity? None of the aforementioned vendors do MitM decrypt with Google properties riding Google QUIC today, as ultimately they can't. The "security" coverage then moves to software / endpoints to pick up the pieces (where plaintext traffic is still available). But in the meantime I feel like the consumer of these products is being told nothing for the sole upside of financials. I used to be a huge proponent of NGFW and the visibility they brought. However I feel as though those devices now give a very high false sense of security as they are only able to catch very low hanging fruit and are simple to bypass [1]. I'm curious what the collective here thinks about the futures of hardware network security, and with that even SaaS based (eg ZScaler).

TL;DR If you're a CISO/CSO is it now a fools errand to continue to invest money in middleboxes with the strong stronger crypto enforcement on the horizon?

[0] https://blogs.cisco.com/security/tls-1-3-and-forward-secrecy... [1] https://http-evader.semantic-gap.de/

Re: Why We Love QUIC and HTTP/3

#26

Post by josteink »

cdmckay wrote: post #12
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.

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.

Nor will they support new HTTP-features.

Re: Why We Love QUIC and HTTP/3

#27

Post by josteink »

blackflame7000 wrote: post #7
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 runs over UDP so they did go back to the protocol layer when designing a solution. Thats the whole point is to fix the tcp halt and retransmit delay when a packet gets lost.

So it will be firewalled by most corporate firewalls then?

Hardly sounds useful.

Re: Why We Love QUIC and HTTP/3

#28

Post by drewg123 »

QUIC costs something like 2x to 4x as much CPU time to serve large files or streams per byte as compared to TCP. This is because the anti-middlebox protections also mean that modern network hardware and software offloads that greatly reduce CPU time cannot work with QUIC. When combined with the fact that QUIC is userspace, that's just deadly for performance. I'm talking about TSO, LRO (aka GRO), kTLS, and kTLS + hw encryption.

Let's compare a 100MB file served via TCP to the same file served via QUIC.

  TCP:
  - web server sends 2MB at a time, 50x times, via async sendfile (50 syscalls & kqueue notifications)
  - kernel reads data from disk, and encrypts.  The data is read once and written once by KTLS in the kernel.
  - TCP sends data to the NIC in large-sh chunks 1.5k to 64k at a time, lets say an average of 16k.  So the network stack runs 6250 times to transmit.
  - The client acks every other frame, so that's 33333 acks.  Let's say they are collapsed 2:1 by LRO, so the TCP stack runs 16,666 times to process acks

  QUIC:
  - web server mmaps or read()'s the file and encrypts it in userspace and sends it 1500b at a time (1 extra memory copy & 66,666 system calls)
  - UDP stack runs 66,666 to send data
  - UDP stack runs 33,333 number of times to receive QUIC acks (no idea what the aggregation is, lets say 2:1) 
  - kernel wakes up web server to process QUIC acks 33,333 times.
So for QUIC we have:

  - 4x as many network stack traversals due to the lack of TSO/LRO.
  - 1000x as many system calls, due to doing all the packet handing in userspace
  - at least one more data copy (kernel -> user) due to data handling in userspace.
Some of these can be solved, by either moving QUIC into the kernel, or by using a DPDK-like userspace networking solution. However, the lack of TSO/LRO even by itself is a killer for performance.

Disclaimer: I work on CDN performance. We've served 90Gb/s with a 12-core Xeon-D. To serve the same amount of traffic with QUIC, you'd probably need multiple Xeon Gold CPUS. I guess that Google can afford this.

Re: Why We Love QUIC and HTTP/3

#29

Post by windexh8er »

zzzcpan wrote: post #24
tyingq wrote: post #20

Earlier quoted context omitted.

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.

So, no reason then. That overhead is like microseconds and you can disable it if it bothers you (you have to configure web browsers for MITM anyway). I actually disable QUIC myself, because I've noticed it slows everything down too much on some home routers.

> I actually disable QUIC myself, because I've noticed it slows everything down too much on some home routers.

I'm curious how you measured and came to this conclusion since the design and most all metrics claim the opposite? And are you sure it isn't a bufferbloat issue rather than QUIC?

Re: Why We Love QUIC and HTTP/3

#30

Post by tyingq »

zzzcpan wrote: post #24
tyingq wrote: post #20

Earlier quoted context omitted.

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.

So, no reason then. That overhead is like microseconds and you can disable it if it bothers you (you have to configure web browsers for MITM anyway). I actually disable QUIC myself, because I've noticed it slows everything down too much on some home routers.

No reason for an MITM to try and support HTTP/3 on a reasonable timeline, and avoid making their customers figure it out on their own? Er, okay.

Edit: Ahh...read some of your other posts. You aren't a fan of HTTP/3, which puts your comment in context for me.

Post reply on HN