计算机网络原理(谢希仁第八版)第五章课后习题答案

Posted 爱栗创

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了计算机网络原理(谢希仁第八版)第五章课后习题答案相关的知识,希望对你有一定的参考价值。

第五章

35题,36题已经做了更正,特别感谢粉丝奈七七的答案。
1.试说明运输层在协议栈中的地位和作用,运输层的通信和网络层的通信有什么重要区别?为什么运输层是必不可少的?
答:运输层处于面向通信部分的最高层,同时也是用户功能中的最低层,向它上面的应用层提供服务 运输层为应用进程之间提供端到端的逻辑通信,但网络层是为主机之间提供逻辑通信(面向主机,承担路由功能,即主机寻址及有效的分组交换)。 各种应用进程之间通信需要“可靠或尽力而为”的两类服务质量,必须由运输层以复用和分用的形式加载到网络层。
2.网络层提供数据报或虚电路服务对上面的运输层有何影响?
答:网络层提供数据报或虚电路服务不影响上面的运输层的运行机制。 但提供不同的服务质量。
3.当应用程序使用面向连接的TCP和无连接的IP时,这种传输是面向连接的还是面向无连接的?
答:都是。这要在不同层次来看,在运输层是面向连接的,在网络层则是无连接的。
4.试用画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上,而这条运输连接有复用到IP数据报上。
答:

在图中,主机H3同时和主机H1和主机H2进行通信。H1和H3两个应用进程(HTTP和SMTP)进行通信,这需要使用两个TCP连接。这两个TCP连接所传送的报文段,使用下面的网络层IP数据报进行传送。H2和H3的应用进程(HTTP)进行通信,这需要使用一个TCP进行连接。这个TCP连接所传送的报文段,也要使用下面的网络层IP数据报进行传送。在网络层所传送的IP数据报已看不到运输层以上的复用情况。
5.试举例说明有些应用程序愿意采用不可靠的UDP,而不用采用可靠TCP。
答:VOIP:由于语音信息具有一定的冗余度,人耳对VOIP数据报损失由一定的承受度,但对传输时延的变化较敏感。有差错的UDP数据报在接收端被直接抛弃,TCP数据报出错则会引起重传,可能带来较大的时延扰动。因此VOIP宁可采用不可靠的UDP,而不愿意采用可靠的TCP。
6.接收方收到有差错的UDP用户数据报时应如何处理?
答:丢弃。
7.如果应用程序愿意使用UDP来完成可靠的传输,这可能吗?请说明理由。
答:可能,但应用程序中必须额外提供与TCP相同的功能。
8.为什么说UDP是面向报文的,而TCP是面向字节流的?
答:发送方 UDP 对应用程序交下来的报文,在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。接收方 UDP 对 IP 层交上来的 UDP 用户数据报,在去除首部后就原封不动地交付上层的应用进程,一次交付一个完整的报文。发送方TCP对应用程序交下来的报文数据块,视为无结构的字节流(无边界约束,课分拆/合并),但维持各字节。
9.端口的作用是什么?为什么端口要划分为三种?
答:端口的作用是对TCP/IP体系的应用进程进行统一的标志,使运行不同操作系统的计算机的应用进程能够互相通信。熟知端口,数值一般为0——1023.标记常规的服务进程;登记端口号,数值为1024——49151,标记没有熟知端口号的非常规的服务进程。
10.试说明运输层中伪首部的作用。
答:用于计算运输层数据报校验和。
11.某个应用进程使用运输层的用户数据报UDP,然而继续向下交给IP层后,又封装成IP数据报。既然都是数据报,可否跳过UDP而直接交给IP层?哪些功能UDP提供了但IP没提提供?
答:不可跳过UDP而直接交给IP层IP数据报IP报承担主机寻址,提供报头检错;只能找到目的主机而无法找到目的进程。UDP提供对应用进程的复用和分用功能,以及提供对数据差分的差错检验。
12.一个应用程序用UDP,到IP层把数据报在划分为4个数据报片发送出去,结果前两个数据报片丢失,后两个到达目的站。过了一段时间应用程序重传UDP,而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问:在目的站能否将这两次传输的4个数据报片组装成完整的数据报?假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。
答:不行。重传时,IP数据报的标识字段会有另一个标识符。仅当标识符相同的IP数据报片才能组装成一个IP数据报。前两个IP数据报片的标识符与后两个IP数据报片的标识符不同,因此不能组装成一个IP数据报。
13.一个UDP用户数据的数据字段为8192字节。在数据链路层要使用以太网来传送。试问应当划分为几个IP数据报片?说明每一个IP数据报字段长度和片偏移字段的值。
答:UDP数据报 = 首部8字节 + 数据部分组成。
因为数据字段为8192字节,所以数据报总长度 = 8192 + 8 = 8200 字节。
以太网的最大传输单元MTU = 1500。
因为要划分为几个IP数据报,而每个IP数据报的首部占20字节,所以字段部分最大占1480字节。
划分的时候,可以划分为 8200 / 1480 = 5,余 800 字节。
所以应当划分为 6 个IP数据报片,前 5 个都是 1480 字节,第 6 个是 800 字节。一个字段即为8个字节。
第一个IP数据报字段长度:1480,第一片偏移字段:1480 * 0 / 8 = 0
第二个IP数据报字段长度:1480,第二片偏移字段:1480 * 1 / 8 = 185
第三个IP数据报字段长度:1480,第三片偏移字段:1480 * 2 / 8 = 370
第四个IP数据报字段长度:1480,第四片偏移字段:1480 * 3 / 8 = 555
第五个IP数据报字段长度:1480,第五片偏移字段:1480 * 4 / 8 = 740
第六个IP数据报字段长度:800, 第六片偏移字段:1480 * 5 / 8 = 925
UDP数据报的首部存在于第一个IP数据报片中,所以第一个IP数据报字段为:首部8字节 + 1472数据部分。
14.一UDP用户数据报的首部十六进制表示是:06 32 00 45 00 1C E2 17.试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器还是服务器发送给客户?使用UDP的这个服务器程序是什么?
解:源端口:1586(前4个字节0632)
目的端口:69(00 45)
用户数据报总长度:28 字节(00 1C,其中首部占8字节)
数据部分长度:20 字节
这个用户数据报是:从客户发送给服务器
服务器程序:TFTP。
UDP数据报由首部字段和数据字段组成,其中首部占8个字节(TCP数据报首部占20字节),格式如下:

