前言
这段时间面试官都挺忙的，频频出现在博客文章标题，虽然我不是特别想蹭热度，但是实在想不到好的标题了-。-，蹭蹭就蹭蹭 :)
事实上我在阿里面试的时候确实被问到了这个问题，HTTP、HTTPS、TCP/IP、Socket通信、三次握手四次挥手过程？当时虽然思路正确，可惜最终也并不算完全答对
结束后花了一段时间整理了下思路，参考和查阅了一下资料，整理如下：
来源：编程充电宝
作者：在所不辞
问题描述
你能否讲解一下
TCP
的三次握手与四次挥手呢？
面试官如果从整体到局部入手，那我们就先讲讲整个三次握手和四次挥手的过程，但不要忘记，讲的同时应该适当体现你对该知识点掌握的深度和广度，具体怎么说，我们后面慢慢道来。
三次握手
所谓的
握手
即一次发包到接收的过程，可能从客户端发送到服务端，也可能从服务端发送到客户端。
过程描述
先上一张
TCP报文结构
图，待会我们会回来看这张图：
TCP报文结构
先上三次握手的流程图：
三次握手
接下来我们来详细讲解下上图的过程：
- 客户主机发起连接请求，设置
SYN
1
随机
client_isn
TCP报文
序号
 第一次握手：SYN报文 - 接下来，当服务端接收到该报文后，会为其分配
TCP 缓存和变量
SYN 洪泛攻击
SYNACK 报文
SYN
1
确认号
client_isn + 1
server_isn
序号
 第二次握手：SYNACK报文 - 当收到服务器发来的
SYNACK
SYN
确认号
server_isn + 1
 第三次握手：ACK报文
细节拓展
- 三次握手的状态转换图（建议达到能默写下来的熟练程度）
 三次握手状态图 - 服务器为什么要使用特殊的初始序号
