p2sp设计需要考虑的几点问题整理（续）

通过前面一篇笔记的简单介绍，我们可以看到这个设计与其说这是P2P文件传输，不如说它是文件共享。因为P2P文件传输应该是针对单一文件，它在下载的同时还为其它用户提供“下载服务”，也就是客户端A下载的分片供客户端B下载，反过来客户端B下载的分片供客户端A下载，而这是个复杂的协同过程。

在网上搜集一些关于“文件共享”和“文件传输”的特点以及优缺点分析，在文件共享中，用户往往需要长时间地保存很多内容，而文件传输仅仅关注当前正在处理的单个文档。文件共享中，为了达到更好的下载效果，往往需要更多的文件提供者，而文件传输更多是同时下载和上传，只需要较短时间，所以两者在设计上有很多根本性的差别。

P2P容易造成网络拥堵

单论传输过程，BT或者其他P2P软件已经处理得很好了，但是在协同处理上仍需要改进。比如BT在要求别的节点传输内容块时，需要向它们查询是否拥有该内容块，然后建立连接，这种的缺点是实时性差，难以调度各个节点的资源，容易造成网络拥堵。

认识NAT

我们要实现UDP穿透，就需要看看客户端网络环境是否支持，前文介绍的UDP穿透过程中就需要NAT设备的帮助。

NAT（网络地址转换）按照实现方式分为：Full Cone NAT,Restricted Cone NAT, Port Restricted Cone NAT以及Symmetric NAT四种

• Full Cone: 同一个内部客户端的请求源IP端口X被NAT转换为同一个外部IP以及端口Y，不管这些请求是否来自一个应用还是多个应用，当X-Y关系建立后，任何外部主机向Y发送的UDP报文均可被NAT转发给X。
• Restricted Cone:是Full Cone的受限版本，只有当内部主机曾经发送过报文的外部主机（假设为Z）发送给Y的UDP报文才会被转发。
  
• Port Restricted Cone:是Restricted Cone的进一步受限版本，Z主机必须是某个特定的端口P发送的UDP报文才会被转发（这个P是内部主机对外请求时的远端端口）
  
• Semmetric NAT:只有来自于内部同一个客户端，且请求同样目标才分配同一通道（这种方式极难穿透成功）

前面三种NAT类型都是可以进行穿透的（好在国内大部分网络环境都是前三者，尤其是第三种NAT类型）

如何检测NAT类型

当然我们可以利用公共的Stun服务器实现检测功能，可以参照我的另一篇介绍——《Stun协议检测网络环境流程》

大致工作原理如下，首先有一个公网的Server并且绑定了两个公网IP(IP-1,IP-2)。这个Server做UDP监听(IP-1,Port-1),(IP-2,Port-2)并根据客户端的要求进行应答。

第一步：检测客户端是否有能力进行UDP通信以及客户端是否位于NAT后？ 
客户端建立UDP socket向服务器（IP-1，Port-1）发送数据包并等待返回，如果超时，则可能是防火墙或NAT阻止UDP通信，这样的客户端不能P2P（当然需要多次尝试）
如果服务器返回客户端IP，Port与自身LocalIP，LocalPort相同，则说明出于公网，并不在NAT后，否则进行第二步判断。

第二步：检测客户端NAT是否是Full Cone NAT？ 
客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包，服务器用另一对(IP-2,Port-2)响应客户端发一个数据包,客户端发送请求后立即开始接受数据包，记着设置超时. 如果得到响应，则是Full Cone（判断停止），否则进行下一步判断。

第三步：检测客户端NAT是否是Symmetric NAT？ 
客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包,重复这个过程直到收到回应（一定能够收到，因为第一步保证了这个客户端可以进行UDP通信）。用同样的方法用一个socket向服务器的(IP-2,Port-2)发送数据包要求服务器返回客户端的IP和Port。 
比较上面两个过程从服务器返回的客户端(IP,Port),如果两个过程返回的(IP,Port)有一对不同则说明客户端为Symmetric NAT，这样的客户端无法进行UDP-P2P通信（检测停止）。否则是Restricted Cone NAT，是否为Port Restricted Cone NAT有待下一步检测。

第四步：检测客户端NAT是Restricted Cone NAT还是Port Restricted Cone NAT？ 
客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器用IP-1和一个不同于Port-1的端口发送一个UDP数据包响应客户端, 如果每次都无法接受到服务器的回应，则说明客户端是一个Port Restricted Cone NAT，如果能够收到服务器的响应则说明客户端是一个Restricted Cone NAT。以上两种NAT都可以进行UDP-P2P通信。

P2P应用程序一些开发难题

需要开发用于消息交换的P2P私有协议

必须查找并连接隐藏在NAT（网络地址转换）或防火墙背后的P2P应用程序实例

需要支持在广域网中定位各个P2P应用程序所需要的系统架构（网络拓扑数据结构及路由表）

P2P的激励机制，防止某些吸血用户导致整个系统低效率