记录

• 202004 补充整理，补充组播MAC地址相关信息
• 201103 整理

关于 UDP

UDP（User Datagram Protocol，用户数据报协议），与TCP相对应的面向非连接的协议，它不与对方建立连接，而是直接发送数据。 “面向非连接”就是在正式通信前不必与对方先建立连接，不管对方状态就直接发送。这与现在风行的手机短信非常相似：你在发短信的时候，只需要输入对方手机号就OK了。 使用UDP协议进行信息的传输之前不需要建议连接。换句话说就是客户端向服务器发送信息，客户端只需要给出服务器的ip地址和端口号，然后将信息封装到一个待发送的报文中并且发送出去。至于服务器端是否存在，或者能否收到该报文，客户端根本不用管。 UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。比如，我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。例如，在默认状态下，一次“ping”操作发送4个数据包（如图2所示）。大家可以看到，发送的数据包数量是4包，收到的也是4包（因为对方主机收到后会发回一个确认收到的数据包）。这充分说明了UDP协议是面向非连接的协议，没有建立连接的过程。正因为UDP协议没有连接的过程，所以它的通信效果高；但也正因为如此，它的可靠性不如TCP协议高。QQ就使用UDP发消息，因此有时会出现收不到消息的情况。 尽管TCP和UDP都使用相同的网络层（IP），TCP却向应用层提供与UDP完全不同的服务。 与 TCP 不同， UDP 并不提供对 IP 协议的可靠机制、流控制以及错误恢复功能等。由于 UDP 比较简单， UDP 头包含很少的字节，比 TCP 负载消耗少。 UDP 适用于不需要 TCP 可靠机制的情形，比如，当高层协议或应用程序提供错误和流控制功能的时候。 UDP 是传输层协议，服务于很多知名应用层协议，包括网络文件系统（NFS）、简单网络管理协议（SNMP）、域名系统（DNS）以及简单文件传输系统（TFTP）。 UDP的特点： 1、UDP传送数据前并不与对方建立连接，即UDP是无连接的，在传输数据前，发送方和接收方相互交换信息使双方同步。 2、UDP不对收到的数据进行排序，在UDP报文的首部中并没有关于数据顺序的信息（如TCP所采用的序号），而且报文不一定按顺序到达的，所以接收端无从排起。 3、UDP对接收到的数据报不发送确认信号，发送端不知道数据是否被正确接收，也不会重发数据。 4、UDP传送数据较TCP快速，系统开销也少。 从以上特点可知，UDP提供的是无连接的、不可靠的数据传送方式，是一种尽力而为的数据交付服务。 UDP传送速度快 由于UDP的特性：它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。比如我们聊天用的ICQ和OICQ就是使用的UDP协议。 多链路层协议都提供错误检查，包括流行的以太网协议，也许想知道为什么UDP也要提供检查和。其原因是链路层以下的协议在源端和终端之间的某些通道可能不提供错误检测。虽然UDP提供有错误检测，但检测到错误时，UDP不做错误校正，只是简单地把损坏的消息段扔掉，或者给应用程序提供警告信息 虽然UDP是一个不可靠的协议，但它是分发信息的一个理想协议。例如，在屏幕上报告股票市场、在屏幕上显示航空信息等等。UDP也用在路由信息协议 RIP（Routing Information Protocol）中修改路由表。在这些应用场合下，如果有一个消息丢失，在几秒之后另一个新的消息就会替换它。UDP广泛用在多媒体应用中，例如，Progressive Networks公司开发的RealAudio软件，它是在因特网上把预先录制的或者现场音乐实时传送给客户机的一种软件，该软件使用的 RealAudio audio-on-demand protocol协议就是运行在UDP之上的协议，大多数因特网电话软件产品也都运行在UDP之上。

vs TCP

TCP：面向连接，可靠，适合传输大量数据应用场合，速度慢 UDP：面向非连接，不可靠，适合少量数据应用场合，速度快

UDP应用

• UDP典型的应用比如实时音视频传输、流媒体。UDP提供较高的实时性，以牺牲可靠性为代价的，可能产生报文丢失、重复、失序等问题。TCPTCP具有重传机制、拥塞控制机制，不适合实时音视频的传输。UDP启动速度要比TCP快，传输之前不需要建立连接，没有确认机制来确保报文到达，也就没有重传机制，传输效率高，可以用它来传输那些对实时性要求高于其可靠性的实时性数据。
• 实时通讯聊天

UDP 单播 组播 广播

广播

广播UDP与单播UDP的区别就是IP地址不同，广播使用广播地址255.255.255.255，将消息发送到在同一广播网络上的每个主机。值得强调的是：本地广播信息是不会被路由器转发。当然这是十分容易理解的，因为如果路由器转发了广播信息，那么势必会引起网络瘫痪。这也是为什么IP协议的设计者故意没有定义互联网范围的广播机制。 广播地址通常用于在网络游戏中处于同一本地网络的玩家之间交流状态信息等。广播就不在写演示程序了，读者可以将ECHO程序的ip地址改为广播地址即可。 其实广播顾名思义，就是想局域网内所有的人说话，但是广播还是要指明接收者的端口号的，因为不可能接受者的所有端口都来收听广播。 UDP 广播地址：255.255.255.255

组播

传输组播报文时，传输目标不再是一个具体的接收者，而是一个成员不确定的组，所以需要使用组播MAC地址作为目的地址，组播MAC地址是一个逻辑的MAC地址。 ipv4中的多播地址范围是：224.0.0.0****到239.255.255.255。 224.0.0.0～224.0.0.255 路由协议及其他底层拓扑发现和维护协议的保留 224.0.1.0 - 224.0.1.255 会议及电视会议 239.0.0.0 - 239.255.255.255 局域网内部使用地址，不能用于 Internet 组播MAC地址的高24bit位是以01-00-5E开头，低23bit为组播IP地址的低23bit 比如：01-00-5e-03-03-03  

组播与路由设备转发

UDP组播，multicast，好像被称为flood，可能被路由器禁用，需要在路由器中设置是否开启UDP组播转发

安卓系统与组播

发送可以，接收不了组播，需要建立单播接收 //Multicasting on Android can be quite the headache. Firstly, there’s the fact that for some obscure reason, certain devices doesnt even support multicasting, and secondly you need permissions and smart code to make it work at all. Allows an application to receive Wifi Multicast packets. Normally the Wifi stack filters out packets not explicitly addressed to this device. Acquring a MulticastLock will cause the stack to receive packets addressed to multicast addresses. Processing these extra packets can cause a noticable battery drain and should be disabled when not needed. //As it turns out, the Android Wifi stack ignores multicast packets not explicitly destined for the device itself. Given the nature of how JmDNS works (Zeroconf to be more precise), this prevented the device from discovering any services on the network but still allowed other clients to discover its services. To solve the problem, one must use the Android SDK to obtain a multicast lock.

UDP客户端和服务器端

使用UDP进行程序设计可以分为客户端和服务器端两部分。服务器端主要包含建立套接字、将套接字与地址结构进行绑定、读写数据、关闭套接字几个过程。客户端包括建立套接字、读写数据、关闭套接字几个过程。服务器端和客户端二者流程之间的其主要的差别在于对于地址的绑定（bind）函数，客户端可以不用进行地址和端口的绑定操作。 UDP协议的程序设计框架，客户端和服务器之间的差别在于服务器必须使用bind()函数来绑定侦听的本地UDP端口，而客户端则可以不进行绑定，直接发送到服务器地址的某个端口地址