lbcqc

TCP/IP详解课后习题（卷一）

2020/05/16 Network

学习TCP/IP详解卷一的过程中，为了加深理解，书本后面的习题基本都做了，此处记录下来。

第一章. 概述

  1. 请计算最多有多少个A类，B类，C类网络号
    A 类：0~127/8, 去掉全0，去掉127环回测试地址，$(127-0+1)-2=126$
    B 类：128~191/16, 去掉全0, $(191-128+1)256-1=16383$
    C 类：192-223/24, 去掉全0，$(223-192+1)    256*256-1=2097151$‬

  2. 用匿名FTP（见27.3节）从主机nic.merit.edu上获取文件nsfnet/statisticshistory.netcount。该文件包含在NSFNET网络上登记的国内和国外的网络数。画一坐标系，横坐标代表年，纵坐标代表网络总数的对数值。纵坐标的最大值是习题1.1的结果。如果数据显示一个明显的趋势，请估计按照当前的编址体制推算，何时会用完所有的网络地址（3.10节讨论解决该难题的建议）

    由于访问不了外国网络，此处无法获取数据。参考网上答案，IPV4地址将约在2000年耗尽，目前使用NAT技术延续使用。

  3. 获取一份主机需求RFC拷贝[Braden 1989a]，阅读有关应用于TCP/IP协议族每一层的稳健性原则。这个原则的参考对象是什么？

    RFC 1122
    RFC 1123

  4. 获取一份最新的赋值RFC拷贝。“quote of the day”协议的有名端口号是什么？哪个RFC对该协议进行了定义？

    qotd 17/tcp Quote of the Day
    qotd 17/udp Quote of the Day
    RFC 1700

  5. 如果你有一个接入TCP/IP互联网的主机帐号，它的主IP地址是多少？这台主机是否接入了Internet？它是多接口主机吗？

    IP地址：192.168.3.10， 接入了INTERNET， 是多接口主机，有网卡/显卡/鼠键接口

  6. 获取一份RFC 1000的拷贝，了解RFC这个术语从何而来。

    RFC(THE REQUEST FOR COMMENTS REFERENCE GUIDE)是互联网社区的引用指导，摘录了1969年4月到1987年3月间所有征求意见的请求。
    RFC 1000

  7. 与Internet协会联系，isoc@isoc.org或者+1 703 648 9888，了解有关加入的情况。

    略

  8. 用匿名FTP从主机is.internic.net处获取文件about-internic/information-about-the-internic。

    同2，略

第二章 链路层

  1. 如果你的系统支持netstat(1)命令（参见3.9节），那么请用它确定系统上的接口及其MTU。

     ➜  ~ netstat -i
 Kernel Interface table
 Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
 eth0             1500    18375      0      0 0         11346      0      0      0 BMRU
 lo              65536      226      0      0 0           226      0      0      0 LRU

第三章 IP：网际协议

  1. 环回地址必须是127.0.0.1吗？

    不必须，A类网络地址127.0.0.0/8被预留做环回网络段，可以使用该网段的任何一个地址。127.0.0.1只是一个习惯性设置的地址。

  2. 在图3-6中指出有两个网络接口的路由器。

    kpno 有5个接口：3个点对点链路和2个以太网接口。R10 有4个以太网接口。gateway 有3个接口：2个点对点链路和1个以太网接口。最后，netb 有1个以太网接口和2个点对点链路。

  3. 子网号为16 bit的A类地址与子网号为8 bit的B类地址的子网掩码有什么不同？

    都是255.255.255.0

  4. 阅读RFC 1219 [Tsuchiya 1991]，学习分配子网号和主机号的有关推荐技术。

    RFC 1219

  5. 子网掩码255.255.0.255是否对A类地址有效？

    它是合法的，被称为非连续的子网掩码，因为其用于子网掩码的16位是不连续的。但是RFC建议反对使用非连续的子网掩码。

  6. 你认为为什么3.9小节中打印出来的环回接口的MTU要设置为1536？

    IEEE802.3以太网格式报文，其第13-14字节头部在802.3中是报文类型/长度，为了区分其具体属性，IEEE802.3中规定，如果Length/Type的值大于0×600则表示是类型，0x600 = 1536，否则表示长度。MTU设置为1536表示以太网长度报文不会超过1536字节，超过了，则13-14字节表示的就是Type。

  7. TCP/IP协议族是基于一种数据报的网络技术，即IP层，其他的协议族则基于面向连接的网络技术。阅读文献[Clark 1988]，找出数据报网络层提供的三个优点。

    • 基于数据包的形式，使其成为最基本的网络构件，为传输层提供更大的灵活性，可以基于此构建可靠的（tcp）和不可靠的（udp）服务。
    • 不面向连接，降低了对路由器的要求，方便组网。

