如果在接收端增加对frame的纠错功能，则开销会很大，大大降低系统的传输效能，一般没人这么做。

如果接收端根本没有收到数据封包，它就不会给发送端回送ACK，因而需要在发送端添加timeout机制，超时重传

每次只发一个封包，在收到该封包的ack之后才发送下一个封包。

发一个封包，然后等ack，在整个round trip time（RTT）时间段内，整个链路上只有一个封包在传送，带宽利用率低。

增加frame sequence，用于区分是哪个frame，以及是哪个frame对应的ack。

slideing window：允许同时几个封包，具体数量取决于链路上的sequence number的设定，当表示sequence number的bit为3位，则最多同时发送8个封包，sequence number设定的bit数是可变的。

sliding window size：发送端同时发送可以发送多个封包，而不用停下来等ack的最大的封包的数量。

LAR：最近收到的ack的sequence number

LFS：最后或最近送出去的frame的sequence number

保证LFS与LAR的差值小于SWS（设定的滑动窗口的大小）。

LAR加1，整个窗口也会向右滑动一个栏位，意味着又有一个sequence number可用，可以发送下一个封包了。

每一个发送出去的封包，在发送端都有一个timer，超时未收到相应的ACK将重送

发送端应该有一个buffer，缓存发送出去的frame，大小未发送窗口大小个frame，用于必要时重送相应的frame。万一发送窗口移动，则清除之前缓存的frame，缓存新的发送窗口对应的frame。

LAR=1，当ACK2未收到前，即使ACK3，4，5，6已经收到，滑动视窗也不会移动。

当ACK2收到时，上图的滑动视窗则一次性移动到LAR=6的位置，即从7开始。

最理想的状况是：发送端sliding window填满以后，每发送一个frame，就马上收到一个ack，窗口不停，一直处于移动状态，同理，发送端一直处于发送不同的封包的状态。 当一个封包不在发送视窗之内，则该封包不会被发送。

同理发送视窗，在收端，落在接收视窗之外的封包也不会被接收。

LFR：连续接收到的最后一个封包的sequence number

RWS:同时可接收的封包数/接收窗口的大小。

LAF：当前最大可以接收的序列号

LAF-LFR小于等于RWS

如果到达接收端的封包的序列号不在接收视窗内（不论是左边，还是右边），意味着该封包可能之前已经接收过，因而拒绝接收。

接收端只要正确的接收封包，就会将接收视窗移走，而不去管发送端是否有收到ACK，以及是否正确收到ACK（若发送端未收到ACK，或正确的ACK，则会超时重送）。

在接收视窗内的封包都会被接收，不再接收视窗内的封包一律不收

在2没有收到之前，即使3，4，5，6先收到，接收视窗也不会移动，只有LFR+1=2收到之后，才会一次性移动到最新的LFR的位置。，即6的位置。6以前的统统收到，回送对方，6之前的封包已经成功收到。移动后，会告诉发送端此时的接收窗口是什么样子的。

之前，每发送一个封包就会回送一个ACK的方式，ACK数量过多，消耗较大。采用cumulative ACK的方式，减少ack的数量，提高效率，同时回送ack时会告诉发送端接收端的最新状态。

Cumulative ack sequency number：小于CACK sequence number的封包都已经收到。 CACK=2，说明还在等2，1已经收到。

在2每首收到之前，即使3，4，5，6已经收到，回送发送端的CACK仍然未2，还在等2，接收滑动视窗还不能移动。

即使采用了滑动视窗，每个封包的发送端还是采用了timeout机制。 ACK=7，说明7还没收到，7以前的已经收到。ACK的值，会影响到视窗滑动的时间点。

传统的方式，收到错误的封包就会直接丢弃，也不会ack，一直等到发送端time out才会重发。改进方式是收到错误封包，马上回送NACK，则发送端不必等到timeout之前就可以再次发送。

发送端：理想状况是塞满整个通路：SWS=delay x Bandwidth

接收端：window size = 1时，就是stop and wait的机制，只接受按序发来的frame，提前或延后到达的frame均不被接受，丢弃，也不回ack/nack。发送端最终会timeout，效率低。

为了效率更高一点，可以增加接收视窗，按序收的越多，窗口移动越快，接收窗口大小可以与发送窗口大小相同。将接收窗口做的比发送窗口还大，则没有任何意义。

Sequence number是有限的。因此，这些sequence number就会被重用。sequence number在封包的header中

如何区分相同序列号，但属于不同的封包的情形? 可以用的sequence number必须大于外面同时跑的封包数。例如：sequence number=8，代表在外面同时跑的封包数小于8

Stop and wait:同时在外面跑的封包只有1个，sequence number只有0/1，即sequence number的space为2，满足条件。

假设：MaxSeqNumber=8，RWS=SWS=7

1. 假设sender开始送封包，0~6，7个封包，不用等ack，这7个封包就可以直接发送

2. 接收端收到0~6

3. 接收端回送0~6的ACK，但ACK全部丢失

4. 发送端timeout，并且重发0~6

5. 接收端当正确的收到0~6，并且回送ack时，其接收视窗就会移动，此时接收端期待的sequence number是7，0~5. 这样，发送端重送的封包，0~5就刚好落在接收视窗内部，0~5就会被重复接收，6不被接收。

sender已经发送了编号为0~6的7个封包。

如果接收端没有按序接收，0收到之前，后面的1/2/3/4/5/6即使先收到，out-of-order，接收视窗均不会移动。

当0收到时，则接收视窗会移动。新的接收视窗为7，0~5.

如果接收端回送给发送端的0~6的ACK全部丢失，则发送端会重送0~6.

而此时接收端的视窗已经移走，0~5会被重复接收，6会被丢弃。

这个接收是错误的。

只比MaxSeqNum少1的SWS还不够安全。应该更加苛刻一点，SWS要小于（MaxSeqNum+1）/2

假设2先收到，视窗也不动，只有0收到后，才开始滑动视窗。

0/1/2/3全部收到后，新的接收视窗就会变为4/5/6/7.

假设0/1/2/3的ACK全部丢失，则发送端会timeout，重送，重送的封包统统不会被接收。

如果sender一直不停的重送，接收视窗已经到达下一轮的0/1/2/3怎么办？会不会继续被重复接收？ 不会。 因为，当4/5/6/7接收过程中，每收到0/1/2/3中的任何一个封包，都会回一个cumulative ACK，告诉发送端，正在等4，4以下的0/1/2/3均已被正确接收，发送端只要收到一个这样的ACK，发送端就不会一直不停的发送0/1/2/3.

Receiver通过sliding window RWS，来限制发送端的发送速度，避免发送端的发送速率超过接收端的接收能力。送的太快，sender就会重送，从而使得网络速度降下来。

RWS=1，2，。。。 不同的接收视窗设定，来控制流量的速率