server_isn
这个细节和
问题深究第3题
是一致的，服务器使用
特定的初始序列号 server_isn
（从
源
和
目的地IP
端口
的
散列
中获取）可以用来抵御SYN洪水攻击。具体为什么，以及什么是
SYN 洪泛攻击
，问题深究部分我们会再详谈。
为了下文描述方便，我们将三次握手分别称为：、SYN 报文
SYNACK 报文
ACK 报文
问题深究
1.为什么要三次握手而不是两次？
简单来说，三次握手的目的是为了让双方验证各自的接收能力和发送能力。
- 第一次握手，A 发送
SYN
B
B
B
A
发送
B
接收
- 第二次握手，
B
SYNACK
A
A
A
B
A
A
SYNACK
A
SYN
B
A
发送
B
接收
A
OK
ESTABLISHED
- 第三次握手，
A
ACK
B
B
直接的，`B`能确认`A`的`发送`能力和`B`的`接收`能力，另外由于`B`能收到`ACK`说明前面发送的`SYNACK`已经成功被接受了，说明能确认`A`的`接收`能力和`B`的`发送`能力。
如果使用两次握手，就不能确认上述所说的四种能力，那么就会导致问题。
假定不采用第三次报文握手，那么只要B发出确认，新的连接就建立了。
现假定一种异常情况，即
A
发出的
SYN
报文段并没有丢失，而是在某些网络节点长时间滞留了，以致延误到连接释放后的某个时间才到达
B
。本来这是一个早已失效的报文段。但
B
收到此失效的连接请求报文段后，却误以为是
A
又发出一次新的连接请求，于是就向
A
发出确认报文段，同意建立连接。
由于现在
A
并没有发出建立连接的请求，因此不会理睬
B
的确认，也不会向
B
发送数据，但
B
却以为新的运输连接已经建立了，并一直等待
A
发来的数据。
B
的许多资源就这样白白浪费了。
2.两个TCP建立请求相互之间同时发起时会发生什么？建立几个连接？
首先理解题意，我们知道
三次握手
正是建立
TCP连接
的过程，我们假设 A 是客户端，B 是服务端：
rfc793-同时启动
这里先给大家讲一下上图中一些符号的含义：
- 右箭头 (-->) ：从 A 发送到 B 的 TCP 报文段，且 B 接收到了；
- 左箭头 (<--) ：从 B 发送到 A 的 TCP 报文段，且 A 接收到了；
- 省略号 (…) ：TCP 报文段仍在网络中（delayed）；
- 丢失 ("XXX") ：TCP 报文段丢失或者被拒绝。
- 注释会放在括号中；
- TCP 状态代表了处于中间的报文段到达之后的状态（AFTER）；
- 报文段的内容只显示了序列号（SEQ）、控制符（CTL）和 ACK，其余内容被省略。
接下来我们详细来看看上图中，两个请求同时相互发起时，两个
TCP
均会经历如下状态的转换：
同步请求的状态转换
上述的状态转换图可以跟前面的三次握手的转换图进行对比理解，同时发起的两个请求最终
只会建立一个连接
。
跟SYN-RECEIVED
是一样的，前者SYN-RCVD
中的描述方法，后者是《计算机网络-自顶向下方法》中的使用方法。rcf793
3. 客户端正在和服务端建立 TCP 连接，然而当服务器变 SYN-RCVD 后，此时一个旧的 SYN 报文 又到达了，服务器会如何处理？
其实这道题更加深挖了
TCP 建立连接
的过程，我们可以在
rfc793
中了解到详细信息。
rfc793-RST
从上图可以看到，第三行就是旧的
SYN 连接
到达服务器时，第四行是服务器照常返回，第五行是客户端给服务端发送
RST 报文
，将服务端重置为
LISTEN
我们需要从上图了解到的一点是，服务端在
SYN_RECEIVED
状态下，接收到旧的
SYN 报文
时是不能作出判断的，而是照常返回，当客户端接收到该报文后发现异常，才会发送
RST 报文
，重置连接。
关于
RST 报文
，我一开始也很疑惑，直到看到
rfc793 原文
：
rfc793-page33
确实说明了
TCP B
不能检测这个旧的
SYN 报文
是否正确，所以正常返回。而客户端收到会进行检测，发现是旧的报文，就会返回
RST 报文
4.第三次握手失败了怎么办？
这个问题在网上找到的答案质量参差不齐，翻阅了
rfc793
，仔细研究后，最终整理出以下答案：
首先考虑失败的情况：
ACK报文丢失导致第三次握手失败
当客户端收到服务端的
SYNACK
应答后，其状态变为
ESTABLISHED
，并会发送
ACK
包给服务端，准备发送数据了。如果此时
ACK
在网络中丢失（如上图所示），过了超时计时器后，那么服务端会重新发送
SYNACK
包，重传次数根据
/proc/sys/net/ipv4/tcp_synack_retries
来指定，默认是
5
次。如果重传指定次数到了后，仍然未收到
ACK
应答，那么一段时间后，
Server
自动关闭这个连接。
问题就在这里，客户端已经认为连接建立，而服务端则可能处在
SYN-RCVD
或者
CLOSED
，接下来我们需要考虑这两种情况下服务端的应答：
- 服务端处于
CLOSED
RST 报文
-
SYN-RCVD
ACK 报文
ACK 报文
ESTABLISHED
这个结论也可以在
STACKFLOW
上找到验证：
What if a TCP handshake segment is lost?
上图圈住的部分：
总的来说，如果一个 ACK 报文
5.知道SYN攻击吗？如何防范？
所谓
SYN 洪泛攻击
，就是利用
SYNACK 报文
的时候，服务器会为客户端请求分配缓存，那么黑客（攻击者），就可以使用一批虚假的
ip
向服务器大量地发建立
TCP 连接
的请求，服务器为这些
虚假ip
分配了缓存后，处在
SYN_RCVD
状态，存放在
半连接队列
中；另外，服务器发送的请求又不可能得到回复（ip都是假的，能回复就有鬼了），只能不断地
重发请求
，直到达到设定的时间/次数后，才会关闭。
服务器不断为这些
半开连接
分配资源（但从未使用），导致服务器的连接资源被消耗殆尽，不过所幸，我们可以使用
SYN Cookie
进行有效地防御。
防御系统，与前面接收到SYN Cookie
就分配缓存不同，此时暂不分配资源；同时利用SYN 报文
SYN 报文
源
目的地IP
，以及服务器存储的一个端口
，使用它们进行散列，得到秘密数
，然后附着在server_isn
中发送给客户端，接下来就是对SYNACK 报文
进行判断，如果其返回的ACK 报文
字段正好等于ack
，说明这是一个合法的server_isn + 1
，那么服务器才会为其生成一个具有套接字的全开的连接。ACK
SYN Cookie 防御
当然这种方案也有一定，最明显的就是缺点
，就服务器不保存连接的半开状态
了丧失
的能力，这一方面会降低正常用户的连接成功率，另一方面会导致某些情况下正常通信的双方会对连接是否成功打开产生误解，如客户端发给服务端的第三次握手消息（重发SYN-ACK消息
）半路遗失，客户端认为连接成功了，服务端认为没收到ACK
，连接没成功，这种情况就需要上层应用采取策略特别处理了。ACK
6.（ISN）是固定的吗？
不固定，
client_isn
是随机生成的，而
server_isn
则需要根据
SYN 报文
中的
源、ip和端口
，加上服务器本身的
密码数
进行相同的散列得到，显然这也不是固定的。
7.三次握手过程中可以携带数据吗？
讲过程的时候其实已经讲了，
第三次握手是可以携带数据的
，而前两次不行。
8. 关于 https 的认证过程？
限于篇幅，此处暂时不讲，留意后续文章。
四次挥手
握手
类似，每次
挥手
也代表一次报文的发出和接收。
因为自顶向上这本书里面的图比较简略，这里采用谢希仁版本的计算机网络中的图：
计算机网络-谢希仁-四次挥手
首先，当前客户端和服务器的状态都为
ESTABLISHED
，接下来我们详细讲解下上图的过程：
- 客户主机发起连接释放的请求，设置
FIN
1
seq
u
FIN-WAIT-1
 第一次挥手：FIN报文 - 服务端接收到