第四章 ARP: 地址解析解析

  1. 当输入命令以生成类似图4 - 4那样的输出时，发现本地ARP快速缓存为空以后，输入命令bsdi ％ rsh svr4 arp -a如果发现目的主机上的ARP快速缓存也是空的，那将发生什么情况？ (该命令将在svr4主机上运行arp -a命令）。

    如果运行telnet命令连接主机时，ARP缓存为空，那么talnet程序将一直无法连接成功，呈现出来的是程序阻塞/卡顿状态，直到超时失败。

  2. 请描述如何判断一个给定主机是否能正确处理接收到的非必要的A R P请求的方法。

    使用发包工具，构造免费ARP报文，向该主机所在网络发送，看该主机是否能在ARP缓存中新增免费ARP报文所携带信息。

  3. 由于发送一个数据包后ARP将等待响应，因此4.2节所描述的步骤7可能会持续一段时间。你认为ARP将如何处理在这期间收到相同目的IP地址发来的多个数据包？

    收到之后，更新自身的ARP缓存，包括刷新超时时间。

  4. 在4.5节的最后，我们指出Host Requirements RFC和伯克利派生系统在处理活动ARP表目的超时时存在差异。那么如果我们在一个由伯克利派生系统的客户端上，试图与一个正在更换以太网卡而处于关机状态的服务器主机联系，这时会发生什么情况？如果服务器在引导过程中广播一份免费ARP，这种情况是否会发生变化？

    客户端上缓存的服务器主机ARP缓存超时时间为20分钟，在未超时期间与服务器联系，将会一直以缓存中的MAC作为目的MAC发送以太网报文，该报文会送到服务器连接的以太网交换机，交换机发现目的端口是DOWN的，将广播该报文，明显广播报文不会得到回应。待服务器起机发送免费ARP后，网络中所有设备更新ARP缓存，客户端将以新MAC作为目的MAC发送报文，此时服务器接收到之后回应。如果20分钟超时后，服务器依然没有发送免费ARP，那么客户端ARP表项超时删除，将不会再发送报文。

第五章 RARP：逆地址解析协议

  1. RARP需要不同的帧类型字段吗？ A R P和R A R P都使用相同的值0 x 0 8 0 6吗？

    需要，使ARP服务器和RARP服务分别处理不同协议，无需解析报文内容出来判断Op字段。
    不同，ARP:0x0806，RARP：0X8035

  2. 在一个有多个RARP服务器的网络上，如何防止它们的响应发生冲突？

    无需防止，如果同步收到报文，随机取一个即可。如果冲突导致丢包没收到报文，重发请求即可。因为报文的传输延时性，每个服务器都无法判断对端报文的接收及回应抵达情况。

第六章 ICMP：Internet控制报文协议

  1. 在6.2节的末尾，我们列出了5种不发送ICMP差错报文的特殊条件。如果这些条件不满足而我们又在局域网上向一个似乎不存在的端口号发送一份广播UDP数据报，这时会发生什么样的情况？

    此时会收到一份端口不可达的ICMP差错报文消息。

  2. 阅读RFC [Braden 1989a]，注意生成一个ICMP端口不可达差错是否为“必须”，“应该”或者“可能”。这些信息所在的页码和章节是多少？

    RFC 1122 [Braden 1989a]
    在4.1.3.3 ICMP Messages章节，描述如下： DP MUST pass to the application layer all ICMP error messages that it receives from the IP layer. Conceptually at least, this may be accomplished with an upcall to the ERROR_REPORT routine (see Section 4.2.4.1).
    故而是‘必须’

  3. 阅读RFC 1349 [Almquist 1992]，看看IP的服务类型字段（见图3-2）是如何被ICMP设置的？

    RFC 1349 [Almquist 1992]
    ICMP在路由阶段，会设置IP数据包的TOS服务类型，类型包括：“最小时延”，“最高可靠性”，“最大吞吐”，“最小费用”。

  4. 如果你的系统提供netstat命令，请用它来查看接收和发送的ICMP报文类型。

    略

第七章 Ping程序

  1. 请画出7.2节中ping输出的时间线。

    以7.2.2WAN输出章节为例，每秒发送一个报文，以0秒开始发送为例，输出时间线为：

    send_time rtt recv_time
    0 660ms 0.66s
    1    
    2    
    3    
    4    
    5 1780ms 6.780s
    6    
    7 380ms 7.38s
    8 420ms 8.42s
    9 390ms 9.39s
    10    
    11    
    12    
    13    
    14 110ms 14.11s
    15 170ms 15.17s
    16 100ms 16.1s

  2. 若把bsdi和slip主机之间的SLIP链路设置为9600 b/s，请计算这时的RTT。假定默认的数据是56字节。

    此时我们假设实际的RTT与带宽差15倍，计算结果如下：
    $((56+20+8)/960)*2=0.175$
    即175ms, 如果按照15倍的理论差值，则需要2625ms

  3. 当前BSD版中的ping程序允许我们为ICMP报文的数据部分指定一种模式（数据部分的前8个字节不用来存放模式，因为它要存放发送报文的时间）。如果我们指定的模式为0xc0，请重新计算上一题中的答案（提示：阅读2.4节）。

    除前8字节，后48字节需要被转义：0xc0是SLIP END字符。 故而需要多传送48 Byte，重新计算结果如下：
    $((56+48+20+8)/960)*2=0.275$
    即175ms, 如果按照15倍的理论差值，则需要5125ms

  4. 使用压缩SLIP（CSLIP，见2.5节）是否会影响我们在7.2节中看到的ping输出中的时间值？

    会影响，由于CSLIP会将TCP即IP首部压缩到3-5个字节，故而报文小了，时间会变短，以将20 IP首部字节压缩到5字节为例，如下：
    $((56+5+8)/960)*2=0.122$
    从175ms减小到122ms

  5. 在图2-4中，ping环回地址与ping主机以太网地址会出现什么不同？

    svr4 % ping -R localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=254 time=0 ms
RR：    localhost (127.0.0.1)
64 bytes from 127.0.0.1: icmp_seq=1 ttl=254 time=0 ms (same route)
64 bytes from 127.0.0.1: icmp_seq=2 ttl=254 time=0 ms (same route)
^?
--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
route-trip min/avg/max = 0/0/0 ms

第八章 Traceroute 程序

  1. 当IP将接收到的TTL字段减1，发现它为0时，将会发生什么结果？

    路由器会将该报文丢弃，并给信源机发一份ICMP“超时”信息。Tranceroute程序的关键在于这份ICMP信息的IP报文的信源地址是该路由器的IP地址。

  2. traceroute程序是如何计算RTT的？将这种计算RTT的方法与ping相比较?

    Tranceroute程序对每个TTL值均发送3份数据报，然后等待ICMP报文并打印出相应往返时间，如果5s内没收到，则打印’*‘号。
    和PING程序比较，略。

  3. （本习题与下一道习题是基于开发traceroute程序过程中遇到的实际问题，它们来自于traceroute程序源代码注释）。假设源主机和目的主机之间有三个路由器（R1、R2和R3），而中间的路由器（R2）在进入TTL字段为1时，将TTL字段减1，但却错误地将该IP数据报发往下一个路由器。请描述会发生什么结果。在运行traceroute程序时会看到什么样的现象？

    下一跳R3路由器将该数据报丢弃并回复ICMP超时报文。Traceroute程序显示中将跳过R2路由器IP而直接显示R3路由器。

  4. 同样，假设源主机和目的主机之间有三个路由器。由于目的主机上存在错误，因此，它总是将进入TTL值作为外出ICMP报文的TTL值。请描述这将发生什么结果，你会看到什么现象。

    这将导致Tranceroute程序认为目的主机不可达，并中止运行。

  5. 在图8-8运行例子中，我们可以在sun和netb之间的SLIP链路上运行tcpdump程序。如果指定-v选项，就可以看到返回ICMP报文的TTL值。这样，我们可以看到进入netb、butch、Gabby和enss142.UT.westnet.net的TTL值分别为255、253、252和249。这是否为我们判断是否存在丢失路由器提供了额外的信息？

    是的，通过最小的TTL值249开始逆推，中间至少经历了255-249即7个路由节点（含终点主机），正常情况应收到249/250/251/252/253/254/255这7个TTL值的报文。

  6. SunOS和SVR4都提供了带-l选项的ping版本，以提供松源选路。手册上说明，该选项可以与-R选项（指定记录路由选项）一起使用。如果已经进入到这些系统中，请尝试同时用这两个选项。其结果是什么？如果采用tcpdump来观测数据报，请描述其过程。

    Centos7上进行测试，-R与-l选项已经和课本中描述的不太一致，可能新版ping已不支持该功能。

  7. 比较ping和traceroute程序在处理同一台主机上客户的多个实例的不同点。

    略。

  8. 比较ping和traceroute程序在计算往返时间上的不同点。

    ping是一份ICMP回复报文中累计所有中间节点的时间点。
    tranceroute是每个中间节点单独回复时间。

  9. 我们已经说过， traceroute程序选取开始UDP目的主机端口号为33453，每发送一个数据报将此数加1。在1 . 9节中，我们说过暂时端口号通常是1024 ~ 5000之间的值，因此traceroute程序的目的主机端口号不可能是目的主机上所使用的端口号。在Solaris2.2系统中的情况也是如此吗？（提示：查看E.4节）

    略。

  10. RFC 1393 [Malkin 1993b]提出了另一种判断到目的主机路径的方法。请问其优缺点是什么？

    RFC 1393 [Malkin 1993b]
    略。

第九章 IP选路

  1. 为什么你认为存在两类ICMP重定向报文—网络和主机？

    由于路由器的路由表项中本身目的地址就分主机和网络和默认路由三种，对于主机和默认路由，都可以归类为该主机的下一跳，对于网络命中，则可归类为整个网段都命中，将整个网段信息直接重定向给主机，有利于更加优化主机路由表项，无需该网络内每个主机IP都一一重定向，同时主机上也不会多出很多主机路由表项，节约路由表项资源。

  2. 在9.4节开头列出的svr4主机上的路由表中，到主机slip（140.252.13.65）的特定路由是必需的吗？如果把这一项从路由表中删除会有什么变化？

    是必须的，如果删除该条路由，到主机slip的数据报就会匹配140.252.13.32 -> 140.252.13.33的路由表项，由于该表项非G非H，故而是一个网段，且为直达路由，需要之直接填写slip的MAC地址在以太网报文种，由于slip的实际不在直连网络，需要通过路由器140.252.13.35才能获取到，故而ARP将无法获取到MAC，网络报文将无法发送，将会收到ICMP目的地址不可达消息。

  3. 考虑有一电缆连接4.2BSD主机和4.3BSD主机。假定网络号是140.1。4.2BSD主机把主机号为全0的地址识别为广播地址(140.1.0.0)，而4.3BSD通常使用全1的主机号（140.1.255.255）发送广播。另外，4.2BSD主机在默认条件下要尽力转发接收到的数据报，尽管它们只有一个接口。请描述当4.2BSD主机收到一份目的地址为140.1.255.255的IP数据报时会发生什么事。

    主机收到该IP地址后，判断不是自己的IP，将直接丢弃不做转发。

  4. 继续前一个习题，假定有人在子网140.1上的某个系统ARP高速缓存中增加了一项（用arp命令）内容，指定I P地址140.1.255.255对应的以太网地址为全1（以太网广播地址）。请描述此时发生的情况。

    即使有ARP表，但是主机收到目的IP为140.1.255.255的报文时，不是自己的IP，将不做转发，故而使用不到这个ARP表项。

  5. 检查你所使用的系统上的路由表，并解释每一项内容。

     Kernel IP routing table
 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
 default         bogon           0.0.0.0         UG    0      0        0 eth0
 172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
    列 含义
    Destination 目的地址
    Gateway 下一跳地址
    Genmask 掩码，用于比较确定网络号+子网号
    Flags 使用标识，U表示该表项正在失败，G表示非直连网段，H表示目的地址为主机地址
    Metric 路由长度
    Ref 正在被进程引用数
    Use 正在使用
    Iface 发送报文的网络接口

## 第十章 动态选路协议

  1. 在图10-9中哪些路由是从路由器kpno进入gateway的？

    Metric大于2的都是，只需要看Address是否在Kpno端即可判断是否从Kpno同步来。

  2. 假设一个路由器要使用RIP通告30个路由，这需要一个包含25条路由和另一个包含5条路由的数据报。如果每过一个小时，第一个包含25条路由的数据报丢失一次，那么其结果如何？

    不会发生什么，RIP本身有处理UDP丢包逻辑，RIP通告报文30s发一次，需要连续丢6次以上才会标志为删除，过60s后删除，故而间隔一小时丢一次没有影响。

  3. OSPF报文格式中有一个检验和字段，而RIP报文则没有此项，这是为什么？

    RIP报文格式是固定死的，每个报文段该存什么内容，长度只能为多少（有限的几个有效值）等，故而其可以根据报文内容及报文总长度来做校验，可以不需要检验和来对内容做校验。

  4. 像OSPF这样的负载平衡，对于传输层的影响是什么？

    传输层不能依赖IP层的发包顺序及发包路径，其收到报文进行组装时，可能来自不同的接收端口，不同的时序，传输层需要自己处理。

  5. 查阅RFC1058关于实现RIP的其他资料。在图10-8中，140.252.1网络的每个路由器只通告它所提供的路由，而它并不能通过其他路由器的广播中知道任何其他路由。这种技术的名称是什么？

    RFC 1058 [Malkin 1993b]
    略

  6. 在3.4节中，我们说过除了图10-7中所示的8个路由器外，140.252.1子网上还有超过100个主机。那么这100个主机是如何处理每30秒到达它们的8个广播信息呢（图10-8）？

    直接忽略，因为主机上没有运行RIP的守护程序，没有监听UDP 520端口，即没有程序去处理这些报文信息

第十一章 UDP 用户数据包协议

  1. 在11.5节中，向UDP数据报中写入1473字节用户数据时导致以太网数据报片的发生。在采用以太网IEEE 802封装格式时，导致分片的最小用户数据长度为多少？

    由于MTU通常为1514，实际显示为1500（去掉了以太网报文头14Byte）,如果算上802.1Q扩展，以太网报文头长度为18Byte，此时导致分片的最小用户数据长度为$1473-4=1469$

  2. 阅读RFC 791[Postel 1981a]，理解为什么除最后一片外，其他片中的数据长度均要求为8字节的整数倍？

    RFC 791 [Postel 1981a]
    略

  3. 假定有一个以太网和一份8192字节的UDP数据报，那么需要分成多少个数据报片，每个数据报片的偏移和长度为多少？

    第一片数据包长度为1472，除第一片数据包后剩余长度为$8192-1472=6720$，剩下的报文分片不需要UDP首部，最长数据包长度为1480，正好是8的整数倍，还可分$6720 \div 1480 \approx 4.5$即5片数据报
    故而需要分成6片，每片数据包的偏移和长度分别如下表格所示：

    Index offset length
    1 0 1472
    2 1472 1480
    3 2852 1480
    4 4432 1480
    5 5912 1480
    6 7392 800

  4. 继续前一习题，假定这些数据报片要经过一条MTU为552的SLIP链路。必须记住每一个数据报片中的数据（除IP首部外）为8字节的整数倍。那么又将分成多少个数据报片？每个数据报片的偏移和长度为多少？

    $552 - 20 - 8 = 524$，$524 \div 8 = 65.5$, $8 * 65 = 520$，520正好能被8整除，第一片数据包长度为520；
    $8192 - 520 = 7672$，剩余数据包长度为7672；
    $552 - 20 = 532$， $532 \div 8 = 66.5$， $66 * 8 = 528$，剩余数据包分片大小为528；
    $7672 \div 528 \approx 14.5$，甚于数据包可分15片；
    $7672 - 14 * 528 = 280$，最后一片大小为280Byte。 最终分为16片，每片长度如下所示：

    Index offset length
    1 0 520
    2 520 528
    3 1048 528
    4 1576 528
    5 2104 528
    6 2632 528
    7 3160 528
    8 3688 528
    9 4216 528
    10 4744 528
    11 5272 528
    12 5800 528
    13 6328 528
    14 6856 528
    15 7384 528
    16 7912 280

  5. 一个用UDP发送数据报的应用程序，它把数据报分成4个数据报片。假定第1片和第2片到达目的端，而第3片和第4片丢失了。应用程序在10秒钟后超时重发该UDP数据报，并且被分成相同的4片（相同的偏移和长度）。假定这一次接收主机重新组装的时间为60秒，那么当重发的第3片和第4片到达目的端时，原先收到的第1片和第2片还没有被丢弃。接收端能否把这4片数据重新组装成一份IP数据报？

    不可以，对于发送端发送的每份IP数据报来说，其标识字段都含有一个唯一值，这个唯一值在分片时被复制到每一片中，故而原先的第1片和第2片无法和重传的第3片和第4片组转成一份数据报，因为其IP头中的标识值不一样。

  6. 你是如何知道图11-15中的片实际上与图11-14中第5行和第6行相对应？

    从打印出来的IP首部源端与目的端IP均相同，同时frag表示均为47942。

  7. 主机gemini开机33天后，netstat程序显示48000000份IP数据报中由于首部检验和差错被丢弃129份，在30000000个TCP段中由于TCP检验和差错而被丢弃20个。但是，在大约18000000份UDP数据报中，因为UDP检验和差错而被丢弃的数据报一份也没有。请说明两个方面的原因（提示：参见图11-4）。

    • 发送端UDP数据包的校验和可能是没有打开的。
    • UDP检验和是简单的16bit检验，其只能检测出数据报中某个16bit被修改，但检测不出两个16bit的交换。

  8. 在讨论分片时没有提及任何关于I P首部中的选项——它们是否也要被复制到每个数据报片中，或者只留在第一个数据报片中？我们已经讨论过下面这些I P选项：记录路由（7.3节）、时间戳（7.4节）、严格和宽松的源站选路（8.5节）。你希望分片如何处理这些选项？对照RFC 791检查你的答案。

    RFC 791 [Postel 1981a]
    一个IP数据报的每个分片都具有自己的IP头部信息，它们都具有相同的标识值，但是具有不同的位偏移，且除了最后一个分片外，其他分片都将设置MF标志。此外，每个分片的IP头部的总长度字段将被设置为该分片的长度。
    对于记录路由和时间戳，不同的分片如果都记录，结果可能不一样，但是最终组转分片报文时只能保留一个，此处应当只保留在第一片数据包中，其余分片不保留。 对于严格和宽松的源站选路，由于其应当作用到各个分片报文上，限制所有分片的选路，故而应当保留在所有分片中。

  9. 在图1-8中，我们说UDP数据报是根据目的UDP端口号进行分配的。这正确吗？

    不太准确，因为UDP可以做本地IP地址限制，准确的说法应当是根据本地IP和UDP端口号进行分配。

第十二章 广播和多播

  1. 广播是否增加了网络通信量？

    增加了，使得有些不关注该报文的主机也处理了该报文。

  2. 考虑一个拥有50台主机的以太网：20台运行TCP/IP，其他3 0台运行其他的协议族。主机如何处理来自运行另一个协议族主机的广播？

    通过设备驱动程序来做过滤，以太网帧头中含有2Byte的协议类型，设备驱动程序向上层传送解析报文时，相应的Type找不到处理程序即丢弃。

  3. 登录到一个过去从来没有用过的Unix系统，并且打算找出所有支持广播的接口的指向子网的广播地址。如何做到这点？

    只需向内核请求所有接口的信息，例如ifconfig, 看是否有广播支持标志BROADCAST，看其子网广播地址broadcast，如下所示：

     ➜  ~ ifconfig 
 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
         inet 172.17.0.2  netmask 255.255.0.0  broadcast 172.17.255.255
         ether 02:42:ac:11:00:02  txqueuelen 0  (Ethernet)
         RX packets 1213  bytes 81252 (79.3 KiB)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 1290  bytes 117683 (114.9 KiB)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
         inet 127.0.0.1  netmask 255.0.0.0
         loop  txqueuelen 1  (Local Loopback)
         RX packets 0  bytes 0 (0.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 0  bytes 0 (0.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    其中eth0接口支持广播，其子网广播地址为172.17.255.255

  4. 如果我们用ping程序向一个广播地址发送一个长的分组，如 (略)， 它正常工作，但将分组的长度再增加一个字节后出现如下差错：

     sun % ping 140.252.13.63 1473
 PING 140.252.13.63: 1473 data bytes
 sendto: Message too long

    究竟出了什么问题?
    可能是发送端设置了不允许分片，导致ping程序无法发出需要分片的广播报文。

  5. 重做习题10.6，假定8个RIP报文是通过多播而不是广播（使用RIP 版本2）。有什么变化？

    改为多播后主机网卡将直接丢弃该报文，如果是广播，则网卡会接收，有网卡驱动进行过滤丢弃。

第十三章 IGMP：Internet组管理协议

  1. 我们知道主机通过设置随机时延来调度IGMP的发送。一个局域网中的主机采取什么措施才能避免两台主机产生相同的随机时延？

    可以简单通过MAC地址做HASH，将值映射到时间段1~10s内，如果局域网中的主机数量多于10台，则将精度扩大，变为1 ~ 6000ms。只有发生HASH碰撞时两台主机的随机时延才相同。

  2. 在[Casner and Deering 1992]中，他们提到UDP缺少两个通过MBONE传送音频采样数据的条件：分组失序检测和分组重复检测。你怎样在UDP上增加这些功能？

    略

第十四章 DNS:域名系统

  1. 讨论一个DNS名字解析器和一个DNS名字服务器作为客户程序、服务器或同时作为客户和服务器的情况。

    • 分别作为解析器和服务器

      名字解析器首先通过/etc/resolv.conf获取域名服务器A，向域名服务器A发送IP查询请求，域名服务器向根名字服务器查询域名所在的名字服务器，接收到根名字服务器的返回结果B后，A向名字服务器B发送IP查询，A收到名字服务器B的结果后将器缓存到自身磁盘中，并返回给名字解析器。

    • 同时作为解析器与服务器

      名字解析器在自身缓存中直接获取到目标域名的IP地址，直接使用，无需向域名服务器发送查询请求。

  2. 说明图14-12中构成响应的75个字节的含义。

    首部

    • 20字节IP头
    • 8字节UDP头
    • 12字节DNS首部

    RR

    • 21字节域名
    • 2字节类型
    • 2字节类
    • 4字节TTL
    • 2字节长度
    • 4字节IP地址

  3. 在12.3节我们指出，一个既可接受点分十进制形式的IP地址、也可接收主机名的应用程序，应先假定输入的是IP地址，如果失败，再假定是主机名。如果改变这个测试顺序会出现什么情况？

    改变这个测试顺序会导致输入IP地址时每次都做了多余的DNS查询。

  4. 每个UDP数据报有一个相应的长度。一个接收UDP数据报的进程将被告知这个长度。当名字解析器使用TCP而不是UDP来处理查询请求时，由于TCP是没有任何记录标记的字节流，那么应用程序是如何知道有多少数据返回？注意在DNS的报文首部（图14-3）中没有任何长度字段（提示：查阅RFC 1035）

    RFC 1035 [Domain Implementation and Specification]
    增加两个字节前缀作为TCP数据报的长度。

  5. 我们说一个名字服务器必须知道根名字服务器的IP地址，这一信息可通过匿名FTP获得。不幸的是当根名字服务器表发生变化时，并不是所有的系统管理员都会更新他们的DNS配置文件（根名字服务表的确会发生变化，尽管不是经常的）你认为DNS如何处理这个问题？

    DNS可以使用失败更新机制在和根名字服务器通信失败时尝试重新更新DNS配置文件；或者使用定时更新的方式，定时的去更新根名字服务表。

  6. 利用习题1.8指明的文件来确定谁应负责维护根名字服务器。名字服务器更新的频度是怎样的？

    略

  7. 维护一个名字服务器和一个无状态的名字解析器高速缓存的问题分别是什么？

    略

  8. 在图14-10的讨论中，我们指出名字服务器将对A类型记录进行排序以便在公共网中的地址先出现。谁对A类型记录进行这种排序，是名字服务器还是名字解析器?

    名字服务器，因为TCPDUMP抓的包是名字服务器返回的，此时已经做了排序，故而是名字服务器返回的。

第十五章 TFTP：简单文件传送协议

  1. 阅读Host Requirements RFC，了解如果一个TFTP服务器收到的请求的目的IP地址是一个广播地址，它将做什么。

    RFC [THE TFTP PROTOCOL (REVISION 2)]
    略。

  2. 当TFTP块号由65535跳回到0时，你认为会发生什么？ RFC 1350提到了如何处理这一问题吗？

    会导致覆盖原有数据，RFC 1350没有提到如何处理该问题，故而当前TFTP最多只能处理$65535*512Byte=32MB$

  3. TFTP发送方采用超时重发来处理分组丢失。当TFTP作为引导进程的一部分时，这种方法对TFTP的使用有何影响？

    超时时间设置过大时将导致丢包代价过高，过小可能导致重复收发包阻塞网络。

  4. 使用TFTP时，影响传输文件所需时间的限制性因素是什么？

    超时重发机制的超时时间间隔大小。

第十六章 BOOTP：引导程序协议

  1. 我们说BOOTP优于RARP的一个方面是BOOTP能穿越路由器，而RARP由于使用链路层广播则不能。在16.5节为使BOOTP穿越路由器，我们必须定义特殊的方式。如果在路由器中增加允许转发RARP请求的功能会发生什么？

    由于RARP是基于链路层的协议，其穿越路由器跨三层之后就服务端无法发送回应报文到客户端上，因为此时客户端还没有IP地址；另外，将二层广播泛洪报文转发到三层链路上将可能导致拥塞网络。

  2. 我们说过，当有多个客户程序同时向一个服务器发出引导请求时，因为服务器要广播多个BOOTP应答，BOOTP客户就必须使用事务标识来使响应与请求相匹配。但在图16-3中，事务标识为0，表示这个客户不考虑事务标识。你认为这个客户将如何将这些响应与其请求匹配。

    这是由于此时服务端没有采用广播发送回复报文，故而客户端无需进行特殊匹配。

第十七章 TCP：传输控制协议

  1. 我们已经介绍了以下几种分组格式： IP、ICMP、IGMP、UDP和TCP。每一种格式的首部中均包含一个检验和。对每种分组，说明检验和包括IP数据报中的哪些部分，以及该检验和是强制的还是可选的。

    • IP

      IP分组校验和仅包含IP首部，同时不含有首部中的校验和字段。IP首部校验和是可选的。

    • ICMP

      ICMP校验和字段含ICMP报文首部及数据段。ICMP检验和是必须的。

    • IGMP

      IGMP校验和字段含IGMP报文首部及数据段。IGMP校验和是必须的。

    • UDP

      UDP检验和包含报文首部和数据，同时含有一个伪首部。UDP首部校验和是必须的。

    • TCP

      TCP检验和包含报文首部和数据，同时含有一个伪首部。TCP首部校验和是必须的。

  2. 为什么我们已经讨论的所有Internet协议（IP, ICMP, IGMP, UDP, TCP）收到有检验和错的分组都仅作丢弃处理？

    这是由于Internet协议底层的数据链路层本身就是不可靠的，数据报在传输过程中本身就存在概率性丢包或包损坏的情况。这是发送端必须要考虑的场景，故而接收方只需要将顺坏的报文直接丢弃，如丢包一样处理即可，如果本次通信是可靠的，发送方会处理重传。

  3. TCP提供了一种字节流服务，而收发双方都不保持记录的边界。应用程序如何提供它们自己的记录标识？

    很多Internet应用使用一个回车和换行来标记每个应用记录的结束。这是 NVT ASCII采用的编码（26.4节） 。另外一种技术是在每个记录之前加上一个记录的字节计数， DNS（习题14.4）和Sun RPC（29.2节）采用了这种技术。

  4. 为什么在TCP首部的开始便是源和目的的端口号？

    ICMP数据报返回差错报文时，含IP首部和IP数据报的前8个字节，故而不论时TCP还是UDP，想要正确识别ICMP差错报文，就必须将端口放在前8个字节。

  5. 为什么TCP首部有一个首部长度字段而UDP首部（图11 - 2）中却没有？

    这是由于UDP首部是定长的，而TCP首部拥有可选字段。

第十八章 TCP连接的建立和终止

  1. 在18.2节我们说初始序号（ISN）正常情况下由1开始，并且每0.5秒增加64000，每次执行一个主动打开。这意味着ISN的最低三位通常总是001。但在图18-3中，两个方向上ISN中的最低三位都是521。究竟是怎么回事?

    这是由于ISN实际上并不仅仅是每0.5s增加64000，每隔4ms也会增加1。

  2. 在图18-15中，我们键入12个字符，看到TCP发送了13个字节。在图18-16中我们键入8个字符，但TCP发送了10个字符。为什么在第1种情况下增加1个字节，而在第2种情况下增加2个字节？

    18-15我们使用的是sock程序，TCP多发送的一个字节时UNIX换行符；18-16我们使用的是Telnet程序，此时会末尾会自动添加回车换行符，故而多两个字节。故而这种差异性是由应用层客户端导致的。

  3. 半打开连接和半关闭连接的区别是什么？

    • 半打开

      指双方建立连接后，有一方退出但是没有通知对端FIN或RST，导致对端不知道其已退出，此时对端就是半打开状态。

    • 半关闭

      指双方建立连接后，有一方退出，并且通知了对端，对端收到FIN之后回了ACK，但是还没有发送FIN关闭自身的连接时，此时就属于半关闭状态。

  4. 如果启动sock程序作为一个服务器程序，然后终止它（还没有客户进程与它相连接），我们能立即重新启动这个服务器程序。这意味着它没有经历2MSL等待状态。用状态变迁来解释这一切。

    只有ESTABLISHED状态下主动关闭的一方才会进入到TIME_WAIT状态，LISTEN状态下直接退出不会走到TIME_WAIT状态。

  5. 在18.6节我们知道一个客户进程不能重新使用同一个本地端口，如果该端口是仍处于2MSL等待连接的一部分。但如果sock程序作为客户程序连续运行两次，并且连接到daytime服务器上，我们就能重新使用同一本地端口。另外，对一个仍处于2MSL等待的连接，也能为它创建一个替身。这将如何做？

    需要设置SO_REUSEADDR强制复用端口即可。

  6. 在18.6节的最后，我们介绍了FINWAIT2状态，提到如果应用程序仅过11分钟后实行完全关闭（不是半关闭），许多具体的实现都将一个连接由这个状态转移到CLOSED状态。如果另一端（处于CLOSEWAIT状态）在宣布关闭（即发送FIN）之前等待了12分钟，这一端的TCP将如何响应这个FIN？

    由于12分钟后应用程序已经进入CLOSED状态，此时连接已经不存在，收到来自对端的FIN报文，将会回复RST。

  7. 对于一个电话交谈，哪一方是主动打开，哪一方是被动打开？是否允许同时打开？是否允许同时关闭？

    拨打电话的属于主动打开，接听电话的属于被动打开，不允许同时打开，允许同时关闭。

  8. 在图18-6中，我们没有见到一个ARP请求或一个ARP应答。显然主机svr4的硬件地址一定在bsdi的ARP高速缓存中。如果这个ARP高速缓存不存在，这个图会有什么变化？

    在svr4回第一个报文前回增加两行报文交互，ARP请求和ARP应答。

  9. 解释如下的tcpdump输出，并和图18-13进行比较。

    不同在于三次握手的最后一次ACK没有单独发送一个报文，而是与下一个报文一起发送，这样可以减少一次发包。

  10. 为什么图18-4中的服务器不将对客户FIN的ACK与自己的FIN合并，从而将报文段数减少为3个？

    这是由于TCP连接的半关闭机制，客户端关闭之后，只是中断了客户端向服务端传送数据的通道，但是此时服务端还可以往客户端发送数据。

  11. 在图18-16中，RST的序号为什么是26368002?

    这是由于第6个报文bsdi回给srv4上的报文带的ack是26368001，故而srv4重启之后也能得知自己的序号应当为多少。

  12. TCP向链路层查询MTU是否违反分层的规则？

    略。

  13. 假定在图14.16中，每个DNS使用TCP而不是UDP进行查询，试问需要交换多少个报文段？

    DNS使用UDP使会产生两个报文，UDP查询和UDP响应报文。如果更换为TCP，则连接的建立和终止需要多7个报文，同时查询和响应需要多两个ACK报文，即一次查询产生11个报文，多9个报文。总共产生5个查询，总共需要55个报文，多出45个报文。

  14. 假定MSL为120秒，试问系统能够初始化一个新连接然后进行主动关闭的最大速率是多少？

    关闭一个连接需要2MSL即240秒，初始化连接和关闭连接的报文在网络环境正常的情况基本可以忽略，如果不复用或不适用其他客户端端口的情况下，最大速率为1/240(个/秒)。如果使用其他客户端端口，则可以同时建立很多个端口，去掉知名端口 $65525-1024=64511$，则为$64511 \div 240=268.8（个/秒）$

  15. 阅读RFC 793，分析处于TIMEWAIT状态的主机收到使其进入此状态的重复的FIN时所发生的情况。

    重复的FIN会得到确认，2MSL定时器重新计时。

  16. 阅读RFC 793，分析处于TIMEWAIT状态的主机收到一个RST时所发生的情况。

    TIMEWAIT状态忽略RST报文。

  17. 阅读Host Requirements RFC并找出半双工TCP关闭的定义。

    略。

  18. 在图1-8中，我们曾提到到来的TCP报文段可根据其目的端口号进行分用，请问这种说法是否正确？

    不。输入的数据段通过源IP地址、源端口号、目的IP地址和目的端口号进行区分。一个SOCKET对应一个四元组，唯一标识一个连接。

第19章 TCP的交互数据流

  1. 考虑一个TCP客户应用程序，它发送一个小应用程序首部（8个字节）和一个小请求（12个字节），然后等待来自服务器的一个应答。比较以下两种方式发送请求时的处理情况：先发送8个字节再发送12个字节和一次发送20个字节。

    以太网头部12Byte, IP头部20Byte, TCP头部20Byte，如果使分开发送，则前后总共发送两个报文并需要接收两个ACK，发送报文大小分别为60Byte与64Byte，总共124Byte；如果单独发送20Byte，则只需要一个ACK，发送报文大小为72Byte报文。
    同时单独发送需要考虑Nagle算法和延时确认机制导致的时延，如果触发的Nagle算法，则需要等待服务端回下一个ACK时才继续发送，而服务端如果除法了延时确认算法，回ACK就可能最大需要200 MS的延时。

  2. 图19-4中我们在路由器sun上运行tcpdump。这意味着从右至左的箭头中的数据也需要经过bsdi，同时从左至右的箭头中的数据已经流经bsdi。当观察一个送往slip的报文段及下一个来自slip的报文段时，我们发现它们之间的时间差分别为：34.8、26.7、30.1、28.1、29.9和35.3ms。现给定在sun和slip之间存在两条链路（一个以太链路和一个9600 b/s的CSLIP链路），试问这些时间差的含义（提示：重新阅读2.10节）。

    假设5个字节的CSLIP首部（IP和TCP）和两个字节的数据，总共47字节，这些段通过SLIP链路的RTT大约是$(47 \div 960 B/s) \times 2=14.6ms$。我们要加上通过以太网的 RTT（一般是5~10 ms），加上在sun和bsdi上的选路时间。因此，观察到的时间看起来是正确的。

  3. 比较在使用Nagle算法（图19-6）和禁止Nagle算法（图19-8）的情况下发送一个特殊功能键并等待其应答所需要的时间。

    可以看到，如若不丢包，不使用Nagle算法耗时0.28 s，丢了一个包之后，耗时2.48 s；使用Nagle算法，没有发送丢包，耗时0.49 s。
    Nagle算法导致其触发了两次完整的延时发送，耗时0.4 s，这是Nagle算法的主要耗时段。
    不使用Nagle算法时，虽然也触发两次延时，但由于两次延时没有相互等待，故而总时长主要看最后一次时延，耗时0.2 s, 可以看到，如果没有丢包情况，不采用Nagle算法必然是比采用Nagle算法要快的。

第20章 TCP的成块数据流

  1. 在图20-6中，我们可以看到一个序号为0的字节和一个序号为8193的字节，试问这两个字节的含义是什么？

    0字节表示初始滑动窗口左延边的字节，8193表示最终传送结束时滑动窗口左延边的字节。

  2. 提前观察图22-1，并解释主机bsdi设置PUSH标志的含义。

    第一个PUSH是慢启动，拥塞控制窗口大小为1，只能发送一个报文；第二个PUSH是等待第一个报文ACK（延时确认时）总共有三个报文累计在TCP发送缓存里面，故而第三个报文有PUSH标志，但是此时拥塞控制窗口为2，先发送两个不带PUSH标志的报文，等ACK到了之后，发送第三个报文，由于没有PUSH标志，表示还有报文没有发送故而立即回ACK（不做延时确认），第三个报文立即发送，此时带有PUSH标志，此时拥塞控制窗口扩大到4，再来一个报文，又立即发送PUSH标志过去，接收到接到两个报文，直接回ACK（不做延时确认），此时拥塞控制窗口扩大到8，接下来按序到3个发送报文，直接发送出去。

  3. 在一个Usenet记录中，有人抱怨说美国和日本之间的一个128 ms时延、速率为256 000 b/s的链路吞吐量为120 000 b/s（利用率为47%），而当链路通过卫星时其吞吐量则为33 000 b/s（利用率为13%）。试问在这两种情况下窗口大小各为多少（假定卫星链路的时延为500 ms）？卫星链路的窗口大小应该如何调整？

    链路窗口：$120000 b/s \times 0.128 s \div 8 b/B= 1920 Byte$
    卫星窗口：$33000 b/s \times 0.5 s \div 8 b/B = 2062.5 B$
    链路-带宽时延乘积：$256000 b/s \times 0.128 s \div 8 b/B= 4096 Byte$
    卫星-带宽时延乘积：$256000 b/s \times 0.5 s \div 8 b/B= 16000 Byte$
    故而卫星链路的窗口大小应该调整为至少16000 Byte

  4. 如果API提供一种方法，使得发送方可以告诉其TCP打开PUSH标志，而接收方可以查询一个接收的报文段是否被设置了PUSH标志，试问该标志能否被用作一个记录标记？

    可以，前提是发送发不告诉TCP打开PUSH标志时，TCP不能主动打开该标志。

  5. 在图20-3中为什么没有合并报文段15和16？

    15是一个窗口扩大报文，不宜和FIN报文合并。

  6. 在图20-13中，我们假定对应数据报文段之间的间隔，返回的ACK之间的间隔被分隔得很好。如果在链路某处进行缓存并使许多ACK同时到达发送方，试问会发生什么情况？

    按照接收端接收的先后顺序，可能回导致触发乱序重传。

第21章 TCP的超时和重传

  1. 在图21-5中第1个超时时间计算为6秒而第2个为12秒。如果初始SYN的确认在12秒超时溢出时还没有到达，则下一次超时在什么时候发生？

    24 s，指数退避。

  2. 在图21-5后面的讨论中，我们提到计算的超时间隔分别为图4-5中表示的6、24和48秒。但是如果观察一个从SVR4系统到一个不存在的主机的连接，则超时间隔分别为6, 12, 24和48秒。请问发生了什么情况？

    略。

  3. 按下面的描述比较TCP滑动窗口协议与TFTP的停止等待协议的性能。在本章中，我们在35秒（图21-6）内传输32768字节的数据，其中链路的平均RTT是1.5秒（图21-4）。计算在同样条件下TFTP需要多长时间？

    TFTP以512 Byte为一个包进行传输，总共需要$21768 \div 512 = 64$个包，同样条件下我们认为也会丢失3个包，故而总共需要发送67个包，及等待3个超时时间。总共需要时间为$3 \times 5s + 67 \times 1.5s = 123s$。即TFTP传输需要123秒。

  4. 在第21.7节，我们提到过收到一个重复的ACK是因为一个报文段丢失或重新进行排序。在21.5节我们看到1个丢失的报文段产生一些重复的ACK。请画图表示重新排序也会产生一些重复的ACK。

    按序发送三个报文，1:257(256) 257:513(256) 513:769(256)，假设接收反正好倒叙收到这三个报文，则回的ACK确认序号是下一个期望的序号，为下：ACK 1, ACK 1，ACK 257。此时收到两个重复ACK。

  5. 在图21-6中的时刻28.8和29.8之间有一个显而易见的点，请问这是不是一个重传？

    不是，重传结束之后cwnd会有明显下降，此处只是有一段平滑区间，可能是接收端ACK回复慢了一点，或许是延时确认，或许是网络稍微延时。

  6. 在21.6节我们提到过，如果目的地址位于一个不同的网络上，4.3 BSD Tahoe版本只执行慢启动。你认为在这里“不同的网络”是由什么决定的？（提示：参看附录E）。

    由源IP地址与目的IP地址的网络号及子网号是否相同，及内核变量来决定是否是本地网络，还是不同网络。

  7. 在20.2节我们提到过，在正常情况下，TCP每隔一个报文段进行一次确认，但是在图21-2中，我们看到接收方对每个报文段都进行了确认，请解释其中的原因？

    接收方回ACK有个延时确认的机制，在200 ms时间内，有下一个发送方报文的到来或接收方需要发送报文，会立即回复ACK，否则超时200 ms之后回复ACK。由于图21-2中明显RTT时间较长，此时前后收到两个报文间隔通常也较长，这可能是图21-2接收一个报文回复一个ACK的原因。

  8. 如果默认路由占优势，那么每路由（per-route）的度量是否真的有用？

    仍然有用，只是不太准确，但是以其作为一个初始值是可以的。通常默认路由指向互联网，会经过一段相同的营运商网络，故而是有用的。

第22章 TCP的坚持定时器

  1. 在图22-3中注意到所有确认（报文段5、7、9、11、13、15和17）的发送时刻为：0.170, 5.170、10.170、15.170、20.170和25.170，还注意到在接收数据和发送ACK之间的时间差分别为：164.5、18.5、18.7、18.8、198.3、18.5和19.1 ms。试解释可能会发生的情况。

    略。

  2. 在图22-3中的时刻25.174，发送出一个767字节的通告窗口，而在接收缓存中有768字节的可用空间。为什么相差1个字节？

    略。

第23章 TCP的保活定时器

  1. 列出保活功能的一些优点。
  • 能让应用程序检测出半关闭的连接，进而释放连接所占用的资源。
  1. 列出保活功能的一些缺点。
  • 消耗带宽，增加流量计费。
  • 网络临时出现问题时，可能错误关闭一个正常的连接。

第24章 TCP的未来和性能

  1. 当一个系统发送一个开始的SYN报文段，其窗口扩大因子为0，这是什么含义？

    可测试对端是否支出窗口扩大选项。

  2. 如果在图24-7中的主机bsdi支持窗口扩大选项，则来自vangogh的报文段3的16 bit窗口大小字段中的期望值是多少？类似地，如果在该图的第2个连接中也使用这个选项，那么报文段13中的窗口通告应该是多少？

    vangogh的窗口大小字段为 $65535 \times 2 = 131070$，报文段13的窗口通告应为 $65535 \times 2^2 = 262140$。

  3. 与在建立连接时的固定窗口扩大因子不同，已经定义过的窗口扩大因子能否在扩大因子变化时也出现呢？

    窗口扩大因子在连接建立时确认，往后扩大因子无法更改。

  4. 假定MSL为2分钟，那么在什么速率下序号回绕会成为一个问题呢?

    在MSL时间内走完2^32 Byte个报文就会产生回绕，速率为 $(2^{32} \times 8)b \div (2 \times 60)s = 286,331,153 b/s$。

  5. PAWS被定义为只在一个单独的连接中进行。为了使TCP将PAWS来替换2MSL等待(即TIMEWAIT状态)，需要进行什么改动？

    使TCP自动识别对端发送来的FIN报文或其他数据报文是否使本次连接，更具PAWS来识别，如果不是，由TCP直接代为处理。这样即可做到TIMEWAIT避免的新旧连接数据冲突，及ACK报文丢失导致对端无法关闭TCP连接的问题。

  6. 在24.4节最后的例子中，为什么sock程序在紧接着（具有IP地址和端口）后面的一行之前，将接收缓存的大小来输出呢？

    这表明使用扩大因子时，由于扩展因子是位便宜扩大，通常应当刚好比接收缓存大一些，不能小，为了最大化吞吐。

  7. 假定MSS为1024，重新计算24.8节中的吞吐量。

    MSS为1024，则总数据最大为$1538 - ( 1460 - 1024 ) = 1102$

  • 发送方传输两个背对背、满长度报文时：

    $\frac{2 \times 1024 B}{2*1102 B + 84 B} \times \frac{10000000 b/s}{8 b/B} = 1,118,881 B/s$

  • TCP窗口开到它的最大值

    $\frac{22 \times 1024 B}{22*1102 B + 84 B} \times \frac{10000000 b/s}{8 b/B} = 1,157,514 B/s$

  1. 时间戳选项是如何影响Karn算法（见21.3节）的？

    加上时间戳选项后，遇到重传报文ACK，无需判断其是首次报文的ACK还是重传报文的ACK，直接取ACK中的时间戳与当前时间戳差值即可计算出RTT时间即可。Karn算法已经不再被需要。

  2. 如果主动建立连接的TCP发送带有SYN标志的报文段（没有使用我们在24.7节介绍的扩展），那么接收TCP应该怎样处理这些数据呢?

    回复RST报文即可。

  3. 在24.7节我们提到如果没有使用T/TCP扩展，即使主动开启方发送带有FIN的数据，客户在接收服务器的响应的时延仍然是两倍的RTT再加上SPT。给出符合这种情况的报文段。

    略。

  4. 假定支持T/TCP，且源自伯克利系统的最小RTO为0.5秒，重做习题18.14。

    略。

  5. 如果我们实现了T/TCP，并测量两个主机之间的事务时间，那么可以通过比较什么指标来确定它的有效性？

    略，（TIME_WAIT时间，RTT时间，SPT时间？？？）。

第25章 SNMP：简单网络管理协议

  1. 我们说过采用两个不同的UDP端口（161和162）可以使得一个系统既可以是管理进程，也可以是代理进程。如果对管理进程和代理进程采用一个同样的端口，会出现什么情况？

    此时如果管理进程和代理进程同时在一个系统上，那么通信建立连接时，将出现自身到自身的一个连接，此时代理程序或管理程序将有一端无法打开端口，显示端口已经被使用。

  2. 用get-next操作，如何列出一张路由表的完整信息？？

    首先获取路由表的一个实例对象，然后调用get-next一直遍历，直到返回的属性不再属于路由表的属性则结束，由于SNMP的对象是已层次结构命名的，故而很容易通过字符串比较判断该属性是否属于路由表。

第26章 Telnet和Rlogin：远程登陆

  1. 在图26-5中，标出所有延迟的ACK。

    报文8。

  2. 在图26-7中，为什么要发送报文段12？

    保持定时器，检测对端win窗口大小。

  3. 我们说过Rlogin客户进程必须使用保留端口号（见1.9节）（通常Rlogin客户使用512~1023之间的保留端口）。这会给主机带来什么限制？有没有解决的办法？

    保留端口号是可能被使用的，故而Rlogin占用该端口可能引起其它服务异常，同时保留端口数有限，Rlogin客户端个数容易被限制。

  4. 阅读RFC 1097，它描述了Telnet的阈下报文(subliminal-message)选项。

    略。

第27章 FTP：文件传输协议

  1. 图27-8中，如果客户对第2个数据连接做一次主动打开，而不是由服务器来做，那将发生什么变化？

    同样会打开失败，客户端上的sock四元组处在TIME_WAIT中。

  2. 在本章FTP客户例子中，我们加入诸如由客户输出行的行注释。如果不看源代码，我们如何确定这些不是来自服务器？
    local: hello.c remote: hello.c
    42 bytes received in 0.0037 seconds (11 Kbytes/s)

    通常服务器的结果输出都是带有代码号的，比如220-开头，220空格结束。

第28章 SMTP：简单邮件传输协议

  1. 读RFC 822，找到域文字（domain literal）的意思。试试用其中一个给自己发送邮件。

    略。

  2. 除了连接建立和终止外，要发送一个小的邮件报文的最小网络往返次数是多少？

    HELO-MAIL-RCPT-DATA-. 共有5个命令需要发送，故而至少10个网络往返。

  3. TCP是一个全双工协议，但是SMTP用半双工的形式使用TCP。客户发送一个命令后停止等待应答。为什么客户不一次发送多个命令，如一行中包括HELO、MAIL、RCPT、DATA和QUIT命令（假定正文不是太大）？

    命令解耦，各个命令直接互不影响，独立设置，独立修改，不会导致修改一个命令时，所有的命令重新发送。

  4. 当网络在接近其容量运行时， SMTP的这种半双工操作如何欺骗缓慢的启动机制？

    每个小命令单独发送，使得用户的人机交互时间远大于报文传输时间，故而从用户观感上感受不出来网络的缓慢。

  5. 当存在多个具有相同优先值的MX记录时，名服务器是否总能以相同的顺序返回它们？

    可以，MX记录进行排序时不仅看优先级，优先级相同之后还会排序IP地址等字段。

第29章： 网络文件系统

  1. 在图29-7中，我们看到tcpdump将分组理解为NFS的请求和应答，打印了XID。tcpdump可以为任何的RPC请求或者应答这样做吗？

    不可以，tcpdump只能为知名的有固定协议描述的RFC过程调用做定制化的打印，其它自定义的RPC则无法做到这样。

  2. 在一个Unix系统中，你认为为什么RPC服务器程序使用的是临时端口，而不是知名端口？

    这是由于RPC服务器程序是可扩展的，RPC只提供了一种标准，基于该标准可定制很多RPC服务，知名端口数是有限的，如果都为这些RPC分配知名端口，将消耗很多知名端口，甚至可能导致端口不够用。

  3. 一个RPC客户调用了两个服务器过程。第1个服务器过程执行花了5秒钟的时间，第二个过程花了1秒钟。客户有一个4秒钟的超时。画出客户与服务器之间在时间轴上交互的信息（假定信息从客户传到服务器或者相反都不花时间）。

    略。

  4. 在图29-9的例子中，如果NFS服务器关机时，把它的以太网卡给换掉了，将会发生什么事情？

    由于RPC是运行在运输层之上的，以太网卡换掉影响的是数据链路层的MAC地址，对上层不影响，故而只会出现NFS客户端由于MAC地址不对导致的更长时间的丢包，等待MAC地址缓存更新之后，将会恢复。

  5. 在图29-9中，当服务器重启动后，它处理了从偏移65536开始的请求（168行和171行），然后处理了从偏移66560开始的下一个请求（172行和173行）。对于从偏移73728开始的请求怎么处理的呢？（167行）

    同样处理即可。

  6. 当描述等幂NFS过程时，我们给出了一个REMOVE应答在网络中丢失的例子。在这种情况下，如果使用的是TCP而不是UDP会怎么样呢？

    首先TCP内部会处理丢包重传，如果服务端已经故障，则KEEPALIVE保活定时器超时前一直重传，超时之后则应用层NFS同UDP处理一样，重新发送TCP请求。

  7. 如果NFS服务器使用的是一个临时端口而不是2049，那么当服务器崩溃然后又重启动时，一个NFS客户会发生什么情况呢？

    首先NFS客户会收到服务器的一个RST回复（TCP）或者是ICMP网络不可达错误（UDP），客户端会重新发送RPC查询端口映射，从头开始尝试重新建立NFS连接。

  8. 每个主机最多只有1023个保留端口，所以保留端口是很缺乏的（1.9节）。如果一个NFS服务器要求它的客户拥有保留端口（公共的端口），一个NFS客户使用TCP安装了N个不同的服务器上的N个文件系统，那么客户对每个连接都需要一个不同的保留端口号吗？

    对于不同的服务器可以重用保留端口，因为SOCK是由四元组唯一标识的，但是如果是同一个服务器上的文件系统，就无法复用。

第30章 其它的TCP/IP应用程序

  1. 试用Whois找到网络号为88的A类网络的拥有者。

    略。

  2. 试用Whois找到管理whitehouse.gov域的DNS服务器。这个应答与DNS给出的答案相匹配吗？

    略。

  3. 在图30-3中，你认为xscope进程必须和X服务器运行在同一台主机上吗？

    不必要，xscope进程运行在X服务器和客户端的中间，通过TCP连接两端，故而不再同一主机上也可以工作。

Search

    Table of Contents