近来研究IM软件

最近做一个语音教学的东东，也就是一个语音聊天室 。
现在基于TCP实现的，所有语音数据都由Server中转。在广域网速度还可以。要求带宽15---20bps.
对于这种语音的数据用Server中转肯定支持不了多少用户，这是一定的。因为数据量太大了。
所以首先想在两个人私聊的时候能够建立点对点。然后在实现多人点对点，正好想写毕业论文，如果要是能够把P2P加进入多少能够提高很多含金量啊。要不然感觉写这个内容太少了。

在上面的情形下最近看了点p2p,尤其是UDP穿越NAT.感觉UDP的点对点在理论上不是很难。我把我总结的发上来，有不对的地方大家指教。同时真希望这个话题能深入的展开。。。。。。。。。有经验的多讲讲，我不仅要文字消息，同时还需要语音点对点。

P2P的NAT研究                  
第一部分：NAT介绍
第二部分：NAT类型检测

第一部分： NAT介绍
各种不同类型的NAT(according to  RFC)
Full Cone NAT:
内网主机建立一个UDP socket(LocalIP:LocalPort) 第一次使用这个socket给外部主机发送数据时NAT会给其分配一个公网(PublicIP:PublicPort),以后用这个socket向外面任何主机发送数据都将使用这对(PublicIP:PublicPort)。此外，任何外部主机只要知道这个(PublicIP:PublicPort)就可以发送数据给(PublicIP:PublicPort)，内网的主机就能收到这个数据包
Restricted Cone NAT:
内网主机建立一个UDP socket(LocalIP:LocalPort) 第一次使用这个socket给外部主机发送数据时NAT会给其分配一个公网(PublicIP:PublicPort),以后用这个socket向外面任何主机发送数据都将使用这对(PublicIP:PublicPort)。此外，如果任何外部主机想要发送数据给这个内网主机，只要知道这个(PublicIP:PublicPort)并且内网主机之前用这个socket曾向这个外部主机IP发送过数据。只要满足这两个条件，这个外部主机就可以用自己的(IP,任何端口)发送数据给(PublicIP:PublicPort)，内网的主机就能收到这个数据包
Port Restricted Cone NAT:
内网主机建立一个UDP socket(LocalIP:LocalPort) 第一次使用这个socket给外部主机发送数据时NAT会给其分配一个公网(PublicIP:PublicPort),以后用这个socket向外面任何主机发送数据都将使用这对(PublicIP:PublicPort)。此外，如果任何外部主机想要发送数据给这个内网主机，只要知道这个(PublicIP:PublicPort)并且内网主机之前用这个socket曾向这个外部主机(IP,Port)发送过数据。只要满足这两个条件，这个外部主机就可以用自己的(IP,Port)发送数据给(PublicIP:PublicPort)，内网的主机就能收到这个数据包
Symmetric NAT:
内网主机建立一个UDP socket(LocalIP,LocalPort),当用这个socket第一次发数据给外部主机1时,NAT为其映射一个(PublicIP-1,Port-1),以后内网主机发送给外部主机1的所有数据都是用这个(PublicIP-1,Port-1)，如果内网主机同时用这个socket给外部主机2发送数据，第一次发送时，NAT会为其分配一个(PublicIP-2,Port-2), 以后内网主机发送给外部主机2的所有数据都是用这个(PublicIP-2,Port-2).如果NAT有多于一个公网IP，则PublicIP-1和PublicIP-2可能不同，如果NAT只有一个公网IP,则Port-1和Port-2肯定不同，也就是说一定不能是PublicIP-1等于 PublicIP-2且Port-1等于Port-2。此外，如果任何外部主机想要发送数据给这个内网主机，那么它首先应该收到内网主机发给他的数据，然后才能往回发送，否则即使他知道内网主机的一个(PublicIP,Port)也不能发送数据给内网主机，这种NAT无法实现UDP-P2P通信。

