TCP Wireshark网络抓包分析和问题解决说明

淡淡的烟草味﹌ 2022-08-05 01:28 3272阅读 0赞

今天遇到问题，更新博客（20200520）：

# 一、数据包详细信息 #

--------------------

**Packet Details面板**内容如下，主要用于分析封包的详细信息。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70][]

帧：物理层、链路层

包：网络层

段：传输层、应用层

![format_png][]

**1）Frame**

物理层数据帧概况

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 1][]

**2）Ethernet II**

数据链路层以太网帧头部信息

![20200310164958301.png][]

**3）Internet Protocol Version 4**

互联网层IP包头部信息

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 2][]

IP包头：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 3][]

**4）Transmission Control Protocol**

传输层数据段头部信息，此处是TCP协议

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 4][]

TCP包头：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 5][]

**5）Hypertext Transfer Protocol**

应用层信息，此处是HTTP协议

# 二、着色规则 #

--------------------

Wireshark默认有一组着色规则，可以在Packet Details面板中展开包的帧部分，查看着色规则。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 6][]

在View | Coloring Rules中，打开着色规则窗口，可以自己创建、删除、选中、去除。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 7][]

# 三、Wireshark提示 #

--------------------

> 1.  **Tcp previous segment lost（tcp先前的分片丢失）**
> 2.  Tcpacked lost segment（tcp应答丢失）
> 3.  Tcp window update（tcp窗口更新）
> 4.  Tcp dup ack（tcp重复应答）
> 5.  Tcp keep alive（tcp保持活动）
> 6.  Tcp retransmission（tcp重传）
> 7.  Tcp ACKed unseen segument （tcp看不见确认应答）
> 8.  tcp port numbers reused（tcp端口重复使用）
> 9.  tcp retransmission（tcp重传）
> 10. tcp fast retransmission (tcp快速重传)
> 11. TCP Previoussegment lost（发送方数据段丢失）
> 12. tcp spurious retransmission(tcp伪重传)

### **1）Packet size limited during capture** ###

说明被标记的那个包没有抓全。一般是由抓包方式引起，有些操作系统中默认只抓每个帧的前96个字节。

4号包全长171字节，但只有96字节被抓到。

![20200310165158609.png][]

### **2）TCP Previous segment not captured** ###

如果Wireshark发现后一个包的Seq大于Seq+Len，就知道中间缺失了一段。

如果缺失的那段在整个网络包中找不到（排除了乱序），就会提示。

6号包的Seq是1449大于5号包的Seq+Len=1+1=1，说明中间有个1448字节的包没被抓到，就是“Seq=1,Len=1448”。

![format_png 1][]‘

175: SEQ=4675 大于 174: SEQ=Seq(4381)+0 (len)

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 8][]

前一个TCP分段没有抓到。   
在TCP连接建立的时候，SYN包里面会把彼此TCP最大的报文段长度，即MSS标志，一般都是1460.如果发送的包比最大的报文段长度长的话就要分片了，被分片出来的包，就会被标记了“TCP segment of a reassembled PDU”，这些包分片存在同样的ack number，且每个分片的seq number不同。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 9][]

这些分片正常应该是连续接收的，即前一个分片指示的next seq number即为下一个收到的分片的seq number。假如收到的下一个分片的seq number与上一个比不连续的话，wireshark就会将该分片标记为TCP Previous segment not captured。如下图，ack number为705的TCP包被分为多个分片发送，其中有一个长度为1408的分片没有被抓到。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 10][]

### **3）TCP ACKed unseen segment** ###

当Wireshark发现被Ack的那个包没被抓到，就会提示。

32号包的Seq+Len=6889+1448=8337，说明下一个包Seq=8337。

而我们看到的是35号包的Seq=11233，意味着8337~11232这段数据没抓到。

![202003101657048.png][]

### **4）TCP Out-of-Order** ###

> 一般来说是网络拥塞，导致顺序包抵达时间不同，延时太长，或者包丢失，需要重新组合数据单元，因为他们可能是由不同的路径到达你的电脑上面。

当Wireshark发现后一个包的Seq号小于前一个包的Seq+Len时，就会认为乱序，发出提示。

3362号包的Seq小于3360包的Seq，所以就是乱序。

![format_png 2][]

Wireshark判断TCP out-of-order是基于TCP包中SEQ number并非期望收到的下一个SEQ number，则判断为out-of-order。因此，出现TCP out-of-order时，很大可能是TCP存在乱序或丢包，导致接收端的seq number不连续。   
如下图，第4包数据，在客户端已经收到服务端的SYN ACK后，服务端再次发送了SYN ACK，wireshark将此包标记为out-of-order。

