“三次握手，四次挥手”你真的懂吗？

记得刚毕业找工做面试的时候，常常会被问到：你知道“3次握手，4次挥手”吗？这时候我会“成竹在胸”地“背诵”前期准备好的“答案”，第一次怎么怎么，第二次……答完就没有下文了，面试官貌似也没有深刻下去的意思，深刻下去我也不懂，皆大欢喜！

做为程序员，要有“刨根问底”的精神。知其然，更要知其因此然。这篇文章但愿能抽丝剥茧，还原背后的原理。

什么是“3次握手，4次挥手”

TCP是一种面向链接的单播协议，在发送数据前，通讯双方必须在彼此间创建一条链接。所谓的“链接”，实际上是客户端和服务器的内存里保存的一份关于对方的信息，如ip地址、端口号等。

TCP能够当作是一种字节流，它会处理IP层或如下的层的丢包、重复以及错误问题。在链接的创建过程当中，双方须要交换一些链接的参数。这些参数能够放在TCP头部。

TCP提供了一种可靠、面向链接、字节流、传输层的服务，采用三次握手创建一个链接。采用4次挥手来关闭一个链接。

TCP服务模型

在了解了创建链接、关闭链接的“三次握手和四次挥手”后，咱们再来看下TCP相关的东西。

一个TCP链接由一个4元组构成，分别是两个IP地址和两个端口号。一个TCP链接一般分为三个阶段：启动、数据传输、退出（关闭）。

当TCP接收到另外一端的数据时，它会发送一个确认，但这个确认不会当即发送，通常会延迟一下子。ACK是累积的，一个确认字节号N的ACK表示全部直到N的字节（不包括N）已经成功被接收了。这样的好处是若是一个ACK丢失，极可能后续的ACK就足以确认前面的报文段了。

一个完整的TCP链接是双向和对称的，数据能够在两个方向上平等地流动。给上层应用程序提供一种双工服务。一旦创建了一个链接，这个链接的一个方向上的每一个TCP报文段都包含了相反方向上的报文段的一个ACK。

序列号的做用是使得一个TCP接收端可丢弃重复的报文段，记录以杂乱次序到达的报文段。由于TCP使用IP来传输报文段，而IP不提供重复消除或者保证次序正确的功能。另外一方面，TCP是一个字节流协议，毫不会以杂乱的次序给上层程序发送数据。所以TCP接收端会被迫先保持大序列号的数据不交给应用程序，直到缺失的小序列号的报文段被填满。

TCP头部

tcp header

源端口和目的端口在TCP层肯定双方进程，序列号表示的是报文段数据中的第一个字节号，ACK表示确认号，该确认号的发送方期待接收的下一个序列号，即最后被成功接收的数据字节序列号加1，这个字段只有在ACK位被启用的时候才有效。

当新建一个链接时，从客户端发送到服务端的第一个报文段的SYN位被启用，这称为SYN报文段，这时序列号字段包含了在本次链接的这个方向上要使用的第一个序列号，即初始序列号ISN，以后发送的数据是ISN加1，所以SYN位字段会消耗一个序列号，这意味着使用重传进行可靠传输。而不消耗序列号的ACK则不是。

头部长度（图中的数据偏移）以32位字为单位，也就是以4bytes为单位，它只有4位，最大为15，所以头部最大长度为60字节，而其最小为5，也就是头部最小为20字节（可变选项为空）。

ACK —— 确认，使得确认号有效。
RST —— 重置链接（常常看到的reset by peer）就是此字段搞的鬼。
SYN —— 用于初如化一个链接的序列号。
FIN —— 该报文段的发送方已经结束向对方发送数据。

当一个链接被创建或被终止时，交换的报文段只包含TCP头部，而没有数据。

状态转换

三次握手和四次挥手的状态转换以下图。
tcp connect

为何要“三次握手，四次挥手”

三次握手

换个易于理解的视角来看为何要3次握手。

客户端和服务端通讯前要进行链接，“3次握手”的做用就是双方都能明确本身和对方的收、发能力是正常的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。
从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，而且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。而另外一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我本身的发送和接收能力也是正常的。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。
第1、二次握手后，服务端并不知道客户端的接收能力以及本身的发送能力是否正常。而在第三次握手时，服务端收到了客户端对第二次握手做的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。因此，个人发送能力是正常的。而客户端的接收能力也是正常的。

经历了上面的三次握手过程，客户端和服务端都确认了本身的接收、发送能力是正常的。以后就能够正常通讯了。

每次都是接收到数据包的一方能够获得一些结论，发送的一方其实没有任何头绪。我虽然有发包的动做，可是我怎么知道我有没有发出去，而对方有没有接收到呢？

而从上面的过程能够看到，最少是须要三次握手过程的。两次达不到让双方都得出本身、对方的接收、发送能力都正常的结论。其实每次收到网络包的一方至少是能够获得：对方的发送、我方的接收是正常的。而每一步都是有关联的，下一次的“响应”是因为第一次的“请求”触发，所以每次握手实际上是能够获得额外的结论的。好比第三次握手时，服务端收到数据包，代表看服务端只能获得客户端的发送能力、服务端的接收能力是正常的，可是结合第二次，说明服务端在第二次发送的响应包，客户端接收到了，而且做出了响应，从而获得额外的结论：客户端的接收、服务端的发送是正常的。

用表格总结一下：

视角 客收 客发 服收 服发
客视角 二 一 + 二 一 + 二 二
服视角 二 + 三 一 一 二 + 三
四次挥手

TCP链接是双向传输的对等的模式，就是说双方均可以同时向对方发送或接收数据。当有一方要关闭链接时，会发送指令告知对方，我要关闭链接了。这时对方会回一个ACK，此时一个方向的链接关闭。可是另外一个方向仍然能够继续传输数据，等到发送完了全部的数据后，会发送一个FIN段来关闭此方向上的链接。接收方发送ACK确认关闭链接。注意，接收到FIN报文的一方只能回复一个ACK, 它是没法立刻返回对方一个FIN报文段的，由于结束数据传输的“指令”是上层应用层给出的，我只是一个“搬运工”，我没法了解“上层的意志”。

“三次握手，四次挥手”怎么完成？

其实3次握手的目的并不仅是让通讯双方都了解到一个链接正在创建，还在于利用数据包的选项来传输特殊的信息，交换初始序列号ISN。

3次握手是指发送了3个报文段，4次挥手是指发送了4个报文段。注意，SYN和FIN段都是会利用重传进行可靠传输的。

三次握手