第二部：NAT类型检测
前提条件:有一个公网的Server并且绑定了两个公网IP(IP-1,IP-2)。这个Server做UDP监听(IP-1,Port-1),(IP-2,Port-2)并根据客户端的要求进行应答。

第一步：检测客户端是否有能力进行UDP通信以及客户端是否位于NAT后？
客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器返回客户端的IP和Port, 客户端发送请求后立即开始接受数据包，要设定socket Timeout（300ms），防止无限堵塞. 重复这个过程若干次。如果每次都超时，无法接受到服务器的回应，则说明客户端无法进行UDP通信，可能是防火墙或NAT阻止UDP通信，这样的客户端也就不能P2P了（检测停止）。
当客户端能够接收到服务器的回应时，需要把服务器返回的客户端（IP,Port）和这个客户端socket的（LocalIP，LocalPort）比较。如果完全相同则客户端不在NAT后，这样的客户端具有公网IP可以直接监听UDP端口接收数据进行通信（检测停止）。否则客户端在NAT后要做进一步的NAT类型检测(继续)。

第二步：检测客户端NAT是否是Full Cone NAT？
客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器用另一对(IP-2,Port-2)响应客户端的请求往回发一个数据包,客户端发送请求后立即开始接受数据包，要设定socket Timeout（300ms），防止无限堵塞. 重复这个过程若干次。如果每次都超时，无法接受到服务器的回应，则说明客户端的NAT不是一个Full Cone NAT，具体类型有待下一步检测(继续)。如果能够接受到服务器从(IP-2,Port-2)返回的应答UDP包，则说明客户端是一个Full Cone NAT，这样的客户端能够进行UDP-P2P通信（检测停止）。

第三步：检测客户端NAT是否是Symmetric NAT？
客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器返回客户端的IP和Port, 客户端发送请求后立即开始接受数据包，要设定socket Timeout（300ms），防止无限堵塞. 重复这个过程直到收到回应（一定能够收到，因为第一步保证了这个客户端可以进行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数据包响应客户端, 客户端发送请求后立即开始接受数据包，要设定socket Timeout（300ms），防止无限堵塞. 重复这个过程若干次。如果每次都超时，无法接受到服务器的回应，则说明客户端是一个Port Restricted Cone NAT，如果能够收到服务器的响应则说明客户端是一个Restricted Cone NAT。以上两种NAT都可以进行UDP-P2P通信。

注：以上检测过程中只说明了可否进行UDP-P2P的打洞通信，具体怎么通信一般要借助于Rendezvous Server。另外对于Symmetric NAT不是说完全不能进行UDP-P2P达洞通信，可以进行端口预测打洞，不过不能保证成功。

 

1.传递聊天消息的时候使用UDP or TCP?
聊天消息如果走Server中转，我认为毫无疑问TCP,因为聊天的消息要求可靠性。如果用UDP的话还要实现可靠性。对于可靠性的实现也不一定比TCP节省资源和系统开销。
UDP可靠性可以参见UDT,虽然他的设计主要是在高带宽少并发大数据量的传输情况下，不过我感觉实现可以借鉴。

聊天消息如果P2P,感觉还是UDP好一些，毕竟UDP的点对点实现要比TCP容易的多

2.聊天消息P2P or Server转发？
能实现P2P最理想，Server转发最次，两者结合可以考虑啊

3.客户端与服务器TCP采用长连接短连接？
短连接确实很费资源，httpServer还Keep-Alive呢？所以一个消息一次连接感觉呵呵呵呵呵呵。
如果采用长连接，由于TCP的RTT不公平，所以如果数据量和并发比较大的话可能RTT大的客户端饿死。不过每个客户端聊天文字消息的数据量一般不大。。。
采用不长不短的连接最好，哈哈哈哈哈哈。。。

4.文件传输方式？
客户端点对点首先的问题就是NAT和防火墙，其次是可靠性。
TCP固然可靠，不过NAT防火墙是个大问题啊？？？
Http, FTP基于TCP。