TCP打洞实现

建立穿越NAT设备的p2p的TCP连接只比UDP复杂一点点，TCP协议的"打洞"从协议层来看是与UDP的"打洞"过程非常相似的。尽管如此，基于TCP协议的打洞至今为止还没有被很好的理解，这也造成了对其提供支持的NAT设备不是很多。在NAT设备支持的前提下，基于TCP的"打洞"技术实际上与基于UDP的"打洞"技术一样快捷、可靠。实际上，只要NAT设备支持的话，基于TCP的p2p技术的健壮性将比基于UDP的技术的更强一些，因为TCP协议的状态机给出了一种标准的方法来精确的获取某个TCP session的生命期，而UDP协议则无法做到这一点。

一 套接字和TCP端口的重用

实现基于TCP协议的p2p"打洞"过程中，最主要的问题不是来自于TCP协议，而是来自于来自于应用程序的API接口。这是由于标准的伯克利(Berkeley)套接字的API是围绕着构建客户端/服务器程序而设计的，API允许TCP流套接字通过调用connect()函数来建立向外的连接，或者通过listen()和accept函数接受来自外部的连接，但是，API不提供类似UDP那样的，同一个端口既可以向外连接，又能够接受来自外部的连接。而且更糟的是，TCP的套接字通常仅允许建立1对1的响应，即应用程序在将一个套接字绑定到本地的一个端口以后，任何试图将第二个套接字绑定到该端口的 *** 作都会失败。

为了让TCP"打洞"能够顺利工作，我们需要使用一个本地的TCP端口来监听来自外部的TCP连接，同时建立多个向外的TCP连接。幸运的是，所有的主流 *** 作系统都能够支持特殊的TCP套接字参数，通常叫做"SO_REUSEADDR"，该参数允许应用程序将多个套接字绑定到本地的一个endpoint（只要所有要绑定的套接字都设置了SO_REUSEADDR参数即可）。BSD系统引入了SO_REUSEPORT参数,该参数用于区分端口重用还是地址重用，在这样的系统里面，上述所有的参数必须都设置才行。

应该是这个原因:

你的客户端应该是使用的私有IP地址(比如:192168123),它通过NAT(位于路由器上)访问公网,所以客户端发送的数据服务端能够接收到,而且服务器并不知道你客户端的地址是192168123,它认为是你路由器转换后的地址所以不难想象为什么服务端向客户端发送数据不成功了

应该需要在路由器上做相应设置(比如:映射特定端口---比如:12345---到你的客户端机器192168123),这样服务端只要向你的路由器地址发送数据(端口号12345),路由器便会将数据转发到192168123的机器上了,而服务端并不知道客户端真实地址(192168123)

希望能够帮助到你

85%以上。udp打洞由于如今的网络环境都比较好，成功率也较高，达到了85%以上，但是TCP打洞得成功率仅仅65%，而且不稳定，UDP打洞在计算机科学中，UDP打洞指的是一种普遍使用的NAT穿越技术，通过UDP路由验证实现NAT穿越是一种在处于使用了NAT的私有网络中的Internet主机之间建立双向UDP连接的方法。

以上就是关于TCP打洞实现全部的内容，包括:TCP打洞实现、QQ是一个基于TCP/UDP协议的通讯软件、如何使用java实现tcp的p2p的打洞技术等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！