Research on P2P communication methods through NAT

 

Overview

In P2P communication, problems caused by NAT (Network Address Translation) are well known, it causes the P2P client inside the NAT to be inaccessible regardless of the valid public IP address. Although
However, a variety of NAT traversal technologies have been developed, but there are few technical documents to prove the stability and advantages of these technologies. The purpose of this article is to describe and analyze the most widely used, reliable, and simple NAT traversal Technology in practice. This technology is usually called the "hole hitting" technology. At present, the "hole" technology has been widely understood and applied in the UDP communication field. Here, we will also discuss how to use it to implement reliable P2P TCP stream communication. After collecting a large amount of data on NAT devices and networks that can be crossed by the "hole" technology, we found that 82% of NAT devices tested support the "hole" traversal in the UDP format, 64% of NAT devices have been tested to support "hole-in" traversal in the form of TCP streams. Heavyweight P2P applicationsProgramThe demand for users (such as VoIP, BT, and online games) continues to rise, and this fact has aroused widespread attention from Nat equipment manufacturers. Therefore, we believe that more and more NAT devices will be available in the future to support the penetration technology.

1. Introduction

The rapid growth of the number of users and the huge pressure on a large number of security problems have forced Internet technologies to keep moving forward, but these emerging technologies have greatly increased the cost and complexity of application development. The original Internet address system is that each node has a unique, unchanged global address, which can be used to directly communicate with any other node, this address system has been replaced by the new widely used address system. The new address system consists of a global address domain and a large number of private address domains that access the global address domain through NAT. In the new address system (1), only nodes in the "Main" Global Address domain can easily communicate with any other node with a global address in the network, because the node has a global, unique, and routable address. Nodes in a private network can communicate with other nodes in the same private network, in addition, you can initiate a TCP connection or send UDP packets to a "Famous" node in the global address. The NAT device is responsible for assigning a temporary forwarding session to the node that initiates a connection from the Intranet to convert the address and port of the data packet from the Intranet to the Internet address and port, convert the addresses and ports of data packets from the Internet to the Intranet ports and addresses. Meanwhile, Nat shields all unauthorized data packets from the Internet.

