常见问题
1.详细描述三次握手和四次挥手的过程。
2.三次握手可以变成两次握手吗？
3.简述 TCP 连接和关闭的状态转移。
4.简述TCP 四次挥手的 TIME_WAIT状态，以及为什么需要有这个状态
重要的字段定义与作用
（1）序号(sequence number)：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认号（acknowledgement number）：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：
| 标志位 | 含义 |
|---|---|
| URG | 紧急指针（urgent pointer）有效。 |
| ACK | 确认序号有效。（为了与确认号ack区分开，我们用大写表示） |
| PSH | 接收方应该尽快将这个报文交给应用层。 |
| RST | 重置连接。 |
| SYN | 发起一个新连接。 |
| FIN | 释放一个连接。 |
这些字段有什么作用呢？
seq序号、ack序号：用于确认数据是否准确，是否正常通信。
标志位：用于确认/更改连接状态
1. 三次握手
1.1 三次握手的详细过程
1）第一次握手：建立连接时，把SYN置1，客户端向服务器发送SYN包（seq=x），请求建立连接，等待确认。
2）第二次握手：服务端收到客户端的SYN包，回一个ACK包（ack=x+1）确认收到，同时发送一个SYN包（seq=y）给客户端，也就是把SYN+ACK报文发送给客户端。
3）第三次握手：客户端收到服务器的SYN+ACK包后，再回一个ACK包（ack=y+1）告诉服务端已经收到。
三次握手完成，成功建立连接，开始传输数据。通过以上三次连接，不管是服务端还是客户端都彼此知道了，我既能给对方发送消息也能收到对方的消息，那么这个连接就能被安全的建立了。
1.2 三次握手的状态变化：
一开始客户端和服务器同时属于CLOSED状态，表示没有连接关系。
客户端发送请求，客户端打开发送(SYN-SENT)状态，同时服务器打开监听(Listen)状态；（第一次）
服务器在接收到客户端的请求时，服务器切换为回复(SYN-RCVD)状态；（第二次）
客户端在接收到服务器的响应时，客户端切换为稳定连接(Established)状态的同时发送第二次数据包。（第三次）
服务器在接收到客户端的第二次数据时，服务器切换为稳定连接(Established)状态。
双方建立稳定连接后，开始正常通信数据。
1.3 场景模拟
第一次握手：你能和我建立连接吗，可以接受到我的数据吗。
SYN = 1 ，seq = x
第二次握手：可以建立连接，我接受到你的请求了，能接受到我的数据吗，你的数据是这个吗
SYN = 1 ，ACK = 1 ，seq = y ，ack = x + 1
第三次握手：我已经收到你的回复，这是我的数据，这是你的数据（用于再次核对）
ACK = 1 ，seq = x + 1 ，ack = y + 1
建立连接成功。
2. 四次挥手
2.1 四次挥手的详细过程
1）客户端发送FIN包（FIN=1)给服务端，告诉它自己的数据已经发送完毕，请求终止连接，此时客户端不发送数据，但还能接收数据
2）服务端收到FIN包，回一个ACK包给客户端告诉它已经收到包了，此时还没有断开socket连接，而是等待剩下的数据传输完毕
3）服务端等待数据传输完毕后，向客户端发送FIN包，表明可以断开连接
4）客户端收到后，回一个ACK包表明确认收到，等待一段时间，确保服务端不再有数据发过来，然后彻底断开连接
2.2 说说 TCP 2次握手行不行？为什么要3次
为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认
3. 简述 TCP 连接 和 关闭的状态转移
上半部分是TCP三路握手过程的状态变迁，下半部分是TCP四次挥手过程的状态变迁。
1.CLOSED：起始点，在超时或者连接关闭时候进入此状态，这并不是一个真正的状态，而是这个状态图的假想起点和终点。
2.LISTEN：服务器端等待连接的状态。服务器经过 socket，bind，listen 函数之后进入此状态，开始监听客户端发过来的连接请求。此称为应用程序被动打开（等到客户端连接请求）。
3.SYN_SENT：第一次握手发生阶段，客户端发起连接。客户端调用 connect，发送 SYN 给服务器端，然后进入 SYN_SENT 状态，等待服务器端确认（三次握手中的第二个报文）。如果服务器端不能连接，则直接进入CLOSED状态。
4.SYN_RCVD：第二次握手发生阶段，跟 3 对应，这里是服务器端接收到了客户端的 SYN，此时服务器由 LISTEN 进入 SYN_RCVD状态，同时服务器端回应一个 ACK，然后再发送一个 SYN 即 SYN+ACK 给客户端。状态图中还描绘了这样一种情况，当客户端在发送 SYN 的同时也收到服务器端的 SYN请求，即两个同时发起连接请求，那么客户端就会从 SYN_SENT 转换到 SYN_REVD 状态。
5.ESTABLISHED：第三次握手发生阶段，客户端接收到服务器端的 ACK 包（ACK，SYN）之后，也会发送一个 ACK 确认包，客户端进入 ESTABLISHED 状态，表明客户端这边已经准备好，但TCP 需要两端都准备好才可以进行数据传输。服务器端收到客户端的 ACK 之后会从 SYN_RCVD 状态转移到 ESTABLISHED 状态，表明服务器端也准备好进行数据传输了。这样客户端和服务器端都是 ESTABLISHED 状态，就可以进行后面的数据传输了。所以 ESTABLISHED 也可以说是一个数据传送状态。
下面看看TCP四次挥手过程的状态变迁。
1.FIN_WAIT_1：第一次挥手。主动关闭的一方（执行主动关闭的一方既可以是客户端，也可以是服务器端，这里以客户端执行主动关闭为例），终止连接时，发送 FIN 给对方，然后等待对方返回 ACK 。调用 close() 第一次挥手就进入此状态。
2.CLOSE_WAIT：接收到FIN 之后，被动关闭的一方进入此状态。具体动作是接收到 FIN，同时发送 ACK。之所以叫 CLOSE_WAIT 可以理解为被动关闭的一方此时正在等待上层应用程序发出关闭连接指令。TCP关闭是全双工过程，这里客户端执行了主动关闭，被动方服务器端接收到FIN 后也需要调用 close 关闭，这个 CLOSE_WAIT 就是处于这个状态，等待发送 FIN，发送了FIN 则进入 LAST_ACK 状态。
3.FIN_WAIT_2：主动端（这里是客户端）先执行主动关闭发送FIN，然后接收到被动方返回的 ACK 后进入此状态。
4.LAST_ACK：被动方（服务器端）发起关闭请求，由状态2 进入此状态，具体动作是发送 FIN给对方，同时在接收到ACK 时进入CLOSED状态。
5.CLOSING：两边同时发起关闭请求时（即主动方发送FIN，等待被动方返回ACK，同时被动方也发送了FIN，主动方接收到了FIN之后，发送ACK给被动方），主动方会由FIN_WAIT_1 进入此状态，等待被动方返回ACK。
6.TIME_WAIT：从状态变迁图会看到，四次挥手操作最后都会经过这样一个状态然后进入CLOSED状态。
4.简述 TCP 四次挥手的 TIME_WAIT状态，为什么需要有这个状态
TIME_WAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它是任何报文段被丢弃前在网络内的最长时间。
对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。
理论上，四次挥手的四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一次挥手的ACK，也就是最后一个ACK会丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
5. 简述什么是 MSL，为什么客户端连接要等待2MSL的时间才能完全关闭
MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
- 两个理由：
1.保证客户端发送的最后一个ACK报文段能够到达服务端。
这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。
2.防止“已失效的连接请求报文段”出现在本连接中。
客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。
