全面掌握报文协议

全面掌握ISO8583报文协议

我刚进入金融行业时，就知道了IS08583报文协议，我想可能我还没进入这个行业都已经听过了，可知ISO8583的影响力有多大了。最初刚接触它时，确实对其中的一些细节概念不是很清晰，对有些地方比较迷惑。鉴于此，我想很多同行也必然会经历同样得阶段，所以我写下本文，以便大家能够少走一些弯路。同时，我在网上写下我要写“全面掌握ISO8583报文”和“符合CEN/XFS（即WOSA/XFS）规范的SP编写”两篇文章时，很多人都询问我什么时候能够写出来，可知许多人是需要了解这方面的知识的，即使我时间不是很多，也得尽量将这两篇文章写出来，给需要的人提供一些参考。

如果单纯的讲IS08583那些字段的定义，我觉得没有什么意思，标准中已经对每个字段解释的非常详细了，如果你觉得理解英文版的ISO8583规范有些困难，网上也有同行为我们翻

译好的中文版ISO8583规范，所以我的目的是达到阅读本文后能够对ISO8583知其然，亦知其所以然，使以前基本没有接触它的人也能够达到掌握ISO8583报文规范。

好了，我们该转入正题了。

最开始时，金融系统只有IBM这些大的公司来提供设备，象各种主机与终端等。在各个计算机设备之间，需要交换数据。我们知道数据是通过网络来传送的，而在网络上传送的数据都是基于0或1这样的二进制数据，如果没有对数据进行编码，则这些数据没有人能够理解，属于没有用的数据。起初的X.25、SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议，它们解决了最底层的通讯问题，能够将一串字符从一个地方传送到另一个地方。但是，仅仅传送字符串是没有太大意义的，怎样来解析字符串代表什么内容是非常重要的，否则传送一些“0123abcd”的字符串也是无用的乱码。

让我们随着时光回到几十年前的某个时刻，

假设我们被推到历史的舞台上，由我们来设计一个通用报文协议，来解决金融系统之间的报文交换，暂且称该协议叫做ISO8583协议。此时，技术是在不断的前行，当初IBM一支独秀的局面好像已经不妙了，各种大小不一的公司都进入金融行业以求能有所斩获，呈一片百花齐放的局面。我们怎样来设计一个报文协议，能够将这些如雨后春笋般出现的所有公司都纳入进来，其实也不是一件很简单的事。

我们还是先一步步的来考虑吧。金融行业其实涉及到的数据内容并不是成千上万，无法统计，恰恰相反，是比较少的。我们都可以在心底数得过来，象交易类型、帐号、帐户类型、密码、交易金额、交易手续费、日期时间、商户代码、2磁3磁数据、交易序列号等，把所有能够总结出来的都总结起来不过100个左右的数据。那我们可以首先简单的设计ISO8583，定义128个字段，将所有能够考虑到的类似上面提到的“帐号”等金融数据类型，按照一个顺序排起来，分别对应128个字段中的一个字段。每个数据类型占固定的长度，这个顺序和长度我们都事先定义好。

这样就简单了，要发送一个报文时，就将128个字段按照顺序接起来，然后将接起来的整串数据包发送出去。

任何金融软件收到ISO8583包后，直接按照我们定义的规范解包即可，因为整个报文的128个字段从哪一位到哪一位代表什么，大家都知道，只要知道你的数据包是ISO8583包即可，我们都已经定义好了。比如第1个字段是“交易类型”，长度为4位，第2个字段位是“帐号”，为19位等等。接收方就可以先取4位，再取接着的19位，依次类推，直到整个数据包128个字段都解完为止。

其实这种做法真是简单直接，基本上就可以满足需要了。不过我们有几个问题要思考下：1、我怎么知道每个字段的数据类型呢，是数字还是字符？

2、每个传送的报文都把128个字段都传过去，那网络带宽能够承受得了，有时候我可能只需要其中5个字段，结果多收到了123个无用的字段。

3、如果我某些字段的长度不固定，属于变长怎

么办，因为你现在解包是当作数据包每个字段都是固定的，用C语言解包时直接依靠指针取固定长度的一串字符做为一个字段。

我们来一一解决这些问题。

第一个问题简单，我在定义ISO8583时除了定义每个字段表示什么，还规定其内容是数字或是字符等即可。考虑可能出现的类型不过有以下几种：字母、数字、特殊字符、年月日等时间、二进制数据。比如我对128个字段中的“商户类型”字段定义其长度是15，同时定义其类型为字母。再精细点，如果“商户类型”里面的数据同时包括数字和字母呢？那我们就定义其类型为字母也可，为数字也可，即一个字段可以同时属于多个类型。

第二个问题稍微复杂点。其本质就是如果我只传128个字段的5个字段，接收方怎么知道我传了哪几个字段给它了。要是我们把剩下的123全部填成0或其他特殊标识，标明该字段不需要使用？这种处理方法没有半点用处，没有解决网

络带宽的本质问题，还是要传128个字段。

2 4 16

2 8 256

换个思路，我在报文前面加上个包头，包头里面包含的信息能够让别人知道只传了5个字段。怎样设计这个包头，可以这样，我们用16个字节，即128个bit（一个字节等于8bit）来表示128个字段中的某个字段是否存在。每个bit在计算机的二进制里面不是1就是0，如果是1就表示对应的字段在本次报文中存在，如果是0就是不存在。这样好了，如果别人接收到了ISO8583报文，可以先根据最前面的报文头，就知道紧接着报文头后面的报文有哪些字段，没有哪些字段了。比如，我要发送5个字段，分别属于128个字段中的第2、3、6、8、9字段，我就可以将128bit的报文头填成011001011000000000………..，一共128个bit，后面就全是0了。注意其中第2、3、6、8、9位为1，其他都为0。

有了这个128bit的报文头，我们就可以只发送需要的5个字段了。怎样组织报文？先放上这

128bit，即2个字节的头，然后在头后面放2、3、6、8、9字段，这些字段紧挨在一起，3和6之间也不需要填上4、5这两个字段了。接收方收到这个报文，它会根据128bit的报文头来解包，它自然知道把第3个字段取出后，就直接在第3字段的后面取第6个字段，每个字段的长度在ISO8583里面都定义好了，很轻松就把数据包解出来了。

这下好了，为了解决上面的第二问题，我们只是在报文中增加了2个字节的数据，就轻松搞定了，我们把这2个字节称为bit map，即位图，用来表示某个位是否存在。不过我们再稍微优化一下，考虑到很多时候报文不需要128个字段这么多，其一半64个字段都不一定能够用完。那我可以将报文头由128bit减到64bit，只有在需要的时候才把剩下的64bit放到报文里面，这样报文长度不又少了1个字节吗？

是个好主意。我们把ISO8583的128个字段中最常见的都放到前64个字段中，那我们可以将处理缩小一倍。这样我一般发送报文时只需发

送64bit，即一个字节的报文头，再加上需要的几个字段就可以了。如果有些报文用到64到128之间的字段呢？这个也好办，我把64bit报文头的第一位bit用来代表特殊含义，如果该bit为1，则表示64bit后面跟了剩下的64bit报文头；如果第一位bit为0，则表示64bit后面没有跟剩下的64bit报文头，直接是128个字段中的报文了。那们，接收方会判断一下报头的第一个bit是1还是0，从而知道报文头是64bit还是128bit了，就可以做相应处理。因为报文头第二个64bit属于有时候有，所以我们叫它Extended bit map 扩展位图，相应的报文头最开始的64bit我们叫它Primary bit map主位图。我们直接把扩展位图固定放到128个字段的第一个字段，而主位图每个数据包都有，就强制性放在所有128个字段的前面，并不归入128个字段中去。

第三个问题可以考虑这样解决。比如第2个字段是“帐号”，是不定长的，可能有的银行帐号是19位，有的是17位等。我们定ISO8583规范时可以规定第2个字段是25位，这下足够将19和17的情况都包含进来，但是如果以后出现