Figure 1
The new Internet address system is very suitable for communication modes such as "Client/Server". A typical c/s communication mode is: the client is in the Intranet (private address domain ), the server is in the public network (Global Address domain) and connects the Intranet to the public network through NAT. This address system makes it difficult for two nodes in different Intranet (private address domains) to communicate directly. This is precisely the most basic requirement for P2P applications (such as teleconference or online games. Obviously, we need a way to implement P2P communication without any access to the NAT device. The most effective way to establish P2P connections between two nodes in different intranets is to "punch holes ". This technology is widely used in UDP-based applications. Likewise, this technology can also be used in TCP-based applications. Interestingly, this technology does not affect the security of the Intranet. In fact, the "hole" technology enables most of the functions of P2P software to be controlled by the default security policies of NAT devices, which are managed by Sessions established by NAT devices. This article describes the "drilling" technology for UDP and TCP, and describes in detail the behavior between applications and NAT devices during the important "drilling" process. Unfortunately, because the responses and behaviors of NAT devices are not standard, there is no technology available to traverse all existing NAT devices. This article provides some lab results on existing NAT devices. The data we collect comes from users who use the "nat check" tool on the Internet and perform "Hole-hitting" experiments on NAT devices of a large number of different manufacturers. Because the data comes from a user called "self-selecting ", Community It may not represent the NAT devices that are actually deployed and used on the Internet, but the results are still very exciting. When evaluating the basic "Hole-hitting" operation, we should point out that the complexity of the existing NAT device "Hole-hitting" varies with the complexity. However, the focus of our discussion is on the simplest development that can be applied to the "hitting holes" Technology on any network topology, stable NAT devices with correct Nat responses. We intentionally avoid using some "smart tricks" to spoof some NAT devices to traverse more NAT devices in the short term, but in the long term, it will cause unknown network errors. Although the introduction of IPv6 greatly increases the Internet address space and reduces the demand for NAT devices, IPv6 does increase the demand for NAT devices in the short term, because the NAT device provides a convenient method for IPv4 address translation and IPv6 address translation. In addition, the establishment of anonymous and encrypted access nodes on the private network is also conducive to the security of the organization and is not subject to external interference, which means that Nat will exist for a long time. Similarly, the firewall technology will not disappear because of enough IP addresses. The IPv6 firewall will still lose all unauthorized data packets by default, and still allow applications that work in the IPv6 environment
Sequential "hitting holes ". The subsequent sections of this article are organized as follows: Chapter 2 introduces the basic concepts and terminologies of NAT traversal; Chapter 3 introduces the UDP "drilling" process; Chapter 4 introduces the TCP "drilling" process; chapter 5 describes the features that NAT devices that support "hole-hitting" must have. Chapter 6 describes the experiment results of "hole-hitting" on popular NAT devices; chapter 7 discusses related network problems. Chapter 8 summarizes the full text and concluding remarks.

2. Basic Concepts

This section describes the basic Nat terms used in this article, and focuses on the general NAT traversal technology applicable to UDP and TCP Protocols.

2.1 Nat terminology

The vast majority of terms and classifications in this article come from the definition of RFC 2663, and some also come from the definition of the newer RFC 3489.

It is important to understand the session. A tcp or UDP session endpoint is composed of an IP address and a port number. Each session is composed of two session endpoints. From the perspective of Intranet nodes, a session consists of four parts: local IP address, local port, remote IP address, and remote port. The session direction usually represents the direction of the initial data packet flow; for TCP, It is the flow of the SYN packet, and for UDP, It is the flow of the first user data packet.

There are many types of NAT, but the most common one is "traditional" Nat, or "external" nat. They provide an asymmetric ing between the Intranet and the Internet. By default, "outbound" Nat only allows external sessions to pass through NAT:

All outgoing packets are discarded, unless the NAT device has defined these outgoing packets as part of an existing Intranet session.

"Outward" Nat will cause confusion in the P2P protocol, because when the P2P parties decide to start communication with the other party after different NAT, no matter which party tries to initialize a session, the other NAT will reject this request. The core idea of NAT traversal is to make the NAT between P2P users look like an "external" nat.

There are two types of "outward" NAT: (1) "Basic" Nat. This Nat only converts IP addresses, not port numbers. (2) napt (Network Address/port translation) napt converts the entire session endpoints. Since napt allows multiple nodes in the Intranet to share the same public IP address, more and more NAT devices support napt. Although all the content discussed in this article is based on NAT devices supporting napt, these rules and technologies are also applicable to "Basic" nat.

2.2 forwarding Method

The most reliable but also the least efficient method for P2P cross-Nat communication is to use a C/S-like forwarding method. Assume that both nodes A and B have an external TCP or UDP connection to the public known server S. The public IP address of S is 18.181.0.31, and the port number is 1234 (2 ), each client is located in a different private intranet, and their NAT devices prevent direct P2P connections between clients. As an alternative to the direct connection scheme, two clients can use the public server s to forward messages. For example, to send a message to B, A only needs to send the message to s and then forward it to B. In this process, a and B establish a connection with S in advance.

Figure 2
The forwarding method is generally valid only when both clients connect to the server. The disadvantage of this method is that it assumes that the server's processing capacity, network bandwidth, and communication latency are both ideal and will not be affected by the number of clients. However, since there are no other methods that can traverse all existing NAT devices like the forwarding method, when building a high-reliability P2P system, server-based forwarding is still a very useful method to ensure system reliability. The TURN protocol defines how to implement secure forwarding.

2.3 reverse connection

Some P2P applications use direct but limited technologies to implement NAT traversal. This technology is called "reverse connection", which is used when two nodes are connected to server S, only one node is behind the NAT device (3 ). If a wants to establish a connection with B, A can directly join B because B exists in the public network and has not undergone Nat translation, in addition, NAT device a allows a to directly initiate a connection to the Internet from the Intranet. If B wants to establish a connection with A, it is unfortunate that a's NAT device will block this operation. At this time, B can send a "reverse connection" request to a by means of forwarding server S, A "actively" connects B to achieve P2P communication between A and B.

Figure 3

Although the limitations of this technology are obvious, the idea of using a known server as an intermediary to assist P2P clients in P2P connection has become the basic idea of a more general "drilling" technology.

3. UDP Injection

Even if both P2P clients are behind the NAT device, UDP can be used to directly connect P2P clients through known servers. This technology was mentioned in section 3027 of RFC 5.1. It can be found to have a vague description on the network and used in recent ipprotocol experiments, it has been applied in a variety of online game protocols.

3.1 centralized server

The penetration technique assumes that client a and client B can establish a UDP connection with a known centralized server in the public network (UDP packets can be sent to each other ). When a client logs in to S, the server records the two endpoints (IP addresses and UDP ports) of the client ), one is that the client is sure that it communicates with server s through the IP address and port, the other is the IP address and port used by the client to actually communicate with itself "observed" by the server S. We can regard the previous endpoint as the Intranet IP address and port of the client, and the latter as the Intranet IP address and port of the client after Nat translation. The server can obtain information about the client's intranet endpoint from the client's login message body, and obtain the client's Internet endpoint through the IP address or UDP header of the login message. If the client is not behind the NAT device, the values of the two endpoints obtained using the above method should be identical.

