P2P打洞与转发

0.063字数 1367阅读 2352

P2P打洞与转发

前言


经过3月份的动荡,总算下定决心在目前这家公司安定下来,但是随之而来的也是新技术的挑战。我所在的部门是做硬件存储和云存储相关的产品,所有的APP都是围绕着硬件产品来开发。这和以前做电商类平台专注于界面交互不一样,硬件产品更多的是多媒体播放以及各种通讯技术的运用。由于存储设备并不能提供强大的API接口支持,很多后端的工作都移动到前端来做。(骂了一辈子后端,再也没有后端能够给我”嫌弃”啦 (T﹏T))
p2p打洞就是目前需要研究攻克的技术之一,这里记录下最近2天学习的心得。

什么是NAT(Network Address Translators)


NAT就是网络转换器,也就是路由器中的一个模块。当今的联网设备多种多样,但是全球公网的IP地址是有限的,肯定不能满足所有设备分配一个公网IP。路由器就是为了解决这一矛盾而诞生的,它把内部设备划分成域,形成内网,在内网的设备相互通信使用内网IP,如果内网的设备需要访问外网,则路由器统一用一个公共IP转发出去,收到消息再转变成内网IP,然后转发给内网设备。这样就实现了多个设备公用一个公网IP地址。

公网数据传达到路由器后,路由器又是怎么知道是内网哪个数据的呢?答案是端口号。路由器会给每个需要请求外网数据的内网设备一个端口号。比如设备A的内网IP为192.168.20.1,设备B的内网IP地址为192.168.20.2 ,路由器的公网地址是200.20.20.20。如果设备A需要访问外网,数据经过路由器的时候会添加上一个端口号再转发出去,如200.20.20.20:4400。那么当外部需要访问200.20.20.20:4400的数据就会被路由器转发给设备A而不是B设备B。

为什么需要打洞


实现原理

如图所示,有这么一个需求终端A要访问终端B。A先给B发送数据经过NAT B,NAT B打开数据包看来源IP是100.10.10.10,但是NAT B发现自己内部并没有设备请求过这个IP,于是NAT B会认为这个数据包是“不请自来”的。对待这种“不请自来”的数据包,大多数路由器出于安全性的考虑,都选择丢弃包,NAT B也是如此,因此这条请求被抛弃,并没有传达到终端B。反过来终端B访问终端A也是如此。这样看来,终端A和终端B永远都不能通信,这是就需要有第三方介入,完成消息的传达,而这个过程就成为“打洞”。

怎么实现打洞


上面的例子中默认设备A知道设备B的公网IP和端口号,然后实际上内网的IP和端口号很可能时时变动,因此,Sever S不仅要完成消息的转发,还得分别告诉设备A和设备B对方的公网IP和端口号。

首先,终端A连接上互联网,给Sever S发送一个请求,Sever S记录了A的公网IP为100.10.10.10:4400。终端B连接上互联网,给Sever S发送一个请求 ,Sever S记录了终端B的公网IP为200.20.20.20:5500。这时Sever S会通知设备B:“设备A的公网地址是100.10.10.10:4400,你快发一条消息给它”。于是设备B就会尝试性发送一条消息到100.10.10.10:4400,并告诉Sever S:“我已经发送了”。虽然设备B发送的的请求会被NAT A拦截下来,但是NAT B记录了设备B访问的100.10.10.10:4400,以后来自这个IP的信息不会被拦截。Sever S收到设备B的消息后,就给设备A发送请求:“设备B的公网IP是200.20.20.20:5500,你可以发送消息了”。设备A收到消息后,就可以直接用200.20.20.20:5500这个公网地址与设备B交流,打洞也就因此实现了。

关于失败率


在设备A与设备B的打洞过程大多不是即时完成的,有可能任意一方的的端口被重新分配,有可能设备B比设备A先上线等等,因此,打洞还是存在一定的失败率。这时就需要结合一些算法,如端口猜测算法,逆向打洞等技术支持,减小失败率。

推荐阅读更多精彩内容