TCP的三次握手建立连接和四次挥手释放连接
TCP的三次握手
TCP连接的建立采用客户服务器方式。主动发起连接的建立的应用进程叫做客户（client），而被动等待连接建立的应用进程叫做服务器（server）。
为什么不使用两次
（１）不使用两次的原因：假设客户端发送建立连接的请求由于网络原因滞留在了网络中，没有到达服务端，客户端没有收到确认请求就会进行超时重传这个建立连接的请求，假设服务端收到了第二次建立的连接请求，并返回向客户端发送同意建立连接的报文，至此，连接建立，之后发送数据，数据发送完之后关闭连接。
（２）若此时，滞留在网络中的客户端发送的第一次连接请求有到达了服务端，此时服务端并不知道这是之前的连接请求，会以为客户端又要建立连接，然后服务端发送给客户端同意建立连接的报文，至此又建立一次连接。
（３）如果使用三次握手，客户端在收到第（２）步中的同意建立连接的报文之后，就会丢弃，因为客户端自己知道自己没有要建立连接请求。
为什么不使用四次握手建立连接
（１）第一次握手：服务端：知道了客户端发送的情况，服务端接收的情况
（２）第二次握手：客户端：知道了客户端的发送和接收情况，服务端可以发送和接收
（３）第三次握手：服务端：服务端可以知道自己的发送情况，客户端的接收情况
至此：客户端和服务端都知道了对方的发送和接收能力，所以四次握手就会显得多余或者浪费资源。
TCP的四次挥手释放
客户端在收到服务端的关闭请求之后，为什么要等待２ＭＬ？
（１）为了保证客户端发送的最后一个ACK报文段能够到达服务端。这个ACK报文段有可能丢失，因而使处在LAST_ACK状态的B收不到对已发送的FIN+ACK报文段的确认。
此时服务端会超时重传这个FIN+ACK报文段，而客户端就能在2MSL时间内收到这个重传的FIN+ACK报文段。
接着客户端重传一次确认，重新启动2MSL计时器。
最后，客户端和服务端都正常进入到CLOSED状态。如果客户端在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到服务端重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。
这样，服务端就无法按照正常步骤进入CLOSED状态。
（２）防止"已失效的连接请求报文段"出现在本连接中。客户端在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
服务端只要收到了客户端发出的确认，就进入CLOSED状态。
同样，服务端在撤销相应的传输控制块TCB后，就结束了这次的TCP连接。我们注意到，服务端结束TCP连接的时间要比客户端早一些。
