wireshark应用层抓包分析

Wireshark

抓包分析

CONTENT

引言

1 利用wireshark抓取网页服务协议并分析 1.1 HTTP协议报文结构及分析 1.2 HTTPS是什么

1.3 HTTP与HTTPS的比较

1.4分别在网络空闲与网络繁忙时比较相关报文传送的区别 2 利用wireshark抓取邮件传输协议并分析 2.1 SMTP邮件发送协议的结构 2.2 POP3与IMAP协议结构的区别

2.3网页版收发邮件与邮件客户端收发时使用协议的比较 3 利用wireshark抓取ftp文件传输协议 3.1 ftp协议的格式及特点分析

4 分析DNS的解析过程

4.1“www.hzbook.com”域名解析实例分析 4.2“www.gatech.edu”域名解析实例分析

Ps：之前在写目录的时候觉得这样来分析分析会对应用层协议的理解更加全面一点，但是基于各种原因只是完成了黑色字体部分，而且还可能存在很多错误。有机会可以进一步完善。

引言

经过计算机网络基础前面时间的学习，使我们对网络应用层的协议有了一定的了解。协议就像一门语言，需要定义语法、语意和语序（时序、同步）。语法即为协议的具体格式；语意定义了具体格式中具体指代，比如说，空一行后的数据表示为数据字段；就目前说掌握的只是而言，我对语序的理解还不是很清楚，这里就不加赘述。

下面将主要从应用层的协议出发，利用我们所学习过的知识，对不同的应用请求响应过程进行分析，探究在不同网络工作环境下网络协议的变化。

本次抓包分析的环境为IE9浏览器，使用wireshark的版本为32位第1.4.9版。

1 利用wireshark抓取网页服务协议并分析

1.1 HTTP协议报文结构及分析

首先清空IE浏览器的缓存、cookie等信息，并运行wireshark。 输入“http://yunpan.360.cn”后得到抓包文件如图1所示。

图1“http://yunpan.360.cn”后得到抓包数据

第1行的SSDP协议也是应用层的协议，大致意思就是用来申明自己的存在。从在No.14时用户向服务器（web缓存）发起360云盘的网页请求。在No.25时用户想360云盘的服务器直接发起请求，说明在此之前web缓存已将360云盘服务器的地址信息转发给用户。同时此后的通信双方为用户与360云盘服务器，并没有经过web缓存，说明实际web缓存的作用并不像我们所学习的那样——web缓存要缓存小区域内说用用户请求过的网页文件，并在超时时才给以删除。在No.25时，用户向服务器发起网页请求，同时在No.32时服务器向用户返回请求的信息（html）即基本的网页文件。此后，用户发应用文件的申请。No.34、35中用户发起的申请并为按照次序返回给用户，而是No.35的请求先到达，No.34后到，但是用户却没有再次发出请求报文，说明定时器还没有超时，并且两个响应报文可能走了不同的路由路径。

图2 TCP out-of-order

在No.135时，出现了陌生地址发送来的HTTP报文，该报文采用的是

HTTP1.0协议，可见HTTP1.0与HTTP1.1监听的端口都是80。HTTP报文的传输层协议是TCP协议，采用IP地址以及端口号同时建立一对一的连接关系，接收到陌生地址报文的原因或许是360云盘的网页上引用了其他服务器的信息。但更多的可能是报文地址出错，错发到这里了。

图3 同样也是第三方的服务器地址

No.364时，又是出现了第三方的服务器地址，并没有出现图2中TCP乱序的说法，因此此处的第三方服务器更像是360云盘网页上引用的其他服务器的信息。

1.2 HTTPS协议报文结构及分析

当我们在使用网盘的时候，比如说酷盘，不难发现它使用的URL是以https开头的协议而不是我们所熟知的http协议。想必这二者之间必定存在一定联系，但是又有一定区别。下面就利用wireshark抓的酷盘登陆时的数据包来探究上述二者的异同。

百度百科中对HTTPS即安全超文本传输协议是：HTTPS又称S-HTTP是一种结合HTTP而设计的消息的安全通信协议。S-HTTP协议为HTTP客户机和服务器提供了多种安全机制，这些安全服务选项是适用于Web上各类用户的。还为客户机和服务器提供了对称能力，同时维持HTTP的通信模型和实施特征。 S-HTTP不需要客户方的公用密钥证明，但它支持对称密钥的操作模式。这意味着在没有要求用户个人建立公用密钥的情况下，会自发地发生私人交易。它支持端对端安全传输，客户机可能首先启动安全传输（使用报头的信息），用来支持加密技术。

