当前位置：首页 > news >正文

传输控制协议（TCP）和用户数据报协议（UDP）

news 2024/11/26 0:03:43

一、传输控制协议（TCP）

传输控制协议（Transmission Control Protocol，TCP）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的 RFC 793 定义。

它通过三次握手建立连接，确保数据的可靠传输，并提供顺序控制、流量控制和拥塞控制等功能‌。

在简化的计算机网络 OSI 模型中，它完成第四层传输层所指定的功能。用户数据报协议（UDP）是同一层内另一个重要的传输协议。
在因特网协议族（Internet protocol suite）中，TCP 层是位于 IP 层之上，应用层之下的中间层。

1.TCP的特点

TCP 是面向连接（虚连接）的传输层协议。
每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的。
TCP 提供可靠交付的服务，无差错、不丢失、不重复、按序到达。
TCP 提供全双工通信。
TCP 面向字节流

2.TCP报文

在这里插入图片描述

源端口（Source Port）：16 bits，通过一个端口号告诉 TCP 报文来自于哪个进程。
目标端口（Destination Port）：16 bits，通过一个端口号告诉 TCP 报文要发给哪个进程。
序号（Sequence Number，seq）：32 bits，在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号，本字段表示本报文段所发送数据的第一个字节的序号。
确认号（Acknowledgment Number，ack）：32 bits，期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N，则证明到序号N-1为止的所有数据都已正确收到。
数据偏移（Data Offset，DOffset） ：4 bits，TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远，以4B位单位，即1个数值是4B。
保留（Reserved ，Rsrvd）：6 bits，须置0。
控制位（Flags）：6 bits，
- 紧急位 URG：URG=1 时，标明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用。
- 复位 RST：RST=1 时，表明 TCP 连接中出现严重差错，必须释放连接，然后再重新建立传输链接。
- 确认位 ACK：ACK=1 时确认号有效，在连接建立后所有传送的报文段都必须把 ACK 置为 1。
- 推送位 PSH：PSH=1 时，接收方尽快交付接收应用进程，不再等到缓存填满再向上交付。
- 同步位 SYN：SYN=1 时，表明是一个连接请求/连接接受报文。
- 终止位 FIN：FIN=1 时，表明此报文段发送方数据已发完，要求释放连接。
窗口（Window，WIN）：16 bits，指的是发送本报文段的一方的接收窗口，即现在允许对方发送的数据量。
检验和（Checksum）：16 bits，检验首部+数据，检验时要加上 12B 伪首部，第四个字段为6。
紧急指针（Options） ：16 bits，URG=1 时才有意义，指出本报文段中紧急数据的字节数。
选项（Options ） ：最多40 bits，最大报文段长度MSS、窗口扩大、时间戳、选择确认…

3.ACK与ack的区别

大写ACK是确认值(Acknowledgement)，为1便是确认连接。
小写ack是确认编号(Acknowledgement Number)，即接收到的上一次远端主机传来的seq然后+1，再发送给远端主机。提示远端主机已经成功接收上一次所有数据。

4.TCP连接过程

TCP 是面向连接的，客户端与服务器要建立连接才能进行通信，通信后需要断开连接。

（1）三次握手建立连接

假设运行在一台主机（客户）上的一个进程想与另一台主机（服务器）上的一个进程建立一条连接，客户应用进程首先通知客户 TCP，他想建立一个与服务器上某个进程之间的连接，客户中的 TCP 会用以下步骤与服务器中的 TCP 建立一条 TCP 连接：

第一次握手：客户端把 SYN 标志位置为1，随机初始化 “序列号” seq=x 的数据包到服务器，并进入 SYN-SENT 状态；服务器由 SYN=1 知道，客户端要求建立联机，此时服务器进入 LISTEN 状态；
第二次握手：服务器收到请求后，随机初始化自己的“序列号” seq=y，“确认应答号” ack=x+1，把 SYN 和 ACK 标志位置为1，把该报文发给客户端，此时服务器进入进入 SYN-RECEIVED 状态。
第三次握手：客户端收到服务端报文后，将 ACK 标志位置为1，“确认应答号” ack=y+1，“序列号” seq=x+1，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端和服务器处于 ESTABLISHED 状态。

