Muduo network programming example 10: socks4a proxy server

TCP Repeater
Before implementing the socks4a proxy, we should first write a simpler Network Program-TCP relay or poor mans tcpdump ).

Generally, client programs connect directly to the server, for example. Sometimes, we want to put a relay between the client and the server to record the communication content between the client and the server. At this time, using tcpdump is the most convenient and convenient, but tcpdump requires the root permission. What if there is no root password? The poor have a way to write a relay by themselves, so that the client can connect to the relay and then connect the relay to the server. For example, in the T-type structure, the relay plays a role similar to the proxy.

TcpRelay is written by ourselves and can be applied. In addition to recording communication content, you can also create latency, or deliberately flip 1 bit data to simulate a router hardware failure.

The TcpRelay function (business logic) looks very simple. It is nothing more than sending the data received on connection C to connection S, and sending the data received on connection S to connection C. But after careful consideration, the details are actually not that simple:

1. Establish a connection. To simulate the client, TcpRelay initiates a connection to the server after the accept connects to C. What should I do if I receive data from C before S is established? Do you want to save it temporarily?
2. manage concurrent connections. Only one client is shown in. In fact, TcpRelay can serve multiple clients. How can we manage these concurrent connections on both sides and prevent cross talk )?
3. The connection is disconnected. Both the Client and Server may be disconnected. When the Client actively disconnects C, TcpRelay should immediately disconnect S. When the Server actively disconnects S, TcpRelay should immediately disconnect C. In this way, the behavior of the Client and Server can be accurately simulated. When the connection was closed, a new client was connected and reused the fd number that was just closed. Will this cause a string of calls? What Should TcpRelay do if the Client and Server are disconnected almost at the same time?
4. The speed does not match. If the connection bandwidth of C is kb/s, and the connection bandwidth of S is 10 MB/s, the Server is a chargen service and data is sent at full speed, will the TcpRelay buffer be cracked? How is the speed limit? Especially when using non-blocking IO and level-trigger polling, how does one limit the speed of Data Reading?
Before reading the implementation of muduo, you should consider how to solve these problems if you use the Sockets API to implement TcpRelay.

Socks4a proxy server
The function of Socks4a is very similar to that of TcpRelay. It also sends the data received on connection C to connection S and the data received on connection S to connection C. It differs from TcpRelay in that TcpRelay is fixed to a server address, while socks4a allows the client to specify the server to be connected. After the accept is connected to C, Socks4a server reads several bytes to understand the server address and then initiates a connection to S.

Muduo socks4a is a standard network service that can be used by Web browsers (I tested it in this way ).

N: 1 and 1: n connection forwarding
Yun Feng wrote a TCP tunnel in "Write a proxy usage you know". The program consists of three parts: n: 1 connection forwarding service and 1: n connection forwarding service, socks proxy service.

I followed his ideas and used muduo to implement these two programs. The difference is that I didn't do data obfuscation, so I couldn't use it to flip the legendary Wall.

N: 1 the connection and forwarding service is the multiplexer (data selector) in Muduo network programming example 7: "concatenating and converting" Connecting servers and automated testing ).
Socks proxy service is exactly the socks4a implemented in this article.
Interested readers can join these two programs for a try.

The Muduo programming example series has come to an end
I wrote the "html"> Muduo network programming example "from the beginning of February this year, and now it is exactly four months. I wrote eleven blogs and basically completed the task as planned. This series has come to an end.

This series covers the functions provided by muduo for writing single-threaded server and client TCP network programs. muduo has the following capabilities:

Multithreading: muduo: net: TcpServer provides a simple but adaptive thread model. At present, the example on the blog involves a very simple business logic. There is no complicated operation, and the bottleneck is usually I/O. The advantages of multithreading cannot be realized.
Advanced applications. For example, muduo: net: Channel is used with signalfd to process signals. Other non-blocking network client libraries (such as ZooKeeper's C client and PostgreSQL client libpq) are integrated with muduo EventLoop.
The above two points will be mentioned in future articles and will not be hidden in the dark.

Next Plan
Next, I will write a series of blogs, including:

1. Talk about my network programming learning experience. Most of the articles have been completed and can be published after the Dragon Boat Festival.
2. Use muduo to implement some slightly more complex network programs, such as small-scale distributed systems. The plan is to use the Paxos algorithm to implement a highly available in-memory key value storage, implement the naming service, and then implement the simple cluster management system that I mentioned many times before. Currently, the muduo sample programs are simple and independent network programs. In the second half of the year, I want to write a system composed of multiple programs. Let's talk about the detailed design of the distributed system.