【计算机网络系列】TCP 实现可靠传输的方式

我会带着你远行 2023-01-05 12:55 172阅读 0赞

# TCP 可靠传输实现 #

*  简单的把停等协议或连续ARQ 协议等可靠通信原理照搬到真实的TCP 运行环境并不适合。
 *  在TCP 中，每个连接的两端都各两个窗口：一个**发送窗口和一个接收窗口**。
 *  TCP 为其传输的**每个字节都编制一个序号**，并以此为基础构建可靠传输。同样，TCP 的确认也都是**基于（字节）序号而不是报文序号**。
 *  TCP 连接的**往返时间 RTT 也不是固定**不变的。需要使用特定的算法**估算较为合理的重传时间**。

## 字节为单位窗口 ##

*  滑动窗口用于
    
     *  差错控制：控制 “ 连续 ARQ” 的参数
     *  流量控制：控制发送报文的速率
 *  TCP 滑动窗口的特点之一：面向字节流
    
     *  以字节为单位进行控制
 *  TCP 报文首部中的窗口字段即为接收方可允许发送方可以发送的字节数，以约束发送方的发送量。
    
     *  发送方根据接收方给出的窗口值，构造自己的发送窗口尺寸。通常不大于对方的窗口值。

发送窗口结构与参数

![image-20210104172104935][]

*  P1：指向窗口后沿（已发送、未被确认的最小序号的字节），对方期望收到的序号
 *  P2：指向允许发送的最小序号的字节
 *  P3：指向窗口前沿（不许发送的最小序号的字节），P3=P1+窗口值，(P3 – P1 = 发送窗口,又称为通知窗口)
 *  P2 – P1 = 已发送但尚未收到确认的字节数
 *  P3 – P2 = 允许发送但尚未发送的字节数（可用窗口大小）
 *  注意：发送窗口内的序号都已用完，但还没有收到确认，必须停止发送。

接收窗口

*  TCP 标准没有规定对不按序到达的数据如何处理。
 *  通常的方法：
    
     *  先临时存放在接收窗口中，等收到字节流中所缺少的字节后，再一并交付上层应用程序。
 *  因此，接收窗口大小不为1 （通常，与发送窗口一样大）

接收和发送窗口比较

![image-20210104174043364][]

发送窗口的调整

*  可用窗口大小、发送窗口的移动：根据连续ARQ 的要求调整
 *  发送窗口大小：根据流量控制（接收方的接收窗口）调整
 *  规则：接收窗口控制发送窗口大小的变动

窗口移动

*  结论
    
     *  确认号不可能减小
     *  确认号增加K1 ：窗口 后沿前移K1、窗口 前沿前移K1
     *  窗口值增加K2 ：窗口 前沿前移K2
     *  窗口值减小K2 ：窗口 前沿收缩K2
 *  可以表示为
    
     *  确认号增加K1 且窗口值增加K2（K1≥0 ，K2 可以正负，K1<K2 ）：
        
         *  窗口后沿前移K1
         *  窗口前沿前移(K1+K2)
 *  TCP 标准强烈不赞成发送窗口前沿向后收缩

缓存与接收缓存的作用

*  发送缓存用来暂时存放：
    
     *  发送应用程序传送给发送方 TCP 准备发送的数据；
     *  TCP 已发送出但尚未收到确认的数据。
 *  接收缓存用来暂时存放：
    
     *  按序到达的、但尚未被接收应用程序读取的数据；
     *  不按序到达的数据。

另外

*  发送窗口并不总是和对应的接收窗口一样大（因为有一定的时间滞后）。
 *  TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
 *  TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销。

## 超时重传时间 ##

*  重传机制是TCP中最重要和最复杂的问题之一，也是TCP可靠传输的基石。
 *  TCP 每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。
 *  超时重传时间（RetransmissionTime-Out，RTO）的确定对TCP的性能有重大影响。
 *  往返时间（Round Trip Time，RTT）是确定超时重传时间的最重要的基础。
 *  在真实网络环境中，RTT的测量是有非常大的不确定性。

RTT在报文重传过程中的重要性

*  测量准确的RTT 对于确定更加适合的RTO 具有重要影响。在TCP 中，如果：
    
     *  RTO 小于 RTT ，则会造成很多不必要的重传；
     *  RTO 远大于 RTT ，则会降低整体网络利用率。
 *  在TCP 中，不同连接的RTT 不相同，同一个连接不同时间的 RTT

加权平均往返时间