了30位的怎么办？那我们现在将字段定为100位。以后超过100位怎么办，况且如果你只有19位的帐号，我们定义了100位，那81位的数据不是浪费了网络的带宽。看来预先定义一个我们认为比较大的位数是不太好的。

我们这样，对于第2个字段“帐号”，在字段的开头加上“帐号”的长度。比如帐号是0123456789，一共10位，我们变成100123456789，注意前面多了个10，表示后面的10位为帐号。如果你接触过COM里面的BSTR，应该对这种处理比较熟悉了。接收方收到该字段后，它知道ISO8583规定第2个字段“帐号”是变长的，所以会先取前面的2位出来，获取其值，此时为长度，然后根据该长度值知道应该拷贝该字段后面哪几位数据，才是真正的帐号。如果你觉得长度如果只有两位最多只能表示99位长，不太够，我们也定义可以允许前面3位都为长度的变长字段，这样就有999位长，应该够了吧。在规范里面如果我定义某个字段的属性是“LLV AR”，你注意了，其中的LL表示长度，V AR表示后面的数据，两个LL表示两位长，最

大是99，如果是三位就是“LLLV AR”，最大是999。这样看我们定义的ISO8583规范文档时直接根据这几个字母就理解某个变长字段的意思了。

该解决的几个问题到这里都解决了，我们来回顾下自己设计的ISO8583规范。其实没有什么，无非是把金融行业可能出现的数据分门别类，排好顺序，接着把它们连接起来，组成一个报文发送出去而已。其中针对该报文的设计进行了一些优化，引入了bit map位图的概念，也算是一个不错的想法。

剩下的工作就简单了，我们就直接收集金融行业可能出现的数据字段类型，分成128个字段类型，如果没有到128个这么多就先保留一些下来，另外考虑到有些人有特殊的要求，我们规定可以将128个字段中的几个字段你自己来定义其内容，也算是一种扩展了。

这样，最后我们就得到了ISO8583规范的那张字段描述表了。想要详细的知道每个字段的含

义直接对着表看就可以，比较简单。

全文完

8583协议

?编辑词条

摘要

ISO8583包（简称8583包）是一个国际标准的包格式，最多由128个字段域组成，每个域都有统一的规定，并有定长与变长之分。8583包前面一段为位图，用来确定包的字段域组成情况。

其中位图是8583包的灵魂，它是打包解包确定字段域的关键，而了解每个字段域的属性则是填写数据的基础，

1、位图描述如下：

位图位置：1

格式：定长

类型：B16（二进制16位，16*8=128bit）

描述：

如将位图的第一位设为'1'，表示使用扩展位图（128个域），否则表示只使用基本位图（64个域）。

如使用某数据域，应在位图中将相应的位设位'1'，如使用41域，需将位图的41位设为'1'。

选用条件：如使用65到128域，需设位图域第一位为'1'

2、变长，定长域说明

如第二域：域名为主帐号，

数据类型为string

长度为22（是长长度不得超过此数）

是个２位变长域

由于是２位变长，在打包时需在数据域前加上数据的实际长度，如为１９位，

则表示为：

１９＋数据值（即前两位为长度）

如第三域：域名为处理码，

数据类型为string

长度为６

是个定长域

必须填满６位。

附A:ISO8583各域段的说明

1，信息类型（message type)定义

位图位置：－

格式：定长

类型：N4

描述：

数据包的第一部分，定义数据包的类型。

数据类型由数据包的发起者设定，应遵循以下要求：

数据包开始部分必须是信息类型；

对不支持的信息类型能给出拒绝应答。

0100授权交易

0110授权交易答复

0200金融交易

0210金融交易答复

0240查询交易

0250查询交易答复

0400冲正交易

0410冲正交易答复

0800管理交易

0810管理交易答复

2，位图(Bit Map) - 基本位图和扩展位图

位图位置：1

格式：定长

类型：B16

描述：

如将位图的第一位设为'1'，表示使用扩展位图，否则表示只使用基本位图。如使用某数据域，应在位图中将相应的位设位'1'，如使用41域，需将位图的41位设为'1'。

选用条件：如使用65到128域，需设位图域为'1'

3，Bit02主帐号(Primary Account Number )

位图位置：02

格式：变长,LLVAR

类型：N..22

唯一的确认一个用户交易的基本帐号。

由于银行电子服务系统涉及多个应用系统，而帐号长度最多为22位，故将原标准的19长度改为22位。

4, Bit03 处理代码（Processing Code )

位图位置：03

格式：定长

类型：N6

描述：用于描述交易对客户帐户造成何种影响的代码。

处理代码和信息码一起可唯一定义一种交易的类型。

处理代码由以下三部分组成：

位置描述

1－2交易动作码

3－4付出帐户类型，用于借记类，如查询、代收费、转场交易。

5－6收入帐户类型，用于代收费、转帐等。

其中：

ff : 付出帐户

tt：收入帐户

* 视主机而定

5，Bit04 交易金额（Amount, Transaction)

位图位置：04

格式：定长

类型：N12

描述：帐户人要求交易的交易金额，不含任何处理和交易费用。

金额的表示和货币代码有关，应能表示相应货币的最小单位。参ISO4217有关货币代码定义。

如“000000000100”用于表示美元，表示1.00元；如用于表示意大利货币，则表示100里拉。

对于查询等交易，应设交易金额为“000000000000”。

6，Bit07交易日期和时间Transmission Date and Time

位图位置：07

格式：定长，MMDDhhmmss

类型：N10

描述：本地交易日期和时间

7，Bit11系统跟踪号（System s Trace Audit Number)

位图位置：11

格式：定长

描述：终端交易的跟踪号码。

交易发起终端填写，和“交易日期、时间”、信息类型等合在一起可唯一定义某一个终端的唯一一笔交易。即是说，在同一天，对一终端，同一类交易的系统跟踪号应保证不同。系统跟踪号在交易过程中不能修改。使用此域来匹配请求和通知类交易的返回。

应用系统使用此域来检查收到的授权、金融、自动冲正、结算、管理和网管等类交易的应答包是否是其请求包的应答。

系统跟踪号不用于匹配自动冲正交易，也不用于在预授权消费时匹配前面的预授权交易。参90域。

对于银行电子服务系统，其系统跟踪号是交易流水号。

8，Bit12本地交易时间（Time ,Local Transaction）

位图位置：12

格式：定长，hhmmss

类型：N6

描述：交易在终端上发生的时间。

本地交易时间在交易处理过程中不能改变。在自动冲正，存贮转发时，本地交易时间不能改变。

9，Bit13本地交易日期(Date ,Local Transaction)

位图位置：13

格式：定长,MMDD

类型：N4

描述：交易在终端上发生的时间。

本地交易时间不能改变，在自动冲正、存储转发交易时，本地交易时间也不能改变。

10，Bit14有效期(Date ,Expiration)

位图位置：14

格式：定长,YYMM

类型：N4

描述：卡的有效期，年年月月

由于卡类写磁格式不同，收单行可能提不出卡的有效期，授权机构从卡的二磁道中提取卡的有效期。如卡，无二磁道，收单行应要求手工录入卡的有效期。选用条件：100、200、400等交易如没有2、3磁道时，一定要有此域。

11，Bit15结算日期(Date ,Settlement)

位图位置：15

格式：定长，MMDD

类型：N4

描述：

银行电子服务系统和主机结算的时间，格式月月日日。

结帐日期前发生的交易参加当天结算。

在结算时，结帐日期也用于计算处理、交易费用。

12，Bit17获取日期(Date ,Capture)

位图位置：17

格式：定长，MMDD

类型：N4

描述：从主机获取交易的记帐日期。通常用于主机和商户清算。

13，Bit18商户类型（Merchant's Type)

位图位置：18

格式：定长

类型：N4

描述：定义商户产品和服务类型的代码

商户类型用于金融、授权交易，用于指定服务点的类型。它主要有以下用途：决定预授权交易得到确认的最长时间；

控制合法限额；

为交易授权处理，控制网络操作规则；

欺诈检测；

