IT数码 购物 网址 头条 软件 日历 阅读 图书馆
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
图片批量下载器
↓批量下载图片,美女图库↓
图片自动播放器
↓图片自动播放器↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁
 
   -> 网络协议 -> 计算机网络第七版(谢希仁)第五章——传输层课后习题答案(上) -> 正文阅读

[网络协议]计算机网络第七版(谢希仁)第五章——传输层课后习题答案(上)

5-01

试说明运输层在协议栈中的地位和作用。运输层的通信和网络层的通信有什么重要的区别?为什么运输层是必不可少的?

解答

在这里插入图片描述

5-02

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

解答

在这里插入图片描述

5-03

当应用程序使用面向连接的TCP和无连接的IP时,这种传输是面向连接的还是无连接的?

解答

在这里插入图片描述

5-04

试画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上,而这条运输连接又复用到IP数据报上。

解答

在这里插入图片描述

5-05

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

解答

在这里插入图片描述

5-06

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

解答

简单地丢弃

5-07

如果应用程序愿意使用UDP完成可靠传输,这可能吗?请说明理由。

解答

解答:这是可能的,但这要由应用层自己来完成可靠传输。例如,应用层自己使用可靠传输协议。当然,这还是需要相当大的工作量的。

5-08

为什么说UDP是面向报文的,而TCP是面向字节流的?

解答

解答:发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。这就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文,如教材的图5-4所示。在接收方的UDP,对IP层交上来的UDP用户数据报,在去除首部后就原封不动地交付上层的应用进程。也就是说,UDP一次交付一个完整的报文。因此,应用程序必须选择合适大小的报文。若报文太长,UDP把它交给IP层后,IP层在传送时可能要进行分片,这会降低IP层的效率。反之,若报文太短,UDP把它交给IP层后,会使IP数据报的首部的相对长度太大,这也降低了IP层的效率。

5-09

端口的作用是什么?为什么端口号要划分为三种?

解答

解答:端口是用来标志进程的。端口也就是协议端口号。但这种在协议栈层间的抽象的协议端口是软件端口,和路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口,而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。不同的系统,具体实现端口的方法可以是不同的(取决于系统使用的操作系统)。TCP/IP的运输层用一个16位端口号来标志一个端口。但端口号只具有本地意义,它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网中不同的计算机中,相同的端口号是没有关联的。
两个计算机中的进程要互相通信,不仅必须知道对方的IP地址(为了找到对方的计算机),而且还要知道对方的端口号(为了找到对方计算机中的应用进程)。
端口号有三种。不同的端口类别有其特殊的用途。例如,客户端是通信的发起方,而服务器是服务的提供方。它们对端口的使用要求是不同的。这三种端口号是:
(1)熟知端口号或系统端口号,数值为0~1023。这些数值可在网址 www.iana.org查到。IANA把这些端口号指派给了TCP/IP最重要的一些应用程序,让所有的用户都知道。
(2)登记端口号,数值为1024~49151。这类端口号是为没有熟知端口号的应用程序使用的。使用这类端口号必须按照IANA规定的手续登记,以防止重复。
上面两种端口号是服务器端使用的端口号。下面的一种是客户端使用的端口号。
(3)短暂端口号,数值为49152~65535。这类端口号仅在客户进程运行时才动态选择,是留给客户进程选择暂时使用。

5-10

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

解答

解答:所谓“伪首部”是因为这种伪首部并不是UDP用户数据报或TCP报文段真正的首部。只是在计算检验和时,临时添加在UDP用户数据报或TCP报文段的前面,得到一个临时的UDP用户数据报或TCP报文段。检验和就是按照这个临时的UDP用户数据报或TCP报文段来计算的。伪首部既不向下传送也不向上递交,而仅仅是为了计算运输层的检验和。

5-11

某个应用进程使用运输层的用户数据报UDP,然后继续向下交给P层后,又封装成IP数据报。既然都是数据报,是否可以跳过UDP而直接交给IP层﹖哪些功能UDP提供了但IP没有提供?

解答

解答:IP数据报只能找到目的主机而无法找到目的进程。如果应用进程直接把数据交给下面的IP层,那么在传送到对方IP层后,就只能交付目的主机,但不知道应当交付哪一个应用进程。UDP提供对应用进程的复用和分用功能,以及提供对数据部分的差错检验。这些功能IP层没有提供。

5-12

一个应用程序用UDP,到了IP层把数据报再划分为4个数据报片发送出去。结果前两个数据报片丢失,后两个到达目的站。过了一段时间应用程序重传UDP,而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问:在目的站能否将这两次传输的4个数据报片组装成为完整的数据报?假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。

解答

解答:不行。重传时,IP 数据报的标识字段会有另一个标识符。仅当标识符相同的IP数据报片才能组装成一个IP数据报。前两个IP数据报片的标识符与后两个IP数据报片的标识符不同,因此不能组装成一个IP数据报。

5-13

一个UDP用户数据报的数据字段为8192字节。在链路层要使用以太网来传送。试问应当划分为几个IP数据报片﹖说明每一个IP数据报片的数据字段长度和片偏移字段的值。

