第五章 | 计算机网络原理 谢希仁（第八版）_ 习题答案（Part 3）

---

计算机网络原理 谢希仁（第八版）

第五章 运输层 习题答案 (Part 3)

---

5-31 ~ 5-35

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

解：
吞吐量=发送数据/时间
发送数据最大=65535×8=524280bit。
时间=发送时延+往返时延=524280bit/(1Gbit/s)+20ms=20.524ms。
最大吞吐量=524280bit/20.524ms=25.5Mbit/s。
信道利用率=吞吐量/带宽=(25.5Mbit/s)/(1Gbit/s)×100%=2.55%。

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

答：
Karn 算法允许 TCP 能够区分开有效的和无效的往返时间样本，从而改进往返时间的估算。
若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。如下图所示，TCP 发送了报文段后，没有收到确认，于是超时重传报文段。但刚刚重传了报文段后，马上就收到了确认。显然，这个确认是对原来发送的报文段的确认。
但是，根据题意，我们就认为这个确认是对重传的报文段的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到很接近于零、
因此，上述的这种做法是不可取的。

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

解：
（1）当第一次测量RTT样本时，RTTS就取值RTT样本值为1.5s。RTTS=1.5s
根据RFC2988的建议，RTTD取值为RTT样本值的一半。
RTTD=0.75s
根据公式可得：RTO=RTTS+4RTTD=1.5s+3s=4.5s
（2）新的RTT样本为2.5s。（根据RFC6298推荐，α取1/8，β取1/4。）
即新的RTTS=（1-α）×（旧的RTTS)+α×（新的RTT样本）=1.625s
新的RTTD=（1-β）×（旧的RTTD)+β×|RTTS-新的RTT样本|=0.78s
根据公式：RTO=RTTS+4RTTD=1.625s+4×0.78s=4.75s

5-34 已知第一次测得 TCP 的往返时延的当前值 RTT 是 30 ms。现在收到了三个接连的确认报文段，它们比相应的数据报文段的发送时间分别滞后的时间是：26 ms，32 ms 和24 ms。设 α = 0.1。试计算每一次的新的加权平均往返时间值RTTS。讨论所得出的结果。

解：
公式：即新的RTTS=（1-α）×（旧的RTTS)+α×（新的RTT样本）
第一次：RTTs=（1-0.1）×30ms+0.1×26ms=29.6ms
第二次：RTTS=（1-0.1）×29.6ms+0.1×32ms=29.86ms
第三次：RTTS=（1-0.1）×29.86ms+0.1×24ms=29.256ms
三次的加权平均时间相差不大，当RTT样本值变化不大时，RTTs的变化也是很小的。

5-35 用TCP通过速率为1Gbit/s的链路传送一个10MB的文件。假定链路的往返时延RTT=50ms。TCP选用了窗口扩大选项，使窗口达到可选用的最大值。在接收端，TCP的接收窗口为1MB，而发送端采用拥塞控制算法，从慢开始传送。假定拥塞窗口以分组为单位计算，在一开始发送1个分组，而每个分组长度都是1KB.假定网络不会发生拥塞和分组丢失，并且发送端发送数据的速率足够快，因此发送时延可以忽略不计，而接收端每一次收完一批分组后就立即发送确认ACK分组。

(1)经过多少个RTT后，发送窗口大小达到1MB？
(2)发送端把整个10MB文件传送成功共需要多少个RTT？传送成功是指发送完整个文件，并收到所有的确认。TCP扩大的窗口够用么？更正后的答案详见下方标题 【 更正5-35-2 】
(3)根据整个文件发送成功所花费的时间（包括收到所有的确认），计算此传输链路的有效吞吐率。链路带宽的利用率是多少？

解：
(1)根据拥塞算法，就是每一次接收端发出确认时，发送端口就会增加为原来的2倍。则1MB=1024KB。那么就是 2 10 2^{10} 210KB=1MB，也就是来回十次就可以了，经过10个RTT，发送窗口大小达到1MB。