以上求出的长度为UDP数据报的总长度28字节,由于UDP数据报的首部占8字节,所以数据字段长度占20字节
因为目的端口号 69 < 1023,是常用的服务端口,所以这个数据报是发往服务器端的
0~1023:常用的服务端口
1024~49151是被注册的端口,也成为“用户端口”
其中 1024~5000为临时端口
因为端口号为69,所以使用 UDP 的这个服务器程序是TFTP
TFTP:是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议,提供不复杂、开销不大的文件传输服务。端口号为69。
15.使用TCP对实时话音数据的传输有没有什么问题?使用UDP在传送数据文件时会有什么问题?
答:如果语音数据不是实时播放(边接受边播放)就可以使用TCP,因为TCP传输可靠。接收端用TCP讲话音数据接受完毕后,可以在以后的任何时间进行播放。但假定是实时传输,则必须使用UDP。 UDP不保证可靠付,但UCP比TCP的开销要小很多。因此只要应用程序接受这样的服务质量就可以使用UDP。
16.在停止等待协议中如果不使用编号是否可行?为什么?
答:不可行,分组和确认分组都必须进行编号,才能明确哪个分则得到了确认。
17.在停止等待协议中,如果收到重复的报文段时不予理睬(即悄悄地丢弃它而其他什么也没做)是否可行?试举出具体的例子说明理由。
答:可行,比如收到重复的报文段不确认相当于确认丢失。
18.假定在运输层使用停止等待协议。发送发在发送报文段M0后再设定的时间内未收到确认,于是重传M0,但M0又迟迟不能到达接收方。不久,发送方收到了迟到的对M0的确认,于是发送下一个报文段M1,不久就收到了对M1的确认。接着发送方发送新的报文段M0,但这个新的M0在传送过程中丢失了。正巧,一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨M0是旧的。于是收下M0,并发送确认。显然,接收方后来收到的M0是重复的,协议失败了。试画出类似于图5-9所示的双方交换报文段的过程。
答:
我们可以看出,旧的M0被当成是新的M0!可见运输层不能使用停止等待协议(编号只有 0 和1 两种)。
19.试证明:当用 n 比特进行分组的编号时,若接收到窗口等于 1(即只能按序接收分组),当仅在发送窗口不超过 2 n − 1 2^n-1 2n1时,连接 ARQ 协议才能正确运行。窗口单位是分组。
答:

