HTTP 是一个无状态的协议。无状态 是指客户端 （Web 浏览器）和 服务器之间不 需要建立持久的链接。这 意味着当一个客户端向服务器端发出请求，然后Web 服务器返回响应 ”*”(response) ，连接就被关闭了，在服务器端不保留连接的有关信息 .HTTP 遵 循请求 (Request)/ 应答 (Response) 模型。客户端（Web 浏览器） 向Web 服务器发送请求， Web 服务器处理请求并返回适当的应答。所有 HTTP 连 接都被构造成一套请求和应答。在 该过程中 要经过4 个 阶段，包括建立连接、发送请求信息、发送 响应信息和关闭连接，如下图所示:

　　

　　下面 详细介绍上图中描述的HTTP 工作流程，如下

　　客户端 通过TCP 三次握手与服务器建立连接。

　　TCP 建立连接成功后，向 服务器发送HTTP 请求。

　　服务器 接收客户端的HTTP 请求后，将返回应答，并向客户端发送数据

　　客户端 通过TCP 四次断开，与服务器断开 TCP 连接。

　　在今天的实验中，我们将通过模拟局域网的两台机器之间的数据传输，配置好HFS软件，来抓取和分析HTTP数据。

　　根据实验环境，本实验的步骤如下：

　　1． 配置HFS 软件，获取 HTTP 的 GET数据和POST 数据

　　2． 分析HTTP数据包

　　在 局域网环境中，我们使用一个小工具来实现HTTP 服务器。先在 服务器上配置HFS

　　1 配置HFS软件

　　本地 解压，进入 文件夹，右键以管理员身份运行。如下

　　

　　我们 先配置HFS ，这里能 达到我们的实验 要求，获取到GET 和 POST 数据包即可。点击左上角 的端口 ，输入 端口，这里我们用8080 ， 如下，点击确定

　　

　　在 虚拟文件系统区域，右键，选择“从磁盘 添加目录”， 选择一个真实 存在的目录（此处注意务必是真实存在的 ），弹出 的选择目录类型 中选择”真实 目录” ，此处 我们用桌面的解压缩目录， 可以看到目录 是红色的

　　

　　右键 目录，点击设置”用户名及 密码”， 在弹出的对话框中输入 用户名和密码（demo/demo ）, 点击 确定。

　　

　　在右键 目录，点击”属性”， 选择”上传”sheet页 ，选中 任何人。点击确定，这样我们 就配置好了HFS 工具，可以在 客户端通过浏览器访问了。

　　下面 我们在测试者 机器上，打开Wireshark 抓包工具， 过滤条件输入ip.addr==10.1.1.33 ，然后输入服务器 中HFS给出 的网址，等待 服务器响应。成功 之后，可以在测试者机器的 浏览器上看到页面， 如下：

　　

　　这时候， 我们已经获取 到了HTTP 的 GET *** 。 我们将Wireshark 获取的数据包保存为 HTTP-Get。

　　点击 页面的登录，在对话框中输入用户名密码（demo/demo ），确定 之后等待 服务器响应。成功 如下

　　

　　接下来 ，双击页面的文件夹（等待 服务器响应）， 同时重新启动Wireshark ，等 待页面刷新成功，

　　如 上图，会 在左侧 看到按钮 ，点击”上传”按钮 ，选择 文件，这里我们选择桌面上的“http-post.txt”,点击 上传。等待 服务器响应。提示 上传成功，如下

　　

　　我们保存 抓包文件 ，名字 为HTTP-Post。 任务一，就 到这里。

　　HTTP 由请求和响应 两部分组成，所以对应的也有两种报文格式。下面分别 介绍HTTP 请求报文格式和 HTTP响应 报文格式。

　　HTTP 请求报文格式

　　

　　以上 表格中，第1 行 为“ 请求行” ， 第2 、3、4 行为 “请求 头部”， 第5 行 为空行，第6 行 为“请求 正文”。 下面分别 介绍这4 部分：