用于商户分类报表；

交易费用处理。

根据ISO8583标准，应使用相应的国家标准。

商户类型代码表如下：

商户类型代码行业类型说明

4215邮递服务

4511民航

4722旅游

4782过桥费

4789其他运输服务

4614电信服务

5542加油站

5812餐馆

5999购物

6010金融机构－人工现金支付

6011金融机构－自动现金支付

6012金融机构－各类服务

7011酒店、旅馆

7299各类个人服务：洗衣、美容、

7399各类商业服务：停车场、租车、广告、其他服务

7699各类维修服务：维修、洗车、拖车

7996娱乐：电影、剧院、体育、游戏

8099医疗服务

8111法律服务

8999各类专业服务：会计、教育、装修、工程

选用条件：服务点终端发起的交易一定要有此域。

14，Bit22服务点输入方式(Point-of-Service Entry Mode)

位图位置：22

格式：定长

类型：N3

描述：在服务终端上定义PIN和PAN的输入方式。

服务点输入方式包含以下两个方面组合而成：

位置描述

1－2在服务终端上PAN有效期输入方式

3－3在服务终端上PIN的输入方式

PAN的输入方式编码如下：

PAN输入方式描述

00不知

01手工

02读磁卡

03条码扫描仪（BAR）

04光学符号阅读器（OCR）

05集成电路卡（IC卡）

PIN的输入方式编码如下：

PIN输入方式描述

0不知

1终端能接收PIN

2终端不能接收PIN

选用条件：服务点终端发起的交易一定要有此域。

15，Bit25服务点条件代码(Point-of-Service Condition Code)

位图位置：25

格式：定长

类型：N2

描述：定义交易发生的服务点类型

用法说明：下面是CYBERBANK支持的服务点条件代码。

服务点条件代码服务点终端类型

2自动柜员机（ATM）

10银行终端（10）

14POS

20电话银行

16，Bit32收单机构标识码(Acquirer institution Identification) 位图位置：32

格式：LLVAR

类型：N..11

描述：在金融交易中此域表示交易发生的银行机构的标识码

应答数据包必须和请求数据包此域相同。

17，Bit33向前机构标识码(Forwarding Institution Identification Code) 位图位置：33

格式：LLVAR

类型：N..11

描述：在金融交易中此域表示帐户所在的银行机构的标识码

在网管交易800/810中，本域含有交易发起机构的代码。

应答数据包必须和请求数据包此域相同。

18，Bit35二磁道数据(Track 2 Data)

位图位置：35

格式：LLVAR

类型：Z..37

描述：写在卡二磁道的数据。数据组成遵循ISO7811－1985标准，数据中包含域分隔符，但不包含卡启始、结束符、LRC等。

收卡行应检测卡的二磁道是否符合国际标准。

为支持国际交换收单行应将二磁道中的分隔符换为“＝”。除此外不能对二磁道数据进行任何修改，如修改PAN的校验字、有效期、服务码等。

19，Bit36三磁道数据(Track 3 Data)

位图位置：36

格式：LLLVAR

类型：Z (104)

描述：写在卡三磁道的数据。数据应组成遵循ISO4909标准，数据中包含域分隔符，但不包含卡启始、结束符、LRC等。

注意：长度说明为3位数字长。

20，Bit37检索索引号(Retrieval Reference Number)

位图位置：37

格式：定长

类型：AN12

描述：检索索引号用来在任何时间标识一个金融、授权、自动冲正交易。

检索索引号不要求打印在持卡人的帐单上。它的主要目的是在收单行和授权行之间定义一个数据项用于跟踪和检索交易。授权机构可以将检索索引号打印在客户的对帐单上。

检索索引号由收单行分配。

选用条件：可包含在收单机构的交易请求中。如在交易请求中有，则应答数据中一定应原样返回。

21，Bit38授权码(Authorization Identification)

位图位置：38

格式：定长

类型：AN6

描述：交易授权机构返回的返回代码。

授权码用于在服务点终端上信用卡授权；

授权机构按网络操作规定，可选使用本域。

22，Bit39返回码(Response Code)

位图位置：39

格式：定长

类型：AN2

描述：对一交易定义其处理结果的编码。

返回码用于说明授权机构对金融（授权）交易的处理状态；也用来指明自动冲正交易的冲正原因；还用来指出目标主机已接收到文件修改、结算、管理、网管等交易请求。

返回码应尽可能准确，应尽可能描述清楚所遇到的问题和状态。网络交换主机、收单行主机有可能会按不同的返回码收取不同的交易处理费用，并执行不同的处理过程。

23，Bit41收卡单位终端标识码(Card Acceptor Terminal Identification) 位图位置：41

格式：定长

类型：ANS8

描述：定义在收单单位中定义一个服务终端的标识码，在同一商户中服务终端标识码应唯一。

24，Bit42收卡商户定义码(Card Acceptor Identification Code)

位图位置：42

格式：定长

类型：ANS15

描述：在本地和网络中定义交易单位（商户）的编码。

25，Bit43收卡商户位置(Card Acceptor Location)

位图位置：43

格式：定长

类型：ANS40

描述：在本地和网络中定义收卡单位（商户）的国家、省。城市等。

选用条件：如对外卡网络，一定要包含此域。

26，Bit44附加返回数据(Additional ResponseData)

位图位置：44

格式：LLVAR

类型：ANS..25

描述：在金融（授权）交易中授权机构返回的其他信息。

27，Bit48附加数据-私用(Additional Data-Private)

位图位置：48

格式：LLLVAR

类型：ANS (999)

描述：银行电子服务系统使用此域作以下用途

存放批量查询的返回数据

其格式与输出格式表对应

28，Bit49交易货币代码(Currency Code,Transaction)

位图位置：49

格式：定长

类型：AN3

描述：按ISO4217定义的交易货币代码，用来表示“交易金额”（field04）所用的货币种类。

交易货币代码是指在收单单位进行交易所用的交易种类。

29，Bit50结算货币代码(Currency Code,Settlement)

位图位置：50

格式：定长

类型：AN3

描述：按ISO4217定义的结算货币代码，用来表示结算金额、结算处理费、结算交易费等所用的货币种类。

结算货币代码是指在进行结算和清算过程中所用的货币种类。

30，Bit52用户密码(PIN)数据(PIN Data)

位图位置：52

格式：定长

类型：B16

描述：用户在服务终端上交易用于识别用户合法性的一些数字。

PIN在分行主机用分行主机密钥按ANSI X9.8标准加密，形成密文块。

选用条件：如果在终端上输入了密码，就需要此域。

31，Bit53密码相关控制信息(Security Related Control)

位图位置：53

格式：定长

类型：AN16

描述：本域提供有关密码块的附加信息，用于指出用于PIN计算的PIN key，用于MAC计算的MAC key。

本域格式如下表所示：

0－1格式代码2N“20”

2－3PIN加密算法2N“01”:DES

4－5密文块格式2N“01”:ANSI

6PIN密钥索引1N‘1’或‘2’

7MAC密钥索引1N‘1’或‘2’

8－11MAC检查数据4B

12－15填充4N

在BOC信用卡网络中PIN和MAC各使用两个密钥---'1'号和'2'密钥，交易中计算PIN和MAC时只能各用某一个KEY，同时需将所用的KEY索引号填写此域。选用条件：如果有PIN域或MAC域，一定需有此域。

网络协议报文格式大集合

