rdt1.0（完全可靠信道）
发送方每次发送一个分组，接受方接受一个分组，数据均是从发送方流向接收方
rdt2.0 （具有比特差错信道的可靠传输）
自动重传协议（ARQ）：打电话：说明白了，对方就ok（ack）；说的不清楚，对方就请再说一遍（nak），此时就再说一遍）
差错检测 接收方反馈 重传
停等协议（stop and wait）：发送方在发送完一次数据后，只有受到ACK才可以接受上层的rdt_send，接着发送写一次数据
**rft2.0的不足之处：**没有考虑ack和nak受损的可能性，处理该问题3个想法如下：
1、发送方就无法辨认的ack和nak发出询问，如是该询问出错，接受方无法辨认这是询问还是新的数据请求，新的困难2、增加检验和比特，在不丢失分组的信道中，发送方可以恢复3、一旦无法判别ack和nak就重传，会造成冗余分组的问题，接收方不知道这是新的还是旧的重传一个简单办法：发送方在数据分组中加一个新字段，将数据分组的序号放在该字段，接收方通过检出序号确定是否重传。针对停等协议，一个比特足够，接收方只需要比较该次和上一次数据分组是否相同。
rdt2.1有从接收方到发送方的肯定确认和否定确认
rdt2.2可以不使用nak，即对上一次数据分组响应两个ack，则发送方同一个数据组收到两个ack，即冗余ack。就知道是该分组后边的分组出现问题了
rdt3.0(具有比特差错的丢包信道的可靠数据传输)
如果发送数据丢失或者ack丢失，发送方都收不到响应。
过一定时间收不到就重传，如果事实上这个数据没有丢失也不必担心，因为rdt2.2中已经对冗余分组做了相应处理，他们会有相同的序号
rdt3.0的问题关键在于停等，流水线可以解决该问题
使用流水线必须增加序号范围，1比特已经不够用了；同时发送方和接收方必须缓存多个分组。
解决流水线问题的2个办法：
1、回退N步（鲜艳的流沙/滑动窗口协议） N：窗口长度 2、选择重传
数据分为0-base 发送成功且受到确认 base：最早的未收到确认的分组的序号
base- nextsequence 未收到确认 nextsequence：最早的未使用序号（下一个待发分组的序号）
nextsequence- base+N-1 下一个发送的分组的序号区间
所以序列号大于等于base+N的序号是不可用的除非未被确认的得到确认
鲜艳的流沙中发送方相应三种事件类型
1、上层的发送调用，上层调用rdt_send，先看发送窗口是否已满，即是否有N个已经发送但未受到相应的分组，若是未满，就可以产生一个分组并发送，否则将数据返回上层，隐式指示窗口已满2、收到一个ack。若是收到的ack序号是N，说明N之前的包括N的分组都被成功接受3、超时时间。正如鲜艳的流沙字面意思，若是用于确认数据丢失的定时器超时，就会回退最多N步，即重传所有已发送但未接受的分组。如果定时器内收到一个ACK，但是还有未被确认的分组，则重启定时器；若是没有了，就直接终止定时器接收方的动作
当按序（上一个接收到的序号为N-1）接收到序号为N的分组，为该分组发送一个ACK。除此之外的所有情况都是丢弃该分组并给上一个成功发送的分组再发一次ACK。
鲜艳的流沙中假设窗口大小为1000且全部发送了，若是第一个丢包了，这1000个都要重传。引出选择重传来解决这个问题：
sr的接收方不管是否按序，只管接受发送方发送过来的分组，若是序号不对，就先缓存（ACK照发），等比该序号小的都发过来一并交付给上层。如果接收方收到很久之前的一个分组（已经发送过ACK）了，也要再发一个ACK，要不然发送方会一直重发这个分组导致发送方窗口不会移动。
sr的发送方窗口内也可能有已经收到ACK的分段，即每个分段维护自己的定时器（使用单个硬件计时器模拟多个计时器）
接受确认：
服务器只管按序累计确认，不管发回的客户收没收到
所以若是服务器收到500的确认后再收到1000的确认，直接更新ybase到1000，因为服务器是累计确认，可以到1000的话必定已经收到500-1000的部分。（三次握手？）
TCP发送方：应用层接受数据，封装到报文段内，报文段有序号。
关于超时类似于sr（多个定时器）。
关于ACK的到来，累计确认（基于鲜艳的流沙），即收到的序号y就代表了y及y之前序号的分组都已得到确认，此时sybase若是小于y-
1，就应该更新了。但是若是序号为n的ack丢失，但是n+1还是可以收到的话，甚至不会重传n，但是gbn会重传n+N。所以tcp是sr与gbn混合体
流量控制：消除发送方使接收方缓存溢出的可能性
保证 LastByteSend-LastByteAcked<=LastByteReceived-LastByteRead
TCP连接步骤：
1、客户端发送syn，syn=1,随即一个初始序号client_isn
2、（服务器发送synack）syn报文段到达服务器，服务器提取syn并分配缓存，并向客户端发送允许连接的报文段（不包含应用层数据），syn=1，首部确认号字段client_isn+1,自己的初始序号为server_isn.即同意建立连接
3、收到syn确认报文，分配缓存空间，同时将server_isn+1放到确认字段中发送确认报文，（可携带应用层数据），同时将syn置为0
TCP关闭步骤：
客户端：FIN=1
服务器：ACK
服务器：FIN=1;
客户端：ACK
拥塞控制：发送方因为ip网络拥塞而被遏制
考虑拥塞控制的话，LastByteSent-LastByteAck<=min(cwnd,rwnd) ,cwnd是拥塞窗口
发送方如何感知链路是否阻塞？ 若是检测到丢包（超时或是收到三个重复的ACK），就是阻塞，一切正常的话就还好
正常的话就慢慢增加发送速率，阻塞就减少，再慢慢加回来
TCP拥塞控制算法
1、 慢启动
2、拥塞避免
3、快速恢复
假设cwnd初始值为MSS,则初始的发送速率为MSS/RTT
，cwnd值每次收到一个确认都会增加一个MSS，成2的指数增长
。结束慢启动三方式：
一旦有丢包事件的发生，发送方就将cwnd置为1。
第二中方式：指数增长同时还有一个状态量，ssthresh，发生阻塞时，将ssrhresh置为当前cwnd的一半，当后边慢启动到达ssthresh时，结束慢启动进入拥塞避免模式
第三种方式：如果监测到3个冗余ACK，进入快速恢复模式
所谓拥塞避免：即到达ssthresh后，每收到一个ACK就将拥塞窗口增加一个（MSS/CWND）个字节，每个RTT全部接受到后增加一个MSS，假设一个RTT发送十个报文段，每个到达ACK将增加1/10个MSS的拥塞窗口长度。即线性增长，每RTT增加一个MSS