　　（1） 请求 行：由3部分组成，分别为：请求 *** 、URL（见备注1）以及协议版本，之间由空格分隔， 请求 *** 包括GET、POST等。 协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1。

　　（2） 请求头部包含很多客户端环境以及请求正文的有用信息。请求头部 由“关键字 ：值”对 组成，每行一堆，关键字和值之间使用英文“：”分隔。

　　（3） 空行，这一行非常重要，必不可少。表示请求头部结束，下面就是请求正文。

　　（4） 请求正文： 可选部分，比如GET 请求就没有请求正文；POST 比如以提交表单数据方式为请求正文。

　　HTTP 响应报文格式

　　

　　以上 表格中，第1 行 为“状态 行” ， 第2 、3、4 行为 “响应 头部”， 第5 行 为空行，第6 行 为“响应 正文”。 下面分别 介绍这4 部分：

　　（1） 状态 行由 由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔。 状态代码为3位数字，200~299的状态码表示成功，300~399的状态码指资源重定向，400~499的状态码指客户端请求出错，500~599的状态码指服务端出错（HTTP/1.1向协议中引入了信息性状态码，范围为100~199）。这里列举几个常见的：

　　状态码

　　说明

　　200

　　响应成功

　　400

　　客户端请求有语法错误，不能被服务器识别

　　404

　　请求资源不存在

　　500

　　服务器内部错误

　　（3） 空行，这一行非常重要，必不可少。表示响应头部结束

　　（4） 响应 正文，服务器返回的文档，最常见的为HTML网页。

　　在HTTP的 请求消息 和应答消息中，都包含头域。头域 分为4 种 ，其中请求 头域和应答头域分别只在请求消息和应答消息中出现，通用头域和实体头域在两种消息中都可以出现，但实体头域只有当 消息中包含了实体数据时 才会出现。下面分别 介绍这4 种 头域中的域名城和功能。

　　HTTP请求头域

　　Header

　　解释

　　Accept

　　指定客户端能够接收的内容类型

　　Accept-Charset

　　浏览器可以接受的字符编码集。

　　Accept-Encoding

　　指定浏览器可以支持的web服务器返回内容压缩编码类型。

　　Accept-Language

　　浏览器可接受的语言

　　Accept-Ranges

　　可以请求网页实体的一个或者多个子范围字段

　　Authorization

　　HTTP授权的授权证书

　　Cache-Control

　　指定请求和响应遵循的缓存机制

　　Connection

　　表示是否需要持久连接。（HTTP 1.1默认进行持久连接）

　　Cookie

　　HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。

　　Content-Length

　　请求的内容长度

　　Content-Type

　　请求的与实体对应的MIME信息

　　Date

　　请求发送的日期和时间

　　Expect

　　请求的特定的服务器行为

　　From

　　发出请求的用户的Email

　　Host

　　指定请求的服务器的域名和端口号

　　If-Match

　　只有请求内容与实体相匹配才有效

　　If-Modified-Since

　　如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码

　　If-None-Match

　　如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变

　　If-Range

　　如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag

　　If-Unmodified-Since

　　只在实体在指定时间之后未被修改才请求成功

　　Max-Forwards

　　限制信息通过 *** 和网关传送的时间

　　Pragma

　　用来包含实现特定的指令

　　Proxy-Authorization

　　连接到 *** 的授权证书

　　Range

　　只请求实体的一部分，指定范围

　　Referer

　　先前网页的地址，当前请求网页紧随其后,即来路

　　TE

　　客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息

　　Upgrade

　　向服务器指定某种传输协议以便服务器进行转换（如果支持）

　　User-Agent

　　User-Agent的内容包含发出请求的用户信息

　　Via

　　通知中间网关或 *** 服务器地址，通信协议

　　Warning

　　关于消息实体的警告信息

　　Accept

　　指定客户端能够接收的内容类型

　　应答 头域只在应答消息中出现，是Web 服务器向浏览器提供的一些状态和要求。如下

