Skip to content

Latest commit

 

History

History
90 lines (26 loc) · 3.14 KB

File metadata and controls

90 lines (26 loc) · 3.14 KB

49、画一下TCP三次握手流程图?为啥是三次而不是二次或者四次呢?

1、面试题

TCP三次握手和四次握手的工作流程是什么(画一下流程图)?为什么不是五次握手或者两次握手?

2、面试官心里分析

这个问题相当经典,大家可别以为就是考察应届生的,实际上在普通社招java面试中,一些大公司,很喜欢考察这个问题,尤其是后面第二个追加问题,让你聊聊为啥必须是三次握手,而不是两次呢?

3、面试题剖析

(1)tcp三次握手过程

通过传输层的tcp协议建立网络连接的时候,其实走的是三次握手的过程

建立三次握手的时候,TCP报头用到了下面几个东西,ACK、SYN、FIN。

第一次握手,客户端发送连接请求报文,此时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报文头,根据报文头是否正确,就是越好的协议来建立连接。简单说就是这样。

01_tcp三次握手

(2)为啥不是2次或者4次握手呢?

假设两次握手就ok了,要是客户端第一次握手过去,结果卡在某个地方了,没到服务端;完了客户端再次重试发送了第一次握手过去,服务端收到了,ok了,大家来回来去,三次握手建立了连接。

结果,尴尬的是,后来那个卡在哪儿的老的第一次握手发到了服务器,服务器直接就返回一个第二次握手,这个时候服务器开辟了资源准备客户端发送数据啥的,结果呢?客户端根本就不会理睬这个发回去的二次握手,因为之前都通信过了。

但是如果是三次握手,那个二次握手发回去,客户端发现根本不对,就会发送个复位的报文过去,让服务器撤销开辟的资源,别等着了。

因为3次握手就够了,不需要4次或者5次浪费资源了。

02_tcp连接为什么是3次握手

(3)tcp断开连接的4次挥手

第一次挥手,客户端发送报文,FIN=1,seq=u,此时进入FIN-WAIT-1状态

第二次挥手,服务端收到报文,这时候进入CLOSE_WATI状态,返回一个报文,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状态。

03_tcp的4次挥手断开连接