wireshark入门 & Wireshark网络问题案例分析

Wireshark进阶之网络问题案例分析

Wireshark的信息统计（Statistics）

每次查看大量数据包流量时，建议从Wireshark的信息统计部分开始进行总的查看，往往能够了解到大体的一些信息，对后续具体的流量分析作用很大。

查看端点（Endpoints），往往可以观察到该数据包中哪些地址的流量较多等信息，可以判断出哪些地址比较可疑等信息
查看会话（Conversations），会话跟端点的区别在于会区别显示哪两个IP在通信，且各自都发送多大的数据等
协议分层（Protocol Hierarchy Statistics），从该窗口中可看出是哪些协议的流量比较多
每次进行流量检查的时候最好先打开这个窗口，方便进行总的流量查看，若不常用的协议流量较多时则可能存在一些异常行为。


数据包长度（Packet Lengths），可以查看数据包的大小所占百分比，如果存在着很多的较大的数据包，则很可能是在传输数据
查看IO图（IO Graphs），显示下载量和下载速度，如下分别为下载慢的和快的

双向时间图（TCP Stream Graph>Round Trip Time Graph），确定是否存在延迟，延迟点的查看即查看峰值较高的点(这个图没找到在哪)

专家信息（Analyze>Expert Info Composite），在Analysis中
四类状态：对话chat（关于通信的基本信息）、注意note（正常通信中的异常数据包）、警告warn（不是正常通信中的异常数据包）、错误error（数据包中的错误，或者解析器解析时错误）。



一些常见的协议包
IPv4头存活时间TTL：TTL值规定了数据包在丢弃之前所能经历的时间或者能够经过的最大的路由数目。
TCP三次握手  SYN----SYN,ACK---ACK
TCP终止FIN   FIN,ACK---ACK;FIN,ACK---ACK(一端发起终止TCP，另一端收到FIN包后，先回复一个ACK包，再发起一个终止包（FIN,ACK）)
TCP重置RST   SYN---RST,ACK
ICMP ping    Echo(ping)request---Echo(ping)reply(Type为8、Code为0意味着这是一个echo请求，Type为0、Code为0意味着这是一个echo响应)
DNS查询（资源记录类型A-IPv4主机地址，NS-权威域名服务器，CNAME-规范别名，MX-邮件交换，TXT-文本字符串，AAAA-IPv6主机地址，IXFR-增量区域传送，AXFR-完整区域传送）

为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

在三次握手的服务器端的回复包中，ack为seq的值+1

1、Wireshark嗅探分别ncat和nc流量来进行无加密和加密传输的对比
nc是明文的，而ncat是加密的。


2.TCP的错误恢复和流量控制机制以及识别、诊断网络慢的问题
1)TCP重传
重传数据包是TCP最基本的错误恢复特性之一。当数据包发送出去但是接收方并没有发送ACK时，发送方会认为原来的数据包已经丢失然后再重传，期间RTO（重传超时）的值会翻倍。整个过程会持续收到接收方发送的ACK或者是发送方重传次数达到最大值为止。
TCP重传包---TCP Retransmission

2)TCP重复确认和快速重传
当接收方收到乱序的数据包时，便发送重复的ACK，且TCP在其头部使用序号和确认号字段来确保数据被可靠接受并以发送顺序重组。
(关键)接收数据的序号+接收数据的字节数=发出的确认号；即回复包的ack值=接收包中的seq值+接收包中的数据长度len值；ack = seq+len

当接收方接收到与计算不一样的序号的时候会假设有数据包丢失了，从而会向发送方发送一个包含丢失的数据包序号的ACK数据包让发送方重传数据包。而当发送方收到3个来自接收方的重复ACK时会立刻发送一个快速重传。重传其间其他所有的正在传输的都停止下来等重传数据包完成传输才能继续传输。



