计算机网络 运输层(二)TCP的实现

计算机网络(十三)

学习计算机网络过程中的心得体会以及知识点的整理,方便我自己查找,也希望可以和大家一起交流。

—— 运输层 ——

文章目录

  • 计算机网络(十三)
    • —— 运输层 ——
  • 上接《计算机网络 运输层(一)》
      • 5 TCP 报文段的首部格式
        • 5.1 为什么要规定 MSS
        • 5.2 其他选项
      • 6 TCP 可靠传输的实现
        • 6.1 以字节为单位的滑动窗口
          • 6.1.1 发送缓存与接收缓存的作用
          • 6.1.2 接收方发送确认
        • 6.2 超时重传时间的选择
          • 6.2.1 TCP 超时重传时间设置
          • 6.2.2 加权平均往返时间
          • 6.2.2 超时重传时间 RTO
          • 6.2.3 往返时间 (RTT) 的测量
          • 6.2.4 Karn 算法
          • 6.2.5 接收到的字节流序号不连续
        • 6.3 选择确认 SACK
          • 6.3.1 RFC 2018 的规定
  • 后续内容查看《计算机网络 运输层(三)》

上接《计算机网络 运输层(一)》

《计算机网络 运输层(一)》

5 TCP 报文段的首部格式

  • TCP 虽然是面向字节流的,但 TCP 传送的数据单元却是报文段。
  • 一个 TCP 报文段分为首部和数据两部分,而 TCP 的全部功能都体现在它首部中各字段的作用。
  • TCP 报文段首部的前 20 个字节是固定的,后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。
    计算机网络 运输层(二)TCP的实现_第1张图片
    计算机网络 运输层(二)TCP的实现_第2张图片
    计算机网络 运输层(二)TCP的实现_第3张图片
    计算机网络 运输层(二)TCP的实现_第4张图片
    计算机网络 运输层(二)TCP的实现_第5张图片
    计算机网络 运输层(二)TCP的实现_第6张图片
    计算机网络 运输层(二)TCP的实现_第7张图片
    计算机网络 运输层(二)TCP的实现_第8张图片
    计算机网络 运输层(二)TCP的实现_第9张图片
    计算机网络 运输层(二)TCP的实现_第10张图片
    计算机网络 运输层(二)TCP的实现_第11张图片

5.1 为什么要规定 MSS

  • MSS 与接收窗口值没有关系。
  • 若选择较小的 MSS 长度,网络的利用率就降低。
  • 当 TCP 报文段只含有 1 字节的数据时,在 IP 层传输的数据报的开销至少有 40 字节(包括 TCP 报文段的首部和 IP 数据报的首部)。这样,对网络的利用率就不会超过 1/41。到了数据链路层还要加上一些开销。
  • 若 TCP 报文段非常长,那么在 IP 层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的 TCP 报文段。当传输出错时还要进行重传。这些也都会使开销增大。
  • 因此,MSS 应尽可能大些,只要在 IP 层传输时不需要再分片就行。
  • 由于 IP 数据报所经历的路径是动态变化的,因此在这条路径上确定的不需要分片的 MSS,如果改走另一条路径就可能需要进行分片。
  • 因此最佳的 MSS 是很难确定的。

5.2 其他选项

  • 窗口扩大选项 ——占 3 字节,其中有一个字节表示移位值 S。新的窗口值等于 TCP 首部中的窗口位数增大到 (16 + S),相当于把窗口值向左移动 S 位后获得实际的窗口大小。
  • 时间戳选项——占 10 字节,其中最主要的字段时间戳值字段(4 字节)和时间戳回送回答字段(4 字节)。
  • 选择确认选项——在后面介绍。

6 TCP 可靠传输的实现

6.1 以字节为单位的滑动窗口

  • TCP 的滑动窗口是以字节为单位的。
  • 现假定 A 收到了 B 发来的确认报文段,其中窗口是 20 字节,而确认号是 31(这表明 B 期望收到的下一个序号是 31,而序号 30 为止的数据已经收到了)。
  • 根据这两个数据,A 就构造出自己的发送窗口,
    计算机网络 运输层(二)TCP的实现_第12张图片
    计算机网络 运输层(二)TCP的实现_第13张图片
    计算机网络 运输层(二)TCP的实现_第14张图片
    计算机网络 运输层(二)TCP的实现_第15张图片
    计算机网络 运输层(二)TCP的实现_第16张图片
    计算机网络 运输层(二)TCP的实现_第17张图片
6.1.1 发送缓存与接收缓存的作用
  • 发送缓存用来暂时存放:
    • 发送应用程序传送给发送方 TCP 准备发送的数据;
    • TCP 已发送出但尚未收到确认的数据。
  • 接收缓存用来暂时存放:
    • 按序到达的、但尚未被接收应用程序读取的数据;
    • 不按序到达的数据。