　　HTTP 应答头域

　　Header

　　解释

　　Accept-Ranges

　　表明服务器是否支持指定范围请求及哪种类型的分段请求

　　Age

　　从原始服务器到 *** 缓存形成的估算时间（以秒计，非负）

　　Allow

　　对某 *** 资源的有效的请求行为，不允许则返回405

　　Cache-Control

　　告诉所有的缓存机制是否可以缓存及哪种类型

　　Content-Encoding

　　web服务器支持的返回内容压缩编码类型。

　　Content-Language

　　响应体的语言

　　Content-Length

　　响应体的长度

　　Content-Location

　　请求资源可替代的备用的另一地址

　　Content-MD5

　　返回资源的MD5校验值

　　Content-Range

　　在整个返回体中本部分的字节位置

　　Content-Type

　　返回内容的MIME类型

　　Date

　　原始服务器消息发出的时间

　　ETag

　　请求变量的实体标签的当前值

　　Expires

　　响应过期的日期和时间

　　Last-Modified

　　请求资源的最后修改时间

　　Location

　　用来重定向接收方到非请求URL的位置来完成请求或标识新的资源

　　Pragma

　　包括实现特定的指令，它可应用到响应链上的任何接收方

　　Proxy-Authenticate

　　它指出认证方案和可应用到 *** 的该URL上的参数

　　Retry-After

　　如果实体暂时不可取，通知客户端在指定时间之后再次尝试

　　Server

　　web服务器软件名称

　　Set-Cookie

　　设置Http Cookie

　　Trailer

　　指出头域在分块传输编码的尾部存在

　　Transfer-Encoding

　　文件传输编码

　　Vary

　　告诉下游 *** 是使用缓存响应还是从原始服务器请求

　　Via

　　告知 *** 客户端响应是通过哪里发送的

　　Warning

　　警告实体可能存在的问题

　　WWW-Authenticate

　　表明客户端请求实体应该使用的授权方案

　　refresh

　　应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）

　　通用 头域既可以用在 请求消息中，也可以用在应答消息。

　　HTTP通用头域

　　Header

　　解释

　　Cache-Control

　　Cache-Control指定请求和响应遵循的缓存机制，可以附带很多的规定值。

　　Connection

　　表示是否需要持久连接

　　Date

　　表示消息发送的时间

　　Pragma

　　Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache，用于定义页面缓存

　　Trailer

　　表示以Chunked编码传输的实体数据的尾部存在哪些头域

　　Transfer-Encoding

　　WEB 服务器表明自己对本响应消息体（不是消息体里面的对象）作了怎样的编码，比如是否分块（chunked），例如：Transfer-Encoding: chunked

　　Upgrade

　　它可以指定另一种可能完全不同的协议，如HTTP/1.1客户端可以向服务器发送一条HTTP/1.0请求，其中包含值为“HTTP/1.1”的Update头部，这样客户端就可以测试一下服务器是否也使用HTTP/1.1了。

　　Via

　　列出从客户端到 OCS 或者相反方向的响应经过了哪些 *** 服务器，他们用什么协议（和版本）发送的请求。

　　Warning

　　用于警告应用到实体数据上的缓存操作或转换可能缺少语义透明度。

　　只有在请求和应答消息中包含实体数据时， 才需要实体头域。 请求消息中的实体数据是一些由浏览器向web服务器提交的数据，如在浏览器中采用POST方式提交表单时，浏览器就要把表单中的数据封装在请求消息的实体数据部分。应答消息中的实体数据是web服务器发给浏览器的媒体数据，如网页，图片和文档等。实体头域说明了实体数据的一些属性。如下表

　　HTTP实体头域

　　Header

　　解释

　　Allow

　　列出由请求URI标识的资源所支持的 *** 集

　　Content-Encoding

　　说明实体数据是如何编码的

　　Content-Language

　　说明实体数据所采用的自然语言

　　Content-Length

