计算机网络谢希仁第五版第五章课后习题详解.docx

计算机网络谢希仁第五版第五章课后习题详解.docx

《计算机网络谢希仁第五版第五章课后习题详解.docx》由会员分享，可在线阅读，更多相关《计算机网络谢希仁第五版第五章课后习题详解.docx（17页珍藏版）》请在冰豆网上搜索。

计算机网络谢希仁第五版第五章课后习题详解

第五章传输层

5—01试说明运输层在协议栈中的地位和作用，运输层的通信和网络层的通信有什么

重要区别？

为什么运输层是必不可少的？

答：

运输层处于面向通信部分的最高层，同时也是用户功能中的最低层，向它上面的应

用层提供服务

运输层为应用进程之间提供端到端的逻辑通信，但网络层是为主机之间提供逻辑

通信（面向主机，承担路由功能，即主机寻址及有效的分组交换）。

各种应用进程之间通信需要“可靠或尽力而为”的两类服务质量，必须由运输

层以复用和分用的形式加载到网络层。

5—02网络层提供数据报或虚电路服务对上面的运输层有何影响？

答：

网络层提供数据报或虚电路服务不影响上面的运输层的运行机制。

但提供不同的服务质量。

5—03当应用程序使用面向连接的TCP和无连接的IP时，这种传输是面向连接的还是

面向无连接的？

答：

都是。

这要在不同层次来看，在运输层是面向连接的，在网络层则是无连接的。

5—04试用画图解释运输层的复用。

画图说明许多个运输用户复用到一条运输连接上

，而这条运输连接有复用到IP数据报上。

5—05试举例说明有些应用程序愿意采用不可靠的UDP，而不用采用可靠的TCP。

答：

VOIP：

由于语音信息具有一定的冗余度，人耳对VOIP数据报损失由一定的承受度，

但对传输时延的变化较敏感。

有差错的UDP数据报在接收端被直接抛弃，TCP数据报出错则会引起重传，可能

带来较大的时延扰动。

因此VOIP宁可采用不可靠的UDP，而不愿意采用可靠的TCP。

5—06接收方收到有差错的UDP用户数据报时应如何处理？

答：

丢弃

5—07如果应用程序愿意使用UDP来完成可靠的传输，这可能吗？

请说明理由

答：

可能，但应用程序中必须额外提供与TCP相同的功能。

5—08为什么说UDP是面向报文的，而TCP是面向字节流的？

答：

发送方UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。

UDP对

应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。

接收方UDP对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层

的应用进程，一次交付一个完整的报文。

发送方TCP对应用程序交下来的报文数据块，视为无结构的字节流（无边界约束，课分

拆/合并），但维持各字节

5—09端口的作用是什么？

为什么端口要划分为三种？

答：

端口的作用是对TCP/IP体系的应用进程进行统一的标志，使运行不同操作系统的计

算机的应用进程能够互相通信。

熟知端口，数值一般为0~1023.标记常规的服务进程；

登记端口号，数值为1024~49151，标记没有熟知端口号的非常规的服务进程；

5—10试说明运输层中伪首部的作用。

答：

用于计算运输层数据报校验和。

5—11某个应用进程使用运输层的用户数据报UDP，然而继续向下交给IP层后，又封

装成IP数据报。

既然都是数据报，可否跳过UDP而直接交给IP层？

哪些功能UDP提供了但

IP没提提供？

答：

不可跳过UDP而直接交给IP层

IP数据报IP报承担主机寻址，提供报头检错；只能找到目的主机而无法找到目

的进程。

UDP提供对应用进程的复用和分用功能，以及提供对数据差分的差错检验。

5—12一个应用程序用UDP，到IP层把数据报在划分为4个数据报片发送出去，结果前

两个数据报片丢失，后两个到达目的站。

过了一段时间应用程序重传UDP，而IP层仍然

划分为4个数据报片来传送。

结果这次前两个到达目的站而后两个丢失。

试问：

在目的

站能否将这两次传输的4个数据报片组装成完整的数据报？

假定目的站第一次收到的后

两个数据报片仍然保存在目的站的缓存中。

答：

不行

重传时，IP数据报的标识字段会有另一个标识符。