在这里插入图片描述

（2）四次挥手关闭连接

参与一条TCP连接的两个进程中的任何一个都能终止该连接，连接结束后，主机中的“资源”（缓存和变量）将被释放。

第一次挥手：客户端发送一个 FIN=1，seq=u 的数据包到服务端，用来关闭客户端到服务器的数据传送。然后客户端进入 FIN-WAIT-1 状态。
第二次挥手：服务器收到这个数据包，它发送一个 ACK标志为1，ack=u+1，seq=v 的数据包到客户端。然后服务端进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。
第三次挥手：服务端发送一个 FIN=1，ACK=1，seq=w，ack=u+1 的数据包到客户端，请求关闭连接，然后服务端进入 LAST-ACK 状态。
第四次挥手：客户端发送 ACK=1，ack=w+1 的数据包到服务端，然后客户端进入TIME-WAIT 状态，服务端在收到数据包后进入 CLOSE 状态。

此时如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后客户端也可以关闭连接了。

在这里插入图片描述

5.滑动窗口

在TCP通信中，每次发送数据都需要等待一次确认应答，如果在等待前一个数据包的确认时才发送下一个数据包，通信效率会变得很低。

为解决这个问题，TCP 引入了滑动窗口这个概念。它允许发送方在不接收确认应答的情况下持续发送数据，并根据接收方的反馈及时调整数据发送速率。即使在往返时间较长的情况下，它也不会降低网络通信的效率。

TCP 报文里有一个字段叫窗口（Window，WIN），记录着窗口大小的信息窗口大小。
这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收
端的处理能力来发送数据，而不会导致接收端处理不过来。

发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。所以，通常窗口的大小是由接收方的窗口大小来决定的。

滑动窗口基本概念

SND.WND：发送窗口。
SND.UNA：Send Unacknowledged 指针，指向发送窗口的第一个字节。
SND.NXT：Send Next 指针，指向可用窗口的第一个字节。
可用窗口大小 = SND.UNA + SND.WND - SND.NXT 。

（1）发送窗口的工作原理

发送窗口的工作空间，根据处理的情况分成四个部分：
已发送并收到 ACK确认的数据、已发送但未收到 ACK确认的数据、未发送但总大小在接收方处理范围内（接收方还有空间）、未发送但总大小超过接收方处理范围（接收方没有空间）

其中已发送但未收到 ACK确认的数据的部分方框是发送窗口，未发送但总大小在接收方处理范围内（接收方还有空间）的部分是可用窗口。

下面是发送窗口工作原理的示意图，在下图中，蓝色部分为已发送并收到 ACK确认的数据的子节，绿色部分为已发送但未收到 ACK确认的数据，黄色部分为未发送但总大小在接收方处理范围内的数据，白色部分为未发送但总大小超过接收方处理范围。

下图以滑动窗口大小为 8 为例子：

（a）:
在这里插入图片描述
已发送并收到 ACK确认的数据：11 ~ 13字节，共3个字节；
已发送但未收到 ACK确认的数据：0个字节；
未发送但总大小在接收方处理范围内（接收方还有空间）的数据：14 ~ 21字节，共8个字节；
未发送但总大小超过接收方处理范围（接收方没有空间）的数据：22字节以后。

（b）:
在这里插入图片描述
已发送并收到 ACK确认的数据：11 ~ 13字节，共3个字节；
已发送但未收到 ACK确认的数据：14 ~ 16字节，共3个字节；
未发送但总大小在接收方处理范围内（接收方还有空间）的数据：17 ~ 21字节，共5个字节；
未发送但总大小超过接收方处理范围（接收方没有空间）的数据：22字节以后。

（c）:
在这里插入图片描述
已发送并收到 ACK确认的数据：11 ~ 15字节，共5个字节；
已发送但未收到 ACK确认的数据：26 ~ 23字节，共8个字节；
未发送但总大小在接收方处理范围内（接收方还有空间）的数据：0个字节；
未发送但总大小超过接收方处理范围（接收方没有空间）的数据：28字节以后。

