TCP三次握手问题详解

tcp三次握手过程

首先以通俗易懂的方式来描述此过程

• 第一次

浏览器----------》服务器
浏览器告诉服务器，我要和你建立连接了

• 第二次

浏览器《----------服务器
服务器知道浏览器和自己建立连接，并告诉浏览器可以和自己建立连接了

• 第三次

浏览器----------》服务器
服务器发起建立连接的请求，浏览器收到服务器建立连接的请求

真实的三次握手

也是要确认双方的两样能力：发送能力与接收的能力。

 

最开始双方都属于CLOSED状态。然后服务器开始监听某个端口，进入LISTEN状态。

• 客户端注重发起连接，发送SYN，自己变成了SYN-SENT状态

• 服务端收到，返回SYN和ACK（对应客户端发来的SYN），自己变成了SYN-RECD

• 客户端再发送ACK给服务端，自己变成ESTABLISHED（established）状态；服务端收到ACK之后，也变成这个状态

其中SYN需要对端的确认，而ACK并不需要，因此SYN消耗一个序列号而ACK不需要。

凡是需要对端确认的，一定消耗TCP报文的序列号。

为什么不是两次？

如果只是两次握手，第二次握手后服务器端会认为自己已经与客户端建立了连接，假如此时网络出现问题，丢失了第二次握手的报文。那么客户端没有收到应答报文，他认为与服务器端并没有建立连接，那么之后服务器端向客户端发来的消息，客户端并不会接受，而是一直等待应答报文。因此，需要三次握手才能确认双方的接收与发送能力是否正常

TCP三次握手原因，而不是四次

因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好

TCP三次握手能携带数据吗

TCP三次握手阶段只有第三次握手（ACK）可以携带数据，用于开始数据传输。因为在TCP连接的建立过程中，这时双方已经确认了彼此的通信能力和可靠性，因此可以开始发送数据。前两次握手主要是用来建立连接的必要信息交互。

三次握手连接阶段，最后一次ACK包丢失，会发生什么

如果最后一次ACK包丢失，会导致连接建立失败。TCP通过超时重传机制来解决这个问题，重新发送ACK包以尝试建立连接。