三次握手和四次挥手细节，为什么是三次而不是两次、四次，最后一次挥手等待 2MSL

<h1 id="tcp-">TCP 握手和挥手进一步理解</h1>
<h2 id="heading">握手</h2>
<h3 id="heading-1">序号与确认</h3>
TCP 所有的报文都需要携带一个序号 <code>seq</code>，用于确保接收的顺序，避免丢包重包。这个序号是一个随机数，并非从零开始，但是在使用中往往会用当前序号减去初始序号，显示一个偏移量作为相对序号。序号本身代表的含义是，当前数据包负载部分的第一个字节，在整个实际数据中的位置。以发送 <code>Hello World!</code> 为例，如果其被拆分成两个包 <code>Hel</code>、<code>lo World!</code>，那么这两个包的相对序号将是 0 和 3。
从 TCP 头部可知，序号最大为 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mn>4</mn><mi>G</mi></mrow><annotation encoding="application/x-tex">4G</annotation></semantics></math>4G，但由于序号可以循环重复使用，每个报文实际存活时间有限（<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mn>180</mn></mrow><annotation encoding="application/x-tex">180</annotation></semantics></math>180 秒），因此除非带宽达到 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mn>180</mn></mrow><annotation encoding="application/x-tex">180</annotation></semantics></math>180 秒传输 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mn>4</mn><mi>G</mi></mrow><annotation encoding="application/x-tex">4G</annotation></semantics></math>4G 的数据（<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mn>22</mn><mi>M</mi><mi mathvariant="normal">/</mi><mi>s</mi></mrow><annotation encoding="application/x-tex">22 M/s</annotation></semantics></math>22M/s），否则 TCP 本身就可以做到不冲突。同时，TCP 头部的扩充字段可以通过设置时间戳来进一步避免冲突，因此即使超过 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mn>22</mn><mi>M</mi><mi mathvariant="normal">/</mi><mi>s</mi></mrow><annotation encoding="application/x-tex">22 M/s</annotation></semantics></math>22M/s 仍然可以正常使用 TCP
与 <code>seq</code> 对应的是 <code>ack</code>，其表示自己已经收到了所有 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>s</mi><mi>e</mi><mi>q</mi><mo>&lt;</mo><mi>a</mi><mi>c</mi><mi>k</mi></mrow><annotation encoding="application/x-tex">seq \lt ack</annotation></semantics></math>seq&lt;ack 的包，属于对对方数据的确认。换种方式理解，其也是自己所期望的对方下一个包 <code>seq</code> 的值
<h3 id="heading-2">什么是三次握手</h3>
要想解释三次握手，首先需要解释三次握手是什么
TCP 是一个 可靠、有连接 传输协议 
要确保可靠性，需要 确保对方能收到自己的信息 
要确保有连接，需要 建立会话
而握手要解决的就是这两个问题，当然，顺带还确定了对方真的是在用 TCP 协议（毕竟存在双方用不同的协议，还 “凑巧” 能理解对方的情况的）
三次握手实际上是通过对对方序号的确认，来实现了连接建立
<ol>
<li>客户端发起连接，发送报文<code>SYN=1,seq=x</code></li>
<li>服务端收到请求后如果接收连接，则返回<code>SYN=1,seq=y,ack=x+1</code></li>
<li>客户端确认收到连接，如果已有数据需要发送则发送<code>seq=x+1,ack=y+1</code>，并携带对应的数据；否则发送<code>seq=x,ack=y+1</code></li>
</ol>
前两个数据包携带<code>SYN</code>字段，即使不携带数据，序号也需要加 1 
由于第二步服务端就已经分配资源，因此如果有大量握手请求，会导致 SYN 泛洪攻击
<h3 id="heading-3">为什么是三次握手</h3>
首先，给出标准答案
<blockquote>
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.
</blockquote>
大概意思是，为了避免序号错误的问题。假设如下情况: 
发起者 A 向服务端 B 发起了 TCP 握手（第一个第一次握手），等了几秒钟还没有结果，于是他决定重新发起 TCP 连接（第二个第一次握手）。 
在第二个第一次握手到达服务端 B 前，服务端 B 终于发现自己有个请求没处理，于是他开始处理握手请求（第一个第二次握手）。 
这时，对 A 而言，其第一个握手已经结束，现在是第二个握手流程，也即 A 第二个握手与 B 第一个握手对接上了！
结果就是两个人都以为对方理解了自己的思路，但实际上在两个频道说话……
<hr>
上面的解释，没有问题，但是可以从另一个方向理解三次握手
如果将通信简单划分为可以通信和无法通信，那么实际上一个 TCP 连接有四种可能：
<ul>
<li>A 无法发送给 B，B 无法发送给 A</li>
<li>A 可以发送给 B，B 无法发送给 A</li>
<li>A 无法发送给 B，B 可以发送给 A</li>
<li>A 可以发送给 B，B 可以发送给 A</li>
</ul>
握手的任务就是让 A、B 双方都确认对方知道了双方都可以通信。
第一次握手，A 不知道对方有没有收到，因此 A 什么都不知道。B 收到了 A 的消息，因此他知道 A-&gt;B 是连通的 
第二次握手，A 在收到 B 的消息时，知道了 A→B 连通（不然 B 不会返回消息），B-&gt;A 也连通（不然自己收不到）。但是 B 由于不知道 A 是否已经收到，因此他只知道 A→B 连通 
第三次握手，B 收到 A 的确认，B 知道 B→A 也是连通的，双方都确认通信没有问题
<h2 id="heading-4">挥手</h2>
<ol>
<li>某一方希望关闭连接，向对端发送释放报文段<code>FIN=1,ACK=1,seq=u</code>，并停止发送数据</li>
<li>对端接收到后发送确认<code>ACK=1,seq=v,ack=u+1</code></li>
<li>发起方不再发送数据，对端可能还需要发送数据，TCP 处于半关闭状态</li>
<li>对端也没有需要发送的数据时，发送释放报文段<code>FIN=1,ACK=1,seq=w,ack=u+1</code></li>
<li>发起方确认<code>ACK=1,seq=u+1,ack=w+1</code>。发送报文 2MSL 后，连接关闭（可能会存在确认报文发送失败，对端请求重传的情况）</li>
</ol>
与三次握手类似，FIN 即使不携带数据，序号也需要加 1 
四次挥手顺序不定，只需要满足响应在对应的请求后即可
<h3 id="heading-5">为什么是四次</h3>
四次挥手类似三次握手，需要确认：A 已经关闭，并且 B 也已经关闭
第一次挥手，A 发送关闭请求，B 知道 A 准备关闭 
第二次挥手，B 发送确认，A 知道 B 已经知道自己准备关闭，因此 A 停止发送数据（但还要接收，因为 B 还未关闭） 
第三次挥手，B 发送关闭请求，A 知道 B 也准备关闭（到这时，双方都已经确认对方准备关闭，因此除去最后的确认外，几乎已经完全关闭） 
第四次挥手，A 发送确认，B 知道 A 已经知道自己准备关闭，此时 B 也可以正式关闭
原理上来说，三次握手其实应该和四次挥手一样，为四次握手。但是由于第二次握手不需要传输数据，因此 B 发送给 A 的确认以及 B 请求建立连接两条报文可以合并为一次。而关闭连接时期，由于另一方可能还需要发送数据，因此无法合并。
<h2 id="heading-6">抓包</h2>
网络问题，抓包解释一切妖魔鬼怪，下面是一个三次握手后直接四次挥手的会话（数据包包含 IPv4 包，seq 除去前两个握手使用的是相对序号）
<pre style="background-color:#fff">$ tcpdump -A -t -ns 0 -X -r a.pcap

