【网络】TCP的滑动窗口以及包丢失的重传问题
滑动窗口
在TCP的确认应答策略中，对每一个发送的数据段，都要给一个ACK确认应答，收到ACK之后再发送下一个数据段，这样做的缺点就是性能较差，在等待确认应答包环节浪费环节。由于一发一收的方式性能较低，那么可以一次发送多条数据，就可以大大提高性能（将多个端的等待时间重叠到一起）。
如下图（窗口大小为4，数据的传输过程）：
- 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，上图的窗口大小就是4000个字节（4个段）；
- 发送前四个端的时候，不需要等待任何ACK，直接发送；
- 收到第一个ACK之后，滑动窗口向后移动，继续发送第五个段的数据，以此类推；
- 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有确认应答的数据，才能从缓冲区删掉；
- 窗口越大，则网络的吞吐率就越高；
窗口大小在实际应用中，可以分为两部分。第一部分表示数据包已经发送，但未得到确认应答包；第二部分表示允许发送，但未发送的数据包。在进行数据包发送时，当发送了最大数量的数据包（窗口大小数据包），有时不会同时收到这些数据包的确认应答包，而是收到部分确认应答包。那么，此时窗口就会通过滑动的方式，向后移动，确保下一次发送仍然可以发送窗口大小的数据包。这样的方式被称为滑动窗口机制。滑动窗口机制的原理如下：
数据重传
在进行数据包传输时，难免会出现数据丢失情况。这种情况一般分为两种。
情况一：数据包已经抵达，ACK（确认应答包）被丢了
这种情况下，如果未使用滑动窗口机制，发送的数据包没有收到确认应答包，那么数据都会被重发；如果使用了滑动窗口机制，即使确认应答包丢失，也不会导致数据包重发，因为可以通过后续的ACK进行确认；
这种情况下指的是前面发送的数据包没有收到对应的确认应答。当收到后面数据包的确认应答包，表示前面的数据包已经成功被接受到了，发送端不需要重新发送前面的数据包了。如下图所示：
窗口在一定程度上较大时，即使有少部分的确认应答丢失也不会进行数据重发，可以通过下一个确认号进行确认。
情况二：数据包直接丢了
这种情况指的是发送端发送的部分数据没有达到接收端。那么，如果接收端收到的数据包，不是本该要接受的数据包，就是给发送端返回消息，告诉发送端自己应该接收的数据包。
如果发送端连续收到3次这样的数据包，就认为该数据包成功发送到接收端，这时就重发该数据包。这种机制叫做高速重发机制。
有以下7个过程：
（1）发送端发送数据包：这里的窗口大小为4，所以发送端1发了四个数据包，如上图所示‘
（2）接收端返回确认应答包：接收端收到这些数据，并给出确认应答包。数据包2001-3001在发送过程中丢失了，没有成功到达接收端，但是它的下一个数据包3001-4000没有丢失成功到达了接收端，但是该数据包不是接收端应该接受到的数据包，因此接收端收到数据包3001-4000以后，第一次返回下一个是2001的数据包的确认应答包；
（3）发送端发送数据包：发送端仍然向接收端发送4个数据包；
（4）接收端返回确认应答包：当接收端收到数据包4001-5000时，发现不是自己应该接受的数据包2001-3000，第二次返回下一个是2001的数据包的确认应答包。当接收端收到数据包5001-6000时，仍然发现不是自己应该接受的数据包，第三次返回下一个是2001的数据包的确认应答包。依次类推直到接受完所有数据包，接收端都返回下一个应该是2001的数据包的确认应答包。
（5）发送端重发数据包：发送端连续3次收到结束端发来的下一个应该发送2001的数据包的确认应答包，认为数据包2001-3000丢失了，就进行重发该数据包。
（6）接收端收到重发数据包：接收端收到重发数据包以后，查看这次是自己应该接受的数据包2001-3000，并返回确认应答包，告诉发送包，下一个该接受8001的数据包了（因为3001-8000接收端其实之前就收到了，被放到了接收端操作系统内核的接受缓冲区）。
（7）发送端发送数据包：发送端收到确认应答包后，继续发送窗口大小为4的数据包。
补充：之所以连接到3次而不是两次的原因是因为，即使数据段的序号被替换两次也不会触发重发机制。