五、实验过程
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页面，鼠标右键单击看到的照片，将图片另存为到本地
打开 http://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功能了解不够深入
目前待解决