FIN 报文
ACK 报文
ACK
1
确认号
u + 1
CLOSE-WAIT
FIN-WAIT-2
 第二次挥手：ACK报文 - 服务器端准备好关闭连接时，向客户端发送结束连接请求，
FIN
1
LAST-ACK
ACK
 第三次挥手：FIN报文 - 客户端接收到服务端传来的
FIN 报文
TIME-WAIT
ACK 报文
CLOSED
客户端等待了某个固定时间（两个最大段生命周期，`2MSL`，2 Maximum Segment Lifetime）之后，没有收到服务器端的 `ACK` ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 `CLOSED` 状态。  第四次挥手：ACK报文
这里我们再来看下
rfc793
中关于四次挥手的简单例子：
rfc793-正常的关闭例子
- 四次挥手重要的是
TIME-WAIT
要确保服务器是否已经收到了我们的
ACK 报文
，如果没有收到的话，服务器会重新发
FIN 报文
给客户端，那么客户端再次收到
FIN 报文
之后，就知道之前的
ACK 报文
丢失了，就会再次发送
ACK 报文
1.为什么握手只要三次，挥手却要四次？
关键就在中间两步。
- 建立连接时，当服务器收到客户端的
SYN 报文
SYNACK 报文
ACK
SYN
- 但是关闭连接时，当服务器收到
FIN 报文
SOCKET
ACK 报文
FIN 报文
FIN 报文
2.为什么 TIME_WAIT 状态需要经过 2MSL 才能转换到 CLOSE 状态？
- 第一，为了保证客户端发送的最后一个
ACK 报文
ACK 报文
FIN 报文
ACK 报文
FIN 报文
TIME-WAIT
ACK 报文
FIN 报文
ACK 报文
FIN 报文
MSL
2MSL
FIN 报文
ACK 报文
TCP 连接
- 第二，防止已失效的连接请求报文段出现在新的连接中。客户端在发送完最后一个
ACK 报文
2MSL
![网络攻防技术（2021期末考试）[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)