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

31–40 of 116 posts

Re: Why We Love QUIC and HTTP/3

#31

Post by move-on-by »

As far as I’ve been able to determine, QUIC suffers from the same SNI data leak that existing TLS versions with TCP has. I understand that ESNI is being (or is already?) included in the TLS 1.3 spec, but it’s obviously optional at this point.

Anyways, since QUIC is being touted everywhere as being very secure:

> [QUIC] protects both the data and the transport protocol itself

It seems like missing ESNI as a required feature is a bit of a glaring omission. Does anyone have a better understanding? To me, it seems like a great opportunity to make ESNI required for HTTP/3. Much like how browsers made TLS required for HTTP/2. I would love further insights if anyone has any.

Re: Why We Love QUIC and HTTP/3

#32

Post by tyingq »

windexh8er wrote: post #25
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 TL…

"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?"

I wouldn't mind a progression in http transports that made corporate MITM unworkable. In the past, though, some kind of crappy loophole always makes it possible.

Re: Why We Love QUIC and HTTP/3

#33

Post by vfaronov »

drewg123 wrote: post #28

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

How much of this applies to 1~100KB responses?

Re: Why We Love QUIC and HTTP/3

#34

Post by drewg123 »

vfaronov wrote: post #33
drewg123 wrote: post #28

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

How much of this applies to 1~100KB responses?

1k, not so much since there is no aggregation that can happen there anyway.

100k is not that much different than 100mb, except the TCP window will not be as far open, so TSO will not be as effective.

Note that I work on a CDN that serves large media files, so I'm biased towards that workload.

Re: Why We Love QUIC and HTTP/3

#35

Post by [deleted] »

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…

[deleted]

Re: Why We Love QUIC and HTTP/3

#36

Post by zzzcpan »

windexh8er wrote: post #29
zzzcpan wrote: post #24

Earlier quoted context omitted.

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?

I was just browsing websites that were loading unusually slowly, so did the usual ping/mtr to investigate, which pointed to the router. From there and a bit of tcpdumping the cause turned out to be UDP traffic to Google from another person, who was watching videos I think.

Re: Why We Love QUIC and HTTP/3

#38

Post by simfoo »

drewg123 wrote: post #28

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

Wouldn't pretty much all of that overhead compared to TCP vanish if QUIC was implemented in the kernel?

Re: Why We Love QUIC and HTTP/3

#40

Post by the8472 »

drewg123 wrote: post #28

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

> and sends it 1500b at a time

sendmmsg (or the upcoming io_uring) let you send multiple UDP packets with a single syscall.

Post reply on HN