电子科技大学-计算机网络与通信技术-基于Wireshark的抓包分析

HTTP报文的结构基本与TCP报文的结构相同，都含有：Frame物理层；Ethernet II 数据链路层；Internet Protocol Version 4（6）互联网层IP包头部；Transmission Control Protocol传输层。其中的结构都是相同的，我们在1.1中已经分析过，此处不再赘述。

HTTP和TCP报文唯一不同的是，前者多了一个Hypertext Transfer Protocol，即应用层。我们将针对这一层的相关内容进行分析。报文是1.1中展示的。

1. 1. Request报文

HTTP的请求报文包括：请求行(request line)、请求头(header)、空行和请求体(request data) 四个部分组成。

请求行(request line)：包括请求方法，URL(包括参数信息)，协议版本这些信息，本次抓取的请求行如下（GET /json/xl_chrome_ext_config.json HTTP/1.1）：

请求头部(Header)是一个个的key-value值，比如

Accept-Encoding：gzip, deflate

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36

空行(CR+LF)：请求报文用空行表示header和请求数据的分隔

请求体：可见是由一个单独的\r\n分割的

1. 1. Response报文

HTTP的响应报文包括：响应行（状态行），响应头，空行，数据(响应体)

状态行：包括：HTTP版本号，状态码和状态值组成。

采用了HTTP1.1版本，状态码是304，表明服务端已经执行了GET，但文件未变化。

响应头：类似请求头，是一系列key-value值

Server: Tengine\r\n

Connection: keep-alive\r\n

Cache-Control: max-age=3600\r\n

等等

空白行：同上，响应报文也用空白行来分隔header和数据

响应体：响应的data，本例中是一段HTML，可见是由一个单独的\r\n分割的

1. TLSv报文的封装分析

我们选择了TLSv的第一个报文 Client Hello来分析

我们可以看到出来同样含有物理，数据链路，IP,TCP,之外，多出了一个Transport Layer Security层，我们将对这一层进行分析，其他类型的TLS报文我们将在时序分析中简单介绍。（168.63.202.111来自香港微软云）

Content Type

指示SSL通信处于握手阶段。除此之外，还有开始加密传输(Change Cipher Spec)还是正常通信(Application)等

Version

是TLS的版本1.2。

Handshake Type

是在handshake阶段中的client hello。还有如下的部分阶段：

Client Hello
Server Hello
Certificate
Server Key Exchange
Server Hello Done
Client Key Exchange
Change Cipher Spec
Encrypted Handshake Message
New Session Ticket：
Client Hello

附带的数据随机数据random，会在生成密钥时使用

Cipher Suite

列出了client支持的所有加密算法组合。

Cipher的格式为：认证算法_密钥交换算法_加密算法_ 摘要算法。如非对称算法RSA；对称算法如AES，3DES；Hash算法如SHA等。Server会从这些算法组合中选取一组，作为本次SSL连接中使用。

时序分析
1. TCP的三次握手

我们抓取的TCP握手是来自WPS，如下图所示：

客户端发送一个TCP，标志位为SYN，序列号为0，代表客户端请求建立连接。如下图

服务器发回确认包, 标志位为 SYN,ACK. 将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即0+1=1, 如下图

客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段ISN+1, 如下图:

整个过程如图所示：

1. TLSv加密协议

对于TLSv协议的具体内容，我们在第三部分介绍

Client Hello：

客户端向服务端打招呼；携带支持的协议、支持的安全套件供服务端选择；

Server Hello：

服务端回应客户客户端的招呼信息；结合客户端的信息，选择合适的加密套件；

Certificate：

服务端向客户端发送自己的数字证书（此证书包含服务端的公钥），以实现验证身份；

Server Key Exchange：

服务端向客户端发送基于选择的加密套件生成的公钥（此公钥为椭圆曲线的公钥，用于协商出对称加密的密钥）；

Server Hello Done：