（d）:

在这里插入图片描述
已发送并收到 ACK确认的数据：11 ~ 19字节，共9个字节；
已发送但未收到 ACK确认的数据：20 ~ 23字节，共4个字节；
未发送但总大小在接收方处理范围内（接收方还有空间）的数据：24 ~ 27字节，共4个字节；
未发送但总大小超过接收方处理范围（接收方没有空间）的数据：28字节以后。

（2）接收窗口的工作原理

接收窗口根据处理的情况划分成三个部分：已成功接收并确认的数据（等待应用进程读取）、未收到数据但可以接收的数据、未收到数据并不可以接收的数据；

上面发送窗口的图d情况中，接收窗口的示意图如下：
在这里插入图片描述
已成功接收并确认等待应用进程读取）数据：11 ~ 19字节，共9个字节；
未收到数据但可以接收的数据：20 ~ 27字节，共8个字节；
未收到数据并不可以接收的数据：28字节以后。

二、TCP 保证可靠性机制

可靠：保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。

前文提到 TCP 是可靠的，那么 TCP 靠着哪些机制保证了可靠性呢？

TCP 主要通过连接管理、序列号、确认应答、重传机制、流量控制、拥塞控制四个机制来保证可靠性的。

1.序列号与确认应答机制

在TCP中，通过序列号与确认应答来实现数据的可靠传输。

TCP将每个字节的数据都进行了编号，这就是序列号，序列号能够保证可靠性和有序性。

接收方接收数据之后，会回传ACK报文，报文中带有此次确认的序列号，用于告知发送方此次接收数据的情况这就是确认应答。

序列号与确认应答机制就是，在发送端将数据传输到接收主机时，接收主机会根据收到消息的序列号，发送一个确认应答消息以表示已成功接收到数据。
在这里插入图片描述

2. 重传机制

在错综复杂的网络，数据在传输过程中是有可能丢失的，所以 TCP 针对数据包丢失的情况，会用重传机制解决。

（1）超时重传

发送方在发送数据时，设定一个定时器，使用一个保守估计的时间作为收到 ACK 确认应答报文的超时上限。如果超过这个上限仍未收到对方的 ACK 确认应答报文，发送方将重传这个数据包。每当发送方收到确认包后，会重置这个重传定时器。
在这里插入图片描述
TCP 会在以下两种情况发生超时重传：数据包丢失、确认应答丢失。

超时重传时间怎么确定

RTT（Round Trip Time）：往返时间，指的是数据发送时刻到接收到确认的时刻的差值，也就是包的往返时间。
RTO（Retransmission Time Out）：重传超时时间，即从数据发送时刻算起，超过这个时间便执行重传。

RTO 的确定是一个关键问题，因为它直接影响到 TCP 的性能和效率。当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差；当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。
因此，RTO 应该根据网络的实际状况，动态地进行调整。

TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT 。TCP保留了 RTT 的一个加权平均往返时间 RTT_S（这又称为平滑的往返时间，S表示 Smoothed。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到 RTT 样本时，RTT值就取为所测量到的 RTT 样本值。但以后每测量到一个新的 RTT样本，就按下式重新计算一次 RTT_S:
（1）首次计算RTO时：

$RTT_S=R1$

$RTT_{dev}=R1/2$

$\times RTT_S+∂ \times RTT_{dev}=μ \times R1+∂ \times R1/2$

其中：R1 是第一次测量的 RTT

（2）迭代计算RTO时：

$RTT_S=RTT_S+ α \times(RTT-RTT_S)=RTT_S+ α \times(R2 - R1)$

$RTT_{dev}=(1-β) \times RTT_{dev}+β \times (RTT-RTT_S)$

$\times RTT_S+∂ \times RTT_{dev}$

其中：R2 是新测量的 RTT
RTT_S 是计算平滑的 RTT ，RTT_dev 是计算平滑的 RTT 与最新 RTT 的差距。
在 Linux 下， $α = 0.125$ ， $β = 0.25$ ， $μ = 1$ ， $\partial = 4$ 。是大量实验中调出来的。

