运输层---可靠传输

• 前面讲到链路层的时候，讲到它不可靠，只进行差错检错，检错的是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的重传是自动进行的。
• 优点： 简单
• 缺点： 信道利用率太低

信道利用率：

• 其中 T_D是传输时延。很多时间都用在等待上了，因此信道利用率很低。
• 问题: 为什么是T_D/总时间呢？？？？

二、流水线传输----连续ARQ协议

• 为解决ARQ信道利用率的问题
• 流水线传输就是发送方可连续发送多个分组，不必每发送一分组就等待对方的确认。大大提高了信道利用率。

工作原理

• 窗口是接收方对发送方的约束，约束发送方一次只能发送多少个分组
  

累计确认

• 接收方一般采用累计确认的方式，即不必对收到的分组逐个发送确认，而是对按序列到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。
• 优点： 容易实现，及时确认丢失迟到也不必重传
• 缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息 （比如说发送方发送了100个分组，除了第3个分组之外，其他分组都成功的到达了接收方，那么接收方只告诉发送方前面两个分组到达了（确认号是3，表示期望下一次收到序号是3的分组），无法反映后面97个分组成功到达的情况。因此发送方会误认为只有前面两个分组到达了，于是就会再重新发送3-100个分组，十分浪费。） （当然这个问题可以用选择确认SACK解决）
  • Go-back-N(回退N)，表示需要再退回来重传已发送过的N个分组 （3-100）
• 修正方案：选择确认SACK:
  • 接收方收到一串不连续的序号字节，发回确认就告诉接收方不连续块和连续快的边界信息。
  • 在TCP首部中的可选部分加上“允许SACK”选项，而双方必须事先约定好
  • 由于首部的可选部分长度最多只有40字节，而指明一个边界就要用掉4字节（序号的范围是4字节），一个块就要用掉8个字节，因此最多只能指明4个字节块的边界信息（不能把40个字节全占掉）。

TCP可靠传输的具体实现

• TCP连接的每一端都必须设有两个窗口—一个发送窗口和一个接收窗口（因为是全双工）。两个端口经常处于动态变化之中
• TCP的可靠传输机制用字节的序号进行控制。TCP所有的确都是基于序号而不是基于报文字段
• TCP连接的往返时间RTT也不是固定不变的。需要用特定算法来估计得出最合理的重传时间。
  
  一、发送缓存
• 发送方的应用进程把字节流写入TCP发送缓存
• 发送窗口通常只是发送方的一部分
• 已发送但未收到的要先保存，有可能需要重传（紫色部分）
  

二、接收缓存

• 接收方的应用进程从TCP的接收缓存中读取字节流
• 接收到的字节可以从缓存中删去（紫色部分）
  
  三、需强调的三点

1. A发送的窗口并不总是和B接收的窗口一样大(因为有一定的时间滞后，滞后咋就不不一样大了？？？？)
2. TCP标志没有规定对不按序号到达的数据如何处理。通常是先存放在缓存中等待确实字节到达。
3. TCP要求接收方必须有累计确认的功能（注意：累计确容易产生Go-Back-N），这样可以减小传输开销

四、接收方发送确认

• 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时，顺便捎带上确认一起发送。但也需要注意两点：
  1. 接收方不应过分推迟发送确，否则会导致发送方不必要的重传。（太迟不发确认，发送方发送窗口里的已经全部发送了，接收方等待时间上限会重发数据。）
  2. 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据

五、超时重传时间RTO如何选择