可编辑目录 1 序、 (2) 1.1 协议的概念 (2) 1.2 TCP/IP体系结构 (2) 2 链路层协议报文格式 (2) 2.1 Ethernet报文格式 (2) 2.2 802.1q VLAN数据帧(4字节） (3) 2.3 QinQ帧格式 (4) 2.4 PPP帧格式 (4) 2.5 STP协议格式 (5) 2.5.1 语法 (5) 2.5.2 语义 (6) 2.5.3 时序 (8) 2.6 RSTP消息格式 (9) 2.6.1 语法 (9) 2.6.2 语义 (11) 2.6.3 时序 (13) 3 网络层协议报文 (14) 3.1 IP报文头 (14) 3.2 ARP协议报文 (16) 3.2.1 语法 (16) 3.2.2 语义 (17) 3.2.3 时序 (17) 3.3 VRRP协议报文 (18) 3.3.1 语法 (18) 3.4 BGP协议报文 (19) 3.4.1 语法 (19) 3.4.2 语义 (25)

1 序、 1.1 协议的概念协议由语法、语义和时序三部分组成：语法：规定传输数据的格式；语义：规定所要完成的功能；时序：规定执行各种操作的条件、顺序关系； 1.2 TCP/IP体系结构 TCP/IP协议分为四层结构，每一层完成特定的功能，包括多个协议。本课程实验中相关协议的层次分布如附图3-1所示。图1-1TCP/IP协议层次这些协议之间的PDU封装并不是严格按照低层PDU封装高层PDU的方式进行的，附图3-2显示了Ethernet帧、ARP分组、IP分组、ICMP报文、TCP报文段、UDP数据报、RIP报文、OSPF报文和FTP报文之间的封装关系。图1-2各协议PDU间的封装关系 2 链路层协议报文格式 2.1 Ethernet报文格式最新的IEEE 802.3标准（2002年）中定义Ethernet帧格式如下：

计算机网络使用网络协议分析器捕捉和分析协议数据包样本

计算机网络使用网络协议分析器捕捉和分析协议数据包样本计算机网络使用网络协议分析器捕捉和分析协议数据包广州大学学生实验报告开课学院及实验室:计算机科学与工程实验室11月月28日学院计算机科学与教育软件学院年级//专业//班姓名学号实验课程名称计算机网络实验成绩实验项目名称使用网络协议分析器捕捉和分析协议数据包指导老师熊伟一、实验目的 (1)熟悉ethereal的使用 (2)验证各种协议数据包格式 (3)学会捕捉并分析各种数据包。本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。二、实验环境1．MacBook Pro2．Mac OS3..Wireshark 三、实验内容，验证数据帧、IP数据报、TCP数据段的报文格式。，，分析结果各参数的意义。器，分析跟踪的路由器IP是哪个接口的。对协议包进行分析说明，依据不同阶段的协议出分析，画出FTP 工作过程的示意图a..地址解析ARP协议执行过程b.FTP控制连接建立过程c.FTP用户登录身份验证过程本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。

文档如有不当之处，请联系本人或网站删除。 d.FTP数据连接建立过程 e.FTP数据传输过程 f.FTP连接释放过程（包括数据连接和控制连接），回答以下问题:a..当访问某个主页时，从应用层到网络层，用到了哪些协议?b.对于用户请求的百度主页（），客户端将接收到几个应答报文??具体是哪几个??假设从是本地主机到该页面的往返时间是RTT，那么从请求该主页开始到浏览器上出现完整页面，一共经过多长时间??c.两个存放在同一个服务器中的截然不同的b Web页（例如，，和d.假定一个超链接从一个万维网文档链接到另一个万维网文档，由于万维网文档上出现了差错而使超链接指向一个无效的计算机名，这时浏览器将向用户报告什么?e.当点击一个万维网文档时，若该文档除了次有文本外，，那么需要建立几次TCP连接和个有几个UDP过程?本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不当之处，请联系本人或网站删除。析，分析ARP攻击机制。（选做），事实上，TCP开始发送数据时，使用了慢启动。利察用网络监视器观察TCP的传输和确认。在每一确认到达之后，慢启动过程中发生了什么?（选做），，TCP 必须准备重发初始段（用于打开一个连接的一个段）。 TCP应等多久才重发这一段?TCP应重发多少次才能宣布它不能打开一个连接?为找到结果尝试向一个不存在的地址打开一个连接，并使用网络监视器观察TCP的通信量。

TCPIP等协议报文格式

TCP/IP等协议报文格式应用层（Application） HTTP、Telnet、FTP、SNMP、SMTP 传输层（transport） TCP、UDP 网间层（Internet） IP-ARP、RARP、ICMP 网络接口层（NETwork）Ethernet、X.25、SLIP、PPP 以太网数据报文封装格式 TCP报文 TCP数据区 TCP IP报文 IP数据区 IP 帧头帧数据区

ETH 前导目的地址源地址帧类型数据 CRC 长度 8 6 6 2 46~1500 4 用户填充数据60~1514 8字节前导用于帧同步，CRC用于帧校验，此2类数据可由网卡芯片自动添加。目的地址和源地址是指网卡的物理地址，即MAC地址，多数情况下具有唯一性。帧类型或协议类型——0X0806为ARP协议，0X0800为IP协议。 ARP/RARP (地址解析/反向地址解析)报文格式 0~7

8~15 16~23 24~31 硬件协议协议类型硬件地址长度协议地址长度操作发送者硬件地址（字节0~3）发送者硬件地址（字节4~5）发送者IP地址（字节0~1）发送者IP地址（字节2~3）目的硬件地址（字节0~1）目的硬件地址（字节2~5）目的IP地址（字节0~3）硬件类型——发送者本机网络接口类型（以太网=1）协议类型——发送者所提供/请求的高级协议地址类型（IP协议=0x0800）操作——ARP请求=1，ARP响应=2，RARP请求=3，RARP响应=4

IP数据报头格式如下表0~3 4~7 8~11 12~15 16~18 19~31 4位版本 4位包头长度 8位服务类型（TOS） 16位总长度 16位标识号（ID号） 3位 Flag 13位片偏移 8位生存时间 8位协议类型 16位

常见网络协议报文格式汇总

附件：报文格式 1.1Ethernet数据包格式(RFC894) 1、DstMac的最高字节的最低BIT位如果为1，表明此包是以太网组播/广播包，送给CPU处理。 2、将DstMac和本端口的MAC进行比较，如果不一致就丢弃。 3、获取以太网类型字段Type/Length。 0x0800→IP 继续进行3层的IP包处理。 0x0806→ARP 送给CPU处理。 0x8035→RARP 送给CPU处理。 0x8863→PPPoE discovery stage 送给CPU处理。 0x8864→PPPoE session stage 继续进行PPP的2层包处理。 0x8100→VLAN 其它值当作未识别包类型而丢弃。 1.2PPP数据包格式 1、获取PPP包类型字段。 0x0021→IP 继续进行3层的IP包处理。 0x8021→IPCP 送给CPU处理。 0xC021→LCP 送给CPU处理。 0xc023→PAP 送给CPU处理。 0xc025→LQR 送给CPU处理。 0xc223→CHAP 送给CPU处理。 0x8023→OSICP 送给CPU处理。 0x0023→OSI 送给CPU处理。其它值当作未识别包类型而丢弃。

1.3 ARP 报文格式(RFC826) |←----以太网首部---->|←---------28字节ARP 请求/应答 ------ 1.4 IP 报文格式(RFC791)(20bytes) TOS 1.5 PING 报文格式(需IP 封装)(8bytes) 1.6 TCP 报文格式(需IP 封装)(20bytes)

紧急指针有效 ACK 确认序号有效 PSH 接收方应该尽快将这个报文交给应用层 RST 重建连接 SYN 同步序号用来发起一个连接 FIN 发端完成发送认务 1.7 UDP 报文格式(需IP 封装)(8bytes) 1.8 MPLS 报文格式 MPLS 报文类型: 以太网中 0x8847(单播) 0x8848(组播) PPP 类型上 0x8281(MPLSCP)

网络协议：传输层协议报文信息分析

网络协议实验报告实验名称：传输层协议报文承载信息分析实验目的：进一步熟悉协议分析工具软件使用，分析传输层报文承载的信息，掌握传输层协议工作的基本原理。实验内容： 1、熟练应用与传输层有关的程序命令netstat、telnet； 2、截取浏览网页时和即时通讯时的数据报文，分析是基于UDP还是基于TCP（即时通讯程序可选择QQ、MSN），并分析每种应用各自的端口号（分客户端和服务端）； 3、通过协议分析软件分析TCP和UDP的报文格式；分析MSS和MTU 的关系，认识TCP报文中携带MSS的时机。 4、截取有关数据报文，分析TCP建立连接时“三次握手”的过程。可通过telnet应用程序帮助建立的TCP连接，也可对基于TCP的应用程序工作时的TCP连接进行截取数据报。 5、截取有关数据报文，分析TCP断开连接时“四次握手”的过程。 6、在进行大量的数据上传或下载时（比如基于HTTP或FTP的较大文件的上传）,通过协议分析观察是否有流量和拥塞控制的表征。实验日期：2010-12-09 实验步骤： (1)学习使用netstat 和telnet 命令在命令窗口中输入 netstat /?即可得到所有命令（如图下）

当前网络的TCP、UDP连接状态（如图）

（2）telnet 命令（如图）使用telnet https://www.360docs.net/doc/be10963478.html, 80 远程登录中国矿业大学服务器，使用三次TCP连接（如图）（3）截取浏览网页时和即时通讯时的数据报文，分析是基于UDP还是基于TCP （即时通讯程序可选择QQ、MSN），并分析每种应用各自的端口号（分客户端和服务端）； A、捕获浏览器浏览网页时的数据报文是基于TCP 其对应的源端口号：客户端是：3575 服务端是：80 （如图）

http协议数据包格式

竭诚为您提供优质文档/双击可除http协议数据包格式篇一：数据包格式 tcp/ip协议族包括诸如internet协议(ip)、地址解析协议(aRp)、互联网控制信息协议(icmp)、用户数据报协议(udp)、传输控制协议(tcp)、路由信息协议(Rip)、telnet、简单邮件传输协议(smtp)、域名系统(dns)等协议。tcp/ip 协议的层次结构如图3所示。图3tcp/ip协议层次结构 (1)应用层应用层包含一切与应用相关的功能，相当于osi的上面三层。我们经常使用的http、Ftp、telnet、smtp 等协议都在这一层实现。 (2)传输层传输层负责提供可靠的传输服务。该层相当于osi模型中的第4层。在该层中，典型的协议是 tcp(transmissioncontrolprotocol)和 udp(userdatagramprotocol)。其中，tcp提供可靠、有序的，面向连接的通信服务；而udp则提供无连接的、不可靠用户数据报服务。 (3)网际层网际层负责网络间的寻址和数据传输，其功

能大致相当于osi模型中的第3层。在该层中，典型的协议是ip(internetprotocol)。 (4)网络接口层最下面一层是网络接口层，负责数据的实际传输，相当于osi模型中的第1、第2层。在tcp/ip协议族中，对该层很少具体定义。大多数情况下，它依赖现有的协议传输数据。 tcp/ip与osi最大的不同在于osi是一个理论上的网络通信模型，而tcp/ip则是实际运行的网络协议。tcp/ip实际上是由许多协议组成的协议簇。图4示出tcp/ip的主要协议分类情况。整个过程： 1.dhcp请求ip地址的过程 l发现阶段，即dhcp客户端寻找dhcp服务器的阶段。客户端以广播方式发送dhcpdiscoVeR包，只有dhcp服务器才会响应。 l提供阶段，即dhcp服务器提供ip地址的阶段。dhcp 服务器接收到客户端的dhcpdiscoVeR报文后，从ip地址池中选择一个尚未分配的ip地址分配给客户端，向该客户端发送包含租借的ip地址和其他配置信息的dhcpoFFeR包。 l选择阶段，即dhcp客户端选择ip地址的阶段。如果有多台dhcp服务器向该客户端发送

Wireshark的数据包截获及协议分析

Wireshark的数据包截获与协议分析 1 引言在数据包的截获方面，Winpcap 是一个可在 Windows 环境下运行的包俘获结构,它由三部分组成:一个数据包截获驱动程序、一个底层动态链接库(Packet.dll)和一个高层静态链接库(wpcap.lib)。它的核心部分是数据包俘获驱动程序,在 Windows NT/2000 系统中,它实现为一个内核驱动程序(packet.sys),在 Windows 95/98 系统中是一个虚拟设备驱动程序 (packet.vxd), 包俘获驱动程序通过NDIS(Network Driver Interface Specification)同网络适配器的驱动程序进行通信,NDIS 是网络代码的一部分,它负责管理各种网络适配器以及在适配器和网络协议软件之间的通信。在库的高层是一个动态链接库(packet.dll)和一个静态链接库 (wpcap.lib)，这两个库的作用是将俘获应用程序同包俘获驱动程序相隔离，屏蔽低层的实现细节，避免在程序中直接使用系统调用或 IOCTL 命令，为应用程序提供系统独立的高层接口（API 函数），从而在 Windows9x、Windows2000/XP 系统下,对驱动程序的系统调用都是相同的。使用 Winpcap，我们可以编写出用于网络协议实验分析、故障诊断、网络安全和监视等各种应用程序，这方面的一个典型例子就是可在 Windows 系统下运行的 Wireshark，Wireshark 和 Winpcap 都可从网上下载，通过 Wireshark 我们可以从网上拦截数据包并对

数据包进行网络协议分析，下面介绍一个分析实例。

网络协议报文格式大集合

目录 1序、 (2) 1.1 协议的概念 (2) 1.2 TCP/IP体系结构 (2) 2链路层协议报文格式 (2) 2.1 Ethernet报文格式 (2) 2.2 802.1q VLAN数据帧(4字节） (3) 2.3 QinQ帧格式 (4) 2.4 PPP帧格式 (4) 2.5 STP协议格式 (5) 2.5.1 语法 (5) 2.5.2 语义 (6) 2.5.3 时序 (8) 2.6 RSTP消息格式 (9) 2.6.1 语法 (9) 2.6.2 语义 (11) 2.6.3 时序 (13) 3网络层协议报文 (14) 3.1 IP报文头 (14) 3.2 ARP协议报文 (16) 3.2.1 语法 (16) 3.2.2 语义 (17) 3.2.3 时序 (17) 3.3 VRRP协议报文 (18) 3.3.1 语法 (18) 3.4 BGP协议报文 (19) 3.4.1 语法 (19) 3.4.2 语义 (25)

(完整版)协议分析--数据报格式

两种不同的MAC帧格式常用的以太网MAC帧格式有两种标准，一种是DIX Ethernet V2标准，另一种是IEEE的802.3标准。如下图所示，为便于理解，图中假定网络层使用的是IP协议。实际上使用其他的协议也是可以的。现在MAC帧最常用的是以太网V2的格式，它较为简单，由5个字段组成。前两个字段分别为6字节长的目的地址和源地址字段。第三个字段是2字节的类型宇段，用来标志上一层使用的是什么协议，以便把收到的MAC 帧的数据上交给上一层的这个协议。施乐公司负责管理这个类型字段的代码分配。例如，当类型字段的值是0x0800时，就表示上层使用的是IP数据报。若类型字段的值为0x8137，则表示该帧是由Novell IPX发过来的。第四个字段是数据字段，但它的正式名称是MAC客户数据宇段，其长度在46到1500字节之间。最后一个字段是4字节的帧检验序列FCS。当数据字段的长度小于46字节时，MAC子层就会在数据字段的后面加入一个整数字节的填充字段，以保证以太网的MAC帧长不小于64字节。我们应当注意到，MAC帧的首部并没有指出数据字段的长度是多少。在有填充字段的情况下，接收端的MAC子层在剥去首部和尾部后就将数据字段和填充字段一起交给上层协议。然而IEEE 802.3标准规定的MAC帧则较为复杂。它和以太网V2的MAC

帧的区别是： (1)第三个字段是长度/类型字段。根据长度/类型字段的数值大小，这个字段可以表示MAC帧的数据字段长度(请注意：不是整个MAC帧的长度)，也可以等同于以太网V2的类型字段。具体地讲：若长度/类型字段的数值小于MAC帧的数据字段的最大值1500(字节)，这个字段就表示MAC帧的数据字段长度。若长度/类型字段的数值大于0x0600(相当于十进制的1536)，那么这个数值就不可能表示以太网有效的数据字段长度，因而这个字段就表示类型。当长度/类型字段表示类型时，802.3的MAC帧和以太网V2的MAC帧一样。当长度/类型字段表示长度时，MAC帧就必须装入802．2标准定义的LLC子层的LLC帧。从图中可看出，在传输媒体上实际传送的要比MAC帧还多8个字节。这是因为当一个站在刚开始接收MAC帧时，由于尚未与到达的比特流达成同步，因此MAC帧的最前面的若干个比特就无法接收，结果使整个的MAC 成为无用的帧。为了达到比特同步，从MAC子层向下传到物理层时还要在帧的前面插入8字节(由硬件生成)，它由两个字段构成。第一个字段共7个字节，称为前同步码(1和0交替的码)。前同步码的作用是使接收端在接收MAC帧时能够迅速实现比特同步。第二个字段是帧开始定界符，定义为10101011，表示在这后面的信息就是MAC帧了。在MAC子层的FCS的检验范围不包括前同步码和帧开始定界符。顺便指出，在广域网点对点通讯中使用同步传输的HDLC规程时则不需要用前同步码，因为在同步传输时收发双方的比特同步总是一直保持着的。 802.3标准规定凡出现下列情况之一的即为无效的MAC帧： (1)MAC客户数据字段的长度与长度字段的值不一致； (2)帧的长度不是整数个字节； (3)用收到的帧检验序列FCS查出有差错； (4)收到的帧的MAC客户数据字段的长度不在46—1500字节之间。考虑到MAC帧首部的长度是18字节，可以得出有效的MAC帧长度为64～1518字节之间。对于检查出的无效MAC帧就简单地丢弃。以太网不负责重传丢弃的帧。当MAC客户数据字段的长度小于46字节时，则应加以填充(内容不限)。这样，整个MAC帧(包含14字节首部和4字节尾部)的最小长度是64字节，或512bit。 MAC子层的标准还规定了帧间最小间隔为9.6us，相当于96bit的发送时间。这就是说，一个站在检测到总线开始空闲后，还要等待9.6us才能发送

以太网协议报文格式

T C P/I P协议族

IP/TCP Telnet和R login、FTP以及SMTP IP/UDP DNS 、TFTP、BOOTP、SNMP ICMP是IP协议的附属协议、IGMP是Internet组管理协议 ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换I P层和网络接口层使用的地址。 1、以太帧类型以太帧有很多种类型。不同类型的帧具有不同的格式和MTU值。但在同种物理媒体上都可同时存在。

?标签协议识别符(Tag Protocal Identifier, TPID): 一组16位元的域其数值被设定在0x8100以用来辨别某个IEEE 802.1Q的帧为已被标签的，而这个域所被标定位置与乙太形式/长度在未标签帧的域相同，这是为了用来区别未标签的帧。 ?优先权代码点(Priority Code Point, PCP): 以一组3位元的域当作IEEE 802.1p 优先权的参考，从0(最低)到7(最高)，用来对资料流(音讯、影像、档案等等)作传输的优先级。 ?标准格式指示(Canonical Format Indicator, CFI): 1位元的域。若是这个域的值为1，则MAC地指则为非标准格式；若为0，则为标准格式；在乙太交换器中他通常默认为0。在乙太和令牌环中，CFI用来做为两者的相容。若帧在乙太端中接收资料则CFI的值须设为1，且这个端口不能与未标签的其他端口桥接。?虚拟局域网识别符(VLAN Identifier, VID): 12位元的域，用来具体指出帧是属于哪个特定VLAN。值为0时，表示帧不属于任何一个VLAN；此时，802.1Q标签代表优先权。16位元的值0x000和0xFFF为保留值，其他的值都可用来做为共4094个VLAN的识别符。在桥接器上，VLAN1在管理上做为保留值。这个12位元的域可分为两个6位元的域以延伸目的(Destination)与源(Source)之48位元地址，18位元的三重标记(Triple-Tagging)可和原本的48位元相加成为66位元的地址。 0、以太网的封装格式（RFC 894） IEEE 802.2/802.3（RFC 1042）

网络协议数据报文格式

协议数据报文格式 1、TCP/IP 协议层次 TCP/IP 协议分为四层结构，每一层完成特定的功能，包括多个协议。本课程实验中相关协议的层次分布如附图3-1所示。附图3-1 TCP/IP 协议层次这些协议之间的PDU 封装并不是严格按照低层PDU 封装高层PDU 的方式进行的，附图3-2显示了Ethernet 帧、ARP 分组、IP 分组、ICMP 报文、TCP 报文段、UDP 数据报、RIP 报文、OSPF 报文和FTP 报文之间的封装关系。附图3-2 各协议PDU 间的封装关系 2、Ethernet 帧格式最新的IEEE 802.3标准（2002 年）中定义Ethernet 帧格式如下：其中，类型/长度值小于1536（0x0600）时表示数据字段的长度，大于等于1536 （0x0600）时表示数据字段的协议类型。类型/长度值0x0800表示帧中封装的数据为IP 分组，类型值0x0806表示帧中封装的数据为ARP 分组。 3、IP 分组格式（RFC 791） 4、ARP 分组格式（RFC 826）操作代码值1表示ARP 请求分组，操作代码值2表示ARP 响应分组。 Ethernet 帧标志（3 bits ）：不分片（D ）： 0=可以分片 1=不能分片还有分片（M ）： 0=最后的分片 1=还有更多分片协议：1=ICMP 89=OSPF 6=TCP 17=UDP 底层协议（Ethernet ） IP 、ARP 、ICMP TCP 、UDP RIP 、OSPF 、FTP

5、ICMP 报文格式（RFC 792） ICMP 回送请求和回送应答报文： ICMP 目的不可达报文： ICMP 超时报文： 6、TCP 报文段格式（RFC 793） 7、RIP 报文格式（版本1－RFC 1058，版本2－RFC2453） RIP 请求报文在某些RIP 路由表项超时或路由器刚接入互联网时发送，请求报文可以询问特定路由或所有路由。路由器在回应请求报文时发送携带被询问路由信息的RIP 响应报文，也可以定期（30秒）发送携带整个路由表信息的RIP 响应报文。控制比特： ACK 确认字段有效 PSH 请求推操作 RST 连接复位 SYN 同步序号 FIN 终止连接代码： 0 TTL 超时 1 分片重组超时 31 bits 8 16 代码： 0 网络不可达 4 需分片但被禁止 1 主机不可达 5 源路由失败 2 协议不可达 6 目的网络未知 3 端口不可达 7 目的主机未知类型： 0 回送应答 8 回送请求 31 bits 硬件类型： 0x0001=以太网 0x0800=IP 协议

分析IP协议数据包格式

实验名称：分析IP协议数据包格式实验目的：掌握IP协议的作用和格式；理解IP数据包首部各字段的含义；掌握IP数据包首部校验和的计算方法。实验器材：计算机及以太网环境。实验内容（步骤）： 1.打开Wireshark软件，选择菜单命令“Capture” “Interfaces…”子菜单项。弹出“Wireshark: Capture Interfaces”对话框。单击“Options”按钮，弹出“Wireshark: Capture Options”对话框。单击“Start”按钮开始网络数据包捕获。 2.浏览外部网站，确保协议分析软件能够捕获足够的网络数据包，单击“Stop”按钮，中断网络协议分析软件的捕获进程，主界面显示捕获到的数据包。几乎所有的高层协议都使用IP协议进行网络传输，只有ARP和RARP报文不被封装在IP数据报中。 3.观察协议树区中IP数据包各个字段的长度与值，是否符合IP报文格式。

对帧61的IP数据包进行分析 Internet Protocol互联网协议（ IP ）源：61.135.163.233，目标：192.168.1.2 Version（版本）：一个4字节的字段。表示当前正运行的IP版本信息。上图中版本的信息是IPv4。 Header length IP（报头长度）：一个4字节的字段，表示以32比特为单位的信息中数据包报头的长度。这是所有报头信息的总长度。上图为20字节 Differentiated services Filed（服务的类别）：一个8字节的字段，表示一个特定的上层协议所分配的重要级别。 Differentiated Services Codepoint(差分服务代码点6位)：默认的DSCP值是0，相当于尽力传送。 two-bit Explicit Congestion Notification field（2位明确的拥塞通知字段） ECN-Capable Transport：(ECN Explicit Cogestion Notification -Capable Transport)：显式拥塞指示能力传输字段，该ECN-Capable Transport (ECT) bit将被数据发送者设置，以表明传输协议的末端节点有ECN的能力。 ECT bit设置为“ 0 ”表明该传输协议将忽略ignore CE bit。这是ECT bit的默认值。 ECT bit设置为“ 1 ”表示该传输协议愿意willing并and能够参与在ECN。

网络协议报文格式汇总

S .. . .. 目录 1 序、 (2) 1.1 协议的概念 (2) 1.2 TCP/IP体系结构 (2) 2 链路层协议报文格式 (2) 2.1 Ethernet报文格式 (2) 2.2 802.1q VLAN数据帧(4字节） (2) 2.3 QinQ帧格式 (2) 2.4 PPP帧格式 (2) 2.5 STP协议格式 (2) 2.5.1 语法 (2) 2.5.2 语义 (2) 2.5.3 时序 (2) 2.6 RSTP消息格式 (2) 2.6.1 语法 (2) 2.6.2 语义 (2) 2.6.3 时序 (2) 3 网络层协议报文 (2) 3.1 IP报文头 (2) 3.2 ARP协议报文 (2) 3.2.1 语法 (2) 3.2.2 语义 (2) 3.2.3 时序 (2) 3.3 VRRP协议报文 (2) 3.3.1 语法 (2) 3.4 BGP协议报文 (2) 3.4.1 语法 (2) 3.4.2 语义 (2)

tcpip协议报文格式

1、IP报文格式 IP协议是TCP/IP协议族中最为核心的协议。它提供不可靠、无连接的服务，也即依赖其他层的协议进行差错控制。在局域网环境，IP协议往往被封装在以太网帧（见本章1.3节）中传送。而所有的TCP、UDP、ICMP、IGMP数据都被封装在IP数据报中传送。如图2-3所示：图2-3TCP/IP报文封装图2-4是IP头部（报头）格式：（RFC 791）。图2-4IP头部格式其中： ●版本（Version）字段：占4比特。用来表明IP协议实现的版本号，当前一般为IPv4，即0100。 ●报头长度（Internet Header Length，IHL）字段：占4比特。是头部占32比特的数字，包括可选项。普通IP数据报（没有任何选项），该字段的值是5，即160比特=20字节。此字段最大值为60字节。 ●服务类型（Type of Service ，TOS）字段：占8比特。其中前3比特为优先权子字段（Precedence，现已被忽略）。第8比特保留未用。第4至第7比特分别代表延迟、吞吐量、可靠性和花费。当它们取值为1时分别代表要求最小时延、最大吞吐量、最高可靠性和最小费用。这4比特的服务类型中只能置其中1比特为1。可以全为0，若全为0则表示一般服务。服务类型字段声明了数据报被网络系统传输时可以被怎样处理。例如：TELNET 协议可能要求有最小的延迟，FTP协议（数据）可能要求有最大吞吐量，SNMP协议可能要求有最高可靠性，NNTP（Network News Transfer Protocol，网络新闻传输协议）可能要求最小费用，而ICMP协议可能无特殊要求（4比特全为0）。实际上，大部分主机会忽略这个字段，但一些动态路由协议如OSPF（Open Shortest Path First Protocol）、IS-IS （Intermediate System to Intermediate System Protocol）可以根据这些字段的值进行路由决策。 ●总长度字段：占16比特。指明整个数据报的长度（以字节为单位）。最大长度为65535字节。

#网络协议：传输层协议报文信息分析

网络协议实验报告实验人：马国礼班级：网络08—（1）班学号：08083726 实验名称：传输层协议报文承载信息分析实验目的：进一步熟悉协议分析工具软件使用，分析传输层报文承载的信息，掌握传输层协议工作的基本原理。实验内容： 1、熟练使用和传输层有关的程序命令netstat、telnet； 2、截取浏览网页时和即时通讯时的数据报文，分析是基于UDP还是基于TCP（即时通讯程序可选择QQ、MSN），并分析每种使用各自的端口号（分客户端和服务端）； 3、通过协议分析软件分析TCP和UDP的报文格式；分析MSS和MTU 的关系，认识TCP报文中携带MSS的时机。 4、截取有关数据报文，分析TCP建立连接时“三次握手”的过程。可通过telnet使用程序帮助建立的TCP连接，也可对基于TCP的使用程序工作时的TCP连接进行截取数据报。 5、截取有关数据报文，分析TCP断开连接时“四次握手”的过程。 6、在进行大量的数据上传或下载时（比如基于HTTP或FTP的较大文件的上传）,通过协议分析观察是否有流量和拥塞控制的表征。实验日期：2010-12-09 实验步骤： (1)学习使用netstat 和telnet 命令在命令窗口中输入 netstat /?即可得到所有命令（如图下）

当前网络的TCP、UDP连接状态（如图）

（2）telnet 命令（如图）使用telnet https://www.360docs.net/doc/be10963478.html, 80 远程登录中国矿业大学服务器，使用三次TCP连接（如图）（3）截取浏览网页时和即时通讯时的数据报文，分析是基于UDP还是基于TCP （即时通讯程序可选择QQ、MSN），并分析每种使用各自的端口号（分客户端和服务端）； A、捕获浏览器浏览网页时的数据报文是基于TCP 其对应的源端口号：客户端是：3575 服务端是：80 （如图）

计算机网络协议分析实验指导书V201506

网络协议分析实验指导书

1、网络层协议分析 1.A 数据包捕获分析部分 1.A.1、实验目的 1)、了解ICMP 协议报文类型及作用。 2）、理解IP协议报文类型和格式。 3）、分析ARP 协议的报文格式，理解ARP 协议的解析过程。 1.A.2、实验内容介绍 1)、ICMP协议分析实验执行ping 和tracert 命令，分别截获报文，分析截获的ICMP 报文类型和ICMP 报文格式，理解ICMP 协议的作用。 2)、IP协议分析实验使用Ping 命令在两台计算机之间发送数据报，用Wireshark 截获数据报，分析IP 数据报的格式，理解IP V4 地址的编址方法，加深对IP 协议的理解。 3)、IP 数据报分片实验我们已经从前边的实验中看到，IP 报文要交给数据链路层封装后才能发送。理想情况下，每个IP 报文正好能放在同一个物理帧中发送。但在实际应用中，每种网络技术所支持的最大帧长各不相同。例如：以太网的帧中最多可容纳1500 字节的数据，这个上限被称为物理网络的最大传输单元（MTU，MaxiumTransfer Unit）。 TCP/IP 协议在发送IP 数据报文时，一般选择一个合适的初始长度。当这个报文要从一个MTU 大的子网发送到一个MTU 小的网络时，IP 协议就把这个报文的数据部分分割成能被目的子网所容纳的较小数据分片，组成较小的报文发送。每个较小的报文被称为一个分片（Fragment）。每个分片都有一个IP 报文头，分片后的数据报的IP 报头和原始IP 报头除分片偏移、MF 标志位和校验字段不同外，其他都一样。重组是分片的逆过程，分片只有到达目的主机时才进行重组。当目的主机收到IP 报文时，根据其片偏移和标志MF 位判断其是否一个分片。若MF 为0，片偏移为0，则表明它是一个完整的报文；否则，则表明它是一个分片。当一个报文的全部分片都到达目的主机时，IP 就根据报头中的标识符和片偏移将它们重新组成一个完整的报文交给上层协议处理。 4)、ARP协议分析实验本次实验使用的Windows自带的Arp命令，提供了显示和修改地址解析协议所使用的地址映射表的功能。

