DNS报文格式

DNS报文格式（借个图贴过来）：

说明一下：并不是所有DNS报文都有以上各个部分的。图中标示的“12字节”为DNS首部，这部分肯定都会有，首部下面的是正文部分，其中查询问题部分也都会有。除此之外，回答、授权和额外信息部分是只出现在DNS应答报文中的，而这三部分又都采用资源记录（Recource Record）的相同格式，这个稍后会提到。下面逐个字段地分析DNS报文。

标识（2字节）：这个字段网上的解释有点不清楚：“由客户程序设置并由服务器返回结果。”看了下实验室的程序和文档，原来这个字段可以看作是DNS报文的ID，对于相关联的请求报文和应答报文，这个字段是相同的，由此可以区分DNS应答报文是哪个请求报文的响应。

标志（2字节）：这部分非常重要，需要逐比特分析。再借个图：

QR(1比特）：查询/响应的标志位，1为响应，0为查询。

opcode（4比特）：定义查询或响应的类型（若为0则表示是标准的，若为1则是反向的，若为2则是服务器状态请求）。

AA（1比特）：授权回答的标志位。该位在响应报文中有效，1表示名字服务器是权限服务器（关于权限服务器以后再讨论） TC（1比特）：截断标志位。1表示响应已超过512字节并已被截断（依稀好像记得哪里提过这个截断和UDP有关，先记着）

RD（1比特）：该位为1表示客户端希望得到递归回答（递归以后再讨论）

RA（1比特）：只能在响应报文中置为1，表示可以得到递归响应。

zero（3比特）：不说也知道都是0了，保留字段。

rcode（4比特）：返回码，表示响应的差错状态，通常为0和3，各取值含义如下：

0 无差错

1 格式差错

2 问题在域名服务器上

3 域参照问题

4 查询类型不支持

5 在管理上被禁止

报文类型：MFT001

数据结构标志:

数据结构标志 数据结构说明 备注

舱单表头信息 共22位

提单信息 共22位

集装箱信息 共22位

发送方代码(18位)：

间接发送方 直接发送方 备注

COMPANY_ID EPORT 铁道部发送时为：T01+0+铁路站编码（3位字母）

接受方代码(18位)：

直接目的地 最终目的地 备注

CUSTOMS CUSTOMS_CODE 发送给直属海关时为：CUS+关区编号（4位）

1.1.1.舱单报文结构

进出口舱单数据结构相同

(MANIFEST_HEAD)

序号 字段中文名称 字段代码名称 类型 说明 是否必填

1 进出口舱单标志 I_E_FLAG X(1) “I”进口舱单

“E”出口舱单

“P”出口预配舱单 是

2 车厢编号 SHIP_ID X(32) H883为X(26) 是

3 航次编号 VOYAGE_NO X(32) YYYYMMDD 是

4 主管地海关 CUSTOMS_CODE 9(4) 海关代码，前后的“0”要补齐，以下涉及海关编码的依此规则 是

5 运输方式 TRAF_MODE X(1) 空运：“5”；海运：“2”；铁路：“3”；邮运：“6” 是

6 舱单编号 MANIFEST_NO 9(18) 电子口岸数据库统一编号，

现H883中不能存储

7 中文运输工具名称 SHIP_NAME_CN X(50) H883为X(26)

8 交接单号 SHIP_NAME_EN X(50) H883为X(26) 是 9 集装箱总数 CONTA_NUM 9(14).9(5) H883为9(4)

无集装箱填“0”，小数点位固定，前后补“0”。下同 是

10 空箱总数 EMPTY_CONTA_NUM 9(14).9(5) H883为9(4) 是

11 总重量 T_GROSS_WT 9(14).9(5) H883为9(7)V99 是

12 总件数 T_PACK_NO 9(14).9(5) H883为9(9) 是

ICMP报文格式

ICMP 协议基本格式 2011-05-17 11:01 ICMP 是IP 层的一个组成部分，它传递查询报文和差错报文，ICMP 报文通常 被IP 层或更高层协议（TCP 或UDP）使用，它是在IP 数据包内被传输的，如图 1 所示。 图1：ICMP 封装在IP 数据包内部 ICMP 报文格式 如图2 所示，所有报文的前4 个字节都是一样的，但是剩下的其他字节则互 不相同。 图2：ICMP 报文格式 类型字段可以有15 个不同的值，以描述特定类型的ICMP 报文。某些ICMP 报文还使用代 码字段的值来进一步描述不同的条件。 检验和字段覆盖整个ICMP 报文。使用的算法与前面介绍的IP 首部检验和算 法相同。ICMP 的检验和是必需的。 ICMP 报文的类型 各种类型的ICMP 报文如3 所示，不同类型由报文中的类型字段和代码字段 来共同决定。 图中的最后两列表明ICMP 报文是一份查询报文还是一份差错报文。因为对 ICMP 差错报 文有时需要作特殊处理，因此我们需要对它们进行区分。例如，在对ICMP 差错 报文进行响应 时，永远不会生成另一份ICMP 差错报文（如果没有这个限制规则，可能会遇到 一个差错产生 另一个差错的情况，而差错再产生差错，这样会无休止地循环下去）。 图3：ICMP 报文类型 ICMP 地址掩码请求与应答 ICMP 地址掩码请求用于无盘系统在引导过程中获取自己的子网掩码。系统广 播它的ICMP 请求报文（这一过程与无盘系统在引导过程中用RARP 获取IP 地址 是类似的）。无盘 系统获取子网掩码的另一个方法是BOOTP 协议。ICMP 地址掩码请求和应答报文 的格式如图4 所示。 图4：ICMP 地址掩码请求与应答报文 ICMP 报文中的标识符和序列号字段由发送端任意选择设定，这些值在应答中 将被返回。这样，发送端就可以把应答与请求进行匹配。 ICMP 时间戳请求与应答 ICMP 时间戳请求允许系统向另一个系统查询当前的时间。返回的建议值是自 午夜开始计 算的毫秒数，协调的统一时间（Coordinated Universal Time, UTC）。 ICMP 时间戳请求和应答报文格式如图5 所示。 图5：ICMP 时间戳请求和应答报文 请求端填写发起时间戳，然后发送报文。应答系统收到请求报文时填写接收 时间戳，在发送应答时填写发送时间戳。但是，实际上，大多数的实现把后面两 个字段都设成相同的值。 ICMP 端口不可达差错 上面介绍了ICMP 两种查询报文—地址掩码和时间戳查询及应答。现在来分 析一种ICMP 差错报文，即端口不可达报文，它是ICMP 目的不可到达报文中的一 种，以此来看一看ICMP 差错报文中所附加的信息。 我们使用采用UDP 协议的TFTP 服务（默认端口号69），在客户端使用TFTP 客户程序connect 服务端的非69 端口，这样就会发生端口不可达错误。完整的 差错报文如图6 所示： 图6：“UDP 端口不可达”返回的ICMP 报文 ICMP 的一个规则是， ICMP 差错报文必须包括生成该差错报文的数据报IP 首部（包含任何选项），还必须 至少包括跟在该IP 首部后面的前8 个字节（包含源端口和目的端口）。在我们的例子中，跟在IP 首部后 面的前8 个字节包含UDP 的首部

DHCP报文

DHCP报文是承载于UDP上的高层协议报文，采用67（DHCP服务器）和68（DHCP客户端）两个端口号。DHCP报文的格式如下图所示。

图1 DHCP报文格式

< 所有DHCP提供的配置信息都在options字段中，这才是精华部分 >

报文中各字段的描述如下：

 op，报文类型，1表示请求报文，2表示回应报文。

 htype，硬件地址类型，1表示10Mb/s的以太网的硬件地址。

 hlen，硬件地址长度，以太网中该值为6。

 hops，跳数。客户端设置为0，也能被一个代理服务器设置。

 xid，事务ID，由客户端选择的一个随机数，被服务器和客户端用来在它们之间交流请求和响应，客户端用它对请求和应答进行匹配。该ID由客户端设置并由服务器返回，为32位整数。

 secs，由客户端填充，表示从客户端开始获得IP地址或IP地址续借后所使用了的秒数。

 flags，标志字段。这个16比特的字段，目前只有最左边的一个比特有用，该位为0，表示单播，为1表示广播。

 ciaddr，客户端的IP地址。只有客户端是Bound、Renew、Rebinding状态，并且能响应ARP请求时，才能被填充。

 yiaddr，"你自己的"或客户端的IP地址。  siaddr，表明DHCP协议流程的下一个阶段要使用的服务器的IP地址。

 giaddr，DHCP中继器的IP地址。//注意：不是地址池中定义的网关

 chaddr，客户端硬件地址。客户端必须设置它的"chaddr"字段。UDP数据包中的以太网帧首部也有该字段，但通常通过查看UDP数据包来确定以太网帧首部中的该字段获取该值比较困难或者说不可能，而在UDP协议承载的DHCP报文中设置该字段，用户进程就可以很容易地获取该值。

 sname，可选的服务器主机名，该字段是空结尾的字符串，由服务器填写。

 file，启动文件名，是一个空结尾的字符串。DHCP Discover报文中是"generic"名字或空字符，DHCP Offer报文中提供有效的目录路径全名。