161–170 of 181 posts
Earlier quoted context omitted.
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?
IDK about "safer", but they will be more numerous and harder to update. (It's not as simple as making sure your kernel is up-to-date.)
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.
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".
Earlier quoted context omitted.
Under the hood, what's happening is that the physical layer is reporting that a packet failed to decode, and the link layer is attempting retransmission at a series of lower and lower fallback rates. It's designed this way because if it fails to deliver a packet, TCP will freak out. There's an RFC about the general case of designing link layers to hide random losses: https://tools.ietf.org/html/rfc3366
Packet loss is an essential part of TCP to determine max. throughput.
Not sure I understand it very well, but that mean http3 is going to use UDP, but does that mean there is going to be a new TCP named TCP/2?
Yes.
> there is going to be a new TCP named TCP/2
No.
There is a new protocol called QUIC, which runs on top of UDP. That is, to routers/firewalls/middleboxes etc. that are not specifically aware of QUIC, it will just look like UDP traffic.
QUIC provides TCP-like features (reliable streams, with retransmissions of dropped packets etc.) plus more. As to why QUIC instead of improving TCP; experience has suggested that TCP has essentially become ossified, meaning that middleboxes will drop TCP packets using new features (see e.g. ECN). Thus in QUIC there's a focus on ossification-resistance (mandatory encryption, and as little information as possible exposed outside the encryption, etc.).
HTTP3 runs on top of QUIC (which runs on top of UDP). Hopefully that makes it clearer.
Earlier quoted context omitted.
Eagerly waiting for you to start sending patches for every system, including proprietary and unmaintained ones, and ensuring that those get included by default.
Why would he start sending patches for them? He already benefits from BBR himself. He doesn’t need to lift everyone else to enjoy the benefits, unlike the IPv4 to IPv6 transition.
If you break TCP, and your answer is that "we'd be ok if every system switched to it", then you'd better start working on switching every system.
Earlier quoted context omitted.
Yes, http.sys is an http server implemented in the Windows Kernel it’s the http server IIS and all other http based windows services use and has an API for 3rd party servers. https://docs.microsoft.com/en-us/iis/get-started/introductio... The point being that there are advantages to implementing a kernel or hybrid mode HTTP server and Microsoft has done it on Windows some other implementations exist but other than MF…
The history of IIS vulnerabilities with in kernel execution and the time it takes to get comprehensive patching seem like pretty substantial disadvantages.
WebRTC is powerful but seems to be limited by not having a good portable server implementation, due to complexity.
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".
Maybe that’s a matter of opinion, but I consider that to be a feature.
I want protocols to remain stable, and not be subject to whatever whims-of-the-month the fruity people at Google LLC comes up with.
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.
TCP is not only used for HTTP