TCP的三次握手和四次挥手

（一）三次握手的过程



        如图所示TCP建立连接的过程形象的称为三次握手，客户端和服务器就像在进行如下的对话：

        客户端：“可以连接你吗”

        服务器：“可以呀，什么时候”

        客户端：“就现在呀”

        第一次握手时：SYN表示连接请求，序号是1000表示用作网络通讯的临时地址。这个序号每发送一字节数据，序号就加一。

这样就可以在接收端排出收到数据的先后顺序，建立连接虽然没有发送数据，但是SYN位占一个字节（FIN也占一个字节）所以下次再发送的时候，就要从1001开始。mss表示最大段尺寸，建议服务器发来的数据段不要超过这个长度。

         第二次握手时：服务器收到服务器收到SYN包向客户端发送一个ACK确认包，同时发送一个自己的SYN包

         第三次握手：客户端收到SYN+ACK包并向服务器发送确认ACK.

       


至于为什么是三次握手而不是两次或者四次原因一般如下：

如果改成两次

（1）防止已过期的连接信息再次传到主机

       比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机；于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。传完东西后，断开。结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上。

（2）防止产生死锁

        计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

改成四次：

        经过大量的实践发现三次连接已经能够可靠地连接自然不必要设计的更加繁琐。

（二）四次挥手

         断开连接端可以是Client端，也可以是Server端。

      （1）假设Client端发起中断连接请求，就先发送FIN报文。

      （2）Server端接到FIN报文后，但是如果还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以服务器端先发送ACK，告诉Client端：请求已经收到了，但是我还没准备好，请继续等待停止的消息。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。

     （3）当Server端确定数据已发送完成，则向Client端发送FIN报文，告诉Client端：服务器这边数据发完了，准备好关闭连接了。      

     （4）Client端收到FIN报文后，就知道可以关闭连接了，但是他还是不相信网络，所以发送ACK后进入TIME_WAIT状态， Server端收到ACK后，就知道可以断开连接了。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，最后，Client端也可以关闭连接了至此，TCP连接就已经完全关闭了！关闭连接的过程如下图所示：