目录
- 建立连接（三次握手）
- 为啥要进行握手？？意义何在？？
- 常见面试题：为啥必须是三次握手？
- 断开连接（四次挥手）
- 三次握手和四次挥手的相同点和不同点
- 连接过程中涉及到的TCP状态转换
上一篇【TCP的“可靠性”（上）-CSDN博客】我们用金角大王和银角大王的例子讲到了TCP的可靠性依靠了：确认应答、超时重传这两个机制。
TCP的可靠性还离不开三次握手四次挥手机制
连接管理（重点）
建立连接（三次握手）
建立连接： 客户端执行 ：socket=new Socket(serberIp,serverPort)这个操作就是在建立连接
上述只是调用 socket API ，真正连接建立的过程，是在操作系统内核完成的
此处的连接是“虚拟的，抽象的”连接，目的是让通信双方都能保存对方的相关信息
第一次交互，一定是客户端主动发起的
所谓的syn是一个特殊的TCP数据报
1.没有载荷，是一个特殊的TCP数据报
2六个标志位中的第五位，为1
虽然syn不带有应用层载荷，但是也是会带有IP报头/以太网数据帧帧头…更会有TCP报头
TCP报头中就包含了客户端自己的端口
IP报头中就包含了客户端自己的IP（这个过程，也是客户端在告诉服务器 我是谁）
上述流程，是有四次交互，但是实际过程中，其中的两次交互，能够合二为一！最终就形成了 “三次握手”。
所谓的建立连接过程，本质上就是通信双方各自给对方发起一个 syn，各自给对方回应一个 ack。
(这里 客户端 的信息告知服务器
这个操作实际上在第一次握手的时候就完成了，但是最终确立出这个连接要建立，确立出后续要进行通信，还是得所有的流程都走完)
虽然第一次握手，客户端已经把自己的信息告诉服务器了，但是服务器具体是否要确定存储这个信息还得再观望。
两种可能性：
- 服务器同意了，服务器表示我也愿意和你建立连接
- 服务器没同意。(一般来说这种情况比较少见，就是出现服务器负载极高的情况下，服务器完全无法响应，客户端太多了) 没有下文了。
服务器收到 syn 之后，会返回 ack（确认应答）
语义就是：收到！！
接下来服务器还会再返回 syn，这个 syn 意思就是
我接收你的连接（我也愿意和你建立连接）
等到所有的握手环节完成，服务器才会最终保存客户端的相关信息。
上述的过程中，画了四次交互，实际上中间两次可以合并。
syn 就是第五位为 1
ack 就是第二位为 1
完全可以有一个数据包，第五位和第二位都是 1，此时这个数据包就同时起到了两个作用，既能够应答上个请求，也能发起 syn。
网络传输过程中要涉及到多次的封装和分用。 两个包就封装分用两次。合并成一个包，就可以减少一次封装分用的过程。
整体的效率就提升了，成本就降低了。
详细版本的三次握手：
为啥要进行握手？？意义何在？？
- 三次握手，可以先针对通信路径，进行投石问路，初步的确认一下通信链路是否畅通。(可靠性的前提条件)
- 三次握手，也是在验证通信双方，发送能力和接收能力是否正常。[关注点在两端]
- 三次握手的过程中也会协商一些必要的参数。
通信是客户端服务器两方的事情，要配合，其中的有些内容要保持一致
最少 0 字节
最多 40 字节（TCP 报头总长度最多 60，去掉前面固定的 20，还剩 40）
其中有一个信息是挺关键的，TCP 通信的序号，起始值。 TCP 一次通信过程中，序号不是从 0 或者从 1 开始计算的。
而是先选择一个比较大的数字，以这个数字开头来继续计算～～
即使是同一个客户端和服务器，每次连接，开始的序号都不同。设计 TCP 的大佬是这样考虑：避免出现一个情况——【前朝的剑，斩本朝的官】
【前朝的剑，斩本朝的官】：
第一次连接的过程中，传输的有一个数据包，在路上堵车了，迟迟没有到达对端。
等到终于到了对端的时候，已经改朝换代了，之前的连接早都没了，现在是新的连接了！！
此时，这份数据，就应该被丢弃！！
数据报时按照 ip + 端口进行识别的。 第一个连接，是用客户端 A 来连的，第二个连接用客户端 B
来连的。(恰好是同一个端口的话，客户端概率是比较低，服务器概率很大)此时数据到达这一边，早已物是人非，这个时候的话，再来进行处理这个数据就不合适了。 此时，丢弃这个数据包是一个上策。
如何识别出，当前的数据是 “前朝” 的数据包呢？？ 就可以通过序号来区分！！
前朝的包，序号就会和本朝的包序号差异非常大，很容易一眼识别出来。
常见面试题：为啥必须是三次握手？
分四次握手，是否可以？ 行，但是没必要。
分两次握手，是否可以？ 肯定不行！！
服务器这边是无法确认自己的发送能力对端的接收能力是否正确的！！
服务器不知道这个结论，此时就缺少了 “可靠传输” 前提。
因此必须得客户端再来一次握手，把上述信息同步给服务器。
断开连接（四次挥手）
四次挥手是正常情况下，但是断开连接不一定非得是【四次挥手】
四次挥手，不一定非得是客户端先发 fin，服务器也可能先发 fin。 和三次握手不一样，三次握手，一定是客户端主动。
四次挥手能否像三次握手一样，把中间两次互动合二为一呢？
看情况
有的时候能合并，有的时候不能合并（不像三次握手，100%会合并）
如果实际通信过程中，ack 和第二个 fin 时间间隔比较长，此时就无法进行合并了，就分成两次来传输。
如果当前时间间隔很小，是有可能会合并的。 TCP 还有机制，延时应答和捎带应答。(后面我会再发一篇【TCP提高传输效率的机制】里面会讲)
三次握手和四次挥手的相同点和不同点
相似之处：
都是通信双方各自给对方发起一个 syn/fin，各自给对方返回 ack
数据传输的顺序，syn/ack/syn/ack， fin/ack/fin/ack
不同之处：
三次握手中间两次一定能合并，四次挥手则不一定。
三次握手，必须是客户端主动，四次挥手，客户端 / 服务器都可以主动。
连接过程中涉及到的TCP状态转换
在我的上一篇有讲：TCP连接过程中涉及到的状态转换-CSDN博客
客官请留步
我的其他TCP相关文章：初识TCP（编写回显服务器）