实验12 HTTP报文分析
实验12 HTTP 协议分析实验
一、实验目的
在PC 机上登录Web 页面，截获报文，分析HTTP 协议的报文格式和HTTP协议的工作过程。
二、实验说明
独立完成各自实验
三、实验内容
在一台计算机上截获不同类型HTTP报文进行分析。
四、实验步骤
1.在PC 机上运行Sniffer，设置过滤器，开始截获报文；
2.从浏览器上访问Web 界面，如http://202.202.4
3.125。打开网页，待浏览器的状
态栏出现“完毕”信息后关闭网页。
3.停止截获报文，将截获的报文命名为http1-座号-姓名保存。
4.分析截获的报文，回答以下几个问题：
?在截获的HTTP 报文中，任选一个HTTP 请求报文和对应的 HTTP 应答报文，
仔细分析它们的格式，填写下面两个表格。
?
?
表2 HTTP 应答报文格式
分析在截获的报文中，客户机与服务器建立了几个连接？服务器和客户机分别使用了哪几个端口号？
建立了10个连接，服务器使用率1281，1282，1283，1284，1285，1286，1287，1288，1289端口，客户端使用80端口
1.获取长文件
(1)启动浏览器，将浏览器的缓存清空。
(2)启动Sniffer，设定过滤器HTTP，在浏览器地址栏中输入以下网址：https://www.360docs.net/doc/209374579.html,/wireshark-labs/HTTP-wireshark-file3.html 浏览器将显示一个相当大的美国权利法案。
(3)停止Sniffer，保存为：http2-座号-姓名，回答以下问题。
?一共发出了多少个HTTP GET请求？
4个GET请求
?承载这个HTTTP响应报文需要多少个data-containing TCP报文段？
一共需要4个TCP报文段
?与GET请求相对应的响应报文状态码和状态短语是什么？。
状态码：302 状态短语：Found
?在被传送的数据中共有多少个HTTP状态行与TCP-induced continuation有
关？
有，对于一个大的HTML文件会被TCP分为若干个独立的小包传输，他们是连
续的，如下图
2.嵌有对象的HTML文档
(1)启动浏览器，将浏览器的缓存清空。
(2)启动Sniffer，设定过滤器HTTP，在浏览器地址栏中输入以下网址：
https://www.360docs.net/doc/209374579.html,/wireshark-labs/HTTP-wireshark-file5.html
浏览器将显示一个具有两个图片的短HTTP文件。
(3)停止Sniffer，保存为：http3-座号-姓名，回答以下问题。
?共有多少个HTTP GET请求？这些请求被送到目的地的IP地址是多少？
4个，
?在下载这两个图片时，是串行还是并行下载？
并行
3.HTML认证
(1)启动浏览器，将浏览器的缓存清空。
(2)启动Sniffer，设定过滤器HTTP，在浏览器地址栏中输入以下网址：
https://www.360docs.net/doc/209374579.html,/wireshark-labs/protected_pages/HTTP-wireshark-file
5.html
用户名：wireshark-students 密码：network
(3)停止Sniffer，保存为http4-座号-姓名，回答以下问题。
?第一个HTTP GET请求，服务器响应是什么（状态码和状态短语）？
状态吗200 状态短语 OK
?浏览器的第二个GET请求时，在报文中包含了哪些新字段。
104规约学习(非常好)
104规约（2002版）报文解析 1、 初始化 ● 主站发: 68 04 07 00 00 00 目的：给子站发请求链路状态命令。 子站回答：68 04 0B 00 00 00 目的：子站向主站响应链路状态。 子站回答：68 0E 00 00 00 00 46 01 04 00 01 00 00 00 00 00 目的：初始化结束。 2、 对时 时钟同步命令一般不在104中应用，因为网络路由的延时永远不定（随机），导致对时不准。 ● 主站发：68 14 2C 00 6A 00 67 01 06 00 01 00 00 00 00 E5 3F 00 0F 09 0C 04 目的：向子站发送对时报文。357 毫秒 16 秒 0分 15小时 9日 12月 4年 3、 总召唤 ● 主站发：68 0E 00 00 06 00 64 01 06 00 01 00 00 00 00 14 目的：向地址为01的子站发总召唤命令。 子站回答：68 0E 08 00 02 00 64 01 07 00 01 00 00 00 00 14 目的：子站响应总召唤。 子站回答：68 2D 0A 00 02 00 01 A0 14 00 01 00 01 00 00 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 目的：子站向主站以ASDU1方式连续上送全遥信，此为第一帧。 报文解析： 子站回答：68 2D 0C 00 02 00 01 A0 14 00 01 00 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 目的：子站继续上送全遥信的下一帧。
http协议请求响应报文格式及状态码详解
HTTP协议报文格式 HTTP协议（Hypertext Transfer Protocol――超文本传输协议）浏览器端（客户端）向WEB 服务器端访问页面的过程和HTTP协议报文的格式。 基于HTTP协议的客户机访问包括4个过程，分别是建立TCP套接字连接、发送HTTP请求报文、接收HTTP应答报文和关闭TCP套接字连接： 1. 创建TCP套接字连接 客户端与WEB服务器创建TCP套接字连接，其中WEB端服务器的地址可以通过域名解析确定，WEB端的套接字侦听端口一般是80。 2. 发送HTTP请求报文 客户端向WEB服务端发送请求报文，HTTP协议的请求报文格式为： 请求消息= 请求行（实体头信息）CRLF[实体内容] 请求行= 方法URL HTTP版本号CRLF 方法= GET|HEAD|POST|扩展方法 URL = 协议名称＋宿主名＋目录与文件名 其中"CRLF"表示回车换行。 "请求行"中的"方法"描述了对指定资源执行的动作，常用的方法"GET"、"HEAD"和"POST"等3种，它们的含义如表15-8所示： 请求报文 一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。 （1）请求行 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。 HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。这里介绍最常用的GET方法和POST方法。 GET：当客户端要从服务器中读取文档时，使用GET方法。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号（“?”）代表URL的结尾 与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。POST：当客户端给服务器提供信息较多时可以使用POST方法。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据。 表15-8 HTTP请求方法
深入监控调试——报文详解
PLM 入门 V 1.0
目录 目录 (1) 版本信息 (2) 一、功能概述 (3) 二、通讯规约介绍 (3) 三、常用工具介绍 (4) 四、调试过程 (5) 4.1环境搭建 (5) 4.2运行调试 (5) 五、报文查看 (7) 5.1如何抓取报文 (7) 5.2以太网TCP104报文和串口IEC103报文： (8) 5.3串口M OD B US报文 (9) 5.4串口非标报文 (10) 六、报文实例 (11) 6.1报文实例-104上送遥脉报文 (11) 6.2报文实例-104上送遥测报文 (11) 6.3报文实例-104遥控报文 (12) 6.4报文实例-IEC103上送遥脉报文 (14) 6.5报文实例-IEC103上送遥测报文 (14) 6.6报文实例-IEC103遥控报文 (15) 6.7报文实例-IEC103压板投退报文 (16) 6.8报文实例-IEC103第一帧报文 (17) 七、实际问题分析 (17) 附A、安装包介绍 (18)
版本信息
一、功能概述 MCU801A，串口服务器，也叫做通讯管理机，在8000监控系统中作为子站（装置）和后台（8000监控）之间通讯的桥梁，起到规约转换的作用。 图1.1 监控抽象结构图 如上图所示，通过MCU，子站的数据可以上送到8000监控后台，监控后台的命令可以下达到每个子站。MCU主要在串口和以太网之间转换规约，主要涉及规约如下： 1、基于以太网的tcp104规约 2、基于串口的iec10 3、Modbus、自定义规约。 二、通讯规约介绍 通讯规约主要规定了通讯机制和数据帧的数据格式。 与我们的MCU相关的通讯规约主要有TCP104、IEC103、MODBUS，还有许多不规则的自定义规约。具体规约参考产品的规约说明文件。
104规约报文说明
主站与子站通过IEC60870－5－104规约通讯协议说明 目录 目录 (1) 前言 (1) 一、IEC60870-5-104应用规约数据单元基本结构 (2) 1.1 应用规约数据单元APDU (2) 1.2 应用规约控制信息APCI (2) 1.3 应用服务数据单元ASDU (3) 二、IEC60870-5-104规约的过程描述 (5) 三、IEC60870-5-104规约源码分析（报文分析） (5) 3.1启动连接（U格式） (5) 3.2启动连接确认（U格式） (6) 3.3总召唤（I格式） (6) 3.4总召唤确认（I格式） (6) 3.5数据确认（S格式） (6) 3.6总召唤结束（I格式） (7) 3.7测试连接（U格式） (7) 3.8测试连接确认（U格式） (7) 3.9．遥信信息（I格式） (7) 3.9遥测信息（I格式） (10) 3.10 SOE信息（I格式） (11) 前言 根据全国电力系统控制及其通信标准委员会三届五次会议和最近出版的国标DL/T634.5.104:2002对104规约的参数选择做了如下说明： 1、采用端正101规约中的链路地址和短报文（指链路确认报文） 2、采用召唤一级数据 3、两个字节表示公共地址（站址） 4、两个字节表示传送原因 5、三个字节表示信息体地址 上述3、4、5点与上一次通讯协议具体说明有冲突，为执行国际国内标准，建议根据上述要求对报文做如下修改。
一、IEC60870-5-104应用规约数据单元基本结构 应用规约数据单元：APDU（Application protocal data unit） 应用规约控制信息：APCI（Application protocal control information） 应用服务数据单元：ASDU（Application protocal control unit） APDU=APCI + ASDU 1.1 应用规约数据单元APDU 定义了启动字符、应用服务数据单元的长度规范、可传输一个完整的应用规约数据单元。 ●启动字符：68H（一个字节） ●长度规范：报文最大长度255字节，应用规约数据单元的最大长度为253字节，控 制域的长度是4字节，应用服务数据单元的最大长度为249字节。 ●控制域：控制域定义抗报文丢失和重复传送的控制信息、报文传输的启动和停止、 传输连接的监视。控制域的这些类型被用于完成计数的信息传输的（I格式）、计 数的监视功能（S格式）和不计数控制功能（U格式）。 ●应用服务数据单元 1.2 应用规约控制信息APCI 控制域定义抗报文丢失和重复传送的控制信息、报文传输的启动和仃止、传输连接的监视。控制域的这些类型被用于完成计数的信息传输的 (I格式)、计数的监视功能(S格式)和不计数的控制功能(U格式)。
常用http响应报文分析
一、HTTP响应码由三位十进制数字组成，它们出现在由HTTP服务器发送的响应的第一行。 响应码分五种类型，由它们的第一位数字表示： 1xx： 信息，请求收到，继续处理 2xx： 成功，行为被成功地接受、理解和采纳 3xx： 重定向，为了完成请求，必须进一步执行的动作 4xx： 客户端错误，请求包含语法错误或者请求无法实现 5xx： 服务器错误，服务器不能实现一种明显无效的请求 下表显示每个响应码及其含义： 100继续 101分组交换协 200 OK 201被创建 202被采纳 203非授权信息 204无内容
205重置内容206部分内容300多选项 301永久地传送302找到 303参见其他304未改动 305使用代理307暂时重定向400错误请求401未授权 402要求付费403禁止 404未找到 405不允许的方法406不被采纳407要求代理授权408请求超时409冲突 410过期的 411要求的xx
412前提不成立 413请求实例太大 414请求URIxx 415不支持的媒体类型 416无法满足的请求范围 417失败的预期 500内部服务器错误 501未被使用 502网关错误 503不可用的服务 504网关超时 505 HTTP版本未被支持 二、HTTP头标由主键/值对组成。它们描述客户端或者服务器的属性、被传输的资源以及应该实现连接。 四种不同类型的头标： 1.通用头标： 即可用于请求，也可用于响应，是作为一个整体而不是特定资源与事务相关联。 2.请求头标： 允许客户端传递关于自身的信息和希望的响应形式。 3.响应头标：
服务器和于传递自身信息的响应。 4.实体头标： 定义被传送资源的信息。即可用于请求，也可用于响应。 头标格式：
HTTP协议分析
HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。 HTTP协议的主要特点可概括如下： 1.支持客户/服务器模式。 2.简单快速： 客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、H EAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 3.灵活： HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 4.无连接： 无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 5.无状态： HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。 一、HTTP协议（URL）
http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。 HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下： http: //host[": "port][abs_path] 二、HTTP协议的请求 http请求由三部分组成，分别是： 请求行、消息报头、请求正文 1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下： Method Request-URI HTTP-Version CRLF 其中Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。 请求方法（所有方法全为大写）有多种，各个方法的解释如下： GET 请求获取Request-URI所标识的资源 POST 在Request-URI所标识的资源后附加新的数据 HEAD 请求获取由Request-URI所标识的资源的响应消息报头 PUT 请求服务器存储一个资源，并用Request-URI作为其标识
实验12 HTTP报文分析
实验12 HTTP 协议分析实验 一、实验目的 在PC 机上登录Web 页面，截获报文，分析HTTP 协议的报文格式和HTTP协议的工作过程。 二、实验说明 独立完成各自实验 三、实验内容 在一台计算机上截获不同类型HTTP报文进行分析。 四、实验步骤 1.在PC 机上运行Sniffer，设置过滤器，开始截获报文； 2.从浏览器上访问Web 界面，如http://202.202.4 3.125。打开网页，待浏览器的状 态栏出现“完毕”信息后关闭网页。 3.停止截获报文，将截获的报文命名为http1-座号-姓名保存。 4.分析截获的报文，回答以下几个问题： ?在截获的HTTP 报文中，任选一个HTTP 请求报文和对应的 HTTP 应答报文， 仔细分析它们的格式，填写下面两个表格。 ? ?
表2 HTTP 应答报文格式 分析在截获的报文中，客户机与服务器建立了几个连接？服务器和客户机分别使用了哪几个端口号？ 建立了10个连接，服务器使用率1281，1282，1283，1284，1285，1286，1287，1288，1289端口，客户端使用80端口 1.获取长文件 (1)启动浏览器，将浏览器的缓存清空。
(2)启动Sniffer，设定过滤器HTTP，在浏览器地址栏中输入以下网址：https://www.360docs.net/doc/209374579.html,/wireshark-labs/HTTP-wireshark-file3.html 浏览器将显示一个相当大的美国权利法案。
(3)停止Sniffer，保存为：http2-座号-姓名，回答以下问题。 ?一共发出了多少个HTTP GET请求？ 4个GET请求 ?承载这个HTTTP响应报文需要多少个data-containing TCP报文段？ 一共需要4个TCP报文段 ?与GET请求相对应的响应报文状态码和状态短语是什么？。 状态码：302 状态短语：Found ?在被传送的数据中共有多少个HTTP状态行与TCP-induced continuation有 关？ 有，对于一个大的HTML文件会被TCP分为若干个独立的小包传输，他们是连 续的，如下图 2.嵌有对象的HTML文档 (1)启动浏览器，将浏览器的缓存清空。 (2)启动Sniffer，设定过滤器HTTP，在浏览器地址栏中输入以下网址： https://www.360docs.net/doc/209374579.html,/wireshark-labs/HTTP-wireshark-file5.html 浏览器将显示一个具有两个图片的短HTTP文件。
104报文解读
104规约大致有1997年和2002年（02版）两个版本，在配置上没什么变化，只 4096个，YK最多可配256个，YM最多可配512个。 4个控制域8位位组：前两个是发送序号，后两个是接收序号。 补充说明： 1、报文中的APDU长度指的是除68和APDU长度字节的所有字节。 2、注意长帧报文的“发送序号”与“接收序号”具有抗报文丢失功能。 3常用的类型标识 遥测：09----带品质描述的遥测量，每个遥测值占3个字节 0a----带3个字节时标的且具有品质描述的遥测值，每个遥测值占6个字节 0b---不带时标的标度化值，每个遥测值占3个字节 0c---带3个字节时标的标度化值，每个遥测值占6个字节 0d---带品质描述的浮点值，每个遥测值占5个字节 0e---带3个字节时标且具有品质描述的浮点值，每个遥测值占8个字节 15---不带品质描述的遥测值，每个遥测值占2个字节 遥信：01---不带时标的单点遥信，每个遥信占1个字节 03---不带时标的双点遥信，每个遥信占1个字节 14---具有状态变位检测的成组单点遥信，每个字节包括8个遥信SOE：02---带3个字节短时标的单点遥信 04---带3个字节短时标的双点遥信 1e---带7个字节时标的单点遥信 1f---带7个字节时标的双点遥信 遥脉：0f---不带时标的电度量，每个电度量占5个字节 10---带3个字节短时标的电度量，每个电度量占8个字节 25---带7个字节长时标的电度量，每个电度量占12个字节 其他：2d---单点遥控 2e---双点遥控 2f---双电遥调 64---召唤全数据 65---召唤全电度 67---时钟同步命令 4、常用的传送原因列表： 1---周期、循环 2---背景扫描 3---突发、自发上传
104规约报文解释说明
链路先握手再通信，不握手不通信，通信中断须再握手（建立链路） 确认报文的来回须对方的认可，认可方式可以是一条专用的报文也可以是下一个询问报文中的FCB来暗示 原因传送的信息都必须带上原因，不允许没有理由的传输 地址每个信息量都有一个唯一的不重复的地址 类型每种信息的传输都有不同的功能类型 68 启动符 5D 长度 6C 控制域1 03 控制域2 78 控制域3 00 控制域4 01 遥信 D0 可变结构限定词(信息体个数) 14 00 传送原因 01 00 站地址 01 00 00 信息体地址(点号=信息体地址-起始地址) 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
结构说明: TYP:类型标识,可查表 在监视方向的过程信息 <0> ：= 未定义 <1> ：= 单点信息M_SP_NA_1 <3> ：= 双点信息M_DP_NA_1 <5> ：= 步位置信息M_ST_NA_1 <7> ：= 32比特串M_BO_NA_1 <9> ：= 测量值，归一化值M_ME_NA_1 <11> ：= 测量值，标度化值M_ME_NB_1 <13> ：= 测量值，短浮点数M_ME_NC_1 <15> ：= 累计量M_IT_NA_1 <20> ：= 带状态检出的成组单点信息M_PS_NA_1 <21> ：= 不带品质描述的归一化测量值M_ME_ND_1 <22..29>：= 为将来的兼容定义保留 <30> ：= 带时标CP56Time2a的单点信息M_SP_TB_1 <31> ：= 带时标CP56Time2a的双点信息M_DP_TB_1 <32> ：= 带时标CP56Time2a的步位置信息M_ST_TB_1 <33> ：= 带时标CP56Time2a的32比特串M_BO_TB_1 <34> ：= 带时标CP56Time2a的测量值，归一化值M_ME_TD_1 <35> ：= 带时标CP56Time2a的测量值，标度化值M_ME_TE_1 <36> ：= 带时标CP56Time2a的测量值，短浮点数M_ME_TF_1 <37> ：= 带时标CP56Time2a的累计量M_IT_TB_1 <38> ：= 带时标CP56Time2a的继电保护装置事件M_EP_TD_1 <39> ：= 带时标CP56Time2a的继电保护装置成组启动事件M_EP_TE_1 <40> ：= 带时标CP56Time2a的继电保护装置成组输出电路信息M_EP_TF_1 <41..44>：= 为将来的兼容定义保留 在控制方向的过程信息 类型标识：= UI8[1..8]<45..69> CON <45> ：= 单命令C_SC_NA_1 CON <46> ：= 双命令C_DC_NA_1 CON <47> ：= 步调节命令C_RC_NA_1 CON <48> ：= 设点命令，归一化值C_SE_NA_1 CON <49> ：= 设点命令，标度化值C_SE_NB_1 CON <50> ：= 设点命令，短浮点数C_SE_NC_1 CON <51> ：= 32比特串C_BO_NA_1 <52..57> ：= 为将来的兼容定义保留 在控制方向的过程信息，带时标的ASDU CON <58> ：= 带时标CP56Time2a的单命令C_SC_TA_1 CON <59> ：= 带时标CP56Time2a的双命令C_DC_TA_1 CON <60> ：= 带时标CP56Time2a的步调节命令C_RC_TA_1 CON <61> ：= 带时标CP56Time2a的设点命令，归一化值C_SE_TA_1 CON <62> ：= 带时标CP56Time2a的设点命令，标度化值C_SE_TB_1 CON <63> ：= 带时标CP56Time2a的设点命令，短浮点数C_SE_TC_1 CON <64> ：= 带时标CP56Time2a的32比特串C_BO_TA_1 <65..69> ：= 为将来的兼容定义保留
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服务器向该客户端发送
http协议分析报告实例
HTTP协议分析 1 实验目的 分析HTTP协议报文首部格式，理解HTTP协议工作过程 2 实验内容 截获HTTP报文，分析HTTP协议报文首部格式，学习HTTP协议工作过程。 3 实验原理 超文本传送协议HTTP（HyperText Transfer Protocol）,是万维网客户程序与万维网服务器程序之间的交互所要严格遵守的协议。HTTP是一个应用层协议，它使用TCP连接进行可靠的传送。对于万维网站点的访问要使用的HTTP协议。 HTTP的URL的一般形式是： http://<主机>:<端口>/<路径> WWW采用 B/S 结构，客户使用浏览器在 URL栏中输入 HTTP 请求，即输入对方服务器的地址，向 web 服务器提出请求。如访问师院的机构设置页面 https://www.360docs.net/doc/209374579.html,/jigou/gljg.htm，具体的工作过程如下： (1) 浏览器分析指向页面的URL. (2) 浏览器向DNS请求解析https://www.360docs.net/doc/209374579.html,的IP地址。 (3) 域名系统DNS解析出师院服务器的IP地址 (4) 浏览器与服务器建立TCP连接 (5) 浏览器发出取文件命令：GET /jigou/gljg.htm. (6) 服务器https://www.360docs.net/doc/209374579.html,给出响应，将文件 gljg.htm发送给浏览器。 (7) TCP连接释放。 (8) 浏览器显示“北航机构设置”的页面。 服务器提供的默认端口号为80. 4 实验步骤 步骤 1 在计算机上打开wireshark软件，进行报文截获。 步骤 2 从浏览器上访问https://www.360docs.net/doc/209374579.html,页面，具体操作为打开网页，浏览，关掉网页。 步骤 3 停止wireshark的报文截获，结果命名为http_学号，保存在本机或上 传至服务器目录下。
IEC-60870-5-104报文解析
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- IEC-60870-5-104：应用模型是：物理层，链路层，网络层，传输层，应用层 物理层保证数据的正确送达，保证如何避免冲突。（物理层利用如 RS232上利用全双工） 链路层负责具体对那个slAvE的通讯，对于成功与否，是否重传由链路层控制（RS485 2线利用禁止链路层确认） 应用层负责具体的一些应用，如问全数据还是单点数据还是类数据等（网络利用CSMA/CD等保证避免冲突的发生） --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 基本定义：端口号2404，站端为SErvEr 控端为CliEnt，平衡式传输，2BytE站地址，2BytE传送原因，3BytE信息地址。 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 注：APDU 应用规约数据单元（整个数据）= APCI 应用规约控制信息（固定6个字节）+ ASDU 应用服务数据单元（长度可变） --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- APDU长度（系统-特定参数，指定每个系统APDU的最大长度）APDU的最大长度域为253（缺省）。视具体系统最大长度可以压缩。 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 【1个例子】 104报文分析 BuF序0 1 2 3 4 5 6 7 8 9 .10 11 12 13 14 15 16 17 18 19 20 21 22 M->R：68 1510 0002 001E 01 03 0001 0079 00 00 01 10 01 24 13 D2 0A 02分析的结果是I （主动上报SOE，主动上报是因为104是平衡式规约）报文头固定为0x68，即十进制104 长度15字节（不是6帧的，都是I帧） 发送序号=8【控制字节的解析10 00 02 00 ，发送序号：0010H/2=16/2=8】 接收序号=1 【控制字节的解析10 00 02 00 ，接收序号：0002H/2=2/2 =1】 0x1E=30 即M_SP_TB_1 带长时标的单点信息 01 -> SQ:0 信号个数:1 03 00 -> 传送原因:[ T=0 P/N=0 原因=3 | 突发] 01 00 -> 公共地址:1 79 00 00 -> 0x79=121 信息体地址: 121 01 -> 状态: 1 IV:0 NT:0 SB:0 BL:0 10 01 24 13 D2 0A 02 ->低位10 高位01，即0x0110=1*16*16+16=272 时标: 2002/10/18 19:36:00.272 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 每个字节都为unsignED ChAr类型，如果是2个字节表示1个short型，则都是低位在前，高位在后。 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 【字节0】0x68即十进制数104，68做为BuF第0个字节，下面的说明依次向后排 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 【字节1】15即从字节2到最后的所有字节数（长度） --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 【字节2、3、4、5】这4个字节是4个控制域，对应不同类型的格式（I帧、U帧、S帧），意义和格式都不相同
HTTP请求报文格式
HTTP报文是面向文本的，报文中的每一个字段都是一些ASCII码串，各个字段的长度是不确定的。HTTP有两类报文：请求报文和响应报文。 请求报文 一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。 （1）请求行 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。 HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。这里介绍最常用的GET方法和POST方法。 GET：当客户端要从服务器中读取文档时，使用GET方法。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号（“?”）代表URL 的结尾与请求参数的开始，传递参数长度受限制。例如， /index.jsp?id=100&op=bind。 POST：当客户端给服务器提供信息较多时可以使用POST方法。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据。 （2）请求头部 请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：User-Agent：产生请求的浏览器类型。 Accept：客户端可识别的内容类型列表。 Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。 （3）空行 最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。 （4）请求数据
1、HTTP协议分析
开放式课题 实验报告 实验名称：基于Wireshark软件的HTTP协议分析 学号： 姓名： 指导教师：宫婧 指导单位：理学院
目录 实验目的..........................................................错误！未定义书签。 1) 掌握Wireshark软件使用方法............. 错误！未定义书签。 2）理解HTTP协议工作原理..................................... 错误！未定义书签。 实验任务.................................... 错误！未定义书签。 1) 抓取数据包........................... 错误！未定义书签。 2）分析数据包........................... 错误！未定义书签。实验环境.............................. 错误！未定义书签。软件介绍 (2) 1） wireshark软件简介 (2) 2） wireshark软件的应用 (2) 3） wireshark软件的价值 (2) 4） wireshark软件的操作简介 (3) HTTP协议详解............................... 错误！未定义书签。 1） HTTP协议基础概念....................... 错误！未定义书签。 2） HTTP协议工作流程....................... 错误！未定义书签。 3） HTTP协议请求响应信息 (6) HTTP请求报文信息．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６ HTTP响应报文信息．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．７HTTP数据包分析 (8) 1）网络接口层信息 (10) 2）网络层信息 (11) 3）传输层信息 (12) 4）应用层信息 (13) 总结........................................ 错误！未定义书签。参考文献.. (14)
104规约向IEC61850信息模型转换的研究与实现
收稿日期:20072052301 基金项目:国家自然科学基金资助项目(60574037)1 104规约向IEC 61850信息 模型转换的研究与实现 李 强,朱永利,董志敏 (华北电力大学电气与电子工程学院,河北保定071003) 摘要:面向点的传统规约向面向对象技术的IEC 61850转换是网络技术发展的必然趋势。文章在深入研究 IEC 60870-5-104和IEC 61850协议的基础上,建立了一种兼顾现有系统又遵循IEC 61850的新型电力远动 通信系统网络结构。通过应用XML Schema 技术对协议映射建模这种新的规约映射方法来设计规约转换网关。该转换网关是利用以太网通信、信息建模以及XML 等技术来实现传统通信协议与IEC 61850协议的无缝转换,它具有配制灵活、通用性强的优点。 关键词:IEC 60870-5-104;IEC 61850;XML Schema ;转换网关;无缝通信 中图分类号:TM764 文献标识码:A 文章编号:1007-2691(2008)02-0098-05 Research and implementation of conversion of 104 protocol toward IEC 61850information model L I Qiang ,ZHU Y ong 2li ,Dong Zhi 2min (School of Electrical and Electronic Engineering ,North China Electric Power University ,Baoding 071003,China )Abstract :The conversion of traditional protocol of the dot 2oriented technique toward object 2oriented IEC 61850is an inevitable trend.Based on the in 2depth study on IEC60870-5-104and IEC 61850,a new network architecture of telecontrol communication which puts both the existing system and IEC 61850into consideration is established .Through applying a new protocol mapping method that uses XML Schema technology to model the protocol mapping ,a conversion gateway is designed.The gateway uses the technique of Ethernet Communication ,Information Modeling and XML to realize the seamlessly conversion between the traditional communication protocol and IEC 61850,it is en 2abled to have the characteristics of smart configuration and strong universality. K ey w ords :IEC 60870-5-104;IEC 61850;XML Schema ;conversion gateway ;seamless communication 0 引 言 目前,在我国电力系统远动信息交换中使用较多的是IEC60870-5-104。在新的网络化规约陆续出台的今天,将采用旧通信规约的远动系统纳入新型网络化远动系统的体系结构中,在保持原有系统结构和设备不变的情况下使其与最新的国际标准接轨。这是实现电力系统无缝远动通信 的重要环节。 文章在对IEC60870-5-104和IEC 61850协议进行深入研究的基础上,针对IEC 61850所定义的数据结构和104数据单元格式的特点,提出了104规约向IEC 61850规约进行映射和转换的方法,并详细描述了它基于XML 技术的具体实现过程,为新旧规约之间的转换创造了条件。 1 IEC 60870-5-104标准简介 IEC60870-5-104远动规约(以下简称104规约)的网络参考模型可分为5层:物理层、链 第35卷第2期2008年3月 华北电力大学学报Journal of North China Electric Power University Vol 135,No 12 Mar 1,2008