在语法上，S-HTTP报文与HTTP相同，由请求行或状态行组成，后面是信头和主体。请求报文的格式由请求行、通用信息头、请求头、实体头、信息主体组成。相应报文由响应行、通用信息头、响应头、实体头、信息主体组成。 以上解释并没有十分透彻的说明HTTP与HTTPS到底有没有关系，如果有又是什么关系。下面直接通过酷盘网页登录的数据包情况直接分析，看是否能够对HTTPS有所了解。

图4 酷盘https://www.kanbox.com/登录的部分数据报

从图4不难发现，酷盘https://www.kanbox.com/的响应报文与之前想象的几乎没有相似之处。此前认为https协议仍是类似于http协议一样的网页文件传输协议。但是从抓包的结果来看，太令人失望了，在数据包的前段部分我们没有看见一点网页文件的影子，取而代之的是一大片TCP协议建立连接的请求与响应报文。还算令人欣慰的是，在No.11、13、17、18的TCP报文后出现了https字样。由此可以基本推测出来HTTPS并不是应用层的协议，而是传输层，可能是TCP向上到HTTP协议的一个有点类似于套接字的某个东西。令我很不解的一点就是，原本请求的是一个网页文件，但是抓到的数据包中没有网页文件的请求以及相应报文，全部是TCP、TLSv1、DNS以及SSDP协议。

1.3 HTTP与HTTPS的比较

与没有看过数据包之前的想法大相径庭，HTTPS并不是应用层协议，与HTTP也没有什么直接的关系。百度上所说的S-HPPT为HTTP提供安全的运行环境，估计就是从传输层的角度出发来讲的，即提供更为可靠的传输层向上的借口。

实践告诉我们并不能想当然的认为一个命题成立，必须经过有理有据才能下推断。猜想是可以的，但是必须验证。就像HTTPS与HTTP一样，要不然到现在仍然会认为HTTPS与HTTP必然有某种联系。

1.4分别在网络空闲与网络繁忙时比较相关报文传送的区别

图5 网络繁忙时的响应以及请求报文

图6 网络空闲时的响应以及请求报文

图5中No.467、469、476的报文都出现了丢包现象，而图6中的报文接收与请求都十分流畅。

综上，通过对HTTP网页请求服务抓包信息的观察以及分析以后，了解了HTTP请求以及相应报文的基本信息，以及WEB缓存的实际作用。同时也明白了报文的层次包裹结构。

4 分析DNS的解析过程

4.1“www.hzbook.com”域名解析实例分析

图7“www.hzbook.com”域名解析

从No.6开始用户向服务器web缓存发起域名解析请求，不清楚为什么是google的域名开始。但是服务器向用户返回一个地址后，用户后面域名解析的请求直接向该地址的服务器发起。在No.42时，用户输入www.hzbook.com的请求，服务器直接响应了地址给用户。由此可见用户到服务器的地址查询请求的算法为循环算法，而服务器向上解析的过程采用何种算法在这里我们就不得而知了。 上述的域名解析是关于国内的一个网址进行的，那么对于国外网址的解析又会有什么不同？下面就应用wireshark对乔治亚理工学院网址解析时的抓包数据进行分析。

4.2“www.gatech.edu”域名解析实例分析

图8“www.gatech.edu”域名解析

与图7中的信息类似，用户首先向IP为202.112.14.151的服务器发起域名解

析请求，大约一个单位时间过后用户又向IP为61.139.2.69的服务器发起域名解析请求。一定时间过后，两个服务器都返回了相同的IP地址给用户。就用户发起请求后的等待响应的时间来看，IP为61.139.2.69的服务器能够更快的响应用户。图7中可以看出在用户与IP为61.139.2.69的服务器建立连接后，用户的域名解析请求全部又该服务器完成，IP为202.112.14.151的服务器不在参与与用户之间的通信。然而图8中可以看出，两个域名解析服务器均在于用户通信，并且通信的主体服务器为IP为202.112.14.151的服务器。那么学校为什么要用两台服务器完成域名解析的功能？

结合前面HTTP网页文件请求的直接相应服务器与域名解析的直接响应服务器IP地址的不同可以看出，二者不是同一服务器，也就是说，web缓存很可能只是起到中转站的作用。从而web缓存上的网络流量压力就不会太大。

小结：

上述许多推理都是基于个人的推断，但究竟是否正确还有待确认。通过wireshark的抓包分析，加深了我对网络的建立连立、请求以及响应的过程，比书本上的知识更加能够然人明白实际到底是怎么进行的。同时也纠正了我对于http和https的误区。

本文来源：https://www.bwwdw.com/article/7h42.html