面试官:TCP三次握手和四次挥手的工作流程是什么?
不念:首先说一下TCP三次握手。
- 第一次握手,客户端发送链接请求报文,此时
SYN=1、ACK=0、seq=x
,这就是个连接请求此时客户端处于SYN_SENT
状态,等待服务器响应。
- 第二次握手,服务端收到
SYN=1
的请求报文后需要返回一个确认的报文,ack=x+1,SYN=1,ACK=1,seq=y
,发送给客户端,自己处于一个SYN_RECV
的状态。
- 第三次握手,客户端接着又给服务端发送了
ack=y+1,ACK=1,seq=x+1
简单总结:其实说白了三次握手就是来回来去的三次请求,每次请求携带上次一堆的TCP报文头,根据报文头是否正确从而建立连接。
面试官:为什么不是五次握手或者两次握手?
不念:假设如果是两次握手的话,第一次客户端握手过去结果卡在某个地方了,没有到达服务端。
可是客户端再次重新又发送了第一次握手过去,服务端收到了并握手返回,接着彼此就建立了连接。
意外的是,之前卡住的第一次握手又死灰复燃发送到了服务端。
服务端直接返回一个第二次握手。这个时候服务器也就开辟了一个资源等待接收客户端的数据。
可是客户端直接就忽略了该回合的第二次握手,因为之前已经通信过了。
如果要是三次握手的话,那个第二次握手发回去之后客户端发现第一次握手已经被丢弃了,就会发送个复位的报文
过去,避免了资源的开销。
说白了就是两次握手可能会导致服务端资源的一个浪费。三次握手会有一个复位的报文从而避免这种情况。
不念:既然三次握手都可以保证连接,四次五次握手就有些浪费资源了。
面试官:不错,继续聊一聊为什么是四次挥手。
不念:好的。
- 第一次挥手,客户端发送报文,
FIN=1,seq=u
,此时进入FIN-WAIT-1
状态。 - 第二次挥手,服务端就收到报文,这是便进入
CLOSE_WAIT
状态,返回一个报文,ACK=1,ack=u+1 seq=v
。客户端收到这个报文后,直接进入到FIN-WAIT-2
状态,此时客户端到服务端的连接断开了。 - 第三次挥手,服务端发送连接释放的报文,
FIN=1,ack=u+1,seq=w
服务端进入LAST-ACK
状态。 - 第四次挥手,客户端收到连接释放的报文后,发应答报文,
ACK=1,ack=w+1,seq=u+1
,进入到TIME_WAIT
状态,等待一会客户端进入到CLOSED
状态,服务端收到报文之后就进入到CLOSED
状态。