【流量分析】

TCP流量分析

TCP流量三次握手建立连接

tcp流量三次握手就如同我们日常的问候一样，首先客户端发送一个SYN数据包（seq初始化序列码，假设为X），服务器接收到数据包后返回一个ACK/SYN数据包（此时seq码重新设定为Y，ACK确认序列码设置为X+1）,客户端接收到数据包后返回一个ACK数据包（seq码设定为Z（X+1），ACK码设定为Y+1）

第一个SYN数据包开启三次握手建立通信过程。
从图中我们可以看到
Src源地址：172.20.185.237；Dst目的地址：2.23.97.10；
源端口：50619；目的端口：80；
Sequence Number(raw)序列码:883778448
Acknowledgment number(raw)确认码:0
Calculated window size窗口:64240（窗口是告知对方下一次数据包发送内容的数据包上限，也是发送方预留相应数据包的缓存空间）

第二个数据包发送SYN/ACK数据包响应第一个SYN包
第二次握手SYN/ACK
Src源地址：2.23.97.10；Dst目的地址：172.20.185.237；
源端口：80；目的端口：50619；
Sequence Number(raw)序列码:1648562050
Acknowledgment number(raw)确认码:883778449（SYN包的seq码+1）
window窗口:64240

最后，发送一个ACK包。这个过程完成后，双方的设备应该已经具有了开始正常通信的信息。
第三次握手ACK
Src源地址：172.20.185.237；Dst目的地址：2.23.97.10；
源端口：50619；目的端口：80；
Sequence Number(raw)序列码:883778449
Acknowledgment number(raw)确认码:1648562051（SYN/ACK包的seq码+1）
至此，三次握手过程完成，客户端与服务器建立连接。

TCP四次挥手连接断开

TCP连接断开示意图
首先客户端发送一个FIN数据包（seq初始化序列码，假设为u），服务器接收到数据包后返回一个ACK数据包（此时seq码重新设定为v，ACK确认序列码设置为u+1）和FIN/ACK数据包（seq码设定为w，ACK确认序列码设置为u+1）,客户端接收到数据包后返回一个ACK数据包（seq码设定为u+1，ACK码设定为w+1）

设备通过发送有着FIN/ACK包的数据包，来开始终止过程。
第一次终止过程的FIN/ACK包
从图中我们可以看到
Src源地址：172.20.185.237；Dst目的地址：116.130.224.118；
源端口：50622；目的端口：80；
Sequence Number(raw)序列码:1738887763
Acknowledgment number(raw)确认码:1125387800

在收到FIN/ACK包后，使用一个ACK包进行响应，来确认第一个FIN/ACK包的接受，然后发送了一个FIN/ACK包
第二次终止过程的ACK包
从图中我们可以看到
Src源地址：172.20.185.237；Dst目的地址：116.130.224.118；
源端口：50622；目的端口：80；
Sequence Number(raw)序列码:1125387639
Acknowledgment number(raw)确认码:1738887763（可能是抓包错误，此码应该和下面的ACK码一致为1738887764）

第二次终止过程的FIN/ACK包
Src源地址：172.20.185.237；Dst目的地址：116.130.224.118；
源端口：50622；目的端口：80；
Sequence Number(raw)序列码:1125387800
Acknowledgment number(raw)确认码:1738887764

第三次终止过程的ACK包
Src源地址：172.20.185.237；Dst目的地址：116.130.224.118；
源端口：50622；目的端口：80；
Sequence Number(raw)序列码:1738887764
Acknowledgment number(raw)确认码:1125387801

TCP握手断开过程在最终的ACK包之后结束。这时的两个设备的通信便已经结束，想要再次开始通信就必须完成新的TCP握手。

TCP重置

理想状态下，每次连接都会以TCP终止来正常结束。但在现实中，连接经常会突然断掉。在这些情况下，就需要使用设置了RST标志的TCP数据包。RST标志用来指出连接被异常中止，或拒接连接请求。RST数据包不需要对方发送ACK确认数据包。

DHCP流量分析

DHCP 是一个应用层协议，主要任务就是向客户端分配IP地址，负责让设备能够自动获取IP地址（以及其他重要的网络资源，比如DNS服务器和路由网关的地址）。过程在一个客户端和DHCP服务器之间进行，过程通常被称作DORA过程，因为它使用了4种类型的DHCP数据包：发现（discover）、提供（offer）、请求（request）和确认（acknowledgement）。
DHCP的DORA示意图

第一次发现（discover）数据包
第一个数据包从0.0.0.0的68端口发往255.255.255.255的67端口。客户端使用0.0.0.0，是因为它目前还没有IP地址。数据包被发往255.255.255.255，是因为这是一个独立于网络的广播地址，从而确保这个数据包会被发往网络上的每台设备。因为这个设备并不知道DHCP服务器的地址，所以它的第一个数据包是为了寻找正在监听的DHCP服务器。
在第四行我们可以一眼看到DHCP是基于UDP作为传输层协议的。DHCP对于客户端得到其所请求信息的速度有很高的要求。由于的DHCP有其内置的保证可靠性的方法，因此意味着UDP是比较适合的协议。

第二个提供（offer）数据包
第二个数据包在IP头中列出了可用的IP地址，显示这个数据包从10.1.2.254发往10.1.2.5，如图。因为客户端还没有10.1.2.5这个地址，所以服务器会首先尝试使用ARP提供的客户端硬件地址与之通信。如果通信失败，那么他将会直接将提供（offer）广播出去，进行通信。
第二个数据包的DHCP部分，被称为提供数据包，表明这是一个响应的消息类型。这个数据包包含了和前一个数据包相同的事务ID，也就是告诉我们这个响应与我们原先的请求相对应。
提供的信息：
子网掩码：255.255.255.0
持续时间：30min（1800s）
DHCP服务器的标识符：10.1.2.254

第三个请求（request）数据包
在客户端接收到DHCP服务器的提供数据包之后，他将以一个DHCP请求数据包作为接受确认。这个捕获的第三个数据包仍然从IP地址0.0.0.0处发出，因为我们还没有完成获取IP地址的过程。但数据包现在知道了他所要通信的DHCP服务器。
这是一个新的请求/响应过程，所以它有了一个新的事件ID。
在最后的选项域。我们看到这个DHCP请求的IP的地址不再是空，并且DHCP服务器标识符域也填有地址。

第四个确认（ACK）数据包
这个过程的最后一步就是DHCP在确认数据包中给客户端发送其所请求的IP地址，并在其数据库中记录相关信息。这是客户端就有了IP地址，并且可以用它在网络上通信。

DNS流量分析

源地址：172.20.185.237向DNS服务器:114.114.114.114询问www.msftconnecttest.com的ipv4地址

DNS服务器向客户端返回了请求地址
www.msftconnecttest.com:type A
IPv4主机地址（A）
IPv6主机地址（AAAA）
权威域名服务器（NS）
规范别名（CNAME）
邮件交换（MX）
文本字符串（TXT）
完整区域传送（AXFR）：这个类型的传送将整个区域在设备间进行传送。
增量区域传送（IXFR）：这个类型的传送仅传送区域的一部分。
区域传送的数据如果落入他人手中可能会很危险。举例来说，通过枚举一个DNS服务器，你可以绘出整个网络的基础结构。