CS随笔-TCP瞎逼逼之数据传输

Tcp可靠传输的实现，主要是做好三方面的细节

1.滑动窗口

2.流量控制

3.拥塞控制

一、滑动窗口

1…10…20…30…40…50…60…70…80…90…100

1…10…20…30…40…50…60…70…80…90…100

首先，给要发的数据通通标上序号

假设：一个数据对应一个序号，已经三次握手，1-19序号的数据已经收到

现在接受方给发送方发消息：发了个ack=19，意思是劳资要从20开始的数据，发了个rwnd=20，意思是一下给我发20个序号。

发送方收到接收方的喊话，做出回应：要的，跟你发，seq=11，表示接收方要的货从11开始的，

一下给接收方发了20个序号，等着接收方回应。

接下来要分情况讨论了

情况一，理想情况

接收方顺利的收到的这20个序号，窗口往前跑，并发个ack=40，告诉发送方，前面的字节我都收到了，这时候发送方的窗口也往前移动，这就是最理想的滑动窗口

1…10…20…30…40…50…60…70…80…90…100    ，看不懂就发挥你的想象力

 算了，贴个图（图与例子不对对应），还不懂，加油，你一定能懂的。

情况二，丢包了

接收方收到了  20,21，23,24, 拐哒，22,没收到，在网络传输的过程中，序号22贪玩，不晓得跑哪旮旯去了。

关键点来了，这时接收方给发送方发的确认包是ack=21，表示序号21收到了。这个应答包，关键就关键在他是以按序收到的数据的最高序号给出确认。有点绕， 按序收到、最高序号、确认。

滑动窗口：接收方滑动窗口到22， 发送方接收到确认包后，滑动窗口到22。

这时发送方给接收方发送了序号为22的数据，接收方接收到了，直接滑动窗口到25，因为刚刚说23,24，已经收到了。一般情况下，未按序收到的序号会暂存在接收窗口中。

极端情况，当发送方迟迟没有收到接收方的确认之后，就会超时重。比如，发了30的序号，发送反开始重传计时，重传计时器超时都没有收到确认包，就会再次发送该序号。

发送方和接收方窗口就这么相互滑动，知道数据收发完。

（错误之处，敬请指正）