解答

解答:UDP用户数据报的长度=8192+8= 8200 B
以太网数据字段最大长度是1500 B。若IP首部为20 B,则IP数据报的数据部分最多只能有1480 B。8200= 1480×5+800,因此划分的数据报片共6个。
数据字段的长度:前5个是1480字节,最后一个是800字节。第1个数据报片的片偏移字节是0。
第⒉个数据报片的片偏移字节是1480 B。
第3个数据报片的片偏移字节是1480 × 2 = 2960 B。第4个数据报片的片偏移字节是1480× 3=4440 B。第5个数据报片的片偏移字节是1480x4 = 5920 B。第6个数据报片的片偏移字节是1480 x5= 7400 B。
图T-5-13给出了以上结果。
在这里插入图片描述
把以上得出的片偏移字节数除以8,就得出片偏移字段中应当写入的的数值。因此最后的答案,片偏移字段的值分别是:0,185,370,555,740和925(字节数除以8)。

5-14

一个UDP用户数据报的首部的十六进制表示是:06 32 00 45 00 1C E2 17。试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器还是从服务器发送给客户?使用UDP的这个服务器程序是什么?

解答

在这里插入图片描述

5-15

使用TCP对实时话音数据的传输会有什么问题?使用UDP 在传送数据文件时会有什么问题?

解答

解答:对实时话音数据的传输是不能使用TCP的。这是因为用TCP传输话音数据时,只要一出现差错或丢失,TCP就要重传。这就产生了额外的时延,有时这种时延会达到很高的数值,使接收方无法容忍。在实时话音通信中,我们宁可丢掉几个分组(这在重放时,还原的话音质量会差一些,但仍然可以听懂),也不愿意收到太迟来到的分组,因为这样会使重放的话音质量严重恶化。虽然UDP不保证可靠交付,但UDP比TCP的开销要小很多。因此只要应用程序接受这样的服务质量就可以使用UDP。
如果话音数据不是实时播放(边接收边播放)就可以使用TCP,因为TCP传输可靠。接收端用TCP将话音数据接收完毕后,可以在以后的任何时间进行播放。但本题目假定是实时话音数据传输,因此必须使用UDP。
使用UDP传送数据文件时,如果出现了差错,UDP仅仅是少收了这个出错的报文段,并不通知发送方重传。这样就不能保证正确地传送数据。因此在传送数据文件时,我们都是采用TCP来传送的,

5-16

在停止等待协议中如果不使用编号是否可行?为什么?

解答

在这里插入图片描述

5-17

在停止等待协议中,如果收到重复的报文段时不予理睬(即悄悄地丢弃它而其他什么也不做)是否可行?试举出具体例子说明理由。

解答

在这里插入图片描述

5-18

假定在运输层使用停止等待协议。发送方发送报文段M后在设定的时间内未收到确认,于是重传 M,但Mo又迟迟不能到达接收方。不久,发送方收到了迟到的对 M的确认,于是发送下一个报文段 M,不久就收到了对M的确认。接着发送方发送新的报文段 M,但这个新的 M在传送过程中丢失了。正巧,一开始就滞留在网络中的M现在到达接收方。接收方无法分辨M是旧的。于是收下Mo,并发送确认。显然,接收方后来收到的M是重复的,协议失败了。试画出类似于图5-9所示的双方交换报文段的过程。

解答

在这里插入图片描述

5-19

试证明:当用n比特进行分组的编号时,若接收窗口等于1(即只能按序接收分组),则仅在发送窗口不超过2”-1时,连续ARQ 协议才能正确运行。窗口单位是分组。

解答

解答:如图T-5-19所示,设发送窗口记为W,接收窗口记为WR。假定用3比特进行编号。设接收窗口正好在7号分组处(有阴影的分组)。
发送窗口Wr的位置不可能比②的位置更靠前。因为接收窗口的位置表明接收方正等待接收7号分组,而这时的发送方不可能已经收到了对7号分组的确认。因此发送窗口必须包括7号分组,也就是不可能比②的位置更靠前(前方就是图的右方)。
发送窗口Wr的位置也不可能比③的位置更靠后。因为接收窗口的位置表明接收方已经对6号分组(以及以前的分组)发送了确认。但如果发送窗口Wr的位置再靠后一个分组,即在6 号分组的左边,那就表明还没有发送6号分组。但接收窗口的位置表明接收方已经发送了对6号分组的确认。这显然是不可能的。
在这里插入图片描述

5-20

在连续ARQ协议中,若发送窗口等于7,则发送端在开始时可连续发送7个分组。因此,在每一分组发出后,都要置一个超时计时器。现在计算机里只有一个硬时钟。设这7个分组发出的时间分别为to, t,…, t6,且 tou都一样大。试问如何实现这7个超时计时器(这叫软时钟法)?

解答

在这里插入图片描述

5-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的分组的。

5-22

