《MY网络基础知识》----传输层之TCP协议

怼烎@ 2022-05-21 04:04 315阅读 0赞

**开局一张表**

<table> 
 <tbody> 
 <tr> 
 <td> OSI模型 </td> 
 <td> 协议 </td> 
 <td> 数据包叫法 </td> 
 <td> 常见设备 </td> 
 <td> 五层模型 </td> 
 </tr> 
 <tr> 
 <td> 应用层 </td> 
 <td> HTTP,DHCP,FTP </td> 
 <td> 报文 </td> 
 <td> 常见PC机，工作站，终端等 </td> 
 <td> 应用层 </td> 
 </tr> 
 <tr> 
 <td> 表示层 </td> 
 <td> &nbsp; </td> 
 </tr> 
 <tr> 
 <td> 会话层 </td> 
 <td> &nbsp; </td> 
 </tr> 
 <tr> 
 <td> 传输层 </td> 
 <td> TCP/UDP </td> 
 <td> 传输协议分组，分组 </td> 
 <td> 网关 </td> 
 <td> 传输层 </td> 
 </tr> 
 <tr> 
 <td> 网络层 </td> 
 <td> IP协议，ICMP协议，IGMP协议 </td> 
 <td> IP包，IP数据报 </td> 
 <td> 路由器，三层交换机 </td> 
 <td> 网络层 </td> 
 </tr> 
 <tr> 
 <td> 数据链路层 </td> 
 <td> 以太网协议，ARP协议 </td> 
 <td> 帧，数据帧 </td> 
 <td> 交换机，网桥 </td> 
 <td> 数据链路层 </td> 
 </tr> 
 <tr> 
 <td> 物理层 </td> 
 <td>&nbsp;</td> 
 <td> 比特流 </td> 
 <td> 网口，网线，集线器 </td> 
 <td> 物理层 &nbsp; </td> 
 </tr> 
 </tbody> 
</table>

**废话不多说先来个概括**

![70][]

**阅读思路**：先列出TCP报头，再介绍创建连接和终止连接部分，最后再介绍中间的数据传输部分。

# 前导部分：TCP报文 #

![70 1][]

**源端口号/目的端口号**: 表示数据从哪个进程来, 到哪个进程去.  
32位序列号:在握手和挥手的时候用来放初始序列号，  
4位首部长度: 表示该tcp报头有多少个4字节(32个bit)  
6位保留: 顾名思义, 先保留着, 以防万一  
  
6位标志位  
URG: 标识紧急指针是否有效   
ACK: 标识确认序号是否有效   
PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走   
RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段   
SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段   
FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段  
16位窗口大小:  
  
  
16位检验和: 由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分.  
16位紧急指针: 用来标识哪部分数据是紧急数据.  
选项和数据暂时忽略

# **一：建立连接（三次握手）** #

## 1.1三次握手时候的状态转换 ##

![70 2][]

**注意每次发送完后的状态变化**

## 1.2 三次握手细节 ##

第一次握手：

客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及**初始序号X**,保存在包头的序列号(Sequence Number)字段里。  
（初始序列号X怎么来？是根据时间戳得来的）

![1232796-20171016102018443-1382861531.png][]

第二次握手：

服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即X+1。  
（服务端回复的，X+1是根据第一条SYN来的，而Y是服务端自己的初始序列号，也是根据时间戳来的）

![1232796-20171016102044052-575081000.png][]

第三次握手：

客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1。

![1232796-20171016102107615-2040951857.png][]

**初始序列号（ISN）**随时间而变化的，而且不同的操作系统也会有不同的实现方式，所以每个连接的初始序列号是不同的。TCP连接两端会在建立连接时，交互一些信息，如窗口大小、MSS等，以便为接着的数据传输做准备。

RFC793指出ISN可以看作是一个32bit的计数器，每4ms加1，这样选择序号的目的在于防止在网络中被延迟的分组在以后被重复传输，而导致某个连接的一端对它作错误的判断。

## 1.3同时打开 ##

