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

---

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

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

---

5-46 ~ 5-50

5-46 试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况。

答：

3 次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
假定 B 给 A 发送一个连接请求分组，A 收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A 认为连接已经成功地建立了，可以开始发送数据分组。可是，B 在 A 的应答分组在传输中被丢失的情况下，将不知道 A 是否已准备好，不知道 A 建议什么样的序列号，B 甚至怀疑 A 是否收到自己的连接请求分组，在这种情况下，B 认为连接还未建立成功，将忽略 A 发来的任何数据分组，只等待连接确认应答分组。而 A 发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

5-47 一个客户向服务器请求建立 TCP 连接。客户在 TCP 连接建立的三次握手中的最后一个报文段中捎带上一些数据，请求服务器发送一个长度为 L 字节的文件。假定：
（1）客户和服务器之间的数据传输速率是 R 字节/秒，客户与服务器之间的往返时间是 RTT（固定值）。
（2）服务器发送的 TCP 报文段的长度都是 M 字节，而发送窗口大小是 nM 字节。
（3）所有传送的报文段都不会出错（无重传），客户收到服务器发来的报文段后就及时发送确认。
（4）所有的协议首部开销都可忽略，所有确认报文段和连接建立阶段的报文段的长度都可忽略（即忽略这些报文段的发送时间）。
试证明，从客户开始发起连接建立到接收服务器发送的整个文件多需的时间 T 是：T = 2RTT + L/R，当 nM > R(RTT) + M
或 T= 2RTT + L/R + (K – 1)[ M/R + RTT – nM/R]，当 nM < R(RTT) + M
其中，K=『L/nM』，符号『x』表示若 x 不是整数，则把 x 的整数部分加 1。
（提示：求证的第一个等式发生在发送窗口较大的情况，可以连续把文件发送完。求证的第二个等式发生在发送窗口较小的情况，发送几个报文段后就必须停顿下来，等收到确认后再继续发送。建议先画出双方交互的时间图，然后再进行推导。）

答：

先看图（a）：
M/R 是一个报文段的发送时间（一个报文段的长度除以数据率）
nM 是窗口大小，nM/R 是把窗口内的数据都发送完所需要的时间。
如果 nM/R > M/R + RTT ，那么服务器在发送窗口内的数据还没有发送完，就收到客户的确认，因此，服务器可以连续发送，直到全部数据发送完毕。
这个不等式两边都乘以 R，就得出等效的条件：
当 nM > R(RTT) + M 发送窗口内的数据还没有发送完就收到确认，因此，服务器可以连续发送，直到全部数据发送完毕。
因此，客户接收全部数据所需的时间是：
T = 2RTT + L/R，当 nM > R(RTT) +
再看图（b）：
当 nM > R(RTT) + M 时，服务器把发送窗口内的数据发送完毕时还收不到确认，因此必须停止发送。从图中可知，停止的时间间隔是 M/R + RTT – nM/R。
整个文件 L 要划分为 K =『L/nM』次传送，停止的时间间隔有（K-1）个。这样就证明了求证的公式：
T = 2RTT + L/R + (K-1)[M/R + RTT – nM/R]，当 nM < R(RTT) + M

5-48 网络允许的最大报文段长度为 128 字节，序号用 8 比特表示，报文段在网络中的寿命为 30 s。求发送报文段的一方所能达到的最高数据率。

解：

根据题意，先可以做出以下一些假设：
（1）本题不是使用 TCP 协议，因为序号字段是 8 位，而不是 TCP 的 32 位。
（2）既然不是使用 TCP 协议，当然也不是使用 TCP 协议得到首部。现在的报文段的首部是什么样子，和我们解题没有关系。我们不用管它。我们只需要知道的是，现在的报文段的首部有一个序号字段。
（3）显然，现在不是给报文中的每一个字节编上序号，而是给每一个报文编上序号。
（4）报文段的传送应当使用滑动窗口协议（而不是停止等待协议），这样可得到较高的效率。
我们知道，在使用滑动窗口协议时，在没有收到确认的情况下，8 位的序号字段可连续发送 255 个序号( 2 n − 1 2^n-1 2n−1)的报文段。
那么一共可以发送的比特数为255×128×8=261120bit
数据率=比特数/时间
最高数据率=261120bit/30s=8704bit/s