主机A向主机B发送一个很长的文件,其长度为L字节。假定TCP使用的MSS为1460字节。
(1)在 TCP的序号不重复使用的条件下,L的最大值是多少?
(2)假定使用上面计算出的文件长度,而运输层、网络层和数据链路层所用的首部开
销共66字节,链路的数据率为10 Mbit/s,试求这个文件所需的最短发送时间。

解答

在这里插入图片描述

5-23

主机A向主机B连续发送了两个TCP报文段,其序号分别是70和100。试问:
(1)第一个报文段携带了多少字节的数据?
(2)主机收到第一个报文段后发回的确认中的确认号应当是多少?
(3)如果B收到第二个报文段后发回的确认中的确认号是180,试问A发送的第二个报文段中的数据有多少字节?
(4)如果A发送的第一个报文段丢失了,但第二个报文段到达了B。B在第二个报文段到达后向A发送确认。试问这个确认号应为多少?

解答

解答:分别求解如下:
(1)第一个报文段的数据序号是70到99,共30字节的数据。
(2)B期望收到下一个报文段的第一个数据字节的序号是100,因此确认号应为100。
(3)A发送的第二个报文段中的数据中的字节数是180- 100= 80字节。
(4)B在第二个报文段到达后向A发送确认,其确认号应为70。

5-24

一个TCP连接下面使用256 kbit/s的链路,其端到端时延为128 ms。经测试,发现吞吐量只有120 kbit/s。试问发送窗口W是多少?(提示:可以有两种答案,取决于接收端发出确认的时机。)

解答

解答:设发送窗口=W(bit),再设发送端连续发送完窗口内的数据所需的时间=T。有两种情况:
(a)接收端在收完一批数据的最后才发出确认,因此发送端经过(256 ms + T)后才能发送下一个窗口的数据。
(b)接收端每收到–个很小的报文段后就发回确认,因此发送端经过比256 ms略多一些的时间即可再发送数据。因此每经过256 ms就能发送一个窗口的数据。
在这里插入图片描述

5-25

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

解答

解答:在ICMP的差错报文中(见教材的图4-28)要包含IP首部后面的8个字节的内容,而这里面有TCP首部中的源端口和目的端口。当TCP收到ICMP差错报文时,需要用这两个端口来确定是哪条连接出了差错。

5-26

为什么在TCP首部中有一个首部长度字段,而UDP的首部中就没有这个字段?

解答

解答:TCP首部除固定长度部分外,还有选项,因此TCP首部长度是可变的。UDP首部长度是固定的,不需要这个字段。

5-27

一个TCP报文段的数据部分最多为多少个字节?为什么?如果用户要传送的数据的字节长度超过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报文段的首部中的源端口和目的端口分别是什么?

解答

解答:当B向A发送回信时,其TCP报文段首部中的源端口就是A发送的TCP报文段首部中的目的端口n,而B发送的TCP报文段首部中的目的端口就是A发送的TCP报文段首部中的源端口m。

5-29

在使用TCP传送数据时,如果有一个确认报文段丢失了,也不一定会引起与该确认报文段对应的数据的重传。试说明理由。

解答

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

5-30

设TCP使用的最大窗口为65535字节,而传输信道不产生差错,带宽也不受限制。若报文段的平均往返时间为20 ms,问所能得到的最大吞吐量是多少?

解答

解答:在发送时延可忽略的情况下,每 20 ms可发送65535×8= 524280 bit最大数据率 =(524280 bit)/ (20 ms) 约等于26.2 Mbit/s。

5-31

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

解答

在这里插入图片描述

5-32

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

解答

解答:Karn算法允许 TCP 能够区分开有效的和无效的往返时间样本,从而改进了往返时间的估算。
若不采用Karn 算法,而是在收到确认时都认为是对重传报文段的确认,那么由此得出的往返时间样本和重传时间都会偏小。如图T-5-32所示,TCP发送了报文段后,没有收到确认,于是超时重传报文段。但刚刚重传了报文段后,马上就收到了确认。显然,这个确认是对原来发送的报文段的确认。
但是,根据题意,我们就认为这个确认是对重传的报文段的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到很接近于零。
因此,上述的这种做法是不可取的。
在这里插入图片描述
对于计算机网络的课后习题我都做了一遍,这里就不再放我的解答过程了,直接给大家展示标准答案,如有不懂,可评论私信,我一定解答,后续还会坚持更新完…

  网络协议 最新文章
使用Easyswoole 搭建简单的Websoket服务
常见的数据通信方式有哪些?
Openssl 1024bit RSA算法---公私钥获取和处
HTTPS协议的密钥交换流程
《小白WEB安全入门》03. 漏洞篇
HttpRunner4.x 安装与使用
2021-07-04
手写RPC学习笔记
K8S高可用版本部署
mySQL计算IP地址范围
上一篇文章      下一篇文章      查看所有文章
加:2021-10-12 23:49:56  更:2021-10-12 23:52:53 
 
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁

360图书馆 购物 三丰科技 阅读网 日历 万年历 2024年11日历 -2024/11/26 4:54:50-

图片自动播放器
↓图片自动播放器↓
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
图片批量下载器
↓批量下载图片,美女图库↓
  网站联系: qq:121756557 email:121756557@qq.com  IT数码