经典话题-三次握手和四次挥手

一、三次握手具体实现过程

第一次握手：建立连接时，客户端发送SYN包到服务器，其中包含客户端的初始序号seq=x，并进入SYN_SENT（同步已发送）状态，等待服务器确认。（其中，SYN=1，ACK=0，表示这是一个TCP连接请求数据报文；序号seq=x，表明传输数据时的第一个数据字节的序号是x）。）

第二次握手：服务器收到请求后，必须确认客户的数据包。同时自己也发送一个SYN包，即SYN+ACK包，此时服务器进入SYN_RECV（同步收到）状态。（其中确认报文段中，标识位SYN=1，ACK=1，表示这是一个TCP连接响应数据报文，并含服务端的初始序号seq(服务器)=y，以及服务器对客户端初始序号的确认号ack(服务器)=seq(客户端)+1=x+1））

第三次握手：客户端收到服务器发送的SYN+ACK后，向服务器发送ACK确认包，此时客户端和服务器进入ESTABLISHED(已建立连接）状态，完成三次握手。（客户端收到服务器的SYN+ACK包，向服务器发送一个序列号(seq=x+1)，确认号为ack(客户端)=y+1，此包发送完毕，客户端和服务器进入ESTAB_LISHED(TCP连接成功)状态，完成三次握手。）

为什么要进行三次握手？
TCP协议是一个面向连接的，可靠，全双工的传输协议，为了保证双方连接的成功建立，进行了三次握手。

为什么要进行三次，而不是两次
如果是两次握手，假设服务器给客户端在第二次握手时发送数据，数据从服务器发出，服务器认为连接已经建立，但在发送数据的过程中数据丢失，客户端认为连接没有建立，会进行重传。假设每次发送的数据一直在丢失，客户端一直SYN，服务器就会产生多个无效连接，占用资源

二、四次挥手详细过程

第一次挥手：首先，客户端发送一个FIN，用来关闭客户端到服务器的数据传送，然后等待服务器的确认。其中终止标志位FIN=1，序列号seq=u。

第二次挥手：服务器收到这个FIN，它发送一个ACK，确认ack为收到的序号加一（从客户端到服务器的连接就释放了。此时是“半关闭状态”，即客户端不可以发送给服务器，服务器服务端可以发送给客户端。）

第三次挥手：关闭服务器到客户端的连接，发送一个FIN给客户端。

第四次挥手：客户端收到FIN后，并发回一个ACK报文确认（客户端发送确认后，进入TIME_WAIT状态，但是此时TCP连接还没有释放，然后经过等待计时器设置的2MSL后，才进入到CLOSED状态。）

第四次挥手的作用是什么
（1）为了保证客户端发送的最后一个ACK报文段能够到达服务器。
（2）防止已经失效的连接请求报文出现在连接中。经过2MSL，在这个连续持续的时间内，产生的所有报文段就可以都从网络消失。

TCP四次挥手close_wait状态是什么时候？如果一直close_wait可能是什么原因造成的？
在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处CLOSE_WAIT状态。没有写 close 函数关闭 socket 连接，或者出现死循环，服务器端的代码永远执行不到 close。

time_wait的作用是什么
2MSL：最大报文生存时间，超过该时间则报文被丢弃，等2ML是为了防止最后一个ACK包对方没有收到，那么在超时后服务端将重发第三次挥手的FIN包，客户端收到后可以再次发一个ACK应答包。如果没有等待时间，发送完确认报文段就立即释放连接的话，服务器就无法重传，因此也就收不到确认，就无法按步骤进入CLOSED状态，即必须收到确认才能close。

为什么连接的时候是三次握手，关闭的时候却是四次挥手
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。