如何使用java实现tcp的p2p的打洞技术

建立穿越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参数,该参数用于区分端口重用还是地址重用，在这样的系统里面，上述所有的参数必须都设置才行。

使用Socket可以做到，不过直接编程一般都是在局域网内，如果要在不同局域网间通信，需要使用一台有公网IP的服务器，可以电脑A和电脑B同时连接服务器，然后A向服务器传递文件，服务器再将文件转发电脑B。也可以使用打洞的方式使A、B互联，此时服务器的作用是辅助打洞。A、B向服务器发送信息后socket不要关闭（假设使用10989端口），同时使用Serversocket绑定监听相同的端口（监听10989端口）。在java中有参数可以做到，具体方法请自行百度。服务器获取到A、B的外网地址和端口，将A的外网地址信息发送给B、将B的外网地址信息发送给A。然后使用A没有关闭的Socket向B发送一组信息（此时连接会失败，但是B的路由表上已经记录了A的信息），发送后A向服务器发送消息，服务器告诉B A已经发送消息。然后B使用未关闭的socket向A发送消息，就和A上监听的ServerSocket取得连接了。之后就可以互相传递数据。

1、交换机开启多播功能。
2、ghostsrv和客户端的ghost要求版本同一。
3、最好先用ghostsrv采集母盘，成功率比较高。
组播（Multicast）传输：在发送者和每一接收者之间实现点对多点网络连接。如果一台发送者同时给多个的接收者传输相同的数据，也只需复制一份的相同数据包。它提高了数据传送效率。减少了骨干网络出现拥塞的可能性。

两个错误和一点建议。

● 错误1 是按照题主的在问题里所描述的设计，网关服务器根本没有维持长连接的必要，只需要转发消息给业务服务器后跟 Client 的连接就可以断开了，剩下的都是业务服务器跟 Client 直接通信了。不知题主还有什么关于维持长连接的必要没有在问题里说明？

● 错误2 是如果维持长连接了，把 Client 的端口号转发给业务服务器了有什么用？Client 的这个端口正在跟网关服务器通信呢，业务服务器怎么可能通过这个端口跟 Client 建立连接？难道同一个端口还能被多个 Socket 占用吗？

● 建议 要么改为业务服务器不跟 Client 通信，还是经由网关服务器中转进行；要么业务服务器就需要跟 Client 进行“打洞”（Hole Punching）。

先说为什么要“打洞”。对于处在同一子网下的计算机还好说，假如 Client 在子网 A 下，且 A 下有多态接入设备（最常见的就是走路由了），那么 A 子网下的所有计算对于你的服务器来说 IP 都是一样的，所以你要想要穿过路由直接跟 A 子网下的某台计算机建立连接，就必须要先“打洞”。

再推荐几篇有关 C# 打洞（Hole Punching）的资料：
>

WebRTC ，名称源自 网页即时通信 （英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。

首先，他即是 API 也是协议。

其次，他是浏览器进行音频与视频通话的 API，其实还有屏幕共享的功能。

最后，它现在已经处于 W3C 标准，各大浏览器厂商已经对他进行兼容了。

但是如果我们想使用好 webrtc，就得先了解 websocket。而对于 websocket，大家应该都比较熟悉了，比如社交聊天、多人 游戏 、协同编辑、视频会议、基于位置的应用(地图)、等等需要高实时的场景。我们比较常用的微信、QQ、某些直播软件等等也都是基于 websocket 实现消息与信令的转发。大家看到这里可能在信令这里迟疑了，接着看。

webrtc 是 P2P 的一种技术，什么是 P2P？其实就是 端对端，就说是你的音频、视频流不经过服务器中转，直接由一端发送到另一端。

不经过服务器中转，也就说时候，如果通过过程中服务器突然崩溃，是不是通话还能继续？

是的！但是发送音频视频流前，一定是需要建立 P2P 连接的，建立连接前一定需要服务器进行信令转发，这个信令就是通话两端的标识。

而如果想用 webrtc 实现通话，就得先中转信令、建立连接。而建立连接的话最好是要用 websocket 进行信令转发的。大家都知道，websocket 是个通道，在这个通道的所有端，都可以收到任意一端的消息流，包括发消息的本人。

为什么不经过服务器就可以直接获取到对方的视频音频流呢？是因为建立了 P2P 通道，这个 P2P 在中转信令的时候就已经通了，传输视频音频流的时候还要啥服务器啊。这个时候，肯定有小伙伴表示怀疑，音频视频流可以不通过服务器？是的，我骗了大家，确实要经过服务器，但是只是线上需要服务器转发，如果我们是本地两台或者多台同一局域网的端 进行 webrtc 音频视频流的转发，确实不需要中转服务器，但是线上有可能需要，也有可能不需要，这里又涉及到了一个 打洞 的概念。

