---

1.超时重传

1.什么是超时重传？

• 在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的ACK确认应答报文，就会重发该数据

• TCP在两种情况下会触发超时重传：

  • 确认应答丢失
  • 数据包丢失
    

• 当出现丢包时，客户端(发送方)是无法辨别是发送的数据包丢失了，还是对方发来的确认应答报文丢失了，因为这两种情况下发送方都收不到对方发来的响应报文，此时客户端(发送方)就只能进行超时重传

• 如果是服务器(接收方)确认应答报文丢失而导致发送方进行超时重传，此时服务器(接收方)就会再次收到一个重复的报文数据，但此时也不用担心，接收方可以根据报头当中的32位序列号来判断曾经是否收到过这个报文，从而达到报文去重的目的

• 需要注意的是，当发送缓冲区当中的数据被发送出去后，操作系统不会立即将该数据从发送缓冲区当中删除或覆盖，而会让其保留在发送缓冲区当中，以免需要时进行超时重传，直到收到该数据的响应报文后，发送缓冲区中的这部分数据才可以被删除或覆盖

2.超时时间是如何确定的？

• 超时重传时间是以RTO(Retransmission Timeout 超时重传时间)表示
• 如果超时重传的时间过长或过短会发生什么情况呢？
  • 超时重传的时间设置的太长，会导致丢包后对方长时间收不到对应的数据，进而影响整体重传的效率
  • 超时重传的时间设置的太短，会导致对方收到大量的重复报文，可能对方发送的响应报文还在网络中传输而并没有丢包，但此时发送方就开始进行数据重传了，并且发送大量重复报文会也是对网络资源的浪费
• TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间
  • Linux中(BSD Unix和Windows也是如此)，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍
  • 如果重发一次之后, 仍然得不到应答, 等待 2*500ms后再进行重传
  • 如果仍然得不到应答, 等待 4*500ms 进行重传，依次类推，以指数形式递增
  • 累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接

---

2.快速重传

• TCP 还有另外一种快速重传机制，它不以时间为驱动，而是以数据驱动重传
  • 快速重传的工作方式是当收到三个相同的ACK报文时，会在定时器过期之前，重传丢失的报文段
• 快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另外一个问题
  • 就是重传的时候，是重传之前的一个，还是重传所有的问题
  • 为了解决不知道该重传哪些TCP报文，于是就有SACK方法
    

---

3.SACK

• 还有一种实现重传机制的方式叫：SACK(Selective Acknowledgment 选择性确认)
• 这种方式需要在TCP头部选项字段里加一个SACK的东西，它可以将缓存的地图发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据
• 如下图，发送方收到了三次同样的ACK确认报文，于是就会触发快速重发机制，通过SACK信息发现只有200~299这段数据丢失，则重发时，就只选择了这个TCP段进行重发
  

---

4.D-SACK

• 其主要使用了SACK来告诉发送方有哪些数据被重复接收了

1.ACK丢失

• 接收方发给发送方的两个ACK确认应答都丢失了，所以发送方超时后，重传第⼀个数据包(3000 ~ 3499)
• 于是接收方发现数据是重复收到的，于是回了⼀个 SACK = 3000_{3500，告诉发送方3000}3500的数据早已被接收了，因为ACK都到了 4000了，已经意味着4000之前的所有数据都已收到，所以这个SACK就代表着D-SACK
• 这样发送方就知道了，数据没有丢，是接收方的ACK确认报文丢了

2.网络延迟

• 数据包(1000~1499)被网络延迟了，导致发送方没有收到Ack 1500的确认报文
• 而后面报文到达的三个相同的ACK确认报文，就触发了快速重传机制，但是在重传后，被延迟的数据包(1000~1499)又到了接收方
• 所以接收方回了⼀个 SACK=1000~1500，因为ACK已经到了3000，所以这个SACK是D-SACK，表示收到了重复的包
• 这样发送方就知道快速重传触发的原因不是发出去的包丢了，也不是因为回应的ACK包丢了，而是因为网络延迟了
• 可见，D-SACK有这么几个好处
  • 可以让发送方知道，是发出去的包丢了，还是接收方回应的ACK包丢了
  • 可以知道是不是发送方的数据包被网络延迟了
  • 可以知道网络中是不是把发送方的数据包给复制了