即本端的回复ack中，ack的值=服务器端发来的数据包的seq值+该数据包中的数据长度len
服务器端发送的数据包中的seq值（非该TCP会话的第一个数据包）=本端回复的ack值
本场景为到服务器端下载文件，当TCP三次握手建立成功后：
第一个数据包为：本端先发送了一个PSH,ACK包，该数据包中含有少量数据（其实就是http get请求），即seq=1（wireshark设置的相对序列号），len有值（大小100+）；所以服务器端回复的ACK包中ack值=接收包中的seq+len
然后服务器端开始不断地传回数据，此时可以看到本端只回复ACK确认包，而不会再发送数据。
所以可以发现，本端的所有ACK确认包中，seq值不变，ack值=接收包中的seq+len
而服务器端的所有发来的数据包(wireshark上显示也是为ACK包)中，ack值不会，seq值=上一个本端回复的ack包的ack值。

更简练的总结：最初是的seq为1，ack值=该次tcp会话中接收到的所有数据的len值+1
所以就很简单了：服务器端只有在接收本端的一个PSH,ACK包中有数据，所以服务器端接下来所有的包ack值都不变。seq值等于回复的ack值，而数据发送要连续，所以seq在不断变化
本端接下来只接收数据，而不发送数据，所以seq值不变，而ack值不断变化
服务器端：ack值不变，seq值不断变化（）
本端：seq值不变，而ack值不断变化（）


3)TCP滑动窗口机制
TCP滑动窗口机制用于检测何时发生了数据包丢失并调整数据传输速率加以避免。

窗口大小：服务器会计算客户端在此前发送数据包的速率并计算按如此速率下去接受是否会发生数据包丢失，若可能会发生丢失时，服务器会根据能够接受的速率进行调整返回的ACK数据包的TCP头部窗口大小值来实现数据的正常接受。另外，窗口大小值递减，是主机延迟增加的一个典型指标。

零窗口：有时候服务器会没办法处理客户端发送过来的数据，这是服务器会发送一个数据包指明窗口大小是零，让客户端停止所有的数据传输。但客户端依然会通过发送“保活数据包”来保持和服务器的连接以便确认服务器接受窗口的状态。




4)网络高延迟
正常通信
整个通信过程是相当迅速的，即每个数据包发送的时间不会隔很久：即数据包间隔在0.1秒以内（基本在0.01-0.05之间）

线路延迟
在示例中看到在三次握手时，SYN和SYN,ACK包的间隔较长（1秒左右）；因为这种三次握手的数据包都是无数据的，即使设备再忙，也可以快速响应，排除了设备的可能，所以可能为线路延迟。（原话：因为当服务器收到一个SYN数据包时，它不涉及任何传输层以上的处理，是只需要很小的处理量就能够进行发送一个响应的，即使是在承受巨大的流量负载的时候也一样能迅速响应，从而排除了服务器的可能性。）

HTTP的GET请求从客户端正常发送给服务器之后的，而同样，服务器在发送数据之前先发送一个ACK是不会耗费很多处理资源的，因而这也是线路延迟的一个标志。
（可以参考我个人总结的ack = seq+len）

通过上面的2个示例得出结论：无数据的ack包不涉及任何传输层以上的处理，是只需要很小的处理量就能够进行发送一个响应，即使是在承受巨大的流量负载的时候也一样能迅速响应，所以当这种ack包明显延迟时，可以得出是线路延迟的结论。
线路延迟说明了问题并不是出在客户端或者服务器中，而是线路中的某些设备中，可能是防火墙、代理服务器之类的问题等等。

客户端延迟
如果在tcp三次握手建立后，看到http get请求包有明显延迟，则可以判断是客户端问题。（此时在客户端抓的包）

服务器延迟
当前面的都没问题，http get请求包也顺利发送到了服务器，这时服务器该开始回传数据了，此时若看到服务器的数据包明显延迟过高，则说明是服务器的问题。

小总结（抓包环境为客户端）：
因为ack包无数据，若延迟过高，则判断为线路问题。
http get请求包延迟高，则判断为客户端问题。
http get相应包延迟高，则判断为服务器端问题。


