报文分析笔记---常见wireshark报文标记

曾经终败给现在 2022-11-25 13:19 1075阅读 0赞

### 文章目录 ###

*  报文分析笔记---常见wireshark报文标记
 *   *  Fragmented IP protocol
     *  Packet size limited during capture
     *  TCP Previous segment not captured
     *  TCP ACKed unseen segment
     *  TCP Out-of-Order
     *  TCP Dup ACK
     *  TCP Fast Retransmission
     *  TCP Spurious Retransmission
     *  TCP Retransmission
     *  TCP zerowindow
     *  TCP window Full
     *  TCP window Update
     *  TCP port numbers reused
     *  TCP segment of a reassembled PDU
     *  Continuation to
     *  Time-to-live exceeded (Fragment reassembly time exceeded)
     *  TCP keep-alive
     *  TCP keep-alive ACK

# 报文分析笔记—常见wireshark报文标记 #

## Fragmented IP protocol ##

Fragmented IP protocol  ----报文分片

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70][]  
关于报文分片，会在wireshark中有首选项进行配置；  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 1][]  
当前取消勾选后：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 2][]  
关于该配置的说明：

简单说明，

开启该选项时，wireshark 会尝试重组分片报文，并会在成功重组报文之前，只会将报文分片解析为IP协议数据报文，即第一副图的IPV4协议报文；当然如第一图，分片后的IPV4报文并没有成功重组；

关闭该选项时，wireshark 不会进行分片报文的重组，直接解析，所以对于分片报文而言，可能会有异常的标记，需要注意；

第一副图IPV4报文未成功重组的原因，是环境异常，定位后原因为原始数据报文是IPIP隧道封装的双层报文，在数据传输中，途径的一个网元节点，是按照外层报文进行的分片hash，导致分片报文被hash到了不同的后端节点上，进而不能正确重组；即大包做了外层分片，不能保证同一个大包的不同分片能hash到同一个LD；

关于wireshark该选项的引用说明：

https://wiki.wireshark.org/IP\_Reassembly

https://www.wireshark.org/lists/wireshark-users/200706/msg00116.html

