其他分享
首页 > 其他分享> > TCP 重传、滑动窗⼝、流量控制、拥塞控制

TCP 重传、滑动窗⼝、流量控制、拥塞控制

作者：互联网

重传机制

TCP 会在以下两种情况发⽣超时重传：

重传超时

重传超时是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

RTT 是数据从⽹络⼀端传送到另⼀端所需的时间，也就是包的往返时间。

RTO （Retransmission Timeout 超时重传时间）。

如果超时重发的数据，再次超时的时候，⼜需要重传的时候，TCP 的策略是超时间隔加倍。

超时重传时间 RTO 的值应该略⼤于报⽂往返 RTT 的值：

快速重传

快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。

它不以时间为驱动，⽽是以数据驱动重传。

Seq 2 丢失，于是后面返回都是ACK 2。收到三个ACk 2之后，在定时器到期之前，重传Seq 2。

快速重传的⼯作⽅式是当收到三个相同的 ACK 报⽂时，会在定时器过期之前，重传丢失的报⽂段。

新的问题？

就是重传的时候，是重传之前的⼀个，还是重传所有。于是提出了SACK方法（Selective Acknowledgment 选择性确认）。

这种⽅式需要在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，它可以将缓存的地图发送给发送⽅，这样发送
⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

如果要⽀持 SACK ，必须双⽅都要⽀持。在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux
2.4 后默认打开）

滑动窗口

由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，

所以就有了滑动窗口机制来解决此问题。

有了窗⼝，就可以指定窗⼝⼤⼩，窗⼝⼤⼩就是指⽆需等待确认应答，⽽可以继续发送数据的最⼤值。

窗⼝的实现实际上是操作系统开辟的⼀个缓存空间，发送⽅主机在等到确认应答返回之前，必须在缓冲区中保留已

发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

详细见图示：

TCP 滑动窗⼝⽅案使⽤三个指针来跟踪在四个传输类别中的每⼀个类别中的字节。其中两个指针是绝对指针（指特定的序列号），⼀个是相对指针（需要做偏移）。

接收窗⼝和发送窗⼝的⼤⼩并不是完全相等，接收窗⼝的⼤⼩是约等于发送窗⼝的⼤⼩的。滑动窗⼝的大小也是根据实际情况不断变化的。

流量控制

TCP 提供⼀种机制可以让「发送⽅」根据「接收⽅」的实际接收能⼒控制发送的数据量，这就是所谓的流量控制。

利用上述的滑动窗口与操作系统的缓存结合来控制流量。

大致设计俩个大问题：

减小的过程应该遵循：先收缩窗⼝，过段时间再减少缓存，这样就可以避免了丢包情况。

窗口的关闭：窗⼝⼤⼩为 0 时，就会阻⽌发送⽅给接收⽅传递数据，直到窗⼝变为⾮ 0 为⽌，这就是窗⼝关闭。

潜在的危险-死锁

解决很简单-加定时器，TCP 为每个连接设有⼀个持续定时器，只要 TCP 连接⼀⽅收到对⽅的零窗⼝通知，就启动持续计时器。

如果持续计时器超时，就会发送窗⼝探测 ( Window probe ) 报⽂，⽽对⽅在确认这个探测报⽂时，给出⾃⼰现在的接收窗⼝⼤⼩。

拥塞控制

拥塞现象是指到达通信子网中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象。

这种现象跟公路网中经常所见的交通拥挤一样，当节假日公路网中车辆大量增加时，各种走向的车流相互干扰，使每辆车到达目的地的时间都相对增加（即延迟增加），甚至有时在某段公路上车辆因堵塞而无法开动(即发生局部死锁)。

发送窗⼝ swnd

接收窗⼝ rwnd

拥塞控制主要是四个算法：

慢启动

有⼀个叫慢启动⻔限 ssthresh （slow start threshold）状态变量。

拥塞避免

拥塞避免是线性增长，当触发了重传机制，也就进⼊了「拥塞发⽣算法」。

拥塞发⽣算法

重传机制主要有两种：

重传超时：

快速重传：

参考

标签：重传,TCP,发送,拥塞,超时,cwnd
来源： https://www.cnblogs.com/bbzblog/p/16083057.html