网络协议实验报告讲解

实验一以太网链路层帧格式分析一．实验目的分析MAC层帧结构二．实验内容及步骤步骤一：运行ipconfig命令在Windows的命令提示符界面中输入命令：ipconfig /all，会显示本机的网络信息：步骤二：编辑LLC信息帧并发送 1、打开协议数据发生器，在工具栏选择“添加”，会弹出“网络包模版”的对话框，在“选择生成的网络包”下拉列表中选择“LLC协议模版”，建立一个LLC帧。

2、在“网络包模版”对话框中点击“确定”按钮后，会出现新建立的数据帧，此时在协议数据发生器的各部分会显示出该帧的信息。 3、编辑LLC帧。 4、点击工具栏或菜单栏中的“发送”，在弹出的“发送数据包”对话框上选中“循环发送”，填入发送次数，选择“开始”按钮，即可按照预定的数目发送该帧。在本例中，选择发送10次。 5、在主机B的网络协议分析仪一端，点击工具栏内的“开始”按钮，对数据帧进行捕获，按“结束”按钮停止捕获。捕获到的数据帧会显示在页面中，可以选择两种视图对捕获到的数据帧进行分析，会话视图和协议视图，可以清楚的看到捕获数据包的分类统计结果。步骤三：编辑LLC监控帧和无编号帧，并发送和捕获步骤四：保存捕获的数据帧步骤五：捕获数据帧并分析 1、启动网络协议分析仪在网络内进行捕获，获得若干以太网帧。 2、对其中的5-10个帧的以太网首部进行观察和分析，分析的内容为：源物理地址、目的物理地址、上层协议类型。捕获到的数据报报文如下：