我们平常可能会听到比较牛 x 的词汇，什么打洞、内网穿透、NAT 穿越，各种高大上的东西，其实也是蛮好理解的。大家都知道，两个不同网络下的两台主机不可以直接进行通信，而是需要走公网或者说各自的网关。打洞、内网穿透、NAT 穿越其实就是一个意思，就是使用 udp 让我们两台非同一网络的主机互联，不走公网，直接实现连接。有玩过花生壳的同学一定能理解内网穿透这个概念。

本地开发的话，两台主机连同一局域网，根本不需要内网穿透，就可以直接通信。

线上开发的话，如果能够 STUN 打洞成功，也不需要中转服务器。但是，有打洞不成功的概率，为什么呢，因为没有走公网，没有给运营商带来收益却带来通信成本，肯定要限制。国外打洞成功的概率在 70%，但是国内 50%都不到。

所以，为了防止打洞不成功的情况，我们使用 TURN 中转服务器 转发流媒体数据进行一个最后保障。此外还有一种方式为 逆向连接 ，也可以帮助我们实现 P2P 建立，他的原理是必须是一方走公网，也是有局限性的。

coturn 中继服务器由两部分组成 STUN 与 TURN，STUN 帮助我们打洞，TURN 帮助我们转发流媒体数据。

##连接过程

以下所有 API 截止到 20211206 为最新

##我有疑问

给大家看看 sdp 的本质，就是自身的媒体信息和编解码信息

一个 offer，一个 answer，我们彼此都知道对方的媒体信息与编解码信息，这样我们才能好好协商，我这边该用什么方式对你的视频音频流进行解码、渲染。

过程有些繁杂，具体流程小伙伴们可以看这篇文章 WebRTC TURN 协议初识及 turnserver 实践。

了解 webrtc 的音视频采集、桌面采集；

了解 websocket 和 webrtc 的整个链路建立过程；

实现 1V1 文字传输、视频通话、语音通话、屏幕共享；

实现视频通话、语音通话、屏幕共享过程中的截图、录音、录屏及 截图、录音、录屏的在线播放与下载;

将以上功能部署上线；

在这里，我们要对音视频建立过程画一个基本的流程图。

基本流程图

对于这些信令，我们使用 websocket 进行转发，这里大家会问，为什么不使用 >UDP"打洞"原理
1 NAT分类
根据Stun协议(RFC3489),NAT大致分为下面四类
1) Full Cone
这种NAT内部的机器A连接过外网机器C后,NAT会打开一个端口然后外网的任何发到这个打开的端口的UDP数据报都可以到达A不管是不是C发过来的
例如 A:1921688100 NAT:202100100100 C:292888888
A(1921688100:5000) -> NAT(202100100100 : 8000) -> C(292888888:2000)
任何发送到 NAT(202100100100:8000)的数据都可以到达A(1921688100:5000)
2) Restricted Cone
这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口然后C可以用任何端口和A通信其他的外网机器不行
例如 A:1921688100 NAT:202100100100 C:292888888
A(1921688100:5000) -> NAT(202100100100 : 8000) -> C(292888888:2000)
任何从C发送到 NAT(202100100100:8000)的数据都可以到达A(1921688100:5000)
3) Port Restricted Cone
这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口然后C可以用原来的端口和A通信其他的外网机器不行
例如 A:1921688100 NAT:202100100100 C:292888888
A(1921688100:5000) -> NAT(202100100100 : 8000) -> C(292888888:2000)
C(202888888:2000)发送到 NAT(202100100100:8000)的数据都可以到达A(1921688100:5000)
以上三种NAT通称Cone NAT我们只能用这种NAT进行UDP打洞
4) Symmetic
对于这种NAT连接不同的外部目标原来NAT打开的端口会变化而Cone NAT不会虽然可以用端口猜测但是成功的概率很小因此放弃这种NAT的UDP打洞
2 UDP hole punching
对于Cone NAT要采用UDP打洞需要一个公网机器C来充当”介绍人”内网的A,B先分别和C通信打开各自的NAT端口C这个时候知道A,B的公网IP:Port 现在A和B想直接连接比如A给B发除非B是Full Cone否则不能通信反之亦然但是我们可以这样
A要连接BA给B发一个UDP包同时A让那个介绍人给B发一个命令,让B同时给A发一个UDP包这样双方的NAT都会记录对方的IP,然后就会允许互相通信
3 同一个NAT后面的情况
如果A,B在同一个NAT后面如果用上面的技术来进行互连那么如果NAT支持loopback(就是本地到本地的转换),A,B可以连接,但是比较浪费带宽和NAT有一种办法是,A,B和介绍人通信的时候,同时把自己的local IP也告诉服务器A,B通信的时候,同时发local ip和公网IP谁先到就用哪个IP但是local ip就有可能不知道发到什么地方去了比如A,B在不同的NAT后面但是他们各自的local ip段一样A给B的local IP发的UDP就可能发给自己内部网里面的某某某了

---