---

TCP 可靠传输的实现

为了讲述可靠传输原理的方便，假定数据传输只在一个方向进行，即 A 发送数据，B 给出确认。

以字节为单位的滑动窗口

现假定 A 收到了 B 发来的确认报文段，其中窗口是 20 字节，确认号是 31。

发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
发送窗口里面的序号表示允许发送的序号。A 的发送窗口一定不能超过 B 的接收窗口数值。发送方的发送窗口大小还要受到当时网络拥塞程度的制约。
发送窗口后沿的后面部分表示已发送且已收到了确认。这些数据不需要保留了。发送窗口前言部分表示不允许发送的，因为接收方没有为这部分数据保留临时存放的缓存空间。
发送窗口后沿的变化情况有两种可能，即不动 (没有收到新的确认) 和前移 (收到了新的确认)。
发送窗口前沿通常是不断向前移动，也有可能不动。这对应于两种情况：①没有收到新的确认；②收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。
发送窗口前沿也有可能向后收缩。这发生在对方通知的窗口缩小了。但 TCP 的标准强烈不赞成这样做。因为很可能发送方在收到这个通知前已发送了窗口中的许多数据。

指针 P₃ - P₂ = 允许发送但当前尚未发送的字节数 (又称为可用窗口或有效窗口)

现在假定 B 收到了序号为 31 的数据，并把序号为 31 ~ 33 的数据交付主机，然后 B 删除这些数据。

发送方的应用进程把字节流写入 TCP 的发送缓存，接收方的应用进程从 TCP 的接收缓存中读取字节流。

首先明确两点：

• 缓存空间和序号空间都是有限的，且都是循环使用的。
• 实际上缓存或窗口中的字节数是非常之大的。

强调三点：

• 虽然 A 的发送窗口是根据 B 的接收窗口设置的，但在同一时刻，A 的发送窗口并不总是和 B 的接收窗口一样大。因为通过网络传送窗口值需要经历一定的时间滞后。发送方 A 还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。
• 对于不按序到达的数据应如何处理，TCP 标准并无明确规定。
  如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但对网络资源的利用不利。
  因此 TCP 通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
• TCP 要求接收方必须有累计确认的功能，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。

TCP 的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。

超时重传时间的选择

TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。

运输层的超时计时器的超时重传应设置为多大呢？

TCP 采用一种自适应算法，他记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。TCP 保留了 RTT 的一个加权平均往返时间 RTT_S，这又称为平滑的往返时间，S 表示 Smoothed。因为进行的是加权平均，因此得出的结果更加平滑。

每当第一次测量到 RTT 样本时，RTT_S 值就取为所测量到的 RTT 样本值。但以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTT_S：

新的 RTT_S = (1 - $\alpha$) × (旧的 RTT_S) + $\alpha$ × (新的 RTT 样本)

在上式中，$0\le \alpha <1$。RFC 6298 推荐的 $\alpha$ 值为 1/8，即 0.125。

超时计时器设置的超时重传时间 RTO (RetransmissionTime-Out) 应略大于 RTT_S。RFC 6298 建议使用下式计算 RTO：

RTO = RTT_S + 4 × RTT_D

而 RTT_D 是 RTT 的偏差的加权平均值，它与 RTT_S 和新的 RTT 样本之差有关。RFC 6298 建议这样计算 RTT_D。当第一次测量时，RTT_D 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算 RTT_D：

新的 RTT_D = (1 - $\beta$) × (旧的 RTT_D) + $\beta$ × | RTT_S - 新的 RTT 样本|

这里的 $\beta$ 是个小于 1 的系数，它的推荐值是 1/4，即 0.25。

Karn 提出了一个算法：在计算加权平均 RTTS 时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均 RTTS 和 RTO 就较准确。

对 Karn 算法进行修正。方法是：报文段每重传一次，就把 RTO 增大一些。典型的做法是取新的重传时间为旧的重传时间的 2 倍。当不再发生报文段的重传时，才根据 (5-5) 式计算 RTO。实践证明，这种策略较为合理。

选择确认 SACK

若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？
答案是可以的。选择确认就是一种可行的处理方法。

选择确认 (Selective ACK) 的工作原理。
TCP 的接收方在接收对方发送过来的数据字节流的序号不连续，结果形成了一些不连续的字节块。
如果收到的字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。

和前后字节不连续的每一个字节块都有两个边界：左边界和右边界。

