建立TCP连接时的三次握手与四次挥手问题

1. 字段含义

1.1 状态字段

ACK 报文是用来应答的，SYN 报文是用来同步的
LISTEN：侦听来自远方TCP端口的连接请求
SYN-SENT：在发送连接请求后等待匹配的连接请求
SYN-RECETVED：在收到和发送一个连接请求后等待对连接请求的确认
ESTABLISHED：代表一个打开的连接，数据可以传送给用户
FIN-WAIT-1：等待远程TCP的连接中断请求，或先前的连接中断请求的确认
FIN-WAIT-2：从远程TCP等待连接中断请求
CLOSE-WAIT：等待从本地用户发来的连接中断请求
CLOSING：等待远程TCP对连接中断的确认
LAST-ACK：等待原来发向远程TCP的连接中断请求的确认
TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认
CLOSED：没有任何连接状态

1.2 传输中的涉及字段（重点字段）

序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
确认序号：Ack 序号，占32位，只有 ACK 标志位 为1时，确认序号字段才有效，Ack = Seq+1
标志位
- URG：紧急指针（urgent pointer）有效
- ACK：确认序号有效（用来应答的）
- SYN：发起一个新连接（用来同步的）
- PSH：接收方应该尽快将这个报文交给应用层
- RST：重置连接
- FIN：释放一个连接

注意：

不要将确认序号 Ack 与标志位中的 ACK 搞混了

确认方Ack=发起方Req+1，两端配对

2. 三次握手

2.1 原理

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN©，此时客户端处于 SYN_SEND 状态。

第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s) ，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于SYN_RCVD 的状态。

第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了链接。

2.2 作用

（1）确认双方的接受能力、发送能力是否正常。

（2）指定自己的初始化序列号，为后面的可靠传送做准备。

（3）如果是 HTTPS 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成。

2.3 涉及问题

为什么需要三次握手，两次不行吗？
第三次握手的必要性
（ISN）是固定的吗？
什么是半连接队列？
三次握手过程中可以携带数据吗？
如果第三次握手丢失了，客户端服务端会如何处理？
SYN攻击
什么是SYN攻击（SYN Flood）？如何检测SYN攻击？如何防御SYN攻击？

3. 四次挥手

3.1 原理

刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。

第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。

需要过一阵子以确保服务端收到自己的 ACK 报文之后，就处于关闭连接了，进入 CLOSED 状态。

3.2 涉及问题

（TIME WAIT）为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭？
挥手为什么需要四次？
四次挥手释放连接时，等待 2MSL 的意义？
为什么 TIME_WAIT 状态需要经过2MSL（最大报文段生存时间）才能返回到 CLOSE 状态？