TCP三次握手，四次挥手

三次握手：

交换的信息是：序列号syn，确认号ack，头部标志位

1. SYN：客户端发送一个TCP包，其SYN标志位设置为1，序列号设为随机值x。
2. SYN-ACK：服务器收到客户端的SYN包后，回复一个TCP包，其中SYN和ACK标志位都设置为1。这个包的序列号设为另一个随机值y，确认号设为x+1。
3. ACK：客户端收到SYN-ACK包后，发送一个ACK包来确认连接的建立。该包的序列号设为x+1，确认号设为y+1。

为什么是三次握手，两次or四次为什么不行？

两次握手：客户端发，服务收到后发，两方即可建立连接

存在的问题：这个过程确认了客户端发送能力正常，服务端发送，接受能力正常，但是没能确认客户端的接收能力是否正常

三次握手

目的一（有争议）：防止已失效的连接请求又传送到服务器端，因而产生错误

之所以需要进行三次握手，是第二次握手后，如果服务器发送的 SYN和ACK 报文段丢失，客户端无法收到确认消息，此时客户端就会重新发送 SYN ，而服务器会重新创建连接请求队列。如果此时原来的 SYN 报文段突然到达服务器，服务器会认为是一个新的连接请求，从而建立多余的连接，造成资源浪费和安全风险。

目的二：(38条消息) TCP 为什么三次握手而不是两次握手（正解版）_tcp三次握手为什么不能两次_贺二公子的博客-CSDN博客

• 为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
• 如果只是两次握手，至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认
• 

 为什么 A 要先进入TIME-WAIT状态，等待2MSL时间后才进入CLOSED状态

为了保证B能收到A的确认应答。若A发完确认应答后直接进入CLOSED状态，那么如果该应答丢失，B等待超时后就会重新发送连接释放请求，但此时A已经关闭了，不会作出任何响应，因此B永远无法正常关闭。

为什么是四次挥手，三次是否可以？

从工程角度看，tcp是全双工的，因此每个方向都必须单独进行关闭:当一方完成它的数据发送任务后就发送一个FIN来终止这个方向的连接，对端收到后回复一个ACK报文，这样双向就需要四次交互。

Client主动关闭的情况下，Server收到Client的FIN报文时，仅仅表示Client没有数据发送给Server了；但Server可能还有数据要发送给Client，所以Server可能并不会立即关闭SOCKET，而是先回复一个ACK报文，告诉Client“你发的FIN报文我收到了”。只有等到Server所有的报文都发送完了，才发送FIN报文。也就是说，被动关闭方的ACK和FIN报文多数情况下都是分开发送的，所以需要四次交互。

   第一次挥手 ： 主动方 发送断开连接的请求（FIN 报文）给被动方， 仅仅代表 主动方不会发送 数据报文了，但仍然可以接受数据报文。

   第二次挥手：  被动方可能还有一些数据报文需要发送，因此会先发送 ACK 报文，告知 主动方 “我知道了你不想发送数据了”。这样主动方 便不会因为没有收到应答 而继续向被动方继续发送断开连接的请求（FIN 报文）。

   第三次挥手：  被动方处理完数据报文后，便主动发送 FIN 报文；（这样可以保证数据通信正常可靠的完成）， 被动方进入 LAST_ACK 阶段（超时等待）。

   第四次挥手：  如果主动方及时发送 ACK 报文 进行 连接中断的确认，这是被动方就直接释放连接，进入可用状态。

2MSL原因

为了保证主动关闭方发送的最后一个ACK报文能够到达被动关闭方。因为这个ACK有可能无法到达对端，这样对端会重发FIN报文，这时候主动关闭方需要重发ACK。

保证本连接的所有报文在网络上消失。如果没有这个机制，可能会对新连接产生干扰。

举例如下：

1、A和B正常建立TCP连接，数据传输，然后断开连接。但是由于网络传输原因，A发给B的seq为100的报文滞留在了网络上。

2、 A和B再次建立连接，所用IP和端口与1中相同，二者数据传输过程中，B正好请求A发送seq为100的数据，这时1中滞留的报文到达B，TCP认为该报文合法，就接收了这个报文。