Some "mentally retarded" NAT devices scan the packet body of UDP data packets to find 4-byte bit domains, which look like the bit domains of IP addresses, and change them to the same address as the IP header. In order to prevent the NAT device from modifying the UDP data packet body, the application can directly encrypt the IP address value to defraud the NAT device from checking.

3.2 Create a P2P session

Assume that a wants to initiate a direct connection to B. The "hole" process is as follows: (endpoint refers to the pairing of IP addresses and ports) (1) A initially does not know how to initiate a connection to B, therefore, a sends a message to server s and requests s to help establish a UDP connection with server B.

(2) s sends the Internet and Intranet endpoint containing B to A. At the same time, s sends the request connection message of the Internet and Intranet endpoint containing A to B. Once these messages arrive, both A and B will know the Internet and Intranet endpoints of the other party.

(3) When a receives a message from S containing B's Internet and Intranet endpoints, A starts to send UDP packets to these B's endpoints, in addition, a will automatically lock the endpoint of the first B that gives the response. Similarly, when B receives the Internet and Intranet endpoint of A from S, it will also start to send UDP data packets to a's Internet and Intranet endpoints, and automatically lock the endpoint of the first response to. Since the communication between A and B to send UDP data packets to the other party is asynchronous, the time sequence of sending data packets between A and B is not strict.

Next, let's take a look at how the three roles perform UDP "drilling. Here we will discuss three specific scenarios: the first and most "simple" scenario, where both clients are located behind the same NAT device and on the same Intranet; the second and most common scenario is that the two clients are located behind different NAT devices and belong to different intranets. The third scenario is that the clients are located behind two NAT devices, generally, the top Nat layer is the ISP network provider, and the second Nat layer is a household Nat router and other devices.

In general, the network physical layer connection method determined by the application itself is very difficult, and sometimes it is not even possible, even in the preceding scenarios, Nat can be crossed, it is valid for a certain period of time, not permanently. Network protocols such as stun may provide necessary Nat information. However, in the case of a multi-layer NAT device, this information is generally not completely complete and valid. Even so, as long as the NAT device's response is "reasonable", the "hole" technology can automatically apply to most scenarios without knowing the network conditions of the application. ("Reasonable" nat response will be discussed in detail in chapter 5)

3.3 The P2P client is located behind the same NAT device

