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

本文主要是介绍第五章 | 计算机网络原理 谢希仁（第八版）_ 习题答案（Part 5），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

---

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

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

---

5-61 ~ 5-65

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）我们应当注意到，发送窗口 = 2 KB 就是 2 ×1024 = 2048 字节。因此，发送窗口应当是从 0 到第 2047 字节为止，长度是 2048 字节。A 开始就发送了 1024 字节，因此发送窗口中左边的 1024 个字节已经用掉了（窗口的这部分为灰色），而可用窗口是白色的，从第 1024 字节到第 2047 字节位置。请注意，不是到第 2048 字节位置，因此第一个编号是 0 而不是 1。
（2）发送方 A 一直发送数据，直到把发送窗口用完。这时，整个窗口都已用掉了，可用窗口的大小已经是零了，一个字节也不能发送了。
（3）发送方 A 收到对第 1000 字节的确认报文段，表明 A 收到确认号 ack = 1001 的确认报文段。这时，发送窗口的后沿向前移动，发送窗口从第 1001 字节（不是从第 1000 字节）到第 3048 字节（不是第 3047 字节）为止。可用窗口从第 2048 字节到第 3048 字节。【注意，因为从 1001 起，3048 – 1001 + 1 = 2048】
（4）发送方 A 再发送 850 字节，使得可用窗口的后沿向前移动 850 字节，即移动到 2898 字节。现在的可用窗口从第 2898 字节到 3048 字节。
（5）发送方 A 收到 ack = 900 的确认报文段，不会对其窗口状态有任何影响。这是个迟到的确认。
（6）发送方 A 收到对第 2047 号字节的确认报文段。A 的发送窗口再向前移动。现在的发送窗口从第 2048 字节开始到第 4095 字节。可用窗口增大了，从第 2898 字节第 4095 字节。
（7）发送方 A 把剩下的数据全部发送完。发送方 A 共有 3 KB（即 3072 字节）的数据，其编号从 0 到 3071。因此现在的可用窗口变小了，从第 3072 字节到第 4095 字节。
（8）发送方 A 收到 ack = 3072 的确认报文段，表明序号在 3071 和这以前的报文段都收到了，后面期望收到的报文段的序号熊 3072 开始。因此新的发送窗口的位置又向前移动，从第 3072 号字节到第 5119 号字节。整个发送窗口也就是可用窗口。

5-62 TCP 连接处于 ESTABLISHED 状态。以下的事件相继发生：
（1）收到一个 FIN 报文段。
（2）应用程序发送 “关闭” 报文。
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？

答：

（1）处于 ESTABLISHED 状态又能够收到一个 FIN 报文段，只有 TCP 的服务器端而不会是客户端。当这个服务器端收到 FIN 时，服务器就向客户端发送 ACK 报文段，并进入到 CLOSE-WAIT 状态。这是被动关闭。请注意，这时客户端不会再发送数据了，但服务器端如还有数据要发送给客户端，那么还是可以继续发送的。

（2）应用程序发送 “关闭” 报文给服务器，表明没有数据要发送了。这时服务器就应当发送 FIN 报文段给客户，然后转换到 LAST-ACK 状态，并等待来自客户端的最后的确认。
以上的状态转换可参考教材上的图 5-30。

5-63 TCP 连接处于 SYN-RCVD 状态。以下的事件相继发生：
（1）应用程序发送 “关闭” 报文。
（2）收到 FIN 报文段。
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？

答：

（1）处于 SYN-RCVD 状态而又能够收到应用程序发送的 “关闭” 报文的，只有 TCP 的客户端而不会是服务器端。这时，客户端就应当向服务器端发送 FIN 报文段，然后进入到 FIN-WAIT-1 状态。

（2）当客户收到服务器端发送的 FIN 报文段后，就向服务器发送 ACK 报文段，并进入到 CLOSED 状态。
以上的状态转换可参考教材上的图 5-30。