(2) 从图中可看出，当第10个RTT结束时，已传送成功的分组是 2 10 − 1 2^{10}-1 210−1个分组，正好比1MB少一个分组。一个分组只有1KB，可先不考虑。可以这样分析:在第10个RTT结束时，发送窗口为1MB，已传送成功的数据量约为1MB（准确的是1MB-1 KB)，因此在此基础上，我们还需要再传送9MB（实际上还需要再传送9MB+ 1 KB)。由于每经过一个RTT，发送窗口就加倍，因此在第11个RTT结束时，又成功发送了1MB。第12个RTT结束时，又成功发送了2MB。第13个RTT结束时，又成功发送了4MB。至此，一共又成功传送了I+2+4=7MB。与9MB 相比还差2MB。因此还要经过一个RTT。在第14个RTT开始时把所有剩下的数据2MB(实际上是2MB+1KB）都发送完毕。这样，全部10MB的数据成功发送完毕需要14个 RTT。

(3)吞吐率=数据量/时间
数据量=10MB=10× 2 20 2^{20} 220B=10× 2 20 2^{20} 220×8bit
时间=14×50ms=0.7s
有效吞吐率=10× 2 20 2^{20} 220×8bit/0.7s=119.8Mbit/s
带宽利用率=吞吐量/带宽
带宽利用率=119.8Mbit/s/1Gbit/s×100%=11.98%

---

更正5-35-2

关于原文第 35 题第 (2) 问中发送窗口大小的疑问：

TCP的发送窗口大小应该是 min(接收窗口, 拥塞窗口)。在第10个RTT之后，发送窗口的大小应该受到接收窗口的限制，而不是继续增大。

以下是详细分析：

分析：

1. 拥塞窗口和接收窗口的关系：
   • 拥塞窗口（cwnd）是由发送端根据网络状况动态调整的。
   • 接收窗口（rwnd）是由接收端告知发送端的，表示接收端当前能够接收的最大数据量。
2. 慢启动阶段：
   • 在慢启动阶段，拥塞窗口每个RTT会加倍。
   • 但是，当拥塞窗口达到接收窗口的大小时，发送窗口将受到接收窗口的限制。

具体计算：

1. 第10个RTT结束时：
   • 拥塞窗口达到1MB（1024KB），此时发送窗口大小为 min(1MB, 1MB)，即1MB。
2. 之后的RTT：
   • 由于接收窗口为1MB，发送窗口不能再继续增大，仍然保持在1MB。

更正：

因此，第2问的解答应该考虑接收窗口的限制：

1. 第10个RTT结束时：

• 已传送的数据量为 2^{10} - 1 = 1023KB。
  2. 剩余数据传输：
• 还需传输 10MB - 1023KB ≈ 9MB。
• 每个RTT可以传输1MB，因此还需要 9MB / 1MB = 9个RTT。
  3. 总RTT数：
• 总共需要 10 + 9 = 19个RTT。

结论：

1. 经过多少个RTT后，发送窗口大小达到1MB？

• 10个RTT

2. 发送端把整个10MB文件传送成功共需要多少个RTT？

• 19个RTT

3. 有效吞吐率和带宽利用率：

• 有效吞吐率 = 数据量 / 时间 = 10MB / (19 * 50ms) = 10MB / 0.95s ≈ 84.2Mbit/s
• 带宽利用率 = 吞吐量 / 带宽 = 84.2Mbit/s / 1Gbit/s × 100% ≈ 8.42%

---

5-36 ~ 5-40

5-36 假定TCP采用一种仅使用线性增大和乘法减小的简单拥塞控制算法，而不使用慢开始。发送窗口不采用字节为计算单位，而是使用分组pkt为计算单位。
在一开始发送窗口为1pkt。假定分组的发送时延非常小，可以忽略不计。所有产生的时延就是传播时延。
假定发送窗口总是小于接收窗口。接收端每收到一分组后，就立即发回确认ACK。
假定分组的编号为i，在一开始发送的是i=1的分组。以后当i=9，25，30，38，50时，发生了分组的丢失。
再假定分组的超时重传时间正好是下一个RTT开始的时间。
试画出拥塞窗口（也就是发送窗口）与RTT的关系曲线，画到发送第51个分组为止。

答：开始时拥塞窗口（发送窗口)为1 pkt，发送编号为1的分组。
当RTT=1时(即第1个RTT结束时),收到确认，拥塞窗口增大到2 pkt,发送2个分组，其编号为2和3。
当RTT=2时(即第2个RTT结束时),收到确认,拥塞窗口增大到3 pkt,发送3个分组，其编号为4~～6。
当RTT=3时(即第3个RTT结束时),收到确认,拥塞窗口增大到4 pkt,发送4个分组，其编号为7~10。
但在RTT=4时(即第4个RTT结束时),发送端发现编号为9的分组丢失了,没有收到相应的确认。于是这时把拥塞窗口减半，从前面的4减到2。请注意，拥塞窗口的值仅在RTT为整数值时才有意义。因为只有在这些时刻，确定了发送端能够发送几个分组。分组一旦发送出去，发送窗口就不再起作用。只有到了下一个RTT 结束时，发送窗口才再次起作用。
后面的分组发送，在图中表示，就不再作过多的解释了。但最后，在RTT=18时，由于编号为50的分组丢失，拥塞窗口应减半，从5 pkt减小到2.5 pkt。但分组组不能只发送半个，因此实际上拥塞窗口就是2。如果在图中把拥塞窗口设定为2.5 pkt，那么在发送时也只能发送2个分组。因此在RTT -18时，发送的分组编号是50和51。

