Several study questions and experiments on TCP concurrent connection

A few days ago, on Sina Weibo, I had two study questions about TCP, which sparked a discussion http://weibo.com/1701018393/eCuxDrta0Nn.

The first primary topic is:

There is a machine, it has an IP, the above run a TCP service program, the program listens to only one port, ask: Theoretically (consider only TCP/IP this level, regardless of IPV6) This service program can support how many concurrent TCP connection? Answer 65536 up and down directly brush off.

Specifically, the problem is equivalent to the following: The address of a TCP service is 1.2.3.4:8765, how many concurrent connections can it theoretically accept?

The second advanced question is:

A test machine A, function ibid, the same switch also has a machine B, if the program allows B to directly send and receive Ethernet frame, Q: Let a bear 100,000 concurrent TCP connections need to use how many B resources? What about 1 million?

From the results of the discussion, many people made the first question, and the second question almost nobody.

Let's not publish the answer here (see the end of the first question), lets keep thinking about an essential question: how much system resources a TCP connection consumes.

on today's Linux operating system, if you use the socket ()/connect () or accept () to create a TCP connection, then at least one file descriptor for each connection is occupied (file descriptor). Why say "at least"? Because a file descriptor can be duplicated, such as DUP (), or it can be inherited, such as fork (), so that there may be multiple file descriptors corresponding to the same TCP connection inside the system. As a result, many people answer the first question: the number of concurrent connections is limited by the maximum number of files that the system can open at the same time. The answer is correct in practice, but it does not fit the original question.

What is the overhead of setting up a TCP connection if the operating system level is taken into account and only the TCP/IP level is considered? What is the theoretical minimum cost? Consider two scenarios:

1. What do you need to do to successfully initiate a connection to this program, assuming there is a TCP service program? In other words, how do you make this TCP service program think that a client is connected to it (let its accept () call return normally)?

2. What do you want to do if you have a TCP client program that allows the program to successfully establish a connection to the server? In other words, how do you make this TCP client think that it is connected to the server (let its connect () call return normally)?

These two questions are not how to program, how to invoke the Sockets API, but how to let the operating system's TCP/IP protocol stack think that the task has been successfully completed, the connection has been successfully established.

Learned the TCP/IP protocol, understand the three-way handshake students understand that the TCP connection is a virtual connection, not a circuit connection, the maintenance of TCP connections in theory does not occupy network resources (will occupy two programs of the system resources). TCP connections persist as long as both sides of the connection believe that the TCP connection exists and that IP packet can be sent to each other.

For issue 1, to initiate a connection to a TCP service program, the client (hereinafter referred to as the FAKETCP client) needs to do only three things (three-way handshake):

1a. Send an IP packet to the TCP server, containing the SYN TCP segment

1b. Wait for each other to return a TCP segment containing SYN and ACK

1c. Send a segment that contains an ACK to each other

After these three things are done, the TCP server program considers the connection to be established. And doing these three things does not occupy the client's resources (? If the FAKETCP client program can bypass the TCP/IP protocol stack of the operating system, send and receive the IP packet or Ethernet frame directly. In other words, the FAKETCP client can repeat these three events, creating countless TCP connections on the server each time with a different ip:port, while the FAKETCP client itself is unscathed. Soon we'll see how to do this with the program.

For question 2, in order for a TCP client to think that the connection is established, the FAKETCP server only needs to do two things:

2a. SYN TCP segment waiting for client to send

2b. Send a TCP segment that contains SYN and ACK

2c. Ignore the segment of the other side that contains the ACK

After these two things are done (after a SYN, a syn+ack), the TCP client considers the connection to be established. And doing these three things does not occupy the resources of the FAKETCP server (? In other words, the FAKETCP server can repeat these two events over and over again, accepting countless TCP connections, while the FAKETCP service is intact. Soon we'll see how to do this with the program.

Based on the analysis of the above two questions, it is meaningless to talk about "TCP concurrent connections" alone, because the number of connections is basically how much. A more meaningful performance metric might be "how many messages per second," How many bytes per second, and "How many concurrent customers to support" and so on.