5-64 TCP 连接处于 FIN-WAIT-1 状态。以下的事件相继发生：
（1）收到 ACK 报文段。
（2）收到 FIN 报文段。
（3）发生了超时。
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？

答：

（1）处于 FIN-WAIT-1 状态的只有 TCP 的客户。当收到 ACK 报文段后，TCP 客户不发送任何报文段，只是从 FIN-WAIT-1 状态进入到 FIN-WAIT-2 状态。

（2）在收到 FIN 报文段后，TCP 客户发送 ACK 报文段，并进入到 TIME-WAIT 状态。
（3）当发生了超时，也就是经过了 2 MSL时间后，TCP 客户进入到 CLOSED 状态。
以上的状态转换可参考教材上的图 5-30。

5-65 假定主机 A 向 B 发送一个 TCP 报文段。在这个报文段中，序号是 50，而数据一共有 6 字节长。试问，在这个报文段中的确认字段是否应当写入 56？

答：

在这个报文段中的确认字段应当写入的是B期望下次收到A发送的数据中的第一个字节的编号，而这个数值是B已经收到的数据的最后一个字节的编号加 1。然而这些在题目中并未给出。题目给出的是 A 向 B 发送的数据中第一个字节的编号是 50，并且在这个报文段中共有 6 字节的数据。这些都和此报文段中的确认字段是什么毫无关系。因此，现在我们无法知道这个报文段中的确认字段应当写入的数值。

5-66 ~ 5-70

5-66 主机 A 通过 TCP 连接向 B 发送一个很长的文件，因此这需要分成很多个报文段来发送。假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号是否就是 x + 1 呢？

答：

假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号应当是 x+n，这里的 n 是这个报文段中的数据长度的字节数。如 n = 4000，那么下一个报文段的序号应当是 x + 4000。若此报文段中仅有一个字节的数据，则下一个报文段的序号才是 x + 1。

5-67 TCP 的吞吐量应当是每秒发送的数据字节数，还是每秒发送的首部和数据之和的字节数？吞吐量应当是每秒发送的字节数，还是每秒发送的比特数？

答:

① TCP 的吞吐量本来并没有标准的定义，可以计入首部，也可以不计入首部，但应当说清楚。不过，从拥塞控制来看，拥塞窗口和发送窗口针对的都是 TCP 报文段中的数据字段，而重要的参数 MSS 也是指 TCP 报文段中的数据字段的长度，因此，把 TCP 的吞吐量定义为每秒发送的数据字节数是比较方便的。
② 计算机内部的数据传送是以每秒多少字节作为单位的，而在通信线路上的数据率则常用每秒多少比特作为单位。这两种表示方法并无实质上的差别。在上面的习题中，因为 MSS 用字节作为单位，因此，用每秒发送多少字节作为 TCP 吞吐量的单位就比较简单一些。

5-68 在 TCP 的连接建立的三报文握手过程中，为什么第三个报文段不需要对方的确认？这会不会出现问题？

答：