（2）快速重传（Fast Retransmit）

TCP 还有另外⼀种快速重传（Fast Retransmit）机制，它基于接收端的反馈信息来引发重传，而非重传计时器超时。

换言之，当数据包未连续到达时，接收方会针对可能丢失的最后一个包发送 ack 确认。若发送方连续3次接收到相同的ack，便会触发重传机制。快速重传的优势在于，它无需等待超时即可进行重传，从而提高了数据传输的效率。

在这里插入图片描述

如上图的例子，发送方发出了 1，2，3，4，5 份数据：

当发送方依次发送了seq序号为1、2、3、4、5的数据包后，接收方首先成功接收了seq1并返回了确认（ack=2）请求下一个包（即seq2）。然而，由于某些原因，seq2未能到达接收方。随后，seq3、seq4、seq5号包均成功送达，但接收方依然只能回复ack=2，因为它仍然期待seq2的到达。发送方在连续三次收到ack=2的反馈后，识别出2号包可能丢失，于是立即重传2号包。在接收方最终收到seq2后，鉴于seq3、seq4、seq5号包均已成功接收，它随即发送ack=6，请求下一个期望的包（若存在）。

快速重传机制解决了超时时间的问题，但是它依然面临着另外一个问题。就是重传的时候，是重传一个，还是重传所有的问题。

（3）选择确认重传（Selective Acknowledgment，SACK）

改进的方法就是选择确认重传（Selective Acknowledgment，SACK）。

在TCP头部的选项（Options） 字段中，添加了选择性确认(SACK)选项。通过SACK，接收方可以返回最近收到的报文段的序列号范围，使发送方能够准确知道哪些数据包已经成功接收，哪些数据包尚未到达。

有了这些信息，发送端只需重传丢失的数据包，而不是整个数据流，从而提高了重传的精确性和效率。
在这里插入图片描述
如上图的例子：
现在先后发送了5个数据包的数据，如果此时发送第2个数据包时数据丢失，而其余4个数据包都收到了接收方的确认信息，那么此时根据SACK可以判断出只有第二个数据包丢失，而第1个、第3个、第4个、第5个数据包已被接收，此时可以只重新发送第2个数据包。

（4）DSACK

DSACK，即重复 SACK（Duplicate Selective Acknowledgment），这个机制是在 SACK 的基础上，额外携带信息，告知发送方有哪些数据包自己重复接收了。DSACK 的目的是帮助发送方判断，是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。

3. 流量控制

为避免触发重发机制和避免网络流量浪费，发送方需要考虑接收方的处理能力。如果发送方持续发送数据给接收方而后者无法及时处理，将导致重发机制触发，进而浪费网络资源。为此，TCP引入了流量控制机制。

通过流量控制，发送方可以根据接收方当前的接收能力来动态调整发送的数据量，避免过载接收方而导致数据丢失或延迟，从而优化整个网络通信的效率和可靠性。

一句话总结一下，流量控制就是：让发送方慢点，要让接收方来得及接收。

（1）流量控制

TCP利用 滑动窗口 机制实现流量控制。

在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，即接收窗口rwnd（接收方设置确认报文段的窗口字段来将rwnd通知给发送方），发送方的发送窗口取接收窗口 rwnd 和拥塞窗口cwnd 的最小值。

例子如下：

A向B发送数据，连接建立时，B告诉A：“我的rwnd=400（字节）”，设每一个报文段100B，报文段序号初始值为1
在这里插入图片描述

（2）窗口关闭

TCP 通过让接收方指明滑动窗口的大小来进行流量控制。如果窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。

当窗口关闭时，接收方在处理完数据后会发送一个非0窗口大小的ACK报文通知发送方。然而，如果这个通告窗口的ACK报文在网络中丢失，可能会导致问题。发送方会继续等待ACK确认，无法发送新的数据。如不采取措施，这种相互等待的过程，会造成了死锁的现象。

