udp的广播_c# udp广播_udp广播和组播

其实是个好问题，UDP的广播或者说组播，它是一种非常有效率的多播方式，在交换网络当中，它是沿着生成树传播的。什么叫做沿着生成树传播呢？假如说我有一台汇聚交换机，下面有两台接入交换机，每个接入交换机上有8台服务器，我从其中一个交换机的一台服务器上发送一个广播包，这个包：

被接入交换机复制到同交换机的所有其他口，以及汇聚的上联口上

被汇聚交换机复制到另一台接入交换机上

另一台接入交换机将它复制到所有服务器的端口上

可以看到，每条链路、每个设备都最多只会经过一次，因此占用的带宽不会随着广播域的增大而扩大。如果是两两建立TCP连接那就不一样了，每个数据包都会发送N-1次，也就占用N-1次带宽。ARP和DHCP的广播也是采用这样的方法。

那么广播的缺点是什么呢？缺点也是大大的。

一般来说使用UDP广播都被限制到二层网络范围内，它不能越过网关进行广播，虽然曾经规定过IP段将子网部分全部填充为1的IP地址是广播IP地址，但没有网关会真的处理这种IP包。交换机处理广播包的协议非常简单，按照协议，MAC地址的最高字节的最低位表示该MAC地址是否为广播MAC地址，如果这一位为1，交换机就会采用广播策略，否则会采用学习策略。通过这种策略进行广播，自然也无法让这个包跨越网关，广播到其他IP段内。通常来说，一个二层网的大小应当被严格限制，一般在一个C段附近（最大254个IP地址），这主要是因为交换机按照MAC地址管理交换策略，服务器也要维护MAC-IP关系的ARP表，二层网络中MAC地址过多会给交换机和服务器带来很大的压力。据我之前的实测，默认参数下Linux内核在ARP表项达到几千的数量级的时候会开始强制清理缓存，网络会非常不稳定。这一定是需要避免的。udp的广播

发送广播的MAC地址，将不可避免地被整个数据中心中所有的交换机学习到，这在很多情况下是额外增加了交换机负担的。即使二层广播域得到了控制，但在许多数据中心大二层结构中，即便某个交换机下并没有该VLAN的服务器，也会放开VLAN，因为这样配置起来比较简单。这样原本这些交换机上不需要学习到那些广播源的MAC地址，却也因为收到了广播包而增加了额外的表项。

广播有一种升级得协议叫做组播，一般来说是指IGMP协议，它可以通过组播IP、组播MAC和IGMP协议进行分组的多播，如果交换机支持，可以做到在二层网当中有选择地多播数据包，更加优化流量，也能实现更精确的控制，甚至某些交换机支持经过配置让组播跨三层网段——但是，一般来说很少这么使用，因为将组播包跨三层转发是非常危险的，现代数据中心的网络通常非常复杂，甚至可能有上千个VLAN，如果不慎将组播包复制到了所有的VLAN当中，将导致非常可怕的后果。

一般来说，二层广播功能只用于很底层的网络协议，许多协议自己会影响网络的通断，这种协议自然是不能依赖其他协议来进行工作了，常见的例子包括ARP、DHCP、VRRP、OSPF、IGMP等。业务层一般来说是离广播协议非常远的，广播的socket编程比较复杂，很难写对，许多时候我们也不愿意它随便丢包。一般来说这种多到多的结构，都是通过中心转发节点然后由TCP实现的。比如说我们希望多个服务器进行节点发现，以及竞选出主节点，主流的做法是通过一组ZooKeeper服务器来进行；比如说我们希望多个服务器每个都把数据发送到所有其他节点，可以考虑使用一套MQ（比如kalfka）。基于TCP协议的设计稳定可靠安全，对底层网络依赖小，能够在包括NAT的多种网络情况下正常工作，任何情况下都应该是业务类需求的首选。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shumachanpin/article-43923-1.html