High Performance TCP Proxy Server
partow.net
partow.net
For example, it doesn't relay FINs between connections, doesn't disable Nagle algorithm on the upstream socket, doesn't wait for pending writes to complete before tearing down the connection, doesn't handle congestion at all (potentially leading to unbound memory use), etc.
nginx and apache only do HTTP(S). Don't support TCP.
That's not entirely accurate. For nginx, for example, there's the ngx_stream_core_module[1]. It's not particularly well-documented though, so I don't know much about it.
[1]: https://nginx.org/en/docs/stream/ngx_stream_core_module.html
For the sake of god, please don't have your entire site run on experimental software like that. ^^
Linux: iptables -t nat -A PREROUTING -p tcp -s 192.168.20.200/0 -d 192.168.0.100/0 --dport 8080 -j REDIRECT --to-ports 20000
Windows: netsh interface portproxy add v4tov4 listenaddress=192.168.20.200 listenport=8080 connectaddress=192.168.0.100 connectport=20000 protocol=tcp
Still, I agree.
-s 192.168.20.200/0 -d 192.168.0.100/0
That sounds wrong.You probably meant /24 or /32. Or you meant to not write anything to not filter it at all.
Use Keepalived (http://www.keepalived.org/) for HA and health checking or use Gorb (https://github.com/kobolog/gorb) and you can dynamically change services / backends using a REST API.
Around half the code in this implementation could probably be removed by the realisation that, after a connection is established, both ends are completely symmetric: all it needs to do is try to read from A and write to B, then try to read from B and write to A. If A closes, close B. If B closes, close A.
It's shutdown() writes on EOFs, not close, with refcounting to also do close() when EOFs were detected on both directions (I also have written a TCP proxy). But yeah, TCP proxies are trivial, would be more interesting to see something like a tunneling proxy that sends data over multiple connections to maximize performance.
Probably, though, it's best to start with why you would want to do that. You could be, for example, trying to solve something where a pub/sub model would work better. Or just two separate apps, on different ports. What's driving the idea of multiplexing?
If A closes or errors out, the proxy should first push out any pending data and only then close B.
The same goes for when A sends a FIN - it should flush any data queued at application level before calling shutdown() on B's socket.
If A becomes unwritable, it should stop reading from B.
On Linux it uses an epoll native driver and is asynchronous. The framework makes it possible to write proxies in a few lines.
If you want to beat netty by a significant margin you'll probably need to use kernel bypass
Netty is also a lot easier to extend and more portable
If I had to pick something in the C/C++ space to implement a custom proxy, I would probably stick to something where I could find a similar list of established high volume real world users. Facebook's Proxygen, or some customized HAProxy maybe.
As for performance, a reproducible benchmark is the minimum requirement to even start the conversation.
(Similarly, because I don't really care about JVM versus not, HAProxy--which I'd probably use for something like this because I have better things to do with my programming time--is 90Kloc because it has stuff to do and does it right. Simple is only better if simple can actually get the job done.)
HAproxy was first released around 2001.
Probably irrelevant to the question of speed, but there is a comment in another thread about hype driven development on HN first page right now where a commenter states they prefer Netty to the alternatives apparently because the alternatives are older or more cumbersome to use, although I may have misread.
Edit: This was a hasty, dumb comment. Please accept my apologies. Netty is not new and I should have known better. For whatever irrational reason, I have a bias against Java and deliberately avoid it. I do know it helps professional programmers get things done easier and faster. I'm an HAproxy user and have probably developed an HAproxy bias.
Netty 2 (the current version that underlies WebSphere and Vertx) was first released in 2004. This stuff is pretty well-bulletproofed. And a lot of folks who know how to write high-performance Java are naturally going to prefer Netty to the C++ alternatives (I am ambivalent; I can do either and I'd probably just use HAProxy to begin with because life is short) because you get competitive performance while ruling out entire classes of errors.
Netty is a far more robust, faster, and easier to use framework for TCP proxies than the one the author cooked up and I'm getting downvoted like crazy for saying it.
It's also used internally by Google, Twitter, and netflix. It's embedded in the GRPC library, Cassandra's database driver, Play framework, and Vert.x among many others. Check their related projects page https://netty.io/wiki/related-projects.html
Netty is a phenomenal project, and had the author known about it, I doubt he would have spent the time writing his own TCP proxy.
It's cool to show people an example of networking using Boost but the article and post have no mention of this being alpha quality software.