TCP可靠传输

  再介绍TCP可靠传输之前，先对之前的两种可靠传输协议（GBN协议、SR协议）未介绍完的内容介绍完。

1 GBN协议中滑动窗口长度

  窗口的长度越长，发送方可以不需等待确认就发送的分组就越多，信道利用率也就高，但是窗口的长度不能是无限的。若采用n位比特表示序号，那么发送窗口的尺寸大小W应满足：1 ≤ W ≤ 2ⁿ - 1。因为发送窗口过大，就会使得接收方无法区分新的分组和旧的分组。

  假设采用2位来表示序号，则序号的范围就是[0 , 3]，根据上面的公式，发送窗口的最大尺寸是2² - 1 = 3。现在如果取发送窗口的大小为4，如下图所示。

发送方发送分组0~3，接收方在接收到4个分组后，返回ACK 3（表示收到这4个分组了），但是确认分组在传送的过程中丢失了，发送方在等待一段时间后，计时器超时，重新发送分组0~3，这时接收方就不清楚这四组数据是新的数据还是旧的数据。

2 SR协议中发送窗口和接收窗口

  在SR协议中，同样存在窗口大小的问题，在SR协议中发送窗口最好和接收窗口大小相等。如果发送窗口过大，会导致接收窗口溢出，过小同样也不好。

  对于采用n位比特表示序号，那么发送窗口和接收窗口的尺寸大小W_Tmax、W_Rmax 应满足：W_Tmax = W_Rmax = 2^(n-1)。

  假设采用2位来表示序号，则序号的范围就是[0 , 3]，根据上面的公式，发送窗口和接收窗口的最大尺寸是2^2-1 = 2。现在如果取发送窗口的大小为3。

  如下图所示，发送方发送分组0~3，接收方接收了3个分组并返回了分组的确认，但是三个确认分组在传送过程中都是丢失了，接收方在计时器超时后会重发三个分组，现在仅考虑分组0。

  如下图所示，发送方发送分组0~3，接收方接收了3个分组并返回了分组的确认，发送方接收到了确认后将窗口向前滑动，此时发送方乱序发送分组0。

  从上帝视角来看，虽然接收方接收的都是分组0，但是第一种情况分组0是旧的数据，而第二种情况是新的数据。即如果窗口的大小设置为3时，如果接收某个时刻接收到分组0，接收方并不能分清接收的是超时重传的分组还是一个新的分组，从而产生歧义。所以窗口大小并不是无限制的。

3 TCP可靠传输

  前面提过，网络层是不可靠的。IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。

  TCP在IP不可靠的尽力服务之上创建了一种可靠数据传输服务。TCP可靠传输服务确保一个进程从其接受缓存中读出的数据流时无损坏、无间隔、非冗余和按序的数据流。即该字节流和发送方发出的字节流是完全一样的。

  (1) TCP使用流水线机制，使得发送方在任意时刻都可以有多个发出但还未确认的报文段存在。

  (2) TCP使用累积确认机制。

  (3) TCP使用单一重传定时器。TCP只重传具有最小序号的还未被确认的报文段（即超时重传只重传一个报文段）。只是每次TCP重传时都会将下一次的超时间隔设置为原来的两倍。

例如，假设当定时器第一次过期时，与最早的未被确认的报文段相关联的过期时间是0.75秒。TCP就会重传该报文段，并把新的过期时间设置为1.5s。如果1.5秒后定时器又过期了，则TCP重传该报文段，并把过期时间设置为3.0秒。因此，超时间隔在每次重传后呈指数型增长。

定时器过期很有可能是由网络拥塞引起的，即太多的分组在传输路径的一台（或多台）路由器的队列中，造成分组丢失或长时间的排队时延。在这种情况下报文段的时延就会增大很多，原来本可以在重传时间内就可以收到确认报文的报文段，由于网络拥塞而没有收到确认，所以就会重传报文段。网络本来就拥塞了，如果此时发送端持续的重传，就会导致拥塞的更严重。所以TCP发送方重传都是经过越来越长的时间间隔后进行的。

  (4) TCP使用冗余确认技术（快速重传）

