TCP的三次握手四次挥手

三次握手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

• 客户端：服务器，我想要和你建立连接，你同意吗？（SYN＝１）
• 服务器：客户端，我同意和你建立连接（ACK＝１）；我也想和你建立连接，你同意吗？（SYN＝１）
• 客户端：服务器，我同意和你建立连接。（ACK＝１）

其实，在进行第二次握手时（即服务器向客户端进行应答时），可以看作时发了两次包，先回答客户端的服务请求（ACK＝１，确认号ack＝x+１），然后向客户端发出请求（SYN＝１，序列号seq＝ｙ）

问题1： 三次握手中，为什么客户端最后还要再向服务器发送一次确认呢？
答：这是为了防止已失效的连接请求报文段突然又传到了服务器。所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常的情况，客户端发出连接请求，但因为连接请求报文丢失而未收到确认。于是客户端再重传了一次连接请求，后来收到了确认，建立了连接。数据传输完后，就释放了连接。客户端共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务器，没有所谓的“已失效的连接请求报文段”。

四次挥手

（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。
（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A。
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。

• 客户端：服务器，我想和你断开连接，你同意吗？（FIN=1）
• 服务器：我同意（ACK=1）
  （在此期间，服务器可能还会向客户端发送数据，但是客户端却不能再向服务器发送数据）
• 服务器：客户端，我想要和你断开连接，你同意吗？（FIN=1）
• 客户端：我同意。（ACK=1）
  再等待2**MSL（四分钟）时间后就真正断开了连接。

问题2： 为什么客户端发送完最后一个数据后要在TIME-WAIT状态等待一段时间呢？
答：第一：为了保证客户端最后发送的那个ACK报文段能够到达服务器。这个ACK报文段可能会丢失。因而使处在LAST-ACK状态的B收不到对已发送的FIN＋ACK报文段的确认。服务器会超时重传这个FIN＋ACK报文段，而客户端就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务器都可以进入到CLOSED（关闭）状态。如果没有2MSL等待时间，那么就无法收到重传的FIN+ ACK包，无法进入正常的CLOSED状态。
第二，防止“已失效的连接请求报文段”出现在本连接中。客户端在发送完最后一个ACK报文段，再经过时间2MSL，就可以使本连接持续的时间内所产生的报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。