前言
TCP协议为数据提供可靠的端到端的传输，处理数据的顺序和错误恢复，保证数据能够到达其应到达的地方。TCP协议是面向连接的，在两台主机使用TCP协议进行通信之前，会先建立一个TCP连接（三次握手），双方不再继续通信时，会将连接释放（正常情况下四次挥手）。下面就抓包分析TCP三次握手和四次挥手的过程。
建立连接——三次握手
第一次握手
客户端192.168.1.148发送一个建立TCP连接的请求包给服务器端174.143.213.184。可以从数据包中得出，建立连接源端口为57678，目标端口为80，确认编号为0。同步标志位SYN被置为1，表示请求连接建立。TCP首部长度大于20字节，说明选项中也附带了一些内容，给出最大段长度为1460字节，允许使用选择确认等。
第二次握手
服务器端收到请求后，发送给客户端确认包。该数据包中包含服务器的初始序列号为0，以及对请求包的确认，所以确认号为1也是期望下一个收到的包的字节流编号是从2开始的。
第三次握手
客户端向服务器端发出确认包，序号是从1开始，确认号为1，标志位只有ACK被置为1，说明这是一个确认包。于是便完成TCP连接建立。在这个包发送后，客户端就已将可以向服务器端请求数据，正常通信了。
关闭连接——三次挥手
四次挥手过程
放一张以前做的图介绍TCP四次挥手的过程：
当客户端向服务器端发起连接关闭请求时，因为服务器端还有数据发送给客户端所以不能立马将连接关闭，于是先回复客户端ACK表示你的请求我已经收到。然后将剩下的数据继续发送给客户端，数据发送完毕后，在回复给客户端的ACK包中将FIN标志置为1，请求连接关闭。最后，客户端回复ACK包表示收到服务器端的FIN。服务器端收到此ACK包后立马就关闭连接。客户端继续等待2MSL（因为发送给客户端的ACK包可能会丢失），服务器端没有重传包回来就关闭连接。到此，整个连接算是完全结束。
以上过程是标准的释放过程，但是在实际通信当中，可能只会有三次挥手。当客户端发送FIN包给服务器端，服务器端因为没有数据再传给客户端，于是就会在回复给客户端的FIN的ACK包中将FIN字段置位1，发送给客户端的包就为ACK+FIN，表示我也要求连接关闭。然后，客户端回复一个ACK确认收到FIN+ACK包，服务器端就关闭连接，客户端等待2MSL后也关闭连接。
上图就是三次挥手的数据包截图
第一次挥手
客户端192.168.1.140向服务器端172.143.213.184请求断开连接。
第二次挥手
因为服务器端没有数据传给客户端于是将回复给客户端的ACK包中FIN置为1，表示也请求连接断开。
第三次挥手
客户端对服务器端的FIN+ACK进行回复。服务器端收到该ACK包就关闭连接。
小结
回头想一想TCP为什么是三次握手呢，两次好像也是可以的。但是，这里存在一个问题，网络中的包是会延迟的，如果有一个很久以前的连接请求发送到了服务器端（实际上客户端已经发送了新的连接请求给服务器端，完成了数据请求并且连接已经关闭），服务器端并不知道这是以前的连接请求，于是也会回复一个ACK并且等待客户端的下一次请求。客户收到该ACK不会回复，就会造换成服务器端一直等待并且超时重发ACK包。所以，两次握手是不可以的，四次握手也是显得多余的。三次握手最后一次客户端回复ACK给服务器端，服务器端收到后，才分配资源等待客户端的正式请求。
总结一句话需要三次握手的原因是：客户发送确认服务器发送的接收连接报文是为了防止以前的连接请求即失效连接请求发送到服务器而造成错误。