两个应用程序同时彼此执行主动打开的情况是可能的，尽管发生的可能性极小。每一方  
必须发送一个S Y N，且这些S Y N必须传递给对方。这需要每一方使用一个对方熟知的端口作  
为本地端口。这又称为同时打开（ simultaneous open）  
主机A中的一个应用程序使用本地端口7 7 7 7，并与主机B的端口8 8 8 8执行主动打开。  
主机B中的应用程序则使用本地端口8 8 8 8，并与主机A的端口7 7 7 7执行主动打开。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMTMxOTcxMzkyNQ_size_16_color_FFFFFF_t_70][]  
一个同时打开的连接需要交换 4个报文段，比正常的三次握手多一个。此外，要注意的是  
我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。

## 1.4 三次握手相关问题 ##

### （1）三次握手数据包丢失 ###

1.丢失syn,ack+syn会由重发机制解决，没有问题。  
2.丢失ack。需重建新的连接  
因客户端进入了established状态，此时服务端在syn\_rcvd状态，会在3,6,12,秒后重发ack+syn，但是客户端处于established不会回应。于是服务端关闭此处于syn\_rcvd的连接。而客户端发送数据到服务端的时候，因服务端没有处于establishde状态，所以会回应rst。此时客户端就会发现连接异常，就会关闭它的连接。

### （2）三次握手数据包重复 ###

1.重复ack+syn和ack，因对方处于established状态，所以不会回应，忽略。所以不会造成影响。  
2.重复的syn，服务端会新建连接回复syn+ack并进入syn\_rcvd状态，但是重发几次syn+ack都收不到ack，此状态的连接便关闭，也不会有什么影响。

**（1）为什么不用两次?**

**主要是为了防止已经失效的连接请求报文突然又传送到了服务器，从而产生多余连接。**

**两次握手的情况**：假如是2次握手就进入连接，如图因为syn在网络中迷途，导致重发和晚到。服务器收到多条syn，就回应多个ack，因为是两次握手就会直接进入连接，就会创建多余的连接。

**![70 3][]**

三次握手避免了这种情况：ESTABLISHED状态收到ack+syn不会回复ack，服务器也就不会创建多余的连接。

**![70 4][]**

**（2）为什么不用四次?**

因为三次已经可以满足需要了, 四次就多余了.

## ##

# **二：终止连接（4次挥手）** #

## 2.1 四次挥手时的状态转换 ##

![70 5][]

## 2.2 四次挥手细节 ##

**1,** 客户端进程发出连接释放报文，并且停止发送数据。   
释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。   
**2,** 服务器收到连接释放报文，发出确认报文，ACK=1，确认序号为 u+1，并且带上自己的序列号seq=v，此时服务端就进入了CLOSE-WAIT（关闭等待）状态。   
TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。   
**3,** 客户端收到服务器的确认请求后，此时客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最终数据）   
**4,** 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，确认序号为v+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。   
**5,** 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，确认序号为w+1，而自己的序列号是u+1，此时，客户端就进入了**TIME-WAIT**（时间等待）状态。注意此时TCP连接还没有释放，必须经过**2∗MSL**（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。   
**6,** 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

**解释MSL （重要）：**MSL代表任何IP数据报能够在因特网上存货的最长时间。RFC1122上建议设置成2分钟，传统上设置成30秒。

**理解TIME-WAIT状态（重要）：**

存在的两个理由：

**1.可靠的实现TCP的终止**，也即最后一个ack如果丢失了，那么会导致再发一个fin，如果没有TIME-WAIT状态，该请求关闭的那方，就会收到RST导致无法关闭。长期处于半关闭状态。

**2.等待迷途的IP数据报在网络中消逝**。原因是一般是客户端主动关闭才会进入time-wait状态。如果客户端再次创建连接，在传输过程中，收到了迷途的数据报。会导致异常。（导致什么样的异常？具体没研究过，可以自己思考一下）为了防止再次创建这样的连接，收到了没消逝的上一次连接在网络中没消逝的数据报。如果有了TIME-WAIT状态，即使客户端再创建连接，也不能绑定time-wait的端口号，就不会收到没消失的数据。如果要绑定的话，默认情况下，是不允许的，因为那个端口被time-wait暂用了。在此状态下不能创建这样的连接。就不会出现收到上一个连接的数据的情况。

## 2.3 同时关闭 ##

略

## 2.4 四次挥手相关问题 ##

**（1）服务器主动关闭，再次启动则无法绑定端口号**

