上面这个图就是完整的三次握手过程
首先由 client 发出请求连接,即SYN=1 ACK=0,TCP 规定 SYN=1 时不能携带数据,但要消耗一个 seq,所以声明自己的seq=x
然后 Server 进行回复确认,即 SYN=1 ACK=1 seq=y ack=x+1
最后 Client 再进行一次确认,但不用SYN了,即ACK=1 seq=x+1 ack=y+1
整个过程中对应的TCP状态如下:
CLOSED:初始状态,表示TCP连接是”关闭着的”或”未打开的”
LISTEN:表示服务器端的某个SOCKET处于监听状态,可以接受客户端的连接
SYN_RCVD:表示服务器接收到了来自客户端请求连接的SYN报文。这个状态是在服务端的,但是它是一个中间状态,很短暂,平常我们用netstat或ss的时候,不太容易看到这种状态,但是遇到SYN flood之类的SYN攻击时,会出现大量的这种状态,即收不到三次握手最后一个客户端发来的ACK,所以一直是这个状态,不会转换到ESTABLISHED
SYN_SENT:这个状态与SYN_RCVD状态相呼应,,它是TCP连接客户端的状态,当客户端SOCKET执行connect()进行连接时,它首先发送SYN报文,然后随机进入到SYN_SENT状态,并等待服务端的SYN和ACK,该状态表示客户端的SYN已发送
ESTABLISHED:表示TCP连接已经成功建立,开始传输数据
以上就是三次握手的五种TCP状态,单从客户端服务端角度来区分的话,CLOSED和ESTABLISHED会在客户端和服务端都出现,而LISTEN和SYN_RCVD通常是出现在服务端,SYN_SENT出现在客户端
但通常在服务器和客户端并不是绝对的,比如 Nginx 的服务器中,Nginx 通常作为 web 代理服务器,它既是服务端,也是客户端,所以在查询统计 TCP 状态的时候,最好通过匹配端口来区分是客户端的还是服务端的,来更精确的定位问题。
接着看四次挥手的状态