二次握手？？三次挥手？？

当我们学习《计算机网络》这门课程的时候，一定会学习到TCP这个经典的传输层协议，TCP里面有一个特性叫做连接管理，这个特性里面引出了两个概念，TCP三次握手和四次挥手。为什么是三次，和为什么是四次这个问题困扰了初学的我很久，今天就跟大家详细讲解一下这个原因。

关于这个问题，大多数的文章会引用《计算机网络》里面的一句话。

防止已经失效的连接请求又传到了服务器端，因而产生错误

实际上这么说太宽泛了，是无法真正理解的。

TCP的通信过程是什么样子的？

互相发送报文，这是一件非常容易理解的事情。

例如这样：

那么这个时候我们需要引入一个概念，叫做TCP的缓冲区：

TCP的缓冲区可以理解为一个非常巨大的数组：

当我们的应用层里面有数据传输过来，通过系统调用接口往传输层写数据是写在TCP协议的缓冲区里面，TCP会malloc两段内存空间。拥有缓冲区的作用很明显：

1. 提高应用层效率
2. 只有OS，TCP协议可以知道网络，乃至对方状态明细，所以也只有TCP协议，能处理如何发，什么时候发， 发多少，出错了怎么办等细节问题，因为缓冲区的存在，所以可以做到应用层和TCP进行解耦

我的TCP缓冲区里面放了很多数据，里面有一部分数据已经发送了，有一部分还没有发送，那么我们这次建立连接的时候要从哪里开发发送呢？这不一定是从0位置(下标)开始的，因此client端和server端需要知道对方的缓冲区从哪里(数组下标)开发发送数据。

• 为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
• 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

我们先来看一下TCP通信的完整过程：

大家可以看到这个双方确认序号的过程。

为什么TCP需要握手这个操作？能不能不要握手？

如果对比UDP协议的话可以发现，UDP协议中是不需要握手这个操作的，这里就需要引出TCP和UDP协议的特性了，一个关键的特性就是，TCP协议是可靠协议，UDP协议是不可靠协议。

可靠协议的含义是：接收方收到的数据是完整的，有序的，无差错的。

不可靠就代表着：接收方接收到的数据可能存在部分丢失，顺序也不可以保证。

TCP协议为了实现可靠性，通信双方就需要知道自己发送的数据是否已经被接收方收到了，如果没有收到，就需要重新发送。为了实现这个需求，就要引出序号和确认序号。

发送方在发送数据包（假设大小为 10 byte）时， 同时送上一个序号( 假设为 500)，那么接收方收到这个数据包以后， 就可以回复一个确认号（510 = 500 + 10） 告诉发送方 “我已经收到了你的数据包， 你可以发送下一个数据包， 序号从 510 开始” 。

这样发送方就可以知道哪些数据被接收到，哪些数据没被接收到， 需要重发。

于是就有了上图的过程，这样就很好解释为什么是3次，而不是2次了。

有人可能对上面一张图的TCP通信流程的数据有疑问。

• 为什么三次握手最后一次握手中， 在上面的示意图中回复的 seq = x+1 。

来看一下大黑书里面的一段话：

这里说的很复杂，实际上就是：我的ACK里面的序号是我下一个需要得到的序号。

那么为什么是四次挥手呢？

难道不能像三次握手一样去挥手吗？

答案是不可以的，原因是：TCP协议是全双工的。client和server两端都是要传输和处理数据的。我client端请求关闭链接，发送FIN，由OS内核规定，发送FIN了之后会马上回显ACK来表示我收到了这个信息，但是我的server端此时可能正在处理数据，所以不可以马上关闭，只能等事情处理完了之后发送FIN给client，表示我处理完了，client收到之后回显ACK表示收到，然后server关闭，client在2MSL之后也完成关闭。

如果server端没有任何事情处理，那么FIN和ACK就会合并在一起发送，也就是所谓的三次挥手。

也就是说，相比于三次握手，四次挥手多了一个等我把事情做完再给你回电话的过程。

就好像是我找胡桃出去玩：

我：胡桃，我们出去玩儿吧！

胡桃：可以呀！但是我有事情，等我把事情办完再给你打电话。

胡桃：我事情办完了，走吧！

我：好的！

为什么client等2MSL才关闭？

这也是可靠性的保证，如果我发出去的ACK丢包了我要等着重新发送，如果我秒退了怎么办？