为了解决上述的死锁问题，TCP为每一个连接设有一个持续计时器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。
若持续计时器设置的时间到期，就发送一个**零窗口探测 ( Window probe )**报文段。接收方收到探测报文段时给出现在的窗口值。

若窗口仍然是0，那么发送方就重新设置持续计时器；如果不是0，则发送方可以根据窗口的大小继续发送数据，死锁的局面就被打破了。

这样通过定时地进行探测，就可以避免死锁的产生。

4. 拥塞控制

在网络拥堵时，若持续发送大量数据包，可能导致数据包时延和丢失。TCP会进行重传，然而重传会增加网络负担，导致更大的延迟和丢包。这会形成恶性循环，不断放大问题。

为了解决此问题，就有了拥塞控制的概念，拥塞控制是指防止过多的数据注入网络，保证网络中的路由器或链路不致过载。

拥塞控制是通过拥塞拥塞窗口实现的。

拥塞窗口（cwnd）是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。只要网络中没有出现拥塞，cwnd 就会增大；但网络中出现了拥塞，cwnd 就减少。

常见的拥塞控制算法有慢启动、拥塞避免、快速恢复。

（1）慢启动（Slow Start）

在 TCP 刚刚连接好并开始发送TCP报文段时，先令拥塞窗口 cwnd=1，即一个最大报文段长度 MSS。每收到一个对新报文段的确认后，将 cwnd 加1，即增大一个 MSS。用这样的方法逐步增大发送方的拥塞窗口 cwnd，可使分组注入网络的速率更加合理。

例如：
A 向 B发送数据，发送时 A的拥塞窗口为 1，那么A一次可以发送1个 TCP 报文段，经过一个RTT后(也称一个传输轮次)，A收到B对刚才1个报文的确认，于是把拥塞窗口调整为 2，下一次发送时就可一次发送2个报文段。
第二轮数据发送时，发送时 A的拥塞窗口为 2，那么A一次可以发送2个 TCP 报文段，经过一个RTT后(也称一个传输轮次)，A收到B对刚才2个报文的确认，于是把拥塞窗口调整为 4，下一次发送时就可一次发送4个报文段。
在这里插入图片描述

（2）拥塞避免（Congestion Avoidance）

慢启动算法，发包的个数是指数性的增长，这样拥塞窗口的增长速度会过快，所以需要拥塞避免算法来降低拥塞窗口的增长速度。

拥塞避免算法的做法如下：

发送端的拥塞窗口 cwnd（Congestion Window）每经过一个往返时延 RTT就增加1个 MSS的大小，而不是加倍，使cwnd 按线性规律缓慢增长(即加法增大)。

可以通过 慢启动门限 ssthresh（slow start threshold）状态变量，来决定慢启动算法和拥塞避免算法的使用。

当 cwnd<ssthresh 时，使用慢开始算法。
当 cwnd>ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当cwnd= ssthresh 时，既可使用慢开始算法，又可使用拥塞避免算法(通常做法)。

在这里插入图片描述

（3）拥塞发生的处理

网络出现拥塞时，无论是在慢开始阶段还是在拥塞避免阶段，只要发送方检测到超时事件的发生（未按时收到确认，重传计时器超时），就要采取激烈的应对措施。具体反应如下：

将慢启动阈值（sshthresh）设置为当前拥塞窗口（cwnd）的一半，即 sshthresh = cwnd /2。
将拥塞窗口（cwnd）重置为1，即 cwnd=1。
随后进入慢启动过程，以逐步恢复数据传输速率。
这样做的目的是迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完。

拥塞避免并不能完全能避免拥塞。利用以上措施要完全避免网络拥塞是不可能的。拥塞避免是指在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

在这里插入图片描述

（4）快速重传（Fast Retransmit）与快速恢复（Fast Recovery）

当拥塞发生时，如果将拥塞窗口直接设置为1，并重新开始慢启动，是会突然减少数据流的。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。所以提出了快速重传算法。

快速重传

如上文的重传机制，当丢包的时候，会有两种情况：超时重传和快速重传。