reading from file a.pcap, link-type EN10MB (Ethernet), snapshot length 262144
IP 127.0.0.1.43402 &gt; 127.0.0.1.6666: Flags [S], seq 916859721, win 65495, options [mss 65495,sackOK,TS val 2545404621 ecr 0,nop,wscale 7], length 0
 0x0000: 4500 003c 7b94 4000 4006 c125 7f00 0001 E..&lt;{.@.@..%....
 0x0010: 7f00 0001 a98a 1a0a 36a6 2b49 0000 0000 ........6.+I....
 0x0020: a002 ffd7 fe30 0000 0204 ffd7 0402 080a .....0..........
 0x0030: 97b7 cacd 0000 0000 0103 0307 ............
IP 127.0.0.1.6666 &gt; 127.0.0.1.43402: Flags [S.], seq 3047146258, ack 916859722, win 65483, options [mss 65495,sackOK,TS val 2545404622 ecr 2545404621,nop,wscale 7], length 0
 0x0000: 4500 003c 0000 4000 4006 3cba 7f00 0001 E..&lt;..@.@.&lt;.....
 0x0010: 7f00 0001 1a0a a98a b59f c312 36a6 2b4a ............6.+J
 0x0020: a012 ffcb fe30 0000 0204 ffd7 0402 080a .....0..........
 0x0030: 97b7 cace 97b7 cacd 0103 0307 ............
IP 127.0.0.1.43402 &gt; 127.0.0.1.6666: Flags [.], ack 1, win 512, options [nop,nop,TS val 2545404622 ecr 2545404622], length 0
 0x0000: 4500 0034 7b95 4000 4006 c12c 7f00 0001 E..4{.@.@..,....
 0x0010: 7f00 0001 a98a 1a0a 36a6 2b4a b59f c313 ........6.+J....
 0x0020: 8010 0200 fe28 0000 0101 080a 97b7 cace .....(..........
 0x0030: 97b7 cace ....
IP 127.0.0.1.6666 &gt; 127.0.0.1.43402: Flags [F.], seq 1, ack 1, win 512, options [nop,nop,TS val 2545404622 ecr 2545404622], length 0
 0x0000: 4500 0034 58e5 4000 4006 e3dc 7f00 0001 E..4X.@.@.......
 0x0010: 7f00 0001 1a0a a98a b59f c313 36a6 2b4a ............6.+J
 0x0020: 8011 0200 fe28 0000 0101 080a 97b7 cace .....(..........
 0x0030: 97b7 cace ....
IP 127.0.0.1.43402 &gt; 127.0.0.1.6666: Flags [.], ack 2, win 512, options [nop,nop,TS val 2545404628 ecr 2545404622], length 0
 0x0000: 4500 0034 7b96 4000 4006 c12b 7f00 0001 E..4{.@.@..+....
 0x0010: 7f00 0001 a98a 1a0a 36a6 2b4a b59f c314 ........6.+J....
 0x0020: 8010 0200 fe28 0000 0101 080a 97b7 cad4 .....(..........
 0x0030: 97b7 cace ....
IP 127.0.0.1.43402 &gt; 127.0.0.1.6666: Flags [F.], seq 1, ack 2, win 512, options [nop,nop,TS val 2545405622 ecr 2545404622], length 0
 0x0000: 4500 0034 7b97 4000 4006 c12a 7f00 0001 E..4{.@.@..*....
 0x0010: 7f00 0001 a98a 1a0a 36a6 2b4a b59f c314 ........6.+J....
 0x0020: 8011 0200 fe28 0000 0101 080a 97b7 ceb6 .....(..........
 0x0030: 97b7 cace ....
IP 127.0.0.1.6666 &gt; 127.0.0.1.43402: Flags [.], ack 2, win 512, options [nop,nop,TS val 2545405622 ecr 2545405622], length 0
 0x0000: 4500 0034 0000 4000 4006 3cc2 7f00 0001 E..4..@.@.&lt;.....
 0x0010: 7f00 0001 1a0a a98a b59f c314 36a6 2b4b ............6.+K
 0x0020: 8010 0200 0ba4 0000 0101 080a 97b7 ceb6 ................
 0x0030: 97b7 ceb6 
</pre><h2 id="heading-7">参考文献</h2>
<ul>
<li>
<a href="https://www.gingerdoc.com/tcp-seq-and-loop/">TCP序列号 与 序列号循环介绍</a>
</li>
<li>
<a href="https://www.zhihu.com/question/320833399/answer/660079068">线路的发送速率受限于 TCP 分组序号长度，5G 的快速率如何实现？ - void l的回答 - 知乎</a>
</li>
</ul>