网络协议 TCP

约定不等于承诺〃 2023-01-05 01:18 172阅读 0赞

### 文章目录 ###

*  前言
 *  滑动窗口
 *   *  协定窗口缩放比
 *  可靠性
 *   *  三次握手
     *   *  第一次握手
         *  第二次握手
         *  第三次握手
     *  为什么需要三次握手
     *  1 保证通信双方的发送和接收都没有问题
     *  2 保证不会因为丢失的报文重新连接
     *  四次挥手
     *   *  为什么要等候2MSL?
     *  ARQ 协议
     *   *  停止并等待ARQ协议（stop-and-wait）
         *  连续ARQ协议（\`Continuous ARQ\`）
         *  SACK
     *  可靠性总结
 *  流量控制
 *  拥塞控制
 *   *  慢开始和避免拥塞
     *  快恢复和快重传

# 前言 #

`TCP`是传输层协议,具有如下特性：  
1.可靠性  
2. 拥塞控制  
3. 流量控制

而`拥塞控制`和`流量控制`需要基于滑动窗口机制。

# 滑动窗口 #

消息的接收方: 都会有自己的处理能力上限。比如`计算机B`一次性只能处理`50`个消息，这个大小我们叫做`窗口大小`。

消息的发送方:  
消息的发送方也有一个自己发送大小窗口,当然这个大小受限于上层协议控制，比如`流量控制和拥塞控制`，一般来说都会小于接收方的接收窗口。

我们以发送端的举例说明：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70]  
我们假设我们要发送的数据为`HELLOWORD` ，在网络传输中我们传输的数据会分多个片段然后发送。上图中 `HEL`为`TCP`协议中已发送且已经确认的数据，`LOWO`为已发送但是没有收到确认的报文。`RD`还未发送。

我们看下动图发送这个数据流程。  
![在这里插入图片描述][2021011112251720.gif_pic_center]

我们看到收到确认信息后，黄色窗口会像后移动，这种现象我们称为`滑动窗口`.

> tip: 滑动窗口大小会随时改变哦

## 协定窗口缩放比 ##

在传输数据中双方会不断告知自己的窗口大小给对方。如下tcp报文格式  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 1]  
上图有一个16位窗口大小，但是这个数字要乘上syn所发协定的缩放比(可参考后文三次握手)

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 2]  
也就是传输的窗口大小要乘上syn所协定的比例大小。

# 可靠性 #

TCP 具有可靠传输的特性，如丢失一个报文会重传，在建立连接的时候会确认双方通信无障碍，关闭连接的时候确认双方都有收到。

## 三次握手 ##

`三次握手`用于确认通信前双方的发送功能和接收功能都是正常的。  
我们首先看下如下图TCP通信流程。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 3]  
图片来自 https://github.com/jawil/blog/issues/14

我们重新看下报文格式  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 1]

### 第一次握手 ###

我看下`wireshark`客户端第一次发送链接的syn报文  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 4]

我们这里只挑几个地方来讲  
顺序号：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 5]  
客户端会在`syn`时生成一个随机数作为seq号，后续的报文序号根据此计数。所以第一个报文的`sequence`的相对值是0.

`FLAG`：  
标志位将syn设置为1，表示这是一个链接请求  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 6]

窗口大小：

注意这个数值需要乘上option中窗口缩放比  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 7]

`option`:  
这个`TCP`用于协商一些特性，如`sack`等。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 8]

[RFC132中timestamps说明][RFC132_timestamps]

### 第二次握手 ###

本次由服务端发出.

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 9]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 10]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 11]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 12]

### 第三次握手 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 13]

## 为什么需要三次握手 ##

为什么连接需要三次？不是两次？

## 1 保证通信双方的发送和接收都没有问题 ##

两次握手图  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 14]  
当客户端收到第二次握手包时可以证明两件事：

1.  客户端可以感知：客服端可以正常发送到服务端，并且服务端可以正常接收和发送
2.  服务端可以感知：客户端可以正常发送，服务端接收没问

但是服务端无法感知自己的发送能力是否正常，所以需要客户端重新在发送一次`ack`

也就是必须要三次握手确保客户端和服务端可以确认双发收发都正常。

## 2 保证不会因为丢失的报文重新连接 ##

我们假设两次握手就可以链接的话，会出现以下情况

![在这里插入图片描述][20210114111458291.gif_pic_center]  
上图客户端发送第一个`Syn`时因为网络原因滞留在网络中还没有发送到服务端。  
所以客户端超时没收到ack，因此重发了一个`Syn`然后服务端发送`ack`，完成连接。

但是问题来了：

1.  此时客户端和服务端突然完成通信然后断开连接.
2.  滞留在网络的`Syn`包突然又发送到了服务端  
    ![在这里插入图片描述][2021011411264560.gif_pic_center]  
    ![在这里插入图片描述][20210114113343855.gif_pic_center]  
    因为服务端滞留的syn报文 发送到服务端，让服务端以为客户端又需要连接，所以发送ack报文后，直接连接完成。但是客户端是没有这种需求的，所以客户端会拒绝连接，但服务端会错误认为连接已经完成所以会不断发送信息。

## 四次挥手 ##

挥手协议的目的：保证双方都收到的关闭的消息，并且留给一定的时间给给对方做处理。

我们来看下抓包处理情况：  
![在这里插入图片描述][20210114142641301.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 15]

**客户端状态说明：**

`FIN_WAIT1` 和 `CLOSE_WAIT`

**客户端**  
发送`FIN`报文给另一方,然后进入此`FIN_WAIT1`状态，标记不在发送任何信息给对方。（除最后确认的`ack`外） 。

**服务端：**  
收到一个`FIN`报文后，进入`CLOSE_WAIT`状态，标记已经收到了对方想关闭链接的请求，但是可能我这边还需要处理资源释放的操作，所以先回复一个`ACK`报文给对方，等接收真的可以断开连接的时候你在真的释放，因为接收方可能还会发送一些数据给`发送发`。

`FIN_WAIT2`  
客户端：  
收到服务端的确认的报文，知道了对方我的关闭请求的对方已经知道了，我只需要静静的等候对方处理关闭请求，并等候对方`FIN`报文,期间依然可以接收报文只是不发送而已，有可能对方在回收资源的时候需要客户端一起协助处理一些事情。

`TIME_WAIT`和`LAST-ACK`

`服务端`：  
此时已经完成了所有的资源回收处理，已经可以发送`FIN`告诉客服端，服务器可以随时断开连接，然后进入`LAST-ACK`阶段

`客户端`：  
收到对方的`FIN`报文，自己已经知道对方可以释放连接然后回一个`ACK`包，并进入`TIME-WAIT`状态，自己等候`2MSL`的时间，如果`2MSL`等候期间又收到了对方的`FIN`包，证明自己发送的确认报文丢失。那么客户端会重复的发送确认报文然后重新等候`2MSL`

以上便是四次挥手的全部过程。

**常见问题挥手面试：**

### 为什么要等候2MSL? ###

1.  客户端发送最后的ACK报文的时候有可能会丢失，服务端会因为超时等候而重发FIN报文
2.  防止成功断开连接后又收到上次回话的报文。在网络传输的过程中，一个报文最大的生存时间是`MSL`，也就是超过这个时间后报文哪怕到了也要主动丢弃。但是如果一个`TCP`请求完成后，立马重用又链接，可能会得到一个上次回话的报文。如果我们在断开连接的时候主动等候2MSL，可以确保本次回话的所有报文都已经过期，不会影响下次使用。

[知乎 为什么TCP4次挥手时等待为2MSL？][_TCP4_2MSL]

## ARQ 协议 ##

`arp` 全称 `Automatic repeat request` .包含：

1.  停止并等待`ARQ`协议（`stop-and-wait`）
2.  连续`ARQ`协议（`Continuous ARQ`）

其核心思想有两点：  
3. 超时重传  
4. 确认

### 停止并等待ARQ协议（stop-and-wait） ###

核心思想有两点：

**发送方收到确认在继续发送消息**

![在这里插入图片描述][20210114165106229.gif_pic_center]

**超时重传**  
如果在一定时间内没有收到信息那么就重新发送信息  
![在这里插入图片描述][20210114170344263.gif_pic_center]

### 连续ARQ协议（`Continuous ARQ`） ###

`停止并等待ARQ协议（stop-and-wait）`存在一个问题就是在于信道带宽利用率过低的问题。  
我们其实可以一次发送多个信息，然后对方只需要回复最后一个信息便表示收到之前的所有信息包。

![在这里插入图片描述][20210114173949671.gif_pic_center]  
但是上面会存在一个问题，如果我一次性发送 4个报文 编号为:1 ,2 ,3 ,4.

此时报文`3`因为网络原因没有没收到，只收到`1 2 4` 那么回复确认报文只能为`2`,因为发送方会重新发送 `3 4 5 6` 报文到服务端，只会让一些报文多次发送(回退N重传(Go-Back-N))。

为了解决`(回退N重传(Go-Back-N))`问题，因此又推出了另一个协议叫做选择性确认SACK。

### SACK ###

`SACK`需要通信双方都支持才可以使用，确认支持是位于双方在`SYN`阶段的时候协商,可以看文本三次握手阶段。

我买看下下面的两张图（转载自参考文献）：

在没有启用SACK之前的丢包重传情况：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 16]  
**解释**：  
服务端连续发送`seg1`,`seg2`,`seg3`,`seg4`给客户端，但是`seg2`丢失。所以在收到`seg3`,`seg4`将视为乱序报文，所以客户端立马回复两次`ACK1`。服务端收到`ACK1`后，其实不知道客户端收到了`seg3`,`seg4`，但是双方窗口又足够发送多余报文，所以用重新发送`seg2`,`seg3`,`seg4`，但是冗余的发送带来性能消耗。

我们在看下启用`SACK`后的丢包情况图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 17]  
客户端收到`seg3`之后发送一个 `ack1`并且附带一个`sack3`标志，标识收到`3`但是缺失了`2`  
客户端收到`seg4`之后发送一个 `ack1`并且附带一个`sack 3-4`标志，标识收到3和4，但是缺失了2  
服务端整合两个ack和sack，判断出客户端丢失2但是收到了3和4，所以我只需要发送2给对方就好。

**那么在数据传输中sack在哪？**

sack数据会放入tcp数据包的option当中  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 1]  
格式如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 18]  
乱序方会告诉发送方，自己收到的数据区间，上图两个一组，最大只能传输四组（option最大40字节）

比如收包的收到报文如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 19]  
那么会发送如下sack的格式：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 20]  
wireshark抓包如下（转载参考链接）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 21]

[SACK参考文献][SACK]

## 可靠性总结 ##

1.  TCP通过三次握手确保通信双方通信能力没有障碍，且确保丢失报文重连问题
2.  TCP通过四次挥手确保双方都接收到了通知信息，并且有时间处理释放，且确保丢失报文会在下次重连时错误到底问题
3.  ARQ协议 保证每个报文都会正确传递到对方上，确保不会丢包等错误

# 流量控制 #

计算机A于计算机B的在处理网络数据包的时候都有自己上限，在双方发送TCP报文的时候会不断告诉对方自身的窗口大小，让发送方控制自己速率和大小。

如下下图的某TCP报文  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 22]

这个报文告诉对方我的窗口大小是 501(需要自己乘上syn协商的窗口缩放比)，不可以发送过大的数据。

通过不断的交换数据包告诉对方自己的接收能力，可以很好控制流量，防止爆发式的资源浪费。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 23]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 24]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 25]

# 拥塞控制 #

假设`机算机A`和`计算机B`通信的过程中某一路由节点发生了网络拥塞事件引起了大量的丢包，这时发送发应减少发送频率和数量防止加重拥塞和避免无用资源的浪费。请注意拥塞控制是指整个网络传输过程的，而流量控制是两个终端之间的。

举例情况：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 26]  
由于路由器负载过大无法正常转发所有请求，所以只转发了第一个报文。如果计`算机A`无视这一情况，不断发送大量的数据包，只会做徒劳的操作，还引起更多的网络堵塞。

为了应对这一情况我们首先推出了两个协议：

1.  慢开始
2.  避免拥塞

## 慢开始和避免拥塞 ##

`计算机A`要给`计算机B`发送数据包，但是`计算机A`不清楚发动数据包到`计算机B`的网络是否顺畅，所以我们应该一开始少量发送数据包作为探测，因此我们定义了一个`cwnd`变量，表示拥塞窗口大小，我们发送数据的大小由两个决定 ，一个是`计算机B`接收能力`rwnd`,和`cwnd`。`计算机A`的发送数据大小我们称为发送窗口大小`swnd`。  
综上我们可以得到以下公式：  
`swnd=min(rwnd,cwnd)`  
发送大小在拥塞窗口和接收窗口中取最小值。

而慢开始协议是真对`cwnd`变化指定的，所以我们只讨论`cwnd`。  
一开始，`cwnd`应该是一个较小的数值，作为试探包。当我们收到确认的信息表示，当前网络顺畅，我们可以适当的提高`cwnd`的大小，所以我们直接将`cwnd`\*2。

如下图：  
![congestion window][]  
无休止的增大拥塞窗口，会导致网络拥塞的情况，所以我们设置了一个阈值`ssthresh`.  
当拥塞窗口`cwnd`大于等于`ssthresh`时启用一个叫`拥塞避免`算法。

`拥塞避免`会在次成功收到`ack`时，`cwnd`会加一。相比起慢开始的倍数增长减缓了很多。  
如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 27]  
当然不管怎么样网络出现网络丢包是早晚的事情，我们看下出现这类情况下`TCP`的处理方式.  
出现拥塞时`ssthrehold`和`cwnd`更新。  
`ssthrehold` = `当前cwnd`/`2`. (注意不管如何`ssthrehold`必须大于等于2)  
`cwnd`=1

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 28]

## 快恢复和快重传 ##

`快重传`和`快恢复`是对`慢开始`和`避免拥塞`的一种改良。  
假设`计算机A`发送一个数据包到`计算机B`中途因为一些其他原因引起其中一个数据包丢失（比如传输过程受到了一些干扰引起某一数据包校验和失败），但是整体网络实际没有拥塞。如果直接判断丢包为`网络拥塞`，然后降低`cwnd`和`ssthrehold`会极大影响网络整体交互体验。

所以TCP制定了新的策略来避免整这类情况。

`计算机B`为接收方 ，`计算机a`为发送方。

`计算机B`发现乱序报文直接回复ack，而不是等到要发送数据的时候顺带带上`ack`。

`计算机a`连续收到三个失序的确认报文后立即重传丢失报文(`快重传`)，并启动`快恢复`算法（实际会收到4个同一ack，至于为什么这样设计网上有轮子文章，这样设计较为合理）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 29]

为什么要收到失序报文后立即回复`ack`？

要发送方更快的知晓网络状况，而不是等超时器触发，这样连续收到三个失序ack报文时直接回传丢失报文，这样提高了通讯效率。

为什么`快重传`之后执行`快恢复`?  
能连续收到三个重复确认的`ack`,证明网络不一定是拥塞，但是为了预防拥塞情况因此开始对`cwnd`和`ssthresh`进行调整。

快恢复执行以下操作：  
`ssthresh=cwnd/2`  
`cwnd=cwnd/2`  
然后继续执行拥塞避免算法

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 30]  
为什么快重传是是连续三次冗余的ack后触发  
`https://blog.csdn.net/u010202588/article/details/54563648`

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70]: /images/20221119/80a4e4da7509489aa325ee55398e1cbf.png
[2021011112251720.gif_pic_center]: https://img-blog.csdnimg.cn/2021011112251720.gif#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210111124825125.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/2021011112500962.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210111125725496.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20210111125931986.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20210111130257211.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20210111130457960.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20210111130616115.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/20210111135415668.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[RFC132_timestamps]: https://www.freesoft.org/CIE/RFC/1323/8.htm
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 9]: https://img-blog.csdnimg.cn/20210111140140808.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 10]: https://img-blog.csdnimg.cn/20210114103644668.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 11]: https://img-blog.csdnimg.cn/2021011410373094.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 12]: https://img-blog.csdnimg.cn/20210114104134232.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 13]: https://img-blog.csdnimg.cn/20210114104629545.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 14]: https://img-blog.csdnimg.cn/2021011410542326.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[20210114111458291.gif_pic_center]: https://img-blog.csdnimg.cn/20210114111458291.gif#pic_center
[2021011411264560.gif_pic_center]: https://img-blog.csdnimg.cn/2021011411264560.gif#pic_center
[20210114113343855.gif_pic_center]: https://img-blog.csdnimg.cn/20210114113343855.gif#pic_center
[20210114142641301.png]: https://img-blog.csdnimg.cn/20210114142641301.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 15]: https://img-blog.csdnimg.cn/20210114143622537.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[_TCP4_2MSL]: https://www.zhihu.com/question/67013338
[20210114165106229.gif_pic_center]: https://img-blog.csdnimg.cn/20210114165106229.gif#pic_center
[20210114170344263.gif_pic_center]: https://img-blog.csdnimg.cn/20210114170344263.gif#pic_center
[20210114173949671.gif_pic_center]: https://img-blog.csdnimg.cn/20210114173949671.gif#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 16]: https://img-blog.csdnimg.cn/202101161419081.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 17]: https://img-blog.csdnimg.cn/2021011615041657.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 18]: https://img-blog.csdnimg.cn/20210116151636936.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 19]: https://img-blog.csdnimg.cn/2021011615201952.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 20]: https://img-blog.csdnimg.cn/2021011615235565.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 21]: https://img-blog.csdnimg.cn/20210116152424597.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[SACK]: https://packetlife.net/blog/2010/jun/17/tcp-selective-acknowledgments-sack/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 22]: https://img-blog.csdnimg.cn/20210117195225843.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 23]: https://img-blog.csdnimg.cn/20210117200934423.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 24]: https://img-blog.csdnimg.cn/20210117201021603.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 25]: https://img-blog.csdnimg.cn/20210117201115433.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 26]: https://img-blog.csdnimg.cn/20210117202618716.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[congestion window]: https://img-blog.csdnimg.cn/20210117220032442.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 27]: https://img-blog.csdnimg.cn/20210117222851930.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 28]: https://img-blog.csdnimg.cn/20210117222758503.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 29]: https://img-blog.csdnimg.cn/20210118105505623.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70 30]: https://img-blog.csdnimg.cn/20210118104637982.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx,size_16,color_FFFFFF,t_70