【注意】

  • 第一,A 的发送窗口并不总是和 B 的接收窗口一样大(因为有一定的时间滞后)。
  • 第二,TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。
  • 第三,TCP 要求接收方必须有累积确认的功能,这样可以减小传输开销。
6.1.2 接收方发送确认
  • 接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上。
  • 但请注意两点:
    • 第一,接收方不应过分推迟发送确认,否则会导致发送方不必要的重传,这反而浪费了网络的资源。。
    • 第二,捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据。

6.2 超时重传时间的选择

  • 重传机制是 TCP 中最重要和最复杂的问题之一。
  • TCP 每发送一个报文段,就对这个报文段设置一次计时器。
  • 只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段。
  • 重传时间的选择是 TCP 最复杂的问题之一。

计算机网络 运输层(二)TCP的实现_第18张图片

6.2.1 TCP 超时重传时间设置
  • 如果把超时重传时间设置得太短,就会引起很多报文段的不必要的重传,使网络负荷增大。
  • 但若把超时重传时间设置得过长,则又使网络的空闲时间增大,降低了传输效率。
  • TCP 采用了一种自适应算法,它记录一个报文段发出的时间,以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。
6.2.2 加权平均往返时间
  • TCP 保留了 RTT 的一个加权平均往返时间 RTTS(这又称为平滑的往返时间)。
  • 第一次测量到 RTT 样本时,RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本,就按下式重新计算一次 RTTS
    计算机网络 运输层(二)TCP的实现_第19张图片
  • 式中,0<α<1。若 α 很接近于零,表示 RTT 值更新较慢。若选择α 接近于 1,则表示 RTT 值更新较快。
  • RFC 2988 推荐的 α 值为 1/8,即 0.125。
6.2.2 超时重传时间 RTO
  • RTO (Retransmission Time-Out) 应略大于上面得出的加权平均往返时间 RTTS
  • RFC 2988 建议使用下式计算 RTO:
    运输层
  • RTTD 是 RTT 的偏差的加权平均值。
  • RFC 2988 建议这样计算 RTTD。第一次测量时,RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中,则使用下式计算加权平均的 RTTD
    计算机网络 运输层(二)TCP的实现_第20张图片
  • β个小于 1 的系数,其推荐值是 1/4,即 0.25。
6.2.3 往返时间 (RTT) 的测量

往返时间 (RTT) 的测量相当复杂

  • TCP 报文段 1 没有收到确认。重传(即报文段 2)后,收到了确认报文段 ACK。
  • 如何判定此确认报文段是对原来的报文段 1 的确认,还是对重传的报文段 2 的确认?
    计算机网络 运输层(二)TCP的实现_第21张图片
6.2.4 Karn 算法
  • 在计算平均往返时间 RTT 时,只要报文段重传了,就不采用其往返时间样本。
  • 这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确。
  • 但是,这又引起新的问题。当报文段的时延突然增大了很多时,在原来得出的重传时间内,不会收到确认报文段。于是就重传报文段。但根据 Karn 算法,不考虑重传的报文段的往返时间样本。这样,超时重传时间就无法更新。

修正的 Karn 算法

  • 报文段每重传一次,就把 RTO 增大一些:
    计算机网络 运输层(二)TCP的实现_第22张图片
  • 系数 γ 的典型值是 2 。
  • 当不再发生报文段的重传时,才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。
  • 实践证明,这种策略较为合理。
6.2.5 接收到的字节流序号不连续

计算机网络 运输层(二)TCP的实现_第23张图片

6.3 选择确认 SACK

  • 接收方收到了和前面的字节流不连续的两个字节块。
  • 如果这些字节的序号都在接收窗口之内,那么接收方就先收下这些数据,但要把这些信息准确地告诉发送方,使发送方不要再重复发送这些已收到的数据。
6.3.1 RFC 2018 的规定
  • 如果要使用选择确认,那么在建立 TCP 连接时,就要在 TCP 首部的选项中加上“允许 SACK”的选项,而双方必须都事先商定好。
  • 如果使用选择确认,那么原来首部中的“确认号字段”的用法仍然不变。只是以后在 TCP 报文段的首部中都增加了 SACK 选项,以便报告收到的不连续的字节块的边界。
  • 由于首部选项的长度最多只有 40 字节,而指明一个边界就要用掉 4 字节,因此在选项中最多只能指明 4 个字节块的边界信息。

后续内容查看《计算机网络 运输层(三)》

你可能感兴趣的:(计算机网络基础)