六十三、应用层篇-网络抓包神器：Wireshark

HTTP协议我们也有了大体的认识，但是他在网络中传输的报文到底长什么样子呢？本篇文章让我们来熟悉下陌生的老朋友Wireshark吧！它的强大早就流传于江湖。

本文略长，但是值得。

一、前言

Wireshark是一个极其强大的软件，通常被称为嗅探器，可以帮助我们监视网络上发生的事情。

具体来说，Wireshark 可以捕获到达你的网卡上的网络数据包，并将数据包的内容以清晰易懂的形式呈现给你。Wireshark 能查看到以你的网卡为目标的所有数据包。

wire 是“电线，金属丝，导线”的意思，shark 是“鲨鱼”的意思。所以 Wireshark 的图标是一个鲨鱼鳍。

官方下载地址为：https://www.wireshark.org/download.html

安装好之后，打开 Wireshark 来到初始页面：

这里选择需要捕获报文的网卡，由于我电脑使用的是无线网络，因此我会关注WLAN这一项，并且可以看到波浪线，说明这个网卡目前正在有佷多的网络报文在这个网卡上经过，双击点开即可实时抓取网络包了。下面还有一个Loopback Adapter，这是本地回环，我们先不关心。

我们可以通过左上角的蓝三角和红方块，控制开始抓包和暂停抓包。整体抓包界面如下：

可以看到，主要分为四大块，下面一一来说明下。

二、Wireshark主体页面

2.1 菜单

菜单的部分非常重要，首先就是上面说到的蓝三角和红方块，分别决定了开启抓包和暂停抓包。

最重要的是过滤器，可以通过输入筛选条件，筛选出指定的数据包，因为茫茫数据包太多了，有了这个筛选让我们拿到最关注的一部分报文，可以大大降低网络包分析的难度。

Wireshark 也为我们预设了不少过滤选项，只要点击过滤器栏目最左边的 “书签” 状图标，就会显示如下图的下拉菜单，你可以选择你想要的过滤选项：

过滤器很有用，例如我们要追踪 TCP 连接，就可以设置过滤器只显示 TCP 的数据包（上图中的 TCP only: tcp），而不显示例如 UDP 的数据包或其他会干扰我们的数据包。我们待会就会用到过滤器。

2.2 捕获到的数据包的摘要呈现

上图中每一行对应了一个捕获到的 packet（数据包），或者称为 message（报文，消息）。

每一行都有七列数据。

第一列是编号，我们可以看到，是从1开始递增的。

第二列是时间，默认是相对时间，就是捕获到此数据包的时间相对于捕获到编号为 1 的第一个数据包的时间的差额，单位是秒，精确到小数点后面六位。我这里将时间调整为了绝对时间，方便我自己看。调整的方法很简单，鼠标悬浮到 Time 上，右击选中编辑列，会出现一个下拉框，选中Absolute date并确认OK即可。

第三列是Source，标识此数据包的源IP地址。

第四列是Destination，标识此数据包的目标 IP 地址。

第五列是Protocol，标识此数据包最近一层封装的协议。

第六列是Length，标识此数据包的长度，单位是 byte（字节）。

第七列是Info，标识此数据包的其他相关信息。

2.3 指定数据包的详细呈现

我们可以看到，选中第二块中不同的行，下面的详细呈现会随之变化，这块默认显示第 1 个数据包的详细信息。如果你点击第二部分 “捕获到的数据包的摘要列表” 中的某一行，就会显示此数据包的详细信息。Wireshark 将 OSI 模型的每个层的相关信息分开展示：

这些在前面的学习中，都已一起探索过。这里简单再说说，当作总结。

①Frame ：第 1 层物理层数据帧概况

第一层是物理层数据帧的概况，Frame 1269标识帧的编号是1269。帧的大小是522 bytes，也就是4176 bits。（因为一个 byte 等于 8 个 bit）

②Ethernet II ：第 2 层数据链路层以太网帧的头部信息

以太网帧的头部信息很简单，就三个重要信息：依次是目的MAC地址、源MAC地址和IPV4协议。

