Linux网络-------4.传输层协议UDP/TCP-----原理

1.再谈端⼝号

端⼝号(Port)标识了⼀个主机上进⾏通信的不同的应⽤程序;

在TCP/IP协议中,⽤ "源IP","源端⼝号","⽬的IP","⽬的端⼝号","协议号" 这样⼀个五元组来标识⼀个通信(可以通过netstat-n查看);

• UDP和TCP协议主要管理的是端口号----包含目的端口号和源端口号
• 网络层的报头会显示提交给传输层，使用的是哪一个协议！！！
• 图中蓝色方框中的其实就是TCP/UDP的报头！！！！！！！

2.UDP报头详解

1.如何分离？

如图，这个udp报文中给出了16位的UDP长度，而且除了数据以外的内容长度是固定的，都是8字节，那么用 UDP长度减去8字节就是数据的部分 了，实现数据的分离！！！！！

2.如何分用？

通过目的端的端口号来进行分用—分配给客户端对应的端口处！！！！！

3.UDP协议详解

1.特点

2.UDP的缓冲区

3.UDP的注意事项

4.报文格式

在这里插入图片描述

5.TCP协议详解

在这里插入图片描述

• 可以看到采用TCP协议，服务端和客户端都 拥有发送缓冲区和接收缓冲区两个缓冲区 ！！！！

6.TCP报头格式详解

在这里插入图片描述

1.如何分用

和UDP一致，有16位目的端口号

2.如何分离

在这里插入图片描述

3.可靠性的保证

TCP是具有可靠性的·，UDP则没有

1.什么是可靠性？？？？

2.tcp如何保证可靠性？？？？？

提问：为什么需要两个信号嘞？

• 因为 服务器不只是做应答，还要求对方能接受到自己的数据
• 即一个tcp报文的序号是用来让对方接收自己数据的！！！！
• 确认序号是用来让对方确认自己收到了对方的数据的！！！

4.可接收信息的标识

• 如果对方的接收缓冲区的大小不足以接收即将发送的内容大小，那么发送端的TCP报文就会被丢弃
• 据上文，如果被丢弃，那么就没办法返回TCP报文给发送端，导致不可靠

如何解决这个问题呢？？？？？？？？？？？？？？？？？？？？？

答案是，如果发送端在发送内容前就知道接收端的接收缓冲区的剩余空间大小不就好啦！！！！！！！！！！

这就需要使用 TCP报头的16位窗口大小 啦！！！！

5.标识报文类型的字段

为什么需要这个字段？

在这里插入图片描述

以三次握手为例子，想要两端进行通信，必须要先完成三次握手！！！！

在这里插入图片描述

在这里插入图片描述

7.TCP机制介绍

1.确认应答(ACK)机制

在这里插入图片描述

序号的理解

在这里插入图片描述

其实，序号就是要传递的数据的最后一个字节编号，如图，第一个数据的序号就是1000，确认序号就是1001

每⼀个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下⼀次你从哪⾥开始发.

丢包的解释

在这里插入图片描述

在正常情况下,TCP要经过三次握⼿建⽴连接,四次挥⼿断开连接

2.TCP连接管理机制—三次握手解释

在这里插入图片描述

为什么要使用三次握手？？？？？

–为了以最快的方式验证全双工！！！！！！！！------即客户端和服务端都能写能发！！！！！！

在这里插入图片描述

在这里插入图片描述

3.TCP断开连接机制—四次挥手解释

在这里插入图片描述

4.滑动窗⼝机制

刚才我们讨论了确认应答策略,对每⼀个发送的数据段,都要给⼀个ACK确认应答.收到ACK后再发送下⼀个数据段.这样做有⼀个⽐较⼤的缺点,就是性能较差.尤其是数据往返的时间较⻓的时候.

在这里插入图片描述

既然这样⼀发⼀收的⽅式性能较低,那么我们⼀次发送多条数据,就可以⼤ 的提⾼性能(其实是将多个段的等待时间重叠在⼀起了).

在这里插入图片描述

那么，怎么知道我一次性可以发多少个数据呢？？？？--------使用滑动窗口！！！