3.抓包分析NMAP工具进行SYN扫描
TCP SYN扫描是依赖于三次握手来确定目标主机上哪些端口是开放的。攻击者会发送TCP SYN数据包到目标主机的一个范围的端口上，假装是要进行建立正常的通信连接，这也是TCP三次握手的第一次。若目标机器回复了TCP SYN/ACK数据包，则表明该端口是打开的，且这时候攻击者是不进行任何回复的，这样导致目标主机会进行3次重传SYN/ACK；若攻击者收到相应的RST数据包，表明端口已经关闭了；若攻击者没有收到任何响应，则意味着端口被某个中间设备过滤了，可能是防火墙或者主机本身。

可以通过“统计”>“会话”中的数据来快速识别哪些端口是开放的或者是关闭的：
其中点击Conversations窗口内的TCP：1994，让packets按从大到小的顺序排序，其中5个包（SYN、SYN/ACK、三次重传SYN/ACK）的端口就是开放的，2个包（SYN、RST）的端口就是关闭的，剩下的都是一个包（SYN）的都是不确定的。



4.被动式操作系统指纹术
“操作系统指纹术”是指在无物理接触的情况下，来确定目标主机运行的操作系统的一组技术，分为主动式和被动式。

主动式主要为使用Nmap发起主动的扫描，然后再与指纹数据库进行对比后确认。而被动式则主要是根据不同操作系统实现的TCP/IP协议栈都必须为这些域定义它自己的默认值来实现识别的原理。

参考：

Wireshark进阶之网络问题案例分析
https://blog.csdn.net/SKI_12/article/details/78333085

 ----------------------------------------------2021.9.8补充------------------------------------------------

TCP/IP协议及常见状态码（URG,SYN,FIN,ACK,PSH,RST）
    https://blog.csdn.net/weixin_41948075/article/details/88074633

TCP每发送一个报文段，便启动一个定时器，若在定时器超时之间还未收到ACK请求确认，就重传该报文
数据包由A的缓冲区发往B，B在收到数据包之后，回发一个ACK确认包给A，之后将数据包从缓冲区释放。（该数据包会一直缓冲在A的缓冲区，直到一个ACK确认为止）

只有ACK标志位为1时，确认序号字段才有效。

------------------------------------------------------------------------------------------------------
标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等。
    URG    指示报文段里存在着被发送方的上层实体标记为”紧急”数据，当URG=1时，其后的紧急指针指示紧急数据在当前数据段中的位置(相对于当前序列号的字节偏移量)，TCP接收方必须通知上层实体。
    ACK    当ACK=0时，表示该数据段不包含确认信息，当ACK=1时，表示该报文段包括一个对已被成功接收报文段的确认。
    PSH    当PSH=1时，接收方在收到数据后立即将数据交给上层，而不是直到整个缓冲区满。
    RST    用于重置一个已经混乱的连接(如主崩溃)，也可用于拒绝一个无效的数据段或者拒绝一个连接请求。一般而言，如果你得到的数据段被设置了RST位，那说明你这一端有问题了。
    SYN    用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。注：捎带是指对客户机到服务器数据的确认被装载在一个承载服务器到客户机的数据
    FIN    用于释放一个连接，表示发送方已经没有数据要传输了。此时，接收方可能继续接收数据，好在SYN和FIN数据段都有序列号，从而保证了这两种数据段以正确顺序被处理


    我的理解：
        PSH 意味着该tcp报文有实际承载的数据，接收方在收到数据后立即将数据交给上层，而不是直到整个缓冲区满。
        RST 用于重置连接or中断连接。

        SYN(Synchronize Sequence Number)同步序列号，表示建立连接；
        ACK(Acknowledgement)即确认字符，表示响应；
        FIN(Finish)表示关闭连接；
        PSH(Push)表示DATA数据传输；
        RST(Reset)表示重置

