【TCP/IP】UDP

UDP介绍：

UDP是一个简单的面向数据报的传输层协议：进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发送的IP数据包

这与面向流字符的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系

       UDP不提供可靠性

       应用程序必须关系IP数据报的长度，如果它超过了网络的MTU，那么就要对IP数据报进行分片。

UDP首部：

 

端口号：发送进程和接收进程

UDP长度：UDP首部和UDP数据

校验和：UDP首部和UDP数据校验

TCP端口号与UDP端口号时相互独立的。（rsh和syslog=514）

尽管相互独立，如果TCP和UDP同时提供某种知名服务，两个协议通常选择相同的端口号。这纯粹是为了使用方便，而不是协议本身的要求。如（TCP：53，UDP：53 都是DNS）

 

 

 

UDP校验和：

UDP校验和覆盖UDP首部和UDP数据，IP的首部的校验和，它只能覆盖IP的首部

UDP的校验和是可选的，而TCP的校验和是必须的

UDP数据报的长度可以为奇数字节，但是如果要校验的话就要填充字节0，补齐16bit倍数，填充字段只会用来计算效验和而不会被发走

UDP的校验和包含UDP伪首部、UDP首部、和数据部分。在TCP里面也一样都加入了伪首部。

UDP数据报和TCP数据报都包含一个12字节长的伪首部（实际不占用地址空间），目的是让UDP两次检查数据是否以及正确到达目的地

Tcpdump输出：

三个系统中有两个打开了UDP校验和选项（第1和第2行）由此可以看出UDP校验和是可选的

送出的数据报与收到的数据报具有相同的校验和值（第3和第4行、第5和第6行），发送的包和收到的包，源目IP地址和源目端口那怕掉换过，校验和也还是一样，说明UDP校验和是一个简单的16bit和，16bit校验和校验数据的个数的总数是一样的，位置被换过，那么校验和就是一样的

UDP在发送数据报之前，不会与目的端之间协商什么，而是直接发送

 

UDP的应用

1.    查询类（DNS）

2.    实时流量（语音、视频）

3.    传输数据（TFTP）

UDP在查询类里面是非常靠谱的，效率高，不用像TCP那样还要先建立三次握手，在实时流量的应用中也是很靠谱的，如果使用TCP会造成明明是在3S前出现的画面在现在或者以后出现了，会使体验效果变差。在传输数据时使不靠谱的，TFTP是一个停止等待传输协议，服务端发了512K，客户端必须跟服务器确认，确认后，服务端才会继续发送数据，然后又等待客户端的确认，再发送。

 

最大UDP数据包长度：

   理论上说，最大UDP数据包长度应该为：65535-IP数据报首部-UDP头部。也就是IP数据报的数据部分-UDP头部，其实不然。第一，应用程序可能会受到其程序接口的限制。应用程序通过API接口来调用网络，可能API接口最大只支持8192。所以API限制了应用程序不可能一下子发很多。第二，有可能在TCP/IP的内核里面也对UDP最大的数据包进行限制。

 

数据报截断：

  发的时候有限制，在接收的时候也可能收不了这么多，当发过去一个8192字节的数据，对端接收的API最大只支持4096，根据操作系统的不同处理的方法也会不同，有的会只接收前4096个字节，后面的就直接丢弃了。有的会先接收4096个字节，然后等下再接收4096个字节。

TCP就不会发生这种情况，TCP大了就会拆小，小了就会补充大。

最大UDP数据包长度详解：

 https://blog.csdn.net/cathysun118/article/details/2281952（参考）

ICMP的源站抑制：

   源端一直在发送数据，如果中间设备路由器的缓存满了，它就会向源发送一个ICMP源站抑制的差错信息，RFC提出建议：其实路由不应该产生这种差错报文，由于以及拥塞了，路由器还要发送这个差错报文，占用网络资源，可能让网络拥塞更加严重，而且对于UDP而言，可能一口气就把要发的数据报全发出去了，就算中间路由器返回给源端差错报文，要求源端抑制，但是源端已经发送完了，没有可抑制的数据报了。这时候就相当于白白浪费带宽。TCP接收源站抑制差错报文后，会将放慢在该连接上的数据报传输速度。总体上说是不建议发送这个源站抑制差错的。