对所抓的数据帧进行分析： ①MAC header: 目的物理地址：00:D0:F8:BC:E7:08 源物理地址：00:13:D3:51:44:DD 类型：0800表示IP协议 ②IP header: IP协议报文格式如下：版本：4表示IPv4 首部长度：5表示5×4=20个字节。服务类型：00表示正常处理该数据报。总长度：0028表示此数据报的总长度为40字节。

网络协议报文格式汇总

目录 1 序、 (2) 1.1 协议的概念 (2) 1.2 TCP/IP 体系结构 (2) 2 链路层协议报文格式 (2) 2.1 Ethernet 报文格式 (2) 2.2 802.1q VLAN 数据帧（4 字节） (3) 2.3 QinQ 帧格式 (4) 2.4 PPP 帧格式. (4) 2.5 STP 协议格式 (5) 2.5.1 语法 (5) 2.5.2 语义 (6) 2.5.3 时序 (8) 2.6 RSTP 消息格式 (9) 2.6.1 语法 (9) 2.6.2 语义 (11) 2.6.3 时序 (13) 3 网络层协议报文 (14) 3.1 IP 报文头. (14) 3.2 ARP 协议报文 (16) 3.2.1 语法 (16) 3.2.2 语义 (17) 3.2.3 时序 (17) 3.3 VRRP 协议报文 (18) 3.3.1 语法 (18) 3.4 BGP 协议报文 (19) 3.4.1 语法 (19) 3.4.2 语义 (25)

