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

We improved the performance of a userspace TCP stack in Go

coder.com

Post reply on HN
Print view View original

11–20 of 133 posts

Re: We improved the performance of a userspace TCP stack in Go

#11

Post by tazjin »

neonsunset wrote: post #8
vlovich123 wrote: post #4

Earlier quoted context omitted.

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…

The quote - is this yet another issue caused by abysmal FFI overhead in Go?

There's nothing related to FFI calls in this quote.

Re: We improved the performance of a userspace TCP stack in Go

#13

Post by cricketlover »

vlovich123 wrote: post #4
tazjin wrote: post #3

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

Agree. Very unclear why they won't simply use a secure socket or why a user space tunnel will be needed.

I surmise that the reason might be that a user space tunnel might be faster (like maybe they can do UDP over TCP or something to gain speed improvements).

Good post nevertheless.

Re: We improved the performance of a userspace TCP stack in Go

#14

Post by syzcowboy99 »

pantalaimon wrote: post #10

The obvious question is: How does it compare to the in-Kernel TCP stack?

gVisor's netstack is still much slower than the kernel's (and likely always will be). The goal of this userspace netstack is not to compete with the kernel on performance, but offer an alternative that is more portable and secure.

Re: We improved the performance of a userspace TCP stack in Go

#17

Post by tptacek »

wmf wrote: post #2

"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, things like Postgres and Redis) without having to build custom serverside "gateways" for each of those protocols.

Re: We improved the performance of a userspace TCP stack in Go

#18

Post by tptacek »

nynx wrote: post #12

Doesn’t creating a raw socket need elevated permissions?

They're not creating raw sockets†. The neat thing about WireGuard is that it runs over vanilla UDP, and presents to the "client" a full TCP/IP interface. We normally plug that interface directly into the kernel, but you don't have to; you can just write a userspace program that speaks WireGuard directly, and through it give a TCP/IP stack interface directly to your program.

† I don't think? I didn't see them say that, and we do the same thing and we don't create raw sockets.

Re: We improved the performance of a userspace TCP stack in Go

#19

Post by parhamn »

I 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.

Re: We improved the performance of a userspace TCP stack in Go

#20

Post by dpeckett »

Really cool to see others hacking on netstack, bit of a shame it's tied up in the gVisor monorepo (and all the Bazel idiosyncracies) but it's a very neat piece of kit.

I've actually been hacking on a similar FOSS project lately, with a focus on building what I'm calling a layer 3 service mesh for the edge. More or less came out of my learned hatred for managing mTLS at scale and my dislike for shoving everything through a L7 proxy (insane protocol complexity, weird bugs, and you still have the issue of authenticating you are actually talking to the proxy you expect).

Last week I got the first release of the userspace router shipped, worth taking a look if you want to play around with a completely userspace and unprivileged WireGuard compatible VPN server.

https://github.com/noisysockets/nsh/blob/main/docs/router.md

Post reply on HN