TCP 的首部没有哪个字段能够提供上述这些字节块的边界信息。RFC 2018 规定，如果要使用 SACK，那么在建立 TCP 连接时，要在 TCP 首部的选项中加上“允许 SACK”的选项，而双方必须都事先商定好。
如果使用选择确认，那么原来首部中的“确认号”字段的用法不变。只是以后在 TCP 报文段的首部中都增加了 SACK 选项，以便报告收到的不连续的字节块的边界。

然而，SACK 文档没有指明发送方应当怎样响应 SACK。因此，大多数的实现还是重传所有未被确认的数据块。

---

TCP 的流量控制

利用滑动窗口实现流量控制

流量控制 (flow control) 是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口机制可以很方便地在 TCP 连接上实现对发送方的流量控制。

发送方的发送窗口不能超过接收方给出的接收窗口的数值。注意，TCP 的窗口单位是字节，不是报文段。

图中大写 ACK 表示首部中的确认位 ACK，小写 ack 表示确认字段的值。

接收方的主机 B 进行了三次流量控制。这里的 rwnd 表示 receiver window。第一次把窗口减小到 rwnd = 300，第二次减到 rwnd = 100，最后减到 rwnd = 0，即不允许发送方再发送数据了。这种使发送方最暂停发送的状态将持续到主机 B 重新发出一个新的窗口值为止。B 向 A 发送的三个报文段都设置了 ACK = 1，只有在 ACK = 1 时确认号字段才有意义。

TCP 为每一个连接设有一个持续计时器 (persistence timer)。只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段 (仅携带 1 字节的数据)，而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可打破。

TCP 的传输效率

应用进程把数据传送到 TCP 的发送缓存后，剩下的发送任务就由 TCP 来控制了。可以用不同的机制来控制 TCP 报文段的发送时机。例如，

• 第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
• 第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送 (push) 操作。
• 第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段发送出去。

如何控制 TCP 发送报文段的时机是一个较为复杂的问题。

在 TCP 的实现中广泛使用 Nagle 算法。算法如下：

• 若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。
• 当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。
• 只有在收到对前一个报文段的确认后才继续发送下一个报文段。
• 当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。
• Nagle 算法还规定，当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。这样做，可以有效地提高网络的吞吐量。

一个问题叫做糊涂窗口综合征 (silly window syndrome) [RFC 813]，有时也会使 TCP 的性能变坏。设想一种情况：TCP 接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取 1 个字节，然后向发送方发送确认，并把窗口设置为 1 个字节。接着，发送方又发来 1 个字节的数据 (发送的 IP 数据报是 41 字节长)。接收方发回确认，仍然将窗口设置为 1 个字节。这使网络的效率很低。

要解决这个问题，可以让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的时间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。

上述两种方法可配合使用。使得在发送方不发送很小的报文段的同时，接收方也不要在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。

---

5-24 一个 TCP 连接下面使用 256 kbit/s 的链路，其端到端时延为 128 ms。经测试，发现吞吐量只有 120 kbit/s。试问发送窗口 W 是多少？ (提示：可以有两种答案，取决于接收端发出确认的时机。)

吞吐量 (throughput) 表示在单位时间内通过某个网络 (或信道、接口) 的实际的数据量。吞吐量更经常地用于对现实世界中的网络的一种测量，以便知道实际上到底有多少数据量能够通过网络。

设发送窗口 = W (bit)。发送端连续发送完窗口内的数据所需的时间 = T。有以下情况。
(a) 接收端在收完一批数据的最后才发出确认，因此发送端经过 (256 ms + T) 后才能发送下一个窗口的数据。
(b) 接收端每收到一个很小的报文段后就发回确认，因此发送端经过比 256 ms 略多一些的时间即可再发送数据。因此每经过 256 ms 就能发送一个窗口的数据。

对于 (a)：
W / (256 ms + T) = 吞吐量，将 T = W / 数据率 代入，得 W = 57825.88 bit，约为 7228 字节。

对于 (b)：
W / 256 ms = 吞吐量，得 W = 30720 bit = 3840 B。

---

5-29 在使用 TCP 传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该确认报文段对应的数据的重传。试说明理由。

解：还未重传就收到了对更高序号的确认。

---

5-30 设 TCP 使用的最大窗口为 65535 字节，而传输信道不产生差错，带宽也不受限制。若报文段的平均往返时延为 20 ms，问所能得到的最大吞吐量是多少?

解：见习题 5-24 的图。

在发送时延可忽略的情况下，最大吞吐量是 65535 B / 20 ms = 26.214 Mbit/s。

---

5-31 通信信道带宽为 1 Gbit/s，端到端传播时延为 10 ms。TCP 的发送窗口为 65535 字节。试问：可能达到的最大吞吐量是多少？信道的利用率是多少？

解：见习题 5-24 的图。

