传输层
1、TCP首部格式？
源端口: 占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。
目的端口： 占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。
序号: 占32比特，取值范围[0,2^32-1]，序号增加到最后一个后，下一个序号就又回到0。指出本TCP报文段数据载荷的第一个字节的序号。
确认号： 占32比特，取值范围[0,2^32-1]，确认号增加到最后一个后，下一个确认号就又回到0。指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。
确认标志位ACK： 取值为1时确认号字段才有效；取值为0时确认号字段无效。TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。
校验和： 占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。
紧急指针： 占16比特，以字节为单位，用来指明紧急数据的长度。
填充： 由于选项的长度可变，因此使用填充来确保报文段首部能被4整除(因为数据偏移字段，也就是首部长度字段，是以4字节为单位的)。
2、TCP 和 UDP 的区别
表格总结：
类型 |
是否面向连接 |
传输可靠性 |
传输形式 |
传输效率 |
所需资源 |
应用场景 |
首部字节 |
TCP |
是 |
可靠 |
字节流 |
慢 |
多 |
文件传输、邮件传输 |
20~60 |
UDP |
否 |
不可靠 |
数据报文段 |
快 |
少 |
即时通讯、域名转换 |
8个字节 |
图文总结：
3、UDP 和 TCP 对应的应用场景是什么？
TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：
- FTP文件传输
- HTTP / HTTPS
- 邮件传输
UDP 面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：
- DNS域名转换
- 视频、音频等多媒体通信
- 广播通信
音视频传输通常使用UDP协议，原因如下：
- 实时性要求：音视频通信对实时性要求较高，UDP比TCP的延迟更小，可以更快地接收和传输数据，从而满足实时性的需求。
- 丢包容错性：音视频通信中丢失一个数据包对整个通信不会造成影响，因此UDP比TCP更适合音视频通信。
- 带宽效率：UDP在传输音视频数据时，不需要与接收方确认每个数据包是否到达，从而提高了带宽效率。
- 简化协议：UDP协议简单，没有TCP的三次握手和确认等过程，因此在音视频通信中使用UDP可以减少开销。
4、TCP拥塞控制如何实现？
拥塞控制
- 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞(congestion)。
- 在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等，都是网络的资源。
- 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
TCP一共使用了四种算法来实现拥塞控制：
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。
- TCP发送方一开始使用慢开始算法，让拥塞窗口值从1开始按指数规律增大。
- 当拥塞窗口值增大到慢开始门限值时，停止使用慢开始算法转而执行拥塞避免算法，让拥塞窗口值按线性加1的规律增大。
- 当发生超时重传时，就要判断网络很可能出现了拥塞，采取相应的措施，一方面将慢开始门限值更新为发生拥塞时拥塞窗口值的一半。另一方面，将拥塞窗口值减小为1，并重新开始执行慢开始算法。
- 拥塞窗口值又从1开始按指数规律增大，当增大到了新的慢开始门限值时，停止使用慢开始算法转而执行拥塞避免算法，让拥塞窗口值按线性加1的规律增大。
- 发送方一旦收到3个重复确认(快重传)，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法。发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半，开始执行拥塞避免算法。
5、快重传和快恢复？
1990年又增加了两个新的拥塞控制算法(改进TCP的性能)，这就是快重传和快恢复（TCP Reno版本)。
快重传
有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞：
- 这将导致发送方超时重传，并误认为网络发生了拥塞;
- 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。
采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失，所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
- 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认;
- 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认；
- 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
快恢复
发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法;
- 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法。
- 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh + 3。
6、TCP 的流量控制？
- 一般来说，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
- 所谓流量控制（flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。
- 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
- TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小；
- TCP发送方收到接收方的零窗口通知后，停止发送报文，并启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。
7、TCP滑动窗口实现？
- 发送方和接收方各有一个窗口，接收方通过 TCP 确认报文段 中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。
- 发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；
- 接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。
- 接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。
8、什么是TCP粘包？怎么解决这个问题
什么是TCP粘包问题？
TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。
为什么会发生TCP粘包？
- 发送方要发送的数据小于TCP发送缓冲区大小，TCP 将多次写入缓冲区的数据一次发送出去，这将会发生粘包。
- 发送方发送的数据太快，接收方处理数据的速度赶不上发送端的速度，将发生粘包。
常见解决方法：
- 在消息的头部添加消息长度字段，服务端获取消息头的时候解析消息长度，然后向后读取相应长度的内容。
- 固定消息数据的长度，服务端每次读取既定长度的内容作为一条完整消息，当消息不够长时，空位补上固定字符。但是该方法会浪费网络资源。
- 设置消息边界，也可以理解为分隔符，服务端从数据流中按消息边界分离出消息内容，一般使用换行符。
什么时候需要处理粘包问题？
当接收端同时收到多个分组，并且这些分组之间毫无关系时，需要处理粘包；而当多个分组属于同一数
据的不同部分时，并不需要处理粘包问题。
9、TCP三次握手 ⚡
三次握手是 TCP 连接的建立过程。在握手之前，主动打开连接的客户端结束 CLOSE（关闭） 阶段，被动打开的服务器也结束 CLOSE（关闭） 阶段，并进入 LISTEN（监听） 阶段。随后进入三次握手阶段：
- 首先客户端向服务器发送TCP连接请求报文段，并等待服务器确认，其中：
- 同步位SYN被设置为1, 表明这是一个TCP连接请求报文段。
- 序号字段seq被设置了一个初始值x作为TCP客户进程所选择的初始序号。（x 一般取随机数）；
- 随后客户端进入 SYN-SENT 阶段。
- 服务器接收到客户端发来的 TCP连接请求报文段后，进行确认后结束 LISTEN 阶段，并返回TCP连接请求确认报文段，其中：
- 该报文段首部中的同步位SYN和确认位ACK 都设置为1，表明这是一个TCP连接请求确认报文段；
- 序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号；
- 确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号seq的确认，随后服务器端进入 SYN-RCVD 阶段。
- 客户端接收到发送的 TCP连接请求确认报文段后，明确了从客户端到服务器的数据传输是正常的，最后还要向TCP服务器进程发送一个普通的TCP 确认报文段，其中：
- 该报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段 。
- 序号字段seq 被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，并且不携带数据，因此第二个报文段的序号为x +1。
- 确认号字段ack被设置为y + 1，这是对TCP服务器进程所选择的初始序号的确认。
- 随后客户端进入 ESTABLISHED。
- 当服务器端收到来自客户端确认收到服务器数据的报文后，得知从服务器到客户端的数据传输是正常的，从而结束 SYN-RCVD 阶段，进入 ESTABLISHED 阶段，从而完成三次握手。
10、为什么需要三次握手，而不是两次？
主要有三个原因：
- 防止已失效的连接请求报文段突然又传送到了TCP服务器进程因而导致错误和资源浪费。
- 假设采用两报文握手，TCP客户进程发出一个TCP连接请求报文段，但是该报文段由于网络原因滞留了，这必然会造成该报文段的超时重传。
- 假设重传的报文段被TCP服务器进程正常接收，TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文段，并进入连接已建立状态。他们可以相互传输数据，之后可以通过四报文挥手来释放连接，TCP双方都进入了关闭状态。
- 一段时间后，失效的TCP连接请求报文段到达了TCP服务器进程，TCP服务器进程随即给TCP客户进程发送TCP连接请求确认报文段并进入连接已建立状态。
- 但由于TCP客户进程并没有发起新的TCP连接请求，并且处于关闭状态，因此不会理会该报文段。而TCP服务器进程一直等待TCP客户进程发来数据，这将白白浪费TCP服务器进程所在主机的很多资源。
- 三次握手才能让双方均确认自己和对方的发送和接收能力都正常。
- 第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；
- 第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；
- 第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；
- 可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。
- 告知对方自己的初始序号值，并确认收到对方的初始序号值。
- TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。
- 这两个字段的值会在初始序号值的基础上递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。
11、为什么要三次握手，而不是四次？
因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值的确认，也就无需再第四次握手了。
- 第一次握手：服务端确认“自己收、客户端发”报文功能正常。
- 第二次握手：客户端确认“自己发、自己收、服务端收、客户端发”报文功能正常，客户端认为连接已建立。
- 第三次握手：服务端确认“自己发、客户端收”报文功能正常，此时双方均建立连接，可以正常通信。
12、半连接队列和 SYN Flood 攻击的关系？
半连接队列：
- TCP 进入三次握手前，服务端会从 CLOSED 状态变为 LISTEN 状态, 同时在内部创建了两个队列：半连接队列（SYN 队列）和全连接队列（ACCEPT 队列）。
- 半连接队列存放的是三次握手未完成的连接，全连接队列存放的是完成三次握手的连接。
- TCP 三次握手时，客户端发送 SYN 到服务端，服务端收到之后，便回复 ACK 和 SYN，状态由 LISTEN 变为 SYN_RCVD，此时这个连接就被推入了 SYN 队列，即半连接队列。
- 当客户端回复 ACK, 服务端接收后，三次握手就完成了。这时连接会等待被具体的应用取走，在被取走之前，它被推入 ACCEPT 队列，即全连接队列。
SYN Flood
SYN Flood 是一种典型的 DDos 攻击，它在短时间内，伪造不存在的 IP 地址, 向服务器发送大量SYN 报文。当服务器回复 SYN+ACK 报文后，不会收到 ACK 回应报文，那么SYN队列里的连接就不会出队，久而久之就会占满服务端的 SYN 接收队列（半连接队列），使得服务器不能为正常用户服务。
如何解决？
- syn cookie：在收到 SYN 包后，服务器根据一定的方法，以数据包的源地址、端口等信息为参数计算出一个 cookie 值作为自己的 SYNACK 包的序列号，回复 SYN+ACK 后，服务器并不立即分配资源进行处理，等收到发送方的 ACK 包后，重新根据数据包的源地址、端口计算该包中的确认序列号是否正确，如果正确则建立连接，否则丢弃该包。
- SYN Proxy 防火墙：服务器防火墙会对收到的每一个 SYN 报文进行代理和回应，并保持半连接。等发送方将 ACK 包返回后，再重新构造 SYN 包发到服务器，建立真正的 TCP 连接。
13、TCP四次挥手
四次挥手即 TCP 连接的释放，这里假设客户端主动释放连接。在挥手之前主动释放连接的客户端结束ESTABLISHED 阶段，随后开始四次挥手：
1、首先客户端向服务器发送一段 TCP 报文表明其想要释放 TCP 连接，其中：
- 终止位FIN和确认为ACK的值都被设置为1，表示请求释放连接；
- 序号为 Seq = u；
- 确认号ack = v；
- 随后客户端进入 FIN-WAIT-1 阶段，即半关闭阶段，并且停止向服务端发送通信数据。
2、服务器接收到客户端请求断开连接的 FIN 报文后，结束 ESTABLISHED 阶段，进入 CLOSE-WAIT 阶段并返回一段 TCP 报文，其中：
- 标记位为 ACK = 1，表示接收到客户端释放连接的请求；
- 序号为 Seq = v；
- 确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。
- 随后服务器开始准备释放服务器端到客户端方向上的连接。
客户端收到服务器发送过来的 TCP 报文后，确认服务器已经收到了客户端连接释放的请求，随后客户端结束 FIN-WAIT-1 阶段，进入 FIN-WAIT-2 阶段。
3、服务器端在发出 ACK 确认报文后，服务器端会将遗留的待传数据传送给客户端，待传输完成后即经过 CLOSE-WAIT 阶段，便做好了释放服务器端到客户端的连接准备，再次向客户端发出一段 TCP 报文， 其中：
- 标记位为 FIN = 1 和 ACK = 1，表示已经准备好释放连接了；
- 序号为 Seq = w；
- 确认号 ack = u + 1，这是对之前收到的TCP连接释放报文段的重复确认。
随后服务器端结束 CLOSE-WAIT 阶段，进入 LAST-ACK 阶段。并且停止向客户端发送数据。
4、客户端收到从服务器发来的 TCP 报文，确认了服务器已经做好释放连接的准备，于是结束 FIN-WAIT-2 阶段，进入 TIME-WAIT 阶段，并向服务器发送一段报文，其中：
- 标记位为 ACK = 1，表示接收到服务器准备好释放连接的信号；
- 序号为 Seq= u + 1，表示是在已收到服务器报文的基础上，将其确认号 ack 值作为本段序号的值；
- 确认号为 ack= w + 1，这是对所收到的TCP连接释放报文段的确认。
随后客户端开始在 TIME-WAIT 阶段等待 2 MSL。服务器端收到从客户端发出的 TCP 报文之后结束LAST-ACK 阶段，进入 CLOSED 阶段。由此正式确认关闭服务器端到客户端方向上的连接。客户端等待完 2 MSL 之后，结束 TIME-WAIT 阶段，进入 CLOSED 阶段，由此完成「四次挥手」。
14、为什么连接的时候是三次握手，关闭的时候却是四次挥手？
- 服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段。
- 接下来可能会继续发送数据，在数据发送完后，服务器会向客户端发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。
15、为什么客户端的 TIME-WAIT 状态必须等待 2MSL ？
什么是2MSL：
- MSL指一段 TCP 报文在传输过程中的最大生命周期。2 MSL 即服务器端发出 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。
为什么需要等待：
- 当客户端发出最后的 ACK 确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完 ACK 确认报文之后，会设置一个时长为 2 MSL 的计时器。
- 若服务器在 1 MSL 内没有收到客户端发出的 ACK 确认报文，再次向客户端发出 FIN 报文。如果客户端在 2 MSL 内收到了服务器再次发来的 FIN 报文，说明服务器由于一些原因并没有收到客户端发出的 ACK 确认报文。客户端将再次向服务器发出 ACK 确认报文，并重新开始 2 MSL 的计时。
- 若客户端在 2MSL 内没有再次收到服务器发送的 FIN 报文，则说明服务器正常接收到客户端 ACK 确认报文，客户端可以进入 CLOSE 阶段，即完成四次挥手。
总结：
- 客户端要经历 2 MSL 时长的 TIME-WAIT 阶段，为的是确认服务器能否接收到客户端发出的 ACK 确认报文。
- 另外，TCP客户进程在发送完最后一个TCP确认报文段后，在经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中，不会出现旧连接中的报文段。
16、保活计时器有什么用？
场景：
- 客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
作用：
- 服务器每收到一次客户端的数据，就重新设置保活计时器，时间的设置通常是两个小时。
- 若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若连续发送 10 个探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。
17、CLOSE-WAIT 和 TIME-WAIT 的状态和意义？
CLOSE-WAIT意义
- 服务端收到客户端关闭连接的请求并确认之后，就会进入CLOSE-WAIT状态。此时服务端可能还有一些数据没有传输完成，因此不能立即关闭连接，而CLOSE-WAIT状态就是为了保证服务端在关闭连接之前将待发送的数据处理完。
TIME-WAIT意义
- TIME-WAIT状态发生在第四次挥手，当客户端向服务端发送ACK确认报文后进入TIME-WAIT状态。
- 它存在的意义主要是两个：
- 防止旧连接的数据包（经过2MSL时长，可以使本次连接持续时间内所产生的所有报文段都从网络中消失）：
- 保证连接正确关闭；
18、TIME-WAIT产生太多原因及解决方法？
产生原因：
- 网络拥塞：当网络中出现拥塞，网络延迟变长，连接关闭时间延长，从而增加了TIME-WAIT状态数量。
- 过长的TIME-WAIT超时时间：默认情况下，TIME-WAIT状态的超时时间为4分钟，如果超时时间过长，则可能产生大量的TIME-WAIT状态。
- 高并发的连接：对于高并发的应用，例如Web服务器，大量的连接和断开连接可能导致大量的TIME-WAIT状态。
如何解决：
- 优化服务器系统的网络配置，连接配置，使用socket重用或及时释放资源。
- 采用长连接的方式减少 TCP 的连接与断开，在长连接的业务中往往不需要考虑 TIME-WAIT 状
态，但其实在长连接的业务中并发量一般不会太高。
- 调整TIME-WAIT超时时间：使用sysctl命令或操作系统的其他方法，可以减少TIME-WAIT状态的超时时间。
19、CLOSE-WAIT产生太多原因及解决方法？
产生原因：
- 网络拥塞：当网络中出现拥塞，网络延迟变长，连接关闭时间延长，从而增加了CLOSE-WAIT状态数量。
- 应用程序编程错误：如果应用程序没有正确关闭连接，可能导致大量的CLOSE-WAIT状态。
- 高并发的连接：对于高并发的应用，例如Web服务器，大量的连接和断开连接可能导致大量的CLOSE-WAIT状态。
解决方法：
- 首先检查是不是自己的代码问题（看是否服务端程序忘记关闭连接），如果是，则修改代码。
- 调整系统参数，包括句柄相关参数和 TCP/IP 的参数，一般一个 CLOSE_WAIT 会维持至少 2 个小时 ( KeepLive在Windows操作系统下默认是7200秒 ) 的时间，我们可以通过调整参数来缩短这个时间。
20、TCP协议如何保证可靠性？ ⚡
TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和 流量控制等方法实现了可靠性传输。
- 检验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
- 序列号/确认应答：
序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。
TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。 - 滑动窗口：滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
- 超时重传：超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。
- 拥塞控制：在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。
- 流量控制：如果主机A 一直向主机B发送数据，不考虑主机B的接受能力，则可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。
21、UDP协议为什么不可靠？
UDP在传输数据之前不需要先建立连接，远地主机的传输层在接收到UDP报文后，不需要确认，提供不可靠交付。总结就以下四点：
- 不保证消息交付：不确认，不重传，无超时
- 不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞
- 不跟踪连接状态：不必建立连接或重启状态机
- 不进行拥塞控制：不内置客户端或网络反馈机制