5-37 在 TCP 的拥塞控制中，什么是慢开始、拥塞避免、快重传和快恢复算法?这里每一种算法各起什么作用? “乘法减小”和“加法增大”各用在什么情况下?

答：

① 慢开始：
在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个 MSS 的数值。用这样的方法逐步增大发送端的拥塞窗口 cwnd，可以分组注入到网络的速率更加合理。
② 拥塞避免：
当拥塞窗口值大于慢开始门限时，停止使用慢开始算法而改用拥塞避免算法。拥塞避免算法使发送的拥塞窗口每经过一个往返时延 RTT 就增加一个 MSS 的大小。
③ 快重传算法规定：
发送端只要一连收到三个重复的 ACK 即可断定有分组丢失了，就应该立即重传丢手的报文段而不必继续等待为该报文段设置的重传计时器的超时。
④ 快恢复算法：
当发送端收到连续三个重复的 ACK 时，就重新设置慢开始门限 ssthresh 与慢开始不同之处是拥塞窗口 cwnd 不是设置为 1，而是设置为 ssthresh 若收到的重复的 ACK 为 n 个（n>3），则将 cwnd 设置为 ssthresh 若发送窗口值还容许发送报文段，就按拥塞避免算法继续发送报文段。若收到了确认新的报文段的 ACK，就将 cwnd 缩小到 ssthresh。
⑤ 乘法减小：
是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。当网络频繁出现拥塞时，ssthresh 值就下降得很快，以大大减少注入到网络中的分组数。
⑥ 加法增大：
是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口 cwnd 增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。

5-38 设 TCP 的 ssthresh 的初始值为 8 (单位为报文段)。当拥塞窗口上升到 12 时网络发生了超时，TCP 使用慢开始和拥塞避免。试分别求出第 1 次到第 15 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗？

答：

拥塞窗口大小及变化原因见下表：

轮次	拥塞窗口	拥塞窗口变化的原因
1	1	网络发生了超时，TCP 使用慢开始算法
2	2	拥塞窗口值加倍
3	4	拥塞窗口值加倍
4	8	拥塞窗口值加倍，这是 ssthresh 的初始值
5	9	TCP 使用拥塞避免算法，拥塞窗口值加 1
6	10	TCP 使用拥塞避免算法，拥塞窗口值加 1
7	11	TCP 使用拥塞避免算法，拥塞窗口值加 1
8	12	TCP 使用拥塞避免算法，拥塞窗口值加 1
9	1	网络发生了超时，TCP 使用慢开始算法
10	2	拥塞窗口值加倍
11	4	拥塞窗口值加倍
12	6	拥塞窗口值加倍，但到达 12 的一半时，改为拥塞避免算法
13	7	TCP 使用拥塞避免算法，拥塞窗口值加 1
14	8	TCP 使用拥塞避免算法，拥塞窗口值加 1
15	9	TCP 使用拥塞避免算法，拥塞窗口值加 1

注：
依照原理，首先执行 TCP 连接初始化，将拥塞窗口 cwnd 值置为 1；其次执行慢开始算法，cwnd 按指数规律增长，因此随后窗口大小分别为 2，4，8。
当拥塞窗口 cwnd = ssthresh 时，进入拥塞避免阶段，其窗口大小依次是 9，10，11，12，直到上升到 12 为止发生拥塞；然后把门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5，门限值 ssthresh 变为6,；然后进入慢开始，cwnd 值置为1，cwnd 按指数规律增长，随后窗口大小分别为 1，2，4，6。
当拥塞窗口 cwnd = ssthresh 时，进入拥塞避免阶段，其窗口大小依次是 7，8，9。