在拥塞发生时，使用“快速重传算法”进行重传更符合需求。当接收端检测到有中间数据包丢失时，会连续三次发送对前一个数据包的确认（ack），从而促使发送端迅速进行重传，无需等待超时。TCP协议认为这种情况下的网络拥塞并不严重，因为仅丢失了少量数据包。

在发生此类拥塞时的快速重传流程如下：

将拥塞窗口（cwnd）减半，即cwnd = cwnd/2。
将慢启动阈值（ssthresh）设置为当前的拥塞窗口值，即ssthresh = cwnd。
随后进入快速恢复算法阶段。

快速恢复：

RFC5681文档中描述了快速恢复算法。快速重传与快速恢复算法常被并行运用。快速恢复算法的基本思想是，当收到三个重复的ack确认时，意味着网络状况尚可并未严重恶化，因此无需采取像RTO超时那样的严厉措施来应对。

进入快速恢复之前，cwnd 和 sshthresh在快速重传算法执行之前已被进行如下更新：

cwnd = cwnd /2
sshthresh = cwnd

快速恢复过程概述如下：

将拥塞窗口（cwnd）设置为慢启动阈值（sshthresh）加3，并确认已收到3个数据包，即cwnd = sshthresh + 3 ；
重传之前丢失的数据包；
当收到针对重传数据包的确认（ack）时，那么拥塞窗口增加1，即（cwnd = cwnd +1）；
若收到确认新数据的确认（ack），，表明所有重传的数据包均已被成功接收，此时将拥塞窗口（cwnd）重新设置为慢启动阈值（sshthresh），即cwnd = sshthresh，并结束快速恢复过程，随后进入拥塞避免阶段。

在这里插入图片描述

三、用户数据报协议（UDP）

用户数据报协议（User Datagram Protocol，UDP）又称用户数据包协议，是一个简单的是一种无连接的、不保证可靠的、面向数据包的传输层通信协议，位于OSI模型的传输层。

该协议由 David P. Reed 在1980年设计且在RFC 768中被规范。典型网络上的众多使用 UDP 协议的关键应用在一定程度上是相似的。

在 TCP/IP 模型中，UDP 为网络层以上和应用层以下提供了一个简单的接口。UDP 只提供数据的不可靠传递，它一旦把应用程序发给网络层的数据发送出去，就不保留数据备份（所以 UDP 有时候也被认为是不可靠的数据包协议）。UDP 在 IP 数据包的头部仅仅加入了复用和数据校验字段。

1. UDP 的特点

UDP是无连接的，减少开销和发送数据之前的时延。
UDP使用最大努力交付，即不保证可靠交付 。
UDP是面向报文的，适合一次性传输少量数据的网络应用。
UDP无拥塞控制，适合很多实时应用。
UDP首部开销小，8B，TCP20B。

2. UDP 报文

在这里插入图片描述

源端口（Source Port）：16 bits，通过一个端口号告诉 TCP报文来自于哪个进程。
目标端口（Destination Port）：16 bits，通过一个端口号告诉 TCP报文要发给哪个进程。
包长度（Length）：16 bits，该字段保存了 UDP 首部的长度跟数据的长度之和。
校验和（Checksum）：16 bits，校验和是为了提供可靠的 UDP 首部和数据而设计，防止收到在网络传输中受损的 UDP 包。

四、TCP 与 UDP 区别

1.TCP 与 UDP 区别

面向连接：TCP 是面向连接的传输层协议，传输数据前先要建立连接。UDP 是不需要连接，即刻传输数据；
服务对象：TCP 是一对一的两点服务，即一条连接只有两个端点。UDP 支持一对一、一对多、多对多的交互通信；
可靠传输：TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按序到达。UDP 是尽最大努力交付，不保证可靠交付数据，但是我们可以基于 UDP 传输协议实现一个可靠的传输协议，QUIC 协议；
拥塞控制、流量控制：TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率；
传输效率：由于使用 TCP 进行传输的时候多了连接、确认、重传等机制，所以 TCP 的传输效率要比 UDP 低很多；
首部开销：TCP首部开销20字节。UDP首部开销8字节；
传输方式：TCP 是流式传输，没有边界，但保证顺序和可靠。UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。