> IP Reassembly
> 
> IP Reassembly is a feature in Wireshark and TShark to automatically reassemble all fragmented [IP][] Datagrams into a full [IP][] packet before calling the higher layer dissector.
> 
> This feature will require a lot of extra memory to be consumed by wireshark in order to store the reassembly buffers and is disabled by default.
> 
> To enable IP Reassembly, go to preferences and tick the box for reassembly
> 
> When you enable IP Reassembly several things in TShark and Wireshark change. First of all, Wireshark will no longer dissect the [UDP][] or [TCP][] header (or any protocol above these) in the frame that contained the header of the [IP][] packet any more. Instead, the calling of the [UDP][] or [TCP][] protocol dissectors will be deferred until all [IP][] fragments have been received and the full [IP][] datagram has been fully reassembled.
> 
> This difference shows up as that without IP Reassembly the upper layer protocol, [UDP][] or [TCP][] and whatever sits above it, as much as was present in this frame of the initial fragment (where fragment offset is 0) will be dissected and displayed for that particular frame. This frame will also usually have an information text in the packet summary line along the lines of “\[Short Frame\]”. All the other \[IP Fragment\](https://wiki.wireshark.org/IP Fragment)s for this [IP][] datagram will be dissected only up to and including the [IP][] layer.
> 
> When this feature is enabled, dissection of the [IP][] datagram will be deferred until that packet in the capture where the full [IP][] datagram was completely reassembled.
> 
> This means that some packets that are using reassembly, such as [NFS][]over[UDP][], will dissect differently, and even in different frames when IP Reassembly is enabled.
> 
> IP Reassembly is an all-or-nothing feature. If not every single \[IP Fragment\](https://wiki.wireshark.org/IP Fragment) required to complete the reassembly can be found in the capture, then nothing at all will be dissected. Not even the [TCP][] or [UDP][] layer.
> 
> Common reasons why IP Reassembly fails to reassemble packets:
> 
>  *  Short packets. You have captured packets with a [SnapLen][] less than the [MTU][] of the link and thus some of the packet(s) content are missing, then Wireshark will not even try to perform reassembly.
>  *  IP Header Checksum is invalid. If the IP Header Checksum is invalid, then the IP Reassembly function will ignore the packet.
>  *  Some of the \[IP Fragment\](https://wiki.wireshark.org/IP Fragment)s are just plain missing from the capture. This is a fact of life, you will never have a guarantee that every single packet that went across the wire was actually captured and written to the Capture File. sorry that is just a fact of life
> 
> Beware
> 
> This feature WILL consume a lot of additional memory at runtime if there are \[IP Fragment\](https://wiki.wireshark.org/IP Fragment)s present in the trace. It is a very very bad idea to enable this feature for huge [NFS][]over[UDP][] traces since that will eat memory like there is no tomorrow.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 3][]

## Packet size limited during capture ##

该标记说明对应报文未抓全；

例如该片报文长度44 byte ，抓包只抓到了20 byte，就会出现该标记提示；

可能和抓包方式有关系，在抓包时，无论是tcpdump/wireshark 都可以配置抓包长度；tcpdump 选项 -s 指定抓包长度；

# 模拟命令，规避该现象可以 tcpdump -s0 抓取全部报文长度；
    tcpdump -i any -nne -vv -s 40 icmp -w icmp_size_limited_during_capture.pcapng

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 4][]

## TCP Previous segment not captured ##

在TCP传输过程中，同一台主机发出的数据段应该是连续的，即后一个包的Seq号等于前一个包的Seq Len（三次握手和四次挥手是例外）。如果Wireshark发现后一个包的Seq号大于前一个包的Seq Len，就知道中间缺失了一段数据。假如缺失的那段数据在整个网络包中都找不到（即排除了乱序），就会提示［TCP Previous segment not captured］。比如在图2这个例子中，6号包的Seq号1449大于5号包的Seq Len=1 0=1，说明中间有个携带1448字节的包没被抓到，它就是“Seq=1, Len=1448”。

![20200809165238977.png][]

网络包没被抓到还分两种情况：一种是真的丢了；另一种是实际上没有丢，但被抓包工具漏掉了。在Wireshark中如何区分这两种情况呢？只要看对方回复的确认（Ack）就行了。如果该确认包含了没抓到的那个包，那就是抓包工具漏掉而已，否则就是真的丢了。

顺便分析一下图2这个网络包，它是HTTPS传输异常时在客户端抓的。因为“Len: 667”的小包（即6号包）可以送达，但“Len: 1448”的大包却丢了，说明路径上可能有个网络设备的MTU比较小，会丢弃大包。后来的解决方式证实了这个猜测，只要把整个网络路径的MTU保持一致，问题就消失了。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 5][]

## TCP ACKed unseen segment ##

当Wireshark发现被Ack的那个包没被抓到，就会提示 \[TCP ACKed unseen segment］。这可能是最常见的Wireshark提示了，幸好它几乎是永远可以忽略的。以图3为例，32号包的Seq Len=6889 1448=8337，说明服务器发出的下一个包应该是Seq=8337。而我们看到的却是35号包的Seq=11233，这意味着8337～11232这段数据没有被抓到。这段数据本应该出现在34号之前，所以Wireshark提示了\[TCP ACKed unseen segment\]。

![20200809165323771.png][]

不难想象，在一个网络包的开头会经常看到这个提示，因为只抓到了后面的Ack但没抓到前面的数据包。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 6][]  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 7][]

## TCP Out-of-Order ##

在TCP传输过程中（不包括三次握手和四次挥手），同一台主机发出的数据包应该是连续的，即后一个包的Seq号等于前一个包的Seq Len。也可以说，后一个包的Seq会大于或等于前一个包的Seq。当Wireshark发现后一个包的Seq号小于前一个包的Seq Len时，就会认为是乱序了，因此提示 \[TCP Out-of-Order\] 。如图4所示，3362号包的Seq=2685642小于3360号包的Seq=2712622，所以就是乱序。

![20200809165435530.png][]  
小跨度的乱序影响不大，比如原本顺序为1、2、3、4、5号包被打乱成2、1、3、4、5就没事。但跨度大的乱序却可能触发快速重传，比如打乱成2、3、4、5、1时，就会触发足够多的Dup ACK，从而导致1号包的重传。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 8][]