③Internet Protocol Version 4 ：第 3 层网络层 IP 数据包的头部信息

网络层的头部信息包含的信息就比数据链路层多一点了，核心上是用的IP版本、是否切片、数据长度、源IP地址和目的IP地址等信息。

④Transmission Control Protocol ：第 4 层传输层数据段的头部信息

此处是 TCP 协议。如果是 UDP 协议，则是 User Datagram Protocol。TCP首部字段我们也详细做过分析，可以看到，这一层最关键的信息是端口号，指定了源端口号和目的端口号。

⑤Hypertext Transfer Protocol：第 5 层应用层报文头部信息

这里就是大名鼎鼎的HTTP协议，本次示例的请求是一个GET请求，并且是长链接。学习了HTTP协议的报文结构，相信看这个请求报文就很明朗了！

2.4 数据包的十六进制内容

数据包的十六进制内容稍微复杂一点，它是数据包的原始内容，就是没有经过 Wireshark 翻译的。如果你想查看数据包的实际内容，而不仅仅是 Wireshark 翻译的内容，这会很有用。数据包的实际内容和 Wireshark 的翻译结果之间可能会有差异：

我们可以简单看到红框框的内容，就是以太网头的目的MAC地址和源MAC地址。以及下面还看到了HTTP头信息，可以知道，这一坨就是数据包的原始内容了。我们肉眼稍加分段实际上也是可以大概理出来各层的头信息和实体报文信息的范围的。不过我们完全没有必要，因为上面是Wireshark帮助我们现成翻译好的，是不是可以感受到Wireshark的方便和强大？

三、实际抓一个包

注意，如果你是在 Linux 操作系统中用命令行来启动 Wireshark 的，请确认你具有 root 权限（用 sudo wireshark 来启动），否则 Wireshark 将没有访问网络接口收到的帧的权限。

让我们以访问http://www.oursnail.cn:8080/fossi-shop/为例，这是我自己搭建在云服务器上的一个商城项目。当然了，你也可以用其他的网站做实验，不过暂时先找个HTTP的网站做实验吧。

首先我打开嗅探，访问上述的网站，然后网站首页打开完成后，我关闭嗅探，目的是减少其他不需要的网络包的干扰。

我可以在筛选条件中输入：http || dns

这是我经常用的一个筛选条件，是为了筛选出HTTP协议和DNS协议的两种协议类型的报文，因为我比较关注应用层的报文，而我打开这个网站，最基本的步骤应该是先DNS解析域名拿到IP地址，然后跟此IP地址进行后续的TCP三次握手建立连接，连接建立完成后即可进行HTTP报文交互。

我们来看下效果:

可以看到，符合我们的预期，第一步是域名解析，查询出来结果直接是个A记录，即111.231.119.253。没错，这个就是我云服务器的公网IP地址。我们有可以通过nslookup或者ping等命令查询出域名解析结果。

我们也往往可以通过IP地址进行报文的筛选，比如我要IP为111.231.119.253的报文：

这样就可以筛选出跟这个IP相关的报文，当然了，也可以更加细化，比如我只要源IP地址是111.231.119.253的，就可以输入：ip.src == 111.231.119.253，目的IP为111.231.119.253的，就可以输入：ip.dst == 111.231.119.253.

好了，查询到域名之后，我找到显示是GET /fossi-shop/ HTTP/1.1这一行，我对它很感兴趣，因为这个显然就是我刚才访问http://www.oursnail.cn:8080/fossi-shop/的报文了，那么我如何对这一个报文单独进行查看呢？右击选中追踪流==》TCP流：

首先会弹出一个新的页面来，新的页面是什么呢？是请求报文和响应报文。红色字体的是请求报文，蓝色字体的是响应报文。

这个HTTP报文比较简单，经过前面几篇文章的说明，已经不需要赘述了，唯一需要注意的是，请求报文中有个Cookie的字段，这个请求携带了Cookie信息提交给服务器端，也是在跟上面文章做呼应。我们先关闭此页面：

