什么是滑动窗口
维持发送方/接收方缓冲区,缓冲区是用来解决网络之间数据不可靠的问题,例如丢包,重复包,出错,乱序。在TCP协议中,发送方和接受方通过各自维护自己的缓冲区。通过商定包的重传机制等一系列操作,来解决不可靠的问题。
问题一:如果你是TCP设计者,如何保证数据包依次序传输?
解决方案: 发送 <=> 确认机制
问题二: 采用问题一的解决方案会带来效率上的弊端,数据包在网络上的传输需要时间
解决方案: 一次发送多个包,同时确认多个
问题三: 我们每次需要发多少个包过去呢?发送多少包是最优解呢?
正常情况
我们能不能把第一个和第二个包发过去后,收到第一个确认包就把第三个包发过去呢?而不
是去等到第二个包的确认包才去发第三个包。这样就很自然的产生了我们"滑动窗口"的实
现。
在图中,我们可看出灰色1号2号3号包已经发送完毕,并且已经收到Ack。这些包就已经是过去式。4、5、6、7号包是黄色的,表示已经发送了。但是并没有收到对方的Ack,所以也不知道接收方有没有收到。8、9、10号包是绿色的。是我们还没有发送的。这些绿色也就是我们接下来马上要发送的包。 可以看出我们的窗口正好是7格。后面的11-16还没有被读进内存。要等4号-10号包有接下来的动作后,我们的包才会继续往下发送。
可以看到4号包对方已经被接收到,所以被涂成了灰色。“窗口”就往右移一格,这里只要保证“窗口”是7格的。 我们就把11号包读进了我们的缓存。进入了“待发送”的状态。8、9号包已经变成了黄色,表示已经发送出去了。接下来的操作就是一样的了,确认包后,窗口往后移继续将未发送的包读进缓存,把“待发送“状态的包变为”已发送“。
丢包情况
有可能我们包发过去,对方的Ack丢了。也有可能我们的包并没有发送过去。从发送方角度
看就是我们没有收到Ack。
一般情况:一直在等Ack。如果一直等不到的话,我们也会把读进缓存的待发送的包也一起发过去。但是,这个时候我们的窗口已经发满了。所以并不能把12号包读进来,而是始终在等待5号包的Ack。
如果我们这个Ack始终不来怎么办呢? 采用超时重传机制解决:
发送端每发送一个报文段,就启动一个定时器并等待确认信息;接收端成功接收新数据后返回确认信息。若在定时器超时前数据未能被确认,TCP就认为报文段中的数据已丢失或损坏,需要对报文段中的数据重新组织和重传。(重传超时时间: RTO)