服务端向客户端表示响应结束；

Client Key Exchange：

客户端向服务端发送自己生成的公钥（此公钥为椭圆曲线的公钥，用于协商出对称加密的密钥）；

Change Cipher Spec：

变更密码规范；告知服务端/客户端，以后的通信都是基于AES加密的；

Encrypted Handshake Message：

基于协商生成的密钥，用AES加密验证信息让服务端/客户端进行认证；如果对方可以解密，则双方认证无误开始通信；

New Session Ticket：

是优化SSL连接的一种方法，此处不做特别说明

五个协议
1. HTTP

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。是用于从万维网（WWW , World Wide Web ）服务器传输超文本到本地浏览器的传送协议。他基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。Ted Nelson组织协调万维网协会（World Wide Web Consortium）和互联网工程工作小组（Internet Engineering Task Force ）共同合作研究，最终发布了一系列的RFC，其中著名的RFC 2616定义了HTTP 1.1。

1. DNS

域名系统(Domain Name System，DNS)是Internet上解决网上机器命名的一种系统。就像拜访朋友要先知道别人家怎么走一样，Internet上当一台主机要访问另外一台主机时，必须首先获知其地址，TCP/IP中的IP地址是由四段以“.”分开的数字组成，记起来总是不如名字那么方便，所以，就采用了域名系统来管理名字和IP的对应关系。

虽然IP地址是因特网上节点的惟一标识，并且可以通过IP地址被访问，但即使是将32位的二进制IP地址写成4个0～255的十位数形式，也依然太长、太难记。因此，人们发明了域名，域名可将一个IP地址关联到一组有意义的字符上去。用户访问一个网站的时候，既可以输入该网站的IP地址，也可以输入其域名，对访问而言，两者是等价的。

域名系统（英文：Domain Name System，缩写：DNS）是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。

1. TLS

传输层安全性协议（英语：Transport Layer Security，缩写作TLS），是一种安全协议，目的是为通信提供安全及数据完整性保障。

TLS协议主要解决：保密(message privacy)，保密通过加密encryption实现，所有信息都加密传输，第三方无法嗅探；完整性(message integrity)，通过MAC校验机制，一旦被篡改，通信双方会立刻发现；认证(mutual authentication)，双方认证,双方都可以配备证书，防止身份被冒充。

在客户端和服务器开始交换TLS所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括：使用RSA算法生成公钥和私钥（在TLS握手协议中被称为TLS_RSA），Diffie-Hellman（在TLS握手协议中被称为TLS_DH），临时Diffie-Hellman（在TLS握手协议中被称为TLS_DHE），椭圆曲线迪菲-赫尔曼（在TLS握手协议中被称为TLS_ECDH），临时椭圆曲线Diffie-Hellman（在TLS握手协议中被称为TLS_ECDHE），匿名Diffie-Hellman（在TLS握手协议中被称为TLS_DH_anon）和预共享密钥（在TLS握手协议中被称为TLS_PSK）。

在浏览器、邮箱、即时通信、VoIP、网络传真等应用程序中，广泛支持这个协议。主要的网站，如Google、Facebook等也以这个协议来创建安全连线，发送数据。目前已成为互联网上保密通信的工业标准。

1. MDNS

多播DNS （ mDNS ）协议将主机名解析为不包含本地名称服务器的小型网络中的IP地址。允许系统在局域网中广播查询其他资源的名称。简单来说，你可以通过这个mDNS发现同一个局域网下的其他设备。它使用与单播域名系统（DNS）基本相同的编程接口，数据包格式和操作语义。虽然Stuart Cheshire将mDNS设计为独立协议，但它可以与标准DNS服务器协同工作。

当mDNS客户端需要解析主机名时，它会发送一个IP多播查询消息，要求具有该名称的主机标识自己。然后该目标机器多播包含其IP地址的消息。然后，该子网中的所有计算机都可以使用该信息来更新其mDNS高速缓存。

