加载中…ICMP报文的格式和种类——学习积累
(2012-11-19 16:33:17)
标签：
icmp报文it |
分类： 网络编程 |
各种报文的前32bits都是三个长度固定的字段：type类型字段(8位)、code代码字段(8位)、checksum校验和字段(16位)
1不能到达信宿（Destination Unreachable）差错报文
2分组过大（Packet Too Big）差错报文
3超时（Time Exceeded）差错报文
4参数问题（Parameter Problem）差错报文
128返回请求（Echo Request）报文
129返回应答（Echo Reply）报文
130组成员查询（Group Membership Query）
131组成员报告（Group Membership Report）
132组成员结束（Group Membership Termination）
133路由器请求（Router Solicitation）
134路由器公告（Router Advertisement）
135邻机请求（Neighbor Solicitation）
136邻机公告（Neighbor Advertisement）
137 重定向（Redirect）
图6-8 由TFTP产生的端口不可达差错
在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行）。在客户程序放弃之前重发了三次。
注意，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。
如果用- e选项运行同样的例子，我们可以看到每个返回的I C M P端口不可达报文的完整长度。这里的长度为7 0字节，各字段分配如图6 - 9所示。图6-9 “UDP端口不可达”例子中返回的报文
I C M P的一个规则是，I C M P差错报文（参见图6 - 3的最后一列）必须包括生成该差错报文的数据报I
P首部（包含任何选项），还必须至少包括跟在该I P首部后面的前8个字节。在我们的例子中，跟在I P首部后面的前8个字节包含U D
P的首部。
一个重要的事实是包含在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首部,可以发现源端口和目的端口被包含在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发现机制却允许路由器把外出接口的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个字节。
我们还要以时间系列的格式给出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有一个较好的超时重发算法。
T F T P客户程序所采用的超时重传算法已被R F C所禁用。不过，在作者所在子网上的三个系统以及Solaris 2.2仍然在使用它。AIX 3.2.2采用一种指数退避方法来设置超时值，分别在0、5、1 5和3 5秒时重发报文，这正是所推荐的方法。
最后需要指出的是，I C M P报文是在发送U D P数据报3.5 ms后返回的，这与第7章我们所看到的P i n g应答的往返时间差不多。
1.
IP数据报首部的固定部分中的各字段
①版本：占4位，指IP协议的版本。通信双方使用的
②首部长度：占 4 位，可表示的最大十进制数值是
15。请注意，
③服务：占 8
位，用来获得更好的服务。
④总长度：总长度指首都及数据之和的长度，单位为字节。
⑤标识 (Identification)：占
16位。
⑥标志 (Flag)：占3
位，但目前只有2位有意义。
⑦片偏移：占
13位。较长的分组在分片后，
⑧生存时间：占
8位，生存时间字段常用的英文缩写是
⑨协议：占 8
位，协议字段指出此数据报携带的数据是使用何种协议，以便使目的主机的IP层知道应将数据部分上交给哪个处理过程。
⑩首部检验和：占
16位。这个字段只检验数据报的首部，
⑾源地址：占32位。
⑿目的地址：占 32位。
2. IP数据报首部的可变部分
IP首都的可变部分就是一个可选字段。选项字段用来支持排错、测量以及安全等措施，内容很丰富。此字段的长度可变，从 1
个字节到40个字节不等，取决于所选择的项目。某些选项只需要 1 个字节，它只包括 1
个字节的选项代码。但还有些选项需要多个字节，这些选项一个个拼接起来，中间不需要有分隔符，最后用全0 的填充字段补齐成为
4字节的整数倍。 增加首都的可变部分是为了增加 IP
数据报的功能，但这同时也使得 IP 数据报的首部长度成为可变的。这就增加了每一个路由器处理数据报的开销。实际上这些选项很少被使用。新的
IPv6就将 IP数据报的首部长度做成固定的。
8bits类型和8bits代码字段：一起决定了报文的类型。常见的有：
类型8、代码0：回射请求。
类型0、代码0：回射应答。
类型11、代码0：超时。
16bits校验和字段：包括数据在内的整个数据包的校验和，其计算方法和IP头部校验和的计算方法是一样的。
类型8、代码0：回射请求。
类型0、代码0：回射应答。
类型11、代码0：超时。
16bits校验和字段：包括数据在内的整个数据包的校验和，其计算方法和IP头部校验和的计算方法是一样的。
下图是一张回射请求和应答报文头部格式
对于回射请求和应答报文来说，接下来是16bits标识符字段：用于标识本进程。
最后是16bits序列号字段：用于判断回射应答数据报。
最后是16bits序列号字段：用于判断回射应答数据报。
报文包含在IP数据报中，属于IP的一个用户，IP头部就在报文的前面
一个报文包括IP头部（20字节）、头部（8字节）和报文
IP头部的Protocol值为1就说明这是一个报文
头部中的类型（Type）域用于说明报文的作用及格式
此外还有代码（Code）域用于详细说明某种报文的类型
所有数据都在头部后面。RFC定义了13种报文格式，具体如下：
类型代码 类型描述
0 响应应答（ECHO-REPLY）
3 不可到达
4 源抑制
5 重定向
8 响应请求（ECHO-REQUEST）
11 超时
12 参数失灵
13 时间戳请求
14 时间戳应答
15 信息请求（*已作废）
16 信息应答（*已作废）
17 地址掩码请求
18 地址掩码应答
其中代码为15、16的信息报文已经作废。
下面是几种常见的报文：
1.响应请求
我们日常使用最多的ping，就是响应请求（Type=8）和应答（Type=0），一台主机向一个节点发送一个Type=8的报文，如果途中没有异常（例如被路由器丢弃、目标不回应或传输失败），则目标返回Type=0的报文，说明这台主机存在，更详细的tracert通过计算报文通过的节点来确定主机与目标之间的网络距离。
2.目标不可到达、源抑制和超时报文
这三种报文的格式是一样的，目标不可到达报文（Type=3）在路由器或主机不能传递数据报时使用，例如我们要连接对方一个不存在的系统端口（端口号小于1024）时，将返回Type=3、Code=3的报文，它要告诉我们：“嘿，别连接了，我不在家的！”，常见的不可到达类型还有网络不可到达（Code=0）、主机不可到达（Code=1）、协议不可到达（Code=2）等。源抑制则充当一个控制流量的角色，它通知主机减少数据报流量，由于没有恢复传输的报文，所以只要停止该报文，主机就会逐渐恢复传输速率。最后，无连接方式网络的问题就是数据报会丢失，或者长时间在网络游荡而找不到目标，或者拥塞导致主机在规定时间内无法重组数据报分段，这时就要触发超时报文的产生。超时报文的代码域有两种取值：Code=0表示传输超时，Code=1表示重组分段超时。
3.时间戳
时间戳请求报文（Type=13）和时间戳应答报文（Type=14）用于测试两台主机之间数据报来回一次的传输时间。传输时，主机填充原始时间戳，接收方收到请求后填充接收时间戳后以Type=14的报文格式返回，发送方计算这个时间差。一些系统不响应这种报文。
--------------------------------种类-------------------------------------
报文格式
虽然是网络层的协议，但要将报文放入IP中发送。
虽然是网络层的协议，但要将报文放入IP中发送。
报文的公共头标由1字节的类型（type）、1字节的
代码（code）和2字节的校验和（checksum）组成。
类型域和代码域用来标识各种报文。类型域表示报文的类型，目前已定义了14
种，从类型值来看报文可分为二大类。
代码（code）和2字节的校验和（checksum）组成。
类型域和代码域用来标识各种报文。类型域表示报文的类型，目前已定义了14
种，从类型值来看报文可分为二大类。
第1 类是取值为1~127的差错报文，
第2类是取值128以上的是信息（informational）报文。
1不能到达信宿（Destination Unreachable）差错报文
2分组过大（Packet Too Big）差错报文
3超时（Time Exceeded）差错报文
4参数问题（Parameter Problem）差错报文
128返回请求（Echo Request）报文
129返回应答（Echo Reply）报文
130组成员查询（Group Membership Query）
131组成员报告（Group Membership Report）
132组成员结束（Group Membership Termination）
133路由器请求（Router Solicitation）
134路由器公告（Router Advertisement）
135邻机请求（Neighbor Solicitation）
136邻机公告（Neighbor Advertisement）
137 重定向（Redirect）
端口不可达差错
http://www.cnpaf.net/Class/TCPANDIP/200408/292.html
查询报文—地址掩码和时间戳查询及应答。现在来分析一种差错报文，即端口不可达报文，它是目的不可到达报文中的一种，以此来看一看差错报文中所附加的信息。使用UDP来查看它。
查询报文—地址掩码和时间戳查询及应答。现在来分析一种差错报文，即端口不可达报文，它是目的不可到达报文中的一种，以此来看一看差错报文中所附加的信息。使用UDP来查看它。
UDP的规则之一是，如果收到一份UDP数据报而目的端口与某个正在使用的进程不相符，那么UDP返回一个不可达报文。可以用TFTP来强制生成一个端口不可达报文。
对于TFTP服务器来说，UDP的公共端口号是69。但是大多数的TFTP客户程序允许用connect命令来指定一个不同的端口号。这里，我们就用它来指定08端口：
http://www.cnpaf.net/article/Files/RoUpimages/1813019342.jpg
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所示。
http://www.cnpaf.net/article/Files/RoUpimages/1813156682.jpg
一个I C M P端口不可达差错是立刻返回的（第4行）。但是，T F T P客户程序看上去似乎忽略了这个I C M P报文，而在5秒钟之后又发送了另一份U D P数据报（第5行）。在客户程序放弃之前重发了三次。
注意，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。
如果用- e选项运行同样的例子，我们可以看到每个返回的I C M P端口不可达报文的完整长度。这里的长度为7 0字节，各字段分配如图6 - 9所示。
http://www.cnpaf.net/article/Files/RoUpimages/1813349520.jpg
一个重要的事实是包含在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首部,可以发现源端口和目的端口被包含在T C P首部的前8个字节中。I C M P不可达报文的一般格式如图6 - 1 0所示。
http://www.cnpaf.net/article/Files/RoUpimages/1813554943.jpg
我们还要以时间系列的格式给出t c p d u m p命令的输出，如图6 - 11 所示。
http://www.cnpaf.net/article/Files/RoUpimages/1813814801.jpg
当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秒时重发报文，这正是所推荐的方法。
最后需要指出的是，I C M P报文是在发送U D P数据报3.5 ms后返回的，这与第7章我们所看到的P i n g应答的往返时间差不多。
附加：
IP数据包格式详解
TCP/IP协议定义了一个在因特网上传输的包，< xmlnamespace prefix
="o" ns ="urn:schemas-microsoft-com:office:office"
/>
称为IP数据报 (IP Datagram)。这是一个与硬件无关的虚拟包，
由首部和数据两部分组成。首部的前一部分是固定长度，共 20 字节，
是所有IP数据报必须具有的。在首部的固定部分的后面是一些可选字段，
其长度是可变的。首都中的源地址和目的地址都是 IP 协议地址。
那么IP数据报格式又是怎样要求的呢？
IP协议版本必须一致。日前广泛使用的 IP协议版本号为 4 (即 IPv4)。
IPv6 目前还处于起步阶段。
这个字段所表示数的单位是32位字 ( 1 个32位字长是4 字节)，
因此，当 IP 的首部长度为 1111 时 (即十进制的 15)，
首部长度就达到 60字节。当 IP 分组的首部长度不是4字节的整数倍时，
必须利用最后的填充字段加以填充。
因此数据部分永远在 4字节的整数倍开始，
这样在实现 IP协议时较为方便。
首部长度限制为 60字节的缺点是有时可能不够用。
这样做的目的是希望用户尽量减少开销。
最常用的首部长度就是 20 字节 (即首部长度为 0101)，
这时不使用任何选项。
这个字段在旧标准中叫做服务类型，但实际上一直没有被使用过。
1998年IETF把这个字段改名为区分服务 DS (DifferentiatedServices)。
只有在使用区分服务时，这个字段才起作用。
因为总长度字段为 16位，所以数据报的最大长度为 216-1=65 535字节。
在IP层下面的每一种数据链路层都有自己的帧格式，其中包括帧格式中的数据字段的最大长度，即最大传送单元
MTU (Maximum Transfer Unit)。当一个数据报封装成链路层的帧时，此数据报的总长度
(即首部加上数据部分)一定不能超过下面的数据链路层的MTU值。
IP软件在存储器中维持一个计数器，每产生一个数据报，
计数器就加 1，并将此值赋给标识字段。但这个“标识”并不是序号，
因为 IP是无连接的服务，数据报不存在按序接收的问题。
当数据报由于长度超过网络的 MTU 而必须分片时，
这个标识字段的值就被复制到所有的数据报的标识字段中。
相同的标识字段的值使分片后的各数据报片最后能正确地重装成为
原来的数据报。
标志字段中的最低位记为 MF (More Fragment)。
MF=1即表示后面“还有分片”的数据报。MF=0表示这已是若干数据报片
中的最后一个。
标志字段中间的一位记为 DF(Don't Fragment)，
意思是“不能分片”。只有当 DF=0时才允许分片。
某片在原分组中的相对位置。也就是说，相对用户数据字段的起点，
该片从何处开始。片偏移以 8个字节为偏移单位。
这就是说，每个分片的长度一定是 8字节 (64位)的整数倍。
TTL (Time To Live)，其表明数据报在网络中的寿命。
由发出数据报的源点设置这个字段。
其目的是防止无法交付的数据报无限制地在因特网中兜围子，
因而白白消耗网络资源。最初的设计是以秒作为 TTL的单位。
每经过一个路由器时，就把TTL减去数据报在路由器消耗掉的一段时间。
若数据报在路由器消耗的时间小于 1 秒，就把TTL值减 1。
当 TTL值为 0时，就丢弃这个数据报。
但不包括数据部分。这是因为数据报每经过一个路由器，都要重新计算一下首都检验和
(一些字段，如生存时间、标志、片偏移等都可能发生变化)。不检验数据部分可减少计算的工作量。
IP数据包指的是第三层的PDU，
IP首部只是其中的一部分，是在第三层网络层上加上去的，是给路由器看的。
IP数据包的总长度过大，超过链路的最大MTU时，数据包就会被分成多片，
而在如今的IPv4的网络中，数据传输时不可靠的，是尽力而为的，
所以这些分片的数据单元到达对端的链路和时间都是不同的，
对端根据IP首部中的标示符（Identification）、标志（Flag）、段偏置值字段
重组数据包。
下面是TCP报文的格式。
UDP报文比较简单。只有源端口、目的端口、长度、校验和四个字段。后面就是数据了
喜欢
0
赠金笔
前一篇：吉他——初涉布鲁斯
后一篇：Winsock服务初始化