通俗大白话来理解TCP协议的三次握手和四次分手

最近在恶补计算机网络方面的知识，以前对于TCP的三次握手和四次分手也是模模糊糊，对于其中的细节更是浑然不知，最近看了不少这方面的知识，也在系统的学习计算机网络，加深本身的CS功底，就把看过的一些比较好的东西和本身的一些理解二次加工组织一下而后交流分享，一块儿学习进步，对了这个面试好像常常问到。

原文收录在个人 GitHub博客 (https://github.com/jawil/blog) ，喜欢的能够关注最新动态，你们一块儿多交流学习，共同进步，以学习者的身份写博客，记录点滴。

通俗理解:

可是为何必定要进行三次握手来保证链接是双工的呢，一次不行么？两次不行么？咱们举一个现实生活中两我的进行语言沟通的例子来模拟三次握手。

引用网上的一些通俗易懂的例子，虽然不太正确，后面会指出，可是不妨碍咱们理解，大致就是这么个理解法。

第一次对话：

老婆让甲出去打酱油，半路碰到一个朋友乙，甲问了一句：哥们你吃饭了么？

结果乙带着耳机听歌呢，根本没听到，没反应。甲内心想：跟你说话也没个音，不跟你说了，沟通失败。说明乙接受不到甲传过来的信息的状况下沟通确定是失败的。

若是乙听到了甲说的话，那么第一次对话成功，接下来进行第二次对话。

第二次对话：

乙听到了甲说的话，可是他是老外，中文很差，不知道甲说的啥意思也不知道怎样回答，因而随便回答了一句学过的中文 ：我去厕所了。甲一听马上笑喷了，“去厕所吃饭”?道不一样不相为谋，离你远点吧，沟通失败。说明乙没法作出正确应答的状况下沟通失败。

若是乙听到了甲的话，作出了正确的应答，而且还进行了反问：我吃饭了，你呢？那么第二次握手成功。

经过前两次对话证实了乙可以听懂甲说的话，而且能作出正确的应答。 接下来进行第三次对话。

第三次对话：

甲刚和乙打了个招呼，忽然老婆喊他，“你个死鬼，打个酱油咋这么半天，看我回家咋收拾你”，甲是个妻管严，听完吓得二话不说就跑回家了，把乙本身晾那了。乙心想：这什么人啊，得，我也回家吧，沟通失败。说明甲没法作出应答的状况下沟通失败。

若是甲也作出了正确的应答：我也吃了。那么第三次对话成功，两人已经创建起了顺畅的沟通渠道，接下来开始持续的聊天。

经过第二次和第三次的对话证实了甲可以听懂乙说的话，而且能作出正确的应答。

可见，两我的进行有效的语言沟通，这三次对话的过程是必须的。

为了保证服务端能收接受到客户端的信息并能作出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端可以接收到服务端的信息并能作出正确的应答而进行后两次(第二次和第三次)握手。

这个例子举得挺好的。不过我的感受为何是三次而不是二次，不是由于为了证实甲能听懂乙并回应（第二次乙能正确的响应甲说明俩人之间沟通已无障碍了），而是怕出现如下状况而浪费感情。这个情景是这样的（例子有点不实际意会就好）：甲在路上跟乙打招呼，因为刮风什么的这句活被吹跑了，而后甲又跟打了个招呼，乙听到了并做出了回应。此时无论是三次握手仍是两次握手两我的都能愉快的沟通。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工做在网络OSI的七层模型中的第四层——Transport层，IP在第三层——Network层，ARP在第二层——Data Link层；在第二层上的数据，咱们把它叫Frame，在第三层上的数据叫Packet，第四层的数据叫Segment。 同时，咱们须要简单的知道，数据从应用层发下来，会在每一层都会加上头部信息，进行封装，而后再发送到数据接收端。这个基本的流程你须要知道，就是每一个数据都会通过数据的封装和解封装的过程。 在OSI七层模型中，每一层的做用和对应的协议以下：

TCP是一个协议，那这个协议是如何定义的，它的数据格式是什么样子的呢？要进行更深层次的剖析，就须要了解，甚至是熟记TCP协议中每一个字段的含义。哦，来吧。



TCP头部

其中 ACK SYN 序号 这三个部分在如下会用到，它们的介绍也在下面。

上面就是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 时，代表此报文段的发送方的数据已经发送完毕，并要求释放链接。

三次握手的过程：

多么清晰的一张图，固然了，也不是我画的，我也只是引用过来讲明问题了。

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的断开链接，这里就有了神秘的“四次分手”。

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

2. 第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“赞成”你的关闭请求；

3. 第三次分手：主机2向主机1发送FIN报文段，请求关闭链接，同时主机2进入LAST_ACK状态；

4. 第四次分手：主机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协议是一种面向链接的、可靠的、基于字节流的运输层通讯协议。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位）

握手过程当中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。

第一次握手：客户端发送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的链接与断开链接是发生的事情，其中还有不少的“坑”，让咱们后续有时间再继续填吧。好了，完毕！



搬运文章

TCP三次握手详解及释放链接过程
首先简单介绍一下TCP三次握手
TCP 为何是三次握手，为何不是两次或四次？

最后推荐一个学习HTTP的github项目地址：我本身提炼的关于《HTTP权威指南》每章的知识点总结！