*  RTT 是一个不断动态调整的测量值，每个连接都有与其他连接不同的RTT ，而且在不同时候，同一连接的RTT
 *  TCP用一个称为加权平均往返时间  R T T S RTT\_S RTTS （也称为平滑往返时间）的参数反映往返时间。
 *  TCP 中  R T T S RTT\_S RTTS 的计算方法：
    
     *  若是第一次测量到RTT样本，则 R T T S RTT\_S RTTS 值就取为所测量到的 RTT 样本值；否则，  R T T S RTT\_S RTTS ：
        
         *  新 R T T S RTT\_S RTTS = (1 - a) \* (旧  R T T S RTT\_S RTTS) + a \* (新的  R T T S RTT\_S RTTS 样本)
         *  式中，0 <= a <= 1。若 a 更接近于零，表示 RTT 值更新较慢。若选择 a 更接近于 1，则表示 RTT 值更新较快。

超时重传时间

*  一般说来，RTO 应略大于 R T T S RTT\_S RTTS
 *  RFC 2988 建议使用下式计算 RTO：RTO =  R T T S RTT\_S RTTS \+ 4 \*  R T T D RTT\_D RTTD
    
     *   R T T D RTT\_D RTTD 是 RTT 的偏差加权平均值。
 *  RFC 2988 建议的  R T T D RTT\_D RTTD计算方法：
    
     *  若是第一次测量，  R T T D RTT\_D RTTD 值取为测量到的 RTT 样本值的一半；
     *  否则，则  R T T D RTT\_D RTTD 使用下式计算：新 R T T D RTT\_D RTTD = (1 - b ) \* (旧  R T T D RTT\_D RTTD ) + b \* | R T T S RTT\_S RTTS \- 新RTT样本|
        
         *  b 是个小于 1 的系数，其推荐值是 1/4，即 0.25。

RTT 测量的复杂性和困难

*  TCP 报文段 1 没有收到确认。重传（即报文段 2）后，收到了确认报文段 ACK。
 *  如何判定此确认报文段是对原来的报文段 1 的确认，还是对重传的报文段 2 的确认？

Karn 算法及修正

*  当超时和重传发生时，因为无法确定确认报文对应是哪个数据报文，因此Phil Karn 提出建议：RTT 的估计仅考虑未发生重传且已得到确认的报文段，忽略发生重传的报文。
 *  Phil Karn 提出的理由是：当重传发生时，RTO 已经采用了指数退避。下一次的传输将按照这个已经增大的RTO 计时，不应该再将其纳入到RTT 的统计样本中。

Karn 算法可能引起的一个问题是

*  当发生重传时，说明时延会增大（或出错），可能会带来连续重传，从而使超时重传时间 RTO 一直得不到更新，无法反映当前现状。
 *  为此，提出了一种修正意见：每发生一次重传，即增大一些RTO 值，即：新RTO = r \* ( 旧RTO)
    
     *  其中：系数 r 的典型值是 2

指数避退

*  在TCP 中，当超时而发生连续多次重传时，在两次重传之间的超时阈值的设置遵循“ 指数避退” 原则：
    
     *  当超时第一次重传后，第二次重传等待时间是第一次的2倍，第三次重传等待时间是第二次的2倍,2为退避因子，直到收到重传数据包的应答，RTO退避因子恢复为1。
     *  这样为了当网络处于无法快速交付数据报文状态时减小网络负担。

## 选择确认 ##

选择确认 (Selective ACK ， SACK) ：

*  接收方收到了和前面的字节流不连续的两个字节块。
 *  如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。

接收到的字节流序号不连续：

![image-20210104191820592][]

*  和前后字节不连续的每一个字节块都有两个边界：左边界和右边界。图中用四个指针标记这些边界。
    
     *  第一个字节块的左边界 L1 = 1501，但右边界 R1 = 3001。
 *  左边界指出字节块的第一个字节的序号，但右边界减 1 才是字节块中的最后一个序号。
    
     *  第二个字节块的左边界 L2 = 3501，而右边界 R2 = 4501。

RFC 2018 的规定：

*  如果要使用选择确认，那么在建立 TCP 连接时，就要在 TCP 首部的选项中加上“允许 SACK”的选项，而双方必须都事先商定好。
 *  如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。只是以后在 TCP 报文段的首部中都增加了 SACK 选项，以便报告收到的不连续的字节块的边界。
 *  由于首部选项的长度最多只有 40 字节，而指明一个边界就要用掉 4 字节，因此在选项中最多只能指明 4 个字节块的边界信息。

[image-20210104172104935]: /images/20221119/67ff40abbea74e8385392b14da982c0c.png
[image-20210104174043364]: /images/20221119/030c0351f9f143f5a1c126b06cff226c.png
[image-20210104191820592]: /images/20221119/774c2825c3934e2ead2faa997294491b.png