## TCP Dup ACK ##

当乱序或者丢包发生时，接收方会收到一些Seq号比期望值大的包。它每收到一个这种包就会Ack一次期望的Seq值，以此方式来提醒发送方，于是就产生了一些重复的Ack。Wireshark会在这种重复的Ack上标记\[TCP Dup ACK\] 。

以图5为例，服务器收到的7号包为“Seq=29303, Len=1460”，所以它期望下一个包应该是Seq Len=29303 1460=30763，没想到实际收到的却是8号包Seq=32223，说明Seq=30763那个包可能丢失了。因此服务器立即在9号包发了Ack=30763，表示“我要的是Seq=30763”。由于接下来服务器收到的10号、12号、14号也都是大于Seq=30763的，因此它每收到一个就回复一次Ack=30763，从图中可见Wireshark在这些回复上都标记了\[TCP Dup ACK\]。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 9][]  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 10][]

一般Linux 默认是dup ack 3次后，就会触发TCP Fast Retransmission 快速重传，有对应的Linux sysctl 配置决定；

# sysctl -a | grep reorder
    net.ipv4.tcp_reordering = 3

## TCP Fast Retransmission ##

TCP Fast Retransmission   -----  TCP 快速重传

在tcp传输时，存在TCP拥塞和慢启动，在网络拥塞传输时，就会出现丢包，丢包后，tcp的机制就会出现重传，而目前重传时，常见的有超时重传(TCP Retransmission)和快速重传(TCP Fast Retransmission)；

在网络拥塞之后会发生什么情况呢？对发送方来说，就是发出去的包不像往常一样得到确认了。不过收不到确认也可能是网络延迟所致，所以发送方决定等待一小段时间后再判断。假如迟迟收不到，就认定包已经丢失，只能重传了。这个过程称为超时重传。如图2所示，从发出原始包到重传该包的这段时间称为RTO。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 11][]

当发送方收到3个或以上\[TCP Dup ACK\]，就意识到之前发的包可能丢了，于是快速重传它（这是RFC的规定）。以图6为例，客户端收到了4个Ack=991851，于是在1177号包重传了Seq=991851。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 12][]

**tcp.analysis.fast\_retransmission** \---- wireshark 过滤条件

可根据tcp seq num 和 ack num 进行具体的数值计算，对应对应的快速重传报文标记缘由的计算；明确对应ack 是丢失了哪条报文；避免判断错误；

历史遇到的快速重传的报文的场景有：

1）物理服务器网卡错包，导致出现出现概率性网络连通性问题，抓包分析时，为快速重传通信场景(网卡错包可通过ifconfig 等命令查询确认)；

2）经过LB转发时，MTU设置关系，出现大包丢包情况，触发出现快速重传，分析报文时需要明确计算seq num 核实对应丢失报文序列(tcp数据传输时ack+len 不是握手时的ack+1)，通过同步的client/ rs 抓包确认丢包为包长超过mtu的大片报文；以此核实情况，确认现象；

3）客户端网卡组了bond 主备模式，抓包时tcpdump -i any 导致单向出现报文重复抓到两片，wireshark 在解析时 ，会错误的解析出 dup ack 报文(主备模式会重复2次，主主模式会重复3次)；错误解析导致将正常的 http response 200 code 解析为 tcp fast retransmission报文；影响分析判断；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 13][]  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 14][]

