I have a problem right now which is that it’s slow to copy large files from one side of the earth to the other. Is this the basis of a solution to that maybe?
What do you think are the current problems contributing to your slow transfers?
We improved the performance of a userspace TCP stack in Go
21–30 of 133 posts
Re: We improved the performance of a userspace TCP stack in Go
#22I have a problem right now which is that it’s slow to copy large files from one side of the earth to the other. Is this the basis of a solution to that maybe?
What do you think are the current problems contributing to your slow transfers?
Window and buffer size is a problem on high latency links.
Re: We improved the performance of a userspace TCP stack in Go
#23I have a problem right now which is that it’s slow to copy large files from one side of the earth to the other. Is this the basis of a solution to that maybe?
No. Profile first. Make sure you've tried tweaking params like batch sizes.
Re: We improved the performance of a userspace TCP stack in Go
#24"Asking for elevated permissions inside secure clusters at regulated financial enterprises or top secret government networks is at best a big delay and at worst a nonstarter." But exfiltrating data with a userspace VPN is totally fine? I'm also wondering why not use TLS.
Every connection you make to a remote service "exfiltrates data". Modern TLS is just as opaque to middleboxes as WireGuard is, unless you add security telemetry directly to endpoints --- and then you don't care about the network anyways, so just monitor the endpoint. The reason you'd use WireGuard rather than TLS is that it allows you to talk directly to multiple services, using multiple protocols (most notably, thin…
I think the point was more that doing this as a way to avoid the red tape of getting permission to open a new connection is odd?
Re: We improved the performance of a userspace TCP stack in Go
#25Earlier quoted context omitted.
Yeah, the optimisations are cool of course, but (maybe due to being unfamiliar with the tool?!) I didn't understand why they can't just `listen(2)`.
It’s answered in the opening paragraph although I’ll admit I’m still unclear. > We are committed to keeping your data safe through end-to-end encryption and to making Coder easy to run across a wide variety of systems from client laptops and desktops to VMs, containers, and bare metal. If we used the TCP implementation in the OS, we’d need a way for the TCP packets to get from the operating system back into Coder for…
I think the key insight behind this approach (and I'm biased here having written something similar) is that the difference between QUIC and (wireguard + network stack) is A LOT less than you might think.
Re: We improved the performance of a userspace TCP stack in Go
#26I don't know anything about Coder, but Gvisor proliferation is annoying. It's a boon for cloud providers, helping them find another way to get a large multiple performance decrease per dollar spent in exchange for questionable security benefits. And I'm seeing it everywhere now.
There are still products from cloud providers that don't use gvisor. Basics like EC2 or GCE. Sounds like you chose the wrong cloud product.
Re: We improved the performance of a userspace TCP stack in Go
#27Earlier quoted context omitted.
Every connection you make to a remote service "exfiltrates data". Modern TLS is just as opaque to middleboxes as WireGuard is, unless you add security telemetry directly to endpoints --- and then you don't care about the network anyways, so just monitor the endpoint. The reason you'd use WireGuard rather than TLS is that it allows you to talk directly to multiple services, using multiple protocols (most notably, thin…
I think the point was more that doing this as a way to avoid the red tape of getting permission to open a new connection is odd?
I understand the impulse, but I think it misconstrues the "red tape" this method avoids. It's sidestepping a quirky OS limitation, which dates back to an era of "privileged ports" and multi-user machines. It's not really sidestepping any sort of modern policy boundary. For instance: you could do the exact same thing with WebSockets (and people do).
Re: We improved the performance of a userspace TCP stack in Go
#28I don't know anything about Coder, but Gvisor proliferation is annoying. It's a boon for cloud providers, helping them find another way to get a large multiple performance decrease per dollar spent in exchange for questionable security benefits. And I'm seeing it everywhere now.
Are you referring to gVisor the container runtime, or gVisor/netstack, the TCP/IP stack? I see more uptick in netstack. I don't see proliferation of gVisor itself. "Security" is much more salient to gVisor than it is to netstack.
Re: We improved the performance of a userspace TCP stack in Go
#29Earlier quoted context omitted.
I think the point was more that doing this as a way to avoid the red tape of getting permission to open a new connection is odd?
I understand the impulse, but I think it misconstrues the "red tape" this method avoids. It's sidestepping a quirky OS limitation, which dates back to an era of "privileged ports" and multi-user machines. It's not really sidestepping any sort of modern policy boundary. For instance: you could do the exact same thing with WebSockets (and people do).
I was thinking websockets; though, I thought those largely hit the same criticisms? That is, tons of things moved to them specifically to avoid any firewall rules about what they were allowed to send over a network.
I'll fully grant that that seems to be the norm for everything browser related. Policies got difficult to install new software, just point your browser to this url and call it a day.
Re: We improved the performance of a userspace TCP stack in Go
#30it's a solution looking for a problem
gVisor definitely solves a problem for me: https://news.ycombinator.com/item?id=39900329