search

microsoft / reverse-proxy

A toolkit for developing high-performance HTTP reverse proxy applications.
https://microsoft.github.io/reverse-proxy
MIT License
8.43k stars 828 forks source link

Support for alternate transports #1504

Open Tratcher opened 2 years ago

Tratcher commented 2 years ago

What would it take to substitute in an alternate transport between HttpClient and Kestrel for fast local machine proxying? E.g. can we replace Sockets with Named Pipes? How much faster would that be?

samsp-msft commented 2 years ago

On windows, sockets are apparently faster than named pipes - windows did specific work to optimize loopback scenarios.

Having a shared memory system similar to http.sys could be interesting, but the issue would be how to synchronize communications so they know where each side is at.

adityamandaleeka commented 2 years ago

Next steps for this are to make a minimal mockup of these options and then test performance.

Note that this supports work we are trying to do in .NET 7, so while it's not necessary for 1.1 it should be done relatively early in the 7 timeframe.

adityamandaleeka commented 2 years ago

We have a prototype for this but need benchmarks. cc: @sebastienros

davidfowl commented 10 months ago

I think one of the big reasons to support named pipes and unix domain sockets besides the potential speed improvement is the ability to avoid having to pick random ports for destinations (especially when trying to treat YARP as the gateway for many apps on the same compute).

damianh commented 5 months ago

treat YARP as the gateway for many apps on the same compute

Yes please, I have this use case, this feature would be great.

Adding my request for in-mem/in-proc transport would also be useful. I have apps that run multiple aspnet core webapps, each in own hosted service and use yarp as the main entry point and it would be preferable to not have to have multiple listeners on multiple ports.