　　说明实体数据的长度

　　Content-Location

　　说明实体数据的资源位置

　　Content-MD5

　　给出实体数据的 MD5值，用于保证实体数据的完整性

　　Content-Range

　　用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度

　　Content-Type

　　用于向接收方指示实体的介质类型，指定 HEAD *** 送到接收方的实体介质类型，或 GET *** 发送的请求介质类型

　　Expires

　　指定实体数据的有效期

　　Last-Modified

　　指定服务器上保存内容的最后修订时间。

　　我们 以HTTP-Get 数据包为例 ，分析GET *** 的HTTP 请求和响应数据包。

　　分析HTTP请求包

　　我们 打开数据包，输入过滤条件ip.addr==10.1.1.33,如下

　　

　　前三个 是TCP 的三次握手，第四个 数据包则是客户端向服务器 发送的HTTP 请求包，我们来学习分析下，

　　

　　HTTP 之前的协议，本次我们 不做讲解， 不懂的同学可以看之前的实验，我们来看下HTTP 协议。

　　Hypertext Transfer Protocol

　　GET / HTTP/1.1\r

　　# 请求行信息

　　Expert Info (Chat/Sequence): GET / HTTP/1.1\r

　　# 专家信息

　　GET / HTTP/1.1\r

　　Severity level: Chat

　　Group: Sequence

　　Request Method: GET # 请求 *** 为 GET

　　Request URI: / # 请求的 URI

　　Request Version: HTTP/1.1 # 请求的版本为HTTP/1.1

　　Host: 10.1.1.33:8080\r

　　# 请求的主机

　　User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0\r

　　# 浏览器类型

　　Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8\r

　　# 请求的类型

　　Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3\r

　　# 请求语言

　　Accept-Encoding: gzip, deflate\r

　　# 请求的编码格式

　　Connection: keep-alive\r

　　# 使用持久连接

　　\r

　　#空行

　　Full request URI: 10.1.1.33:8080/ # 请求的 URI 为10.1.1.33:8080

　　HTTP request 1/8

　　Response in frame: 2770 #应答 是第2770 帧

　　Next request in frame: 2775 # 下一个请求是第2775 帧

　　以上 就是HTTP 请求包的相关信息，可以看到客户端使用HTTP/1.1版本 向服务器发送了GEY 请求，请求 访问10.1.1.33 的 服务器。 将以上 信息填入到报文 格式中，如下

　　GET *** 的HTTP请求报文格式

　　GET

　　空格

　　/

　　空格

　　HTTP/1.1

　　\r

　　Accept

　　:

　　text/html,application/xhtml+xml,application/xml

　　\r

　　…

　　Connection

　　:

　　keep-alive

　　\r

　　\r

　　Full request URI: 10.1.1.33:8080/

　　分析HTTP响应包

　　根据请求包 的信息，我们已经知道， 响应包是第2770 帧 ，下面我们来看下

　　

　　在HTTP 之前，我们看到了 下图显示的，TCP重组 片段， 这些片段共有2270 个 字节，由于超过 了TCP 数据包的更大数据分段（MSS ），所以将数据在TCP 层进行了分段。 从下面 的信息，可以看到 分断后的数据包及包大小，如#2767 （247 ）， 其中2767 表示 帧号，大小 为247 个 字节。

　　

　　下面 来看HTTP 的具体 部分

　　Hypertext Transfer Protocol

　　HTTP/1.1 200 OK\r

　　# 响应行信息

　　Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r

　　#专家 信息

　　HTTP/1.1 200 OK\r

　　#HTTP 响应信息，响应码为200

　　Severity level: Chat

　　Group: Sequence

　　Request Version: HTTP/1.1 # 请求吧

　　Status Code: 200 # 状态码

　　Response Phrase: OK # 响应短语

　　Content-Type: text/html\r

　　# 响应的内容类型

　　Content-Length: 2023\r

　　#包 的长度

　　Content length: 2023