Assume that the two clients are behind the same NAT device and are located in the same Intranet (same private IP address domain) 4. A establishes a UDP connection with S. After Nat translation, the public port of A is mapped to 62000. B Also establishes a UDP connection with S, and the public port ing is 62005.

Figure 4

Suppose a wants to use server s as the introducer to initiate a connection to server B. A sends a message request to S to connect with B. S sends the Internet endpoint (Internet IP address and port) and Intranet endpoint (intranet IP address and port) of B to A, and sends the Internet and Intranet endpoints of A to B. Whether the UDP packet sent from A and B to the other party's Internet endpoint can be received by the other Party depends on whether the current Nat supports "Hairpin" conversion (hairpin conversion, that is, the same device, for details about whether UDP data packets between different ports can be reached, see section 3.5 ). However, UDP data packets sent by A and B to the peer Intranet endpoint are always accessible. In any case, intranet data packets do not need to be routed and are faster. A and B are likely to use an intranet endpoint for regular P2P communication.

If the NAT device supports "Hairpin" conversion and the application ignores the connection from the Intranet endpoint, A and B use the public network endpoint as the P2P communication connection, this will inevitably cause unnecessary packets to pass through the NAT device, which is a waste of resources.
We will discuss this situation in Section 6. After all, NAT devices that support "Hairpin" conversion are far from supporting many NAT devices. In terms of the current network situation, it is best to experiment with both the Internet endpoint and Intranet endpoint when the application program is "drilling holes.

3.4 P2P clients are located behind different NAT devices

Assume that a and B belong to different intranets after different NAT devices, as shown in Figure 5. Both A and B establish a UDP connection to server s through their respective NAT devices. The local port numbers of A and B are both 4321, and the public network port number of server s is 1234. In the "outward" Session, the public IP address of a is mapped to 155.99.25.11, the public port is 62000, the public IP address of B is mapped to 138.76.29.7, and the public port is 31000.

Client A --> local IP: 10.0.0.1, local port: 4321, public IP: 155.99.25.11, public port: 62000 client B --> local IP: 10.1.1.3, local port: 4321, public IP: 138.76.29.7, public port: 31000

Figure 5

The login message body sent by a to server S contains the Intranet endpoint information of a, that is, 10.0.0.1: 4321. Server s records the Intranet endpoint of, at the same time, we will record the public network endpoint of A we observed, that is, 155.99.25.11: 62000. Similarly, the server s records the Intranet endpoint of B, 10.1.1.3: 4321, and the Internet endpoint of B observed by S, 138.76.29.7: 31000. No matter whether a and B send P2P connection requests to S in any direction, the server will send the above-mentioned Internet and Intranet endpoints recorded by a and B to A and B.

Because a and B belong to different intranets, their intranet endpoints cannot be routed to the Internet. Therefore, UDP packets sent to their intranet endpoints will be sent to the wrong host or non-existent host. Therefore, the application must authorize and filter the received messages. Only authorized messages can be sent from the peer endpoint. For example, the program name and encryption of the other party can be added to the message.AlgorithmOr at least a random number obtained by both parties from server S.

Assume that the first message of A is sent to the Internet endpoint of B, as shown in Figure 5. The message passes through a's NAT device and generates an "outward" Session on the device. The new session source endpoint is 10.0.0.1: 4321. This endpoint is the same as the source endpoint generated by Nat when a establishes a connection with server s, but its destination endpoint is different. If a's NAT device gives a "friendly" response, a's NAT device retains a's intranet endpoint and all source endpoints (10.0.0.1: 4321) from) all the data packets of A follow the session established in advance by S, and the public network endpoint is (155.99.25.11: 62000 ). A sends messages to the Internet endpoint of B as a "drilling" process. From the perspective of a's Intranet, it should be sent from (10.0.0.1: 4321) to (138.76.29.7: 31000 ), the session created by a on its nat device is sent from (155.99.25.11: 62000) to (138.76.29.7: 31000 ).

