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

Some notes about HTTP/3

blog.erratasec.com

Post reply on HN
Print view View original

71–80 of 181 posts

Re: Some notes about HTTP/3

#71

Post by bb88 »

denormalfloat wrote: post #66
Tuna-Fish wrote: post #18

Earlier quoted context omitted.

The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?

While this is true, a lot of software is not prepared to have connections change IP address. Lot's of networking software works on the idea of a loop which assigns each connection (5-tuple) to a thread. If QUIC were to be more widely used, the association of the connection would have to be linked to the connection identifier in QUIC, which is different than the 5-tuple. Basically, any software that assumed 1 connecti…

> Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten.

Yeah, but I don't think that's a hard thing to do, realistically speaking. Instead of mapping a source ip/port to a destination in the LB it's mapping a QUIC session ID instead.

> This also means the kernel, which could previously steer traffic to a connection onto a single core.

Most likely the kernel will not be rewritten to support this, since QUIC is a user space protocol. Also, the LB might just be able to rewrite the packet so it looks like it came from the LB when it sends it on to the server. The end server would never see the ip address change.

Re: Some notes about HTTP/3

#72

Post by detaro »

nly wrote: post #63

Is it me or does this part make no sense > But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once. TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer…

HTTP requests are small, and a read() call only gets you the data from a single connection, so you get one to few packet(s) worth of data per syscall. In contrast, recvmmsg can get you a large bunch of packets across all "connections" in a single syscall.

Re: Some notes about HTTP/3

#73

Post by john37386 »

baby wrote: post #45
john37386 wrote: post #17

Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats. I feel this move won't make internet a better and safer place, but let's see.

Or let's actually read about QUIC before quickly commenting on it. QUIC uses two mechanism to make sure you cannot do such attacks: * it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1] * it requires the client's first message (client hello) to be padded to at least the size of the s…

Quic is secure and doesn't allow spoofing.

But, since it runs on UDP, a hacker could attack few DNS servers and amplify a UDP attack toward a Quic server. This is true for all reflection and amplification attacks.

Hence, Quic is vulnerable to receive huge amplification attacks +100Gb and soon 1Tbps. It will not make internet a safer and better place.

Even video game companies used to use UDP and they move away because UDP is too dangerous. They now use TCP with a kind of websocket techno to not allow UDP.

Many big enterprises don't allow UDP toward their critical infrastructure.

Re: Some notes about HTTP/3

#74

Post by nly »

detaro wrote: post #72
nly wrote: post #63

Is it me or does this part make no sense > But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once. TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer…

HTTP requests are small, and a read() call only gets you the data from a single connection, so you get one to few packet(s) worth of data per syscall. In contrast, recvmmsg can get you a large bunch of packets across all "connections" in a single syscall.

Good point. Only that makes sense for servers though since for clients (web browsers etc) sockets will be 'connected' and they will still have lots of sockets anyway. They'll still be epoll()ing or similar.

Not withstanding the other benefits of QUIC, the UDP vs TCP thing wrt to crossing the kernel-userspace boundary doesn't seem that significant.

Re: Some notes about HTTP/3

#75

Post by jandrese »

nly wrote: post #63

Is it me or does this part make no sense > But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once. TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer…

The problem is from userland you don't get to decide how much data the kernel hands you with the read call, and by default the kernel will try not to let its buffers fill too much so you end up with a lot of context switches as you read out one window's worth of data at a time.

You could do something similar with TCP if there were kernel support, but the article suggests that putting this much complexity in the kernel's TCP stack is a bad idea because it increases the chance of failure--which can be catastrophic in kernel space. Better to have your web browser/server crash instead of the entire machine.

Re: Some notes about HTTP/3

#76

Post by CharlesW »

nly wrote: post #65

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.

I don't know much about this, so do you mind elaborating? Wouldn't userspace implementations be safer and easier to update as we spend the next few years sussing out security and performance issues?

Re: Some notes about HTTP/3

#77

Post by jandrese »

tyingq wrote: post #21
romed wrote: post #14

Earlier quoted context omitted.

Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are s…

You can tweak rto_min per route, with ip route.

For a webserver won't that just be the default route most of the time? It's effectively a systemwide tune at that point.

Re: Some notes about HTTP/3

#78

Post by detaro »

nly wrote: post #74
detaro wrote: post #72

Earlier quoted context omitted.

HTTP requests are small, and a read() call only gets you the data from a single connection, so you get one to few packet(s) worth of data per syscall. In contrast, recvmmsg can get you a large bunch of packets across all "connections" in a single syscall.

Good point. Only that makes sense for servers though since for clients (web browsers etc) sockets will be 'connected' and they will still have lots of sockets anyway. They'll still be epoll()ing or similar. Not withstanding the other benefits of QUIC, the UDP vs TCP thing wrt to crossing the kernel-userspace boundary doesn't seem that significant.

For clients these numbers don't matter as much, many thousands of packets per second doesn't really happen to them. For a server with a fast pipe it does happen. I hope one of the big providers will share numbers. I don't think many of them actually use user-space stacks with TCP, would be interesting if QUIC improves performance measurably.

Re: Some notes about HTTP/3

#79

Post by [deleted] »

TazeTSchnitzel wrote: post #70
nly wrote: post #63

Is it me or does this part make no sense > But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once. TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer…

They're not talking about receiving TCP packets there.

[deleted]

Re: Some notes about HTTP/3

#80

Post by ris »

nly wrote: post #65

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.

But the whole point of QUIC is that it is a userspace implementation. From the QUIC viewpoint (and I take no sides in this) kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems. This is why they found they couldn't "just improve TCP".
Post reply on HN