　　Accept-Ranges: bytes\r

　　#服务器支持 的请求：字节

　　Server: HFS 2.3 beta\r

　　# 服务器类型

　　Set-Cookie: HFS_SID=0.248448607278988; path=/; \r

　　# 设置 Http Cookie

　　Cache-Control: no-cache, no-store, must-revalidate, max-age=-1\r

　　# 缓存控制

　　Content-Encoding: gzip\r

　　# 实体数据的压缩格式

　　\r

　　# 空行

　　HTTP response 1/8 #HTTP 响应

　　Time since request: 0.015248000 seconds # 响应使用的时间

　　Request in frame: 2763 # 请求的帧号为2763

　　Next request in frame: 2775 # 下一个请求 的 帧号2775

　　Next response in frame: 2778 #下一个响应 的帧号是2778

　　Content-encoded entity body (gzip): 2023 bytes -> 4375 bytes #内容 编码（gzip ）

　　Line-based text data: text/html # 基于行的文本数据

　　根据 以上信息，可以知道服务器使用HTTP/1.1 200 OK 响应了 客户端的请求。将信息 填入到报文格式中，如下

　　GET *** 的HTTP响应报文格式

　　HTTP/1.1

　　空格

　　200

　　空格

　　OK

　　\r

　　Content-Type

　　:

　　text/html

　　\r

　　…

　　Content-Encoding

　　:

　　gzip

　　\r

　　\r

　　省略

　　分析HTTP请求包

　　下面 我们以HTTP-Post 为例，分析 POST *** 的 HTTP 请求和响应。打开 数据包，输入过滤条件ip.addr==10.1.1.33, 显示 出的HTTP 中，Info列中还有POST 的即可 ，如下

　　

　　我们 展开分析下

　　Hypertext Transfer Protocol #HTTP 协议

　　POST /hfs2_3b287/ HTTP/1.1\r

　　# 请求行

　　Expert Info (Chat/Sequence): POST /hfs2_3b287/ HTTP/1.1\r

　　#专家 信息

　　POST /hfs2_3b287/ HTTP/1.1\r

　　Severity level: Chat

　　Group: Sequence

　　Request Method: POST # 请求 *** 为 POST

　　Request URI: /hfs2_3b287/ # 请求 的URI

　　Request Version: HTTP/1.1 #请求 的版本

　　Host: 10.1.1.33:8080\r

　　# 使用的主机

　　User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0\r

　　# 使用的浏览器类型

　　Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8\r

　　# 浏览器接受的类型

　　Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3\r

　　# 希望使用的语言

　　Accept-Encoding: gzip, deflate\r

　　# 可使用的编码格式，这里是 gzip 和 deflate

　　Referer: 10.1.1.33:8080/hfs2_3b287/\r

　　#从 包含的URL 页面发起请求

　　Cookie: HFS_SID=0.248448607278988\r

　　#Cookie信息

　　Cookie pair: HFS_SID=0.248448607278988

　　Authorization: Basic ZGVtbzpkZW1v\r

　　#授权 证书信息

　　Credentials: demo:demo # 登录的用户名密码

　　Connection: keep-alive\r

　　# 使用持久连接

　　Content-Type:multipart/form-data;boundary=---------------------------54542580413055\r

　　# 请求的内容类型

　　Content-Length: 367\r

　　# 包的长度

　　Content length: 367

　　\r

　　# 空行

　　Full request URI: 10.1.1.33:8080/hfs2_3b287/ # 请求的 URI 为10.1.1.33:8080/hfs2_3b287

　　HTTP request 1/6

　　Response in frame: 3800 # 响应的帧号

　　Next request in frame: 3802 # 下一个请求的 正好

　　以上 就是使用POST *** 的 HTTP 请求包，可以看到请求的连接及登录的用户名密码等。将上面 的信息填入到报文格式中，如下

　　POST *** 的HTTP请求报文格式

　　POST

　　空格

　　/hfs2_3b287/

　　空格