原因：由四次挥手可知，主动关闭的一方会进入TIME-WAIT状态。这时候这个连接绑定了该服务器端口号进入了TIME-WAIT状态，再启动服务器，又绑定这个端口号，所以导致绑定失败。

解决方法：修改套接字选项，使用setsockopt()设置socket描述符的选项SO\_REUSEADDR为1, 表示**允许创建端口号相同但IP地址不同的多个socket描述符**.

int opt = 1; 
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

**（2）使用设置套接字选项倒是可以创建服务器绑定了套接字。那么当有数据包发往这个IP地址和这个端口号的时候，该数据包是被现有的服务器接收，还是被处于TIME-WAIT状态的那个连接接收呢？**

首先要理解：确定一条连接的是4元组：源IP端口，目的IP端口。客户端在创建连接的时候，端口号一般不会是原来的端口号，所以创建出来的连接四元组和time-wait状态的不同。所以TIME-WAIT状态的那个连接只会收到那个连接的数据包，它处于TIME-WAIT状态了，只会收到网络中迷途的数据包，然后丢掉。而我们新启动的服务器，处于listen状态，TCP/IP协议栈只会让他收到连接请求的数据包。

# 三：数据传输 #

关于数据传输这部分，设计到了超时，重传，流量控制，滑动窗口等很多知识。我看过一篇博客，对这部分的总结非常完美，各个概念的讲解能够互相衔接，逻辑性强。所以我索性赋值过来，以备忘。

### 确认应答机制(ACK机制) ###

![这里写图片描述][70 6]

TCP将每个字节的数据都进行了编号, 即为序列号.   
![这里写图片描述][70 7]

每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你要从哪里开始发.   
比如, 客户端向服务器发送了1005字节的数据, 服务器返回给客户端的确认序号是1003, 那么说明服务器只收到了1-1002的数据.   
1003, 1004, 1005都没收到.   
此时客户端就会从1003开始重发.

### 超时重传机制 ###

![这里写图片描述][70 8]

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B   
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发   
但是主机A没收到确认应答也可能是ACK丢失了.   
![这里写图片描述][70 9]

这种情况下, 主机B会收到很多重复数据.   
那么TCP协议需要识别出哪些包是重复的, 并且把重复的丢弃.   
这时候利用前面提到的序列号, 就可以很容易做到去重.

**超时时间如何确定?**   
最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.   
但是这个时间的长短, 随着网络环境的不同, 是有差异的.   
如果超时时间设的太长, 会影响整体的重传效率; 如果超时时间设的太短, 有可能会频繁发送重复的包.

TCP为了保证任何环境下都能保持较高性能的通信, 因此会**动态计算**这个最大超时时间.

*  Linux中(BSD Unix和Windows也是如此), 超时以`500ms`为一个单位进行控制, 每次判定超时重发的超时时间都是`500ms`的整数倍.   
    如果重发一次之后, 仍然得不到应答, 等待 `2*500ms` 后再进行重传. 如果仍然得不到应答, 等待 `4*500ms` 进行重传.   
    依次类推, 以指数形式递增. 累计到一定的重传次数, TCP认为网络异常或者对端主机出现异常, 强制关闭连接.

### 滑动窗口 ###

刚才我们讨论了确认应答机制, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段.   
这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返时间较长的时候.   
那么我们可不可以一次发送多个数据段呢?   
例如这样:   
![这里写图片描述][70 10]  
一个概念: **窗口**   
窗口大小指的是无需等待确认应答就可以继续发送数据的最大值.   
上图的窗口大小就是4000个字节 (四个段).

发送前四个段的时候, 不需要等待任何ACK, 直接发送   
收到第一个ACK确认应答后, 窗口向后移动, 继续发送第五六七八段的数据…

因为这个窗口不断向后滑动, 所以叫做**滑动窗口.**   
操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答   
只有ACK确认应答过的数据, 才能从缓冲区删掉.   
![这里写图片描述][70 11]

如果出现了丢包, 那么该如何进行重传呢?

此时分两种情况讨论:

1, 数据包已经收到, 但确认应答ACK丢了.   
![这里写图片描述][70 12]  
这种情况下, 部分ACK丢失并无大碍, 因为还可以通过后续的ACK来确认对方已经收到了哪些数据包.

