• 《计算机网络·自顶向下方法》第七版 第三章 课后习题与问题 答案


    非官方答案,本人已尽最大努力(包括参考官方答案),使结果正确,如有错误,请大佬指出

    正文:

    3.1~3.3节

    R1

    a.如果只是简单想把信件送到,那么所有的头部信息只需要一个目的地址就够了,题目给出端口号四个字节,所有分组的头部那就只需四个字节
    此协议规定,运输层的全部任务就是,将应用层的数据,切成最大1196字节的块,把每一块加上目的主机对应程序的端口号,并将得到的分组交付给网络层
    在接收方,运输层将网络层报文取回,去掉头部信息,将数据拼接成应用层需要的信息,根据端口号交付给应用层即可
    不过话说回来,没有序号的话,运输层应该不能将数据拼回来。。。所以剪切数据的活可以让应用层完成,运输层不接收超过1196字节的分组,这样就更简单了
    反正要保证本层最简单,把活给其他人干,或者干脆不干就行了
    b.头部加四个字节,源端口号,交付给应用层的时候把这个源端口号一起交付给应用层
    c.众所周知,运输层生活在网络边缘,所以网络核心的工作它不用干

    R2

    a.这些信一定要提供信的接收者信息,而不是题目说的不用,倒是信封上确实不用说明
    在这个模型中,邮局是网络层及其以下层次,负责收集分发的家庭成员是运输层,其他家庭成员是应用层
    就如同我们常做的,信封上只写上了收件人的地址,而在新的开头写上收件人的名字,信的结尾写上自己的名字
    如果严格按照计算机网络的工作范围而言,这两个名字并不是写信的人写上去的,而是负责收集分发的家庭成员为其填上的。
    同样,信封也是负责收集分发的家庭成员制作的,并且将信放入正确的信封,交给邮局
    在接收方,负责收集分发的家庭成员拆开信封,读取了信件开头的收件人姓名,并将报文交付给收件人
    b.不需要,邮局提供家到家的服务就行了

    R3

    y,x

    R4

    较高的时延对这些应用来说难以接受,而且他们可以接受一部分数据丢失

    R5

    答案说很多防火墙会阻止UDP,而放行TCP
    但是不得不说,TCP由于其可靠的服务,是当前语音和图像选择它的主要理由,显而易见,如果UDP足够优秀,防火墙也不会设置成这个样子。

    R6

    可能,在应用层完成UDP没有提供而TCP提供了的服务

    R7

    报文段恐怕很难被描述成套接字,是或不是我就不回答了,建议如果英语不是差到跟我一样,不要读翻译本
    UDP报文首部包含了源端口号,而网络层报文中包含了源IP,根据源端口号和源IP接收方可以分辨数据从哪里来

    R8

    既然是链接,那我姑且认为你是在问TCP吧
    TCP的socket有四个标志字段:源端口号,源IP,目的端口号,目的IP
    显然这两个请求含有不同的IP,所以发送的请求不会通过相同的套接字
    这两个套接字端口号的目的端口号都是80,源端口号不一定

    3.4节

    R9

    序号是在讨论rdt(reliable data transfer)2.0的时候引入的,背景是,下层信道可能造成数据损坏,除此之外完全可靠
    当接收方收到一个完好的报文,它将发送一个ACK报文作为响应,然而,这个ACK报文可能在传输过程中损坏。
    当发送方收到一个损坏的ACK报文,它无法分辨这是损坏的ACK还是NAK,所以,要么询问接收方,这个到底是个啥,要么,重发报文
    重新询问的话,询问报文有可能也会出问题,而且影响效率,所以发送方选择了,接收到损坏的响应报文,就把数据重发一遍
    然而对于接受方来说,它之前已经接收到了一份数据,下次应该接收下一份数据。
    然而接收方下一次还是接收到了这一份数据,也就是说,在这种情况下,接收方根本不知道自己收到的是发送方第一次发送的,还是重发的数据
    于是在报文中引入序号,使得接收方能够分辨报文的是发送方第一次发送的,还是重发的

    R10

    在rdt2.0的基础上,下层信道可能会丢包
    这个时候需要设置计时器,来判断下层信道有没有丢包

    R11

    仍然需要
    时延是否固定,已知与是否需要计时器没有关系,但是会影响定时器设定的值及其运算过程

    R12

    小程序地址

    a.五个分组全部重传了
    b.在第二个ACK到达时,第一个分组也就被确认到达了,毁掉第一个ACK没有任何影响
    c.发送窗口只有五,不能一次发送六个

    R13

    注意在这里没有用到累计确认
    a.只重传了第一个分组
    b.重传了第二个分组
    c.发送窗口只有五,不能一次发送六个

    3.4节

    R14

    a.false
    会发送一个没有数据的报文来进行确认
    b.false
    (rwnd = RcvBuffer - [LastByteRcvd - LastByteRead])
    c.true
    d.false
    这条报文可能是重发
    e.false
    我认为应该是通过握手时确认的RcvBuffer 和数据传输时的最后发送的数据编号和最后确认的数据编号来确定的
    但是答案给了true。。。
    f.false
    不是必定哦,之前的SampleRTT也有一定的权值
    g.false
    确认号用于确认自己接收的数据,而不是发出的

    R15

    a.20
    b.90

    R16

    3个
    第一段: seq = 43, ack =80;
    第二段: seq = 80, ack = 44;
    第三段:seq = 44, ack = 81

    3.7节

    R17

    一开始这两个TCP都将占有一个MSS的cwnd,随后二者都将进入慢启动,拥塞避免,快速恢复阶段,具体的变化过程与RTT等其他因素有关,但是最后的传输速率都会相等,即R/2

    R18

    false
    被设置成cwnd的一半

    R19

  • 相关阅读:
    vs已停止工作
    2.3.4 工具运行和错误解决方法
    vs2010 :0X80041FEB 程序集无法修改版等内容
    VS2010 F5调试时出现:“ 尝试运行项目时出错:未捕获通过反射调用的方法引发的异常”解决
    栅格计算器中空间分析函数
    设备系统,个人消费系统
    知己知彼
    ASP.NET MVC 实现二级域名
    自定义ASP.NET MVC Html辅助方法
    MVC系统过滤器(局部缓存,局部动态)
  • 原文地址:https://www.cnblogs.com/ZGQblogs/p/12235146.html
Copyright © 2020-2023  润新知