发送时延 t = 65535 字节 / (1 Gbit/s) = 0.524 ms。

可能达到的最大吞吐量是 65535 B / (20 ms + t) = 25.544 Mbit/s。

信道的利用率是 t / (20 ms + t) = 2.55%。

---

5-32 什么是 Karn 算法？在 TCP 的重传机制中，若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时延样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度？

Karn 算法：在计算加权平均 RTTS 时，只要报文段重传了，就不采用其往返时间样本。

在统计意义上，重传时间最后会减小到使用 Karn 算法的 1/2。

假设实际 RTT 不变，计算出的 RTO 越小，获得的 RTT 样本值就越大。

---

5-33 假定 TCP 在开始建立连接时，发送方设定超时重传时间是 RTO = 6 秒。
(1) 当发送方收到对方的连接确认报文段时，测量出 RTT 样本值为 1.5 秒。试计算现在的 RTO 值。
(2) 当发送方发送数据报文段并收到确认时，测量出 RTT 样本值为 2.5 秒。试计算现在的 RTO 值。

解：见上面超时重传时间的选择章节。
(1) 第一次，RTT_S = 1.5 s，RTT_D = RTT 样本值 / 2 = 0.75 s。
RTO = RTT_S + 4 × RTT_D = 4.5 s。

(2) 新的 RTT_S = (1 - $\alpha$) × (旧的 RTT_S) + $\alpha$ × (新的 RTT 样本)
新的 RTT_D = (1 - $\beta$) × (旧的 RTT_D) + $\beta$ × | RTT_S - 新的 RTT 样本|
RTO = RTT_S + 4 × RTT_D

取 $\alpha$ = 0.125，新的 RTT_S = (1 - 0.125) × 1.5 + 0.125 × 2.5 = 1.625 s。
取 $\beta$ = 0.25，新的 RTT_D = (1 - 0.25) × 0.75 + 0.25 × |1.625 - 2.5| = 0.78125 s。

RTO = 1.625 + 4 × 0.78125 = 4.75 s

---

5-34 已知第一次测得 TCP 的往返时间 RTT 是 30 ms。现在收到了三个确认报文段，用它们测量出的往返时间样本 RTT 分别是：26 ms，32 ms 和 24 ms。设 $\alpha$ = 0.1。试计算每一次的新的加权平均往返时间值 RTT_S。讨论所得出的结果。

解：初始，RTT_S = 30 ms，RTT_D = 15 ms。
样本 RTT 为 26 ms 时，取 $\alpha$ = 0.1，新的 RTT_S = 29.6 ms
样本 RTT 为 32 ms 时，新的 RTT_S = 29.84 ms
样本 RTT 为 24 ms 时，新的 RTT_S = 29.256 ms

可以看出，RTT 的样本值变化多达 20% 时，RTT_S 的变化却很小。

---

5-35 试计算一个包括五段链路的运输连接的单程端到端时延。五段链路程中有两段是卫星链路，有三段是广域网链路。每条卫星链路又由上行链路和下行链路两部分组成。可以取这两部分的传播时延之和为 250 ms。每一个广域网的范围为 1500 km，其传播时延可按 150000 km/s 来计算。各数据链路速率为 48 kbit/s，帧长为 960 bit。

解：发送时延为 960 bit / (48 kbit/s) = 20 ms。五段链路发送时延为 T1 = 100 ms。
每一个广域网传播时延为 1500 km / (150000 km/s) = 10 ms。三段广域网传播时延为 T2 = 30 ms。
两段卫星链路传播时延为 T3 = 250 ms × 2 = 500 ms。
则包括五段链路的运输连接的单程端到端时延为 T1 + T2 + T3 = 630 ms。

---

5-36 重复 5-35 题，但假定其中的一个陆地上的广域网的传输时延为 150 ms。

解：传输时延即为发送时延。
五段链路发送时延为 T4 = 20 ms × 4 + 150 ms = 230 ms。
包括五段链路的运输连接的单程端到端时延为 T2 + T3 + T4 = 760 ms。

---

5-58 TCP 在 4:30:20 发送了一个报文段。由于没有收到确认，因此在 4:30:25 它重传了前面这个报文段，并在 4:30:27 收到了确认。若以前的 RTT 值是 4 秒，根据 Karn 算法，新的 RTT 值为多少？

Karn 算法：在计算加权平均 RTTS 时，只要报文段重传了，就不采用其往返时间样本。

因为收到的确认是在重传后收到的，所以 RTT 值没有变化，仍然是 4 秒。

---