有时候拥塞很轻微，只有少量的包丢失。还有些偶然因素，比如校验码不对的时候，会导致单个丢包。

这两种丢包症状和严重拥塞时不一样，因为后续有包能正常到达。当后续的包到达接收方时，接收方会发现其Seq号比期望的大，所以它每收到一个包就Ack一次期望的Seq号，以此提醒发送方重传。当发送方收到3个或以上重复确认（Dup Ack）时，就意识到相应的包已经丢了，从而立即重传它。这个过程称为快速重传。之所以称为快速，是因为它不像超时重传一样需要等待一段时间。

为什么要规定凑满3个呢？这是因为网络包有时会乱序，乱序的包一样会触发重复的Ack，但是为了乱序而重传没有必要。由于一般乱序的距离不会相差太大，比如2号包也许会跑到4号包后面，但不太可能跑到6号包后面，所以限定成3个或以上可以在很大程度上避免因乱序而触发快速重传。如图7中的左图所示，2号包的丢失凑满了3个DupAck，所以触发快速重传。而右图的2号包跑到4号包后面，却因为凑不满3个Ack而没有触发快速重传。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 15][]

出现快速重传并不会像出现超时重传一样处理拥塞窗口；

既然后续的包都到达了，说明网络并没有严重拥塞，接下来传慢点就可以了。

对此RichardStevens和RFC5681的建议也略有不同。后者认为临界窗口值应该设为发生拥塞时还没被确认的数据量的1/2（但不能小于2个MSS）。然后将拥塞窗口设置为临界窗口值加3个MSS，继续保留在拥塞避免阶段。这个过程称为快速恢复，其拥塞窗口的变化大概可以用图8表示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 16][]

## TCP Spurious Retransmission ##

https://www.chappell-university.com/post/spurious-retransmissions-a-concern

虚假重传

wireshark 过滤器：**tcp.analysis.spurious\_retransmission**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 17][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 18][]  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 19][]

## TCP Retransmission ##

超时重传对传输性能有严重影响。原因之一是在RTO阶段不能传数据，相当于浪费了一段时间；原因之二是拥塞窗口的急剧减小，相当于接下来传得慢多了。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 20][]

如果一个包真的丢了，又没有后续包可以在接收方触发\[Dup Ack\]，就不会快速重传。这种情况下发送方只好等到超时了再重传，此类重传包就会被Wireshark标上\[TCP Retransmission\]。以图7为例，客户端发了原始包（包号1053）之后，一直等不到相应的Ack，于是只能在100多毫秒之后重传了（包号1225）。

超时重传是一个非常有技术含量的知识点，比如等待时间的长短就大有学问，本文就不细说了，毕竟需要懂这个的人很少。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 21][]

和快速重传一样，对应的超时重传的超时时间设置，超时重传的次数也都是有对应的Linux 内核参数可以进行控制的；

## TCP zerowindow ##

TCP包中的“win=”代表接收窗口的大小，即表示这个包的发送方当前还有多少缓存区可以接收数据。当Wireshark在一个包中发现“win=0”时，就会给它打上“TCP zerowindow”的标志，表示缓存区已满，不能再接受数据了。比如图8就是服务器的缓存区已满，所以通知客户端不要再发数据了。我们甚至可以在3258～3263这几个包中看出它的窗口逐渐减少的过程，即从win=15872减小到win=1472。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 22][]

## TCP window Full ##

当Wireshark在一个包中打上\[TCP window Full\]标志时，就表示这个包的发送方已经把对方所声明的接收窗口耗尽了。以图9为例，Britain一直声明它的接收窗口只有65535，意味着Middle East最多能给它发送65535字节的数据而无需确认，即“在途字节数”最多为65535字节。当Wireshark在包中计算出Middle East已经有65535字节未被确认时，就会发出此提示。至于Wireshark是怎么计算的，请参考本书的《计算“在途字节数”》一文。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 23][]

