TCP流量控制与拥塞控制:核心机制与区别
一、TCP流量控制(Flow Control)
定义:通过调节发送方的发送速率,确保接收方能够及时处理数据,避免缓冲区溢出。
本质:解决发送方与接收方之间的"端到端"速率匹配问题。
1. 实现机制:滑动窗口协议
- 窗口大小(Window Size):接收方通过TCP报文段中的窗口字段告知发送方自己当前的接收缓冲区可用空间。
- 动态调整过程:
- 接收方收到数据后,在ACK中反馈剩余缓冲区大小(即窗口大小)。
- 发送方根据窗口大小限制发送数据量,窗口为0时暂停发送。
- 示例:若接收方缓冲区大小为1000字节,已占用400字节,则窗口大小为600字节,发送方最多发送600字节数据。
2. 关键问题与解决方案
- 窗口关闭(Zero Window):当接收方缓冲区满时,发送窗口为0的ACK,发送方进入等待状态。
- 解决:接收方定期发送"窗口探测报文"(Window Probe),通知发送方窗口更新。
- 糊涂窗口综合征(Silly Window Syndrome):接收方频繁发送小窗口通知,导致发送方发送大量小包,浪费网络资源。
- 解决:
- 接收方策略:缓冲区达到一半或最大段大小(MSS)时再通知窗口更新。
- 发送方策略:使用Nagle算法,将小包合并为大包发送。
- 解决:
二、TCP拥塞控制(Congestion Control)
定义:通过监控网络负载情况,动态调整发送方的发送速率,避免网络拥塞(如分组丢失、延迟激增)。
本质:解决网络中多发送方与路由器之间的"全局"流量管理问题。
1. 核心算法:四阶段控制模型
-
1. 慢开始(Slow Start)
- 初始拥塞窗口(cwnd)设为1个MSS,每次收到ACK后cwnd按指数增长(×2)。
- 触发条件:连接建立或超时重传后。
- 阈值(ssthresh):当cwnd超过ssthresh时,切换到拥塞避免阶段。
-
2. 拥塞避免(Congestion Avoidance)
- cwnd按线性增长(每轮RTT增加1个MSS),避免网络负载激增。
- 当检测到丢包时,进入快重传或慢开始。
-
3. 快重传(Fast Retransmit)
- 若收到3个重复ACK,认为分组丢失,立即重传而不等待超时。
- 重传后将ssthresh设为当前cwnd的一半,cwnd设为ssthresh,进入快恢复。
-
4. 快恢复(Fast Recovery)
- 不执行慢开始,直接从拥塞避免阶段继续,cwnd线性增长。
2. 拥塞检测机制
- 丢包检测:
- 超时(Timeout):未收到ACK且等待时间超过阈值,认为严重拥塞,触发慢开始。
- 重复ACK:收到3次相同ACK,认为分组丢失,触发快重传。
三、流量控制与拥塞控制的对比
维度 | 流量控制 | 拥塞控制 |
---|---|---|
目标 | 防止接收方缓冲区溢出 | 防止网络整体拥塞 |
控制范围 | 端到端(发送方与接收方之间) | 全局(整个网络路径) |
触发因素 | 接收方缓冲区容量 | 网络中路由器队列溢出、分组丢失 |
关键参数 | 接收窗口(rwnd) | 拥塞窗口(cwnd)、阈值(ssthresh) |
实现方式 | 接收方反馈窗口大小 | 发送方主动调整发送速率 |
典型算法 | 滑动窗口协议 | 慢开始、拥塞避免、快重传、快恢复 |
四、实际应用与案例
- 流量控制场景:手机APP与服务器通信时,若手机内存有限,服务器需根据手机反馈的窗口大小调整发送速率,避免APP崩溃。
- 拥塞控制场景:当网络中多个用户同时下载大文件时,TCP通过拥塞控制算法自动降低每个连接的发送速率,避免路由器拥塞导致全网瘫痪。
五、总结
TCP通过流量控制和拥塞控制的协同工作,在复杂网络环境中实现了可靠性与效率的平衡:
- 流量控制确保数据"送得进去"(接收方处理能力);
- 拥塞控制确保数据"送得出去"(网络路径通畅)。
两者缺一不可,共同构成了TCP协议在互联网中稳定运行的核心基础。
六、整体流程
最开传送数据的时候,会采用慢开始算法,执行到我们的拥塞窗口的值,达到慢开始门限的值之后,就开始执行拥塞避免算法,拥塞避免执行到什么时候呢?这时候分为两种情况:第一种是发生超时,第二种是收到3个ACK(确认)分组。发生超时的时候,它会将慢开始的门限值变为当前拥塞窗口(cwnd)的一半,同时将拥塞窗口的值变为1,重新执行慢开始算法。同样的,达到慢开始门限值之后,执行拥塞避免算法,这是第一种情况,发生超时的情况。第二种情况就是收到3个确认的分组,这种情况的话,它会将它慢开始的门限值变为当前拥塞窗口的一半,同时也将拥塞窗口的值变为当前拥塞窗口的一半,也就是和调整后的慢开始门限值相同。这时候执行的是快恢复算法。
为什么在TCP的拥塞控制中,如果发生了丢包,接收端会向发送端发送3个ACK,而不是2个或者4个,偏偏是3个?
- 背景:TCP 的拥塞控制机制需要在快速检测丢包和避免过度反应之间取得平衡。
- 解释:
- 两个重复 ACK:可能不足以表明丢包的严重性,容易导致误判。
- 三个重复 ACK:是一个合理的阈值,既能有效检测丢包,又能避免因偶然的网络波动而触发不必要的重传。
- 四个或更多重复 ACK:虽然可以进一步减少误判,但会增加检测丢包的延迟,降低网络效率。
七、检测
可以自己试着做一下,下面的这道题,检测自己是否真正掌握了拥塞控制的整体流程
答案: