TCP基础全面学习

TCP基础–详细笔记

TCP/IP协议簇：以tcp和ip为代表的通信时所必须用到的协议群的统称。

具体来说，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都属于 TCP/IP 协议。

TCP简介

TCP/IP 中有两个具有代表性的传输层协议，分别是 TCP 和 UDP。

TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构，当应用程序采用 TCP 发送消息时，虽然数据分段，但还是犹如没有任何间隔的数据流发送给接收端。TCP 为提供可靠性传输，实行“顺序控制”或“重发控制”机制。此外还具备**“流控制（流量控制）”、“拥塞控制”、提高网络利用率**等众多功能。

tcp连接流程

tcp首部结构

• 序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

• 确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

• 确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

• 同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

• 终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

  PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

三次握手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

Q:为什么是三次握手?
A：因为二次握手达不到要求，客户端作为主动发起者，只要有返回确认，确实就可以建立连接开始通信，而服务器端接收到请求并发回确认包，发出确认包后，确认包有可能丢失，如果丢失，客户端未接收到第二次握手的确认包，而服务器端已经开始工作了。

四次挥手

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态，结束TCP连接的时间要比客户端早一些。

• 多一次挥手是为了等待服务器发送完毕，客户端接收完毕。
• 2MSL表示报文在信道中一次传输时间*2

重传机制

由于TCP的下层网络（IP）可能出现丢失、重复或失序的情况，TCP协议提供可靠数据传输服务。为保证数据传输的正确性，TCP会重传其认为已丢失（包括报文中的比特错误）的包。TCP使用两套独立的机制来完成重传，一是基于时间，二是基于确认信息的构成。

超时重传

超时重传机制用来保证TCP传输的可靠性。每次发送数据包时，发送的数据报都有seq号，接收端收到数据后，会回复ack进行确认，表示某一seq号数据已经收到。发送方在发送了某个seq包后，等待一段时间，如果没有收到对应的ack回复，就会认为报文丢失，会重传这个数据包。

决定报文是否有必要重传的主要机制是重传计时器（retransmission timer），它的主要功能是维护重传超时（RTO）值。TCP每发送一个报文段，就对此报文段设置一个超时重传计时器。.

超时重传时间RTO（Retransmission Time－Out）应当略大于TCP报文段的平均往返时延RTT，一般可取RTO＝2RTT。

另：除了重传计时器，还有另外三种计时器，记在记在 附1。

快速重传

快速重传机制要求当接收到失序报文段时，TCP需要立即生成确认信息（重复ACK），并且失序情况表明在后续数据到达前出现了丢包，发送端的工作即为尽快填补丢包带来的数据段空缺。
　　
TCP发送端等待一定数目的重复ACK（称为重复ACK阈值或dupthresh），来决定数据是否丢失并触发快速重传。通常这个阙值为常量3，但也有一些协议实现可基于当前的失序程度动态调节该值。

TCP 触发快速重传后,期间发送的报文会继续传吗，还是接收方有保留?
暂时考虑是会继续传，因为每个发送必须有应答，而期间的报文都以重复的ACK应答了，后续不可能主动又去发送应答。[参考 [附2](#2_TCP__229)]

P.S. 这个问题应该结合窗口控制来看，理解了窗口控制，或者一应一答就不存在这个问题了

窗口控制

以1个段为单位,每发一个段进行一次确认应答的处理，这样的传输方式有一个缺点，那就是包的往返时间越长通信性能就越低。

为解决这个问题,TCP引入了窗口这个概念。即使在往返时间较长的情况下,它也能控制网络性能的下降。确认应答不再是以每个分段,而是以更大的单位进行确认时,转发时间将会被大幅度的缩短。也就是说,发送端主机,在发送了一个段以后不必要一直等待确认应答,而是继续发送。

滑动窗口控制

使用三个术语来描述窗口左右边沿的运动：

• 窗口合拢：窗口左边沿向右边沿靠近。对于发送端来说，接收到最左边的ACK时可以合拢；对于接收端来说，接收到最左边的数据段时发出ACK后可以合拢（未读取）。
• 窗口张开：当窗口右边沿向右移动。对于发送端来说，合拢之后需要加载数据时可以扩张；对于接收端来说，发出ACK并读取数据缓存后可以扩张
• 窗口收缩:当右边沿向左移动.不提倡，略。

TCP的窗口控制

TCP的窗口传输协议结合了GBN和SR两种经典策略，记在 附3。
对于数据沟通来说，分为发送端和接收端，二者各自维护了一个窗口：
对于发送端来说：窗口内的数据可以一次全部发送出去而不用等待ack的到来，采用确认积累，窗口会向已确认的最左端滑动；
对于接收端来说：窗口内顺序接收数据，相当于窗口大小为1。（具体细节存疑，有很多人说是积累满一个窗口然后发一个ACK，但是这样和快速重传矛盾）

例：

正常情况：

初始：
发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 3 4】 5 6 7 8 9 10 11

发送端依次发送2、3、4，全部成功抵达。
接收端接收2、3、4，依次返回确认ACK，ack=3，4，5，窗口依次滑动到【5 6 7】：

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 2 3 4 【5 6 7】 8 9 10 11

发送端接收到ACK，发生窗口滑动:

发送端 1 2 3 4 【5 6 7】 8 9 10 11
接收端 1 2 3 4 【5 6 7】 8 9 10 11

异常情况情况：

初始：
发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 3 4】 5 6 7 8 9 10 11

发送端依次发送2、3、4，其中2丢失。接收端接收3、4，但是接收端需要的是2，返回两个确认ACK，ack=2

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 3 4】 5 6 7 8 9 10 11

发送端接收到两个重复ACK，等待然后三个包依次超时，触发重传，再次发送2、3、4，这次是4丢失
接收端依次收到2、3，返回确认ACK，ack=4，发生窗口滑动

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 2 3 【4 5 6】 7 8 9 10 11

虽然4丢失了，但是发送端接收到了ACK，ack=3,4，发生窗口滑动，并发出5 ,6 :

发送端 1 2 3 【4 5 6】 7 8 9 10 11
接收端 1 2 3 【4 5 6】 7 8 9 10 11

发送端发现4号包超时没有得到确认，触发超时重传，或者没超时的时候收到了接收端的两次ack=4的确认报文，触发快速重传:

窗口与重传机制

在使用窗口控制中,如果出现段丢失该怎么办?

确认积累

一般地讲，如果发送方发了包1，包2，包3；接受方成功收到包1，包2，包3。那么接受方依次返回三个确认ACK；
但这个时候如果ack=1 和 ack = 2的确认包丢失了，那么发送方接收到ack=3的包也可以视为包1，包2，包3都得到了确认，因为接收方没有接收到1、2是不会发出3的确认的。

确认积累机制加上基本的重传机制就可以解决了

窗口大小

控制窗口大小是流量控制的一个手段，窗口越大吞吐量越大，对于发送方和接收端来说，窗口大小相差过大会造成溢出或者浪费。窗口大小影响流量控制和拥塞控制，放在下一节讨论。

流量控制

双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里（失序的数据包也会被存放在缓存区里）。

如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源，因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

对发送方发送速率的控制，称之为流量控制。

利用窗口控制流量大小

在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方的发送窗口大小,即接收窗口rwnd(接收方设置确认报文段的窗口字段来将rwnd通知给发送方),发送方的发送窗口取决于接收窗口rwnd和拥塞窗口cwnd的最小值

具体操作是,接收端主机向发送端主机通知自己可以接收数据的大小,于是发送端会发送不超过这个限度的数据。该大小限度就被称作窗口大小。在前一节所介绍的窗口大小的值就是由接收端主机决定的。（其实拥塞窗口也决定）

控制接收方的窗口大小，发送方发送的数据小于等接收方tcp首部的窗口大小规定，当该值为0，暂停发送。大概逻辑应该就这么简单，看到网上其他文章，有说什么又分发送端和接收端窗口的，而tcp/ip详解和图解tcp/ip这样的书里没发现这样的概念，而tcp首部也只有一个16bit的窗口大小字段，实际上窗口大小相关控制都是利用这个字段控制了，所以感觉发送端和接收端窗口这种概念属于生造。

拥塞控制

拥塞控制与流量控制的区分

接收窗口接收方根据接受缓存设置的值,并告知给发送方,反映接收方容量
拥塞窗口发送方根据自己估算的网络拥塞程度而设置的窗口值,反映网络当前容量
在发送数据包时,将拥塞窗口的大小与接收端主机通知的窗口大小做比较,然后按照它们当中较小那个值,发送比其还要小的数据量。
发送窗口=Min{接收窗口rwnd,拥塞窗口cwnd}

网络拥塞的判定

慢开始

1. 拥塞窗口初始值为1MSS，每轮传输*2，所以一开始是指数增长
2. 增长超过ssthresh时切换至加法增长
3. 出现网络拥塞时，更新ssthresh为当前拥塞窗口大小的1/2，并且将拥塞窗口大小置1MSS
4. 重复上述流程

慢开始+快重传快恢复

1. 拥塞窗口初始值为1MSS，每轮传输*2，所以一开始是指数增长
2. 增长超过ssthresh时切换至加法增长
3. 出现3个ACK说明有丢包现象，证明可能网络拥塞，更新ssthresh为当前拥塞窗口大小的1/2，并且将拥塞窗口大小置为新ssthresh值
4. 加法增长
5. 重复3

提高网络利用率

Nagle算法

TCP中为了提高网络的利用率,经常使用一个叫做 Nagle的算法。该算法是指发送端即使还有应该发送的数据,但如果这部分数据很少的话,则进行延迟发送的一种处理机制。具体来说,就是仅在下列任意一种条件下才能发送数据。如果两个条件都不满足,那么暂时等待一段时间以后再进行数据发送。
·已发送的数据都已经收到确认应答时
·可以发送最大段长度(MSS)的数据时
根据这个算法虽然网络利用率可以提高,但是可能会发生某种程度的延迟。
为此,在窗口系统’以及机械控制等领域中使用TCP时,往往会关闭对该算法的启用。

延迟确认应答

接收数据的主机如果每次都立刻回复确认应答的话,可能会返回一个较小的窗口。那是因为刚接收完数据,缓冲区已满。当某个接收端收到这个小窗口的通知以后,会以它为上限发送数据,从而又
降低了网络的利用率。
为此,引入了一个方法,那就是收到数据以后并不立即返回确认应答,而是延迟一段时间的机制。
·在没有收到2×最大段长度的数据为止不做确认应答(根据操作系统的不同,有时也有不论数据大小,只要收到两个包就即刻返回确认应答的情况。)
·其他情况下,最大延迟0.5秒发送确认应答(很多操作系统设置为0.2秒左右)
事实上,大可不必为每一个数据段都进行一次确认应答。TCP采用滑动窗口的控制机制,因此通常确认应答少一些也无妨。TCP文件传输中,绝大多数是每两个数据段返回一次确认应答。

捎带应答

TCP的确认应答（作为接收方）和回执数据（作为发送方下一条数据）都通过一个包发送，这种方
式叫做捎带应答( Piggy Back Acknowledgement)。通过这种机制,可以使收发的数据量减少。

另外,接收数据以后如果需要立刻返回确认应答,就无法实现捎带应答。要实现捎带应答，必须等待应用处理生成返回数据以后，再进行发送请求为止,必须一直等待确认应答的发送。也就是说,如果没有启用延迟确认应答就无法实现捎带应答。

附

1.四种定时器

1 重传计时器（retransmission timer）：当TCP发送报文段时，就创建该特定报文段的重传计时器。可能发生两种情况：
A： 若在计时器截止时间到（通常是60秒）之前收到了对此特定报文段的确认，则撤销此计时器。
B： 若在收到了对此特定报文段的确认之前计时器截止期到，则重传此报文段，并将计时器复位。

2： 坚持计时器（persist timer ） ：为了对付零窗口大小通知，TCP需要另一个计时器。
假定接收TCP宣布了窗口大小为零。发送TCP就停止传送报文段，直到接收TCP发送确认并宣布一个非零的窗口大小。但这个确认可能会丢失。
我们知道在TCP中，对确认是不需要发送确认的。若确认丢失了，接收TCP并不知道，而是会认为它已经完成任务了，并等待着发送TCP接着会发送更多的报文段。但发送TCP由于没有收到确认，就等待对方发送确认来通知窗口的大小。双方的TCP都在永远地等待着对方。
要打开这种死锁，TCP为每一个连接使用一个坚持计时器。当发送TCP收到一个窗口大小为零的确认时，就启动坚持计时器。当坚持计时器期限到时，发送TCP就发送一个特殊的报文段，叫做探测报文段。这个报文段只有一个字节的数据。它有一个序号，但它的序号永远不需要确认；甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒对端：确认已丢失，必须重传。
坚持计时器的值设置为重传时间的数值。但是，若没有收到从接收端来的响应，则需发送另一个探测报文段，并将坚持计时器的值加倍和复位。发送端继续发送探测报文段，将坚持计时器设定的值加倍和复位，直到这个值增大到门限值（通常是60秒）为止。在这以后，发送端每隔60秒就发送一个探测报文段，直到窗口重新打开。

3： 保活计时器（keepalive timer ） ：保活计时器使用在某些实现中，用来防止在两个TCP之间的连接出现长时期的空闲。
假定客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远地处理打开状态。
要解决这种问题，在大多数的实现中都是使服务器设置保活计时器。每当服务器收到客户的信息，就将计时器复位。
保活计时器通常设置为2小时。若服务器过了2小时还没有收到客户的信息，它就发送探测报文段。
若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。

4： 时间等待计时器（2MSL timer ）：时间等待计时器是在连接终止期间使用的。
当TCP关闭一个连接时，它并不认为这个连接马上就真正地关闭了。
在时间等待期间中，连接还处于一种中间过渡状态。
这就可以使重复的FIN报文段（如果有的话）可以到达目的站因而可将其丢弃。
这个计时器的值通常设置为一个报文段的寿命期待值的两倍。

2. (知乎问答)TCP 快速重传那些事

知乎提问：
TCP 快速重传重传几个的数据包呢？
触发快速重传后，会只重传丢失的那一个，还是重传到目前发送的为止？
例如连续返送SYN 1 SYN 51 SYN 101 SYN 151 SYN 201 SYN 251
SYN 1 到SYN 251 6个 50字节长度的数据包
但连续收3次到ACK 101， 这时候快速重传是只重传 （SYN101 长度50）的数据包么？还是重传一次（SYN 101 长度200）？还是三次长度为50的数据包呢？如果是只重传1个准确的丢失记录，TCP是如何记录知道丢失数据包的长度的呢？

答主车小胖的回答：
一句话概括：接收方的确认号（Acknowledge Number）是N，那么发送方就发序列号（Sequence Number）为N（起始）的M字节。

具体这个M字节上限是多少，由双方协商的MSS(Maximum Segment Size)决定，如果发送方待发送的字节数< MSS，那就有多少算多少！

当然上文的M字节的上限不仅仅取决于MSS，还要受到SACK、Scaling Window、Timestamp 等Option的制约，因为这些字段同样要消耗集装箱（MSS）的空间。

题主的问题有很多不恰当的描述，比如SYN只有TCP握手才有，另外一个报文不可能连续发送50字节数。这种问题放在知乎平台很难获得青睐，但是我还是觉得这样的问题会困扰很大的人群，他们主要不理解为何要快速重传？

为了让读者更好理解，还是用最浅显的语言描述。Alice为发送方，Bob为接收方。

为何Bob连续给Alice发送四次ACK 101?

首先字节流1-100已经按序到达Bob的仓库，所以触发Bob弹出第一个ACK 101。

那么剩下的三次多余的Duplicated ACK 101，是什么事件触发Bob弹出的呢？

是接收到字节流101-151(第三个包裹)触发的吗？很显然不是，如果是，Bob应该弹出ACK 152才对。

既然101-151Bob没有收到，有两种情况可能发生：

字节101-151丢了
乱序了，101-151依然逗留在网络中，后续的报文反而先到达

无论是什么情况发生，都会造成字节流101-151之后的包裹，被堆积在仓库里，无法提交给应用程序。

TCP有一个神圣的、严格的使命，一定要将字节流按序提交给应用程序，且字节流需要连续，不能出现不连续，比如这里的101-151没有到达，但是152-251却到达了，那么整个字节流在Bob看来是这样的：

1-100，152-201

其中关键的一段101-151空缺，有读者可能会很好奇，为何152-201在这里已经到达Bob的仓库呢，从哪里看出来的？

从三次Duplicated ACK 101看出来的，一次ACK 101就代表Bob收到一个包裹，否则Bob无缘无故会弹射出ACK101,吃饱撑的？

这三个包裹分别为：编号为3的包裹（151-200）、编号为4的包裹（201-250）、编号为5的包裹（251-300）。

Alice通过收到连续收到三次Duplicated ACK，快速判断出包裹2可能丢了，需要赶快修复，否则后果很严重，于是没有一丝一毫的延迟，立马将包裹2（字节流101-151）从重传队列弹射出去。

3.经典窗口控制协议模型

GBN协议（后退N帧协议）

发送方窗口大小>1,接收方窗口=1
发送方：GBN协议中采用累积确认的方式,标明接收方已经收到n号帧和它之前的全部帧。
如果出现超时,发送方重传所有己发送但未被确认的帧。

接收方：如果正确收到n号帧,并且按序,那么接收方为n帧发送并将该帧中
的数据部分交付给上层。其余情况都丢弃帧,并为最近按序接收的帧重新发送ACK。接收方无需缓存任
何失序帧,只需要维护一个信息: expectedseqnum(下一个按序接收的帧序号)

例：

正常情况：

初始：
发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 】3 4 5 6 7 8 9 10 11

发送端依次发送2、3、4，全部成功抵达。
接收端接收2、3、4，依次返回确认ACK，并发生窗口滑动，滑动经过3、4到达5：

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 2 3 4【5】6 7 8 9 10 11

发送端接收到ACK，发生窗口滑动:

发送端 1 2 3 4 【5 6 7】 8 9 10 11
接收端 1 2 3 4【5】6 7 8 9 10 11

异常情况情况：

初始：
发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 】3 4 5 6 7 8 9 10 11

发送端依次发送2、3、4，其中2丢失。接收端接收3、4，但是接收端需要的是2，返回两个确认ACK，ack=2

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 】3 4 5 6 7 8 9 10 11

发送端接收到两个重复ACK，然后等待超时，触发重传，依次发送2、3、4，这次是4丢失
接收端依次收到2、3，依次返回确认ACK，发生窗口滑动，到达4

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 2 3 【4】 5 6 7 8 9 10 11

发送端接收到ACK，发生窗口滑动:

发送端 1 2 3 【4 5 6】 7 8 9 10 11
接收端 1 2 3 【4】 5 6 7 8 9 10 11

SR协议

发送方窗口大小>1,接收方>1
SR接收方将确认一个正确接收的帧而不管其是否按序。失序的帧将被缓存,并返回给发送方一个该帧的确认帧【收谁确认谁】,直到所有帧(即序号更小的帧)皆被收到为止,这时才可以将一批帧按序交付给上层,然后向前移动滑动窗口

对于发送方：如果收到AcK,加入该帧序号在窗口内,则5R发送方将那个被确认的帧标记为已接收。如果该帧序号是窗口的下界(最左边第一个窗口对应的序号),则窗口向前移动到具有最小序号的未确认帧处。如果窗口移动了并且有序号在窗口内的未发送帧,则发送这些帧。
对于接收方：SR接收方将确认一个正确接收的帧而不管其是否按序。失序的帧将被缓存,并返回给发送方一个该帧的确认帧【收谁确认谁】,直到所有帧(即序号更小的帧)皆被收到为止。,这时才可以将一批帧按序交付给上层,然后向前移动滑动窗口
丢失：每个帧都有自己的定时器,一个超时事件发生后只重传一个帧。

例：

正常情况：

初始：
发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 3 4】 5 6 7 8 9 10 11

发送端依次发送2、3、4，全部成功抵达。
接收端接收2、3、4，依次返回确认ACK，并发生窗口滑动：

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 2 3 4 【5 6 7】 8 9 10 11

发送端接收到ACK ack=5，窗口滑动到5:

发送端 1 2 3 4 【5 6 7】 8 9 10 11
接收端 1 2 3 4 【5 6 7】 8 9 10 11

异常情况情况：

初始：
发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 3 4】 5 6 7 8 9 10 11

发送端依次发送2、3、4，其中2丢失。接收端接收3、4，依次返回两个确认ACK，由于2未接收到，窗口不能动

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 【2 3 4】 5 6 7 8 9 10 11

发送端接收到3和4的ACK，由于未接收到2的ACK，窗口不能动，然后2号数据段等待超时，触发重传，发送2
接收端依次收到2，返回确认ACK，ack=5，接收端可滑动至5

发送端 1 【2 3 4】 5 6 7 8 9 10 11
接收端 1 2 3 4 【5 6 7】 8 9 10 11

发送端接收到ACK ack=2，发生窗口滑动:

发送端 1 2 3 4 【5 6 7】 8 9 10 11
接收端 1 2 3 4 【5 6 7】 8 9 10 11

回到开头