- 前面讲到链路层的时候，讲到它不可靠，只进行差错检错，检错的是MAC帧。 讲到网络层的时候，尽最大努力交付，不保证可靠传输。 下层都在逃避这个问题，但问题终究是无法逃避的，最终可靠传世的重任落在了运输层上。
TCP 的可靠传输
一、完全理想化的可靠传输
- 假设1：链路是理想的传输信道，所传输的数据既不会出错，也不会丢失。
- 假设2：无论发送方以多快的速率发送数据，接收方总是来得及收下，并及时上交主机（流量控制问题）。
- 但实际上这两种假设都是不可能实现的。
二、停止等待协议ARQ
- “停止等待”就是每发送完一个分组就停止发送，等待对方的确认（没有确认就
重传）。在收到确认后在发送下一个分组 - 全双工通信的双发即是发送方也是接收方。（这里为了讨论问题方便，我们仅考虑A发送数据而B接受数据并发送确认。因此
A叫做发送方，B叫做接收方） - A向B发送数据后，若B收到了经过差错检测发现数据错了，就会将数据丢弃。A等待一段时间后就会重发一次数据（超时重传，这个时间怎么定在后面会讲）。
错误的几种可能:
1. 发送的数据丢失了或迟到了
2. 发送的数据错了
3. B发回的确认丢失了或迟到了
4. 确认报丢失了
5. 四种情况结果都一样，A等一段时间只要没收到B的确认帧就会超时重传- 使用上述的确认和重传机制称为
自动重传ARQ,意思是B不需要请求A重传，A的重传是自动进行的。 优点： 简单缺点： 信道利用率太低
信道利用率：
- 其中 TD是传输时延。很多时间都用在等待上了，因此信道利用率很低。
- 问题: 为什么是TD/总时间呢？？？？
二、流水线传输----连续ARQ协议
- 为解决ARQ信道利用率的问题
- 流水线传输就是发送方可连续发送多个分组，不必每发送一分组就等待对方的确认。大大提高了信道利用率。
工作原理
窗口是接收方对发送方的约束，约束发送方一次只能发送多少个分组
累计确认
- 接收方一般采用
累计确认的方式，即不必对收到的分组逐个发送确认，而是对按序列到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。 优点：容易实现，及时确认丢失迟到也不必重传缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息 （比如说发送方发送了100个分组，除了第3个分组之外，其他分组都成功的到达了接收方，那么接收方只告诉发送方前面两个分组到达了（确认号是3，表示期望下一次收到序号是3的分组），无法反映后面97个分组成功到达的情况。因此发送方会误认为只有前面两个分组到达了，于是就会再重新发送3-100个分组，十分浪费。） （当然这个问题可以用选择确认SACK解决）- Go-back-N(
回退N)，表示需要再退回来重传已发送过的N个分组 （3-100）
- Go-back-N(
修正方案：选择确认SACK:- 接收方收到一串不连续的序号字节，发回确认就告诉接收方不连续块和连续快的边界信息。
- 在TCP首部中的可选部分加上“
允许SACK”选项，而双方必须事先约定好 - 由于首部的可选部分长度最多只有40字节，而指明一个边界就要用掉4字节（序号的范围是4字节），一个块就要用掉8个字节，因此最多只能指明4个字节块的边界信息（不能把40个字节全占掉）。
TCP可靠传输的具体实现
- TCP连接的每一端都必须设有两个窗口—一个
发送窗口和一个接收窗口（因为是全双工）。两个端口经常处于动态变化之中 - TCP的可靠传输机制用
字节的序号进行控制。TCP所有的确都是基于序号而不是基于报文字段 - TCP连接的往返时间RTT也不是固定不变的。需要用特定算法来估计得出最合理的重传时间。
一、发送缓存 - 发送方的应用进程把字节流写入TCP发送缓存
- 发送窗口通常只是发送方的一部分
- 已发送但未收到的要先保存，有可能需要重传（紫色部分）
二、接收缓存
- 接收方的应用进程从TCP的接收缓存中读取字节流
- 接收到的字节可以从缓存中删去（紫色部分）
三、需强调的三点
- A发送的窗口并不总是和B接收的窗口一样大(因为有一定的时间滞后，滞后咋就不不一样大了？？？？)
- TCP标志没有规定对不按序号到达的数据如何处理。通常是先存放在缓存中等待确实字节到达。
- TCP要求接收方必须有
累计确认的功能（注意：累计确容易产生Go-Back-N），这样可以减小传输开销
四、接收方发送确认
- 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时，顺便捎带上确认一起发送。但也需要注意两点：
- 接收方不应过分推迟发送确，否则会导致发送方不必要的重传。（太迟不发确认，发送方发送窗口里的已经全部发送了，接收方等待时间上限会重发数据。）
- 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据
五、超时重传时间RTO如何选择