1. DHCP

DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）通常被应用在大型的局域网络环境中，主要作用是集中的管理、分配IP地址，使网络环境中的主机动态的获得IP地址、Gateway地址、DNS服务器地址等信息，并能够提升地址的使用率。

阶段2任务概述
1. 任务要求

完成1000个报文抓包后，利用Wireshark软件工具，分析流量成分或变化，流量成分至少从三种不同角度。鼓励从报文流中发现自己感兴趣的问题，进行追踪、查询和分析。

1. 分析和准备

首先我们在cmd窗口输入：ipconfig /flushdns，刷新 DNS 解析缓存。由于我们的抓包是在教学区使用校园网完成的，我们在cmd窗口输入ipconfig all，获取本机的IP地址，选择无线局域网适配器 WLAN：

IPv6 地址 . . . . . . . . . . . . : 2001:da8:6000:302::3:bb87(首选)

IPv4 地址 . . . . . . . . . . . . : 113.54.223.241(首选)

1. 抓包过程

我们打开wireshark，选择WLAN端口，不设置过滤器，开始捕获的同时打开bilibili网页，待抓取到数量足够的报文后，停止抓包，关闭网页。

我们通过cmd的ping命令获得bilibili的IP地址：

即120.92.218.109

流量分析
1. 基本属性

在15.141056秒的时间内，我们共抓取了7005个报文。他们的基本情况如下所示：

第一个分组:	最后分组:	经过时间:
2020/12/20 19:50	2020/12/20 19:50	00:00:15

Packet Length	Count	Average	Percent
all	7005	479.6	100.00%
0-19	0	-	-
20-39	0	-	-
40-79	1163	66.18	16.60%
80-159	2047	100.54	29.22%
160-319	1020	221.88	14.56%
320-639	1205	436.39	17.20%
640-1279	87	975.43	1.24%
1280-2559	1483	1510.29	21.17%
2560 and greater	0	-	0.00%

测量
分组	7005
时间跨度/s	15.691
平均/pps	446.4
平均分组大小/B	480
字节	3359571
平均字节/秒	214k
平均比特/秒	1712k

分析抓到的包分析发现，包的数量主要集中在80-159区间以及1280-2559之间。我们认为前者的数量较多主要是因为，TCP报文，MDNS报文较多

用frame.len >1280 and frame.len <2559筛选包，我们发现：

1280-2559之间的数量较多，两点之间通信的内容包的长度主要是集中在这一范围。而两点之间内容的通信较多，所以这一部分包占总体的比例较大。

1. 报文的类型和比例

结合我们阶段1完成的内容，我们预计抓取到的包的类型：TCP、UDP、ARP、RARP、ICMPv6、HTTP、DNS 、MDNS、TLS。

在实际的抓包中，我们抓取到的种类和比例如下所示：

类型	ADWin Config	ARP	BROWSER	DB-LSP-DISC /JSON	DNS	DTLS	HTTP	HTTP2	ICMPv6	IGMPv2
数量	1	2	13	1	56	110	22	163	29	29
比例	0.02%	0.04%	0.24%	0.02%	1.05%	2.06%	0.41%	3.06%	0.54%	0.54%

类型	LLMNR	MDNS	NBNS	QUIC	RARP	SSDP	SSLv2	TCP	TLS	UDP	WSP
数量	172	2708	77	15	6	187	4	1190	465	77	1
比例	3.23%	50.83%	1.45%	0.28%	0.11%	3.51%	0.08%	22.33%	8.73%	1.45%	0.02%

将其绘制为柱状图如下所示：

针对实验的结果我们有如下的几个问题：

1. 1. 实际抓取的报文多了什么，有什么作用

我们预计出现的几种报文全部出现在了抓包中，但这其中也出现了大量的我们没有预想到的报文，我们针对其中数目比较大的报文进行了查阅，他们是：DTLS、LLMNR、HTTP2、SSDP。

