Ref: https://github.com/jawil/blog/issues/14

通俗理解三次握手
TCP 三次握手 - 图3

但是为什么一定要进行三次握手来保证连接是双工的呢，一次不行么？两次不行么？我们举一个现实生活中两个人进行语言沟通的例子来模拟三次握手。
引用网上的一些通俗易懂的例子，虽然不太正确，后面会指出，但是不妨碍我们理解，大体就是这么个理解法。

第一次对话：

老婆让甲出去打酱油，半路碰到一个朋友乙，甲问了一句：哥们你吃饭了么？
结果乙带着耳机听歌呢，根本没听到，没反应。甲心里想：跟你说话也没个音，不跟你说了，沟通失败。说明乙接受不到甲传过来的信息的情况下沟通肯定是失败的。
如果乙听到了甲说的话，那么第一次对话成功，接下来进行第二次对话。

第二次对话：

乙听到了甲说的话，但是他是老外，中文不好，不知道甲说的啥意思也不知道怎样回答，于是随便回答了一句学过的中文 ：我去厕所了。甲一听立刻笑喷了，“去厕所吃饭”? 道不同不相为谋，离你远点吧，沟通失败。说明乙无法做出正确应答的情况下沟通失败。
如果乙听到了甲的话，做出了正确的应答，并且还进行了反问：我吃饭了，你呢？那么第二次握手成功。
通过前两次对话证明了乙能够听懂甲说的话，并且能做出正确的应答。 接下来进行第三次对话。

第三次对话：

甲刚和乙打了个招呼，突然老婆喊他，“你个死鬼，打个酱油咋这么半天，看我回家咋收拾你”，甲是个妻管严，听完吓得二话不说就跑回家了，把乙自己晾那了。乙心想：这什么人啊，得，我也回家吧，沟通失败。说明甲无法做出应答的情况下沟通失败。
如果甲也做出了正确的应答：我也吃了。那么第三次对话成功，两人已经建立起了顺畅的沟通渠道，接下来开始持续的聊天。

通过第二次和第三次的对话证明了甲能够听懂乙说的话，并且能做出正确的应答。
可见，两个人进行有效的语言沟通，这三次对话的过程是必须的。

为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次 (第一次和第二次) 握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次 (第二次和第三次) 握手。
这个例子举得挺好的。不过个人感觉为什么是三次而不是二次，不是因为为了证明甲能听懂乙并回应（第二次乙能正确的响应甲说明俩人之间沟通已无障碍了），而是怕出现以下情况而浪费感情。这个情景是这样的（例子有点不实际意会就好）：甲在路上跟乙打招呼，由于刮风什么的这句活被吹跑了，然后甲又跟打了个招呼，乙听到了并作出了回应。此时不管是三次握手还是两次握手两个人都能愉快的沟通。0.1 秒后俩人四次挥手告别了。此时被风刮跑的那句话又传到了乙的耳朵里，乙认为甲又要跟他沟通，所以做出了响应的回应。（问题出现了）假如采用 2 次握手，乙就认定了甲要跟他沟通，于是就不停的等，浪费感情。可如果是采用 3 次握手，乙等了一会后发现甲没有回应他就认为甲走了然后自己也就走了！
这就很明白了，其实第三步是防止了乙的一直等待而浪费自己的时间，而不是为了保证甲能够正确回应乙的信息。。。后面的也会讲到。

