计算机网络（五）—— 运输层（6、7）：TCP超时重传时间的选择、TCP可靠传输的实现

6. TCP超时重传时间的选择

  ■ 超时重传时间的选择是TCP最复杂的问题之一

  如下图所示，假设主机A和B是因特网上的两台主机，它们之间已经建立了TCP连接，纵坐标为时间。现在，主机A给主机B发送TCP数据报文段0，并记录下当前的时间，主机B收到后给主机A发送相应的确认报文段，主机A收到确认报文段后记录下当前的时间。主机A记录下的这两个时间，它们的差值就是报文段的往返时间RTT。由于这是第0个报文段的RTT，我们就用RTT0来表示。

  试想一下，如果我们将超时重传时间RTO的值设置的比RTT0的值小，会出现怎样的情况呢？
  很显然，这会引起报文段不必要的重传，使网络负荷增大。

  那么，如果将超时重传时间RTO的值设置的远大于RTT0的值，又会出现怎样的情况呢？
  很显然，这会使重传推迟的时间太长，使网络的空闲时间增大，降低了传输效率。

  综合上述两种情况，我们可以得出结论：超时重传时间RTO的值应该设置为略大于报文段往返时间RRT的值。

  ■ 不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO。
  ■ 利用每次测量得到的RTT样本，计算加权平均往返时间 RTT${}_S$(又称为平滑的往返时间)。

  ■ 用这种方法得出的加权平均往返时间RTT${}_S$就比测量出的RTT值更加平滑。
  ■ 显然，超时重传时间RTO应略大于加权平均往返时间RTTs。
  ■ RFC6298建议使用下式计算超时重传时间RTO：

  由上我们可以发现，不管是RTT${}_S$还是RTT${}_D$都是基于所测量到的RTT样本进行计算的。如果所测量到的RTT样本不正确，那么所计算出的RTT${}_S$和RTT${}_D$自然就不正确，进而所计算出的超时重传时间RTO也就不正确。
  ■ 往返时间RTT的测量比较复杂

  ■ 针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTT${}_S$，进而超时重传时间RTO也不会重新计算。
   $\diamond$ 这又引起了新的问题。设想出现这样的情况：报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。
  ■ 因此，要对Karn算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍，即出现超时重传时，新RTO=2倍的旧RTO。

6.1 课后练习

  1. 以下关于TCP超时重传时间RTO的叙述中，正确的是( D )
    A. RTO应小于TCP端到端加权平均往返时间RTTs
    B. RTO应远大于TCP端到端加权平均往返时间RTTs
    C. RTO应等于TCP端到端加权平均往返时间RTTs
    D. RTO应略大于TCP端到端加权平均往返时间RTTs
   分析： RTO应略大于TCP端到端加权平均往返时间RTTs。

  2. 若出现超时重传，则以下关于TCP超时重传时间RTO的叙述中，正确的是( B )
    A. RTO的值应清零
    B. RTO的值应扩大两倍
    C. RTO的值应减1
    D. RTO的值应保持不变
   分析： 若出现超时重传，RTO的值应扩大两倍。

7. TCP可靠传输的实现

  ■ TCP基于以字节为单位的滑动窗口来实现可靠传输。
   $\diamond$ 发送方在未收到接收方的确认时，可将发送窗口内还未发送的数据全部发送出去；
   $\diamond$ 接收方只接收序号落入发送窗口内的数据。
  ■ 虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。
   $\diamond$ 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
   $\diamond$ 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
  ■ 对于不按序到达的数据应如何处理，TCP并无明确规定。
   $\diamond$ 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。
   $\diamond$ TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
  ■ TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
    $\diamond$ 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
     TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。
    $\diamond$ 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
  ■ TCP的通信是全双工通信。 通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。

  例1： 主机甲与主机乙之间已建立一个TCP连接，主机甲向主机乙发送了两个连续的TCP段，分别包含300字节和500字节的有效载荷，第一个段的序号为200，主机乙正确接收到两个段后，发送给主机甲的确认序号是( D )
      A. 500  B. 700  C. 800  D. 1000
     分析：

  例2： 【2011年题40】主机甲与主机乙之间已建立一个TCP连接，主机甲向主机乙发送了3个连续的TCP段，分别包含300字节、400字节和500字节的有效载荷，第3个段的序号为900。若主机乙仅正确接收到第1个和第3个段，则主机乙发送给主机甲的确认序号是( B )
      A. 300  B. 500  C. 1200  D. 1400
     分析：

        TCP规定只能对按序到达的最高序号进行确认，因此主机乙发送的确认报文段实际上是对第一个数据报文段的确认。由于第一个数据报文段数据载荷的最后一个字节的序号为499，因此针对该序号的确认序号应为500。表明序号499为止的全部数据已经收到了，现在希望接收500号及其后续数据。

7.1 课后练习

  1. 主机甲和乙建立了TCP连接，主机甲向主机乙发送了两个连续的TCP段，分别包含200字节和300字节的有效载荷，第一个段的序号为100，主机乙正确接收到两个段后，发送给主机甲的确认号是( B )
    A. 500  B. 600  C. 800  D. 900
   分析： 第一个段100 ~ 299，第二个段300 ~ 599，主机乙正确接收到两个段后，发送给主机甲的确认号是600。

  2. 主机甲和乙建立了TCP连接，主机甲向主机乙发送了3个连续的TCP段，分别包含200字节、300字节、400字节的有效载荷，第3个段的序号为1000。若主机乙仅正确接收到第1和第3个段，则主机乙发送给主机甲的确认号是( C )
    A. 500  B. 600  C. 700  D. 800
   分析： 第三个段1000 ~ 1399，第二个段700 ~ 999，第一个段500 ~ 699。
       TCP规定只能对按序到达的最高序号进行确认，因此主机乙发送的确认报文段实际上是对第一个数据报文段的确认。由于第一个数据报文段数据载荷的最后一个字节的序号为699，因此针对该序号的确认序号应为700。表明序号699为止的全部数据已经收到了，现在希望接收700号及其后续数据。
       因此，若主机乙仅正确接收到第1和第3个段，则主机乙发送给主机甲的确认号是700。

  3. 主机甲和乙建立了TCP连接，双方持续有数据传输，且数据无差错与丢失。若甲收到1个来自乙的TCP段，该段的序号为1024，确认序号为2048，有效数据载荷为200字节，则甲立即发送给乙的TCP段的序号和确认号分别是( B )
    A. 2048、1223  B. 2048、1224  C. 2049、1223  D. 2049、1224
   分析： 甲在发送数据之前，明确两个信息：1. 段序号为1024，说明乙发给甲的数据段起始字节序号为1024，有效载荷长度为200，说明该数据段的长度为200，那么甲下次需要的数据段的序号就是1024 + 200 = 1224；2. 乙发给甲的确认序号为2048，说明乙这次需要甲发送的数据段的起始字节序号为2048。获取这两个信息后，甲即可确定要发给乙的序号为2048（从乙的确认序号获知），确认序号为1224（希望下次乙能够发送首字节序号1224 的数据段过来）。