Support UNIX sockets

[Daniel15]

The common use-case for Kestrel in production will be behind a reverse proxy such as Nginx. In cases where the reverse proxy is located on the same machine as the application, connecting via a UNIX socket is more efficient than a TCP socket, as it avoids going through the network layer. Accessing 127.0.0.1 through TCP still needs to initiate a TCP connection and perform handshaking, checksumming, etc, all of which is avoided by using UNIX sockets.

Please add support for UNIX sockets to Kestrel. Current solutions for running ASP.NET on Linux (Mono's FastCGI server) already support UNIX sockets so it would be good to get this into Kestrel too. As far as I know, libuv does support UNIX sockets as Node.js supports them.

More references:

UNIX domain sockets should offer better performance than TCP sockets over loopback interface (less copying of data, fewer context switches).

(http://unix.stackexchange.com/questions/91774/performance-of-unix-sockets-vs-tcp-ports)

The Unix domain sockets are always more efficient and the efficiency benefit is in the 2-3x range.

(https://nicisdigital.wordpress.com/2014/03/03/unix-domain-sockets-vs-loopback-tcp-sockets/)

[ThatRendle]

+1

On Sun, Aug 9, 2015 at 09:54, aspnet/KestrelHttpServer
reply@reply.github.com
wrote:
The common use-case for Kestrel in production will be behind a reverse proxy
such as Nginx. In cases where the reverse proxy is located on the same machine
as the application, connecting via a UNIX socket is more efficient than a TCP
socket, as it avoids going through the network layer. Accessing 127.0.0.1 through TCP still needs to initiate a TCP connection and perform handshaking,
checksumming, etc, all of which is avoided by using UNIX sockets.

Please add support for UNIX sockets to Kestrel. Current solutions for running
ASP.NET on Linux (Mono's FastCGI server) already support UNIX sockets so it
would be good to get this into Kestrel too. As far as I know, libuv does support
UNIX sockets as Node.js supports them.

More references:

UNIX domain sockets should offer better performance than TCP sockets over
loopback interface (less copying of data, fewer context switches).

(
http://unix.stackexchange.com/questions/91774/performance-of-unix-sockets-vs-tcp-ports
[http://unix.stackexchange.com/questions/91774/performance-of-unix-sockets-vs-tcp-ports] )

The Unix domain sockets are always more efficient and the efficiency benefit is
in the 2-3x range.

(
https://nicisdigital.wordpress.com/2014/03/03/unix-domain-sockets-vs-loopback-tcp-sockets/
[https://nicisdigital.wordpress.com/2014/03/03/unix-domain-sockets-vs-loopback-tcp-sockets/] )

—
Reply to this email directly or view it on GitHub [https://github.com//issues/156] .[https://github.com/notifications/beacon/AAK4QlZM2rJM5Y-MKSlztfo_2UJnPv2rks5olwy5gaJpZM4FoK1z.gif]

[davidfowl]

How much more efficient is it? Do you have any data? I can tell you this won't happen in the short term (unless libuv already supports it an it's a simple flag)

[Daniel15]

It looks like Kestrel already uses UNIX sockets (or named pipes on Windows) for IPC (https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Microsoft.AspNet.Server.Kestrel/KestrelEngine.cs#L110) so all the appropriate P/Invoke imports are already there.

How much more efficient is it? Do you have any data?

The second link I posted contained some benchmarks using a simple Node.js server (https://nicisdigital.wordpress.com/2014/03/03/unix-domain-sockets-vs-loopback-tcp-sockets/).

[davidfowl]

@Daniel15 I'm like 90% sure that doesn't do what you think it does nor do the pinvokes already exist.

[Daniel15]

Well, what is that code doing? I'm not very familiar with really low
level library code but to me it looks like IPC over either named pipe (on
Windows) or Unix socket (on Linux). Is that not what it's doing?

Sent from my mobile.
On Aug 9, 2015 3:08 PM, "David Fowler" notifications@github.com wrote:

@Daniel15 https://github.com/Daniel15 I'm like 90% sure that doesn't do
what you think it does nor do the pinvokes already exist.

—
Reply to this email directly or view it on GitHub
#156 (comment)
.

[davidfowl]

It's doing IPC to hand off socket handles to enable load balancing across multiple libuv event loops.

[Daniel15]

I think accepting requests via Unix socket would be similar, you'd just
need to use similar API calls but for accepting incoming connections
wherever it's currently accepting TCP connections. It's just another form
of IPC, except the frontend web server is connecting to Kestrel through it.

Sent from my mobile.
On Aug 9, 2015 3:21 PM, "David Fowler" notifications@github.com wrote:

It's doing IPC to hand off socket handles so enable load balancing across
multiple libuv event loops.

—
Reply to this email directly or view it on GitHub
#156 (comment)
.

[davidfowl]

I think accepting requests via Unix socket would be similar, you'd just
need to use similar API calls but for accepting incoming connections
wherever it's currently accepting TCP connections. It's just another form
of IPC, except the frontend web server is connecting to Kestrel through it.

Are you going to send a pull request then?

[Daniel15]

I might attempt it if I get a chance, I don't have any experience with
libuv though so I'll have to learn that first :)

Are there any design docs explaining how all the components of Kestrel fit
together?

Sent from my mobile.
On Aug 9, 2015 3:25 PM, "David Fowler" notifications@github.com wrote:

I think accepting requests via Unix socket would be similar, you'd just
need to use similar API calls but for accepting incoming connections
wherever it's currently accepting TCP connections. It's just another form
of IPC, except the frontend web server is connecting to Kestrel through it.

Are you going to send a pull request then?

—
Reply to this email directly or view it on GitHub
#156 (comment)
.

[davidfowl]

Nope.

[Daniel15]

I got a basic proof-of-concept working, I'll clean it up and send a pull request soon 👍