① 关于这个问题，还不能简单地用 “是” 或 “否” 来回答。
② 我们假定 A 是客户端，是发起 TCP 连接建立一方。现在假定三报文握手过程中的第三个报文段（也就是 A 发送的第二个报文段 —— 确认报文）丢失了，而 A 并不知道。这是，A 以为对方收到了这个报文段，以为 TCP 连接已经建立，于是就开始发送数据报文段给 B。
③ B 由于没有收到三报文握手中的最后一个报文段（A 发送的确认报文段），因此 B 就不能进入 TCP 的 ESTABLISHED 状态（“连接已建立” 状态）。B 的这种状态可以叫做 “半开连接” ，即仅仅把 TCP 连接打开了一半。在这种状态下，B 虽然已经初始化了连接变量和缓存，但是不能接收数据。通常，B 在经过一段时间后（例如，一分钟后） ，如果还没有收到来自 A 的确认报文段，就终止这个半开连接状态，那么 A 就必须重新建立 TCP 连接。因此，在这种情况下，第三个报文段（A 发送的第二个报文段）的丢失，就导致了 TCP 连接无法建立。
④ 但是，假定 A 在这段时间内，紧接着就发送了数据。我们知道，TCP 具有累计确认的功能。在 A 发送的数据报文段中，自己的序号也没有改变，仍然是和丢失的确认真的序号一样（丢失的那个确认帧不消耗序号），并且确认位 ACK = 1，确认号也是 B 的初始序号加 1。当 B 收到这个报文段后，从 TCP 的首部就可以知道，A 已确认了 B 刚才发送的 SYN + ACK 报文段，于是就进入了 ESTABLISHED 状态（“连接已建立” 状态）。接着，就接收 A 发送的数据。在这种情况下，A 丢失的第二个报文段对 TCP 的连接建立就没有影响。
⑤ 大家知道，A 在发送第二个报文段时，可以有两种选择：
（1）仅仅是确认而不携带数据，数据接着在后面发送。
（2）不仅是确认，而且携带上自己的数据。
⑥ 在第一种选择时，A 在下一个报文段发送自己的数据。但下一个报文的首部中仍然包括了对 B 的 SYN + ACK 报文段的确认，即和第二种选择发送的报文段一样。
⑦ 在第二种选择时，A 省略了单独发送一个确认报文段。
从这里也可以看出，A 发送的第二个仅仅是确认的报文段，是个可以省略的报文段，即使丢失了也无妨，只要下面紧接着就可以发送数据报文段即可。

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

解：

发送窗口至少能够容纳的比特数=传输速率×RTT=1Gbit/s × 140ms=1.75× 1 0 7 10^7 107bit
我们知道，每一个字节的数据需要有一个编号。假定发送窗口一共有 w 位，那么总的号码数应当大于1.75× 1 0 7 10^7 107字节，即： 2 w 2^w 2w>17500000，那么w>24.06，那么发送窗口至少为25位。
可见只用 24 位的发送窗口差一点，必须使用 w = 25 位的发送窗口才行。TCP 的窗口字段为 16 位。
再看看 60 秒钟以1Gbit/s 的速率可以发送 60s× 1 0 9 10^9 109bit/s=7.5× 1 0 9 10^9 109字节的数据。
假定需要 n 位的序号字段，那么总的序号数应当大于 7.5× 1 0 9 10^9 109字节，即：
2 n 2^n 2n > 7.5 × 1 0 9 10^9 109,求得n=32.8
因此，取序号字段长度 n = 33 位即可保证在报文段的最大生产时间内没有重复的序号。但TCP 的序号字段为 32 位(因为TCP的序号字段范围是0~32位)。

5-70 假定用 TCP 协议在 40 Gbit/s 的线路上传送数据。
（1）如果 TCP 充分利用了线路的带宽，那么需要多长的时间 TCP 会发生序号绕回？
（2）假定现在 TCP 的首部中采用了时间戳选项。时间戳占用了 4 字节，共 32 位。每隔一定的时间（这段时间叫做一个滴答）时间戳的数值加 1。假定设计的时间戳是每隔 859 微秒，时间戳的数值加 1。试问要经过多长时间才发生时间戳数值的绕回。

解：

(1)40Gbit/s的线路上每秒可以传送5× 1 0 9 10^9 109个字节。TCP序号共有 2 32 2^{32} 232个。那么需要经过 2 32 2^{32} 232/ 5 × 1 0 9 5×10^9 5×109=0.859s就会发生TCP序号绕回。
(2)时间戳绕回时间： 2 3 2 2^32 232×0.000859s=3.69× 1 0 6 10^6 106=42.7天。

5-71 ~ 5-74

5-71 5.5 节中指出：例如，若用 2.5 Gbit/s 速率发送报文段，则不到 14 秒钟序号就会重复。请计算验证这句话。

证明：

2.5Gbit/s的速率，那么每秒就可以发送0.3125× 1 0 9 10^9 109个字节，一共有 2 32 2^{32} 232个序号， 2 32 2^{32} 232/0.3125× 1 0 9 10^9 109=13.74S。所以这不到14秒，TCP序号就会发生绕回。

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