Ethernet 1序、 1.1协议的概念协议由语法、语义和时序三部分组成：语法：规定传输数据的格式；语义：规定所要完成的功能；时序：规定执行各种操作的条件、顺序关系; 1.2 TCP/IP体系结构 TCP/IP协议分为四层结构，每一层完成特定的功能，包括多个协议。本课程实验中相关协议的层次分布如附图3-1所示。图1-1 TCP/IP协议层次 RIP、OSPF. FTP屮 TCP, UDP2 IP, ARP、ICXIP^ 底层协议（Ethernet〉# 这些协议之间的 PDU封装并不是严格按照低层PDU封装高层PDU的方式进行的，附图3-2 显示了 Ethernet帧、ARP分组、IP分组、ICMP报文、TCP报文段、UDP数据报、RIP报文、 OSPF报文和FTP 报文之间的封装关系。图1-2各协议PDU间的封装关系 2链路层协议报文格式 2.1 Ethernet报文格式最新的IEEE 802.3 标准（2002年）中定义 Ethernet帧格式如下: TCP首咅典数据：FT?"UDP首咅弘数拚：RIP" IP分组p IP首制#数据：ICMP、TCP. UDP、OSPF^' 帧苜部*数抿：ARJ\ IP屮丁空报文段a , UDP数將报4

