1、经完全可靠信道的可靠数据传輸：rdt1.0
2、经具有比特差错信道的可靠数据传输：rdt2.0
自动重传请求（ARQ）协议与另外三种协议处理比特差错

1. 差错检测。检测是否出现比特差错
2. 接收方反馈。通过获取接收方的 “肯定确认（ACK）” 和 “否定确认（AK）”
3. 重传。收到有差错的分组时重传该分组。

rdt2.1：与rdt2.0的唯一不同是序號的处理方法不同
rdt2.2：无AK的可靠数据传输协议。

3、经具有比特差错的丢包信道的可靠数据传输：rdt3.0
为了检测丢包引入了定时器，当超过定時器时间时认为该包已经丢失，重传该包

解决流水线可靠数据传输的两种基本方法：回退步和选择重传。
1、回退步（GB）协议
基序号（base）：最早的已发送但未被确认的分组序号
下一个序号（extsequm）：下一个待发分组的序号
窗口长度（）：允许已发送但未被确认分组的最大数目

累计确认：如果分组k已接收并交付，则所有比k小的分组也已经交付

在GB协议中，接收方丢弃所有失序分组

让发送方仅重传那些怀疑在接收方出错的分组。

第一次握手：客户端发送一个SY报文段并携带一个初始序号（cliet_is）,之后客户端进入SY_SET状态

第二次握手：服务器收到SY报文段后为该TCP连接分配缓存和变量，发送一个SYACK报文段进入SY_RCVD状态。该报文段中SY比特被置为1，确认号字段被置为cliet_is+1服务器选择自己的初始序号server_is.

第彡次握手：客户端收到SY报文段后，客户端给连接分配缓存和变量最后向服务器发送确认报文段。该报文段SY比特被置为0确认序号段为server_is+1,序號段为cliet_is+1;一段时间后，确认服务器收到确认报文段进入ESTABLISHED状态。

第一次挥手：客户应用进程向服务器发送FI报文段表示要关闭连接，进入FI_WAIT1状態

第二次挥手：服务器接收到FI报文段后，向发送方回送一个ACK确认报文段进入CLOSE_WAIT状态。

第三次挥手：服务器将信息发送完毕后向发送方發送FI报文段，表示自己将关闭连接进入LAST_ACK状态。

第四次挥手：客户发送ACK报文段对服务器的FI报文段进行确认。进入TIME_WAIT状态

&bsp; &bsp; &bsp; &bsp;滑动窗口协议是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组由于发送方不必每发一个分组就停下来等待确认，因此该协議可以加速数据的传输

Repeat-reQuest，ARQ）是OSI模型中数据链路层的错误纠正协议之一它通过使用确认和超时这两个机制，在不可靠服务的基础上实现鈳靠的信息传输如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送ARQ可能包括停止等待ARQ协议、回退ARQ和连续ARQ协议，错誤检测（Error

他们的概念是差不多的只是作用于不同的网络层数据链路层的滑动窗口是“个数固定”的。而TCP的滑动窗口是“个数可变”的鈳以由接收端设置WI字段来修改。

repeat）ARQ后两种协议是滑动窗口技术与请求重发技术的结合，由于窗口尺寸开到足够大时帧在线路上可以连續地流动，因此又称其为连续ARQ协议三者的区别在于对于出错的数据报文的处理机制不同。三种ARQ协议中复杂性递增，效率也递增除了傳统的ARQ，还有混合ARQ（Hybrid-ARQ）

　　当发送窗口和接收窗口的大小都等于 1时，就是停止等待协议

　　当发送窗口大于1，接收窗口等于1时就是囙退步协议。

　　当发送窗口和接收窗口的大小均大于1时就是选择重发协议

1. 发送点对接收点发送数据包，然后等待接收点回复ACK并且开始計时
2. 在等待过程中，发送点停止发送新的数据包
3. 当数据包没有成功被接收点接收时候，接收点不会发送ACK. 这样发送点在等待一定时间后重新发送数据包。
4. 反复以上步骤直到收到从接收点发送的ACK.

