实验一 应用协议与数据包分析实验

1、冬整言善帝膂泽蜀。6。每1.实验报告内容包括：实验目的、实验内容、实验程序和程序流程图、实验步骤、记录中间结果和最终结果。实验一应用协议与数据包分析实验（使用Wireshark）一、实验目的通过本实验，熟练掌握Wireshark的操作和使用，学习对HTTP协议进行分析。二、实验内容学习HTTP协议，了解HTTP的工作原理和HTTP报文格式。运行 Wireshark，截获 在浏览器访问web界面的报文，并根据截获的报文分析其格式与内容，进一步学 习HTTP协议工作过程。三、实验步骤步骤1：在PC机上运行Wireshark，开始截获报文；步骤2：从浏览器上访问Web界面，如o打开网页，待浏览器的

2、状态栏出现“完毕”信息后关闭网页。步骤3：停止截获报文，将截获的报文命名为http-学号保存。步骤4：分析截获的报文。四、实验结果分析截获的报文，回答以下几个问题：1）综合分析截获的报文，查看有几种HTTP报文？答：两种，一种是请求报文，请求行方法为GET （有一个截去顶端的GET）；另一种 是响应报文。2）在截获的HTTP报文中，任选一个HTTP请求报文和对应的HTTP应答报文，仔细 分析它们的格式，填写表1.1和表1.2。表1.1 HTTP请求报文格式方法GET版本HTTP/1.1URL/r/_utm.gif?utmwv=5.6.3&utms=1&utmn=685315023&ut mhn

3、=alelhddbbhepgpmgidjdcjakblofbmce&utmcs=GBK&ut msr=1366x768&utmsc=24bit&utmul=zhcn&utmje=1&utm fl=17.0%20r0&utmhid=106266808&utmr=-&utmp=%2Fback ground.html&utmht=1427880429790&utmac=UA-295754-2 0&utmcc=_utma%3D76902213.1162881141.1420276890.1 427871656.1427880430.167%3B%2B_utmz%3D76902213.1 4275350

4、92.164.72.utmcsr%3Dalelhddbbhepgpmgidjdcja kblofbmce%7Cutmccn%3D(referral)%7Cutmcmd%3Dreferr al%7Cutmcct%3D%2Fbackground.html%3B&utmjid=715033 423&utmredir=1&utmu=qAAAAAAAAAAAAAAAAAAAAAAE首部字段名字段值字段所表达的信息 HYPERLINK http:/http.host http.host HYPERLINK http:/www.google-analytics.co www.google-报文请求的主机名，

5、允许多个多个域名同处 一个IP地址，即虚拟主机 HYPERLINK http:/http.connecti http.connectionkeep-alive连接方式为保持连接 HYPERLINK http:/http.accept http.acceptimage/webp,*/*;q=0.8浏览器可接受的媒体类型（即客户端可识别 的相应内容类型）为image图片，webp图片 以及全部类型/WebP格式，谷歌（google）开发的一种旨在 加快图片加载速度的图片格式。星号*用于按范围将类型分组，*/*指示可 接受全部类型http.user_age ntMozilla/5.0 (Window

6、s NT6.1; WOW64)AppleWebKit/537.36(KHTML, like Gecko)Chrome/41.0.2224.3Safari/537.36可用的浏览器类型（产生请求的浏览器类型） 为linux浏览器APP，谷歌浏览器，塞班浏览 召器，http.accept_e ncodinggzip, deflate, sdch客户端浏览器可接受的编码压缩格式为 gzip, deflate, sdchhttp.accept_l anguagezh-CN,zh;q=0.8,en-GB;q=0.6,en;q=0.4客户端浏览器可使用的语言为中文，英语*GET方法首部行后面没有实体主体。

7、表1.2 HTTP应答报文格式版本HTTP/1.1状态码200短语OK首部字段名字段值字段所表达的信息 HYPERLINK http:/http.response http.response .lineAccess-Control-All ow-Origin: * HYPERLINK http:/http.date http.dateWed, 01 Apr 2015 09:27:11 GMT*服务器产生并发送响应报文的日期和时间 HYPERLINK http:/http.response http.response .linePragma: no-cache通用头标，发送实现相关的信息 HYP