![20200310171935888.png][]

![20200310171947522.png][]

如下图，第7包数据，本应收到seq number为1366882的TCP包，但却收到了1044834的包，这包数据应该是晚到了，因此wireshark标记为out-of-order。

### **5）TCP Dup ACK** ###

> TCP dup ack XXX\#X：  
> 就是接收端要求发送方重复应答XXX序号丢失的报文，\#后面X的是表示第几次丢失。

当乱序或丢包发生时，接收方会收到一些Seq号比期望值大的包。没收到一个这种包就会Ack一次期望的Seq值，提现发送方。

7号包期望的下一个Seq=30763，但8号包Seq=32223，说明Seq=30763包丢失，9号包发了Ack=30763，表示“我要的是Seq=30763”。

10号、12号、14号也都是大于30763的，因此没收到一个就回复一次Ack。

![20200310170638305.png][]

重复ack。   
当网络中存在乱序或者丢包时，将会导致接收端接收到的seq number不连续。此时接收端会向发送端回复重复ack，ack值为期望收到的下一个seq number。重复ack数大于等于3次将会触发快速重传。如下图，   
315包，客户端向服务端发送ack=126951的反馈，期望下一包收到seq=126951的TCP包。但下一包接收到的却是seq=128211的TCP包，由于seq不连续，wireshark将该报标记为TCP Previous segment not captured。   
317包，客户端向服务端重复发送ack=126951的包，第一次重发，\#后边带1。   
318包，客户端收到seq=126951的TCP包。   
319包，截止到seq=129471的所有TCP包全部收到，因此客户端回复了ack=129471的反馈。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 11][]

### **6）TCP Fast Retransmission** ###

当发送方收到3个或以上的【TCP Dup ACK】，就意识到之前发的包可能丢了，于是快速重传它。

![20200310170659787.png][]

TCP快速重传。   
TCP协议设定了快速重传机制以避免过多的慢启动对传输速率的影响。快速重传通过接收到3个或3个以上重复的ack反馈触发。快速重传不需要等待RTO超时。如下图。   
325包，客户端向服务端反馈ack=133251，说明下一个期望收到服务端seq=133251的包；   
326包，服务端向客户端发送了seq=135771的数据包，与客户端的期望不符，因此客户端在327包重传了ack=133251的包，再次申明期望收到seq=133251的包。Wireshark将重复ack标记为TCP Dup ACK，\#后边指明为第几次重传。   
328包，服务端向客户端发送了seq=137031的数据包，仍然与客户端期望不符，客户端在329包再次重传ack=133251的包。   
330包，服务端收到3次重复ack，触发快速重传，重传了seq=133251的TCP分片。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 12][]

### **7）TCP Retransmission** ###

如果一个包真的丢了，又没有后续包可以在接收方触发【Dup Ack】就不会快速重传。

这种情况下发送方只好等到超时了再重传。

1053号包发出后，一直没有等到相应的Ack，只能在100多毫秒之后重传了。

![20200310170732449.png][]

TCP重传。   
当抓到2次同一包数据时，wireshark判断发生了重传，同时wireshark没有抓到初传包的反馈ack，因此，wireshark判定重传有效，标记为TCP Retransmission。基于软件的判定机制，如果抓包点在客户端的话，TCP重传一般为上行包，因为这时，客户端并没有收到服务端的反馈ack，无从知晓服务端是否收到了初传包，RTO超时后触发客户端重传。此时存在2种情况，即1）服务端收到了初传包，只是下发的反馈ack丢包，客户端没有收到；2）服务端没有收到初传包，因此也就没有下发反馈ack。对于第一种情况，如果抓包点在服务端的话，wireshark很有可能就会把来自客户端的重传包标记为TCP Spurious Retransmission。   
如下图，红线的TCP包为重传包，wireshark为该包添加了重传原因，是由于TRO超时导致，以及初传包序号45，并给出了当前的RTO超时时间。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 13][]

### **8）TCP zerowindow** ###

包种的“win”代表接收窗口的大小，当Wireshark在一个包中发现“win=0”时，就会发提示。

![20200310170744780.png][]

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

### ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 14][] ###

### **9）TCP window Full** ###

此提示表示这个包的发送方已经把对方所声明的接收窗口耗尽了。

当Wireshark计算出Middle East已经有65535字节未被确认，就会发出此提示。