DTLS

DTLS(Datagram Transport Layer Security)，数据包传输层安全性协议。TLS不能用来保证UDP上传输的数据的安全，所有人们在TLS的架构下提出了DTLS，使之支持UDP。

LLMNR

链路本地多播名称解析（LLMNR）是一个基于DNS数据包格式的协议，IPv4和IPv6的主机可以通过此协议对主机执行名称解析。在我们的报文中也出现了很多使用IPv6的报文，所以出现这样的协议也是在情理之中的。

HTTP2

HTTP2即超文本传输协议2.0，相比普通的HTTP，大幅度提高了网页的性能，可以减少很多之前需要做的性能优化工作，但存在一定的兼容问题，以及如何优雅降级，所以还没有普遍使用的原因之一。

SSDP

按照协议的规定，当一个控制点（客户端）接入网络的时候，它可以向一个特定的多播地址的SSDP端口使用M-SEARCH方法发送“ssdp:discover”消息。

类似的，当一个设备接入网络的时候，它应当向一个特定的多播地址的SSDP端口使用NOTIFY方法发送“ssdp:alive”消息。如果控制点在指定的超时值内没有再次收到设备发送的“ssdp:alive”消息，控制点将认为设备已经失效。

1. 1. MDNS是什么，为什么占如此大的比例

在局域网内，我们要通过一台主机和其他主机进行通信，但是有些时候，我们并不知道对方的IP地址，因为一般使用动态分配IP地址的局域网内（也就是UESTC-WiFi吧），各个主机的IP地址是由服务器分配IP地址的。

在IP协议里规定了一些保留地址，其中有一个是 224.0.0.251，（对应的 IPv6 地址是 [FF02::FB]），MDNS 协议规定了一个端口，5353。

MDNS 是基于 UDP 协议。每个进入局域网的主机，如果开启了MDNS服务的话，都会向局域网内的所有主机组播一个消息，我是谁，和我的IP地址是多少。然后其他也有该服务的主机就会响应，也会告诉你，它是谁，它的IP地址是多少。我们甚至能看到设备的名词（大多是由姓名组成，造成了隐私的问题），而观察IP地址，我们可以大概的推断出，这些地址是位于同一个子网中的。

这样就可以利用这个服务开发一些局域网内的自动发现，然后提供一些局域网内交互的应用了。

1. I/O图

数据的吞吐分析，我们借助wireshark的统计中的I/O图，得到数据的吞吐量随时间的变化规律，我们发现这与我们理想的I/O图有极大的差别。

我们理想的I/O图是这样的，由图可知，抓包速度在 0-1 秒逐渐达到最高峰，0-1 秒内也正是我打开网页的时间，发送到我的电脑的数据包也是最多的。打开网页后，界面完全显示，传输的数据包数量也减少，抓包的速率也随之减慢。

但观察我们的报文，发现峰值出现在了4秒和8秒的时候，我们就针对这两个峰值产生的原因进行分析讨论。

1. 1. 峰值1

在4秒的时候，我们去看对应时间段的报文：

我们发现在4-5秒的时候，出现了大量的黑色TCP报文。

黑色底色的 TCP 有 TCP Out-of-Order、TCP Retransmission、TCP Dup Ack XXX#X、TCP Previous Segment Not Captured 四种类，他们分别代表了不同的传输情况。

TCP Out-of-Order 一般来说是网络拥塞，导致顺序包抵达时间不同，延时太长，或者包丢失，需要重新组合数据单元。

TCP Retransmission 是因为超时引发的数据重传。

TCP Dup Ack 就是重复应答#前的表示报文到哪个序号丢失，#后面的是表示第几次丢失。

TCP Previous Segment Not Captured 的意思就是报文没有捕捉到，出现报文的丢失。

我们的异常报文涵盖了所有的异常。

