网络协议和Netty:大白话说三次握手及用一个数据库连接解释三次握手

Posted 2021-08-23 TofuCai

前言：

想起了第一次听说“三次握手”概念的时候。那时候刚到北京，朋友傲娇的跟我讲，我花了两天我终于搞懂了三次握手。当时对网络一无所知的我，还以为是啥新的礼仪方式，心中感叹，帝都人民的热情，握手还要三次。说到半途才搞清楚，原来是TCP创建连接的礼仪。后面空闲的时候，经常从网上找些找些资料，接触“三次握手”。用网友经典的打电话例子，浅浅的理解。时间推移，由浅入深。大概所有人都跟我一开始有同样以下的这个问题：

提问：

为啥TCP建立连接需要进行三次握手？

三次握手

回答问题前，我还是想老生常谈的自己讲解下什么是三次握手。

何为三次握手？

比起语言叙述，有时候图会先的更具体和简单易懂：

 

 

图文讲解

讲解SYN和ACK：

客户端和服务端进行三次握手时除了必要的传输数据，还会有标志位信息。三次握手时，SYN和ACK就是标志位。标志位的作用是，让服务端/客户端根据不同的标志位来确定当前的数据进行对应处理。

比如当服务端发现标志位是SYN=1，就会知道当前的数据是进行第一次握手的请求，然后就会按照第一次握手的规则来处理信息。同样第二次握手时客户端根据SYN=1，ACK=1标志位就会确定是来自服务端的第二次握手的应答请求，然后进行相应的处理。

第一次握手：

由客户端发起，当客户端发起SYN请求后，将客户端状置为SYN_SENT状态，等待服务端确认。此时请求信息中标志位SYN=1，序列Seq=n。

第二次握手：

服务端接收到SYN请求，将Seq在原来值n得基础上加1，赋值Ack=n+1。并且服务端再生成一个序列号m，赋值Aeq=m。服务端应答请求，标志位SYN=1、ACK=1，序列信息Seq=m、Ack=n+1，同时将服务端状态置为SYN_RCVD，等待客户端确认。

第三次握手：

客户端接收到消息，根据标志位SYN=1、ACK=1解析数据，确认Ack=n+1，然后序列赋值Ack=m+1。客户端向服务端发起ACK=1请求。客户端接收到请求，根据标志位ACK=1，校验序列Ack=m+1。校验无误后，将客户端和服务端状态置为ESTABLISHED，建立连接，就可以进行正常的通讯了。

总结：

我们发现所谓三次握手，不过就是客户端和服务端，通过发送三次数据包，来确认连接建立。

我们又知道，TCP的是一个双工连接，即是一个双向连接，就是服务端和客户端都有数据的发送和接收能力。

这就很好的解答了，为何TCP建立连接需要三次握手：

客户端和服务端都必须确认数据是否准确的发送和接收，而在三次握手中序列Seq和Ack的发送和接收，就代表着数据的准确发送和接收。

假如进行两次握手，只有客户端校验了自己生成的序列号，确认了自己的发送和接收能力，很明显是不够的。那为啥不能是四次？我只能说，任何事情三次能解决的事，没必要四次，更何况是作为程序员去解决问题。

用一个数据库连接来验证三次握手：

准备：wireshark（抓包工具），navicat（数据库可视化工具），mysql

说明：mysql的连接是一个TCP连接

1.打开wireshark

2.打开navicat

此时并没有创建连接。

3.wireshark编辑捕获器，监听3306端口（mysql连接端口）

4.点击开始

由于3306端口暂无通信所以为空

5.点击navicat其中一个数据库连接

6.我们发现3306端口有数据包

我们先简单看下前三No1、No2、No3

注意标志位和Seq是不是有些似曾相识，和我们上面上述的三次握手是不是有些相似？

详细看下：

第一个包No1：

下方红色框框SYN=1 ，说明这是第一次握手，上方黄色框为客户端生成的序列号Seq=0。

第二个包No2：

 下方红色框框SYN=1 和ACK=1，说明这是第二次握手，上方黄色框为服务端生成序列号Seq=0和应答序列号Ack=1（即Ack=客户端值为0的Seq+1）。

第三个包No3：

下方红色框框ACK=1，说明这是第三次握手，上方黄色框为客户端应答序列号Ack=1（即Ack=服务端生成的seq+1）。

总计：三次握手双方的序列号都校验无误，故三次握手成功，建立连接，所以有了下方的No4，5，6等等的数据传输