引用知乎上的别人引用的一个回答，从另外一个角度阐释：
在 Google Groups 的 TopLanguage 中看到一帖讨论 TCP “三次握手” 觉得很有意思。贴主提出 “TCP 建立连接为什么是三次握手？” 的问题，在众多回复中，有一条回复写道：“这个问题的本质是，信道不可靠，但是通信双发需要就某个问题达成一致。而要解决这个问题，无论你在消息中包含什么信息，三次通信是理论上的最小值。所以三次握手不是 TCP 本身的要求，而是为了满足 “在不可靠信道上可靠地传输信息” 这一需求所导致的。请注意这里的本质需求，信道不可靠，数据传输要可靠。三次达到了，那后面你想接着握手也好，发数据也好，跟进行可靠信息传输的需求就没关系了。因此，如果信道是可靠的，即无论什么时候发出消息，对方一定能收到，或者你不关心是否要保证对方收到你的消息，那就能像 UDP 那样直接发送消息就可以了.”。这可视为对 “三次握手” 目的的另一种解答思路。
上面的纯属大白话娱乐讲解，可能还有偏差，例子可能有点不得体。在我们真正了解 TCP 的三次握手和四次分手之前，必须了解一些基本的概念，最后和这大白话例子对比结合一下理解，说不定就会顿时融会贯通。

HTTP 连接

HTTP 协议即超文本传送协议 (Hypertext Transfer Protocol)，是 Web 联网的基础，也是手机联网常用的协议之一，HTTP 协议是建立在 TCP 协议之上的一种应用。
HTTP 连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为 “一次连接”。
1）在 HTTP 1.0 中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
2）在 HTTP 1.1 中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。
由于 HTTP 在每次请求结束后都会主动释放连接，因此 HTTP 连接是一种 “短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常 的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次 “保持连接” 的请求，服务器在收到该请求后对客户端进行回复，表明知道 客户端 “在线”。若服务器长时间无法收到客户端的请求，则认为客户端 “下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

SOCKET 原理

套接字（socket）概念

套接字（socket）是通信的基石，是支持 TCP/IP 协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的 IP 地址，本地进程的协议端口，远地主机的 IP 地址，远地进程的协议端口。
应用层通过传输层进行数据通信时，TCP 会遇到同时为多个应用程序进程提供并发服务的问题。多个 TCP 连接或多个应用程序进程可能需要通过同一个 TCP 协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与 TCP／IP 协议交互提供了套接字 (Socket) 接口。应 用层可以和传输层通过 Socket 接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。

建立 socket 连接

建立 Socket 连接至少需要一对套接字，其中一个运行于客户端，称为 ClientSocket ，另一个运行于服务器端，称为 ServerSocket 。
套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。
服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发 给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

SOCKET 连接与 TCP 连接

创建 Socket 连接时，可以指定使用的传输层协议，Socket 可以支持不同的传输层协议（TCP 或 UDP），当使用 TCP 协议进行连接时，该 Socket 连接就是一个 TCP 连接。

Socket 连接与 HTTP 连接

由于通常情况下 Socket 连接就是 TCP 连接，因此 Socket 连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网 络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。
而 HTTP 连接使用的是 “请求 — 响应” 的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。
很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是 Socket 连接，服务器就可以直接将数 据传送给客户端；若双方建立的是 HTTP 连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求， 不仅可以保持在线，同时也是在 “询问” 服务器是否有新的数据，如果有就将数据传给客户端。TCP (Transmission Control Protocol) 传输控制协议
TCP 是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:
位码即 tcp 标志位，有 6 种标示：SYN (synchronous 建立联机) ACK (acknowledgement 确认) PSH (push 传送) FIN (finish 结束) RST (reset 重置) URG (urgent 紧急)
Sequence number (顺序号码) Acknowledge number (确认号码)

TCP 是什么？

TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
具体的关于 TCP 是什么，我不打算详细的说了；当你看到这篇文章时，我想你也知道 TCP 的概念了，想要更深入的了解 TCP 的工作，我们就继续。它只是一个超级麻烦的协议，而它又是互联网的基础，也是每个程序员必备的基本功。首先来看看 OSI 的七层模型：
TCP 三次握手 - 图4
我们需要知道 TCP 工作在网络 OSI 的七层模型中的第四层 ——Transport 层，IP 在第三层 ——Network 层，ARP 在第二层 ——Data Link 层；在第二层上的数据，我们把它叫 Frame，在第三层上的数据叫 Packet，第四层的数据叫 Segment。 同时，我们需要简单的知道，数据从应用层发下来，会在每一层都会加上头部信息，进行封装，然后再发送到数据接收端。这个基本的流程你需要知道，就是每个数据都会经过数据的封装和解封装的过程。 在 OSI 七层模型中，每一层的作用和对应的协议如下：
TCP 三次握手 - 图5
TCP 是一个协议，那这个协议是如何定义的，它的数据格式是什么样子的呢？要进行更深层次的剖析，就需要了解，甚至是熟记 TCP 协议中每个字段的含义。哦，来吧。

TCP 头部

其中 ACK SYN 序号 这三个部分在以下会用到，它们的介绍也在下面。
TCP 三次握手 - 图6
上面就是 TCP 协议头部的格式，由于它太重要了，是理解其它内容的基础，下面就将每个字段的信息都详细的说明一下。

  • Source Port 和 Destination Port: 分别占用 16 位，表示源端口号和目的端口号；用于区别主机中的不同进程，而 IP 地址是用来区分不同的主机的，源端口号和目的端口号配合上 IP 首部中的源 IP 地址和目的 IP 地址就能唯一的确定一个 TCP 连接；
  • Sequence Number: 用来标识从 TCP 发端向 TCP 收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节在数据流中的序号；主要用来解决网络报乱序的问题；
  • Acknowledgment Number:32 位确认序列号包含发送确认的一端所期望收到的下一个序号，因此，确认序号应当是上次已成功收到数据字节序号加 1。不过，只有当标志位中的 ACK 标志（下面介绍）为 1 时该确认序列号的字段才有效。主要用来解决不丢包的问题；
  • Offset: 给出首部中 32 bit 字的数目，需要这个值是因为任选字段的长度是可变的。这个字段占 4bit（最多能表示 15 个 32bit 的的字，即 4*15=60 个字节的首部长度），因此 TCP 最多有 60 字节的首部。然而，没有任选字段，正常的长度是 20 字节；
  • TCP Flags:TCP 首部中有 6 个标志比特，它们中的多个可同时被设置为 1，主要是用于操控 TCP 的状态机的，依次为 URG，ACK，PSH，RST，SYN，FIN。每个标志位的意思如下：

URG：此标志表示 TCP 包的紧急指针域（后面马上就要说到）有效，用来保证 TCP 连接不被中断，并且督促中间层设备要尽快处理这些数据；
ACK：此标志表示应答域有效，就是说前面所说的 TCP 应答号将会包含在 TCP 数据包中；有两个取值：0 和 1，为 1 的时候表示应答域有效，反之为 0；
PSH：这个标志位表示 Push 操作。所谓 Push 操作就是指在数据包到达接收端以后，立即传送给应用程序，而不是在缓冲区中排队；
RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包；
SYN：表示同步序号，用来建立连接。SYN 标志位和 ACK 标志位搭配使用，当连接请求的时候，SYN=1，ACK=0；连接被响应的时候，SYN=1，ACK=1；这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有 SYN 的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口；但是由于这种扫描方式只是进行 TCP 三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全的主机将会强制要求一个连接严格的进行 TCP 的三次握手；
FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送 FIN 标志位的 TCP 数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。

  • Window: 窗口大小，也就是有名的滑动窗口，用来进行流量控制；这是一个复杂的问题，这篇博文中并不会进行总结的；

暂时需要的信息有：
ACK ： TCP 协议规定，只有 ACK=1 时有效，也规定连接建立后所有发送的报文的 ACK 必须为 1
SYN (SYNchronization) ： 在连接建立时用来同步序号。当 SYN=1 而 ACK=0 时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使 SYN=1 和 ACK=1. 因此，SYN 置 1 就表示这是一个连接请求或连接接受报文。
FIN （finis）即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。
TCP 三次握手 - 图7

三次握手的过程：