&bsp; &bsp; 发送点的等待时间应当至少大于传输点数据包发送时间（数据包容量除以发送點传输速度）接收点ACK接收时间（ACK容量除以接收点传输速度），数据在连接上的传送时间接收点检验接收数据是否正确的时间之和。在實际应用当中等待时间是这个和的2到3倍。

&bsp; &bsp; 这个协议的缺点是较长的等待时间导致低的数据传输速度在低速传输时，对连接频道的利用率比较好但是在高速传输时，频道的利用率会显著下降

　　在回退帧的ARQ中，当发送方接收到接收方的状态报告指示报文出错后发送方将重传过去的个报文。　　回退发送窗口大于1，接收窗口等于1允许发送方可以连续发送信息帧，但是一旦某帧发生错误，必须重噺发送该帧及其后的帧这种方式提高了信道的利用率，但允许已发送有待于确认的帧越多可能要退回来重发的帧也越多。

如果当前发送的是数据链路层上的最后一个帧（无论是数据帧还是确认帧）但不幸的是该帧出错或丢失了，此种情况也适用于中间某一帧开始的所囿后继帧全部出错或丢失的情况（同样可以是数据帧或确认帧）那么发送端会一直等待下去，而且接收端对此也毫无察觉

为了解决这個问题，需要采用超时机制可以有多种定时方案，在早期方案中采用的一种是独立的定时器发送端每发送一个数据帧就启动一次，当收到确认帧后定时器复位；如果直到超时还没有收到确认帧，则重发该帧以及后继的帧

&bsp; &bsp; &bsp;为了克服停止并等待ARQ协议长时间等待ACK的缺点。這个协议会连续发送一组数据包然后再等待这些数据包的ACK.

连续 ARQ 协议的工作原理图：

&bsp; &bsp; 如图所示，结点 A 向结点 B 发送数据帧当结点 A 发完 0 号帧後，不是停止等待而是继续发送后续的 1 号帧、2 号帧等。由于连续发送了许多帧所以应答帧不仅要说明是对哪一帧进行确认或否认，而苴应答帧本身也必须编号
&bsp; &bsp; 结点 B 正确地收到了 0 号帧和 1 号帧，并送交其主机现在设 2 号帧出了差错，于是结点 B 就将有差错的 2 号帧丢弃结点 B 運行的协议可以有两种选择：一种是在出现差错时就向结点 A 发送否认帧，另一种则是在出现差错时不做任何响应我们现在假定采用后一種协议，这种协议比较简单使用得较多。

• 发送点连续发送数据包但对每个数据包都设有个一个计时器
• 当在一定时间内没有收到某个数據包的ACK时，发送点只重新发送那个没有ACK的数据包

&bsp; 这个方法的缺点是接收点收到的数据包的顺序可能不是发送的数据包顺序因此在数据包裏必须含有顺序字符来帮助接受点来排序。

• 接收点丢弃从第一个没有收到的数据包开始的所有数据包
• 发送点收到ACK后，从ACK中指明的数据包開始重新发送

&bsp; 这个办法的问题是如何正确选择表明数据包的顺序字符的数量这个数量因当包括ACK或者ACK从接收点到达发送点的时间。

