TCP三次握手与四次挥手

三次握手

TCP建立连接的三次握手

SYN，同步位；ACK，确认位；seq Sequence Number，序列号；ack Acknowledgment Number，确认号

TCP建立连接步骤：

①    客户端发送报文，SYN=1，表明是一个请求建立连接的报文，此报文不能携带数据，消耗一个序列号。报文发送后，客户端进入SYN-SEND（同步发送）状态。

②    服务端收到客户端的建立连接报文，如同意建立连接，则向客户端回应一个SYN=1 ACK=1的报文，表明这是一个同意建立连接的响应的报文，此报文不能携带数据，消耗一个序列号。报文中SYN=1 ACK=1 ack=x+1 seq=y。报文发送后服务端进入SYN-RECV（同步收到）状态。

③    客户端收到服务端的建立连接报文后，向服务端回应确认报文。其中ACK=1 ack=y+1 seq=x+1.此报文可以携带数据，如不携带数据，则不消耗序列号，即下一个报文的序列号仍为x+1。客户端在发送确认报文后进入建立连接状态，服务端在收到确认报文后进入建立连接状态。

为什么是三次握手？

①    防止失效的请求连接报文突然传到服务端，产生错误：客户端发出的第一个连接请求可能在某些节点滞留，由于超时重传，客户端再次向服务端发送该请求并成功建立连接，完成数据传输后，客户端释放连接，此后之前的滞留报文到达服务端，如果是两次握手就建立连接，服务端将在此时建立连接，但是客户端并未发起对应的连接请求，不会向服务端发送数据，建立的这个错误连接将会浪费服务端的系统资源，因此服务端在收到客户端关于建立连接的确认报文后才会建立对应的连接，即通过三次握手建立连接。

②    三次握手是保证信道可用的最少确认次数：理论上无论多少次确认都不可能保证一条信道是可靠的。通过三次握手，至少可知此信道可用，再增加握手次数只是提高信道可用的可信度。

四次挥手

TCP释放连接的四次挥手

FIN，终止位

①    客户端向服务端发出释放连接请求：FIN=1 seq=u。FIN=1表明此报文发送方的数据已发送完毕，要求释放链接。FIN报文不携带数据，消耗一个序列号。报文发送完毕后，客户端进入FIN-WAIT1（终止等待1）状态。

②    服务端收到释放连接请求后，向客户端发送确认报文ACK=1 ack=u+1 seq=v。报文发送后，服务端进入CLOSE-WAIT（关闭等待）状态，服务端进程应通知高层应用进程，客户端到服务端的连接要释放。客户端收到服务端的此报文后进入FIN-WAIT2（终止等待2）状态。此时TCP处于半关闭状态，即客户端不再主动发送数据，但能接受服务端发送的数据。

③    服务端如已经没有要向客户端发送的数据，其应用进程就通知TCP释放连接，报文FIN=1 ACK=1 ack=u+1 seq=w。发送完毕后服务端进入LAST-ACK（最后确认）状态。

④    客户端收到服务端的释放连接报文后，必须发出确认报文ACK=1 ack=w+1 seq=u+1。客户端发送完毕后进入TIME-WAIT（时间等待）状态，等待2MSL（Maximum Segment Lifetime，最大报文生存时间，超过这个时间报文将被丢弃），之后客户端进入CLOSE（连接关闭）状态。服务端在收到客户端的确认报文后即进入CLOSE（连接关闭）状态。

为什么是四次挥手？

双方关闭连接要经过双方都同意。所以，首先是客服端给服务器发送FIN，要求关闭连接，服务器收到后会发送一个ACK进行确认。服务器然后再发送一个FIN，客户端发送ACK确认，并进入TIME-WAIT状态。等待2MSL后自动关闭。

为什么要等待2MSL？

①    为了保证客户端发送的最后一个ACK报文段能够到达服务器。即最后一个确认报文可能丢失，服务器会超时重传，然后服务器发送FIN请求关闭连接，客户端发送ACK确认。一个来回是两个报文生命周期。如果没有等待时间，发送完确认报文段就立即释放连接的话，服务器就无法重传，因此也就收不到确认，就无法按步骤进入CLOSE状态，即必须收到确认才能close。

②    防止已经失效的连接请求报文出现在连接中。经过2MSL，在这个连续持续的时间内，产生的所有报文段就可以都从网络消失。