网络协议抓包分析——TCP传输控制协议（连接建立、释放）

前言

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给服务器端，服务器端收到后，才分配资源等待客户端的正式请求。
总结一句话需要三次握手的原因是：为了防止以前的连接请求即失效连接请求发送到服务器而造成错误。