If the message packet sent by A to B's Internet endpoint reaches the NAT device of B before B sends the message packet to, b's Nat considers the message sent by a as an unauthorized public network message and discards the packet. B will create a packet on the NAT server of B (10.1.1.3: 4321,155.99 .25.11: 62000) session (usually follows the session established when B connects to S, but this session can not only accept messages sent from S to B, messages sent from a NAT device-155.99.25.11: 6200)

Once both A and B send data packets to the peer's Nat endpoint on the public network, the "hole" between A and B is opened ", A and B send data to the peer's Internet endpoint, which is equivalent to sending UDP packets directly to the peer's client. Once the application confirms that it can send data packets to the target application after Nat by sending data packets to the public network endpoint of the other party, the program will automatically stop sending data packets for "hitting holes, instead, we started real P2P data transmission.

3.5 The P2P client is behind a multi-layer NAT device

Some network topologies contain multiple NAT devices. If you do not have detailed information about the topology, you cannot create an "Optimal" P2P route between two clients. Now let's discuss the last case, as shown in figure 6. Assume that Nat C is an industrial NAT device provided by the ISP (Internet Service Provider, nat C provides services to map Nat or user nodes of multiple subordinate users to a limited number of public IP addresses, as an intranet node of nat c, Nat A and Nat B connect your home network or internal network to the intranet of NAT C. Then, your internal network can access the Internet through NAT C. In terms of this topology, only the server s and Nat C are actually devices with public network IP addresses that can be routed, while Nat A and Nat B use the "public network" IP addresses, actually set by the ISP service provider (compared with Nat C) intranet address (in the subsequent part of the standard, the Intranet address provided by the ISP is called a "pseudo" Public IP address relative to Nat A and Nat B). Likewise, it is affiliated with the clients of nat a and Nat B, compared with Nat A and Nat B, they are in the intranet of nat a and Nat B, and so on. Clients can be placed behind multi-layer NAT devices. When Client A and client B initiate a connection to server s, they will establish external sessions on Nat A and Nat B in sequence, when Nat A and Nat B are connected to the public network, an external session is created on Nat C.

Figure 6

Now let's assume that client a and client B want to use UDP to "hole" the P2P direct connection between the two clients. The optimal routing policy is that client a sends data packets to the "pseudo public network" IP address of client B, that is, the Intranet IP address specified by the ISP service provider, the "pseudo" public network endpoint of nat B, 10.0.1.2: 55000. From the perspective of server s, we can only observe the real public network address, that is, Nat A. The real public network address 155.99.25.11: 62000 and 155.99.25.11: 62005 of the session created by Nat B in Nat C, therefore, it is unfortunate that client a and client B cannot know these "pseudo" public network addresses through server S. In addition, even if Client A and client B can obtain the "pseudo" Public IP addresses of nat a and Nat B through some means, we still do not recommend using the "optimized" method above, this is because these addresses are provided by the ISP service provider and may be duplicated with the Intranet address of the client itself. (For example, the Intranet IP address domain of nat a is exactly the same as that of nat a in the "pseudo" Public IP address domain of nat c. This will cause the problem that the punched in data packets cannot be sent)

Therefore, the client has no choice but to use the public network endpoint of A and B observed by the public network server s to perform the "hole" operation. packets used for "hole" will be forwarded by Nat C, whether Nat C supports "Hairpin" conversion or "loop" conversion is very important here. Otherwise, the data packets cannot be forwarded to Nat A and Nat B by Nat C, and thus cannot reach the Client A and B. When Client A sends a UDP packet to the public network endpoint (155.99.25.11: 62005) of client B, Nat a first sets the source endpoint of the packet from the Intranet endpoint (10.0.0.1: 4321) of) convert to "pseudo" public network endpoint (10.0.1.1: 45000). Now that the data packet is sent to Nat C, Nat C should be able to identify that the data packet is sent to the public network endpoint that has been converted by itself, if Nat C can provide a "reasonable" response, Nat C will change the source endpoint of the packet to 155.99.25.11: 62000, And the destination endpoint to 10.0.1.2: 55000, that is, Nat B's "pseudo" public network endpoint. Nat B will finally send the received data packet to client B. Similarly, data packets sent from B to a go through a similar process. Many NAT devices do not support such "Hairpin" conversion, but more and more NAT device manufacturers have begun to support this conversion.