\[TCP window Full\]很容易跟［TCP zerowindow］混淆，实际上它们也有相似之处。前者表示这个包的发送方暂时没办法再发送数据了，后者表示这个包的发送方暂时没办法再接收数据了，也就是说两者都意味着传输暂停，都必须引起重视。

## TCP window Update ##

和tcp window full 和 zerowindow 类似，表示声明的tcp 传输窗口发生了更新；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 24][]

## TCP port numbers reused ##

> It can happen when you have a long running capture of a single client-server relation where the client keeps opening new TCP sessions all the time, like in your case (several hours of captured packets). What happens is that the client uses a temporary port (also called “ephemeral port”) and connects to the server port (which is usually a fixed port, like port 80 for HTTP).
> 
> Windows up until Windows XP uses port 1025 to 5000 as ephemeral ports (it doesn’t matter if it connects to the same server or another, it always increases by 1), and when it gets to 5000 it will start at 1025 again. You can see this text book behaviour in frame 33150 (SYN from port 5000) and the next SYN is in 33162 coming from port 1025 again. Since your capture started after the client had already opened and closed some connections you do not see 1025 twice, but in your case 2242 was the first port number you captured. When it loops around 5000 back to 1025 it is only a matter of time until you get a “port number reused”.
> 
> “Port number reused” might indicate a problem, but only if the ports are reused very shortly again - which is not the case in your trace. Final verdict: yes, port number reused, but in a long running trace, and thus not a problem. The time distance is about 7880 seconds between the reuse, so you’re safe.
> 
> BTW, starting with Vista, Microsoft changed the ephemeral port range to 49152 up to 65535. See also

我们知道每个IP地址有65536个可用的端口(Linux 可以在内核参数 sysctl 配置该port 范围，sysctl -a | grep port\_range)；当在一个抓包文件中，wireshark发现client 发起的请求源port 出现重复时，就会打该标记；

该标记只是声明port 出现了重复；并不代表一定就是存在报错；

在clinet 有大量断连接请求时，请求 src port 很容易会出现源端口重复的情况，分析报文时，只需判断该port 之前的tcp 连接是否已经关闭(fin 或 rst 报文)即可；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 25][]

## TCP segment of a reassembled PDU ##

当你收到这个提示，肯定已经在EditàPreferencesààTCP菜单里启用了Allow sub dissector to reassemble TCP streams。它表示Wireshark可以把属于同一个应用层PDU（比如SMB的Read Response和Write Request之类）的TCP包虚拟地集中起来。如图10所示，这一个SMB Read Response由39～48号包共同完成，因此Wireshark在最后一个包中虚拟地把所有包集中起来。这样做有个好处，就是可以右键点击图10底部的方框，选择Copy - > Bytes - > Printable Text Only，从而复制整个应用层的PDU。做研发的同学可能比较需要这个功能。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 26][]  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 27][]

## Continuation to ##

你看到这个提示，说明已经在Edit – > Preferences – > Protocols – > TCP菜单里关闭了Allow sub dissector to reassemble TCP streams。比如图10的那些包，一关闭就变成图11这样。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 28][]

仔细对比图10和图11，你会发现Read Response在图10中被算在了48号包头上，而在图11中被算到了39号包头上。这样会带来一个诡异的结果：图10的读响应时间为2.528毫秒（38号包和48号包的时间差），而图11的读响应时间为2.476毫秒（38号包和39号包的时间差）。究竟哪个算正确呢？这个问题很难回答，如果在乎的是实际的总性能，那就看前者；如果想忽略TCP/IP协议的损耗，单看服务器的响应速度，那就看后者。在某些特殊情况下，这两者相差非常大，所以必须搞清楚。

## Time-to-live exceeded (Fragment reassembly time exceeded) ##

