HNU-计算机网络-实验1-应用协议与数据包分析实验(Wireshark)
计算机网络 课程基础实验一
应用协议与数据包分析实验(Wireshark)
计科210X 甘晴void 202108010XXX
一、实验目的：
通过本实验，熟练掌握Wireshark的操作和使用，学习对HTTP协议进行分析。
二、实验内容
2.1 HTTP 协议简介
HTTP 是超文本传输协议 （Hyper Text Transfer Protocol）的缩写，用于WWW 服务。
（1）HTTP 的工作原理
HTTP 是一个面向事务的客户服务器协议。尽管HTTP 使用TCP 作为底层传输协议，但 HTTP 协议是无状态的。也就是说，每个事务都是独立地进行处理。当一个事务开始时，就在web客户和服务器之间建立一个TCP 连接，而当事务结束时就释放这个连接。此外，客 户可以使用多个端口和和服务器 （80 端口）之间建立多个连接。其工作过程包括以下几个阶段。
① 服务器监听TCP 端口 80，以便发现是否有浏览器 （客户进程）向它发出连接请求；
② 一旦监听到连接请求，立即建立连接。
③ 浏览器向服务器发出浏览某个页面的请求，服务器接着返回所请求的页面作为响应。
④ 释放TCP 连接。
在浏览器和服务器之间的请求和响应的交互，必须遵循HTTP 规定的格式和规则。
当用户在浏览器的地址栏输入要访问的HTTP 服务器地址时，浏览器和被访问HTTP 服
务器的工作过程如下：
① 浏览器分析待访问页面的URL 并向本地DNS 服务器请求IP 地解析；
② DNS 服务器解析出该HTTP 服务器的IP 地址并将IP 地址返回给浏览器；
③ 浏览器与HTTP 服务器建立TCP 连接，若连接成功，则进入下一步；
④ 浏览器向HTTP 服务器发出请求报文 （含GET 信息），请求访问服务器的指定页面；
⑤ 服务器作出响应，将浏览器要访问的页面发送给浏览器，在页面传输过程中，浏览
器会打开多个端口，与服务器建立多个连接；
⑥ 释放TCP 连接；
⑦ 浏览器收到页面并显示给用户。
（2）HTTP 报文格式
HTTP 有两类报文：从客户到服务器的请求报文和从服务器到客户的响应报文。图 5.46
显示了两种报文的结构。
在图1.1 中，每个字段之间有空格分隔，每行的行尾有回车换行符。各字段的意义如下：
① 请求行由三个字段组成：
-
方法字段，最常用的方法为 “GET”，表示请求读取一个万维网的页面。常用的方法还有 “HEAD（指读取页面的首部）”和“POST（请求接受所附加的信息）
-
URL 字段为主机上的文件名，这时因为在建立TCP 连接时已经有了主机名
-
版本字段说明所使用的HTTP 协议的版本，一般为 “HTTP/1.1”
② 状态行也有三个字段：
-
第一个字段等同请求行的第三字段
-
第二个字段一般为 “200”，表示一切正常，状态码共有41 种，常用的有：301 （网站已转移），400（服务器无法理解请求报文），404（服务器没有锁请求的对象）等
-
第三个字段时解释状态码的短语
③ 根据具体情况，首部行的行数是可变的。请求首部有Accept 字段，其值表示浏览器 可以接受何种类型的媒体；Accept-language，其值表示浏览器使用的语言；User-agent 表明可用的浏览器类型。响应首部中有Date、Server、Content-Type、Content-Length 等字段。在请求首部和响应首部中都有 Connection 字段，其值为Keep-Alive 或 Close，表示服务器在传送完所请求的对象后是保持连接或关闭连接。
④ 若请求报文中使用 “GET”方法，首部行后面没有实体主体，当使用 “POST”方法时，附加的信息被填写在实体主体部分。在响应报文中，实体主体部分为服务器发送给客户的对象。
图1.2 和图1.3显示了捕获的HTTP 请求和响应报文，结合上面的介绍，请自己分析和体会。
2.2实验环境与说明
（1）实验目的
在PC 机上访问Web 页面，截获报文，分析HTTP 协议的报文格式和HTTP协议的工作过程。
（2）实验设备和连接
本地实验室环境，无须设备连接；
注意：请通过访问可以连接的WWW 站点或使用IIS 建立本地WWW 服务器来进行实验。
（3）实验分组
每四名同学为一组，每人一台计算机独立完成实验。
2.3实验步骤
步骤1：在PC 机上运行Wireshark，开始截获报文；
步骤2：从浏览器上访问Web 界面(http://csee.hnu.edu.cn)。打开网页，待浏览器的状态栏出现 “完毕”信息后关闭网页。
步骤3：停止截获报文，将截获的报文命名为http-学号保存。
分析截获的报文，回答以下几个问题：
1）综合分析截获的报文，查看有几种HTTP 报文？
有TCP,DNS,ARP,HTTP,SSL,ICMPV6,TLSv1.3等报文
2）在截获的HTTP 报文中，任选一个HTTP 请求报文和对应的 HTTP 应答报文，仔细分析它们的格式，填写表1.1 和表1.2。
▲请求报文截图：
表1.1 HTTP 请求报文格式：
方法：GET
版本：HTTP/1.1
URL： /favicon.ico
| 首部字段名 | 字段值 | 字段所表达的信息 |
|---|---|---|
| Host | csee.hnu.edu.cn | 接收请求的主机名 |
| Connection | keep-alive | 连接 |
| User-Agent | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36 | 表明可用的浏览器类型，这里使用的是GoogleChrome浏览器。 |
| Accept | image/avif,image/webp,image/apng,image/svg+xml,image/,/*;q=0.8 | 描述接收响应数据的数据类型，q表示相对质量因子，指示接收数据类型的优先级 |
| Referer | http://csee.hnu.edu.cn/ | 提供访问来源信息，即从那里来到的这个页面 |
| Accept-Encoding | gzip, deflate | 表示客户端可处理的压缩编码 |
| Accept-Language | zh-CN,zh;q=0.9 | 接收的语言类型 |
▲回复报文截图：
表1.2 HTTP 应答报文格式 ：
版本：HTTP/1.1
状态码：200
短语：OK
| 首部字段名 | 字段值 | 字段所表达的信息 |
|---|---|---|
| Date | Thu, 12 Oct 2023 05:23:46 GMT | 响应时间 |
| Server | ********* | 服务器应用程序 |
| X-Frame-Options | SAMEORIGIN | 表示该页面可以在相同域名页面的frame中展示（即可以在同域名页面的frame中嵌套） |
| Cache-Control | no-store | 指定不缓存响应，表明资源不进行缓存 |
| Pragma | no-cache | 在 HTTP/1.1 协议中，它的含义和 Cache-Control:no-cache 相同 |
| Expires | Thu, 01 Jan 1970 00:00:00 GMT | 过期时间 |
| Content-Type | image/gif;charset=UTF-8 | 实体的内容类型 |
| Content-Length | 0 | 实体的字节大小 |
| Set-Cookie | JSESSIONID=B3F69D4683D77B4FA0BBD8B423973CED; Path=/; HttpOnly | cookie值 |
| Keep-Alive | timeout=5, max=99 | 持续连接的参数 |
| Connection | Keep-Alive | 建立持续链接 |
| Content-Language | zh-CN | 实体的语言 |
3）分析在截获的报文中，客户机与服务器建立了几个连接？服务器和客户机分别使用 了哪几个端口号？
★菜单栏“编辑”，“首选项”，“外观”，“列”中添加两项，就可以查看端口和端口号了。这一步灵感来源于https://blog.csdn.net/h1580824951/article/details/120333571
按照以上方式可得到所有HTTP报文对应的端口号
答案如下：
客户机与服务器建立了7个连接，
服务器使用的都是端口号80，
用户机使用了端口号51900，52004，52008，52017，52019，52018，52032
其中三次使用52008是TCP的三次握手
4 ）综合分析截获的报文，理解HTTP 协议的工作过程，将结果填入表1.3 中。
实际上，由于我的页面打开初始是www.baidu.com，所以上面的初始一部分实际上在跟www.baidu.com进行通讯。我略去这一过程，只关注与http://csee.hnu.edu.cn进行通讯的过程。
注意到这里报文类型实际上也是一个需要关注的点，故加入这一列。另由于端口过多，只关注部分端口（尤其是端口52019，另外的52108、52107与这个类似）的连接与断开。
| HTTP客户机端口号 | HTTP服务机端口号 | 所包括的报文号 | 报文类型 | 步骤说明 |
|---|---|---|---|---|
| 58508 | 53 | 10337 | DNS | 请求报文 |
| 53 | 58508 | 10352 | DNS | DNS响应报文，返回域名对应的IP地址 |
| 52008 | 80 | 10477 | TCP | SYN报文，请求建立与服务器的连接 |
| 80 | 52008 | 10479 | TCP | SYN ACK报文，允许客户与服务器建立连接 |
| 52008 | 80 | 10480 | TCP | 对SYN ACK的确认，连接已建立 |
| 52008 | 80 | 10481 | HTTP | 对网页的请求报文 |
| 80 | 52008 | 10488 | HTTP | 响应报文 |
| 52019 | 80 | 13629 | HTTP | 请求报文 |
| 80 | 52019 | 13707 | HTTP | 响应报文 |
| 52019 | 80 | 13708 | TCP | ACK报文 |
| 80 | 52019 | 13709 | TCP | FIN ACK报文（服务端发的第一个释放连接的请求） |
| 52019 | 80 | 13710 | TCP | ACK报文（客户端给服务端回应确认消息） |
| 52019 | 80 | 13711 | TCP | FIN ACK报文（客户端发给服务端释放连接的请求） |
| 80 | 52019 | 13727 | TCP | RST报文（本来应该是ACK表示服务端发确认消息，这里是连接突然终止了） |
上面只重点列出了一个TCP连接的建立和释放的过程，其他两个连接是类似的，以上报文体现了HTTP的工作过程。
特别需要指出的是：典型的关闭请求，有时由客户端发起中断连接。但在这里的关闭请求由服务端发起，即http://csee.hnu.edu.cn主动发起并请求中断TCP连接。
★中间解题过程与截图如下：
DNS部分略
TCP三次握手建立连接
52017，52018，52019端口的结束报文
52019端口：RST报文
52019端口：正常传输
52019端口：四次挥手中的前三次
知识补充：三次握手与四次挥手
三次握手
四次挥手
最后的四次挥手原理讲解可以参考如下的讲解
https://blog.csdn.net/weixin_41033105/article/details/123861500
https://blog.csdn.net/m0_52650621/article/details/127797022
三次握手
第一次握手：这是客户端发起给服务器的报文，用于请求建立连接。
第二次握手：这是服务器回复给客户端的报文，用于确认并同意连接请求。
第三次握手：是客户端发给服务器的，是对上一个同意连接请求的确认。
四次挥手
第一次挥手：当数据传输首先结束的端（比如客户端），会率先发起结束断开连接的请求。
第二次挥手：对上一个断开连接请求的报文进行确认。并同时，停止接受数据。
第三次挥手：服务器端也结束数据发送了，所以也会发起一个断开连接的请求。
第四次挥手：是客户端对服务器断开连接请求的进行确认。