Ⅰ、设发送窗口记为 WT,接收窗口记为 WR。假定用 3 比特进行编号。设接收窗口正好在 7 号分组处(有阴影的分组)。
Ⅱ、发送窗口 WT的位置不可能比 ② 的位置更靠前。因为接收窗口的位置表明接收方正在等待接收 7 号分组,而这时的发送方不可能已经收到了对 7 号分组的确认。因此发送窗口必须包括 7 号分组,也就是不可能比 ② 的位置更靠前(前方就是图的右方)。
Ⅲ、发送窗口 WT的位置不可能比 ③ 的位置更靠后。因为接收窗口的位置表明接收方已经对 6 号分组(以及以前的分组)发送了确认。但如果发送窗口 WT的位置再靠后一个分组,即在 6 号分组的左边,那就表明还没有发送 6 号分组。但接收方的位置表明接收方已经发送了对 6 号分组的确认。这显然是不可能的。
Ⅳ、发送窗口 WT的位置可能在某个位置的中间,如 ①。
对于 ① 和 ② 的情况,在 WT的范围内必须无重复序号,即 WT 2 n 2^n 2n
对于 ③ 的情况,在 WT+ WR的范围内无重复序号,即 WT + WR 2 n 2^n 2n
现在 WR = 1,故发送窗口的最大值:WT 2 n − 1 2^n − 1 2n1
20.在连续 ARQ 协议中,若发送窗口等于 7,则发送端在开始时可连续发送 7 个分组。因此,在每一分组发送后,都要置一个超时计时器。现在计算机里只有一个硬时钟。设这 7 个分组发出的时间分别为 t0,t1,…t6,且tout都一样大。试问如何实现这 7 个超时计时器(这叫软件时钟法)?
答:
方法1:可采用链表记录,其信息域为分组的相对发送时间和分组编号来实现。当编号为 0 的分组定时时钟到期后,修改链表指针并重发此分组,同时将头指针指向编号为 1 的分组,以此类推。此类方法相当于数据结构算法里的链表建立的过程。我有一篇C++的链表文章,可以参考。

方法2:可以定义一个含有7个数据的数组,数组中的数据表示时间,当该组数据发送出去时,在对应序号的数组中填入时间值,该时间值是该组发送出去的时间+超时时间得到,如何不停的对该数组的值进行扫描,当接收到接收端的确认分组时,即将对应数组序号的时间值设置为空,准备记录下一个数据发发送时间,当系统时间大于数组中某一个时间值时,说明该分组以及超时了,需要进行重传。
21.使用连续 ARQ 协议中,发送窗口大小是 3,而序列范围 [0, 15],而传输媒体保证在接收方能够按序收到分组。在某时刻,接收方,下一个期望收到序号是 5。试问:
(1)在发送方的发送窗口中可能有出现的序号组合有哪几种?
(2)接收方已经发送出去的、但在网络中(即还未到达发送方)的确认分组可能有哪些?说明这些确认分组是用来确认哪些序号的分组。

答:
(1)在接收方,下一个期望收到的序号是 5。这表明序号到 4 为止的分组都已收到。若这些确认都已到达发送方,则发送窗口最靠前,其范围是 [5, 7]。
假定所有的分组都丢失了,发送方都没有收到这些确认。这时,发送窗口最靠后,应为 [2, 4]。因此,发送窗口可以是 [2, 4],[3, 5],[4, 6],[5, 7] 中的任何一个。
(2)接收方期望收到的序号 5 的分组,说明序号为 2,3,4 的分组都已收到,并且发送了确认。对序号为 1 的分组的确认肯定被发送方收到了,否则发送方不可能发送 4 号分组。可见,对序号为 2,3,4 的分组的确认有可能仍滞留在网络中。这些确认是用来确认序号为 2,3,4 的分组的。
22.主机 A 向主机 B 发送一个很长的文件,其长度为 L 字节。假定 TCP 使用的 MSS 有 1460 字节。
(1)在 TCP 的序号不重复使用的条件下,L 的最大值是多少?
(2)假定使用上面计算出文件长度,而运输层、网络层和数据链路层所使用的首部开销共 66 字节,链路的数据率为 10 Mb/s,试求这个文件所需的最短发送时间

