Posts 使用WireShark抓包分析一个网页的加载
Post
Cancel

使用WireShark抓包分析一个网页的加载

一、 抓取

加载的网页是西安交通大学主页:

  • 域名: www.xjtu.edu.cn
  • IP: 202.117.1.13
  • 应用层协议: http

抓包过程和过滤规则:

  • 开始抓包后立即刷新网页, 网页加载完毕后立即停止抓包
  • 过滤规则为tcp, 即抓取整个过程的所有包含tcp协议的包

下面是抓取结果

抓取结果

TCP/IP有关知识, 可以从这里找到一些参考: tcp/ip概览

二、 分析

大致浏览抓到的24个包, 其中有http协议,也有纯tcp协议、没有添加http内容的包

TCP的连接管理: “握手”与”挥手”

有两个TCP连接?

目光聚焦于前6个包

这6个tcp包明显是”三次握手”的过程, 不过被分为了两组

检查一下即可发现, 只是本地端口有一点区别; 此外, 根据先后顺序也可以断定, 这是为了同一个组网页请求而同时发出的两个TCP”握手信号”

并且检查结尾的”四次挥手”, 也是两组同时进行

也就是说: 这两个TCP连接贯穿整个对网页的请求过程(因为HTTP/1.1默认采用持久连接)

这样并发的连接, 我猜测是为了保证服务质量, 如果一个TCP连接出了问题, 还可以立刻转到另外一个

分析”三次握手”

我们选取分组1,3,5作为”三次握手”的分析对象

第一步: 主机SYN=1 Sequence Number=x

从截图我们可以看到分组1中:

  • SYN标志位为1
  • Sequence Number为3356114380

第二步: 主机SYN=1 ACK=1 Sequence Number=y Acknowledgement Number=x+1

从截图我们可以看到分组3中:

  • SYN标志位为1
  • Sequence Number为2320446697
  • ACK标志位为1
  • Acknowledgement Number为3356114381=3356114380+1

第三步: 主机ACK=1 Acknowledgement Number=y+1

从截图我们可以看到分组3中:

  • ACK标志位为1
  • Acknowledgement Number为2320446698=2320446697+1

分析”四次挥手”

非常有意思的是, 虽说是”四次挥手”, 我却只能抓到三个包

说好的四次呢?

好家伙, 原来是FIN和ACK合一块儿发了

就连第一个FIN, 还带着一个ACK, 应该是要尽量减小开销、提高效率

按照传统四次挥手, 他一次只能发一个FIN或者一个ACK, 他也承认他没按规矩来, 把两个一起发了 他说马老师我不懂规矩、他说他是乱发的, 他可不是乱发的啊! 一个FIN、一个ACK, 训练有素, 一看就是有备而来

具体分析过程和三次握手相近, 就不重复了

另外, 在网上找到资料, 有说为了节省资源, 可以进行这样的合并

HTTP协议的分析

在”握手”和”挥手”之间, 我们截取一个请求从发送到应答完毕的过程

分析HTTP请求报文

HTTP请求报文的结构如下

请求报文的具体内容

  • 方法: GET
  • URL: /
  • 版本: HTTP/1.1

头部域省略

分析HTTP应答报文

HTTP应答报文的结构如下

应答报文的具体内容

  • 版本: HTTP/1.1
  • 状态码: 304
  • 原因短语: Not Modified

头部域省略

综合分析流程

从网络包的顺序来看, 可以推测利用HTTP协议获取Web的基本流程:

  • 建立TCP连接
  • 客户端发出HTTP请求报文
  • 服务器应答收到请求(TCP)
  • 服务器发出HTTP应答报文
  • 客户端回应收到应答报文(TCP)
  • 客户端解析收到的HTTP应答报文, 如仍有需要请求的资源, 则回到第二步
  • 如没有需要请求的资源, 断开TCP连接

三、 参考资料

This post is licensed under CC BY 4.0 by the author.

Linux进程通信与内存管理实验

Boson路由器配置实验