TCP的三次握手与四次挥手

置位概念：根据TCP的包头字段，存在3个重要的标识ACK、SYN、FIN 
ACK：表示验证字段 
SYN：位数置1，表示建立TCP连接 
FIN：位数置1，表示断开TCP连接

1. 源端口号：表示发送端端口号，字段长为16位。 
2. 目标端口号：表示接收端口号，字段长为16位。 
3. 序列号：表示发送数据的位置，字段长为32位。每发送一次数据，就累加一次该数据字节数的大小。 
注意：序列号不会从0或1开始，而是在建立连接时由计算机生成的一个随机数作为其初始值，通过SYN包发送给接收端主机。然后再将每转发过去的字节数累加到初始值上表示数据的位置。 
4. 确认应答号：表示下一次应该收到的数据的序列号，字段长为32字节。发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。

1、三次握手

step1:第一次握手

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

step2:第二次握手

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

step3:第三次握手

客户端收到服务器的SYN+ACK包，向服务器发送一个序列号(seq=J+1)，确认号为ack(客户端)=K+1，此包发送完毕，客户端和服务器进入ESTAB_LISHED(TCP连接成功)状态，完成三次握手。

未连接队列

在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包(syn=j)开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包时，删除该条目，服务器进入ESTAB_LISHED状态。

为什么TCP客户端最后还要发送一次确认呢？主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

2、四次挥手过程

step1：第一次挥手

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

step2：第二次挥手

服务器收到这个FIN，它发送一个ACK，确认ack为收到的序号加一。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

step3：第三次挥手

当服务器端数据发送完毕，关闭服务器到客户端的连接，发送一个FIN给客户端。

step4：第四次挥手

客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

为什么客户端最后还要等待2MSL？

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。 
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。