一篇带你读懂TCP之“滑动窗口”协议

前言

你如今的努力,是为了之后有更多的选择。编程

在上一篇文章经过“表白”方式,让咱们快速了解网络七层协议 了解了网络七层协议。 接下来咱们要把重心放在网络传输的可靠性上面。一块儿来看TCP协议,它是如何解决网络传输不可靠的问题。这其中有个很关键的部分,就是咱们的滑动窗口协议缓存

从工程学角度上,咱们来看一看滑动窗口协议,它到底解决了一个怎样的问题?网络

滑动窗口协议:

  • TCP协议的使用
  • 维持发送方/接收方缓冲区 缓冲区是 用来解决网络之间数据不可靠的问题,例如丢包,重复包,出错,乱序

在TCP协议中,发送方和接受方经过各自维护本身的缓冲区。经过商定包的重传机制等一系列操做,来解决不可靠的问题。学习

问题一:如何保证次序?

提出问题:在咱们滑动窗口协议以前,咱们如何来保证发送方与接收方之间,每一个包都能被收到。而且是按次序的呢?code

问题1
发送方发送一个包1,这时候接收方确认包1。发送包2,确认包2。就这样一直下去,知道把数据彻底发送完毕,这样就结束了。那么就解决了丢包,出错,乱序等一些状况!同时也存在一些问题。问题:吞吐量很是的低。咱们发完包1,必定要等确认包1.咱们才能发送第二个包。

问题二:如何提升吞吐量?

提出问题:那么咱们就不能先连发几个包等他一块儿确认吗?这样的话,咱们的速度会不会更快,吞吐量更高些呢?cdn

改进方案
如图,这个就是咱们把两个包一块儿发送,而后一块儿确认。能够看出咱们改进的方案比以前的好不少,所花的时间只是一个来回的时间。接下来,咱们还有一个问题:改善了吞吐量的问题

问题三:如何实现最优解?

问题:咱们每次须要发多少个包过去呢?发送多少包是最优解呢?视频

咱们能不能把第一个和第二个包发过去后,收到第一个确认包就把第三个包发过去呢?而不是去等到第二个包的确认包才去发第三个包。这样就很天然的产生了咱们"滑动窗口"的实现。 blog

实现
在图中,咱们可看出灰色1号2号3号包已经发送完毕,而且已经收到Ack。这些包就已是过去式。四、五、六、7号包是黄色的,表示已经发送了。可是并无收到对方的Ack,因此也不知道接收方有没有收到。八、九、10号包是绿色的。是咱们尚未发送的。这些绿色也就是咱们接下来立刻要发送的包。 能够看出咱们的窗口正好是11格。后面的11-16尚未被读进内存。要等4号-10号包有接下来的动做后,咱们的包才会继续往下发送。

正常状况

正常状况
能够看到4号包对方已经被接收到,因此被涂成了灰色。“窗口”就往右移一格,这里只要保证“窗口”是7格的。 咱们就把11号包读进了咱们的缓存。进入了“待发送”的状态。八、9号包已经变成了黄色,表示已经发送出去了。接下来的操做就是同样的了,确认包后,窗口日后移继续将未发送的包读进缓存,把“待发送“状态的包变为”已发送“。

丢包状况

有可能咱们包发过去,对方的Ack丢了。也有可能咱们的包并无发送过去。从发送方角度看就是咱们没有收到Ack。 token

丢包
发生的状况:一直在等Ack。若是一直等不到的话,咱们也会把读进缓存的待发送的包也一块儿发过去。可是,这个时候咱们的窗口已经发满了。因此并不能把12号包读进来,而是始终在等待5号包的Ack。

若是咱们这个Ack始终不来怎么办呢?图片

超时重发

这时候咱们有个解决方法:超时重传 这里有一点要说明:这个Ack是要按顺序的。必需要等到5的Ack收到,才会把6-11的Ack发送过去。这样就保证了滑动窗口的一个顺序。

超时重发
这时候能够看出5号包已经接受到Ack,后面的六、七、8号包也已经发送过去已Ack。窗口便继续向后移动。

文末

从咱们为了增长网络的吞吐量,想讲数据包一块儿发送过去,这时候便产生了“滑动窗口”这种协议。有了“滑动窗口”这个概念,咱们又解决了其中出现的一些问题。例如丢包,咱们又经过重发的机制去解决了。以上来自ccmouse老师教学视频,做为学习记录整理。

若是文章对你有用的话,欢迎关注公众号:Coder编程 获取最新原创技术文章和相关免费学习资料,随时随地学习技术知识!

在这里插入图片描述
相关文章
相关标签/搜索