---

5.滑动窗口

0.问题抛出

• 我们都知道TCP是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 再发送下一个

  • 这种方式的缺点是效率比较低

• 这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低
  

• 为解决这个问题，TCP引入了窗口这个概念，即使在往返时间较长的情况下，它也不会降低网络通信的效率

• 那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值

• 窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除

• 假设窗口大小为3个TCP段，那么发送方就可以**「连续发送」** 3个TCP段，并且中途若有ACK丢失，可以通过「下一个确认应答进行确认」

  • 图中的ACK 600确认应答报文丢失，也没关系，因为可以通过下⼀个确认应答进行确认，只要发送方收到了ACK 700确认应答，就意味着700之前的所有数据「接收方」都收到了，这个模式就叫**累计确认或者累计应答**
    

• 窗口大小由哪一方决定？

  • TCP报头里有一个字段叫Window，也就是窗口大小
  • 这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据，于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来
  • 所以，通常窗口的大小是由接收方的窗口大小来决定的
  • 发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据

• 滑动窗口既想给对方推送更多的数据，又想要保证对方来得及接收

• TCP使用滑动窗口进行流量控制，实际上是对发送方数据流量的控制

1.发送方的滑动窗口

• 下图就是发送方缓存的数据，根据处理的情况分成四个部分，其中深蓝色方框是发送窗口，紫色方框是可用窗口：
  

• 在下图，当发送方把数据全部都一下发送出去后，可用窗口的大小就为0了，表明可用窗口耗尽，在没收到ACK确认之前是无法继续发送数据了
  

• 在下图，当收到之前发送的数据32_{36字节的ACK确认应答后，如果发送窗口的大小没有变化，则滑动窗口往右边移动5个字节，因为有5个字节的数据被应答确认，接下来52}56字节又变成了可用窗口，那么后续也就可以发送52~56这5个字节的数据了
  

2.如何表示发送方的四个部分？

• TCP滑动窗口方案使用三个指针来跟踪在四个传输类别中的每一个类别中的字节
  • 其中两个指针是绝对指针(指特定的序列号)
  • 一个是相对指针(需要做偏移)
• SND.WND**：**表示发送窗口的大小(大小是由接收方指定的)
• SND.UNA**：**是一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号
• SND.NXT**：**也是一个绝对指针，它指向未发送但可发送范围的第一个字节的序列号
• 指向#4的第一个字节是个相对指针，它需要 SND.UNA 指针加上SND.WND大小的偏移量，就可以指向#4的第一个字节
• 那么可用窗口大小的计算就可以是：
  • 可用窗口大小 = SND.WND - (SND.NXT - SND.UNA)
    

3.接收方的滑动窗口

• 接收窗口相对简单一些，根据处理的情况划分成三个部分，使用两个指针进行划分:
  • RCV.WND**：**表示接收窗口的大小，它会通告给发送⽅
  • RCV.NXT**：**是一个指针，它指向期望从发送方发送来的下一个数据字节的序列号
  • 指向#4的第一个字节是个相对指针，它需要RCV.NXT指针加上 RCV.WND 大小的偏移量，就可以指向#4 的第一个字节了
    

4.滑动窗口的完善理解

• 滑动窗口的本质：指针或者下标
• 滑动窗口向右移动吗？
  • 不一定
• 滑动窗口可以为0吗？
  • 可以
• 滑动窗口如果一直向右滑动，是否会出现越界问题？
  • 不会，虽然缓冲区物理层面上是数组，但是逻辑层面上是环形数组，到数组结尾的时候或通过模运算等处理手段回到开头