C# UDP通信

最近刚搞完一个TCP通信的项目，但是发觉还是UDP+TCP的通信方式效率稳定性比较高。所以又看了看关于UDP通信的内容，

UDP通信简介：

http://www.csharpwin.com/csharpspace/13275r1253.shtml

UDP将网络数据流量压缩成数据报的形式，每一个数据报用8个字节（8 X 8位=64位）描述报头信息，剩余字节包含具体的传输数据。UDP报头（只有8个字节）相当于TCP的报头（至少20个字节）很短，UDP报头由4个域组成，每个域各占2个字节，具体为源端口、目的端口、用户数据报长度和校验和，

关于UDP通信的两种方式：

1、socket通信

2、udpClient通信

1、同步

socket.Send();

socket.Recevie();

同步阻塞：

默认的同步通信时receive()会阻塞，挂起等待远程主机的消息；

同步非阻塞：

2、异步

socket.beginSend();

socket.beginReceive();

回调函数何时回调？

关于UDP穿透NAT，NAT的类型：

http://www.cnblogs.com/whyandinside/archive/2010/12/08/1900492.html

1.       NAT分类
根据Stun协议(RFC3489),NAT大致分为下面四类
1)      Full Cone
这种NAT内部的机器A连接过外网机器C后,NAT会打开一个端口.然后外网的任何发到这个打开的端口的UDP数据报都可以到达A.不管是不是C发过来的.
例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)
任何发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)
2)      Restricted Cone
这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用任何端口和A通信.其他的外网机器不行.
例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)
任何从C发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)
3)      Port Restricted Cone
这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用原来的端口和A通信.其他的外网机器不行.
例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)
C(202.88.88.88:2000)发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)
以上三种NAT通称Cone NAT.我们只能用这种NAT进行UDP打洞.
4)      Symmetic
对于这种NAT.连接不同的外部目标.原来NAT打开的端口会变化.而Cone NAT不会.虽然可以用端口猜测.但是成功的概率很小.因此放弃这种NAT的UDP打洞.
2.       UDP hole punching
对于Cone NAT.要采用UDP打洞.需要一个公网机器C来充当”介绍人”.内网的A,B先分别和C通信.打开各自的NAT端口.C这个时候知道A,B的公网IP:Port. 现在A和B想直接连接.比如A给B发.除非B是Full Cone.否则不能通信.反之亦然.但是我们可以这样.
A要连接B.A给B发一个UDP包.同时.A让那个介绍人给B发一个命令,让B同时给A发一个UDP包.这样双方的NAT都会记录对方的IP,然后就会允许互相通信.
3.       同一个NAT后面的情况
如果A,B在同一个NAT后面.如果用上面的技术来进行互连.那么如果NAT支持loopback(就是本地到本地的转换),A,B可以连接,但是比较浪费带宽和NAT.有一种办法是,A,B和介绍人通信的时候,同时把自己的local IP也告诉服务器.A,B通信的时候,同时发local ip和公网IP.谁先到就用哪个IP.但是local ip就有可能不知道发到什么地方去了.比如A,B在不同的NAT后面但是他们各自的local ip段一样.A给B的local IP发的UDP就可能发给自己内部网里面的某某某了.

关于UDP通信穿透NAT的流程：

1、http://www.rapapaing.com/blog/?p=24

2、http://blog.csdn.net/formiss/article/details/4758591

3、http://www.cnblogs.com/siqing99/p/3375161.html

思路如下（参照源代码）：

　　1、 frmServer启动两个网络侦听，主连接侦听，协助打洞的侦听。

　　2、 frmClientA和frmClientB分别与frmServer的主连接保持联系。

　　3、 当frmClientA需要和frmClientB建立直接的udp连接时，首先连接frmServer的协助打洞端口，并发送协助连接申请,同时在该端口号上启动侦听。

     4、  frmServer的协助打洞连接收到frmClientA的申请后通过主连接通知frmClientB，并将frmClientA经过NAT-A转换后的公网IP地址和端口等信息告诉frmClientB。

　　5、 frmClientB收到frmServer的连接通知后首先与frmServer的协助打洞端口连接，发送一些数据后立即断开，目的是让frmServer能知道frmClientB经过NAT-B转换后的公网IP和端口号。