ICMP的报错有好多种，大都不难理解，所以我们只举其中的一种为例。 \[Fragment reassembly time exceeded\]表示这个包的发送方之前收到了一些分片，但是由于某些原因迟迟无法组装起来。比如在图12中，由于上海发往北京的一些包被分片传输，且有一部分在路上丢失了，所以北京方无法组装起来，便只好用这个ICMP报错告知上海方。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 29][]

## TCP keep-alive ##

tcp 连接保活机制；具体时间在linux sysctl 内核配置中可查，可调整；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 30][]

## TCP keep-alive ACK ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 31]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70]: /images/20221124/f62fa7a4a44942d6acf7c21706a9b137.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 1]: /images/20221124/07c6bed5387846b3ab6bb21b115d6d36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 2]: /images/20221124/b8f7a552ff6848d99fb9393ecca879b1.png
[IP]: https://wiki.wireshark.org/IP
[UDP]: https://wiki.wireshark.org/UDP
[TCP]: https://wiki.wireshark.org/TCP
[NFS]: https://wiki.wireshark.org/NFS
[SnapLen]: https://wiki.wireshark.org/SnapLen
[MTU]: https://wiki.wireshark.org/MTU
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 3]: /images/20221124/e2a3c567c38d45f88c62172745627115.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 4]: /images/20221124/4c26dfbc9d5c4752a895ebce921c7b89.png
[20200809165238977.png]: /images/20221124/1e59b778204942c8a61e11568996d10c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 5]: /images/20221124/4cb5e0b2d75c4bfcaffc0a77f10388e0.png
[20200809165323771.png]: /images/20221124/c791c3cc02734a5fbea70675bece929f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 6]: /images/20221124/5db3150c08a44a1fa04e4454b429a6b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 7]: /images/20221124/1415584f25594a2ba759ff5791d1b46d.png
[20200809165435530.png]: /images/20221124/b9dd89beeffb4250ab0edce58c3e5aa5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 8]: /images/20221124/eb398d885b044df0ae2ceb70f1a6ced9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 9]: /images/20221124/94b732d17030420299325b9deaa6411a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 10]: /images/20221124/07b32f6ac3074bd09601a61f42034f36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 11]: /images/20221124/bb4f5a3383b44747a98b0fbf6918ddd9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 12]: /images/20221124/c71186c621e84a3dbe84a4f9c67ba673.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 13]: /images/20221124/13433d393a974d7ba867dd8668e2bbe0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 14]: /images/20221124/9db2a86bba6a4ace89c9238235984f14.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 15]: /images/20221124/ae04b762fd0e491291325eef35cb311d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 16]: /images/20221124/708e172514a6432cbcfed0f15332e0b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 17]: /images/20221124/2076ff175b964a559d2308ad34c8a2dd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 18]: /images/20221124/a8f5462ae0a34c33964b93ae039fa588.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 19]: /images/20221124/b7bca12e3a574ebda1fc169fd0f11db0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 20]: /images/20221124/ddbd1c2d064a4b0eb2e112725d3e55b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 21]: /images/20221124/4c19e12e6d2d4aafb5f632e3bde0fe67.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 22]: /images/20221124/666c6db1758845088e45452e6b283020.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 23]: /images/20221124/aa528c5489e444a4b673a9d8522ad4fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 24]: /images/20221124/cc178bb83aa1400183d01de9632050c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 25]: /images/20221124/25a2a6d6a53b4744badc2a78bf92946b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 26]: /images/20221124/ecab48f7a65f482ca39ba1c57d4bfa28.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 27]: /images/20221124/1da176c08b634577835ce69feb4eb7a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 28]: /images/20221124/07a7dee6ad3d4f529f819cd2101afb34.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 29]: /images/20221124/fc563328d3e34bf49eef4a7a3aa16c1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 30]: /images/20221124/55270bfa7a5e4e32937aa50012a4f97f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 31]: /images/20221124/1a2e9252f08e4cea82ca11cb33fcb15e.png