【传输层协议】UDP/TCP结构特点与原理（详解）

1. UDP

1.1 UDP结构

• 2字节的长度表示整个数据报的最大长度（UDP首部＋UDP数据）。
• 校验和用来验证数据是否出错，出错就摒弃。
• 首部8个字节。
• 源/目的端口号：表示数据是从哪个进程来，到哪个进程去；
• 校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。

1.2 UDP特点

1. 无连接

知道对方的端口和IP就可以直接传输不用建立连接。
这使UDP更加的轻量级，适用于一些实时性高的应用。

2. 不可靠

UDP没有任何安全机制，发送端发送数据报以后，如果因为网络错误发生错误，UDP协议层也不会给应用层返回任何错误信息。

3. 面向数据报

应用层给UDP多长的报文，就会发送多长的报文，并不会拆分合并。

4. 缓冲区

UDP并没有真正的发送缓冲区，具有接受缓冲区。
UDP的scoket既能读，又能写，所以是全双工。

5. 大小受限

UDP协议首部有个16位的最大长度，所以一次最多传输64Kb，包括UDP首部。

6. 无序性

UDP不保证数据包的传输顺序，这对某些应用来说可能是一个缺点，但对其他应用来说，这样的特性可以提高性能。

2. TCP

2.1 TCP结构

• 6位标志位:
  URG：紧急指针是否有效
  ACK：确认号是否有效
  PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
  RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段
  SYN：请求建立连接；我们把携带SYN标识的称为同步报文段
  FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段。

2.2 TCP特点

1. 有连接

通信双方通信前需要建立连接，知道对方的端口号和IP。

2. 可靠性

TCP提供可靠的数据传输，确保数据的完整性和顺序。主要通过确认应答。

3. 面向字节流

TCP是面向字节流的协议，而不是面向消息的。这意味着应用程序需要负责将数据分割为适当的消息或数据块，以便进行传输。

4. 拥塞控制

TCP拥有拥塞控制机制，它可以调整发送速率以避免网络拥塞。通过监控网络的延迟和丢包情况，TCP可以自动适应不同的网络条件。

5. 头部开销

TCP头部较大，包含序号、确认号、窗口大小等字段，因此在某些情况下可能引入较高的开销。

2.3 TCP原理

TCP相对UDP安全性提高，但是效率却降低了，所以TCP中引入了很多在保证安全的情况下提高传输效率。

1. 确认应答（安全机制）

TCP将每个字节的数据都进行了编号，即为序列号。每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。
确认应答就是对方收到消息后，给出回应，让对方知道你收到了。
每当一方收到数据包时，它会发送一个确认应答，通常包含了已经成功接收的数据的序号。这确保了数据的可靠传输，因为发送方会等待确认应答，以确定数据已经到达并且没有丢失。

2. 超时重传（安全机制）

当对方的回应你迟迟没有收到，当到达一定时间，可以重新发送一次。
当一方的数据包或者对方的确认应答在传输途中丢失，一定时间后会重新发送相同的数据包，直到收到确认应答。累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

3. 连接管理（安全机制）

正常情况下TCP要经过三次握手建立连接，四次挥手断开连接。

三次握手

第一次握手：客户端向服务器发送一个特殊的TCP报文，这个报文中的SYN标志位被置为1，这个报文表示客户端希望建立连接。
第二次握手：服务器收到客户端的SYN报文后，需要确认建立连接。服务器会响应一个包含SYN和ACK标志位的报文。这个报文表示服务器同意建立连接。
第三次握手：客户端收到服务器的确认后，也要发送一个确认报文ACK。这个报文告诉服务器它已经收到了服务器的确认，连接建立完成。

四次挥手

