tcp/ip (六)

6.1 引言
I C M P经常被认为是I P层的一个组成部分。它传递差错报文以及其他需要注意的信息。
I C M P报文通常被I P层或更高层协议（ T C P或U D P）使用。一些I C M P报文把差错报文返回给
用户进程。
I C M P报文是在I P数据报内部被传输的，如
图6 - 1所示。
ICMP 的正式规范参见RFC 792 [Posterl
1 9 8 1 b ]。
I C M P报文的格式如图6 - 2所示。所有报文的
前4个字节都是一样的，但是剩下的其他字节则互不相同。下面我们将逐个介绍各种报文格式。
类型字段可以有1 5个不同的值，以描述特定类型的I C M P报文。某些I C M P报文还使用代
码字段的值来进一步描述不同的条件。
检验和字段覆盖整个I C M P报文。使用的算法与我们在3 . 2节中介绍的I P首部检验和算法相
同。I C M P的检验和是必需的。
图6-2 ICMP报文
在本章中，我们将一般地讨论I C M P报文，并对其中一部分作详细介绍：地址掩码请求和
应答、时间戳请求和应答以及不可达端口。我们将详细介绍第2 7章P i n g程序所使用的回应请
求和应答报文和第9章处理I P路由的I C M P报文。
6.2 ICMP报文的类型
各种类型的I C M P报文如图6 - 3所示，不同类型由报文中的类型字段和代码字段来共同决定。
图中的最后两列表明I C M P报文是一份查询报文还是一份差错报文。因为对I C M P差错报
文有时需要作特殊处理，因此我们需要对它们进行区分。例如，在对I C M P差错报文进行响应
时，永远不会生成另一份I C M P差错报文（如果没有这个限制规则，可能会遇到一个差错产生
另一个差错的情况，而差错再产生差错，这样会无休止地循环下去）。
当发送一份I C M P差错报文时，报文始终包含I P的首部和产生I C M P差错报文的I P数据报的
前8个字节。这样，接收I C M P差错报文的模块就会把它与某个特定的协议（根据I P数据报首
图6-1 ICMP封装在IP数据报内部
ICMP报文
IP数据报
20字节
IP首部
(不同类型和代码有不同的内容)
8位类型8位代码16位检验和
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
部中的协议字段来判断）和用户进程（根据包含在I P数据报前8个字节中的T C P或U D P报文首
部中的T C P或U D P端口号来判断）联系起来。6 . 5节将举例来说明一点。
下面各种情况都不会导致产生I C M P差错报文：
1) ICMP差错报文（但是，I C M P查询报文可能会产生I C M P差错报文）。
2) 目的地址是广播地址（见图3 - 9）或多播地址（D类地址，见图1 - 5）的I P数据报。
3) 作为链路层广播的数据报。
4) 不是I P分片的第一片（将在11 . 5节介绍分片）。
5) 源地址不是单个主机的数据报。这就是说，源地址不能为零地址、环回地址、广播地
址或多播地址。
这些规则是为了防止过去允许I C M P差错报文对广播分组响应所带来的广播风暴。
第6章ICMP：Internet控制报文协议使用51 下载
类型代码描述查询差错
0 0 回显应答( P i n g应答，第7章） •
3 目的不可达：
0 网络不可达（ 9 . 3节） •
1 主机不可达（ 9 . 3节） •
2 协议不可达•
3 端口不可达（ 6 . 5节） •
4 需要进行分片但设置了不分片比特（ 11 . 6节） •
5 源站选路失败（8 . 5节） •
6 目的网络不认识•
7 目的主机不认识•
8 源主机被隔离（作废不用） •
9 目的网络被强制禁止•
1 0 目的主机被强制禁止•
11 由于服务类型TO S，网络不可达（9 . 3节） •
1 2 由于服务类型TO S，主机不可达（9 . 3节） •
1 3 由于过滤，通信被强制禁止•
1 4 主机越权•
1 5 优先权中止生效•
4 0 源端被关闭（基本流控制， 11 . 11节） •
5 重定向（9 . 5节）： •
0 对网络重定向•
1 对主机重定向•
2 对服务类型和网络重定向•
3 对服务类型和主机重定向•
8 0 请求回显（ P i n g请求，第7章） •
9 0 路由器通告（ 9 . 6节） •
1 0 0 路由器请求（ 9 . 6节） •
11 超时：
0 传输期间生存时间为0（Traceroute, 第8章） •
1 在数据报组装期间生存时间为0（11 . 5节） •
1 2 参数问题：
0 坏的I P首部（包括各种差错） •
1 缺少必需的选项•
1 3 0 时间戳请求（ 6 . 4节） •
1 4 0 时间戳应答（ 6 . 4节） •
1 5 0 信息请求（作废不用） •
1 6 0 信息应答（作废不用） •
1 7 0 地址掩码请求（6 . 3节） •
1 8 0 地址掩码应答（6 . 3节） •
图6-3 ICMP报文类型
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
6.3 ICMP地址掩码请求与应答
I C M P地址掩码请求用于无盘系统在引导过程中获取自己的子网掩码（ 3 . 5节）。系统广播
它的I C M P请求报文（这一过程与无盘系统在引导过程中用R A R P获取I P地址是类似的）。无盘
系统获取子网掩码的另一个方法是B O O T P协议，我们将在第1 6章中介绍。I C M P地址掩码请
求和应答报文的格式如图6 - 4所示。
图6-4 ICMP地址掩码请求和应答报文
I C M P报文中的标识符和序列号字段由发送端任意选择设定，这些值在应答中将被返回。
这样，发送端就可以把应答与请求进行匹配。
我们可以写一个简单的程序（取名为i c m p a d d r m a s k），它发送一份I C M P地址掩码请求报
文，然后打印出所有的应答。由于一般是把请求报文发往广播地址，因此这里我们也这样做。
目的地址（ 1 4 0 . 2 5 2 . 1 3 . 6 3）是子网1 4 0 . 2 5 2 . 1 3 . 3 2的广播地址（见图3 - 1 2）。
sun % icmpaddrmask 140.252.13.63
received mask = ffffffe0, from 140.252.13.来3自3 本 机
received mask = ffffffe0, from 140.252.13.来3自5 b s d i
received mask = ffff0000, from 140.252.13.来3自4 s v r 4
在输出中我们首先注意到的是，从s v r 4返回的子网掩码是错的。显然，尽管s v r 4接口
已经设置了正确的子网掩码，但是S V R 4还是返回了一个普通的B类地址掩码，就好像子网并
不存在一样。
svr4 % ifconfig emd0
emd0: flags=23<UP,BROADCAST,NOTRAILERS>
inet 140.252.13.34 netmask ffffffe0 broadcast 140.252.13.63
S V R 4处理I C M P地址掩码请求过程存在差错。
我们用t c p d u m p命令来查看主机b s d i上的情况，输出如图6 - 5所示。我们用- e选项来查看
硬件地址。
图6-5 发到广播地址的ICMP地址掩码请求
注意，尽管在线路上什么也看不见，但是发送主机s u n也能接收到I C M P应答（带有上面
“来自本机”的输出行）。这是广播的一般特性：发送主机也能通过某种内部环回机制收到一
份广播报文拷贝。由于术语“广播”的定义是指局域网上的所有主机，因此它必须包括发送
52使用TCP/IP详解，卷1：协议
下载
类型(17或18) 代码(0) 检验和
序列号
32位子网掩码
标识符12字节
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
主机在内（参见图2 - 4，当以太网驱动程序识别出目的地址是广播地址后，它就把分组送到网
络上，同时传一份拷贝到环回接口）。
接下来， b s d i广播应答，而s v r 4却只把应答传给请求主机。通常，应答地址必须是单
播地址，除非请求端的源I P地址是0 . 0 . 0 . 0。本例不属于这种情况，因此，把应答发送到广播
地址是B S D / 3 8 6的一个内部差错。
R F C规定，除非系统是地址掩码的授权代理，否则它不能发送地址掩码应答（为
了成为授权代理，它必须进行特殊配置，以发送这些应答。参见附录E）。但是，正如
我们从本例中看到的那样，大多数主机在收到请求时都发送一个应答，甚至有一些主
机还发送差错的应答。
最后一点可以通过下面的例子来说明。我们向本机I P地址和环回地址分别发送地址掩码
请求：
sun % icmpaddrmask sun
received mask= ff000000, from 140.252.13.33
sun % icmpaddrmask localhost
received mask= ff000000, from 127.0.0.1
上述两种情况下返回的地址掩码对应的都是环回地址，即A类地址1 2 7 . 0 . 0 . 1。还有，我们
从图2 - 4可以看到，发送给本机I P地址的数据报（ 1 4 0 . 2 5 2 . 1 2 . 3 3）实际上是送到环回接口。
I C M P地址掩码应答必须是收到请求接口的子网掩码（这是因为多接口主机每个接口有不同的
子网掩码），因此两种情况下地址掩码请求都来自于环回接口。
6.4 ICMP时间戳请求与应答
I C M P时间戳请求允许系统向另一个系统查询当前的时间。返回的建议值是自午夜开始计
算的毫秒数，协调的统一时间（ Coordinated Universal Time, UTC）（早期的参考手册认为
U T C是格林尼治时间）。这种I C M P报文的好处是它提供了毫秒级的分辨率，而利用其他方法
从别的主机获取的时间（如某些U n i x系统提供的r d a t e命令）只能提供秒级的分辨率。由于
返回的时间是从午夜开始计算的，因此调用者必须通过其他方法获知当时的日期，这是它的
一个缺陷。
I C M P时间戳请求和应答报文格式如图6 - 6所示。
图6-6 ICMP时间戳请求和应答报文
第6章ICMP：Internet控制报文协议使用53 下载
类型(13或14) 代码(0)
标识符
检验和
序列号
发起时间戳20字节
接收时间戳
传送时间戳
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
请求端填写发起时间戳，然后发送报文。应答系统收到请求报文时填写接收时间戳，在
发送应答时填写发送时间戳。但是，实际上，大多数的实现把后面两个字段都设成相同的值
（提供三个字段的原因是可以让发送方分别计算发送请求的时间和发送应答的时间）。
6.4.1 举例
我们可以写一个简单程序（取名为i c m p t i m e），给某个主机发送I C M P时间戳请求，并
打印出返回的应答。它在我们的小互联网上运行结果如下：
程序打印出I C M P报文中的三个时间戳：发起时间戳（ o r i g）、接收时间戳（ r e c v）以
及发送时间戳（ x m i t）。正如我们在这个例子以及下面的例子中所看到的那样，所有的主机
把接收时间戳和发送时间戳都设成相同的值。
我们还能计算出往返时间（r t t），它的值是收到应答时的时间值减去发送请求时的时间值。
d i f f e r e n c e的值是接收时间戳值减去发起时间戳值。这些值之间的关系如图6 - 7所示。
图6-7 i c m p t i m e 程序输出的值之间的关系
如果我们相信RT T的值，并且相信RT T的一半用于请求报文的传输，另一半用于应答报文
的传输，那么为了使本机时钟与查询主机的时钟一致，本机时钟需要进行调整，调整值是
d i f f e r e n c e减去RT T的一半。在前面的例子中， b s d i的时钟比s u n的时钟要慢7 ms和8 ms。
由于时间戳的值是自午夜开始计算的毫秒数，即U T C，因此它们的值始终小于86 400 000
( 2 4×6 0×6 0×1 0 0 0 )。这些例子都是在下午4 : 0 0以前运行的，并且在一个比U T C慢7个小时的
时区，因此它们的值比82 800 000（2 3 0 0小时）要大是有道理的。
如果对主机b s d i重复运行该程序数次，我们发现接收时间戳和发送时间戳的最后一位数
总是0。这是因为该版本的软件（ 0 . 9 . 4版）只能提供1 0 m s的时间分辨率（说明参见附录B）。
如果对主机s v r 4运行该程序两次，我们发现S V R 4时间戳的最后三位数始终为0：
由于某种原因， S V R 4在I C M P时间戳中不提供毫秒级的分辨率。这样，对秒以下的时间
差调整将不起任何作用。
如果我们对子网1 4 0 . 2 5 2 . 1上的其他主机运行该程序，结果表明其中一台主机的时钟与
54使用TCP/IP详解，卷1：协议
下载
发起
请求
接收传送
应答
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
s u n相差3 . 7秒，而另一个主机时钟相差近7 5秒：
另一个令人感兴趣的例子是路由器g a t e w a y（一个C i s c o路由器）。它表明，当系统返回
一个非标准时间戳值时（不是自午夜开始计算的毫秒数， U T C），它就用32 bit时间戳中的高
位来表示。我们的程序证明了一点，在尖括号中打印出了接收和发送的时间戳值（在关闭高
位之后）。另外，不能计算发起时间戳和接收时间戳之间的时间差，因为它们的单位不一致。
如果我们在这台主机上运行该程序数次，会发现时间戳值显然具有毫秒级的分辨率，而
且是从某个起始点开始计算的毫秒数，但是起始点并不是午夜U T C（例如，可能是从路由器
引导时开始计数的毫秒数）。
作为最后一个例子，我们来比较s u n主机和另一个已知是准确的系统时钟—一个N T P
stratum 1服务器（下面我们会更多地讨论N T P，网络时间协议）。
如果我们把d i f f e r e n c e的值减去RT T的一半，结果表明s u n主机上的时钟要快3 8 . 5～51.5 ms。
6.4.2 另一种方法
还可以用另一种方法来获得时间和日期。
1) 在1 . 1 2节中描述了日期服务程序和时间服务程序。前者是以人们可读的格式返回当前
的时间和日期，是一行A S C I I字符。可以用t e l n e t命令来验证这个服务：
另一方面，时间服务程序返回的是一个3 2 b i t的二制进数值，表示自U T C，1 9 0 0年1月1日
午夜起算的秒数。这个程序是以秒为单位提供的日期和时间（前面我们提过的r d a t e命令
使用的是T C P时间服务程序）。
2) 严格的计时器使用网络时间协议（ N T P），该协议在RFC 1305 中给出了描述[ M i l l s
1 9 9 2 ]。这个协议采用先进的技术来保证L A N或WA N上的一组系统的时钟误差在毫秒
级以内。对计算机精确时间感兴趣的读者应该阅读这份R F C文档。
3) 开放软件基金会（ O S F）的分布式计算环境（ D C E）定义了分布式时间服务（ D T S），
第6章ICMP：Internet控制报文协议使用55 下载
前三行是Telnet客户的输出
这是日期时间服务器的输出
这也是Telnet客户的输出
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
它也提供计算机之间的时钟同步。文献[ R o s e n b e rg, Kenney and Fisher 1992]提供了该服
务的其他细节描述。
4) 伯克利大学的U n i x系统提供守护程序t i m e d( 8 )，来同步局域网上的系统时钟。不像
N T P和D T S，t i m e d不在广域网范围内工作。
6.5 ICMP端口不可达差错
最后两小节我们来讨论I C M P查询报文—地址掩码和时间戳查询及应答。现在来分析一
种I C M P差错报文，即端口不可达报文，它是I C M P目的不可到达报文中的一种，以此来看一
看I C M P差错报文中所附加的信息。使用U D P（见第11章）来查看它。
U D P的规则之一是，如果收到一份U D P数据报而目的端口与某个正在使用的进程不相符，
那么U D P返回一个I C M P不可达报文。可以用T F T P来强制生成一个端口不可达报文（ T F T P将
在第1 5章描述）。
对于T F T P服务器来说， U D P的公共端口号是6 9。但是大多数的T F T P客户程序允许用
c o n n e c t命令来指定一个不同的端口号。这里，我们就用它来指定8 8 8 8端口：
c o n n e c t命令首先指定要连接的主机名及其端口号，接着用g e t命令来取文件。敲入g e t
命令后，一份U D P数据报就发送到主机s v r 4上的8 8 8 8端口。t c p d u m p命令引起的报文交换结果
如图6 - 8所示。
图6-8 由TFTP产生的ICMP端口不可达差错
在U D P数据报送到s v r 4之前，要先发送一份A R P请求来确定它的硬件地址（第1行）。接着
返回A R P应答（第2行），然后才发送U D P数据报（第3行）（在t c p d u m p的输出中保留A R P请
求和应答是为了提醒我们，这些报文交换可能在第一个I P数据报从一个主机发送到另一个主
机之前是必需的。在本书以后的章节中，如果这些报文与讨论的题目不相关，那么我们将省
略它们）。
一个I C M P端口不可达差错是立刻返回的（第4行）。但是， T F T P客户程序看上去似乎忽
略了这个I C M P报文，而在5秒钟之后又发送了另一份U D P数据报（第5行）。在客户程序放弃
56使用TCP/IP详解，卷1：协议
下载
指定主机名和端口号
试图得到一个文件
大约25秒后
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
之前重发了三次。
注意，I C M P报文是在主机之间交换的，而不用目的端口号，而每个2 0字节的U D P数据报
则是从一个特定端口（ 2 9 2 4）发送到另一个特定端口（ 8 8 8 8）。
跟在每个U D P后面的数字2 0指的是U D P数据报中的数据长度。在这个例子中， 2 0字节包
括T F T P的2个字节的操作代码， 9个字节以空字符结束的文件名t e m p . f o o，以及9个字节以
空字符结束的字符串n e t a s c i i（T F T P报文的详细格式参见图1 5 - 1）。
如果用- e选项运行同样的例子，我们可以看到每个返回的I C M P端口不可达报文的完整长
度。这里的长度为7 0字节，各字段分配如图6 - 9所示。
图6-9 “UDP端口不可达”例子中返回的ICMP报文
I C M P的一个规则是， I C M P差错报文（参见图6 - 3的最后一列）必须包括生成该差错报文
的数据报I P首部（包含任何选项），还必须至少包括跟在该I P首部后面的前8个字节。在我们
的例子中，跟在I P首部后面的前8个字节包含U D P的首部（见图11 - 2）。
一个重要的事实是包含在U D P首部中的内容是源端口号和目的端口号。就是由于目的端
口号（ 8 8 8 8）才导致产生了I C M P端口不可达的差错报文。接收I C M P的系统可以根据源端口
号（2 9 2 4）来把差错报文与某个特定的用户进程相关联（在本例中是T F T P客户程序）。
导致差错的数据报中的I P首部要被送回的原因是因为I P首部中包含了协议字段，使得
I C M P可以知道如何解释后面的8个字节（在本例中是U D P首部）。如果我们来查看T C P首部
（图1 7 - 2）,可以发现源端口和目的端口被包含在T C P首部的前8个字节中。
I C M P不可达报文的一般格式如图6 - 1 0所示。
图6-10 ICMP不可达报文
在图6 - 3中，我们注意到有1 6种不同类型的I C M P不可达报文，代码分别从0到1 5。I C M P端口
不可达差错代码是3。另外，尽管图6 - 1 0指出了在I C M P报文中的第二个32 bit字必须为0，但是当
代码为4时（“需要分片但设置了不分片比特”），路径M T U发现机制（2 . 9节）却允许路由器把外
第6章ICMP：Internet控制报文协议使用57 下载
IP数据报
ICMP报文
ICMP报文的数据部分
产生差错的数据报IP首部UDP首部
14字节20字节8字节20字节8字节
以太网首部IP首部ICMP首部
类型(3) 代码(0~15) 检验和
未用(必须为0)
IP首部(包括选项)+原始IP数据报中数据的前8字节
8字节
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
出接口的MTU填在这个32 bit字的低16 bit中。我们在11.6节中给出了一个这种差错的例子。
尽管I C M P规则允许系统返回多于8个字节的产生差错的I P数据报中的数据，但是大多
数从伯克利派生出来的系统只返回8个字节。Solaris 2.2的i p i c m p r e t u r n d a t a b y t e s选项默认条件下返回前6 4个字节（E . 4节）。
t c p d u m p时间系列
在本书的后面章节中，我们还要以时间系列的格式给出t c p d u m p命令的输出，如图6 - 11所示。
图6-11 发送到无效端口的TFTP请求的时间系列
时间随着向下而递增，在图左边的时间标记与t c p d u m p命令的输出是相同的（见图6 - 8）。
位于图顶部的标记是通信双方的主机名和端口号。需要指出的是，随着页面向下的y坐标轴与真
正的时间值不是成比例的。当出现一个有意义的时间段时，在本例中是每５秒之间的重发，我
们就在时间系列的两侧作上标记。当U D P或T C P数据正在被传送时，我们用粗线的行来表示。
当I C M P报文返回时，为什么T F T P客户程序还要继续重发请求呢？这是由于网络编程中
的一个因素，即B S D系统不把从插口( s o c k e t )接收到的I C M P报文中的U D P数据通知用户进程，
除非该进程已经发送了一个c o n n e c t命令给该插口。标准的BSD TFTP客户程序并不发送
c o n n e c t命令，因此它永远也不会收到I C M P差错报文的通知。
这里需要注意的另一点是T F T P客户程序所采用的不太好的超时重传算法。它只是假定5
秒是足够的，因此每隔5秒就重传一次，总共需要2 5秒钟的时间。在后面我们将看到T C P有一
个较好的超时重发算法。
58使用TCP/IP详解，卷1：协议
下载
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
T F T P客户程序所采用的超时重传算法已被R F C所禁用。不过，在作者所在子网上
的三个系统以及Solaris 2.2仍然在使用它。AIX 3.2.2采用一种指数退避方法来设置超时
值，分别在0、5、1 5和3 5秒时重发报文，这正是所推荐的方法。我们将在第2 1章更详
细地讨论超时问题。
最后需要指出的是， I C M P报文是在发送U D P数据报3.5 ms后返回的，这与第7章我们所看
到的P i n g应答的往返时间差不多。
6.6 ICMP报文的4.4BSD处理
由于I C M P覆盖的范围很广，从致命差错到信息差错，因此即使在一个给定的系统实现中，
对每个I C M P报文的处理都是不相同的。图6 - 1 2的内容与图6 - 3相同，它显示的是4 . 4 B S D系统
对每个可能的I C M P报文的处理方法。
图6-12 4.4BSD系统对ICMP报文的处理
第6章ICMP：Internet控制报文协议使用59 下载
类型代码描述处理方法
0 0 回显应答用户进程
3 目的不可达：
0 网络不可达“无路由到达主机”
1 主机不可达“无路由到达主机”
2 协议不可达“连接被拒绝”
3 端口不可达“连接被拒绝”
4 需要进行分片但设置了不分片比特D F “报文太长”
5 源站选路失败“无路由到达主机”
6 目的网络不认识“无路由到达主机”
7 目的主机不认识“无路由到达主机”
8 源主机被隔离（作废不用） “无路由到达主机”
9 目的网络被强制禁止“无路由到达主机”
1 0 目的主机被强制禁止“无路由到达主机”
11 由于服务类型TO S，网络不可达“无路由到达主机”
1 2 由于服务类型TO S，主机不可达“无路由到达主机”
1 3 由于过滤，通信被强制禁止（忽略）
1 4 主机越权（忽略）
1 5 优先权中止生效（忽略）
4 0 源站被抑制( q u e n c h ) T C P由内核处理， U D P则忽略
5 重定向
0 对网络重定向内核更新路由表
1 对主机重定向内核更新路由表
2 对服务类型和网络重定向内核更新路由表
3 对服务类型和主机重定向内核更新路由表
8 0 回显请求
9 0 路由器通告用户进程
1 0 0 路由器请求用户进程
11 超时：
0 传输期间生存时间为0 用户进程
1 在数据报组装期间生存时间为0 用户进程
1 2 参数问题：
0 坏的I P首部（包括各种差错） “协议不可用”
1 缺少必需的选项“协议不可用”
1 3 0 时间戳请求内核产生应答
1 4 0 时间戳应答用户进程
1 5 0 信息请求（作废不用） （忽略）
1 6 0 信息应答（作废不用） 用户进程
1 7 0 地址掩码请求内核产生应答
1 8 0 地址掩码应答用户进程
该书下载自-书部落-分享计算机经典巨著！--www.shubulo.com!仅供试看^_^
如果最后一列标明是“内核”，那么I C M P就由内核来处理。如果最后一列指明是“用户
进程”，那么报文就被传送到所有在内核中登记的用户进程，以读取收到的I C M P报文。如果
不存在任何这样的用户进程，那么报文就悄悄地被丢弃（这些用户进程还会收到所有其他类
型的I C M P报文的拷贝，虽然它们应该由内核来处理，当然用户进程只有在内核处理以后才能
收到这些报文）。有一些报文完全被忽略。最后，如果最后一列标明的是引号内的一串字符，
那么它就是对应的U n i x差错。其中一些差错，如T C P对发送端关闭的处理等，我们将在以后
的章节中对它们进行讨论。
6.7 小结
本章对每个系统都必须包括的I n t e r n e t控制报文协议进行了讨论。图6 - 3列出了所有的
I C M P报文类型，其中大多数都将在以后的章节中加以讨论。
我们详细讨论了I C M P地址掩码请求和应答以及时间戳请求和应答。这些是典型的请求—
应答报文。二者在I C M P报文中都有标识符和序列号。发送端应用程序在标识字段内存入一个
唯一的数值，以区别于其他进程的应答。序列号字段使得客户程序可以在应答和请求之间进
行匹配。
我们还讨论了I C M P端口不可达差错，一种常见的I C M P差错。对返回的I C M P差错信息进
行了分析：导致差错的I P数据报的首部及后续8个字节。这个信息对于I C M P差错的接收方来
说是必要的，可以更多地了解导致差错的原因。这是因为T C P和U D P都在它们的首部前8个字
节中存入源端口号和目的端口号。
最后，我们第一次给出了按时间先后的t c p d u m p输出，这种表示方式在本书后面的章节
中会经常用到。