5-49 下面是以十六进制格式存储的一个 UDP 首部：
CB84000D001C001C
试问:
(1) 源端口号是什么？
(2) 目的端口号是什么？
(3) 这个用户数据报的总长度是什么？
(4) 数据长度是多少？
(5)这个分组是从客户到服务器还是从服务器到客户？
(6) 客户进程是什么？

答：

(1)源端口号是最前面的四位十六进制数(CB84)16=(52100)10
(2)目的端口号是五到八位的十六进制数(000D)16=(13)10
(3)用户数据报的长度由九到十二位十六进制数决定(001C)16=(28)10字节。
(4)数据长度=数据报长度-首部长度=28字节-8字节=20字节。
(5)因为目的端口是 13 （熟知端口），所以这个分组是从客户到目的端口。
(6)从 RFC 867 可以得知，这个客户进程是 Daytime。当 Daytime 服务器收到客户发送的 UDP 用户数据报后，就把现在的日期和时间以 ASCII 码字符串的形式返回给客户。

5-50 把教材上的图 5-7 计算 UDP 检验和的例子自己具体演算一下，看是否能够得出书上的计算结果。

可以使用两种方法进行二进制反码求和的运算。一种方法是把这 14 行的 16 位数据一起从低位到高位逐位相加。另一种方法是把这 14 行的 16 位数据两行两行地相加（即二进制反码求和）
我们这里使用后一种方法，这里要相加 13 次。
第 1 行和 第 2 行相加，得 10100001 01111011
再和第 3 行相加，得 1 01001100 011111110。请注意，最左边（最高位）的 1 是进位得到的 1，这要和最低位相加。因此和第 3 行相加后，得 01001100 01111111。最低位的 1 就是由最高位的进位得到的。这叫做 “回卷”。
再和第 4 行相加，得 01011010 10001010。
再和第 5 行相加，得 01011010 10011011。
再和第 6 行相加，得 01011010 10101010。
再和第 7 行相加，得 01011110 11101001。
再和第 8 行相加，得 01011110 11110110。
再和第 9 行相加，得 01011111 00000101。
第 10 行是全 0，不用再计算相加。
再和第 11 行相加，得 10110011 01001010。
再和第 12 行相加，得 00000110 10011111。这里的最低位的 1 由最高位的进位回卷得到的。
再和第 13 行相加，得 01001111 11101101。
再和第 14 行相加，得 10010110 11101101。这就是二进制反码求和的结果。把这个结果求反码（1 换成 0 而 0 换成 1），得出：01101001 00010010。这就是应当写在检验和字段的数。和书上给出的结果是一致的。
UDP 用户数据报传送到接收端后，再进行检验和计算。这就是把收到的 UDP 用户数据报连同伪首部（以及可能的填充全零字节）一起，按二进制反码求这些 16 位字的和。当无差错时其结果应当全 1。否则就表明有差错出现，接收方就应丢弃这个 UDP 用户数据报（也可以上交应用层，但附上出现差错的警告）。

5-51 ~ 5-55

5-51 在以下几种情况下，UDP 的检验和在发送时数值分别是多少？
（1）发送方决定不使用检验和。
（2）发送方使用检验和，检验和的数值是全 1。
（3）发送方使用检验和，检验和的数值是全 0。

答：

（1）UDP 规定，UDP 的上层用户可以关闭检验和的计算（即在 UDP 的传送过程中，不使用检验和这个检错功能）。这样做的好处是可以提高 UDP 的传送速度（但要牺牲一些可靠性）。如果发送方决定不使用检验和，那么发送方的检验和的值应当置为全 0。这表示这个数值不是计算出来的，而是发送方关闭了检验和这个功能。
（2）如果发送方使用检验和，但检验和的数值是全 1。
我们可以想一想，怎么会出现这种情况。如果计算检验和最后的结果是全 1，就表明得出这个结果的前一个步骤（即二进制反码求和）的结果是全 0。在什么情况下，伪首部和整个 UDP 按 16 位字进行二进制反码求和的结果是全 0 ？这就是伪首部和整个 UDP 的所有字段都是 0。但很明显，这是不可能的。所有的地址和数据都是 0，还有什么意义？不要以为两个 1 相加就是 0。不对。两个 1 相加按二进制反码求和的结果是 1 0。这里的 1 是进位。因为此按照计算检验和的规矩来计算，对真实的 UDP 用户数据报不可能得出检验和的数值是全 1。
但是，计算检验和时的倒数第二步，即按二进制反码求和的结果却有可能是全 1。在这种情况下，最后一步求反码，就会得出检验和是全 0。但是前面我们已经讲过，检验和置为全 0是表示发送方不使用检验和。这样就产生了疑问：如果检验和是全 0，是发送方不使用检验和？还是使用了检验和但检验和的结果碰巧全是 0？无法确定。于是 UDP 协议就规定：如果计算检验和的结果刚好是全 0，那么就把它人为的置为全 1。因为前面已经讲过，全 1 的检验和是不可能由计算出来的。因此接收方一旦收到检验和为全 1 的 UDP 用户数据报，就知道这是人为的，真正地检验和其实是全 0。
（3）发送方使用检验和，检验和的数值是全 0。
前面已经讲过，这是不可能的。如果发送方计算出来的检验和是全 0，那也要把它变成全 1 再发送出去。