IP协议的报文格式分析

IP协议的报文格式分析 1）分析IP 数据报头的格式，完成表9；表9 IP 协议报文分析字段报文信息说明版本头长服务类型总长度标识标志片偏移生存周期协议校验和源地址目的地址其中主要字段的意义和功能如下： * 版本：指IP协议的版本； * 头长：是指IP数据报的报头长度，它以4 字节为单位。IP报头长度至少为20 字节，如果选项部分不是4 字节的整数倍时，由填充补齐； * 总长度：为整个IP 数据报的长度； * 服务类型：规定对数据报的处理方式； * 标识：是IP协议赋予数据报的标志，用于目的主机确定数据分片属于哪个报文； * 标志：为三个比特，其中只有低两位有效，这两位分别表示该数据报文能否分段和是否该分段是否为源报文的最后一个分段； * 生存周期：为数据报在网络中的生存时间，报文每经过一个路由器时，其值减1，当生存周期变为0 时，丢弃该报文；从而防止网络中出现循环路由； * 协议：指IP数据部分是由哪一种协议发送的； * 校验和：只对IP 报头的头部进行校验，保证头部的完整性； * 源IP地址和目的IP地址：分别指发送和接收数据报的主机的IP 地址。 IP文件头的详细内容(如图13所示)，

图13 IP文件头信息包括： Version(版本)：版本序号为4，代表IPv4。 Header length：Internet文件头长度，为20个字节。 Type of service(服务类型值)：该值为00，我们会看到ToS下面一直到总长度部分都是0。这里可以提供服务质量(QoS)信息;每个二进制数位的意义都不同，这取决于最初的设定。例如，正常延迟设定为0，说明没有设定为低延迟，如果是低延迟，设定值应该为1。 Total length(总长度)：显示该数据的总长度，为Internet文件头和数据的长度之和。 Identification：该数值是文件头的标识符部分，当数据包被划分成几段传送时，接收数据的主机可以用这个数值来重新组装数据。 Flag(标记)：数据包的“标记”功能，例如，数据包分段用0标记，未分段用1标记。 Fragment offset(分段差距)：分段差距为0个字节。可以设定0代表最后一段，或者设定1代表更多区段，这里该值为0。分段差距用来说明某个区段属于数据包的哪个部分。 Time to live(保存时间)：表示TTL值的大小，说明一个数据包可以保存多久。 Protocol(协议)：显示协议值，在Sniffer Pro中代表传输层协议。文件头的协议部分只说明要使用的下一个上层协议是什么，这里为UDP。 Header checksum(校验和)：这里显示了校验和(只在这个头文件中使用)的值，并且已经做了标记，表明这个数值是正确的。 Source address(源地址)：显示了数据的来源地址。 Destination address(目的地址)：显示了数据访问的目的地址。 IP文件头下面为TCP或者UDP文件头，这里为UDP协议(如图14所示)。 UDP协议分析 IP文件头下面为TCP或者UDP文件头，这里为UDP协议(如图14所示)。图14 UDP文件头信息 UDP协议头包括下列信息： Source port(源端口)：显示了所使用的UDP协议的源端口。 Destination port(目的端口)：显示了UDP协议的目的端口。 Length(长度)：表示IP文件头的长度。 Checksum(校验和)：显示了UDP协议的校验和。 Bytes of data：表示有多少字节的数据。根据协议的不同，在详细资料窗口中有的还会显示ARP、HTTP、WINS等信息。通过这些信息，可以发现正在解析的协议中更多内容。选择第一个UDP 报文，分析其结构，填写表14。表14 UDP 报文分析 IP 报文源IP 地址协议目的IP 地址总长度 UDP 报文字段名字段长度字段值字段表达信息