在没有使用滑动窗口之前，超时重发机制大概是这样子的：
根据数据包的RTT和时间偏差计算出粗略的RTO，当一个数据包发送之后，在RTO时间内还没有返回确认ACK时，发送端就认为该数据包已经丢失，并进行重传。
这里有两种情况：
1）数据包真真切切地没有被接收端接收到。
2）数据包已经被接受但是ACK在返回途中丢失。
不管哪种情况，此时发送端都会进行重传。按照2的指数时间间隔进行重发，指定重发次数。如果还没有收到ACK，那么就认为该通信主机异常，强制关闭连接，终止通信。
如果是第二种情况，有人会说，发送端一直重发相同的包。接收端怎么办，会一直接收到相同的包啊，因为是ACK丢失啊
这里就引入了序列号的概念了，也就是说，序列号的概念也解决了这个问题。通过序列号，可以判断当前数据包是不是重复接收到的，是否需要接受！
目前TCP连接采用滑动窗口机制。使用滑动窗口下数据丢失又该怎么办呢？
首先明确为什么使用滑动窗口机制？
试想一下，每个数据包的收发都要经过发送----返回ACK---再发送 这个流程的话。那么就会出现包的往返时间越长，网络的吞吐量就会越差！而且网络环境都是时时刻刻在变化的，包的RTT都是在变化的，这会导致通信很不可靠！
因此，引入滑动窗口机制.。也就是发送方可以在未接受到一个数据包的ACK时继续发送下一个数据包。在滑动窗口内的数据段都可以同时发送。这样一来就明显的提高了效率，提升了吞吐量。
在窗口机制下，也会出现超时重传的问题。也有两种情况：
1）数据包真真切切地没有被接收端接收到。
2）数据包已经被接受但是ACK在返回途中丢失。
在第一种情况下，假如第一个包没有接收到ACK(第一个包的为1~1000)，那么发送端再继续发送下一个包的时候，接收端会一直发送ACK（1001），发送端接收到超过3次ACK（1001）就认为该报文丢失，进行重发！
第二种情况下，窗口在比较大的时候，即使有少量的ACK没有接收到也不会进行数据重发，因为可以通过下一个确认应答进行确认。
引入了窗口机制之后，不免出现流量控制。
什么是流量控制？
试想，当发送端的窗口比较大的时候，接收端会出现会出现缓冲区溢出的问题，这样一来接收端就会丢弃有用的数据包。这就有引发重传机制，从而导致网络流量的无端浪费。
其实窗口机制就是发送端和接收端在进行三次握手的时候交换自己的窗口大小。使得发送端可以根据接收端的实际接受能力控制发送的数据量。这个数值在数据包交互的过程中是动态变化的。
当接受端缓冲区满的时候，发送给发送端的ACK中通告窗口的值为0.此时发送端会停止发包。在接收到发送窗口的更新通知之后通信才得以继续。但是如果更新通知在途中丢失那通信岂不是中断了？不然，发送端会时不时的发送一个窗口探测的数据包，来获取接收端窗口大小的最新值。