5-59 TCP 连接使用 1000 字节的窗口值，而上一次的确认号是 22001。它收到了一个报文段，确认号是 22401.。试用图来说明在这之前与之后的窗口情况。

---

5-60 同上题，但在接收方收到的字节为 22401 的报文段时，其窗口字段变为 1200 字节。试用图来说明在这之前与之后的窗口情况。

解：在这之前的窗口情况与 5-59 题中的图一样。
在这之后的窗口情况的图，发送窗口变为 1200 字节。后沿还是 22401，前言变为 23600。

---

5-61 在本题中列出的 8 种情况下，画出发送窗口的变化，并标明可用窗口的位置。已知主机 A 要向主机 B 发送 3 KB 的数据。在 TCP 连接建立后，A 的发送窗口大小是 2 KB。A 的初始序号是 0。
(1) 一开始 A 发送 1 KB 的数据。
(2) 接着 A 就一直发送数据，直到把发送窗口用完。
(3) 发送方 A 收到对第 1000 号字节的确认报文段。
(4) 发送方 A 再发送 850 B 的数据。
(5) 发送方 A 收到 ack = 900 的确认报文段。
(6) 发送方 A 收到对第 2047 号字节的确认报文段。
(7) 发送方 A 把剩下的数据全部都发送完。
(8) 发送方 A 收到 ack = 3072 的确认报文段。

解：1 KB = 1024 B，2 KB = 2048 B，3 KB = 3072 B。
(1) 允许发送的序号为 0 ~ 2047。可用窗口序号 1024 ~ 2047。
(2) 已发送但未收到确认 0 ~ 2047。可用窗口大小为 0。
(3) 允许发送的序号 1001 ~ 3048。可用窗口 2048 ~ 3048。
(4) 已发送但未收到确认 1001 ~ 2897。可用窗口 2898 ~ 3048。
(5) 同上。
(6) 允许发送的序号 2048 ~ 4095。可用窗口 2898 ~ 4095。
(7) 已发送但未收到确认 2048 ~ 3071。可用窗口 3072 ~ 4095。
(8) 允许发送的序号 3072 ~ 5119。可用窗口 3072 ~ 5119。

---

5-69 现在假定使用类似 TCP 的协议 (即使用滑动窗口可靠传送字节流)，数据传输速率是 1 Gbit/s，而网络的往返时间 RTT = 140 ms。假定报文段的最大生存时间是 60 秒。如果要尽可能快的传送数据，在我们的通信协议的首部中，发送窗口和序号字段至少各应当设为多大？

解：发送窗口至少应当容纳的数据大小 = 数据率 × RTT = $140\times 10^6$ bit = $17.5\times 10^6$ 字节。
每个字节的数据需要一个编号。假设发送窗口一共有 $w$ 位，则有 $2^w\ge 17.5\times 10^6$。
$w$ 至少为 25，即发送窗口至少应当设 25 位。

60 秒可发送数据 1 Gbit/s × 60 s = $60\times 10^9$ bit = $7.5\times 10^9$ 字节。
设序号字段的位数是 $n$，则有 $2^n\ge 7.5\times 10^9$。
$n$ 至少为 33，即序号字段至少应当设 33 位，可保证在报文段的最大生存时间内字节编号没有重复。

---

5-72 已知 TCP 的接收窗口大小是 600 (单位是字节，为简单起见以后就省略了单位)，已经确认了的序号是 300。试问，在不断的接收报文段和发送确认报文段的过程中，接收窗口也可能会发生变化 (增大或缩小)。请用具体的例子 (指出接收方发送的确认报文段中的重要信息) 来说明哪些情况是可能发生的，而哪些情况是不允许发生的。

发送窗口后沿的变化情况有两种可能，即不动 (没有收到新的确认) 和前移 (收到了新的确认)。
发送窗口前沿通常是不断向前移动，也有可能不动。这对应于两种情况：①没有收到新的确认，对方通知的窗口大小也不变；②收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。
发送窗口前沿也有可能向后收缩。这发生在对方通知的窗口缩小了。但 TCP 的标准强烈不赞成这样做。因为很可能发送方在收到这个通知前已发送了窗口中的许多数据。

---

5-73 在上题中，如果接收方突然因某种原因不能够再接收数据了，可以立即向发送方发送把接收窗口置为零的报文段 (即 rwnd = 0)。这时会导致接收窗口的前沿后退。试问这种情况是否允许？

解：这种情况是允许的。当发送方收到这样的信息，并不是把发送窗口缩回到零，而是立即停止发送。什么时候可以再发送数据，就要等接收方重新开放接收窗口，即给出一个非零的接收窗口。

---

【计算机网络 (谢希仁) 习题题解】目录