可以看到tcp.stream eq 10这个字眼，表明这次看的是第10号TCP流。同属于一次TCP的请求都会在这里展示出来。既然是TCP请求，第一步自然就是三次握手，我们可以看到前三行就是三次握手的报文：

可以看到，下面的报文长度Len最大是1412，这个值哪来的呢？我们来实际看下抓包，首先是三次握手的第一次握手：

取其能力较差的一位，那么每次最大报文传输长度自然就是1412了，这就是我们之前学习过的MSS。若一个报文总长度超出1412怎么办？显然是要分割再发送。

三次握手成功，本次TCP连接的准备工作结束，下面就可以放心发请求了。可以看到，第四行紧接着就是一条GET /fossi-shop/ HTTP/1.1请求。

OK，应用层的请求发出来了，服务器端收到请求后，就需要将数据响应给客户端，也就出现了下面一大坨TCP报文，为什么会出现这么多呢？原因是响应的报文太大，需要切割成一小段一小段，即上面提到的MSS长度的报文，客户端进行报文的组装、解析和渲染页面。

因此我们看到了“TCP segment of a reassembled PDU”这个提示：

TCP在发起连接的第一个报文TCP头里面通过MSS(Maximum Segment Size),告知对方本端能够接收的最大报文（TCP净荷的大小），TCP层收到上层大块报文后，会分解成小块报文发送。

下面我们来仔细看看这一坨吧，领略下TCP的核心：TCP滑动窗口机制。

我们都知道，TCP的数据传输是可靠的。所谓可靠是依托序列号和确认号机制让TCP的传输过程中即使出现丢包也会重传。

但是TCP的确认机制会让TCP连接双方的数据传输速度变慢，为什么呢？一方发送数据需要等待对方的确认才能继续发送后续的数据。如果发一条、确认一条才能发下一条的话，效率岂不是慢到炸？

因此出现了滑动窗口机制，所谓窗口，就是充分利用双方的带宽及缓冲区buffer。举个例子，发送方不必等待对方每一条的确认，可以连续发送多个数据包给对方，而对方可以暂时将来不及处理的数据包丢到缓冲区中，最终给对方一个处理完成的确认，这样就不需要一个数据包给一个回执了，即累计确认，大大提高了效率，比如10个数据包，我已处理2个，缓冲区5个，那么我就可以处理完5个后给一个确认号，告知发送方我收到了前7个数据包了。这样发送方也就知道我前7个数据包发送成功，不需要管他们了。

不过这样做有问题，一旦接收方处理很慢，缓冲区即将被填满，如果发送发不知情，接收方会压力越来越大，最终不堪重负而亡。这个时候，就需要有个窗口实时更新机制，比如接收方窗口大小初始设置为10000，也就是说发送方可以不必等待确认一次性发10000字节的数据，一旦接收方意识到不堪重负时，发送窗口更新通知告诉发送方：老哥，我吃不消了，窗口砍到5000，请减少一次发送数据的字节数。

在某些极端情况下，接收方buffer完全被填满，接收方可以发送ZeroWindowSize通知，让发送方暂时停止数据传输，并等待下一个确认通知。

那么窗口大小是如何协商的呢？也是在三次握手期间！在看抓包前，有必要知道下Window size scaling出现的原因：

最早TCP协议涉及用来大范围网络传输时候，其实是没有超过56Kb/s的连接速度的。因此，TCP包头中只保留了16bit用来标识窗口大小，允许的最大缓存大小不超过64KB。为了打破这一限制，RFC1323规定了TCP窗口尺寸选择，是在TCP连接开始的时候三步握手的时候协商的（SYN, SYN-ACK,ACK），会协商一个 Window size scaling factor，之后交互数据中的是Window size value，所以最终的窗口大小是二者的乘积.

大概意思就是，一开始的时候压根没想到现在网速这么快，设计的有点保守。要改进，如何改进呢？增加一个字段，作为放大因子，提高数据传输速度。

下面来看看如何协商的，三次握手第一个SYN报文下有：