答:(1)可能的序号共 2 32 2^32 232=4294967296 个。TCP 的序号是数据字段中每一个字节的编号,而不是每一个报文段的编号。因此,这一小题与报文段的长度无关,即用不到题目给出的 MSS 值。这个文件 L 的最大值就是可能的序号数,即 4294967296 字节。若1GB= 2 30 2^30 230B,则 L 的最大值为 4 GB。
(2)发送帧数等于数据字节/每帧的数据字节= 2 32 2^32 232/1460=2941758.422,需要发送 2941759 个帧。
帧首部的开销是 66×2941759 = 194156094 字节。
发送的总字节数 = 2 32 2^32 232 + 194156094 = 4489123390字节。
数据率 10 Mbilt/s = 1.25 MB/s = 1250000 字节/秒。
发送 4489123390 字节需时间为:4489123390/1250000 =3591.3 秒。
即 59.85 分,约 1 小时。
23.主机 A 向主机 B 连续发送了两个 TCP 报文段,其序号分别为 70 和 100。试问:
(1)第一个报文段携带了多少个字节的数据?
(2)主机 B 收到第一个报文段后发回的确认中的确认号应当是多少?
(3)如果主机 B 收到第二个报文段后发回的确认中的确认号是 180,试问 A 发送的第二个报文段中的数据有多少字节?
(4)如果 A 发送的第一个报文段丢失了,但第二个报文段到达了 B。B 在第二个报文段到达后向 A 发送确认。试问这个确认号应为多少?

