UDP协议学习(转)

reference: https://blog.csdn.net/s_lisheng/article/details/73538229

https://blog.csdn.net/weixin_39138071/article/details/79630133

UDP协议

UDP（User Datagram Protocol），用户数据报协议，是OSI(Open System Interconnection，开放式系统互联) 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，IETF RFC 768是UDP的正式规范。UDP提供了无连接通信，且不对传送数据包进行可靠性保证，适合于一次传输少量数据，UDP传输的可靠性由应用层负责。常用的UDP端口号有:

应用协议	端口号
DNS	53
TFTP	69
SNMP	161

UDP报文没有可靠性保证、顺序保证和流量控制字段等，可靠性较差。但是正因为UDP协议的控制选项较少，在数据传输过程中延迟小、数据传输效率高，适合对可靠性要求不高的应用程序，或者可以保障可靠性的应用程序，如DNS、TFTP、SNMP等。
UDP在IP报文中的位置如下图所示：

可以看到，UDP其实就是在IP报文中添加了端口信息，使数据到达主机后送达至相应端口的应用程序。下面是通过wireshark抓的一个UDP数据包：

UDP使用

在选择使用协议的时候，选择UDP必须要谨慎。在网络质量令人十分不满意的环境下，UDP协议数据包丢失会比较严重。但是由于UDP的特性:它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。比如我们聊天用的QQ就是使用的UDP协议。

既然UDP是一种不可靠的网络协议，那么还有什么使用价值或必要呢?其实不然，在有些情况下UDP协议可能会变得非常有用。因为UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能，但是在实际执行的过程中会占用大量的系统开销，无疑使速度受到严重的影响。反观UDP由于排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，使速度得到了保证。

UDP报头

UDP报头由4个域组成，其中每个域各占用2个字节，如下图所示：

UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方(可以是客户端或服务器端)将UDP数据包通过源端口发送出去，而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口;而另外一些网络应用则可以使用未被注册的动态端口。*因为UDP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。*一般来说，大于49151的端口号都代表动态端口。
数据报的长度是指包括报头和数据部分在内的总字节数。因为报头的长度是固定的，所以该域主要被用来计算可变长度的数据部分(又称为数据负载)。数据报的最大长度根据操作环境的不同而各异。从理论上说，包含报头在内的数据报的最大长度为65535字节。不过，一些实际应用往往会限制数据报的大小，有时会降低到8192字节。（对于一次发送多少字节比较好，后面会讲到）
UDP协议使用报头中的校验值来保证数据的安全。校验值首先在数据发送方通过特殊的算法计算得出，在传递到接收方之后，还需要再重新计算。如果某个数据报在传输过程中被第三方篡改或者由于线路噪音等原因受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检测是否出错。这与TCP协议是不同的，后者要求必须具有校验值。
许多链路层协议都提供错误检查，包括流行的以太网协议，也许你想知道为什么UDP也要提供检查和校验。其原因是链路层以下的协议在源端和终端之间的某些通道可能不提供错误检测。虽然UDP提供有错误检测，但检测到错误时，UDP不做错误校正，只是简单地把损坏的消息段扔掉，或者给应用程序提供警告信息。

UDP特性

UDP是一个无连接协议，传输数据之前源端和终端不建立连接，当UDP它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制;在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。

由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。

UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。

吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表(这里面有许多参数)。

UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

对UDP一次发送多少bytes好？问题的思考

在进行UDP编程的时候,我们最容易想到的问题就是,一次发送多少bytes好? 当然，这个没有唯一答案。相对于不同的系统，不同的要求，其得到的答案是不一样的。我这里仅对像ICQ一类的发送聊天消息的情况作分析，对于其他情况，或许也能得到一点帮助。

首先，我们知道TCP/IP通常被认为是一个四层协议系统，包括链路层、网络层、传输层、应用层。UDP属于传输层,下面我们由下至上一步一步来看: 以太网(Ethernet)数据帧的长度必须在46-1500字节之间,这是由以太网的物理特性决定的。这个1500字节被称为链路层的MTU(最大传输单元)。但这并不是指链路层的长度被限制在1500字节，其实这个MTU指的是链路层的数据区并不包括链路层的首部和尾部的18个字节。所以事实上这个1500字节就是网络层IP数据报的长度限制。因为IP数据报的首部为20字节，所以IP数据报的数据区长度最大为1480字节。而这个1480字节就是用来放TCP传来的TCP报文段或UDP传来的UDP数据报的。又因为UDP数据报的首部8字节，所以UDP数据报的数据区最大长度为1472字节。这个1472字节就是我们可以使用的字节数。

当我们发送的UDP数据大于1472的时候会怎样呢？这也就是说IP数据报大于1500字节，大于MTU。这个时候发送方IP层就需要分片(fragmentation)。把数据报分成若干片，使每一片都小于MTU。而接收方IP层则需要进行数据报的重组。这样就会多做许多事情，而更严重的是，由于UDP的特性，当某一片数据传送中丢失时，无法重组数据报，将导致丢弃整个UDP数据报。因此，在普通的局域网环境下，建议将UDP的数据控制在1472字节以下为好。