Wireshark的常用过滤条件
-----------------------------------------------------------------------------------------------------------------------------------
默认绿色是TCP报文，深蓝色是DNS，浅蓝是UDP，黑色标识出有问题的TCP报文——比如乱序报文。

常用排错过滤条件:
对于排查网络延时/应用问题有一些过滤条件是非常有用的：
    tcp.analysis.lost_segment：表明已经在抓包中看到不连续的序列号。报文丢失会造成重复的ACK，这会导致重传。
    tcp.analysis.duplicate_ack：显示被确认过不止一次的报文。大凉的重复ACK是TCP端点之间高延时的迹象。
    tcp.analysis.retransmission：显示抓包中的所有重传。如果重传次数不多的话还是正常的，过多重传可能有问题。这通常意味着应用性能缓慢和/或用户报文丢失。
    tcp.analysis.window_update：将传输过程中的TCP window大小图形化。如果看到窗口大小下降为零，这意味着发送方已经退出了，并等待接收方确认所有已传送数据。这可能表明接收端已经不堪重负了。
    tcp.analysis.bytes_in_flight：某一时间点网络上未确认字节数。未确认字节数不能超过你的TCP窗口大小（定义于最初3此TCP握手），为了最大化吞吐量你想要获得尽可能接近TCP窗口大小。如果看到连续低于TCP窗口大小，可能意味着报文丢失或路径上其他影响吞吐量的问题。
    tcp.analysis.ack_rtt：衡量抓取的TCP报文与相应的ACK。如果这一时间间隔比较长那可能表示某种类型的网络延时（报文丢失，拥塞，等等）。

------------------------------------------------------------------------------------------------------------------------------------
抓取指定IP地址的数据流（这个是抓包过滤器，应该还是建议少用抓包过滤器吧。。。）:
    如果你的抓包环境下有很多主机正在通讯，可以考虑使用所观察主机的IP地址来进行过滤。以下为IP地址抓包过滤示例：
        host 10.3.1.1：抓取发到/来自10.3.1.1的数据流
        host 2406:da00:ff00::6b16:f02d：抓取发到/来自IPv6地址2406:da00:ff00::6b16:f02d的数据流
        not host 10.3.1.1：抓取除了发到/来自10.3.1.1以外的所有数据流
        src host 10.3.1.1：抓取来自10.3.1.1的数据流
        dst host 10.3.1.1：抓取发到10.3.1.1的数据流
        host 10.3.1.1 or 10.3.1.2：抓取发到/来自10.3.1.1，以及与之通讯的所有数据流，与10.3.1.2，以及与之通讯的所有数据流
        host www.espn.com：抓取发到/来自所有解析为www.espn.com的IP地址的数据流
        
    抓取指定IP地址范围的数据流:
    当你需要抓取来自/发到一组地址的数据流，可以采用CIDR(无类别域间路由，Classless Interdomain Routing)格式或使用mask参数。
        net 10.3.0.0/16：抓取网络10.3.0.0上发到/来自所有主机的数据流(16表示长度)
        net 10.3.0.0 mask 255.255.0.0：与之前的过滤结果相同
        ip6 net 2406:da00:ff00::/64：抓取网络2406:da00:ff00:0000(IPv6)上发到/来自所有主机的数据流
        not dst net 10.3.0.0/16：抓取除了发到以10.3开头的IP地址以外的所有数据流
        not src net 10.3.0.0/16：抓取除了来自以10.3开头的IP地址以外的所有数据流
        ip proto <protocol code>：抓取ip协议字段等于<protocol code>值的报文。如TCP(code 6), UDP(code 17), ICMP(code 1)。
        ip[2:2]==<number>：ip报文大小
        ip[8]==<number>：TTL(Time to Live)值
        ip[9]==<number>：协议值
        icmp[icmptype]==<identifier>: 抓取 ICMP代码等于identifier的ICMP报文, 如icmp-echo 以及 icmp-request。
        方括号中第一个数字表示从协议头开始的偏移量，第二个数字表示需要观察多少位。

 