仅当标识符相同的IP数据报片才能组装成一个IP数据报。

前两个IP数据报片的标识符与后两个IP数据报片的标识符不同，因此不能组装

成一个IP数据报。

5—13一个UDP用户数据的数据字段为8192季节。

在数据链路层要使用以太网来传送

。

试问应当划分为几个IP数据报片？

说明每一个IP数据报字段长度和片偏移字段的值。

答：

6个

数据字段的长度：

前5个是1480字节，最后一个是800字节。

片偏移字段的值分别是：

0，1480，2960，4440，5920和7400.

5—14一UDP用户数据报的首部十六进制表示是：

06320045001CE217.试求源

端口、目的端口、用户数据报的总长度、数据部分长度。

这个用户数据报是从客户发送

给服务器发送给客户？

使用UDP的这个服务器程序是什么？

解：

源端口1586，目的端口69，UDP用户数据报总长度28字节，数据部分长度20字节。

此UDP用户数据报是从客户发给服务器（因为目的端口号<1023，是熟知端口）

、服务器程序是TFFTP。

5—15使用TCP对实时话音数据的传输有没有什么问题？

使用UDP在传送数据文件时会

有什么问题？

答：

如果语音数据不是实时播放（边接受边播放）就可以使用TCP，因为TCP传输可靠。

接收端用TCP讲话音数据接受完毕后，可以在以后的任何时间进行播放。

但假定是实时

传输，则必须使用UDP。

UDP不保证可靠交付，但UCP比TCP的开销要小很多。

因此只要应用程序接受这样

的服务质量就可以使用UDP。

5—16在停止等待协议中如果不使用编号是否可行？

为什么？

答:

分组和确认分组都必须进行编号，才能明确哪个分则得到了确认。

5—17在停止等待协议中，如果收到重复的报文段时不予理睬（即悄悄地丢弃它而其

他什么也没做）是否可行？

试举出具体的例子说明理由。

答：

收到重复帧不确认相当于确认丢失

5—18假定在运输层使用停止等待协议。

发送发在发送报文段M0后再设定的时间内未

收到确认，于是重传M0，但M0又迟迟不能到达接收方。

不久，发送方收到了迟到的对M0

的确认，于是发送下一个报文段M1，不久就收到了对M1的确认。

接着发送方发送新的报

文段M0，但这个新的M0在传送过程中丢失了。

正巧，一开始就滞留在网络中的M0现在到

达接收方。

接收方无法分辨M0是旧的。

于是收下M0，并发送确认。

显然，接收方后来收

到的M0是重复的，协议失败了。

试画出类似于图5-9所示的双方交换报文段的过程。

答：

旧的M0被当成新的M0。

5—19试证明：

当用n比特进行分组的编号时，若接收到窗口等于1（即只能按序接收

分组），当仅在发送窗口不超过2n-1时，连接ARQ协议才能正确运行。

窗口单位是分组

。

解：

见课后答案。

5—20在连续ARQ协议中，若发送窗口等于7，则发送端在开始时可连续发送7个分组

。

因此，在每一分组发送后，都要置一个超时计时器。

现在计算机里只有一个硬时钟。

设这7个分组发出的时间分别为t0,t1…t6,且tout都一样大。

试问如何实现这7个超时计

时器（这叫软件时钟法）？

解：

见课后答案。

5—21假定使用连续ARQ协议中，发送窗口大小事3，而序列范围[0,15],而传输媒体

保证在接收方能够按序收到分组。

在某时刻，接收方，下一个期望收到序号是5.

试问：

（1）在发送方的发送窗口中可能有出现的序号组合有哪几种？

（2）接收方已经发送出去的、但在网络中（即还未到达发送方）的确认分组可能有

哪些？

说明这些确认分组是用来确认哪些序号的分组。

5—22主机A向主机B发送一个很长的文件，其长度为L字节。

假定TCP使用的MSS有

1460字节。

（1）在TCP的序号不重复使用的条件下，L的最大值是多少？

（2）假定使用上面计算出文件长度，而运输层、网络层和数据链路层所使用的首部

开销共66字节，链路的数据率为10Mb/s，试求这个文件所需的最短发送时间。