超时触发重传存在一个问题：超时周期可能较长。当一个报文段丢失时，需要等超时时间间隔后才能重发报文段，因而就增加了端到端的时延。所以，TCP通常在超时事件发生前通过冗余ACK来检测丢包的情况，这样就可以让发送方尽早知道发生了个别报文段的丢失。

  冗余ACK（duplicate ACK）就是再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。如果发送方连续收到3个冗余的ACK，说明跟在这个已经被确认过3次的报文段之后的那个报文段已经丢失了，TCP会立即执行快速重传。即在该报文段的定时器过期事前重传丢失报文段。

  如下图所示，当分组2丢失后，后面的分组到达接收方时，接收方会连续发送确认分组1报文段，当发送方接收到3个冗余ACK（即ACK 1），就知道了分组1之后的分组即分组2丢失了，所以会立即重传分组2。
  

  这里为什么是3个冗余的ACK，而不可以是1个或2个冗余的ACK？

(1) 如果是一个冗余的ACK根本就不知道这个冗余的ACK是由于网络路由选择、报文段丢失还是报文段的乱序到达哪个引起的。
(2) 假定接收方已经接收了N-1号报文段，发送方也已经收到ACK N-1。则考虑下面接收端报文段到达几种情况：
  1) N - 1    N    N + 1    N + 2——> 接收到1个ACK N。
  2) N - 1    N    N + 2    N + 1——> 接收到1个ACK N。
  3) N - 1    N + 1    N    N + 2——> 接收到2个ACK N。
  4) N - 1    N + 1    N + 2    N——> 接收到3个ACK N。
  5) N - 1    N + 2    N    N + 1——> 接收到2个ACK N。
  6) N - 1    N + 2    N + 1    N——> 接收到3个ACK N。
上述除了第一种情况，其余都存在乱序到达，在5种乱序到达的情况下，其中只有3次收到2次ACK N，即有60%的概率收到2次ACK是由于乱序造成的，而如果收到两次冗余ACK就认为报文段丢失显然有点不合适。
  另一方面，如果N号报文段丢失了，那么会100%收到3次ACK N。所以综合上面来看，收到3次冗余ACK就非常有可能认为一个报文段丢失了，当然4次、5次或更多次那么丢失的概率就更大，但是也没有必要。

下面总结一下TCP接收方生成ACK的策略：
  (1) 具有所期望序号的按序报文段到达。所在期望序号以前的数据都已经被确认——延迟的ACK。对另一个按序报文段到达最多等待0.5s，如果下一个按序到达的报文段没在这个规定的时间内到达，则发送一个ACK。

这句话的意思是：假设接收方下一个期望的序号是2号，2号之前的报文段都已经确认过了，如果这时2号报文段到达接收方，接收方不会立即返回对2号报文的确认，而是会等0.5s，因为它觉得3号报文段可能马上就来了，如果在0.5s内3号报文没有到，就不等了，直接返回ACK 3对3号报文段进行确认。

  (2) 具有所期望序号的按序报文段到达，另一个按序报文段等待ACK传输——立即发送单个累积ACK，以确认两个按序的报文段。

还是上面的例子，如果在0.5s内，3号报文段到了，那么就直接发送一个累积的ACK，即ACK 4来确认2号和3号报文段。

  (3) 比期望序号大的乱序报文段到达，检测出间隔——立即发送冗余ACK，指示下一个期待字节的序号（间隔的低端的序号）。

如下图，如果期望收到2号报文段，但是却收到了4号报文段（其间隔为2号~3号，间隔的低端是2号，即期望收到的序号），立即发送冗余ACK，即ACK 1。
注：ACK N表示的是对N号报文段的确认，例如 ACK 1只是表示对1号报文段的确认，其ACK报文段的首部中的确认号是2。只不过ACK N这样比较好表示而已。

  (4) 能部分或完全填充接收数据间隔的报文段到达——倘若该报文段位于间隔的低端，则立即发送ACK。

在(3)的情况下，如果接收到了2号报文段，正好是期望的序号，则立即发送ACK 2对2号报文段确认。如果不是期望的序号，则和(3) 一样发送冗余ACK。

  TCP的可靠传输它既不是纯粹的GBN协议也不是纯粹的SR协议，同时它还引入了快速重传等这类新的机制，它是可以看作是GBN和SR协议的混合体。

  TCP可靠传输的具体内容都在GNB协议和SR协议中介绍过了，只需要知道TCP使用了它们中的哪些机制以及引入了哪些新的机制。

4 小结

  本文完