TCP 三次握手 - 图8
多么清晰的一张图，当然了，也不是我画的，我也只是引用过来说明问题了。

  1. 第一次握手：建立连接。客户端发送连接请求报文段，将 SYN 位置为 1，Sequence Number 为 x；然后，客户端进入 SYN_SEND 状态，等待服务器的确认；
  2. 第二次握手：服务器收到 SYN 报文段。服务器收到客户端的 SYN 报文段，需要对这个 SYN 报文段进行确认，设置 Acknowledgment Number 为 x+1 (Sequence Number+1)；同时，自己自己还要发送 SYN 请求信息，将 SYN 位置为 1，Sequence Number 为 y；服务器端将上述所有信息放到一个报文段（即 SYN+ACK 报文段）中，一并发送给客户端，此时服务器进入 SYN_RECV 状态；

  3. 第三次握手：客户端收到服务器的 SYN+ACK 报文段。然后将 Acknowledgment Number 设置为 y+1，向服务器发送 ACK 报文段，这个报文段发送完毕以后，客户端和服务器端都进入 ESTABLISHED 状态，完成 TCP 三次握手。
    完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是 TCP 三次握手的总体介绍。

    那四次分手呢？

    当客户端和服务器通过三次握手建立了 TCP 连接以后，当数据传送完毕，肯定是要断开 TCP 连接的啊。那对于 TCP 的断开连接，这里就有了神秘的 “四次分手”。

  4. 第一次分手：主机 1（可以使客户端，也可以是服务器端），设置 Sequence Number 和 Acknowledgment Number，向主机 2 发送一个 FIN 报文段；此时，主机 1 进入 FIN_WAIT_1 状态；这表示主机 1 没有数据要发送给主机 2 了；

  5. 第二次分手：主机 2 收到了主机 1 发送的 FIN 报文段，向主机 1 回一个 ACK 报文段，Acknowledgment Number 为 Sequence Number 加 1；主机 1 进入 FIN_WAIT_2 状态；主机 2 告诉主机 1，我 “同意” 你的关闭请求；
  6. 第三次分手：主机 2 向主机 1 发送 FIN 报文段，请求关闭连接，同时主机 2 进入 LAST_ACK 状态；
  7. 第四次分手：主机 1 收到主机 2 发送的 FIN 报文段，向主机 2 发送 ACK 报文段，然后主机 1 进入 TIME_WAIT 状态；主机 2 收到主机 1 的 ACK 报文段以后，就关闭连接；此时，主机 1 等待 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭，那好，主机 1 也可以关闭连接了。

至此，TCP 的四次分手就这么愉快的完成了。当你看到这里，你的脑子里会有很多的疑问，很多的不懂，感觉很凌乱；没事，我们继续总结。

为什么要三次握手

在谢希仁著《计算机网络》第四版中讲 “三次握手” 的目的是 “为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲 “三次握手” 的目的是为了解决 “网络中存在延迟的重复分组” 的问题。
在谢希仁著《计算机网络》书中同时举了一个例子，如下：
“已失效的连接请求报文段” 的产生在这样一种情况下：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”
TCP 三次握手 - 图9
这就很明白了，防止了服务器端的一直等待而浪费资源。

为什么要四次分手

