面试官：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状态。 ...