五、实验过程
1.安装并启动Wireshark。
选择菜单栏上捕获->选项,勾选WLAN网卡。点击Start,进行抓包
Wireshark处于抓包状态中
2.打开浏览器,在地址栏中输入教师指定的web服务器地址。(http://202.113.78.39)
为了确保连通性,先ping一下服务器 打开cmd Ping 202.113.78.39
网址登录失败。更换网址,进行实验 Ping image.baidu.com
ping百度网址以获得百度ip来对抓包进行限制
3. 打开153.3.237.235页面,鼠标右键单击看到的照片,将图片另存为到本地
打开一张图片,将图片另存为到本地。
鼠标单击照片,待页面改变后,关闭浏览器,停止Wireshark抓包
4.所抓到数据包的种类如下:
TCP,HTTP,HTTP/JSON, TLSv1.2,TLVd1.3,DNS,MDNS,NBNS,SSL,UDP,IGMPv2,ARP,ICMPv6,
5.列表写出客户端、网关、web 服务器的 IP 地址和 MAC 地址。HTTP 客户端和服务器段的端口号
cmd ipconfigz 找到客户端IP的地址和网关
根据客户端IP的地址和网关,在Wireshark中找到相对应的MAC地址和HTTP 客户端和服务器段的端口号
Client | Gateway | Server | |
IP | 192.168.0.199 | 192.168.0.1 | 153.3.238.102 |
MAC | ec:63:d7:d7:7c:74 | 50:0f:f5:34:b0:e0 | 50:0f:f5:34:b0:e0 |
Port# | 49961 | ------------------------ | 443 |
6. 将TCP、IP、HTTP 和 Ethernet 的首部字段的名字和值按照协议的格式分别记录下来
访问指定服务器的第一个 HTTP 请求报文格式:
请求行 | GET/HTTP/1.1\r\n |
首部行 | 值 | |
Host | 153.3.237.235\r\n | |
Connection | : | keep-alive\r\n |
Upgrade-Insecure-Requests: | : | 1\r\n |
User-Agent: | : | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.67\r\n |
Accept | : | text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\r\n |
Accept-Encoding | : | gzip, deflate\r\n |
Accept-Language | : | zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6\r\n |
服务器返回的第二个 HTTP 响应报文格式:
状态行 | HTTP/1.1 200 OK\r\n |
首部行 | 值 | |
Response Version | : | HTTP/1.1 |
Status Code | : | 200 |
Response Phrase | : | OK |
Access-Control-Allow-Credentials | : | true\r\n |
Access-Control-Allow-Origin: | : | https://m.baidu.com,https://www.baidu.com,http://m.baidu.com,http://www.baidu.com\r\n |
Connection | : | keep-alive\r\n |
Content-Encoding | : | gzip\r\n |
Content-Type | : | text/html; charset=UTF-8\r\n |
Date | : | Thu, 12 Oct 2023 15:14:33 GMT\r\n |
任意一个UDP报文首部:
源端口号49668 | 目的端口号8000 |
UDP长度514 | UDP检验和0xc7c5 |
与服务器建立连接的第二次握手的 TCP 报文格式:
源端口:80 | 目的端口:49989 | |||||||
序号:0 | ||||||||
确认号:16 | ||||||||
数据偏移:0 | 保留:000 | URG:0 | ACK:1 | PSH:0 | RST:0 | SYN:1 | FIN:0 | 窗口:8192 |
校验和:0x71ca | 填充:0 |
浏览器跳转到第二个Web页面的IP包首部:
版本:4 | 头部长度:20 bytes | 服务类型:0x00 | 总长度:52 | |
标识符:0x0000 | 标志:0x2 | 片位移:0 | ||
存活时间:53 | 上层协议:TCP | 报头校验和:0xbd04 | ||
源IP地址:157.148.41.188 | ||||
目的IP地址:192.168.0.199 |
任意802.3帧头
50:0f:f5:34:b0:e0 | ec:63:d7:d7:7c:74 | 0800 | -------------- | ------------ |
7.在Wireshark界面上,设置抓包后的过滤条件只显示IP地址包括web服务器地址的包(筛选格式类似“ip.addr eq 202.113.78.39”)
筛选条件为:
筛选结果为:
8. 在 Wireshark 界面上分别圈出 TCP 建立连接和释放连接的数据包。(抓图展示)
建立连接过程为:
释放连接过程为:
1
2
3
4
9.在 Wireshark 界面上圈出你的主机如何找到 Web 服务器的 MAC 地址(ARP 协议)或者 IP 地址(DNS 协议)
10. 依据实际抓到的数据包,截图并圈出 TCP 顺序号和确认号的使用方法及变化规律。
Wireshark 中默认使用的是相对顺序号,本步骤中选择 Wireshark 菜单栏中
的 Edit -> Preferences ->protocols ->TCP,去掉 Relative sequence number 后面
勾选框中的√。
去掉前
去掉后
规律:Wireshark通常显示的都是相对序列号/确认号,而不是实际序列号/确认号,相对序列号/确认号是和TCP会话的初始序列号相关联的。在实际中,比起真实序列号/确认号,跟踪更小的相对序列号/确认号会相对容易一些
11.在所抓到的各种类型数据包中,在Wireshark的主界面上是以下底纹标注
12. 尝试使用 Statistics 菜单中“IO graph”、“HTTP”、“Protocol Hierarchy” 等功能,并记录结果
-
IO graph
统计->I/O图表
显示过滤器的配置:在Display filter项内输入需要配置的显示过滤器(不配置显示过滤器就是显示所有的数据包),然后勾选上前面的对勾就可显示图表
IO Graphs应用
1)测量设备之间的吞吐量:
显示过滤器:ip.addr eq153. and ip addr eq 192.168.0.199
2) 可将数据复制到excel表格,再利用excel进行绘图
HTTP统计信息
1)分组计数器
2)请求:主机请求访问Web站点的分布情况,以及所访问的Web站点的具体资源。
3)负载分配:HTTP数据包(请求和响应)访问过哪些站点。
4)请求序列
5)协议分级
6)端点
此工具用来观察第二、三、四层端点(Ethernet端点、IP端点、TCP/UDP端点)有关的统计信息。
15. 找到全部 HTTP 的请求消息并截图。(过滤条件类似“http.request and ip.addr eq 202.113.78.39”)
过滤条件:
过滤结果:
16. 找到全部源 IP 地址为指定 web 服务器地址的 HTTP 响应消息并截图
17. 查看你访问指定 Web 服务器 HTTP 会话的工作过程。将结果截图,并对前 10 个包进行详细分析。
统计->流量图
限制显示过滤器,TCP
每行代表一个单独的TCP包,左边列显示时间,中间列显示包的方向、TCP端口、段长度和设置的标志位,右边列以10进制的方式显示相关序列号/确认号。我们可以利用这个流图更好的理解序列号和确认号是如何工作的。序列号为当前端成功发送的数据位数,确认号为当前端成功接收的数据位数,SYN标志位和FIN标志位也要占1位
包1:TCP会话的每一端的序列号都从0开始,同样的,确认号也从0开始,因为此时通话还未开始,没有通话的另一端需要确认
包2:同包1
包3:服务端响应客户端的请求,响应中附带序列号0和相对确认号1(表明服务端收到了客户端发送的包1中的SYN)
包4:同包3
包5:客户端使用确认号1响应服务端的序列号0,同时响应中也包含了客户端自己的序列号(由于服务端发送的包中确认收到了客户端发送的SYN,故客户端的序列号由0变为1)此时,通信的两端的序列号都为1,通信两端的序列号增1发生在所有TCP会话的建立过程中
包6:同包5
包7:第一个携带有效数据的包(即客户端发送的HTTP请求),序列号和确认号保持1不变,因为客户端没有从服务端接收到任何数据,包中有效数据的长度为482字节
包8:当上层处理HTTP请求时,服务端发送该包来确认客户端在包7中发来的数据,确认号的值增加了482(482是包7中有效数据长度),变为483。服务端告知客户端总共收到了482字节的数据.服务端的序列号保持为1不变
包9:标志着服务端返回HTTP响应的开始,该包带有1400字节的有效数据
包10:同包9
18. 使用Follow TCP Stream功能,将下载的文件从收到的HTTP响应消息数据包中恢复出来
Http 进行过滤
上传文件提交可以使用post一个表单的形式
19.回答下列问题
1)简述访问 web 页面的过程
- 输入URL
- DNS域名进行解析,解析出网站的IP地址
- 客户端与服务器建立TCP连接
- 客户端发送HTTP请求
- 服务器进行响应,将内容发给客户端
- 释放TCP连接
2)找出 DNS 解析请求、应答相关分组,传输层使用了何种协议,端口号是多少?所请求域名的 IP 地址是什么?
DNS请求分组:基于UDP的传输协议,源端口号是57931,目的端口号是53,所请求IP地址:111.206.209.249
DNS应答分组:源端口号是53,目的端口号是57931
3) 针对 TCP 连接,该 TCP 连接的四元组是什么?双方协商的起始序号是什么?TCP 连接建立的过程中,第三次握手是否带有数据?是否消耗了一个序号?
四元组为: 源IP地址: ;源端口号: ;
目的IP地址: ;目的端口号: ;
双方协商的起始序号是0;
第三次握手后,seq和ack都为1.第三次报文没有消耗序号,没有带数据
4) 找到 TCP 连接的释放过程,绘出 TCP 连接释放的完整过程,注明每个 TCP 报文段的序号、确认号、以及 FIN\ACK 的设置。
第一个TCP报文段:seq=2497, ack=6147, FIN:set, ACK:set
第二个TCP报文段:seq=6147, ack=2498, FIN:not set, ACK:set
第三个TCP报文段:seq=6178, ack=2498, FIN:set, ACK:set
第四个TCP报文段:seq=2498, ack=6178, FIN:not set, ACK:set
5)针对 TCP 连接释放,请问释放请求由服务器还是客户发起?FIN 报文段是否携带数据,是否消耗一个序号?FIN 报文段的序号是什么?为什么是这个值?
释放请求是服务端发起的;
FIN报文段不携带数据,消耗一个序号;
FIN报文段的序号是6147,此报文前的一个报文确认号为2498,是前一个传送数据最后一个字节的序号
6)在该 TCP 连接的数据传输过程中,找出每一个 ACK 报文段与相应数据报文段的对应关系,计算这些数据报文段的往返时延 RTT(即 RTT 样本值)。
报文段往返时间RTT 新的RTTs=(1-a)*(旧的RTTs)+a*(新的RTT样本值)
新的RTTD=(1-b)*(旧的RTTD) +b*|RTTs-新的RTT样本|
7)请描述 HTTP 协议的持续连接的两种工作方式。访问这些页面(同一网站的不同页面)的过程中,采用了哪种方式
- 流水线方式:客户在收到 HTTP 的响应报文之前就能接着发送新的请求报文;
- 非流水线方式:客户在收到前一个响应后才能发出下一个请求;
采用的是流水线方式
六、结论与分析
遇到的问题1:
Ping 202.113.78.39 出现数据包100%丢失
Ping出网络丢包原因:
- 物理线路故障
- 设备故障
- 网络拥塞
于是,更换网址,重新进行实验 Ping image.baidu.com
遇到的问题2:Wireshark界面中不显示IP协议
原因:tcp报文正是基于ip协议的,tcp是传输层协议,而ip是它底下的网络层协议
遇到的问题3:显示各种类型数据包在Wireshark的主界面底纹标注颜色
解决方法:与其他同学探讨,发现更简便的方法
视图->着色规则
遇到的问题4:在大量数据中,TCP的三次握手和四次挥手较为难找
解决方法:借助流量图等功能帮助寻找
遇到的问题5:无法成功恢复下载的文件
原因:对Follow TCP Stream功能了解不够深入
目前待解决
标签:HTTP,报文,TCP,实验,序列号,客户端,抓包,Wireshark From: https://blog.csdn.net/qq_61012545/article/details/142455233