解：

（1）L_max的最大值是2^32=4GB,G=2^30.

（2）满载分片数Q={L_max/MSS}取整=发送的总报文数

N=Q*（MSS+66）+{（L_max-Q*MSS）+66}=+682=

总字节数是N=字节，发送字节需时间为：

N*8/（10*10^6）

=3591.3秒，即59.85分，约1小时。

5—23主机A向主机B连续发送了两个TCP报文段，其序号分别为70和100。

试问：

（1）第一个报文段携带了多少个字节的数据？

（2）主机B收到第一个报文段后发回的确认中的确认号应当是多少？

（3）如果主机B收到第二个报文段后发回的确认中的确认号是180，试问A发送的第

二个报文段中的数据有多少字节？

（4）如果A发送的第一个报文段丢失了，但第二个报文段到达了B。

B在第二个报文

段到达后向A发送确认。

试问这个确认号应为多少？

解：

（1）第一个报文段的数据序号是70到99，共30字节的数据。

（2）确认号应为100.

（3）80字节。

（4）70

5—24一个TCP连接下面使用256kb/s的链路，其端到端时延为128ms。

经测试，发现

吞吐量只有120kb/s。

试问发送窗口W是多少？

（提示：

可以有两种答案，取决于接收等

发出确认的时机）。

解：

来回路程的时延等于256ms（=128ms×2）.设窗口值为X（注意:

以字节为单位）,假

定一次最大发送量等于窗口值,且发射时间等于256ms,那么,每发送一次都得停下来期待

再次得到下一窗口的确认,以得到新的发送许可.这样,发射时间等于停止等待应答的时

间,

结果,测到的平均吞吐率就等于发送速率的一半,即

8X÷（256×1000）=256×0.001

X=8192

所以,窗口值为8192.

5—25为什么在TCP首部中要把TCP端口号放入最开始的4个字节？

答：

在ICMP的差错报文中要包含IP首部后面的8个字节的内容，而这里面有TCP

首部中的源端口和目的端口。

当TCP收到ICMP差错报文时需要用这两个端口来确定是哪

条连接出了差错。

5—26为什么在TCP首部中有一个首部长度字段，而UDP的首部中就没有这个这个字段

？

答：

TCP首部除固定长度部分外，还有选项，因此TCP首部长度是可变的。

UDP首

部长度是固定的。

5—27一个TCP报文段的数据部分最多为多少个字节？

为什么？

如果用户要传送的数

据的字节长度超过TCP报文字段中的序号字段可能编出的最大序号，问还能否用TCP来传

送？

答：

65495字节，此数据部分加上TCP首部的20字节，再加上IP首部的20字节，正好是IP

数据报的最大长度65535.（当然，若IP首部包含了选择，则IP首部长度超过20字节

，这时TCP报文段的数据部分的长度将小于65495字节。

）

数据的字节长度超过TCP报文段中的序号字段可能编出的最大序号，通过循环使

用序号，仍能用TCP来传送。

5—28主机A向主机B发送TCP报文段，首部中的源端口是m而目的端口是n。

当B向A发

送回信时，其TCP报文段的首部中源端口和目的端口分别是什么？

答：

分别是n和m。

5—29在使用TCP传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该

确认报文段对应的数据的重传。

试说明理由。

答：

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

5—30设TCP使用的最大窗口为65535字节，而传输信道不产生差错，带宽也不受限制

。

若报文段的平均往返时延为20ms，问所能得到的最大吞吐量是多少?

答：

在发送时延可忽略的情况下，最大数据率=最大窗口*8/平均往返时间=26.2Mb/s。

5—31通信信道带宽为1Gb／s，端到端时延为10ms。

TCP的发送窗口为65535字节。

试

问:

可能达到的最大吞吐量是多少?

信道的利用率是多少?

答：

L=65536×8+40×8=

C=109b/s

L/C=0.s

Td=10×10-3s

0.

Throughput=L/（L/C+2×Td）=/0.=25.5Mb/s

Efficiency=（L/C）//（L/C+2×D）=0.0255

最大吞吐量为25.5Mb/s。

信道利用率为25.5/1000=2.55%

5—32什么是Karn算法?