5-52 UDP 和 IP 的不可靠程度是否相同? 请加以解释。

答：

① UDP 和 IP 都是无连接的协议和不可靠传输的协议。UDP 用户数据报和 IP 数据报的首部都有检验和字段。当检验出现差错时，就把收到的 UDP 用户数据报或 IP 数据报丢弃。这是它们的相同之处。
② 但 UDP 和 IP 的可靠性是有些区别的。UDP 用户数据报的检验和是既检验 UDP 用户数据报的首部又检验整个的 UDP 用户数据报的数据部分，而 IP 数据报的检验和仅仅检验 IP 数据报的首部。UDP 用户数据报的检验和还增加了伪首部，即还检验了下面的 IP 数据报的源 IP 地址和目的 IP 地址。

5-53 UDP 用户数据报的最小长度是多少？用最小长度的 UDP 用户数据报构成的最短 IP 数据报的长度是多少？

答：

UDP 用户数据报的最小长度是 8 字节，即仅有首部而没有数据。用最小长度的 UDP 源用户数据报构成的最短 IP 数据报的长度为 28 字节。此 IP 数据报具有 20 字节的固定首部，首部中没有可选字段。

5-54 某客户使用 UDP 将数据发送给一服务器，数据共 16 字节。试计算在运输层的传输效率（有用字节与总字节之比）。

解：

UDP的数据报总长度=16+8=24字节
传输效率=(16/24)×100%=66.7%

5-55 重做 54，但在 IP 层计算传输效率。假定 IP 首部无选项。

解：

IP数据报总长度=24+20=44字节
传输效率=(16/44)×100%=32.4%

5-56 ~ 5-60

5-56 重做 54，但在数据链路层计算传输效率。假定 IP 首部无选项，在数据链路层使用以太网。

解：

以太网有 14 字节的首部，4 字节的尾部（FCS 字段），发送以太网的帧之前还有 8 字节的前同步码。但其数据字段的最小长度是 46 字节，而我们的 IP 数据报仅有 44 字节，因此还必须加上 2 字节的填充。这样，以太网的总长度 = 14 + 4 + 8 + 2 + 44 = 72 字节。
传输效率=(16/72)×100%=22.2%

5-57 某客户有 67000 字节的分组。试说明怎样使用 UDP 用户数据将这个分组进行传送。

答：

一个 UDP 用户数据报的最大长度为 65535 字节。现在的长度超过了这个限度，因此不能使用一个 UDP 用户数据报来传送。必须进行切割（例如，分割为两个 UDP 用户数据报），使其长度不超过以上的限度。

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

解：

根据 Karn 算法，只要是 TCP 报文段重传了，就不采用其往返时间样本。本题中收到的确认是在重传后收到的。因此 RTT 没有变化，仍然是以前的数值（4 秒）。
Karn算法：运输层用来控制流量算法。在计算平均往返时延 RTT 时，只要报文段重传了，就不采用其往返时延样本。这样得出的平均往返时延 RTT 和重传时间就较准确。

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

答：

在这之前和在这之后的窗口情况如下图所示。
这里要注意的是：发送窗口为 1000 字节，窗口里面的序号也正好是 1000 个。号码小在后面，即在图的左方。另外一点要注意的是，发送方收到的确认号表示接收方期望能够收到序号。这个序号应当在发送窗口的最前面。

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

答：在这之前与之后的窗口情况如下图所示：