2, 数据包丢失   
![这里写图片描述][70 13]

当某一段报文丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001”   
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送   
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了   
因为2001 - 7000接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中.

**这种机制被称为 “高速重发控制” ( 也叫 “快重传” )**

### 流量控制 ###

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被填满, 这个时候如果发送端继续发送, 就会造成丢包, 进而引起丢包重传等一系列连锁反应.   
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度.   
这个机制就叫做 **流量控制(Flow Control)**

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段,   
通过ACK通知发送端;   
窗口大小越大, 说明网络的吞吐量越高;   
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;   
发送端接受到这个窗口大小的通知之后, 就会减慢自己的发送速度;   
如果接收端缓冲区满了, 就会将窗口置为0;   
这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 让接收端把窗口大小再告诉发送端.

![这里写图片描述][70 14]

那么接收端如何把窗口大小告诉发送端呢?   
我们的TCP首部中, 有一个16位窗口大小字段, 就存放了窗口大小的信息;   
16位数字最大表示65536, 那么TCP窗口最大就是65536字节么?   
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是窗口字段的值左移 M 位(左移一位相当于乘以2).

### 拥塞控制 ###

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠地发送大量数据.   
但是如果在刚开始就发送大量的数据, 仍然可能引发一些问题.   
因为网络上有很多计算机, 可能当前的网络状态已经比较拥堵.   
在不清楚当前网络状态的情况下, 贸然发送大量数据, 很有可能雪上加霜.

因此, TCP引入 `慢启动` 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态以后, 再决定按照多大的速度传输数据.

![这里写图片描述][70 15]

在此引入一个概念 `拥塞窗口`

*  发送开始的时候, 定义拥塞窗口大小为1;
 *  每次收到一个ACK应答, 拥塞窗口加1;
 *  每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口

像上面这样的拥塞窗口增长速度, 是指数级别的.   
“慢启动” 只是指初使时慢, 但是增长速度非常快.   
为了不增长得那么快, 此处引入一个名词叫做`慢启动的阈值`, 当拥塞窗口的大小超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长.

![这里写图片描述][70 16]

*  当TCP开始启动的时候, 慢启动阈值等于窗口最大值
 *  在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1

少量的丢包, 我们仅仅是触发超时重传;   
大量的丢包, 我们就认为是网络拥塞;   
当TCP通信开始后, 网络吞吐量会逐渐上升;   
随着网络发生拥堵, 吞吐量会立刻下降.

**拥塞控制**, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

### 延迟应答 ###

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.   
假设接收端缓冲区为1M. 一次收到了500K的数据;   
如果立刻应答, 返回的窗口大小就是500K;   
但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了; 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;   
如果接收端稍微等一会儿再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M

窗口越大, 网络吞吐量就越大, 传输效率就越高.   
TCP的目标是在保证网络不拥堵的情况下尽量提高传输效率;

那么所有的数据包都可以延迟应答么?   
肯定也不是   
有两个限制

>  *  数量限制: 每隔N个包就应答一次
>  *  时间限制: 超过最大延迟时间就应答一次

具体的数量N和最大延迟时间, 依操作系统不同也有差异   
一般 `N` 取2, `最大延迟时间`取200ms

### 捎带应答 ###

在延迟应答的基础上, 我们发现, 很多情况下   
客户端和服务器在应用层也是 “一发一收” 的   
意味着客户端给服务器说了 “How are you”   
服务器也会给客户端回一个 “Fine, thank you”   
那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起发送给客户端   
![这里写图片描述][70 17]

### 面向字节流 ###

创建一个TCP的socket, 同时在内核中创建一个 `发送缓冲区` 和一个 `接收缓冲区`;   
调用`write`时, 数据会先写入发送缓冲区中;   
如果发送的字节数太大, 会被拆分成多个TCP的数据包发出;   
如果发送的字节数太小, 就会先在缓冲区里等待, 等到缓冲区大小差不多了, 或者到了其他合适的时机再发送出去;   
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;   
然后应用程序可以调用`read`从接收缓冲区拿数据;   
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区,   
那么对于这一个连接, 既可以读数据, 也可以写数据, 这个概念叫做 `全双工`