在TCP的重传机制中，若不采用Karn算法，而是在收到确认时

都认为是对重传报文段的确认，那么由此得出的往返时延样本和重传时间都会偏小。

试

问：

重传时间最后会减小到什么程度?

答：

Karn算法：

在计算平均往返时延RTT时，只要报文段重传了，就不采用其往返时延

样本。

设新往返时延样本Ti

RTT

（1）=a*RTT（i-1）+（1-a）*T（i）；

RTT^（i）=a*RTT（i-1）+（1-a）*T（i）/2；

RTT

（1）=a*0+（1-a）*T

（1）=（1-a）*T

（1）;

RTT^

（1）=a*0+（1-a）*T

（1）/2=RTT

（1）/2

RTT

（2）=a*RTT

（1）+（1-a）*T

（2）;

RTT^

（2）=a*RTT

（1）+（1-a）*T

（2）/2;

=a*RTT

（1）/2+（1-a）*T

（2）/2=RTT

（2）/2

RTO=beta*RTT,在统计意义上，重传时间最后会减小到使用karn算法的1/2.

5—33假定TCP在开始建立连接时，发送方设定超时重传时间是RTO=6s。

（1）当发送方接到对方的连接确认报文段时，测量出RTT样本值为1.5s。

试计算现在的

RTO值。

（2）当发送方发送数据报文段并接收到确认时，测量出RTT样本值为2.5s。

试计算现在

的RTO值。

答：

（1）据RFC2988建议，RTO=RTTs+4*RTTd。

其中RTTd是RTTs的偏差加权均值。

初次测量时，RTTd

（1）=RTT

（1）/2；

后续测量中，RTTd（i）=（1-Beta）*RTTd（i-1）+Beta*{RTTs-RTT（i）}

；

Beta=1/4

依题意，RTT

（1）样本值为1.5秒，则

RTTs

（1）=RTT

（1）=1.5sRTTd

（1）=RTT

（1）/2=0.75s

RTO

（1）=RTTs

（1）+4RTTd

（1）=1.5+4*0.75=4.5（s）

（2）RTT

（2）=2.5RTTs

（1）=1.5sRTTd

（1）=0.75s

RTTd

（2）=（1-Beta）*RTTd

（1）+Beta*{RTTs

（1）-RT

（2）}=0.75*3/4+{1.5-2.5}/4=13/16

RTO

（2）=RTTs

（1）+4RTTd

（2）=1.5+4*13/16=4.75s

5—34已知第一次测得TCP的往返时延的当前值是30ms。

现在收到了三个接连的确认

报文段，它们比相应的数据报文段的发送时间分别滞后的时间是：

26ms，32ms和24ms。

设α=0．9。

试计算每一次的新的加权平均往返时间值RTTs。

讨论所得出的结果。

答：

a=0.1，RTTO=30

RTT1=RTTO*（1-a）+26*a=29.6

RTT2=RTT1*a+32（1-a）=29.84

RTT3=RTT2*a+24（1-a）=29.256

三次算出加权平均往返时间分别为29.6，29.84和29.256ms。

可以看出，RTT的样本值变化多达20%时，加权平均往返

5—35试计算一个包括5段链路的运输连接的单程端到端时延。

5段链路程中有2段是

卫星链路，有3段是广域网链路。

每条卫星链路又由上行链路和下行链路两部分组成。

可以取这两部分的传播时延之和为250ms。

每一个广域网的范围为1500km，其传播时延

可按km／s来计算。

各数据链路速率为48kb／s，帧长为960位。

答：

5段链路的传播时延=250*2+（1500/）*3*1000=530ms

5段链路的发送时延=960/（48*1000）*5*1000=100ms

所以5段链路单程端到端时延=530+100=630ms

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

答：

760ms

5—37在TCP的拥塞控制中，什么是慢开始、拥塞避免、快重传和快恢复算法?

这里每

一种算法各起什么作用?

“乘法减小”和“加法增大”各用在什么情况下?

答：

慢开始：

在主机刚刚开始发送报文段时可先将拥塞窗口cwnd设置为一个最大报文段

MSS的数值。

在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个MSS的数值

。

