#头条家时光#
一、着色规则
二、专家信息
三、TCP INFO
四、常见表达式
五、列信息增删
一、着色规则
在 wireshark监控界面上，不同的报文会显示不一样样的颜色，它们分别表示不同的含义；而这些颜色，都是是由着色规则设置的：
在默认的着色规则中，一般黑色背景代表报文的各类错误，红色背景代表各类异常情景，其它颜色代表正常。
着色规则分析：
1.1、Bad TCP： tcp.analysis.flags && !tcp.analysis.window_update && !tcp.analysis.keep_alive && !tcp.analysis.keep_alive_ack
即 TCP包损坏，通常表示为重传，乱序，丢包，重复响应等都在此条规则的范围内。具体看第三大点。
1.2、HSRP State Change： hsrp.state != 8 && hsrp.state != 16
HSRP即热备份路由协议（Hot Standby Router Protocol），这条规则表明当前报文状态非 Standby和 Active。
HSRP的状态值可以是以下几种：
0 - Initial
1 - Learn
2 - Listen
4 - Speak
8 - Standby
16 - Active
1.3、Spanning Tree Topology Change： stp.type == 0x80
当生成树协议的状态标记为 0x80，表示着生成树拓扑发生变化。即 STP协议数据单元 (BPDU) 的 flag 字段发生变化（使用 IEEE-802.1d）：
1.4、OSPF State Change： ospf.msg != 1
OSPF（Open Shortest Path First，开放式最短路径优先协议）的 msg类型不是Hello报文。
OSPF报文的类型，有下面几种类型：Hello报文；DD报文；LSR报文；LSU报文；LSAck报文。
1.5、ICMP errors： icmp.type eq 3 || icmp.type eq 4 || icmp.type eq 5 || icmp.type eq 11 || icmpv6.type eq 1 || icmpv6.type eq 2 || icmpv6.type eq 3 || icmpv6.type eq 4
ICMP协议错误，协议的 type字段值错误。
1.6、ARP： arp 即 ARP协议。
1.7、ICMP： icmp || icmpv6 即 ICMP协议。
1.8、TCP RST： tcp.flags.reset eq 1 TCP流产生 reset。
1.9、SCTP ABORT： sctp.chunk_type eq ABORT SCTP（即流控制传输协议）发生中止。
1.10、TTL low or unexpected： ( ! ip.dst == 224.0.0.0/4 && ip.ttl < 5 && !pim && !ospf) || (ip.dst == 224.0.0.0/24 && ip.dst != 224.0.0.251 && ip.ttl != 1 && !(vrrp || carp))
TTL (Time-To-Live) 指解析记录在本地 DNS服务器中的缓存时间。该规则表示 TTL产生异常。
在 IP组播中，通过 TTL控件来管理转发数据包的范围，按照惯例：
0 - 仅限于同一主机上
1 - 被限制在同一个子网内
32 仅限于同一站点
64 - 仅限于同一区域
128 - 仅限于同一大陆
255 - 不受限制
1.11、Checksum Errors： eth.fcs.status == “Bad” || ip.checksum.status == “Bad” || tcp.checksum.status == “Bad” || udp.checksum.status == “Bad” || sctp.checksum.status == “Bad” || mstp.checksum.status == “Bad” || cdp.checksum.status == “Bad” || edp.checksum.status == “Bad” || wlan.fcs.status == “Bad” || stt.checksum.status == “Bad”
条件中的各类协议的 checksum出现异常。
1.12、SMB： smb || nbss || nbns || netbios Server Message Block类协议。
1.13、HTTP： http || tcp.port == 80 || http2
Hyper Text Transfer Protocol（超文本传输协议），这是很简陋的识别方法。
1.14、DCERPC： dcerpc
即 DCE/RPC，分散式运算环境/远端过程调用（Distributed Computing Environment / Remote Procedure Calls）协议。
1.15、Routing： hsrp || eigrp || ospf || bgp || cdp || vrrp || carp || gvrp || igmp || ismp
路由类协议。
1.16、TCP SYN/FIN： tcp.flags & 0x02 || tcp.flags.fin == 1
TCP连接的起始和关闭。
1.17、TCP： tcp TCP协议。
1.18、UDP： udp UDP协议。
1.19、Broadcast： eth[0] & 1 广播数据。
1.20、System Event： systemd_journal || sysdig
系统调用及系统事件等系统活动。
二、专家信息
在报文的信息栏中，通常也有颜色限定，如下图：
而这次的颜色区别是属于对应的信息条目的：
每个专家信息项都有一个严重性级别。使用以下级别，从最低到最高。Wireshark 使用不同的颜色标记它们：
聊天（蓝色）
有关常用的工作流程信息，例如设置了 SYN 标志的 TCP 数据包；数据包都符合常规流量的特征，包括 SYN、FIN、RST以及各种状态码的HTTP事件。
注意（青色）
值得注意的事件，例如应用程序返回了一个常见的错误代码，例如 HTTP 404；数据包中有可能会引发故障的异常现象，例如TCP重传、重复确认、快速重传等现象。
警告（黄色）
警告，例如应用程序返回异常错误代码，如连接问题。
与 TCP窗口有关的事件 TCP window full或TCP zero window，一般是连接设备忙不过来所致。
与 TCP报文段丢失或失序有关的事件，丢失是因为未抓全某个 TCP数据流的所有 TCP报文段；失序是因其感知到了TCP报文段未按发出的顺序到达接收主机。
错误（红色）
严重的问题。
校验和错误：Ethernet及IP校验和错误。
伪造的数据包：一般涉及具体的应用层协议。
三、TCP Info
3.1、ACK信息
3.1.1、TCP ACKed unseen segment
表示 Wireshark发现该条 ACK在整个网络包中找不到所对应的 Seq（排除了乱序），就会提示。
如图，在这组网络中，第 296号包出现这种情况，然后在上面的包中是找不到它所对应的 Seq的。
3.1.2、TCP Dup ACK < frame > # < acknowledgement number >
重复 ACK包，当收发不稳定时，会出现重复响应的情况；而这种情况就是响应端会向请求端回复重复 ACK。# 符号前面的数字表示对应的重复包号，后面的数字表示确认次数，也可以说是出现的次数。
如图，在第 31191号包的信息中可以看到提示是说跟第 31188号包出现重复，通过查看第 31188号包，而这一包其实是为了响应第 31187号的。
3.1.3、TCP Fast Retransmission
标志着前面接收到重复的 ACK包（即出现了 [TCP Dup ACK] ）达 3个或 3个以上，进而触发了 TCP的快速重传（这是 RFC的规定）。
如图， [TCP Dup ACK] 出现了 3次，而且都是对应第 1309号包，因此触发快速重传包第 1330号包，重传了第 1309号包所响应的请求包第 1245号包，如下图：
然后通过对比原包第 1245号包和快速重传包第 1330号包，你会发现并不相同，实际上原始数据应该是相同的，只不过数据加密了，才出现不同的现象。
3.2、保活探测
3.2.1、TCP Keep-Alive
这个应该不陌生，一般 TCP长链接时，如果启用保活功能，则在特定时间段没有数据交互，那么将会传输一条保活字段，如下图：
3.2.2 、TCP Keep-Alive ACK
作为上一点 [TCP Keep-Alive] 的响应包，例图看上一张。
3.3、乱序 or 丢包
3.3.1、TCP Out-Of-Order
标志着 TCP传输出现乱序。
如图，在 TCP传输过程中（不包括三次握手和四次挥手），同一台主机发出的数据包应该是连续的，即后一个包的 Seq号等于前一个包的 Seq + Len；也可以说，后一个包的 Seq会大于或等于前一个包的 Seq。当 Wireshark发现后一个包的 Seq值小于前一个包的 Seq + Len时，就会认为是乱序了，因此标志 [TCP Out-of-Order]。
在连续传输数据过程中，可以看到从第 330号包一直到第 337包被标志为乱序这几个包，应当是连续的，但是可以发现第 336号包跟第 337号包调转了，因此第 336号包被标志为上一包未捕获，而第 337号包则被标志为乱序。
然后来分析一下，例如第 337号包的 Seq = 83518，Len = 1380，那么 Seq + Len = 84898，可以发现其实该包列栏中 Sequence Number 的 83518 数据对应 Seq，NextSequence Number 的 84898 数据对应 Seq + Len。根据上面的结论，在发生错误前的第 335号包它的 NextSequence Number 表明下一包第 336号包的 Seq值应当是 83518 ，但是实际上第 336号包的 Seq值为 84898 ，当到了第 337号包的时候，才出现理应对应的值 83518 ，这时 Wireshark通过对比在发生错误前的第 335号包至理论连续的第 337号包之间看是否有出现调转包，有则标志 [TCP Out-of-Order]。一般出现 [TCP Out-of-Order] 时都会伴随出现 [TCP Previous segment not captured] 。
3.3.2、TCP Previous segment not captured
在 TCP传输过程中，同一台主机发出的数据段应该是连续的，即后一个包的 Seq号等于前一个包的 Seq + Len（三次握手和四次挥手是例外）。如果 Wireshark发现后一个包的 Seq值大于前一个包的 Seq + Len，就知道中间缺失了一段数据。
依然沿用上一张图，在发生错误前的第 335号包 Seq + Len 值为 83518 ，但下一包的 Seq值为 84898 ，因此出现后一个包的 Seq值大于前一个包的 Seq + Len，而非等于，所以预示着该数据包的上一个包未捕获到，但后面我们也有发现虽然显示上一个包未捕获到，实际紧随它的后一个包就是它们之间的数据包，只是调转了包而已。
3.4、端口
TCP Port numbers reused
这个死活没捕捉出来，就简单说一下吧。
当发送 SYN 标志时（不是 SYN + ACK），如果已经存在一个使用相同地址和端口的现有会话，那么将会被 Wireshark标记 [TCP Port numbers reused]。
3.5、重传
3.5.1、TCP Spurious Retransmission
TCP虚假重传，意味着发送端认为发送的包已经丢失了，然后就重传了，尽管此时接收端已经发送了对这些包的确认（确认还没收到或者已经丢失了）。
如图，第 459号包出现虚拟重传现象，实际为第 453号包的重传，可从显示来看第 453号包是已经是得到接收端的 ACK响应了，理论来讲是不会重传的，但前面也有说到了，可能会出现接收端确认了请求（已经发出去了），发送端却还没收到或者已经丢失了，那么发送端将会重传数据，而由于这时这段数据包在初包发送后接收端有回一次请求，这次重传相当于接收端又回了一次请求（即重复了两次响应，可以看到第 460号包标志为 [TCP Dup ACK] 了），所以对于这种有回 ACK还重传的数据包将被标志为 [TCP Spurious Retransmission] 。然后至于为什么是重传了第 453号包，可以看到第 460号包的信息提示，这是 ACK响应第 459号包的，但同时也是跟第 454号包重复，而第 454号包对应响应第 453号包的，那自然而然地得到第 459号包为第 453号包的重传。
3.5.2、TCP Retransmission
TCP重传，与上面不同的是如果一个包不确定是否丢了，但它又没有像上面 [TCP Spurious Retransmission] 那样得到接收端的 ACK响应，那它大概率就是丢包了，就不会快速重传；而针对这种情况，发送方也就只好等到超时了再重传，此类重传包就会被 Wireshark标志 [TCP Retransmission] 。
如图，第 33号包被标志为 [TCP Previous segment not captured]，预示着有可能出现丢包，并且在后面一段时间内也没有像前面那样有标志 [TCP Out-Of-Order]提示的包，排除了乱序情况，最终等待超时，重传数据包，于是第 33号重传包就有了 [TCP Retransmission]标志。TCP重传是 TCP通讯中常有的事情，有时候看到一大堆黑漆漆一片的 error事件，可能就是这种情况。
3.6、TCP Window
3.6.1、TCP Window Full
顾名思义，就是窗口已满，指的发送端发送的数据已经达到的接受窗口的上限；那么发送端暂停发送，等待新的接收窗口的通告。
如图，在这组数据中，从第 526323号包开始，出现了 [TCP Window Full] 表明发送数据达到上限了，同时还有另一个 [TCP Spurious Retransmission] 表明了虚假重传，但可惜的是接收端后续都没有响应，最终导致在发送 RST 报文后，关闭 TCP连接。
3.6.2、TCP Window Update
TCP协议允许随时改变窗口的大小，并且通过发送标识有 WindowUpdate 的报文通知对端；或者当接收端的应用程序消耗完了已经从 RX 缓冲区接收到的数据时，也会发生 WindowUpdate，以指示缓冲区中现在有更多可用空间；以上这些数据包将被标志 [TCP Window Update]。[TCP Window Update] 是 TCP通信中的一个状态，它可以发生的原因还有有很多，通常在 TCP ZeroWindow 条件发生后看到。
3.6.3、TCP ZeroWindow
如图，当接收窗口值大小为零（Win = 0）且非 SYN、FIN 或 RST 数据时设置。
在每个 TCP报头中的窗口字段表明着接收端可以接受的数据量大小；如果接收端不能接受任何数据，它将把窗口值设置为零，这告诉发送端暂停其传输。在某些特定情况下，这是正常的，例如，打印机可能会在加载或翻转一张纸时使用零窗口暂停打印作业的传输；然而，在大多数情况下，这表明接收端存在性能或容量问题。恢复暂停的连接可能需要很长时间(有时需要几分钟)，即使导致零窗口的底层条件很快就会清除。
3.6.4、TCP ZeroWindowProbe
当通信的一方接收到 TCP ZeroWindow 报文后，会定时发送 TCP ZeroWindowProbe 报文进行探测；探测报文是需要发送下一字节数据，然后通过接收端的响应，由此来判断接收端窗口值是否仍然为 0，如果接收方回复窗口大小仍然为零，则发送端继续探测。ZeroWindowProbe 它有助于证明发送端已经确认到接收端其 TCP 窗口大小为零，但仍试图让数据继续交互而非关闭通讯。
3.6.5、TCP ZeroWindowProbeAck
作为 [TCP ZeroWindowProbe] 的 ACK应答，结合 TCP ZeroWindowProbe 理解。ZeroWindowProbeAck 数据包的存在也表明网络正在传递数据包并且设备没有关闭。
3.7、交互
TCP Conversation Completeness
SYN——SYN-ACK——ACK——DATA——FIN——RST
四、常见表达式
4.1、运算符
4.2、逻辑符
4.3、协议过滤
ip.proto == xxx
note: xxx表示为对应的协议，如 TCP：ip.proto == TCP
TCP： 只显示 TCP协议的数据流
UDP： 只显示 UDP协议的数据流
HTTP： 只显示 HTTP协议的数据流
ICMP： 只显示 ICMP协议的数据流
ARP： 只显示 ARP协议的数据流
DNS： 只显示 DNS协议的数据流
4.4、IP过滤
ip.addr == 192.168.116.138 ，只显示 IP地址为 192.168.116.138 有关的数据流
ip.src == 192.168.116.138 ，只显示源 IP地址为 192.168.116.138 的数据流
ip.dst == 192.168.116.138 ，只显示目标 IP地址为 192.168.116.138 的数据流
4.5、端口过滤
tcp.port == 80 ，只显示 80端口 TCP数据流
udp.prot == 67 ，只显示 67端口 UDP数据流
tcp.srcport == 80 , 只显示源地址的 80端口数据流
tcp.dstport == 80 ，只显示目的地址 80端口数据流
4.6、过滤HTTP协议
http.request.method == "GET" ，显示 GET请求
http.request.method == "POST" ，显示 POST请求
http.request.code == 404 ，显示状态码为 404
五、列信息增删
5.1、增加列信息
在报文的信息栏，选着想要显示的信息，右键点击添加：
5.2、删除列信息
在监控报文栏，选择不需要的列，右键选中：
5.3、隐藏列信息
同样在监控报文栏操作，随便选择一列，右键选中，然后把想要隐藏的列去掉勾选，这里就不放图了。