由于缓冲区的存在, 所以TCP程序的读和写不需要一一匹配   
例如:

*  写100个字节的数据, 可以调用一次`write`写100个字节, 也可以调用100次`write`, 每次写一个字节;
 *  读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次`read` 100个字节, 也可以一次`read`一个字节, 重复100次;

### 粘包问题 ###

首先要明确, 粘包问题中的 “包”, 是指`应用层的数据包`.   
在TCP的协议头中, 没有如同UDP一样的 “报文长度” 字段   
但是有一个序号字段.   
站在传输层的角度, TCP是一个一个报文传过来的. 按照序号排好序放在缓冲区中.   
站在应用层的角度, 看到的只是一串连续的字节数据.   
那么应用程序看到了这一连串的字节数据, 就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包.   
此时数据之间就没有了边界, 就产生了`粘包问题`

那么如何避免粘包问题呢?   
归根结底就是一句话, 明确两个包之间的`边界`

> 对于定长的包   
> \- 保证每次都按固定大小读取即可   
> 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可
> 
> 对于变长的包   
> \- 可以在数据包的头部, 约定一个数据包总长度的字段, 从而就知道了包的结束位置   
> 还可以在包和包之间使用明确的分隔符来作为边界(应用层协议, 是程序员自己来定的, 只要保证分隔符不和正文冲突即可)

**对于UDP协议来说, 是否也存在 “粘包问题” 呢?**

> 对于UDP, 如果还没有向上层交付数据, UDP的报文长度仍然存在.   
> 同时, UDP是一个一个把数据交付给应用层的, 就有很明确的数据边界.   
> 站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收.   
> 不会出现收到 “半个” 的情况.

### TCP 异常情况 ###

*  进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
 *  机器重启: 和进程终止的情况相同.
 *  机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行 `reset`. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.
 *  另外, 应用层的某些协议, 也有一些这样的检测机制.   
    例如HTTP长连接中, 也会定期检测对方的状态.   
    例如QQ, 在QQ断线之后, 也会定期尝试重新连接.

[70]: /images/20220521/2d00e47a8f6e4a62b09c469091ad0a0c.png
[70 1]: /images/20220521/925423dd4e2847c7941431664707e7b4.png
[70 2]: /images/20220521/b2549f188f694cc3a8dc8e2cd27e5144.png
[1232796-20171016102018443-1382861531.png]: /images/20220521/fb9342e6a8e344c8bb0397d90a3ace8b.png
[1232796-20171016102044052-575081000.png]: /images/20220521/1a0edc6ef95f4b69a1de4e8838862f4c.png
[1232796-20171016102107615-2040951857.png]: /images/20220521/e054c353dc304a7e8b2ea4202d0e5049.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMTMxOTcxMzkyNQ_size_16_color_FFFFFF_t_70]: /images/20220521/607d678e969849798cc748b5fbef6762.png
[70 3]: /images/20220521/2f080dc159954da381b075cf2e297dd6.png
[70 4]: /images/20220521/4863aaf4f04243cf99a715261ec3aafe.png
[70 5]: /images/20220521/118f962c38ca4c3d886b0c7d9957878a.png
[70 6]: /images/20220521/d7945c89bf814daea036fc6c0075d2e5.png
[70 7]: /images/20220521/e1e5bcb11b44438e9e3886bc6954282b.png
[70 8]: /images/20220521/9ba3d7efcded471ba250c896dd47e572.png
[70 9]: /images/20220521/b1b647b43c734927b863b94a85f0dc63.png
[70 10]: /images/20220521/237d0fde74f740deae293a5b944dcf46.png
[70 11]: /images/20220521/7805bf4b8bc8401c9a99742f9372afe2.png
[70 12]: /images/20220521/854b2d4676bb43928eb2f18024035b13.png
[70 13]: /images/20220521/933842f9d60c47feb97bb66873603085.png
[70 14]: /images/20220521/d8510f51c8654174a00264b046686203.png
[70 15]: /images/20220521/90cbe00c8a7245cb9df212dcb1055c00.png
[70 16]: /images/20220521/7e395a348d684f08b9b4c2ef853078cc.png
[70 17]: /images/20220521/f14d41450be646db944112e59c09baf5.png