查阅180.208.68.174，得到了如下的结果：

虽然我并不能理解为什么在成都的电子科大的校园里出现了这样一个节点，但包括在阶段1，以及这次的抓包中都反复的出现了这个问题。我也只能暂且的理解为，我们学校网络环境的搭建于这个南京市的公司有一定的关系。

所以，第一个峰值出现的原因是由于传输中出现了大量的重复应答现象，是由于网络的异常所造成的。

1. 1. 峰值2

我们打开的是哔哩哔哩的网站，我1中我们已经用ping命令得知了其IP地址为120.92.218.109，我们在过滤器中输入以下的命令，来找到打开网站时的报文。

ip.addr==120.92.218.109

我们观察发现，该网站使用的不是正常的TCP三次握手来建立HTTP，也不是使用的HTTP1.0，而是使用的HTTP2。

这些报文发生的时间是8-9秒，也就恰好对应了我们的第二个峰值，这也就是我们理想中的I/O图，由于打开网页所需加载的资源较多，传输的数据量较大造成的，这与理论的结果是复合的。

1. 1. 总结

我们设置过滤器，分别找到IP 120.92.218.109和180.208.68.174的报文，做出他们的I/O图，如下所示：

这张图表示了总的数据吞吐量和由“中国江苏南京市江苏有线数据网络有限责任公司教育网节点”所产生的数据流，可见总的数据量和这个节点的数据量是对应的很好的。

这张图表示的是由bilibili产生的数据量，这与我们分析和数据的峰值也是吻合的，说明在打开网页前和关闭网页都需要加载大量的数据，和理论结果吻合的很好。

但是当我们把总的吞吐量和由bilibili产生的吞吐量放在一起的时候，我们发现，其实第二个峰值出现的原因还是由“教育网节点”产生的。但是我们分析了打开网页前后对应流量的变化，与理论结果符合的很好，同时也找到了修正了我们先前得出的结论，也算是很有收获。

1. Conservation(会话)

会话是一个客户与服务器之间的不中断的请求响应序列。当一个未知的客户向Web应用程序发送第一个请求时就开始了一个会话。当客户明确结束会话或服务器一段时间未接受任何请求时，会话就结束了。首次会话指的是创建会话的请求。

Wireshark统计中的Conversations窗口，显示了会话中端点的地址，以及每个设备发送或接收到的数据包和字节数。

1. 1. IPv4会话

IPv4是一种无连接的协议，操作在使用分组交换的链路层上。此协议会尽最大努力交付数据包，但不保证任何数据包均能送达目的地，也不保证所有数据包均按照正确的顺序无重复地到达。这些方面是由上层的传输协议处理的。

我们按照传输的大小排序，自下到上发现最大的传输来自于教育网节点（180.208.68.174），其次是我们打开的bilibili网页（120.92.141.155），再者是电信（27.159.91.1）

而我们自己的IP是113.54.223.241，可以看出，本地IP地址与对应网站的IP地址之间存在着数量很大的包的传输。

但其中也出现了很多意料之外的IP地址，甚至是发送和接受都不是本机IP的报文，这其中有很多的不确定因素，比如所公用了一个WiFi，后台应用比如QQ，OneNote的运行，导致了很多意外的IP出现。

1. 1. IPv6会话

IPv4 可提供 232个地址，IPv6 将原来的 32 位地址空间增大到128 位，数目是2的128次方。

在我们获取的报文中，IPv6所占的比例还是比较少的，而且大多数的报文的目的地址是[FF02::FB]，除此之外又很少的别的部分，而这个地址是IP协议中的一个保留地址，我们在前边也提到过，这个地址是用于MDNS的。

除了MDNS其余的用到IPv6的还有ICMPv6协议，ICMP（Internet Control Message Protocol）Internet控制报文协议。它是TCP/IP协议的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。

ICMPv6为了与IPv6配套使用而开发的。