　　6、 frmClientB尝试与frmClientA的经过NAT-A转换后的公网IP地址和端口进行connect，不同的路由器会有不同的结果，多数路由器对未知不请自到的SYN请求包直接丢弃而导致connect失败，但NAT-A会纪录此次连接的源地址和端口号，为接下来真正的连接做好了准备，这就是所谓的打洞，即frmClientB向frmClientA打了一个洞，下次frmClientA就能直接连接到frmClientB刚才使用的端口号了。

　　7、 客户端frmClientB打洞的同时在相同的端口上启动侦听。frmClientB在一切准备就绪以后通过与frmServer的主连接回复消息“可以了，已经准备”，frmServer在收到以后将frmClientB经过NAT-B转换后的公网IP和端口号告诉给frmClientA。

　　8、 frmClientA收到frmServer回复的frmClientB的公网IP和端口号等信息以后，开始连接到frmClientB公网IP和端口号，由于在步骤6中frmClientB曾经尝试连接过frmClientA的公网IP地址和端口，NAT-A纪录了此次连接的信息，所以当frmClientA主动连接frmClientB时，NAT-B会认为是合法的SYN数据，并允许通过，从而直接的udp连接建立起来了。

3、STUN协议

简单的说STUN协议就是用来协助检测本机的内网IP是否与外网IP一致以及检测NAT类型，以便判断是否能够UDP打洞。网上有STUN服务器可以提供检测。

NAT and Traversal NAT（TURN/STUN/ICE）

http://www.cnblogs.com/whyandinside/archive/2010/12/08/1900492.html

以下转载自：http://blog.csdn.net/suxinpingtao51/article/details/11809011

socket 通信关于bind那点事

结论：
1、采用TCP通信时，客户端不需要bind()他自己的IP和端口号，而服务器必须要bind()自己本机的IP和端口号;
2、若采用UDP通信时（这里是有客户端和服务器之分才这么说的，若是指定特定端口的UDP对等通信则不一样了），客户端可以也不需要bind（）他自己的IP和端口号，而服务器需要bind自己IP地址和端口号；

原因：

1、
因为服务器是时时在监听有没有客户端的连接，如果服务器不绑定IP和端口的话,客户端上线的时候怎么连到服务器呢,所以服务器要绑定IP和端口，而客户端就不需要了,客户端上线是主动向服务器发出请求的,因为服务器已经绑定了IP和端口,所以客户端上线的就向这个IP和端口发出请求,这时因为客户开始发数据了(发上线请求),系统就给客户端分配一个随机端口,这个端口和客户端的IP会随着上线请求一起发给服务器,服务收到上线请求后就可以从中获起发此请求的客户的IP和端口,接下来服务器就可以利用获起的IP和端口给客户端回应消息了。

2、采用UDP通信，
1）若有客户端和服务器之分的程序，创建sock后即可在该socket上用recvfrom/sendto方法发送接受数据了，因为客户端只需要用sendto发送数据到指定的地址，当然若是bind了，程序也没什么问题，区别就是系统用默认自动bind()指定你自己的socket参数地址(特别是在指定特定端口的UDP对等通信)只是这种情况没有这样用的。
那UDP服务器是怎么知道客户端的IP地址和UDP端口？
一般来说有两种方式：
一种是客户端发消息显示显式地告诉服务器IP地址和端口，消息内容就包括IP地址和UDP端口。
另外一种就是隐式的，服务器从收到的包的头部中得到包的源IP地址和端口。

2）若是没有客户端和服务器之分的程序，即自己指定特定端口的UDP对等通信，则客户端和服务器都需要bind（）IP地址和端口了。
通常udp服务端根本不需要知道客户端的socket，它直接建立一个socket用于发送即可，udp通信的关键只在于IP和端口。
多个客户端如果需要点到点分发，必须给服务端socket循环设置每个客户端的IP并发出，但更常用的是广播分发，服务端socket设定一个X.X.X.255的广播地址并始终向它发送，每个客户端建立的socket只需要绑定这个广播地址便可以收到。