地图截选做分析图的网站热搜榜上2023年热门话题

本文描述TCP在异常网络下的处理方式 以保证其可靠的数据传输的服务

TCP超时重传

tcp服务能够重传其超时时间内没有收到确认的TCP报文段，tcp模块为每一个报文段都维护一个重传定时器，定时器在第一次TCP报文段发送的时候启动，如果超时事件内没有收到回复。Tcp模块就会重传该报文段并重置定时器

至于下次重传的事件 和最多的重传次数 就是重传策略的选择。
liunx内核有两个重要的内核参数和tcp超时重传相关:
/proc/sys/net/ipv4/tcp_retries1
/proc/sys/net/ipv4/tcp_retries2
前者指定了底层IP接管TCP最少执行的重传次数 ，默认3
后者指定连接放弃前TCP最多可以执行的重传次数 默认15（一般对应13 - 30min）
虽然超时会导致TCP报文段重传，但是tcp报文段的重传可以发生在超时之前，即快速重传。

拥塞控制

概述

拥塞控制的目的是

• 提高网络利用率
• 降低丢包率
• 保证网络资源对每条数据流的公平性

拥塞控制标准文档是RFC 5861 四个部分：

• 慢启动（slow start）
• 拥塞避免(congestion avoidance)
• 快速重传(fast retransmit)
• 快速恢复（fast recovery）
  拥塞控制算法在liunx上 有多种实现，比如reno算法，vegas算法和cubic算法等。它们或者部分或者全部实现了上面上述四个部分.
  /proc/sys/net/ipv4/tcp_congestion_control 文件指示机械当前所使用的拥塞控制算法
  
  在发送端一次向网络中连续写入的数据量(收到其中第一个数据的确认之前) 我们称为SWND（Send Window 发送窗口） 发送端最终以TCO的报文段来发送内容 所以SWND限定了发送端能发送的TCP报文段的数量。
  TCP报文段的最大长度(数据部分) 被称为SMSS(Sender MAximum Segment Size ，发送者最大段的大小) 其值一般等于MSS
  MSS的值通常是由MTU（Maximum Transmission Unit，最大传输单元）减去IP首部长度（20字节）和TCP首部长度（20字节）得到的。因此，如果MTU值为1500字节，那么MSS的值一般就是1460字节）。
  发送端需要合理的选择SWND的大小 ，如果SWND太小会引起明显的网络延迟 反之如果太大则会导致网络拥塞。
  接收方虽然可以通过RWND来控制发送端的SWND，但是显然不够
  发送端引入了一个称为拥塞窗口的状态变量(CWND) 实际的SWND值 是RWND和CWND里面的较小者
  下图显示了拥塞控制的输入和输出
  

慢启动和拥塞避免

Tcp创建好连接后 CWND的值被初始化为IW(initial Window ) 其大小为2~4个SMSS。但新的Liunx内核提高了该值的初始化，以减少传输滞后。
发送端最多可以发送IW字节的数据 ，此后发送端没收到一个及手段的确认。其CWND就按格式增加

---

cwnd +=min(N,SMSS)
（读者在其他地方也可以看到了 cwnd是直接加上一个SMSS的值的 这个我不太清 查资料没查到 欢迎指正）

---

其中的N表示 此次确认中包含之前未被确认的字节数。
这样CWND将会按指数的形式扩大，这就慢启动。
慢启动算法的理由是，TCP模块刚开始发送数据并不知道网络的实际情况，需要一种探测的方式平滑的增加CWND的小事。
如果不是家其他手段 慢启动必然会使得 CWND很快膨胀最终导致网络拥塞。因此TCP拥塞控制汇总顶一个另一个重要的状态变量：
慢启动门限(ssthresh) 当CWND的大小超过该值的时。TCP拥塞控制将进入拥塞避免阶段。

---

拥塞避免算法是的CWND按照线性的方式增加 从而减缓起扩大.RFC 5681中提到了如下两种实现方式:

• 每个RTT时间内按照格式从新计算新的CWND，不论RTT事件内收到了多少个确认
• 没收到一个新的数据确认报文段，就按照下面公式来更新CWND
• CWND +=SMSS*SMSS/CWND

下图粗略描述了慢启动和拥塞避免发生的时机和区别。 假设ssthresh的大小是16SMSS大小 实际远不止这么大

以上是发送端在未检测到拥塞时所采取的积极避免拥塞的方法。
下面介绍拥塞发生时（可能在慢启动 也可能在拥塞避免阶段） 拥塞控制的行为。

下面讲解发送端如何判断拥塞发生。

• 传输超时，或者TCP重传定时器溢出
• 接受到重复的确认报文段
  拥塞控制对第一种情况仍然使用慢启动和拥塞避免。
  第二种情况使用快速重传和快速恢复（如果真的发生拥塞的话）。
  第二种情况如果发生在第一种情况之后也就是重传定时器溢出，也会被拥塞控制当成第一种情况来对待。
  如果发送端检测到拥塞发生是由于传输超时 它就会执行重传并做出一下调整
  
  其中FlightSize是已经发送但是没有收到确认的字节数。这样调整 CWMD将小于SMSS。必然也小于新的慢启动门限值ssthresh
  拥塞控制一定会再次进入慢启动阶段

快速重传和快速恢复

有时发送端可能接收到重复的确认报文段，如TCP报文段丢失 或者接收端收到乱序的TCP报文段并重排的时候，拥塞控制算法需要判断当收到重复确认的报文。网络是否真的拥塞 或者TCP报文段是否真的丢失。
具体的做法是当发送端连续收到三个重复的确认报文段 就认为是拥塞发生。就会启动快速重传和快速恢复算法来吃处理拥塞
过程如下：

1. 当收到三个重复的确认报文的时候 按照
   
   来计算ssthresh，然后立刻重传丢失的报文段
   并按照
   
   来设置CWND
2. 每次收到一个重复的确认的时候 ，设置CWND=CWND+SMSS。 此时发送端可以发送新的TCP报文段。如果新的CWND允许的话
3. 当收到新的数据确认的时候 设置CWND = ssthresh（ssthresh是新的慢启动的门限值）由第一步计算得到
   快速重传和快速恢复完成之后 拥塞控制将恢复的拥塞避免阶段 这一点由第3 步可以知道