| 词条 | TCP hole punching | |||||||||
| 释义 |
}} TCP NAT traversal and TCP hole punching (sometimes NAT punch-through) occurs when two hosts behind a network address translation (NAT) are trying to connect to each other with outbound TCP connections. Such a scenario is particularly important in the case of peer-to-peer communications, such as Voice-over-IP (VoIP), file sharing, teleconferencing, chat systems and similar applications. TCP hole punching is an experimental used NAT traversal technique for establishing a TCP connection between two peers behind a NAT device in an Internet computer network. NAT traversal is a general term for techniques that establish and maintain TCP/IP network and/or TCP connections traversing NAT gateways. Terms usedIn the following, the terms host, client and peer are used almost interchangeably.
the local IP:port as seen locally by the host and the internal part of the NAT.
the external IP:port mapped by the NAT, as seen by the network and the external part of the NAT.
the IP:port of the other peer as seen by the network, or the external parts of both NATs. DescriptionNAT traversal, through TCP hole punching, establishes bidirectional TCP connections between Internet hosts in private networks using NAT. It does not work with all types of NATs, as their behavior is not standardized. When two hosts are connecting to each other in TCP, both via outbound connections, they are in the "simultaneous TCP open" case of the TCP state machine diagram.[1] Network Drawing
Types of NATThe availability of TCP hole punching depends on the type of computer port allocation used by the NAT. For two peers behind a NAT to connect to each other via {{clarify-span|TCP simultaneous open|date=September 2014}}, they need to know a little bit about each other. One thing that they absolutely need to know is the "location" of the other peer, or the remote endpoint. The remote endpoint is the data of the IP address and a port that the peer will connect to. So when two peers, A and B, initiate TCP connections by binding to local ports Pa and Pb, respectively, they need to know the remote endpoint port as mapped by the NAT to make the connection. When both peers are behind a NAT, how to discover the public remote endpoint of the other peer is a problem called NAT port prediction. All TCP NAT traversal and hole punching techniques have to solve the port prediction problem. A NAT port allocation can be one of the two:
Depending on whether the NATs exhibit a predictable or non-predictable behavior, it will be possible or not to perform the TCP connection via a TCP simultaneous open, as shown below by the connection matrix representing the different cases and their impact on end-to-end communication:
TechniquesMethods of Port Prediction (with predictable NATs)Here are some of the methods used by NATs to allow peers to perform port prediction:
If the remote peer has the information of one mapping, then it can guess the value of subsequent mappings. The TCP connection will happen in two steps, at first the peers make a connection to a third party and learn their mapping. For the second step, both peers can then guess what the NAT port mapping will be for all subsequent connections, which solves port prediction. This method requires making at least two consecutive connections for each peer and require the use of a third party. This method does not work properly in case of Carrier-grade NAT with a lot of subscribers behind each IP addresses, as only a limited amount of ports is available and allocating consecutive ports to a same internal host might be impractical or impossible.
In this case, port prediction is trivial, and the peers simply have to exchange the port to which they are bound through another communication channel (such as UDP, or DHT) before making the outbound connections of the TCP simultaneous open. This method requires only one connection per peer and does not require a third party to perform port prediction.
With this solution, the peers will first connect to a third party server that will save their port mapping value and give to both peers the port mapping value of the other peer. In a second step, both peers will reuse the same local endpoint to perform a TCP simultaneous open with each other. This unfortunately requires the use of the SO_REUSEADDR on the TCP sockets, and such use violates the TCP standard and can lead to data corruption. It should only be used if the application can protect itself against such data corruption. Details of a typical TCP connection instantiation with TCP Hole PunchingWe assume here that port prediction has already taken place through one of the method outlined above, and that each peer knows the remote peer endpoint. Both peers make a POSIX connect call to the other peer endpoint. TCP simultaneous open will happen as follows:
Interoperability requirements on the NAT for TCP Hole PunchingOther requirements on the NAT to comply with TCP simultaneous openFor the TCP simultaneous open to work, the NAT should:
This is enough to guarantee that NATs behave nicely with respect to the TCP simultaneous open. TCP Hole Punching and Carrier-grade NAT (CGN)The technique described above works fine within a CGN. A CGN can also make use of a port overloading behavior, which means that distinct internal endpoints with the same port value can be mapped to the same public endpoint. This does not break the uniqueness of the {{Math|{protocol, public address, public port, remote address, remote port}}} quintuple and, as a result, is acceptable. TCP port preservation can also lead to cases where the CGN ports are overloaded and is not an issue for protocol soundness. Port overloading for TCP allows the CGN to fit more hosts internally while preserving TCP end-to-end communication guarantees. See also{{Portal|Computer networking}}
References1. ^https://www.ietf.org/rfc/rfc793.txt 3 : Computer network security|Peer-to-peer file sharing|VoIP software |
|||||||||
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。