NAT网络中双向P2P打洞的实现
原文链接：http://blog.starrtc.com/?p=134
钟情于在互联网（物联网）产品中集成P2P功能的企业，要么是对自己的技术实力有迷之自信，要么是对自己的资金实力有清醒认识。因为具备P2P功能的万千终端，可以零成本地分担原本集中式Servers所消耗的的带宽、服务器资源压力。
企业对P2P功能的集成也有不同层级，某些家down下 eMule、eDonkey直接改一版。要知道国内的运营商是不会甘心给eMule、eDonkey做数据通道，封堵是必然的。这也就要求想做P2P功能的企业，需要针对NAT网络实现打洞，继而完成数据的传送。
先罗列出NAT网络间，可能存在的打洞路径和方向：
- Full Cone NAT：某台Peer一旦在公网上暴露了【IP_1：Port_1】后，全网其他任意一台Peer_other的任何一个端口Peer_port_all，都能访问到【IP_1：Port_1】
- Restricted Cone NAT：某台Peer一旦在公网上暴露了【IP_2：Port_2】后，全网某一台Peer_part，只有从【IP_2：Port_2】向Peer_part发送过数据包，那么Peer_part的任何一个端口Peer_part_all，都能访问到【IP_2：Port_2】
- Port Restricted Cone NAT：某台Peer一旦在公网上暴露了【IP_3：Port_3】后，全网某一台Peer_special，只有从【IP_3：Port_3】向Peer_special的【IP_special：Port_special】发送过数据，那么只有Peer_special【IP_special：Port_sepcial】能访问到【IP_3：Port_3】
- Symmetric NAT：由于在 Symmetric NAT后的某台Peer，只要访问对方Peer的【IP：Port】任意一个字段改变，那么Symmetric NAT后的Peer对外暴露的【IP_sym：Port_sym】就会改变。所以在一方是Symmetric NAT的情况下，另一方，只有是Full Cone 或Restricted Cone NAT，才有机会P2P。
从上面经典的四种类型来看，由于P2P（Peer to Peer）中的Peer所在NAT网络差异，会存在以下4种打洞成功与否的结果：
| 场景 | 打洞流程发起发向 | 成功与否 | 备注 |
| 1 | Peer_A → Peer_B | √ | 只有当Peer_A发起时，才能成功 |
| 2 | Peer_B → Peer_A | √ | 只有当Peer_B发起时，才能成功 |
| 3 | Peer_A ↔ Peer_B | √ | 任何一方发起，都能成功 |
| 4 | Peer_A ↔ Peer_B | × | 任何一方发起，都是失败 |
铺垫了这么多，都是为了引出本文的重点：要想提高在NAT网络中，P2P打洞成功率，最有效的方法是，实现Peer_X间的双向打洞。
貌似平淡无奇的结论，在波谲云诡的NAT的世界里，是很稚嫩的。因为很多客户都咨询过 starRTC 的客户人员，他们也采用了类似的思路，但是打通的效果并不理想，何解？
请回顾上表，当Peer_A和Peer_B属于场景3的时候，Peer间的双向打洞是没问题的。但是属于场景1、2时，并且打洞逻辑是采用同一组Peer的端口时，那能不能通，就得看运气了。我们还给打洞，取了一个更形象的名称：敲门。那能确保打洞成功的顺序是：
Peer_A发敲门数据Peer_A的38000口，到Peer_B的28000口，记做【Peer_A:38000，Peer_B:28000】，Peer_B也发类似的敲门数据【Peer_B:38000，Peer_A:28000】，同时将这两条敲门数据，记录到打洞服务器。Peer_A要能发回敲数据【Peer_A:28000, Peer_B:38000】，一定要在打洞服务器能找到敲门数据【Peer_B:38000，Peer_A:28000】，否则等待。Peer_B的回敲也类似。这样就能保证P2P打洞过程中的敲门、回敲的严格顺序。
starRTC上线后，从全网数据来看，包括一级运营商：中国电信、中国联通、中国移动，以及若干二线运营商：方正宽带、长城宽带、鹏博士，平均打洞成功率 > 67%，另一项好到傲视竞品的数据：P2P过程中数据完整到达率 > 95%。要知道在随机用户中，还有众多的4G用户当分母了。
下期预告：在P2P时，有没有被某些所谓的安全路由器，莫名其妙地静默丢包了？何解？那自然是有解的 … …