TCP序列号（Sequence Number）、下一个序列号（Next Sequence Number）、确认号（Acknowledgment Number）
=============================================================================================================
序列号（Sequence Number）：
    1.TCP会话的每一端都包含一个32位（bit）的序列号，该序列号被用来跟踪该端发送的数据量。
        next sequence number = sequence number + TCP Segment len
    2.当某个主机开启一个TCP会话时，他的初始序列号是随机的，可能是0和4,294,967,295之间的任意值
    3.像Wireshark这种工具，通常显示的都是相对序列号/确认号，而不是实际序列号/确认号，相对序列号/确认号是和TCP会话的初始序列号相关联的。
确认号（Acknowledgment Number）：
    1.每一个包中都包含序列号，在接收端则通过确认号用来通知发送端数据成功接收

我的小结：
    1.可以通过tcp的序列号判断本端已经发送了多少数据（bytes）
    2.当一个包的sequence number = next sequence number，意味着该tcp包不含有用户数据；可能是同步包（SYN包），请求重传包等
    3.发起建立连接的TCP SYN包，看起来是没有用户数据的，但是 next sequence number = sequence number + 1 ？？？？
    4.目前看来，有部分next sequence number = sequence number + 1；但是也有部分next sequence number = sequence number + 0
        next sequence number = sequence number + 0：目前发现的为ACK包；
        next sequence number = sequence number + 1：目前发现的为SYN包，FIN+ACK包；
        next sequence number = sequence number + N：TCP报文有实际数据


理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）https://blog.csdn.net/a19881029/article/details/38091243

TCP的2种重传：TCP超时重传、TCP快速重传
------------------------------------------------------------------------------------------------------------
TCP超时重传
    默认情况下，Windows主机默认重传5次。大多数Linux系统默认最大15次。两种操作系统都可配置。
    重传计时器（retransmission timer），它的主要功能是维护重传超时（RTO）值
    RTT(Round Trip Time)：一个连接的往返时间，即数据发送时刻到接收到确认的时刻的差值；
    RTO(Retransmission Time Out)：重传超时时间，即从数据发送时刻算起，超过这个时间便执行重传。
    RTT和RTO 的关系是：由于网络波动的不确定性，每个RTT都是动态变化的，所以RTO也应随着RTT动态变化。


    TCP的超时重传之深入了解RTT与RTO  https://blog.csdn.net/whgtheone/article/details/80970292
        在[RFC 6298]中，推荐初始超时重传时间为1秒，当出现超时后，超时重传时间将以指数退避的方法加倍，以免即将被确认的后继报文段过早出现超时。
------------------------------------------------------------------------------------------------------------
TCP快速重传：https://blog.csdn.net/whgtheone/article/details/80983882?spm=1001.2014.3001.5501
    TCP报文是按照顺序发出的；但是接收端收到报文却不一定是按序的，这是由于丢包or乱序造成的（数据包走的不同路径，导致后发先至）

    TCP在收到3个冗余ack报文时，将会进行快速重传，在重传计时器超时之前，重传报文。
    TCP发送报文并不是逐个发送的，而是一次性发送多个报文，例如发送端一次性发送5个报文，seq序列号为11,12,13,14,15；
        假设seq12丢包：
            1.接收端收到seq11后，回复ack12；
            2.收到seq13后，回复ack12（重复ack），并且将seq13置于缓存中。
            3.seq14、seq15处理方式同seq13。
            4.收到3个冗余ack12后，发送端快速重传seq12。
            5.接收端收到seq12后，由于缓存中已存在seq13/14/15，所以回复ack16。
        假设seq12乱序，最晚到达：
            1.接收端收到seq11后，回复ack12；
            2.收到seq13后，回复ack12，并且将seq13置于缓存中。
            3.seq14、seq15处理方式同seq13。
            4.（会触发tcp快速重传），但是此时接收到了seq12；由于接收端缓存存在seq13/14/15，所以回复ack16。

 

