TCP之三次握手与四次挥手

三次握手

三次握手的过程是为了确认双方的接收与发送能力是否正常。

1、第一次握手：客户端给服务器发送一个 SYN 报文，这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文，这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文，这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

4、服务器收到 ACK 报文之后，三次握手建立完成。

具体过程：

当客户端发出第一个连接请求报文段时并没有丢失，而是在某个网络节点出现了长时间的滞留，以至于延误了连接请求在某个时间之后才到达服务器。这应该是一个早已失效的报文段。但是服务器在收到此失效的连接请求报文段后，以为是客户端的一个新请求，于是就想客户端发出了确认报文段，同意建立连接。假设不采用三次握手，那么只要服务器发出确认后，新的连接就可以建立了。但是由于客户端没有发出建立连接的请求，因此不会管服务器的确认，也不会向服务器发送数据，但服务器却以为新的运输连接已经建立，一直在等待，所以，服务器的资源就白白浪费掉了。

四次挥手

tcp是全双工通信，服务端和客服端都能发送和接收数据。

tcp在断开连接时，需要服务端和客服端都确定对方将不再发送数据。

• 第1次挥手由客户端向服务端发起，服务端收到信息后就能确定客户端已经停止发送数据。
• 第2次挥手由服务端向客户端发起，客户端收到消息后就能确定服务端已经知道客户端不会再发送数据。
• 第3次握手由服务端向客户端发起，客户端收到消息后就能确定服务端已经停止发送数据。
• 第4次挥手由客户端向服务端发起，服务端收到信息后就能确定客户端已经知道服务端不会再发送数据。

为什么需要四次挥手？而三次却不可以：

主要是为了确认客户端和服务器端都已经关闭了，避免出现以下两种情况（此处暂时忽略超时机制）

1）客户端不知道服务器端已经关闭，还在继续发送消息，浪费网络资源。

2）服务器端不知道客户端已经关闭，还在等着客户端发来的消息，浪费服务器资源。

为什么TCP客户端最后还要发送一次确认呢？

主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

为什么2、3次挥手不能合在一次挥手中？

因为TCP是一个全双工协议，必须单独拆除每一条信道。4次挥手的目的是终止数据传输，并回收资源，在客服端第1次挥手时，服务端可能还需要发送数据，在服务端的数据发送完成后，才能通知客户端不在发送数据。所以第2次挥手和第3次挥手不能合并。此时客服端虽然不再发送数据了，但是还可以接收数据，服务端可能还有数据要发送给A，所以两次挥手不能合并为一次。

挥手次数比握手多一次，是因为握手过程，通信只需要处理连接。而挥手过程，通信需要处理数据+连接。

当客户端发出第一个连接请求报文段时并没有丢

文章参考自：

【TCP/IP】四次挥手的过程及原因 - 简书

今日头条