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后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
窗口越大，则网络的吞吐率就越高；
丢包处理
- 丢了ACK
这种情况下，如果前面的部分ACK丢失，只要接受到后面的ACK，依然可以确认应答。
- 丢了数据包
当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 “我想要的是 1001” 一样；
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 - 2000 重新发送；
这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了（因为2001 - 7000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；
这种机制被称为 “高速重发控制”（也叫 “快重传”）。
5. 流量控制（安全机制）
接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制。
TCP通过流量控制机制来管理数据传输，以确保发送方不会发送过多的数据，从而导致接收方无法处理或网络拥塞。流量控制的主要目标是防止数据包的丢失和网络拥塞。以下是TCP流量控制的关键概念和工作原理：
窗口机制：TCP使用窗口机制来进行流量控制。接收方会告诉发送方它可以接收多少数据，这个信息被称为"接收窗口大小"（Receiver
Window Size）。滑动窗口：发送方维护一个发送窗口，它表示当前可以发送的数据量。这个窗口的大小受到接收方的接收窗口大小和网络条件的影响。
通告窗口大小：接收方会在TCP报文中通告当前的接收窗口大小，发送给发送方。这告诉发送方可以发送多少数据，以避免过载接收方。
动态调整窗口大小：接收方可以根据自身处理能力和可用内存动态调整接收窗口大小。如果接收方无法及时处理数据，它可以减小窗口大小，通知发送方降低发送速率。
流量控制的目的：流量控制的主要目的是防止发送方发送过多数据，从而导致接收方缓冲区溢出，数据丢失，或网络拥塞。通过维护适当的接收窗口大小，TCP可以确保发送和接收之间的数据传输协调顺畅。
自适应机制：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是一个一个报文过来的。按照序号排好序放在缓冲区中。
站在应用层的角度，看到的只是一串连续的字节数据。
那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。
那么如何避免粘包问题呢？归根结底就是一句话，明确两个包之间的边界。文章来源：https://www.toymoban.com/news/detail-724935.html
- 对于定长的包，保证每次都按固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof（Request）依次读取即可；
- 对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；
- 对于变长的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定的，只要保证分隔符不和正文冲突即可）；
对于UDP协议来说，是否也存在 “粘包问题” 呢？
对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
站在应用层的站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收。不会出现"半个"的情况。文章来源地址https://www.toymoban.com/news/detail-724935.html
到了这里，关于【传输层协议】UDP/TCP结构特点与原理（详解）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