　　HTTP/1.1

　　\r

　　Accept

　　:

　　text/html,application/xhtml+xml,application/xml

　　\r

　　…

　　Content-Length

　　:

　　367

　　\r

　　\r

　　忽略

　　另外 ，我们 在HTTP 的下面，看到了如下的内容

　　

　　类型 的Multipart/form-data 是上传文件的一种方式。 Multipart/form-data 其实就是浏览器用表单上传文件的方式。最常见的情境是：在写邮件时，向邮件后添加附件，附件通常使用表单添加，也就是用 multipart/form-data 格式上传到服务器。我们 实验中向 服务器上传了一个文件，所以就是此类型。

　　在 看Wireshark中 的使用

　　首先看wireshark 中字段与 Multipart/form-data 的对应关系： MIME Multipart Media Encapsulation ：代表整个 Multipart/form-data 上传文件中的数据。

　　Encapsulated multipart part ：代表表单中不同部分的数据。

　　Boundary ：用来隔开表单中不同部分的数据。

　　其次，

　　1) MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---------------------------54542580413055"

　　这行指出这个请求是 multipart/form-data 格式的，且 boundary 是 “----------54542580413055” 这个字符串。

　　2 ）关于 Boundary ： Boundary ：用来隔开表单中不同部分的数据。实际上，每部分数据的开头都是由 “--”+boundary 开始的（这是 MIME 标准中讲述的标准内容）。

　　3 ） Encapsulated multipart part ：紧跟着 boundary 的是该部分数据的描述：

　　Content-Dispostion:form-data;name="Filename"\r

　　每一个 part 至少一个 name 和一个 content 部分。

　　可以从 上面的multipart/form-data中 ，看到我们上传的文本名字为http-post.txt， 内容为“This is demo for HTTP POST”。

　　分析HTTP响应包

　　根据Wireshark 现实的响应包帧数，我们来看下第3800 帧 。

　　

　　Hypertext Transfer Protocol #HTTP 协议

　　HTTP/1.1 200 OK\r

　　# 响应行

　　Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r

　　#专家 信息

　　HTTP/1.1 200 OK\r

　　# 响应信息

　　Severity level: Chat

　　Group: Sequence

　　Request Version: HTTP/1.1 # 请求版本

　　Status Code: 200 # 状态码

　　Response Phrase: OK #响应 短语

　　Content-Type: text/html\r

　　# # 响应包类似

　　Content-Length: 570\r

　　# 响应包长度

　　Content length: 570

　　Accept-Ranges: bytes\r

　　#服务器支持 的请求：字节

　　Server: HFS 2.3 beta\r

　　#web 服务器类型

　　Content-Encoding: gzip\r

　　# 实体数据的压缩格式

　　\r

　　#空行

　　HTTP response 1/6 # 响应

　　Time since request: 0.008774000 seconds # 响应请求的时间

　　Request in frame: 3798 #请求 的帧号

　　Next request in frame: 3802 # 下一个请求的帧号

　　Next response in frame: 3804 # 下一个响应的 帧号

　　Content-encoded entity body (gzip): 570 bytes -> 866 bytes #内容 编码（gzip ）

　　Line-based text data: text/html # 文本内容

　　以上 就是POST *** 的 HTTP 响应包，可以看到服务器向客户端发送了 HTTP/1.1 200 OK响应 了HTTP 请求包。服务器类型为HFS 2.3 beta， 将数据填入到报文格式中

　　POST *** 的HTTP响应报文格式

　　HTTP/1.1

　　空格

　　200

　　空格

　　OK

　　\r

　　Server

　　:

　　HFS 2.3 beta

　　\r

　　…

　　Content-Encoding

　　:

　　gzip

　　\r

　　\r

　　省略

　　实验中我们 讲解了 主要的GET和POST *** ， 可以抓包 考虑， 学习其他的 *** ，动手提高能力 。

　　本文涉及相关实验：Wireshark数据抓包分析之HTTP协议