Muduo network programming example 10: SOCKS4A proxy server

Muduo network programming example 10: SOCKS4A proxy server

Chen Shuo (giantchen_at_gmail)

Blog.csdn.net/solstice t.sina.com.cn/giantchen

This is the tenth article in The muduo network programming example series.ArticleThis series is coming to an end.

Muduo full article list: http://blog.csdn.net/Solstice/category/779646.aspx

This article introduces how to use muduo to implement a simple SOCKS4A proxy server,CodeSee http://code.google.com/p/muduo/source/browse/trunk/examples/socks4a.

TCP Repeater

Before implementing the SOCKS4A proxy, we should first write a network with simpler functions.Program-- TCP Relay (TCP relay), or tcpdump (poor man's tcpdump) called the poor ).

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:

• 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?
• 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 )?
• 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?
• 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.

The implementation of tcprelay is very simple. There are only dozens of lines of code in the tunnel class.

Http://code.google.com/p/muduo/source/browse/trunk/examples/socks4a/tunnel.h. This solution solves the first three problems. The fourth is left for the future.

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.

SOCKS4A protocol is very simple, please refer to Wikipedia http://en.wikipedia.org/wiki/SOCKS#SOCKS_4a.

The SOCKS4A proxy server of muduo is implemented in the tunnel class. Compared with tcprelay, only the server address is parsed.

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 three 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 ).
• 1: n connection forwarding service is the backend mentioned in this article, a data distributor (demultiplexer), code in the http://code.google.com/p/muduo/source/browse/trunk/examples/multiplexer/demux.cc
• Socks proxy service is exactly the SOCKS4A implemented in this article.

Interested readers can join these three programs for a try.

The muduo programming example series has come to an end

I wrote the muduo network programming example from the beginning of February this year, and today 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.

Muduo version 0.1.0 was released by the end of August 2010, with the publication of this programming example series, so far has released 14 small upgrades: http://code.google.com/p/muduo/downloads/list

Next Plan

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

1. Let's talk about my network programming learning experience. Most of the articles have been completed and can be published after the Dragon Boat Festival.
2. The muduo Design and Implementation series describes how to implement a non-blocking network library step by step. The code is almost ready, in the https://github.com/chenshuo/recipes/tree/master/reactor
3. Use muduo to implement some slightly more complex network programs, such as small-scale distributed systems. Plan: Use paxosAlgorithmImplement a high-availability in-memory key value storage, implement the naming service on this basis, and then implement the simple cluster management system 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.

In addition, I will gradually sort the existing blog articles into PDF collection, convenient download and save, address is: http://blog.csdn.net/Solstice/archive/2011/02/24/6206154.aspx