那四次分手又是为何呢？TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着，当主机 1 发出 FIN 报文段时，只是表示主机 1 已经没有数据要发送了，主机 1 告诉主机 2，它的数据已经全部发送完毕了；但是，这个时候主机 1 还是可以接受来自主机 2 的数据；当主机 2 返回 ACK 报文段时，表示它已经知道主机 1 没有数据发送了，但是主机 2 还是可以发送数据到主机 1 的；当主机 2 也发送了 FIN 报文段时，这个时候就表示主机 2 也没有数据要发送了，就会告诉主机 1，我也没有数据要发送了，之后彼此就会愉快的中断这次 TCP 连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

  • FIN_WAIT_1: 这个状态要好好解释一下，其实 FIN_WAIT_1 和 FIN_WAIT_2 状态的真正含义都是表示等待对方的 FIN 报文。而这两种状态的区别是：FIN_WAIT_1 状态实际上是当 SOCKET 在 ESTABLISHED 状态时，它想主动关闭连接，向对方发送了 FIN 报文，此时该 SOCKET 即进入到 FIN_WAIT_1 状态。而当对方回应 ACK 报文后，则进入到 FIN_WAIT_2 状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应 ACK 报文，所以 FIN_WAIT_1 状态一般是比较难见到的，而 FIN_WAIT_2 状态还有时常常可以用 netstat 看到。（主动方）
  • FIN_WAIT_2：上面已经详细解释了这种状态，实际上 FIN_WAIT_2 状态下的 SOCKET，表示半连接，也即有一方要求 close 连接，但另外还告诉对方，我暂时还有点数据需要传送给你 (ACK 信息)，稍后再关闭连接。（主动方）
  • CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方 close 一个 SOCKET 后发送 FIN 报文给自己，你系统毫无疑问地会回应一个 ACK 报文给对方，此时则进入到 CLOSE_WAIT 状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close 这个 SOCKET，发送 FIN 报文给对方，也即关闭连接。所以你在 CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。（被动方）
  • LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送 FIN 报文后，最后等待对方的 ACK 报文。当收到 ACK 报文后，也即可以进入到 CLOSED 可用状态了。（被动方）
  • TIME_WAIT: 表示收到了对方的 FIN 报文，并发送出了 ACK 报文，就等 2MSL 后即可回到 CLOSED 可用状态了。如果 FINWAIT1 状态下，收到了对方同时带 FIN 标志和 ACK 标志的报文时，可以直接进入到 TIME_WAIT 状态，而无须经过 FIN_WAIT_2 状态。（主动方）
  • CLOSED: 表示连接中断。

    实例:

    TCP 的作用是流量控制，主要是控制数据流的传输。下面以浏览网页为例，根据自身理解来解释一下这个过程。（注：第二个 ack 属于代码段 ack 位）
    握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。
    TCP 三次握手 - 图10
    第一次握手：客户端发送 syn 包 (syn=j) 到服务器，并进入 SYN_SEND 状态，等待服务器确认；
    第二次握手：服务器收到 syn 包，必须确认客户的 SYN（ack=j+1），同时自己也发送一个 SYN 包（syn=k），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；
    第三次握手：客户端收到服务器的 SYN＋ACK 包，向服务器发送确认包 ACK (ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。
    握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP 连接一旦建立，在通信双方中的任何一方主 动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开 TCP 连接的请求，断开过程需要经过 “四次握手”（过程就不细写了，就是服务器和客 户端交互，最终确定断开）

    对应的实例

    IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
    IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
    IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1
    第一次握手：192.168.1.116 发送位码 syn＝1, 随机产生 seq number=3626544836 的数据包到 192.168.1.123,192.168.1.123 由 SYN=1 知道 192.168.1.116 要求建立联机；
    第二次握手：192.168.1.123 收到请求后要确认联机信息，向 192.168.1.116 发送 ack number=3626544837,syn=1,ack=1, 随机产生 seq=1739326486 的包；
    第三次握手：192.168.1.116 收到后检查 ack number 是否正确，即第一次发送的 seq number+1, 以及位码 ack 是否为 1，若正确，192.168.1.116 会再发送 ack number=1739326487,ack=1，192.168.1.123 收到后确认 seq=seq+1,ack=1 则连接建立成功。

    我想你应该懂了

    总结到这里，也该结束了，但是对于 TCP 的学习远还没有结束。TCP 是一个非常复杂的协议，这里稍微总结了一下 TCP 的连接与断开连接是发生的事情，其中还有很多的 “坑”，让我们后续有时间再继续填吧。好了，完毕！