5-39 TCP 的拥塞窗口 cwnd 大小与传输轮次 n 的关系如表所示：

（1）试画出如教材中图 5-25 所示的拥塞窗口与传输轮次的关系曲线。
（2）指明 TCP 工作在慢开始阶段的时间间隔。
（3）指明 TCP 工作在拥塞避免阶段的时间间隔。
（4）在第 16 轮次和第 22 轮次之后发送方是通过收到三个重复的确认还是通过超时检测到丢失了报文段？
（5）在第 1 轮次，第 18 轮次和第 24 轮次发送时，门限 ssthresh 分别被设置为多大？
（6）在第几轮次发送出第 70 个报文段？
（7）假定在第 26 轮次之后收到了三个重复的确认，因而检测出了报文段的丢失，那么拥塞窗口 cwnd 和门限 ssthresh 应设置为多大？

答：(1)

（2）慢开始时间间隔：[1, 6] 和 [23, 26]
（3）拥塞避免时间间隔：[6, 16] 和 [17, 22]
（4）在第 16 轮次之后发送方通过收到三个重复的确认，检测到丢失了报文段，因为题目给出，下一个轮次的拥塞窗口减半了。在第 22 轮次之后发送方通过超时，检测到丢失了报文段，因为题目给出，下一个轮次的拥塞窗口下降到 1了。
（5）在第 1 轮次发送时，门限 ssthresh 被设置为 32，因为从第 6 轮次起就进入了拥塞避免状态，拥塞窗口每个轮次加 1。
在第 18 轮次发送时，门限 ssthresh 被设置为发生拥塞时拥塞窗口 42 的一半，即 21。
在第 24 轮次发送时，门限 ssthresh 被设置为发生拥塞时拥塞窗口 26 的一半，即 13。
（6）第 1 轮次发送报文段 1。（cwnd = 1）
第 2 轮次发送报文段 2， 3。（cwnd = 2）
第 3 轮次发送报文段 4 ~ 7。（cwnd = 4）
第 4 轮次发送报文段 8 ~ 15。（cwnd = 8）
第 5 轮次发送报文段 16 ~ 31。（cwnd = 16）
第 6 轮次发送报文段 32 ~ 63。（cwnd = 32）
第 7 轮次发送报文段 64 ~ 96。（cwnd = 33）
因此第 70 报文段在第 7 轮次发送出。
（7）检测出了报文段的丢失时拥塞窗口 cwnd 是 8，因此拥塞窗口 cwnd 的数值应当减半，等于 4，而门限 ssthresh 应设置为检测出报文段丢失时的拥塞窗口 8 的一半，即 4。

5-40 TCP 在进行流量控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有，请举出三种情况。

答：

不是因为拥塞而引起分组丢失的情况是有的，举例如下：
① 当 IP 数据报在传输过程中需要分片，但其中一个数据报片未能及时到达终点，而终点组装 IP 数据报已超时，因而只能丢弃该数据报。
② IP 数据报已经到达终点，但终点的缓存没有足够的空间存放此数据报。
③ 数据报在转发过程中经过一个局域网的网桥，但网桥在转发该数据报的帧时没有足够的储存空间而只好丢弃。

5-41 ~ 5-45

5-41 用 TCP 传送 512 字节的数据。设窗口为 100 字节，而 TCP 报文段每次也是传送 100 字节的数据。再设发送端和接收端的起始序号分别选为 100 和 200，试画出类似于教材中图 5-31 的工作示意图。从连接建立阶段到连接释放都要画上。

要传送的 512 B 的数据必须划分为 6 个报文段传送，前 5 个报文段各 100 B，最后一个报文段传送 12 B。下图是双方交互的示意图。下面进行简单的解释。
【—– 进行三报文握手 —–】
报文段 #1：A 发起主动打开，发送 SYN 报文段，除以 SYN-SENT 状态，并选择初始序号 seq = 100。B 处于 LISTEN 状态。
报文段 #2：B 确认 A 的 SYN 报文段，因此 ack = 101（是 A 的初始序号加 1）。B选择初始序号 seq = 200。B 进入到 SYN-RCVD 状态。
报文段 #3：A 发送 ACk 报文段来确认报文段 #2，ack = 201（是 B 的初始序号加 1）。A 没有在这个报文段中放入数据。因为 SYN 报文段 #1 消耗了一个序号，因此报文段 #3 的序号是 seq = 101。这样，A 和 B 都进入了 ESTABLISHED 状态。
【—– 三报文握手完成 —–】

