三次握手：
第一次握手：A的TCP客户进程也是首先创建传输控制块TCB，然后向B发出连接请求报文段，
第二次握手：B收到连接请求报文段后，如同意建立连接，则向A发送确认连接报文
第三次握手：TCP客户进程收到B的确认后，要向B给出确认报文段
为什么要进行三次握手？
也就是说为什么要在A最后还要再发送一次确认？
是为了防止已经失效的请求报文端，再次传到B，因而产生错误。
四次挥手：
第一次挥手：A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
第二次挥手：B收到连接释放报文段后即发出确认报文段，B进入CLOSE-WAIT（关闭等待）状态。A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
第三次挥手：B没有要向A发出的数据，B发出连接释放报文段，B进入LAST-ACK（最后确认）状态，等待A的确认。
第四次挥手：A收到B的连接释放报文段后，对此发出确认报文段，A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为在开启连接时，当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
TCP四次挥手总结
客户端发送FIN后，进入终止等待状态，
服务器收到客户端连接释放报文段后，就立即给客户端发送确认，服务器就进入CLOSE_WAIT状态，此时TCP服务器进程就通知高层应用进程，因而从客户端到服务器的连接就释放了。此时是“半关闭状态”，即客户端不可以发送给服务器，服务器可以发送给客户端。
此时，如果服务器没有数据报发送给客户端，其应用程序就通知TCP释放连接，然后发送给客户端连接释放数据报，并等待确认。
客户端发送确认后，进入TIME_WAIT状态，但是此时TCP连接还没有释放，然后经过等待计时器设置的2MSL后，才进入到CLOSE状态。