第一次挥手：关闭方（通常是客户端）向另一方发送一个TCP报文，带有FIN标志位，表示它已经没有数据要发送，但仍愿意接收数据。这个报文开始了连接的关闭过程。
第二次挥手：接收方收到第一次挥手的报文后，它会发送一个ACK确认报文作为响应。表示接收方已经收到并确认了关闭方的FIN报文。
第三次挥手：接收方（通常是服务器）在确定没有更多数据要发送后，也会发送一个FIN标志的报文，通知对方它准备关闭连接。
第四次挥手：关闭方收到第三次挥手的报文后，也要发送一个ACK确认报文作为响应，以确认接收方的关闭请求。

4. 滑动窗口（效率机制）

上述传输数据时，每次发送一个数据，都需要等待ACK才能发送下一段数据，这样的效率并不高，性能较差，所以引入了滑动窗口。
如图：
我们可以一次发送多条数据，这样就能才等待时间重叠在一起，提高性能。
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段）。
发送前四个段的时候，不需要等待任何ACK，直接发送；
收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
窗口越大，则网络的吞吐率就越高；
丢包处理

1. 丢了ACK
   这种情况下，如果前面的部分ACK丢失，只要接受到后面的ACK，依然可以确认应答。
   
2. 丢了数据包
   当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 “我想要的是 1001” 一样；
   如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 - 2000 重新发送；
   这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了（因为2001 - 7000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；
   这种机制被称为 “高速重发控制”（也叫 “快重传”）。
   

5. 流量控制（安全机制）

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制。
TCP通过流量控制机制来管理数据传输，以确保发送方不会发送过多的数据，从而导致接收方无法处理或网络拥塞。流量控制的主要目标是防止数据包的丢失和网络拥塞。以下是TCP流量控制的关键概念和工作原理：

1. 窗口机制：TCP使用窗口机制来进行流量控制。接收方会告诉发送方它可以接收多少数据，这个信息被称为"接收窗口大小"（Receiver
   Window Size）。

2. 滑动窗口：发送方维护一个发送窗口，它表示当前可以发送的数据量。这个窗口的大小受到接收方的接收窗口大小和网络条件的影响。

3. 通告窗口大小：接收方会在TCP报文中通告当前的接收窗口大小，发送给发送方。这告诉发送方可以发送多少数据，以避免过载接收方。

4. 动态调整窗口大小：接收方可以根据自身处理能力和可用内存动态调整接收窗口大小。如果接收方无法及时处理数据，它可以减小窗口大小，通知发送方降低发送速率。

5. 流量控制的目的：流量控制的主要目的是防止发送方发送过多数据，从而导致接收方缓冲区溢出，数据丢失，或网络拥塞。通过维护适当的接收窗口大小，TCP可以确保发送和接收之间的数据传输协调顺畅。

6. 自适应机制：TCP的流量控制是自适应的，它可以根据网络状况进行调整。如果网络拥塞，接收方可以减小窗口大小，发送方会相应降低发送速率，从而减轻网络负担。

6. 拥塞控制（安全机制）

虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。
因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。
TCP引入慢启动机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据；

7. 延迟应答（效率机制）

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率；
规则：
数量限制：每隔N个包就应答一次；
时间限制：超过最大延迟时间就应答一次
具体的数量和超时时间，依操作系统不同也有差异；一般N取2，超时时间取200ms；

8. 捎带应答（效率机制）

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “How are you”，服务器也会给客户端回一个 “Fine, thank you”；
那么这个时候ACK就可以搭顺风车，和服务器回应的 “Fine，thank you” 一起回给客户端

2.4 粘包问题

首先要明确，粘包问题中的 “包” ，是指的应用层的数据包。
在TCP的协议头中，没有如同UDP一样的 “报文长度” 这样的字段，但是有一个序号这样的字段。
站在传输层的角度，TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
站在应用层的角度，看到的只是一串连续的字节数据。
那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。
那么如何避免粘包问题呢？归根结底就是一句话，明确两个包之间的边界。

1. 对于定长的包，保证每次都按固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof（Request）依次读取即可；
2. 对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；
3. 对于变长的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定的，只要保证分隔符不和正文冲突即可）；

对于UDP协议来说，是否也存在 “粘包问题” 呢？
对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
站在应用层的站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收。不会出现"半个"的情况。