答：

（1）这是题目开始的情况。接收方发送的确认报文段中的接收窗口 rwnd = 600。已确认的序号是 300。接收方发送的确认报文段的 ack = 301，表示期望收到开始的序号为 301 的数据。我们看到，序号 301 到 900 都在接收窗口内。
（2）接收窗口增大总是不受限制的。这就是说，只要接收端的 TCP 能够拿出更多的空间来接收发来的数据，就可以这样做。图中给出的例子是：已确认的序号是 400，接收方发送的确认报文段为 ack = 401。假定现在接收窗口从情况（1）的 600 增大到了 700，即 rwnd = 700。现在接收窗口的范围是从 401 到 1100。当接收窗口增大时，接收窗口的前沿总是向前移动的。
（3）这种情况是接收窗口变小了，但接收窗口的前沿没有变化。例如，现在的已确认的序号是 400，接收方发送的确认报文段的 ack = 401。假定现在接收窗口从情况（1）的 600 减少到了 500，即 rwnd = 500。接收窗口的范围是从 501 到 1000。
（4）这种情况是接收窗口变小了，同时接收窗口的前言页向前移动了。例如，现在已确认的序号是 500，接收方发送的确认报文段的 ack = 501。假定现在接收窗口从情况 (1) 的 600 减少到了 500，即 rwnd = 500。接收窗口的范围是从 501 到 1000。
（5）这种情况是接收窗口变小了，但接收窗口的前沿是后退的。例如，现在已确认的序号是 500，接收方发送的确认报文段的 ack = 501。假定现在接收窗口从情况（1）的 600 减小到了 300，即 rwnd = 300。接收窗口的范围是从 501 到800。但请注意，这种情况是不允许出现的。也就是说，接收窗口的前沿是不允许后退的。在开始时，接收窗口的前沿的编号是 900。不管是接收窗口是变大还是变小，这个窗口的前沿的编号可以不动，也可以前移，但是不允许后退。
为什么不允许出现这种情况呢？可以先观察一下发送方的情况。在一开始，发送方收到接收窗口 = 600 的报文段后（其中 ack = 301），发送方就把发送窗口设置为 600，可以发送的数据的序号从 301 到 900。假定发送方发送了在发送窗口内的全部数据。这本来正好落入到接收窗口之内。但这些数据正在网络中传输时，接收方却缩小了接收窗口，只接收序号从 501 到 800 之间的数据。这就导致最后的一些数据（编号从 801 到 900）落入接收窗口之外，使得接收方只能丢弃这些数据（编号从 801 到 900）。因此，这种情况（在发送时数据是在发送窗口之内，但到达接收端，这些数据却落入到接收窗口之外）必须避免。总之，我们要记住，接收窗口是不允许后退的。

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

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

5-74 流量控制和拥塞控制的最主要的区别是什么？发送窗口的大小取决于流量控制还是拥塞控制？

简单地说，流量控制是在一条 TCP 连接中的接收端才用的措施，用来限制对方（发送端）发送报文的速率，以免在接收端来不及接收。流量控制只控制一个发送端。
拥塞控制是用来控制 TCP 连接中发送端发送报文段的速率，以免使互联网中的某处产生过载。拥塞控制可能会同时控制许多个发送端，限制它们的发送速率。不过每一个发送端只知道自己应当怎样调整发送速率，而不知道在互联网中还有哪些主机被限制了发送速率。
我们知道，发送窗口的上限值是 Min [rwnd, cwnd]，即发送窗口的数值不能超过接收窗口和拥塞窗口中娇小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制，而拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。因此，当接收窗口小于拥塞窗口时，发送窗口的大小取决于流量控制，即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时，则发送窗口的大小取决于拥塞控制，即取决于整个网络的拥塞状况。

这篇关于第五章 | 计算机网络原理 谢希仁（第八版）_ 习题答案（Part 5）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---