←back to thread

306 points carlos-menezes | 3 comments | | HN request time: 0s | source
Show context
10000truths ◴[] No.41891318[source]
TL;DR: Nothing that's inherent to QUIC itself, it's just that current QUIC implementations are CPU-bound because hardware GRO support has not yet matured in commodity NICs.

But throughput was never the compelling aspect of QUIC in the first place. It was always the reduced latency. A 1-RTT handshake including key/cert exchange is nothing to scoff at, and the 2-RTT request/response cycle that HTTP/3-over-QUIC offers means that I can load a blog page from a rinky-dink server on the other side of the world in < 500 ms. Look ma, no CDN!

replies(1): >>41891384 #
o11c ◴[] No.41891384[source]
There's also the fact that TCP has an unfixable security flaw - any random middleware can inject data (without needing to block packets) and break the connection. TLS only can add Confidentiality and Integrity, it can do nothing about the missing Availability.
replies(2): >>41891453 #>>41891651 #
1. ChocolateGod ◴[] No.41891651[source]
> There's also the fact that TCP has an unfixable security flaw - any random middleware can inject data (without needing to block packets) and break the connection

I am unsure how this is a security flaw of TCP? Any middleman could block UDP packets too and get the same effect, or modify UDP packets in an attempt to cause the receiving application to crash.

replies(1): >>41891976 #
2. o11c ◴[] No.41891976[source]
In order to attack UDP, you have to block all routes through which traffic might flow. This is hard; remember, the internet tries to be resilient.

In order to attack TCP, all you have to do is spy on a single packet (very easy) to learn the sequence number, then you can inject a wrench into the cogs and the endpoints will reject all legitimate traffic from each other.

replies(1): >>41893618 #
3. jeroenhd ◴[] No.41893618[source]
That's only true if you use the kernel TCP stack. You can replicate the slow QUIC stack and do everything in user mode to get control back over what packets you accept (i.e. reject any that don't fit your TLS stream).