![20200310170800186.png][]

【TCP window Full】表示发送方暂时没办法再**发送数据**；

【TCP zerowindow】表示发送方暂时没办法再**接收数据**。

TCP window满。   
是指的发送端发送的数据已经达到的接受窗口的上限。发送端暂停发送，等待新的接收窗口的通告。   
如下图，客户端向服务端发送的ack反馈，期望下一包收到的seq=288961，但接收窗口仅有960，服务端在收到ack后发送了960字节的数据，TCP window full。注意，len=1004是整个IP包的长度，需要减去IP头44字节，即960字节。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 15][]

### **10）TCP segment of a reassembled PDU** ###

Wireshark可以把属于同一个应用层的PDU的TCP包虚拟地集中起来。

TCP层收到上层大块报文后分解成段后发出去，主机响应一个查询或者命令时如果要回应很多数据（信息）而这些数据超出了TCP的最大MSS时，

主机会通过发送多个数据包来传送这些数据（注意：这些包并未被分片）。

![2020031017082289.png][]

### **11）Time-to-live exceeded（Fragment reassembly time exceeded）** ###

表示这个包的发送方之前收到了一些分片，但由于某些原因迟迟无法组装起来。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 16][]

### 12. TCP window update ###

TCP窗口更新。   
当接收方的TCP window发生突变时，接收方通过TCP window update消息告知对方当前的接收窗口大小。如下图，TCP window Update同时携带了反馈ack，ack序列号与前一个反馈ack序列号相同，但这并不是重复ack。   
![这里写图片描述][20161016201652726]

109行：

服务端向客户端端发送 tcp window update，表示buffer已经清空。并提示服务端现在已经有足够的window 大小为 43320。

![20200311134241559.png][]

tcp window update是TCP通信中的一个状态，它可以发生的原因有很多，但最终归结于发送者传输数据的速度比接收者读取的数据还快，这使得接受端的在缓冲区必须释放一部分空间来装发送过来的数据，然后向发送者发送Windows Update，告诉给发送者应该以多大的速度发送数据，从而使得数据传输与接受恢复正常。

### 13. TCP acked unseen segment ###

反馈ACK指向了一个未知的TCP片段。   
这个意思是说ACK反馈的是一个wireshark上不存在的TCP包。很可能是wireshark漏抓了这个包，但却抓到了对端反馈的该报的ack包。如下图，标记为ack unseen segment的包反馈的ack=2721，看着像是反馈的seq=1361的包，但其实这个ack还反馈了seq=1的包，由于seq=1的包没有抓到，因此wireshark将反馈ack标记为ack unseen segment。从下面的图还可知，由于对端已经反馈了ack=2721，说明发端发送的seq=1的包，对端也收到了，只不过wireshark可能漏抓了而已。   
![这里写图片描述][20161016201741524]

### 14. TCP RST ###

TCP 重置。   
是TCP协议结束异常连接的一种方式，通过flags中的reset=1标记。当TCP连接无法通过正常的4次挥手结束时，一方可以通过发送携带reset标志的TCP包结束TCP连接。   
如下图，发送方通过2个TCP流发送数据，截图中，接收方首先向发送方反馈了TCP window=0，让发送方暂缓发送数据，之后紧接着发送了TCP RST标记，释放了TCP连接。猜测可能接收方程序突然崩溃了，导致缓存区数据没法清空，之后接收方系统发送了TCP reset释放TCP连接。   
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 17][]

# 问题 #

--------------------

我们遇到的问题:客户端边下载边播放音频, 在弱网的情况下出现严重的卡顿现象：

> **卡顿的原因：  
> 1、http的MTU默认是1400，tcp每个包大小为1400，但是tcp无法确保数据先按序到达.  客户端接收完整个数据完成后，才对数据包进行排序，然后才把有序数据传送给应用层http  
> 2、TCP包在网络不好的情况下会发生重传现象。  
> 3、客户端是边接收边播放，即按数据包的seq来播放，如果某个包发生tcp重传，客户端要等到这个包接收了才能继续播放, 因此会发生卡顿现象。  
> 4、我们wireshark没看到 seq=29401的包，并不一定是服务器没有下发。  
>      wireshark提示：TCP Previous segment not captured。  
>      wireshark可能没有抓到这个包。**
> 
> **解决办法：  
> 目前边接收边播放，在弱网情况下，tcp发生重传概率很大，就会导致卡顿现象。  
> 断电续传下载播放就会大大降低卡顿现象。**

**1、包丢失:**

