TCP|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 重传、滑动窗?、流量控制、拥塞控制】所以就有了滑动窗口机制来解决此问题。

有了窗?，就可以指定窗???，窗???就是指?需等待确认应答，?可以继续发送数据的最?值。
窗?的实现实际上是操作系统开辟的?个缓存空间，发送?主机在等到确认应答返回之前，必须在缓冲区中保留已
发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

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

文章图片

接收窗?和发送窗?的??并不是完全相等，接收窗?的??是约等于发送窗?的??的。滑动窗?的大小也是根据实际情况不断变化的。
流量控制 TCP 提供?种机制可以让「发送?」根据「接收?」的实际接收能?控制发送的数据量，这就是所谓的流量控制。
利用上述的滑动窗口与操作系统的缓存结合来控制流量。
大致设计俩个大问题：

滑动窗口怎么逐渐变小
滑动窗口怎么关闭

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

窗口的关闭：窗???为 0 时，就会阻?发送?给接收?传递数据，直到窗?变为? 0 为?，这就是窗?关闭。
潜在的危险-死锁
解决很简单-加定时器，TCP 为每个连接设有?个持续定时器，只要 TCP 连接??收到对?的零窗?通知，就启动持续计时器。
如果持续计时器超时，就会发送窗?探测 ( Window probe ) 报?，?对?在确认这个探测报?时，给出??现在的接收窗???。

文章图片

拥塞控制拥塞现象是指到达通信子网中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象。
这种现象跟公路网中经常所见的交通拥挤一样，当节假日公路网中车辆大量增加时，各种走向的车流相互干扰，使每辆车到达目的地的时间都相对增加（即延迟增加），甚至有时在某段公路上车辆因堵塞而无法开动(即发生局部死锁)。