答:
(1)第一个报文段的数据序号是 70 到 99,共 30 字节的数据。
(2)B 期望收到下一个报文段的第一个数据字节的序号为 100,因此确认号为 100。
(3)A 发送的第二个报文段中的数据中的字节数是 180 - 100 = 80 字节(实际上,就是序号 100 到序号 179 的字节,即 179 - 100 + 1 = 80 字节
(4)B 在第二个报文段到达后向 A 发送确认,其确认号应为 70。(报文段丢失,就会重复发送确认上一个未收到的报文段第一个序号,即 70)
24.一个 TCP 连接下面使用 256 kb/s 的链路,其端到端时延为 128 ms。经测试,发现吞吐量只有 120 kb/s。试问发送窗口 W 是多少?(提示:可以有两种答案,取决于接收端发出确认的时机)。
答:设发送窗口 = W(bit),再设发送端连续发送完窗口内的数据所需要的时间 = T。有两种情况:
(a)接收端在收完一批数据的最后才发出确认,因此发送端经过 (256 ms + T) 后才能发送下一个窗口的数据。
(b)接收端每收到一个很小的报文段就发回确认,因此发送端经过比 256 ms 略多一些的时间即可在发送数据。因此每经过 256 ms 就能发送一个窗口的数据。

(a):吞吐量=数据量/时间
数据量=W;时间=发送时延+往返时延=W/256kbit/s+256ms;
吞吐量=W/[(W/256kbit/s)+256ms]=120kbit/s;
求得W=57825.88bit,约等于7228字节。
(b):吞吐量=数据量/时间
数据量=W;时间=发送时延+往返时延=256ms(这里b是发送一点就确认接收一点,所以发送时延可以忽略不计。)
吞吐量=W/256ms=120kbit/s;
求得W=30720bit=3840字节。
25.为什么在 TCP 首部中要把 TCP 端口号放入最开始的 4 个字节?
答:在 ICMP 的差错报文中要包含 IP 首部后面的8个字节的内容,而这里面有 TCP 首部中的源端口和目的端口。当 TCP 收到 ICMP 差错报文时需要用这两个端口来确定是哪条连接出了差错。
26.为什么在 TCP 首部中有一个首部长度字段,而 UDP 的首部中就没有这个这个字段?
TCP 首部除固定长度部分外,还有选项,因此 TCP 首部长度是可变的。UDP 首部长度是固定的。
27.一个 TCP 报文段的数据部分最多为多少个字节?为什么?如果用户要传送的数据的字节长度超过 TCP 报文字段中的序号字段可能编出的最大序号,问还能否用 TCP 来传送?
答:(1) 一个 TCP 那段的数据部分最多为 65495 字节,此数据部分加上 TCP 首部的 20 字节,再加上 IP 首部的 20 字节,正好是 IP 数据报的最大长度 65535。(当然,若 IP 首部包含了选择,则 IP 首部长度超过20字节,这时 TCP 报文段的数据部分的长度将小于 65495 字节。)
(2)如果数据的字节长度超过 TCP 报文段中的序号字段可能编出的最大序号,仍可用 TCP 传送。编号用完后可重复使用。但应设法保证不出现编号的混乱。
IP 数据报的最大长度 = 2 1 6 2^16 216 − 1 = 65535 字节
TCP 报文段的数据部分 = IP 数据报的最大长度 - IP 数据报的首部 - TCP 报文段的首部 = 65535 - 20 - 20 = 65495 字节
一个 TCP 报文段的最大载荷是 65515 字节.
IP数据报的最大长度为 2 1 6 2^16 216 − 1= 65535 字节,减去 IP 数据报首部 20 字节和 TCP 首部 20 字节后的 TCP 报文段的数据部分为 65495 字节。

28.主机 A 向主机 B 发送 TCP 报文段,首部中的源端口是 m 而目的端口是n。当 B 向 A 发送回信时,其 TCP 报文段的首部中源端口和目的端口分别是什么?
答:当 B 向 A 发送回信时,其 TCP 报文段的首部中得到源端口就是 A 发送的 TCP 报文段首部的目的端口 n,而 B 发送的 TCP 报文段首部中的目的端口就是 A 发送的 TCP 报文段首都的源端口 m。
29.在使用 TCP 传送数据时,如果有一个确认报文段丢失了,也不一定会引起与该确认报文段对应的数据的重传。试说明理由。
答:还未重传就收到了对更高序号的确认。因为 TCP 接收方只会对按序到达的最后一个分组发送确认。当对更高的序号确认了,意味着已经到达了,即不用重传了。
30.设 TCP 使用的最大窗口为 65535 字节,而传输信道不产生差错,带宽也不受限制。若报文段的平均往返时延为 20 ms,问所能得到的最大吞吐量是多少?
解: 最大吞吐量那就是单位时间内的最大发送数据量。
即每20ms可以发送65535×8=524280bit。
吞吐量=524280bit/20ms=26.2Mb/s。
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%。
32.什么是 Karn 算法?在 TCP 的重传机制中,若不采用 Karn 算法,而是在收到确认时都认为是对重传报文段的确认,那么由此得出的往返时延样本和重传时间都会偏小。试问:重传时间最后会减小到什么程度?
答:Karn 算法允许 TCP 能够区分开有效的和无效的往返时间样本,从而改进往返时间的估算。
若不采用 Karn 算法,而是在收到确认时都认为是对重传报文段的确认,那么由此得出的往返时间样本和重传时间都会偏小。如下图所示,TCP 发送了报文段后,没有收到确认,于是超时重传报文段。但刚刚重传了报文段后,马上就收到了确认。显然,这个确认是对原来发送的报文段的确认。
但是,根据题意,我们就认为这个确认是对重传的报文段的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到很接近于零、
因此,上述的这种做法是不可取的。
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
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的变化也是很小的。
35.用TCP通过速率为1Gbit/s的链路传送一个10MB的文件。假定链路的往返时延RTT=50ms。TCP选用了窗口扩大选项,使窗口达到可选用的最大值。在接收端,TCP的接收窗口为1MB,而发送端采用拥塞控制算法,从慢开始传送。假定拥塞窗口以分组为单位计算,在一开始发送1个分组,而每个分组长度都是1KB.假定网络不会发生拥塞和分组丢失,并且发送端发送数据的速率足够快,因此发送时延可以忽略不计,而接收端每一次收完一批分组后就立即发送确认ACK分组。
(1)经过多少个RTT后,发送窗口大小达到1MB?
(2)发送端把整个10MB文件传送成功共需要多少个RTT?传送成功是指发送完整个文件,并收到所有的确认。TCP扩大的窗口够用么?
(3)根据整个文件发送成功所花费的时间(包括收到所有的确认),计算此传输链路的有效吞吐率。链路带宽的利用率是多少?

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

(2)从图中可看出,当第10个RTT结束时,已传送成功的分组是 2 10 − 1 2^10-1 2101个分组,正好比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%
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。

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 大小,使拥塞窗口缓慢增大,以防止网络过早出现拥塞。
38.设 TCP 的 ssthresh 的初始值为 8 (单位为报文段)。当拥塞窗口上升到 12 时网络发生了超时,TCP 使用慢开始和拥塞避免。试分别求出第 1 次到第 15 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗?
答:拥塞窗口大小及变化原因见下表:

轮次拥塞窗口拥塞窗口变化的原因
11网络发生了超时,TCP 使用慢开始算法
22拥塞窗口值加倍
34拥塞窗口值加倍
48拥塞窗口值加倍,这是 ssthresh 的初始值
59TCP 使用拥塞避免算法,拥塞窗口值加 1
610TCP 使用拥塞避免算法,拥塞窗口值加 1
711TCP 使用拥塞避免算法,拥塞窗口值加 1
812TCP 使用拥塞避免算法,拥塞窗口值加 1
91网络发生了超时,TCP 使用慢开始算法
102拥塞窗口值加倍
114拥塞窗口值加倍
126拥塞窗口值加倍,但到达 12 的一半时,改为拥塞避免算法
137TCP 使用拥塞避免算法,拥塞窗口值加 1
148TCP 使用拥塞避免算法,拥塞窗口值加 1
159TCP 使用拥塞避免算法,拥塞窗口值加 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。
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。
40.TCP 在进行流量控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有,请举出三种情况。
答:不是因为拥塞而引起分组丢失的情况是有的,举例如下:
① 当 IP 数据报在传输过程中需要分片,但其中一个数据报片未能及时到达终点,而终点组装 IP 数据报已超时,因而只能丢弃该数据报。
② IP 数据报已经到达终点,但终点的缓存没有足够的空间存放此数据报。
③ 数据报在转发过程中经过一个局域网的网桥,但网桥在转发该数据报的帧时没有足够的储存空间而只好丢弃。
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。但这个确认报文段并不消耗序号。
【-----四报文挥手结束-----】
42.在图 5-29 中所示的连接释放过程中,主机 B 能否先不发送 ACK = x + 1 的确认?(因为后面要发送的连接释放报文段中仍有 ACK = x + 1 这一信息)
答:
如果 B 不再发送数据了,是可以把两个报文段合并成为一个,即只发送 FIN+ACK 报文段。但如果 B 还有数据报要发送,而且要发送一段时间,那就不行,因为 A 迟迟收不到确认,就会以为刚才发送的 FIN 报文段丢失了,就超时重传这个 FIN 报文段,浪费网络资源。
43.在图 5-30 中,在什么情况下会发生从状态 SYN-SENT 到状态 SYN-RCVD 的变迁?
答:

当 A 和 B 都作为客户,即同时主动打开 TCP 连接。这时的每一方的状态变迁都是:
CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED
44.试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。
答:设 A,B建立了运输连接。
协议应考虑一下实际可能性: A 或 B 故障,应设计超时机制,使对方退出,不至于死锁;
A主动退出,B被动退出
B主动退出,A被动退出
45.解释为什么突然释放运输连接就可能会丢失用户数据,而使用 TCP 的连接释放方法就可保证不丢失数据。
答:当主机 1 和主机 2 之间连接建立后,主机 1 发送了一个 TCP 数据段并正确抵达主机 2,接着主机 1 发送另一个TCP数据段,这次很不幸,主机 2 在收到第二个 TCP 数据段之前发出了释放连接请求,如果就这样突然释放连接,显然主机 1 发送的第二个 TCP 报文段会丢失。
而使用 TCP 的连接释放方法,主机 2 发出了释放连接的请求,那么即使收到主机 1 的确认后,只会释放主机 2 到主机 1 方向的连接,即主机 2 不再向主机 1 发送数据,而仍然可接收主机 1 发来的数据,所以可保证不丢失数据。
46.试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况。
答:3 次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
假定 B 给 A 发送一个连接请求分组,A 收到了这个分组,并发送了确认应答分组。按照两次握手的协定,A 认为连接已经成功地建立了,可以开始发送数据分组。可是,B 在 A 的应答分组在传输中被丢失的情况下,将不知道 A 是否已准备好,不知道 A 建议什么样的序列号,B 甚至怀疑 A 是否收到自己的连接请求分组,在这种情况下,B 认为连接还未建立成功,将忽略 A 发来的任何数据分组,只等待连接确认应答分组。而 A 发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
47.一个客户向服务器请求建立 TCP 连接。客户在 TCP 连接建立的三次握手中的最后一个报文段中捎带上一些数据,请求服务器发送一个长度为 L

以上是关于计算机网络原理(谢希仁第八版)第五章课后习题答案的主要内容,如果未能解决你的问题,请参考以下文章

《计算机网络》谢希仁第七版课后答案完整版

耗时一个月!期末熬夜复习整理 | 计算机网络(谢希仁第七版)大合集知识点+大量习题讲解

python程序设计基础(嵩天)第五章课后习题部分答案

计算机网络(谢希仁 第七版)运输层 课后习题解析

计算机网络 第一章 概述 快速复习一下(谢希仁 第八版)

R语言基础题及答案——R语言与统计分析第五章课后习题(汤银才)