标签：image 了解 因此 utc 包括 原因 solar 包含 mic
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 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数据报首
部中的协议字段来判断）和用户进程（根据包含在 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差错报文对广播分组响应所带来的广播风暴
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所示。
I C M P报文中的标识符和序列号字段由发送端任意选择设定，这些值在应答中将被返回。
这样，发送端就可以把应答与请求进行匹配。
广播的一般特性：发送主机也能通过某种内部环回机制收到一
份广播报文拷贝。由于术语“广播”的定义是指局域网上的所有主机，因此它必须包括发送
主机在内
R F C规定，除非系统是地址掩码的授权代理，否则它不能发送地址掩码应答（为
了成为授权代理，它必须进行特殊配置，以发送这些应答。参见附录 E）但是
大多数主机在收到请求时都发送一个应答，甚至有一些主机还发送差错的应答
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所示
请求端填写发起时间戳，然后发送报文。应答系统收到请求报文时填写接收时间戳，在
发送应答时填写发送时间戳。但是，实际上，大多数的实现把后面两个字段都设成相同的值
（提供三个字段的原因是可以让发送方分别计算发送请求的时间和发送应答的时间）。
由于某种原因， S V R 4在I C M P时间戳中不提供毫秒级的分辨率。这样，对秒以下的时间
差调整将不起任何作用
最后两小节我们来讨论 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章描述）。
在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规则允许系统返回多于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个字节
在本书的后面章节中，我们还要以时间系列的格式给出t c p d u m p命令的输出，如图6 - 11所示。
时间随着向下而递增，在图左边的时间标记与 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有一
个较好的超时重发算法
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应答的往返时间差不多
由于I C M P覆盖的范围很广，从致命差错到信息差错，因此即使在一个给定的系统实现中，
对每个I C M P报文的处理都是不相同的。图 6 - 1 2的内容与图6 - 3相同，它显示的是 4 . 4 B S D系统
对每个可能的I C M P报文的处理方法。
如果最后一列标明是“内核”，那么I C M P就由内核来处理。如果最后一列指明是“用户
进程”，那么报文就被传送到所有在内核中登记的用户进程，以读取收到的 I C M P报文。如果
不存在任何这样的用户进程，那么报文就悄悄地被丢弃（这些用户进程还会收到所有其他类
型的I C M P报文的拷贝，虽然它们应该由内核来处理，当然用户进程只有在内核处理以后才能
收到这些报文）。有一些报文完全被忽略。最后，如果最后一列标明的是引号内的一串字符，
那么它就是对应的 U n i x差错。其中一些差错，如 T C P对发送端关闭的处理等，我们将在以后
的章节中对它们进行讨论。
本章对每个系统都必须包括的 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输出，这种表示方式在本书后面的章节
中会经常用到。
TCP／IP详解，卷1：协议--第6章 ICMP：Internet控制报文协议
标签：image 了解 因此 utc 包括 原因 solar 包含 mic
原文地址：https://www.cnblogs.com/ygjzs/p/12219126.html