用这样的方法逐步增大发送端的拥塞窗口cwnd，可以分组注入到网络的速率更加合理

。

拥塞避免：

当拥塞窗口值大于慢开始门限时，停止使用慢开始算法而改用拥塞避免算法。

拥塞避免算法使发送的拥塞窗口每经过一个往返时延RTT就增加一个MSS的大小。

快重传算法规定：

发送端只要一连收到三个重复的ACK即可断定有分组丢失了，就应该立即重传丢手的报

文段而不必继续等待为该报文段设置的重传计时器的超时。

快恢复算法：

当发送端收到连续三个重复的ACK时，就重新设置慢开始门限ssthresh

与慢开始不同之处是拥塞窗口cwnd不是设置为1，而是设置为ssthresh

若收到的重复的AVK为n个（n>3），则将cwnd设置为ssthresh

若发送窗口值还容许发送报文段，就按拥塞避免算法继续发送报文段。

若收到了确认新的报文段的ACK，就将cwnd缩小到ssthresh

乘法减小：

是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞）

，就把慢开始门限值ssthresh设置为当前的拥塞窗口值乘以0.5。

当网络频繁出现拥塞时，ssthresh值就下降得很快，以大大减少注入到网络中的分组

数。

加法增大：

是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就

把拥塞窗口cwnd增加一个MSS大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞

。

5—38设TCP的ssthresh的初始值为8（单位为报文段）。

当拥塞窗口上升到12时网络发

生了超时，TCP使用慢开始和拥塞避免。

试分别求出第1次到第15次传输的各拥塞窗口大

小。

你能说明拥塞控制窗口每一次变化的原因吗？

答：

拥塞窗口大小分别为：

1，2，4，8，9，10，11，12，1，2，4，6，7，8，9.

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

cwnd

n1

12

24

38

416

532

633

734

835

936

1037

1138

1239

13

cwnd

n40

1441

1542

1621

1722

1823

1924

2025

2126

221

232

244

258

26

（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轮

次之后发送方是通过超时检测到丢失的报文段。

（5）在第1轮次发送时，门限ssthresh被设置为32

在第18轮次发送时，门限ssthresh被设置为发生拥塞时的一半，即21.

在第24轮次发送时，门限ssthresh是第18轮次发送时设置的21

（6）第70报文段在第7轮次发送出。

（7）拥塞窗口cwnd和门限ssthresh应设置为8的一半，即4.

5—40TCP在进行流量控制时是以分组的丢失作为产生拥塞的标志。

有没有不是因拥

塞而引起的分组丢失的情况?

如有，请举出三种情况。

答：

当Ip数据报在传输过程中需要分片，但其中的一个数据报未能及时到达终点，而终点组

装IP数据报已超时，因而只能丢失该数据报；IP数据报已经到达终点，但终点的缓存没

有足够的空间存放此数据报；数据报在转发过程中经过一个局域网的网桥，但网桥在转

发该数据报的帧没有足够的差错空间而只好丢弃。

5—41用TCP传送512字节的数据。

设窗口为100字节，而TCP报文段每次也是传送100

字节的数据。

再设发送端和接收端的起始序号分别选为100和200，试画出类似于图5-31

的工作示意图。

从连接建立阶段到连接释放都要画上。

5—42在图5-32中所示的连接释放过程中，主机B能否先不发送ACK=x+1的确认?

（因

为后面要发送的连接释放报文段中仍有ACK=x+1这一信息）

答：

如果B不再发送数据了，是可以把两个报文段合并成为一个，即只发送FIN+ACK报文段。

但如果B还有数据报要发送，而且要发送一段时间，那就不行，因为A迟迟收不到确认，

就会以为刚才发送的FIN报文段丢失了，就超时重传这个FIN报文段，浪费网络资源。

5—43在图（5-33）中，在什么情况下会发生从状态LISTEN到状态SYN_SENT，以及从状

态SYN_ENT到状态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发来的数据，所以可保证不丢失数据。

5—46试用具体例子说明为什么在运输连接建立时要使用三次握手。

说明如不这样做

可能会出现什么情况。

答：

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已

准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确

认。

假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。

按照两

次握手的协定，A认为连接已经成功地建立了，可以开始发