零窗口和探测报文；网络延迟高；TCP重置报文段及RST常见场景分析
============================================================================================================================
零窗口和探测报文
滑动窗口直接与服务器无法接收和处理报文有关，任何窗口大小的缩小以及零值都是服务器问题的直接结果。所以如果你在哪里看到这两者之一发生，就应该在那里深入研究。通常应当在网络通讯两端一直主机窗口更新报文。

----------------------------------------------------------------------------------------------------------------------------
网络延迟高---wireshark解析：https://www.ktanx.com/blog/p/4124
sys、sys,ack、ack这些报文因为不需要进行应用程序处理，所以即使服务器繁忙，也可以快速回复。
线路延迟高：客户端发起tcp连接请求，发出sys包，接收回复的sys，ack包慢，则可以判断为线路延迟高。
客户端负载高：客户端收到sys，ack包后，快速响应，发出ack包；但是之后的data包却延迟较高。这很可能是由于客户端负载高，导致应用层数据包封装慢导致的。
服务器负载高：服务器在收到请求，例如在接收到get请求后，快速响应ack包，但是之后的data包却延迟高，这很可能是由于服务器负载高，导致应用层数据包封装慢导致的。

------------------------------------------------------------------------------------------------------------------------------
TCP重置报文段及RST常见场景分析 
    https://www.cnblogs.com/s-lisheng/p/11286708.html
    https://blog.csdn.net/p656456564545/article/details/86570581

RST表示连接重置，用于关闭那些已经没有必要继续存在的连接。一般情况下表示异常关闭连接，区别与四次分手正常关闭连接。
    在TCP协议中RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。
    发送RST包关闭连接时，不必等缓冲区的包都发出去，直接就丢弃缓存区的包发送RST包。
    而接收端收到RST包后，也不必发送ACK包来确认。
产生RST的三个条件是：
    1.目的地为某端口的SYN到达，然而在该端口上并没有正在监听的服务器；
    2.TCP想取消一个已有连接；
    3.TCP接收到一个根本不存在的连接上的分节。

RST常见场景分析：
    1、针对不存在端口的连接请求
        客户端尝试与服务器未对外提供服务的端口建立TCP连接，服务器将会直接向客户端发送reset报文。
        
    2、接收端收到TCP报文，但是发现该TCP的报文，并不在其已建立的TCP连接列表内，则其直接向对端发送reset报文（例如TCP 半开连接）
        如果在未告知另一端的情况下通信的一端关闭或终止连接，那么就认为该条TCP连接处于半开状态。
        a.举个例子，服务器主机被切断电源后重启（切断电源前可将网线断开，重启后再接上），此时的客户端是一个半开的连接。当客户端再次向服务端发送数据时，服务端对此连接一无所知，会回复一个重置报文段RST后，中断连接。
        b.如果一个已关闭的TCP连接又收到数据，显然是异常的，此时应RST中断连接。
        c.再或者如果程序开启了TCP保活机制，则当监测到对方主机不可达时，发送RST中断连接。
        d.连接超时（某些应用设置的超时时间过短，例如设置了100ms）

    3、提前关闭连接
        a.TCP应用程序接收数据是从操作系统中接收的TCP数据，如果数据到达了操作系统但是我应用数据不想继续接收数据了，此时RST中断连接。
        b.客户端和服务器的某一方在交互的过程中发生异常（如程序崩溃等），该方系统将向对端发送TCP reset报文，告之对方释放相关的TCP连接
        c.在交互的双方中的某一方长期未收到来自对方的确认报文，则其在超出一定的重传次数或时间后，会主动向对端发送reset报文释放该TCP连接

    4、终止一条连接
        终止一条连接的正常方法是由通信一方发送一个FIN。这种方法也被称为有序释放。因为FIN是在之前所有排队数据都已发送后才被发送出去，通常不会出现丢失数据的情况。
        然而在任何时刻，我们都可以通过发送一个重置报文段RST替代FIN来终止一条连接。这种方式也被称为终止释放。
        终止一条连接可以为应用程序提供两大特性：
            任何排队的数据都将被抛弃，一个重置报文段会被立即发送出去；
            重置报文段的接收方会说明通信的另一端采用了终止的方式而不是一次正常关闭。API必须提供一种实现上述终止行为的方式来取代正 常的关闭操作。

    5、有些应用开发者在设计应用系统时，会利用reset报文快速释放已经完成数据交互的TCP连接，以提高业务交互的效率

 

