Torrent 点对点连接
我曾经认为我对TCP和UDP协议的理解虽然有限，但是是正确的。尽管最近，当我意识到共享一个公共 torrent 的对等点可以通过 TCP 或 UDP 协议相互连接而无需实际需要端口转发时，我感到很困惑。路由器如何知道将数据包转发到本地网络中的哪台机器？任何帮助解决这个问题的帮助将不胜感激。互联网上的 torrent 协议图和文章已大大简化，因此不包含任何有帮助的信息。
I used to think my understanding of the TCP and UDP protocols, although limited, is correct. Although recently, when I realized that peers sharing a common torrent can connect to one another through a TCP or UDP protocols without the actual need for port forwarding, I got confused. How does a router know which machine in the local network to forward packets to? Any help in clearing that up would be appreciated. The torrent protocol diagrams and articles on the Internet are greatly simplified, and hence do not contain any information that would help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
路由器（运行 NAT）跟踪所有传出数据包，然后允许传入数据包，这些数据包是对这些传出数据包的响应。
因此，如果您与 google.com:80 建立传出 TCP 连接，那么它将允许来自 google.com:80 的数据包返回（作为响应）。如果两个内部主机建立到同一端口的连接，则可以区分它们，因为本地端口不同，例如：
1) 主机 A 建立到 Google 的连接，并且路由器使用自己的本地端口 10001 进行 TCP 连接
2) 主机B 建立类似的连接，路由器使用自己的本地端口 10002 进行 TCP 连接
如果数据包来自 google.com:80，其地址为路由器 WAN IP 上的端口 10001，则路由器知道将其发送到主机 A。如果其地址为端口 10002，则路由器知道将其发送到主机 B。
如果路由器后面有两台对等主机（两个 NAT），则无法建立连接，除非有是传输有关彼此 IP 的信息的东西（即，他们都可以用来交换信息的服务器），他们可以尝试猜测路由器将选择哪个端口作为本地端口，然后开始在该端口上向路由器发送彼此数据广域网IP。由于两个路由器都看到数据流出，因此它们会设置一条规则以允许数据流入。如果正确猜测端口，那么来自每一侧的数据包都可以通过，因为两个路由器都设置了规则。这称为 UDP/TCP 打洞。
http://en.wikipedia.org/wiki/UDP_hole_punching
我相信 Skype 就是一个例子使用 UDP 并进行打洞的应用程序。
The router (running NAT) tracks all outgoing packets and then allows incoming packets which are responses to those outgoing packets.
So if you make an outgoing TCP connection to google.com:80 then it will allow packets back in (in response) from google.com:80. If two internal hosts make a connection to the same port it can differentiate them because the local port is different, for example:
1) Host A makes a connection to Google and the router uses its own local port 10001 for the TCP connection
2) Host B makes a similar connection and the router uses its own local port 10002 for the TCP connection
If a packet comes in from google.com:80 and its addressed for the port 10001 on the router's WAN IP then the router knows to send it to Host A. If its addressed for port 10002 the router knows to send it to Host B.
If you have two peer to peer hosts behind routers (two NATs) then there is no way to establish the connection except that if there is something to transfer information about each others IPs (i.e. a server they can both use to exchange information) they can try to guess what port the router will choose as a local port and then start sending each other data on that port, to the routers WAN IP. Because both routers see data going OUT they then set up a rule to allow data IN. If the ports are guessed correctly then the packets from each side can get through because both routers have a rule set up. This is called UDP/TCP Hole Punching.
http://en.wikipedia.org/wiki/UDP_hole_punching
I believe Skype is an example of a app which uses UDP and does hole punching.
严格来说，由于您尚未使用“NAT”限定您的术语路由器，那么答案是路由器使用 ARP 来确定目标主机的 MAC 地址，然后发送以该 MAC 地址作为目标地址的以太网帧。
但我认为这不是你的意思。
您的意思是 NATting 路由器如何知道将入站数据包转发到哪里？
答案是路由器维护一个活动“连接”列表，使其能够进行地址转换。它使用外部端口号映射到内部主机地址和端口号。就 TCP 而言，“连接”的概念就是是否存在 TCP 连接（尽管通常会设置超时以阻止泄漏）。对于 UDP 来说，情况比较困难，因为本身没有 UDP 连接，因此通常是仅通过超时来跟踪它的情况。
Strictly speaking, since you haven't qualified your term router with 'NAT', then the answer is that the router uses ARP to determine the MAC address of the target host and then sends and ethernet frame with that MAC address as the target address.
But I think that was not what you meant.
You mean how does a NATting router know where to forward inbound packets?
The answer is that the router maintains a list of active "connections" to enable it to be able to do address translation. It uses the outside port number to map to an inside host address and port number. In the case of TCP, the concept of a "connection" is simply whether there is a TCP connection (though usually with a timeout to stop leakage). In the case of UDP it's harder because there is no UDP connection per se, so it is generally a case of tracking it by timeout alone.