Original copyright: Copyright (c) The Internet Society (2003) .all Rights Reserved. Original address: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt translation copyright declaration: please reference The author or website of this article indicates: http://blog.9cbs.Net/hxhbluestar to respect the translator's labor results! Note: Readers need to understand the basics of TCP, understand the basic steps of TCP establishment
3.5. Simultaneous TCP Open also open TCP connection
There is a method that can be used in some cases to establish direct peer-to-peer TCP connections between a pair of nodes that are both behind existing middleboxes. Most TCP sessions start with one endpoint sending a SYN packet, to which the other party responds with a SYN-ACK packet. It is possible and legal, however, for two endpoints to start a TCP session by simultaneously sending each other SYN packets, to which each party subsequently responds with a separate ACK. This procedure is known as a " Simultaneous Open. "
Here, there is a method to establish a penetrating end-to-end TCP penetrating NAT in some cases. We know that the vast majority of TCP sessions are all started by one end, and the other party will return to a SYN-ACK package process. However, there is indeed another case, that is, the two sides of the P2P each other simultaneously issues a SYN package to the other party's public network address, and then each returns an ACK response to establish a TCP session, this process is called : "Simultaneous Open" ("Connection At the same time").
If a middlebox receives a TCP SYN packet from outside the private network attempting to initiate an incoming TCP connection, the middlebox will normally reject the connection attempt by either dropping the SYN packet or sending back a TCP RST (connection reset) packet. If, however , the SYN packet arrives with source and destination addresses and port numbers that correspond to a TCP session that the middlebox believes is already active, then the middlebox will allow the packet to pass through. In particular, if the middlebox has just recently seen and transmitted an outgoing SYN packet with the same addresses and port numbers, then it will consider the session active and allow the incoming SYN through. If clients A and B can each correctly predict the public port number that its respective middlebox will assign the next outgoing TCP connection , and if each client initiates an outgoing TCP Connection with the Other Client Timed So That Each Client's Outgoing Syn Passs THROUGH ITS Local MiddleBox Before Either Syn Reaches The Opposite Middlebox, THEN A WORKING Peer-to-Peer TCP Connection Will Result. If a NAT receives a TCP SYN package from the private network, this package wants to initiate a "introduction" TCP connection. In general, NAT will reject this connection request and throw away this SYN package, or send a TCP RST (Connection RESET, Reconstruction Connection) package to the requester. However, there is a situation that when this source IP address and port in this received SYN package, the target IP address and port are consistent with the address information in the NAT registered TCP session, NAT will release this SYN. Package, let it enter the inside of NAT. In particular, if NAT just sees a SYN package that has just been sent and the address information in the SYN package received above, then NAT will think that this TCP connection has been activated and will allow this direction. The SYN package enters the NAT inside.
If Client A and Client B can correctly predict the other party's NAT will give the next TCP connection to the public TCP port, and the two clients can simultaneously initiate a "out" TCP connection, and in the other party SYN Before the package arrived, the SYN package that I just sent out can pass through my NAT, and the end-to-end TCP connection was successfully established.
(I like a spy activity)
Unfortunately, this trick may be even more fragile and timing-sensitive than the UDP port number prediction trick described above. First, unless both middleboxes are simple firewalls or implement cone NAT behavior on their TCP traffic, all the same things can go wrong with each side's attempt to predict the public port numbers that the respective NATs will assign to the new sessions. In addition, if either client's SYN arrives at the opposite middlebox too quickly, then the remote middlebox may reject the SYN with a RST packet, causing the local middlebox in turn to close the new session and make future SYN retransmission attempts using the same port numbers futile. Finally, even though support for simultaneous open is technically a mandatory part of the TCP specification [TCP], it is not implemented correctly in some common Operating systems. for this Reason, this trick is like histical subjectioned here. IT is not recommended for use by applications. Applica Tions That Require Efficient, Direct Peer-to-Peer Communication over Existing Nats Should UDP.
Unfortunately, this trick 3.4 is more susceptible to smashing, and the sensitivity of time is more dependent! First, unless the NAT's NAT is Simple Firewalls or like the CONE NAT to handle TCP communication, the two clients cannot establish this TCP directly, because they cannot predict that the other's NAT will assign the port number to the new session. How many. In addition, if the SYN of the two parties arrive at the other party is too fast (for example, SYN A has not passed NAT A, SYN B has arrived early Nat a), and the other party's NAT will thrown this SYN, And return a RST package, so that this time, one NAT closes the original session, and re-establish a new session, and use this new session to retransmit a SYN, then the port prediction is invalid, because once again The chance to assign to the same port address is too small.
Finally, although "SIMULTANEOUS OPEN" is a supported standard technology, in some public operating systems, the support of this technology is not good. Based on this reason, we have also stated that this technology is not recommended. If your application wants to penetrate NAT and communicate with high-efficiency P2P, you should use UDP technology! Here I will describe the detailed process of this technology as follows, welcome to correct: Process detailed description:
Client A Send a TCP SYN package to Client B, we call this SYN package SYN A, including the information as follows:
Srcaddress: 10.0.0.1 TCP Port: 1234
Destaddress: 138.76.29.7 TCP port: 310000
At the same time, Client B sends a TCP SYN package to Client a, and we call this package SYN B, including information as follows:
SRCADDRESS: 10.1.1.3 TCP port: 1234
Destaddress: 155.99.25.11 TCP Port: 620000
SYN A first passes NAT A (before SYN B to reach NAT A), NAT A sees this package and converts its address information to:
Srcaddress: 155.99.25.11 TCP Port: 620000
Destaddress: 138.76.29.7 TCP port: 310000
We call this Nat A converted bag called SYN A '
Similarly, SYN B first passes NAT B (before SYN A to reach NAT B), NAT B see this package and performs address translation to:
Srcaddress: 138.76.29.7 TCP Port: 310000
Destaddress: 155.99.25.11 TCP port: 620000
We call this NAT B converted bag called SYN B '
At this time, NAT A and NAT B store the above two public IP addresses and port information in their TCP connection table, so as long as you see the SYN package containing these two information, it will pass.
Just in this moment, SYN A 'reached Nat B, NAT B checked SYN A', discovered that its address information and the information in the TCP connection table, let Syn A 'passed, and will SYN A' The address information is converted to: We call this package to SYN A '' '
Srcaddress: 155.99.25.11 TCP Port: 620000
Destaddress: 10.1.1.3 TCP Port: 1234
To enable this package to reach the interior network CLIENT B
Just in this moment, SYN B 'reached Nat A, Nat a checked SYN B', discovered its address information and the information in the TCP connection table, so that SYN B 'is passed, and SYN B 'Address information conversion to: We call this package for syn b' ''
SRCADDRESS: 138.76.29.7 TCP port: 310000Destaddress: 10.0.0.1 TCP port: 1234 so that this package can reach the internal network CLIENT A
At this time, Client A received SYN B '', Client B received syn a '', and returned to the other party ACK, after three handshakes, this P2P TCP connection was established.