【—– 开始数据传送 —–】
报文段 #4：A 发送 100 字节的数据。报文段 #3 是确认报文段，没有数据发送，报文段 #3 并不消耗序号，因此报文段 #4 的序号仍然是 seq = 101。A 在发送数据的同时，还确认 B 的报文段 #2，因此 ack = 201。
报文段 #5：B 确认 A 的报文段 #4。由于收到了从序号 101 到 200 共 100 字节的数据，因此在报文段 #5 中，ack = 201（所期望收到的下一个数据字节的序号）。B 发送的 SYN 报文段 #2 消耗了一个序号，因此报文段 #5 的序号是 seq = 201，比报文段 #2 的序号多了一个序号。在这个报文段中，B 给出了接收窗口 rwnd = 100。
从报文段 #6 到报文段 # 13 都不需要更多的解释。到此为止，A 已经发送了 500 字节 的数据。值得注意的是，B 发送的所有确认报文都不消耗序号，其序号都是 seq = 201。
报文段 #14：A 发送最后 12 字节的数据，报文段 #14 的序号是 seq = 601。
报文段 #15：B 发送对报文段 #14 的确认。B 收到从序号 601 到 602 共 12 字节的数据。因此，报文段 #15 的确认号是 ack = 613（所期望收到的下一个数据字节的序号）。
需要注意的是，从报文段 #5 一直到 报文段 #15，B 一共发送了 6 个确认，都不消耗序号，因此 B 发送的报文段 #15 的序号仍然和报文段 #5 的序号一样，即 seq = 201。
【—–数据传送完毕—–】
【—–进行四报文挥手——】
报文段 #16：A 发送 FIN 报文段。前面所发送的数据报文段 #14 已经用掉了序号 601 到 612，因此报文段 #16 序号是 seq = 613。A 进入 FIN-WAIT-1 状态。报文段 #16 的确认号 ack = 202。
报文段 #17：B发送确认报文段，确认号为 614，进入 CLOSE-WAIT 状态。由于确认报文段不消耗序号，因此报文段 #17 的序号仍然和报文段 #15 的一样，即 seq = 201
报文段 #18：B 没有数据要发送，就发送 FIN 报文段 #18，其序号仍然是 seq = 201。这个 FIN 报文会消耗一个报文。
报文段 #19：A 发送最后的确认报文段。报文段 #16 的序号是 613，已经消耗掉了。因此，现在的序号是 seq = 614。但这个确认报文段并不消耗序号。
【—–四报文挥手结束—–】

5-42 在图 5-29 中所示的连接释放过程中，主机 B 能否先不发送 ACK = x + 1 的确认?（因为后面要发送的连接释放报文段中仍有 ACK = x + 1 这一信息）

答：

如果 B 不再发送数据了，是可以把两个报文段合并成为一个，即只发送 FIN+ACK 报文段。但如果 B 还有数据报要发送，而且要发送一段时间，那就不行，因为 A 迟迟收不到确认，就会以为刚才发送的 FIN 报文段丢失了，就超时重传这个 FIN 报文段，浪费网络资源。

5-43 在图 5-30 中，在什么情况下会发生从状态 SYN-SENT 到状态 SYN-RCVD 的变迁？

答：

当 A 和 B 都作为客户，即同时主动打开 TCP 连接。这时的每一方的状态变迁都是：
CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED

5-44 试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。

答：

设 A，B建立了运输连接。
协议应考虑一下实际可能性： A 或 B 故障，应设计超时机制，使对方退出，不至于死锁；
A主动退出，B被动退出
B主动退出，A被动退出

5-45 解释为什么突然释放运输连接就可能会丢失用户数据，而使用 TCP 的连接释放方法就可保证不丢失数据。

答：
当主机 1 和主机 2 之间连接建立后，主机 1 发送了一个 TCP 数据段并正确抵达主机 2，接着主机 1 发送另一个TCP数据段，这次很不幸，主机 2 在收到第二个 TCP 数据段之前发出了释放连接请求，如果就这样突然释放连接，显然主机 1 发送的第二个 TCP 报文段会丢失。
而使用 TCP 的连接释放方法，主机 2 发出了释放连接的请求，那么即使收到主机 1 的确认后，只会释放主机 2 到主机 1 方向的连接，即主机 2 不再向主机 1 发送数据，而仍然可接收主机 1 发来的数据，所以可保证不丢失数据。