3.6 UDP timeout in idle state

Because the "hole" provided by UDP is not absolutely reliable, most NAT devices have a idle timer for UDP conversion. If there is no UDP data communication within a period of time, the NAT device will turn off the "hole" made by the "hole" operation. As an application, if you want to do this, you 'd better set a validity period for the traversal after the NAT traversal. Unfortunately, there is no standard validity period, which is related to the internal configuration of the NAT device. The minimum validity period is about 20 seconds. During this period, even if no P2P data packet needs to be transmitted, the application must send a "hole" to the other party to maintain the "hole. This maintenance package must be sent by both applications. Only one Party sends the package and does not maintain the normal operation of the Session of the other party. In addition to frequently sending "holes" to maintain the package, there is also a way to re-"holes" on both sides of the P2P client before the current "holes" expire and discard the original "holes ", this is also an effective method.

4 TCP Punching Technology

The establishment of a P2P connection through a NAT device through the TCP hole technique is only a little more complex than that of UDP, from the protocol layer, the "hole" process of TCP is very similar to that of UDP. However, TCP-based holes have not been well understood so far, which leads to not many NAT devices. With the support of NAT devices, TCP-based "hole" technology is actually as fast and reliable as UDP-based "hole" technology. In fact, as long as the NAT device supports it, the TCP-based P2P technology is more robust than the UDP-based technology, because the state machine of the TCP protocol provides a standard method to accurately obtain the lifetime of a TCP session, UDP cannot.

4.1

In the process of reusing sockets and TCP ports to implement P2P "drilling" based on the TCP protocol, the main problem is not from the TCP protocol, but from the application's API interface. This is because the standard Berkeley Socket API is designed around the construction of client/server programs. The API allows TCP stream sockets to establish external connections by calling the connect () function, you can also use the listen () and accept functions to accept external connections. However, the API does not provide Connections similar to UDP. The same port can be connected both externally and externally. What's worse, TCP sockets usually only allow one-to-one response, that is, after an application binds a socket to a local port, any attempt to bind the second socket to this port will fail. In order to allow TCP to work smoothly, we need to use a local TCP port to listen for TCP connections from outside and establish multiple external TCP connections at the same time. Fortunately, all mainstream operating systems support special TCP socket parameters, usually called "so_reuseaddr ", this parameter allows the application to bind multiple sockets to a local endpoint (as long as the so_reuseaddr parameter is set for all sockets to be bound ). The so_reuseport parameter is introduced in the BSD system to distinguish between port reuse and address reuse. In such a system, all the above parameters must be set.

4.2

Open the P2P TCP stream. Assume that client a wants to establish a TCP connection with client B. We generally assume that A and B have established TCP connections with known servers on the Internet. The server records the Internet and Intranet endpoints of each connected client, which is the same as the UDP Service. From the protocol layer, TCP "hole" and UDP "hole" are almost identical processes. 1. Client A uses its connection with server s to send a request to the server, asking server s to help it connect to client B. 2. s returns the TCP endpoint of B's Internet and Intranet to A. At the same time, s sends the Internet and Intranet endpoint of A to B. 3. Client A and client B use the port connecting s to initiate a TCP connection to the peer's public network and Intranet endpoint asynchronously, and listen on whether their local TCP ports have external connections. 4. A and B start to wait for the external connection to check whether there is a new connection. If an external connection fails due to a network error, for example, "the connection is reset" or "the node cannot be accessed", the client only needs to delay for a short period of time (for example, one second ), then re-initiate the connection. The latency and the number of reconnections can be determined by the application writer. 5. After the TCP connection is established, authentication should be performed between clients to ensure that the currently connected connection is the desired connection. If authentication fails, the client closes the connection and continues waiting for the new connection to join. Generally, the client adopts a "first-in-first" policy. It only accepts the first client that passes authentication, and then enters the P2P communication process and no longer waits for new connections to be connected.

