TCP/IP的三次握手和四次挥手

TCP/IP协议的三次握手

三次握手是建立连接的过程，当客户端向服务端发起连接时，会先发一个连接请求数据包，询问服务端能否建立连接。我们称这包数据为SYN包。如果服务端同意建立连接则回一个SYN+ACK包，客户端收到后回ACK包，连接建立成功。

为什么不采用两次握手？

假设采用两次握手，当客户端向服务器发送一个SYN包，请求建立连接，因为某些原因并未到达服务器，在中间某个网络节点产生了滞留

为了建立连接客户端会重发SYN包，这次的数据包正常送达，

服务端会回复SYN+ACK包之后建立起了连接。

此时阻塞的网络节点突然恢复,第一个SYN包又送达至服务端。

    这时服务端会误认为是客户端又发起了一个新的连接,从而在两次握手后进入数据等待状态。

服务端认为是两个连接，而客户端认为是一个连接，造成了状态不一致，如果是在三次握手的情况下服务端收不到最后的ACK包，不会建立连接。所以本质上三次握手就是为了解决网络信道不可靠的问题，为了在不可靠的信道上建立起可靠的连接。

TCP/IP协议的四次挥手

处于连接状态中的客户端和服务端都可以发起关闭连接请求。此时需要四次挥手来进行连接关闭。

假设客户端主动向服务器发起关闭连接请求，他需要向服务端发FIN包,表示要关闭连接。

客户端进入终止等待1状态，这是第一次挥手。

服务端收到FIN包后向客户端发出ACK包，进入关闭等待状态，客户端进入终止等待2状态，这是第二次挥手。

服务端此时可以发送未发送的数据，而客户端还可以接收数据。待服务端发送完数据后，向客户端发送FIN包，进入最后确认状态，这是第三次挥手。

客户端收到FIN包后，向服务端发送ACK包，并进入超时等待状态，经过超时时间后关闭连接，而服务端收到ACK包后立即关闭连接，这是第四次挥手。客户端进入超时等待状态是为了确保服务端已经收到ACK包，假设客户端发送完最后一个ACK包后就关闭连接，一旦ACK包在网络中丢失，服务端将一直停留在最后确认状态。如果客户端发送最后一个ACK包后进入超时等待状态，服务端在未收到ACK包时会重发FIN包。客户端会响应这个FIN包，重发ACK包，并刷新超时时间。这个机制和三次握手一样，也是为了在不可靠的信道中，进行可靠的连接断开确认。