**    **首先wireshark抓包看到提示:TCP Previous segment not captured 说明有数据包缺失：

501： seq=28001， ACK=140

502:   seq=30801， ACK=140 (TCP Previous segment not captured)

即数据包seq=29401， ACK=140发生丢失了。

503:   seq=40， ACK=29401 要求服务器发送这个包，

504:   seq=32201， ACK=140  数据包到达，

505、507、509（TCP Dup ACK）一直发送给服务器发，告知包已经丢失了，

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 18][]

**2、重传数据包：   ** 结果直到547，服务器才重传tcp包过来。

等到的这段时间，播放音频肯定卡顿了。

**3、继续要求重传：**seq=30801， ACK=140，（550，552，554...TCP Dup ACK）.

其实这个包之前已经发送过，客户端没有缓存这个数据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 19][]

**4、再次重传数据包：    结果直到573，服务器才重传tcp包过来。**

**      客户端播放音频卡顿就发非常严重啦。**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 20][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70]: /images/20220805/a34f55b8c9324436815c3fd15fcb05b5.png
[format_png]: /images/20220805/29348dec002043b4a3d8801321428620.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 1]: /images/20220805/25a5dafab77b4b54b2e0924120cdeaa7.png
[20200310164958301.png]: /images/20220805/c5e0fc38348142399e87155a354bceed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 2]: /images/20220805/c1f8da6350644007ac7e89af9c7da8c0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 3]: /images/20220805/a2ec0ac7adb947f4b659b6a23e5298b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 4]: /images/20220805/6ceebf82ce6747108a4a1b50f7fefe53.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 5]: /images/20220805/a248fa39f0384dfca46e7771e92d7986.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 6]: /images/20220805/a54e64509b6a446c9a712fbc06856f0f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 7]: /images/20220805/3e61e76192bc42cb92bc14cdb925bb38.png
[20200310165158609.png]: /images/20220805/86da3fc0c75943fbbc6cffd1c0bbc8a3.png
[format_png 1]: /images/20220805/a45b4fd5e5cf42da8cc202c09772a90c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 8]: /images/20220805/a7c70a2ee8ce4113abdc9d639f595701.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 9]: /images/20220805/190aeeaf4579450d970b8e7cb9f3d3a2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 10]: /images/20220805/93259c5121c641d0a3db33764f035738.png
[202003101657048.png]: /images/20220805/d209bd6950294b8a82371c87af6d79a7.png
[format_png 2]: /images/20220805/a4bf3d8496d540bb92b9af128afa99f2.png
[20200310171935888.png]: /images/20220805/085b791da09c484baf5f6982931d0931.png
[20200310171947522.png]: /images/20220805/8fb5b654b16948028e9685cb82bf49d1.png
[20200310170638305.png]: /images/20220805/46a3ad9145dd47ad80ea042ecd484103.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 11]: /images/20220805/7b3ba59aa2224e24888a9645c7120cdf.png
[20200310170659787.png]: /images/20220805/d1771b980ebf4062bce3b7a8a547596e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 12]: /images/20220805/116299aad6cf4f488d10e5319db50f70.png
[20200310170732449.png]: /images/20220805/6672e41e5b0b41ca907c84a5a5a4f9ce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 13]: /images/20220805/2a574372b6514be1b6d433ea8f7b70a3.png
[20200310170744780.png]: /images/20220805/56f1b492f0aa41b2b895345a9a668081.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 14]: /images/20220805/c86a189583164445b62f6af5fd21d6d6.png
[20200310170800186.png]: /images/20220805/e09395ef24e841608a799fcb02b17c00.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 15]: /images/20220805/f372fd6577cf436795c1f09bd0b2525c.png
[2020031017082289.png]: /images/20220805/66b1317ab1e84822a5542bb8b66094ab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 16]: /images/20220805/0d4d1603bd4549f2a9883bc84c13ce47.png
[20161016201652726]: /images/20220805/c27fbd2dc49f40ed97286c5f3e4b291d.png
[20200311134241559.png]: /images/20220805/64064efcae214f1a94a99fcd91e0c4eb.png
[20161016201741524]: /images/20220805/d19451462c934b57967dd326fc3eda5a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 17]: /images/20220805/9a518f8cbf614121959d9a4a274e6971.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 18]: /images/20220805/eefe593eb4f6496db5e4d9309e4ef31f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 19]: /images/20220805/2f2316a885744d028d6fb458328a4780.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 20]: /images/20220805/ca044bb49d9149e0a72e01077620df42.png