Figure 7

Unlike UDP, each client using UDP only needs one socket to complete the task of communicating with server s and multiple P2P clients at the same time, the tcp client must bind multiple sockets to the same local TCP port, as shown in figure 7. Now let's look at a more practical scenario. A and B are respectively located behind different NAT devices, as shown in figure 5, and assume that the port number in the figure is the port number of the TCP protocol, rather than the UDP port number. The external connection in the figure indicates the connection that a and B initiate to the Intranet endpoint of the other party. These connections may fail or cannot connect to the other party. Just like the problems encountered when using the UDP protocol to perform the "hole" operation, during the TCP "hole-in" operation, you may also encounter problems such as connection failure or wrong connection due to repeated Intranet IP addresses and "pseudo" Public IP addresses. When the client initiates a connection to each other's public network endpoint, the NAT device opens a new "hole" to allow TCP data of A and B to pass through. If the NAT device supports the TCP "hole" operation, a TCP-based channel between clients is automatically established. If the first SYN Packet sent by A to B is sent to the NAT device of B, and B does not send the SYN packet to a before, the NAT device of B discards the packet, this will cause a "connection failure" or "connection failure" problem. At this time, because a has sent a SYN packet to B, the SYN Packet sent by B to a will be considered as part of the response from A to B, therefore, the SYN Packet sent by B to a will smoothly reach a through a's NAT device, thus establishing a P2P connection between A and B.

4.3

from the application perspective, what happens when TCP "holes" are implemented? Assume that a first sends a SYN packet to B, which is sent to B's Internet endpoint and is discarded by B's NAT device, however, the SYN Packet sent by B to a's public network endpoint reaches a through a's Nat. Then, one of the following two results will occur, which of the following depends on the implementation of the TCP protocol by the operating system: (1) the TCP implementation of a will find that the received Syn packet is the SYN Packet of B that it initiates a connection and wants to join, generally speaking, it means "Cao, Cao to". Originally, A was going to look for B, and B came to the door. The TCP protocol stack of A therefore uses B as part of a's connection to B and considers the connection successful. The asynchronous connect () function called by program A will be returned successfully, and the listen () function of program a waiting for external join will not be reflected. In this case, the operation of B connecting to a is considered as a successful connection to B in program a, and a starts to use this connection to start P2P communication with B. Since the received SYN Packet does not contain the ACK data required by a, TCP of a will respond to the Internet endpoint of B with the SYN-ACK package, in addition, the serial number of the SYN Packet sent from A to B will be used. Once TCP of B receives the SYN-ACK package from a, it sends its ack package to A, and then establishes a TCP connection between the two ends. To put it simply, the first one is that even if the SYN Packet sent by A to B is discarded by the NAT packet of B, the packet sent by B to a reaches. As a result, a thinks that the connection is successful, and B thinks that the connection is successful. No matter who is successful, the connection is established. (2) Another result is that the TCP implementation of A is not as "intelligent" as described in (1), and it does not find that B is the one that you want to join. Just like picking up at the airport, I met people I wanted to pick up, but I didn't know them. I mistakenly thought I was another person and arranged for someone else to pick up. Then I realized that I missed the opportunity, however, in any case, the person has received the task and completed it. Then, a connects to B through the regular listen () function and accept () function, and the connection initiated by A to B's public network endpoint will end in failure. Even if the connection from A to B fails, a still obtains the connection from B to A, which is equivalent to the connection between A and B, regardless of the intermediate process, A and B have been connected, and the result is that A and B have established a TCP-based P2P connection. The first result is applicable to the TCP implementation of the BSD-based operating system, while the second result is more common. Most Linux and Windows systems will follow the second result.