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先上线等等，因此，打洞还是存在一定的失败率。这时就需要结合一些算法，如端口猜测算法，逆向打洞等技术支持，减小失败率。