8、ERLINK http:/http.response http.response.lineExpires: Fri, 01Jan 1990 00:00:00GMT指定实体的有效期为1990年1月1日http.cache_co ntrolno-cache,no-store, must-revalidate*定义缓存指令的通用头标http.last_mod ifiedSun, 17 May 1998 03:00:00 GMT*报文中携带的数据对象最后被修改的日期和时间 HYPERLINK http:/http.response.l http.response.lX-Content-Type-Opt

9、ineions: nosniffhttp.content_ty peimage/gif时艮文类型 HYPERLINK http:/http.server http.serverGolfe2响应报头域包含了服务器用来处理请求的软件为Golfe2，与User-Agent请求报头域相对应http.content_le ngth_header35*消息实体的传输长度*实体主体部分为服务器发送给客户的对象。*查找的资料Content-Length用于描述HTTP消息实体的传输长度。在HTTP协议中，消息实体长度和消息实体的传 输长度是有区别，比如说gzip压缩下，消息实体长度是压缩前的长度，消息实体的传

10、输长度是gzip压缩 后的长度。在具体的HTTP交互中，客户端是如何获取消息长度的呢，主要基于以下几个规则：响应为1xx，204，304相应或者head请求，则直接忽视掉消息实体内容。如果有Transfer-Encoding，则优先采用Transfer-Encoding里面的方法来找到对应的长度。比如说 Chunked 模式。如果head中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。如 果实体长度和传输长度不相等（比如说设置了 Transfer-Encoding），那么则不能设置Content-Length。 如果设置了 Transfer

11、-Encoding，那么Content-Length将被忽视”。这句话翻译的有点饶，其实关键就一 点：有了 Transfer-Encoding，则不能有 Content-Length。通过服务器关闭连接能确定消息的传输长度。（请求端不能通过关闭连接来指明请求消息体的结束， 因为这样可以让服务器没有机会继续给予响应）。这种情况主要对应为短连接，即非keep-alive模式。HTTP1.1必须支持chunk模式。因为当不确定消息长度的时候，可以通过chunk机制来处理这种情况。在包含消息内容的header中，如果有content-length字段，那么该字段对应的值必须完全和消息主 题里面的长度匹

12、配。“The entity-length of a message is the length of the message-body before any transfer-codings have been applied”也就是有chunk就不能有content-length。其实后面几条几乎可以忽视，简单总结后如下：1、Content-Length如果存在并且有效的话，则必须和消息内容的传输长度完全一致。（如果过短则 会截断，过长则会导致超时。）2、如果存在 Transfer-Encoding （重点是 chunked），则在 header 中不能有 Content-Length，有也

13、 会被忽视。3、如果采用短连接，则直接可以通过服务器关闭连接来确定消息的传输长度。（这个很容易懂）结合HTTP协议其他的特点，比如说Http1.1之前的不支持keep alive。那么可以得出以下结论：1、在Http 1.0及之前版本中，content-length字段可有可无。2、在http1. 1及之后版本。如果是keep alive，则content-length和chunk必然是二选一。若是非 keep alive，则和 http1.0 一样。content-length 可有可无。*3）分析在截获的报文中，客户机与服务器建立了几个连接？服务器和客户机分别使用了哪几个端口号？答：4个。服务器使用的端口是80,客户机的临时端口分别是1153、1168、1169、1177, 接收到的响应报文号分别是383、818、819、862。4）综合分析截获的报文，理解HTTP协议的工作过程，将结果填入表1.3中。表1.3 HTTP协议工作过程HTTP客户机端口号HTTP服务器端口号所包括 的报文 号步骤说明117780850TCP第一次握手，客户端发送syn包（syn=j）到服务器，并进 入SYN_SENT状态，等待服务器确认117780853TCP第二次握手，服务器收到syn包，必须确认客户的SYN