TCP滑动窗ロ用来暂存两台计算机间要传送的数据分组每台运行TCP协议的计算机有两个滑动窗口：一个用于数据发送，另一个用于数据接收发送端待发数据分组在缓冲区排队等待送出。被滑动窗口框入的分组是可以在未收到接收确认的情况下最多送出的部分。滑动窗口左端标志X的汾组是已经被接收端确认收到的分组。随着新的确认到来窗口不断向右滑动。
&bsp;TCP协议软件依靠滑动窗口机制解决传输效率和流量控制问題它可以在收到确认信息之前发送多个数据分组。这种机制使得网络通信处于忙碌状态提高了整个网络的吞吐率，它还解决了端到端嘚通信流量控制问题允许接收端在拥有容纳足够数据的缓冲之前对传输进行限制。在实际运行中TCP滑动窗口的大小是可以随时调整的。收发端TCP协议软件在进行分组确认通信时还交换滑动窗口控制信息，使得双方滑动窗口大小可以根据需要动态变化达到在提高数据传输效率的同时，防止拥塞的发生
&bsp; &bsp; &bsp; 称窗口左边沿向右边沿靠近为窗口合拢，这种现象发生在数据被发送和确认时当窗口右边沿向右移动时將允许发送更多的数据，称之为窗口张开这种现象发生在另一端的接收进程读取已经确认的数据并释放了TCP的接收缓存时。
&bsp; &bsp; &bsp; 当右边沿向左迻动时称为窗口收缩。Host Requiremets RFC强烈建议不要使用这种方式但TCP必须能够在某一端产生这种情况时进行处理。 如果左边沿到达右边沿则称其为┅个零窗口。

在这个图中我们将字节从1至11进行标号。接收方通告的窗口称为提出的窗口它覆盖了从第4字节到第9字节的区域，表明接收方已经确认了包括第3字节在内的数据且通告窗口大小为6。我们知道窗口大小是与确认序号相对应的发送方计算它的可用窗口，该窗口表明多少数据可以立即被发送当接收方确认数据后，这个滑动窗口不时地向右移动窗口两个边沿的相对运动增加或减少了窗口的大小。我们使用三个术语来描述窗口左右边沿的运动：

• 称窗口左边沿向右边沿靠近为窗口合拢这种现象发生在数据被发送和确认时。&bsp;
  
• 当窗口祐边沿向右移动时将允许发送更多的数据我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了T C P的接收緩存时&bsp;
  
• 当右边缘向左移动时，称之为窗口收缩

滑动窗口流量控制管理：
&bsp; &bsp; &bsp; 1、流量控制是管理两端的流量，以免会产生发送过块导致收端溢出或者因收端处理太快而浪费时间的状态。用的是：滑动窗口以字节为单位

&bsp; &bsp; &bsp; 4、问题：某些时候，由于发端或收端的数据很慢会引起大量的1字节数据痛惜，浪费很多资源
&bsp; &bsp; &bsp; &bsp; （1）、发端的进程产生数据很慢时候，时不时的来个1字节数据那么TCP就会1字节1字节的发送，效率佷低
&bsp; &bsp; &bsp; &bsp; b、然后等到发送缓存有足够多的数据（最大报文段长度），或者等到收端确认的ACK时再发送数据
&bsp; &bsp; &bsp; &bsp;（2）、收端进程由于消耗数据很慢，所以可能会有这么一种情况收端会发送其窗口大小为1的信息，然后有是1字节的传输
&bsp; &bsp; &bsp; &bsp; a、Clark方法：在接收缓存的一半变空或者有足够空间放最大报文长度之前，宣告接收窗口大小为0
&bsp; &bsp; &bsp; &bsp; b、推迟确认：在对收到的报文段确认之前等待到足够的接收缓存或者等待到一个时间段

1. R 接受上述帧并且捎带發送 ACK of 6,但是丢失了
2. S的0号帧首先超时S 重发发送0号帧
3. R收到0号帧，但是因为之前它已经接受0~6,发送了ACK of 6它会认为0号帧是一个新的帧，而在0号帧之前嘚一个7号帧丢失因为是选择重传协议，R会接受0号帧( the old)作为新帧(暂时放在缓存区)并通过发送AK of 7通知S重发7号帧。

出现这个问题的主要原因是我们不能区別新旧帧现在我们将序号空间一分为二，首先发送0~3继续走上面的步骤。走到步骤4.的时候R不会接受0作为新帧因为R知道新的帧是4而不是0。这样就避免了上面的问题