在这里插入图片描述

1.滑动窗口详解

在这里插入图片描述

在这里插入图片描述

• 确认应答后，滑动窗口开始移动！！！！

在这里插入图片描述

2.滑动窗口数据丢失问题

1.最左侧数据丢失

情况⼀:数据包已经抵达,ACK被丢了

在这里插入图片描述

• 滑动窗口正常工作，因为实际数据已经收到，只是没有应答，只要后序其他有应答完成即可。

情况⼆:数据包就直接丢了.

在这里插入图片描述

• 滑动窗口左端不动，右端移动-------这种机制被称为"⾼速重发控制"(也叫"快重传").

在这里插入图片描述

在这里插入图片描述

• 只有触发重传并且得到应答之后，滑动窗口左端才会开始移动！！！！！！！

5.TCP流量控制

接收端处理数据的速度是有限的.如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继⽽引起丢包重传等等⼀系列连锁反应. 因此TCP⽀持根据接收端的处理能⼒,来 决定发送端的发送速度.这个机制就叫做流量控制(Flow Control);

在这里插入图片描述

6.TCP拥塞控制----阻塞窗口

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

在这里插入图片描述

在这里插入图片描述

• 即 滑动窗口=min（对方win，阻塞窗口） ！！！！！！

在这里插入图片描述

在这里插入图片描述

• 注意，前期拥塞窗口按指数级增长，不代表数据发送量也要增长----------滑动窗口=min（对方win，阻塞窗口）
• 1.对方的win可能变小导致滑动窗口变小，导致发送的数据量减少
• 2.一旦遭遇网络拥堵------即大规模丢包，阻塞窗口会被重新设置为1，发送的数据量也会减少

7.TCP延迟应答

在这里插入图片描述

在这里插入图片描述

7.TCP可靠性保证（总结）

TCP协议通过以下机制保证数据传输的可靠性：

1. 数据分块与序列号（Sequence Number）

• 分段传输：将应用层数据分割为适合网络传输的TCP报文段。
• 序列号标记：每个字节的数据都被分配唯一的序列号，确保接收方能按顺序重组数据。

2. 确认应答（ACK）与超时重传

• ACK机制：接收方收到数据后，发送确认报文（ACK），包含下一个期望的序列号。
  • 例如，发送方发送序列号1~1000的数据，接收方回复ACK=1001。
• 超时重传：若发送方未收到ACK（超时或丢包），则重传数据。
  • 动态计算超时时间（RTO，基于RTT自适应调整）。

3. 滑动窗口（流量控制）

• 接收方窗口（rwnd）：接收方通过TCP头部通告可用缓冲区大小，防止发送方过快发送导致溢出。
• 发送方限制：实际发送窗口取 min(cwnd, rwnd)（拥塞窗口与接收窗口的最小值）。

4. 拥塞控制（Congestion Control）

通过动态调整拥塞窗口（cwnd）避免网络过载：

• 慢启动（Slow Start）：cwnd从1开始指数增长，直到达到阈值（ssthresh）。
• 拥塞避免（AIMD）：超过ssthresh后，cwnd线性增长（“加法增大”）。
• 快速重传/恢复：
  • 收到3个重复ACK时，立即重传丢失报文（快速重传），并减半cwnd（快速恢复）。
  • 超时重传时，直接重置cwnd=1，重新进入慢启动。

5. 校验和（Checksum）

• 每个TCP报文段包含校验和字段，接收方验证数据完整性。若校验失败，直接丢弃并触发重传。

6. 连接管理（三次握手与四次挥手）

• 三次握手：建立连接时同步序列号（SYN/ACK），确保双方收发能力正常。
• 四次挥手：可靠释放连接，确保数据全部传输完毕（FIN/ACK）。

可靠性保障的核心

• 无丢失：通过ACK和重传确保数据到达。
• 无重复：序列号去重。
• 无乱序：滑动窗口和序列号保证顺序。
• 无错误：校验和验证数据完整性。

TCP通过以上机制在不可靠的IP层上实现了可靠的、面向连接的数据传输。