| title | categories | tags | toc | comments | ||||
|---|---|---|---|---|---|---|---|---|
网络协议分析 |
|
|
true |
true |
总括： 本文通过Fiddler和Wireshark抓包进行互联网协议实践
-
原文博客地址：网络协议分析
-
博主博客地址：Damonare的个人博客
人生在勤，勤则不匮；户枢不蠹，流水不腐。
网络协议分析
关于Fiddler： Fiddler是一款由C#开发的免费http调试代理软件，有.net 2和.net 4两种版本。Fiddler能够记录所有的电脑和互联网之间的http通讯，Fiddler 可以也可以检查所有的http通讯，设置断点，以及Fiddle 所有的"进出"的数据。
优点：
-
Firebug虽然可以抓包，但是对于分析http请求的详细信息，不够强大。模拟http请求的功能也不够，且firebug常常是需要"无刷新修改"，如果刷新了页面，所有的修改都不会保存；
-
Wireshark是通用的抓包工具，但是比较庞大，对于只需要抓取http请求的应用来说，似乎有些大材小用。且Wireshark无法解密HTTPS故而选择使用fiddler来对HTTP协议进行分析；
-
Httpwatch也是比较常用的http抓包工具，但是只支持IE和firefox浏览器（其他浏览器可能会有相应的插件），对于想要调试chrome浏览器的http请求，似乎稍显无力，而Fiddler2 是一个使用本地 127.0.0.1:8888 的 HTTP 代理，任何能够设置 HTTP 代理为 127.0.0.1:8888 的浏览器和应用程序都可以使用 Fiddler。
这里为体现个人特色，选择在本地服务器运行观察抓包结果，如图：
实际上，Wireshark抓不到本地服务器发送报文，这也是Fiddler更利于开发调试的原因之一。 HTTP协议分析（1）：由于之前本地测试过，所以第一次抓到的包返回的状态码是304，清除缓存后变为正常的200，图中我们可以看到返回的数据："xxxFiddlerHTTP协议测试"，这里我们通过请求头报文可以看到请求站点（localhost:81）,请求方式（XMLHttpReQuest）等信息。由于Fiddler只能抓到HTTP/HTTPS的包，关于HTTP协议的深入分析我们使用Wireshark进行。
关于Wireshark： Wireshark（前称Ethereal）是一个网络封包分析软件。网络封包分析软件的功能是撷取网络封包，并尽可能显示出最为详细的网络封包资料。Wireshark使用WinPCAP作为接口，直接与网卡进行数据报文交换。 优点：
-
使用操作非常简单，对于初级和中级网络学习者来说是一款完美的抓包软件。
-
有很多小工具和小技巧可以帮助我们更快更好的了解网络，例如filter，expression，statistics等等。
-
界面设计很简洁，给使用者一种非常清新的感觉。
-
与Fiddler相比可抓取的包更广，更多，并且软件开源，用着放心。
实例分析TCP三次握手过程：**
这里我们打开哔哩哔哩网站首页观察抓包情况（http://www.bilibili.com/
- 第一次握手数据包；
客户端发送一个TCP，标志位为SYN，序列号为0， 代表客户端请求建立连接。如下图：
- 第二次握手的数据包；
服务器发回确认包, 标志位为 SYN,ACK. 将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即0+1=1, 如下图：
- 第三次握手的数据包；
客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1,如下图：
就这样通过了TCP三次握手，建立了连接,三次握手基本结束，开始真正的数据传送阶段： 建立了三次握手后，我们就开始利用这个链接来传送信息了。下面我们看看经过三次握手后的第四个TCP报文段。这是服务器返回来的报文段：
我们惊奇的发现服务器返回了ack=557，即请求第557Byte的数据，而这557Bytes是什么时候发出去的呢，我们想到了在第三次握手的时候，客户端发送的TCP是能够携带数据的。怎么验证是否携带了557Bytes数据呢，我们想到了HTTP协议封装的报文，我们来验证一下是否是557Bytes，打开HTTP协议如下:
我们看到，HTTP协议封装的报文，长度为Bytes in flight：556。表示已经发送了557Bytes，所以，服务器理应返回一个ack=554的确认，以表示接收到了556Bytes以前的数据，希望接受557bytes以及以后的数据。而上面的第四个报文也正是这么做的。 服务端返回了ack=557之后，服务端没有继续停下，而是继续向客户端发送了两个报文段。我们来看下第五、六个报文段:
第五个报文段发送了seq=557，ack=1203告诉服务端，请求你的1203数据，我这是第557个数据。发完后服务端又发送了第六个报文，如下:
服务端发送了seq=1113，ack=2400，这表示：我请求第2400Bytes，这是我的第1113Bytes,这个报文之后，服务端会继续给客户端传送数据，这里就不一一列出了。
断开连接： 断开连接时，要发送FIN=1，并且对方要回复ACK=1。我们来看下截取的报文段。
我们看到FIN=1。
返回了ACK=1，结束连接。
到这里HTTP协议就算分析结束了，我们可以看到HTTP传输数据确实是靠TCP协议来完成的，由于哔哩哔哩网站内容很多，所以看起来很乱...这点没有考虑周全。
在显示筛选编辑框中输入"arp"，回车，分组列表窗口将只显示ARP消息。点击第一行查看具体数据：
可以看出硬件类型（hardware type）是以太网（1），协议类型（protocol type）为0x0800，表示使用ARP的协议类型为IPV4。硬件地址长度（hardware size）为6。协议地址长度（protocol size）为4。 发送方硬件地址（sender MAC address）：bc:30:7d:97:c8:08 发送方协议地址（Sender IP address）：192.168.1.5 目的硬件地址（target MAC address）为00:00:00:00:00:00，表示是广播地址。 目的协议地址（target IP address）为192.168.1.1，定义目的设备的协议地址。
在cmder(也可以是一般的命令行窗口)中以www.damonare.cn(个人网站)为目标主机，在命令行窗口执行Ping命令，要求ping通10次；
停止截获报文，抓包结果:（只显示ping的数据包） 在显示筛选编辑框中输入"icmpv6"，回车，分组列表窗口将只显示icmp消息。点击第一行查看具体数据：
在显示筛选编辑框中输入"ip"，回车，分组列表窗口将只显示IP消息。选取一个有IP协议的数据报：
能力有限，水平一般，欢迎勘误，不胜感激。
转载请获本人授权，并注明作者和出处。
订阅更多文章可关注公众号「前端进阶学习」，回复「666」，获取一揽子前端技术书籍