Wireshark中常见的TCP Info ：https://blog.csdn.net/faithc/article/details/52832617

1. TCP out-of-order segment（很大可能是TCP存在乱序或丢包，导致接收端的seq number不连续）
    Wireshark判断TCP out-of-order是基于TCP包中SEQ number并非期望收到的下一个SEQ number，则判断为out-of-order。

2. TCP Previous segment not captured（数据包被分片，前一个TCP分段没有抓到）
    要发送的数据包较大时，TCP会对该数据包进行分片；
    这些分片的包会被标记了“TCP segment of a reassembled PDU”（这个标识在wireshark中可以看到），使用不同的seq number，但使用相同的ack number。
    前一个分片中的next seq number字段指定了下一个分片的seq number
    假如收到的下一个分片的seq number与上一个比不连续的话，wireshark就会将该分片标记为TCP Previous segment not captured。

3. TCP Spurious Retransmission（TCP虚假重传）和TCP Retransmission（TCP重传）
    当抓到2次同一包数据时，wireshark判断网络发生了重传
        1.若同时抓到了该重传包的ack报文，则判断为TCP虚假重传
            举例：一端因为RTO超时，触发重传；而另一端实际有发送ack，并且也能到达，只不过太慢了。。。此时会判断为TCP虚假重传
        2.若同时没抓到重传包的ack报文，则判断为TCP重传
    
    小总结：有条件，建议2端都进行抓包。
        假设一种情况，客户端发送数据包，正常到达；服务端回复ack时，丢包。
        客户端抓包：TCP重传
        服务端抓包：TCP虚假重传（因为服务端有回复ack，并被wireshark抓到）

4. TCP fast Retransmission（TCP快速重传）和TCP Dup ACK（TCP重复ack）
    TCP快速重传通过接收到3个或3个以上重复ack反馈触发。
    当网络中存在乱序或者丢包时，将会导致接收端接收到的seq number不连续。此时接收端会向发送端回复重复ack，ack值为期望收到的下一个seq number。重复ack数大于等于3次将会触发快速重传。

5. TCP window update（TCP窗口更新）
    当接收方的TCP window发生突变时，接收方通过TCP window update消息告知对方当前的接收窗口大小

6. TCP acked unseen segment（反馈ACK指向了一个未知的TCP片段）
    很可能是wireshark漏抓了这个包，但却抓到了对端反馈的该报的ack包。

7. TCP ZeroWindow
    TCP滑动窗口为0。
    当发送端发包速率大于接收端的接收速率时，会造成接收端TCP window越来越小，当接收端在反馈ack时携带的window size=0时，wireshark标记TCP Zero window。此时发送端将暂停发送数据，直到收到接收端window size!=0的标志。

8. TCP window full
    是指的发送端发送的数据已经达到的接受窗口的上限。发送端暂停发送，等待新的接收窗口的通告。

9.TCP RST（TCP 重置）
    详见（TCP重置报文段及RST常见场景分析）

10. TCP PSH
    我的总结：一般传输数据时，会携带PSH

 

一站式学习Wireshark：https://www.ktanx.com/blog/p/4112
wireshark样本下载：https://wiki.wireshark.org/SampleCaptures
Wireshark中常见的TCP Info ：https://blog.csdn.net/faithc/article/details/52832617