TCP协议：三次握手和四次挥手简述

在TCP报文的报头中，有几个标志字段：
1、SYN：同步连接序号，TCP SYN报文就是把这个标志设置为1，来请求建立连接；
2、ACK：请求/应答状态。0为请求，1为应答；
3、FIN：结束连线。FIN为0是结束连线请求，FIN为1表示结束连线；
4、RST：连线复位，先断开连接，然后重新建立连接；
5、PSH：通知协议栈尽快把TCP数据提交给上层程序处理；

三次握手（建立TCP连接）

交互双方需要知道双方均有接收和发送的能力，所以采用三次握手建立一个连接。

首先客户端发送建立连接的请求，告诉服务端：我要向你发送数据了，你能接收到吗？
然后服务端发出对客户端响应， 告诉客户端 我能接收到你发送的数据，你能接收到我发送的数据吗？
最后，客户端响应服务端 我能接收到你发送的数据，我要开始发送数据了。

第一次握手：客户端和服务器都处于CLOSED关闭状态，客户端将标志位SYN置为1，随机产生一个值seq=x，并将该数据包发给服务器，客户端进入SYN-SENT（同步已发送）状态。

第二次握手：服务端收到数据包后由标志物SYN=1得知客户端请求建立连接，服务端将标志位SYN和ACK都设置为1，确认号ack = x+1,随机产生一个值seq = y，并将该数据包发送给客户端以确认连接请求，服务端进入SYN-RCVD（同步收到）状态，此时操作系统为该TCP连接分配TCP缓存和变量；

第三次握手：客户端收到确认后，检查确认号ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1，ack = y+1，并且此时操作系统为该TCP连接分配TCP缓存和变量，并将该数据包发送给服务器，服务器检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，客户端和服务端进入ESTABLISHED（已建立连接）状态，完成三次握手，随后客户端和服务端就可以开始传输数据。

为什么客户端还要发送一次确认呢？可以二次握手吗？

答：为了避免已失效的连接请求报文段突然又传送到了服务端，因而产生错误。 如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端不理睬服务端的确认且不发送数据，则服务端一直等待客户端发送数据，非常浪费资源。

四次挥手（终止TCP连接）

第一次挥手：客户端发起中断连接请求，也就是发送FIN报文，告诉服务端我的数据已经全部发送完了，如果你还没有准备好，可以继续发送数据。客户端进入FIN-WAIT-1（终止等待1）状态，等待服务端确认；

第二次挥手：服务端发送ACK，告诉客户端，请求我收到了，但我还没有准备好，请你等我的消息。这个时候服务端进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态。客户端收到服务端的确认后就进入FIN_WAIT（终止等待2）状态，等待服务端发送连接释放报文段；

第三次挥手：服务端没有要向客户端发送的数据了，服务端发出连接释放报文段，服务器进入LAST-ACK（最后确认）状态，等待客户端的确认。

第四次挥手：客户端收到服务端发送的连接释放报文段后，对此发出确认报文段，客户端进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED（关闭）状态。

为什么A在TIME-WAIT状态必须等待2MSL的时间？

MSL最长报文段寿命Maximum Segment Lifetime，MSL=2

两个理由：
1、保证客户端发送的最后一个报文段能够到达服务器。
这个报文段有可能会丢失，使得处于LAST-ACK状态的服务端收不到对已发送的确认报文段，服务端超时重新发送连接释放报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，如果客户端在TIME-WAIT状态不等待一段时间，而是发送完确认报文段后立即释放连接，则无法收到服务端重传的连接释放报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。
2、防止已失效的连接请求报文段”出现在本连接中。
客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。