进行Internet编程时则不同,因为Internet上的路由器可能会将MTU设为不同的值. 如果我们假定MTU为1500来发送数据的,而途经的某个网络的MTU值小于1500字节,那么系统将会使用一系列的机制来调整MTU值,使数据报能够顺利到达目的地,这样就会做许多不必要的操作. 鉴于Internet上的标准MTU值为576字节,所以我建议在进行Internet的UDP编程时. 最好将UDP的数据长度控件在548字节(576-8-20)以内.

UDP协议：低开销通信

UDP是一种简单协议，提供了基本的传输层功能。与TCP相比，UDP的开销极低，因为UDP是无连接的，并且不提供复杂的重新传输、排序和流量控制机制。

UDP数据报重组

与TCP的通信机制不同，由于UDP是无连接协议，因此通信发生之前不会建立会话。UDP是基于事务的，换言之，应用程序要发送数据时，它仅是发送数据而已。很多使用UDP的应用程序发送的数据量很小，用一个数据段就够了。但是也有一些应用程序需要发送大量数据，因此需要用多个数据段。UDP PDU(协议数据单元)的实际意义是数据报，尽管数据段和数据报可以互换使用来描述某个传输层PDU。

将多个数据报发送到目的主机时，它们可能使用了不同的路径，到达顺序也可能跟发送时的顺序不同。与TCP不同，UDP不跟踪序列号。UDP不会对数据报重组，因此也不会将数据恢复到传输时的顺序。
因此，UDP仅仅是将接收到的数据按照先来后到的顺序转发到应用程序。如果数据的顺序对应用程序很重要，那么应用程序只能自己标志数据的正确顺序，并决定如何处理这些数据。

UDP服务器进程与请求

与基于TCP的应用程序相同的是，基于UDP的服务器应用程序也被分配了公认端口或已注册的端口。当上述应用程序或进程运行时，它们就会接受与所分配端口相匹配的数据。当UDP收到用于某个端口的数据报时，它就会按照应用程序的端口号将数据发送到相应的应用程序。

UDP客户端进程

对于TCP而言，客户端/服务器模式的通信初始化采用由客户端应用程序向服务器进程请求数据的形式。而UDP客户端进程则是从动态可用端口中随机挑选一个端口号，用来作为会话的源端口。而目的端口通常都是分配到服务器进程的公认端口或已注册的端口。

采用随机的源端口号的另一个优点是提高安全性。如果目的端口的选择方式容易预测，那么网络入侵者很容易就可以通过尝试最可能开放的端口号访问客户端。

由于UDP不建立会话，因此一旦数据和端口号准备就绪，UDP就可以生成数据报并递交给网络层，并在网络上寻址和发送。

需要谨记的是，客户端选定了源端口和目的端口后，通信事务中的所有数据报文头都采用相同的端口对。对于从服务器到达客户端的数据来说，数据报头所含的源端口和目的端口作了互换。

内容补充

TCP在目的主机没有确定可以接收数据时不会向网络发送数据。TCP管理数据流，并会重新发送目的主机没有确认收到的数据。TCP使用握手、计时器和确认机制，以及动态窗口来实现可靠传输。但是，可靠性带来的结果就是增加了网络开销。有两点原因，其一是TCP采用了更大的数据段报头信息；其二是管理源端和目的端之间的数据传输也导致了更大的网络流量。

UDP传输过程中存在的主要问题：
①丢失和乱序：因为UDP不提供ACK、序列号等机制，所以是没有办法知道是否有报文丢失以及接收方到达等报文顺序是否和发送方发送的报文数据一样；
②差错：对于差错问题则是可以通过校验和等检测到，但是不提供差错纠正；
③数据完整性，UDP协议头部虽然有16位的校验和，但是IPv4并不强制执行，也就是说UDP无法抱枕数据的完整性
UDP如何解决其传输过程中的问题：
想要保证数据的可靠投递和正确排序，必须由应用程序自己实现这些保护功能
简单思路，既然原生UDP有那么多痛点，那我能不能像应用层协议一样在UDP数据包头再加一段包头，从而定义为RUDP呢，答案是肯定的。首先思考RUDP需要解决哪些问题，然后根据问题加上必要的包头字段。
1. 数据完整性 –> 加上一个16或者32位的CRC验证字段
2. 乱序 –> 加上一个数据包序列号SEQ
3. 丢包 –> 需要确认和重传机制，就是和Tcp类似的Ack机制（若中间包丢失可以通过序列号累计而检测到，但是一开始的包就丢失是没有办法通过序列号检测到的）
在思考一下既然是自定义协议是不是需要一个协议号字段来过滤一些非法包，那么又可以加入一个新字段：
4. 协议字段 –> protol 字段，标识当前使用协议
综合以上字段，我们的RUDP就可以简单实现成如下：

RUDP（Reliable UDP）：
RUDP，可靠UDP，实现了UDP的一些可靠性
参考链接：http://www.sohu.com/a/208825991_467759