mysql通信协连接阶段主要内容包括：
交换客户端和服务端的信息
如果客户端设置了SSL，设置SSL通信通道
服务端根据客户端返回的数据进行用户验证
客户端开始连接服务端时，服务端可以发送ERR_Packet完成握手或发送客户端初始握手需要的数据包，在该阶段客户端还可以请求SSL连接，在身份验证之前建立SSL通信通道。
在初次握手时服务端会发送用于验证的方法，客户端根据收到的信息进行数据包组装返回，整个连接过程直到服务端返回ERR_Packet或OK_Packet结束，整个过程见下图(摘自官网)：
初次握手：
初次握手从服务器发送Protocol::Handshake数据包开始，在此之后，客户端可以请求使用Protocol::SSLRequest包建立SSL连接，或者客户端直接发送Protocol::HandshakeResponse包，下面分别介绍两种连接方式的情况
ssl 连接：
服务端发送Protocol::Handshake数据包
客户端回复Protocol::SSLRequest包
服务端设置ssl通道
客户端发送Protocol::HandshakeResponse数据包
普通连接：
服务端发送Protocol::Handshake数据包
客户端发送Protocol::HandshakeResponse数据包
握手时当然不可能都是一帆风顺的，在这途中会有各种情况发生，比如身份验证失败、密码验证方法不符合、客服端未按要求返回验证方法等，这里只介绍密码验证方法错误的情况，想详细了解见官网文档：
客户端连接到服务端
服务端发送Protocol::Handshake
客户端返回Protocol::HandshakeResponse
服务端发送Protocol::AuthSwitchRequest 告诉客户端它需要切换到新的身份验证方法。
客户端和服务端可能根据客户端进行身份验证的方法，要求交换更多数据包。
服务端发送OK_Packet或ERR_Packet数据包
可以看出该情况比一步完成连接的情况多了Protocol::AuthSwitchRequest和客户端重新回复包的两步，当然在这其中也可能继续发生该异常或其他异常，需要继续交换数据包，下面来看下Protocol::Handshake和Protocol::HandshakeResponse两个数据包的组装情况，mysql通信协议中的所有包会有4bytes的head，前3bytes记录包的大小，第4位置的1byts记录数据包的顺序id，客户端和服务端的一次协议交互直到结束，这途中所有数据包的id都是顺序增长，所以下面介绍的结构都不包含这4bytes需要先明白：
Protocol::Handshake
图中我们可以很清楚的看到包中包含有协议版本、mysql版本、当前连接的id、默认的字符集还有一些需要交换的信息，而密码验证方法的内容分成了两个部分，这可能是出于安全考虑吧.....
Protocol::HandshakeResponse
Response包有Protocol::HandshakeResponse320和Protocol::HandshakeResponse41，因为Protocol::HandshakeResponse320是4.1以下版本的协议包，所以只关注了Protocol::HandshakeResponse41包的内容，毕竟现在mysql使用的主流都是5.7了，更多详细内容还是看官方文档吧，毕竟篇幅有限，这里主要说下密码的加密方式，8.0默认密码验证方式为caching_sha2_password，还没来得及认真研究，这里讲讲我们普遍使用的加密方式：mysql_navicat_password：
上面看到Protocol::Handshake有发送两部分的auth-plugin-data，这两部分数据起到加密用户密码的作用，加密方式如下：
SHA1( password ) XOR SHA1( "20-bytes random data from server" <concat> SHA1( SHA1( password ) ) )
假如服务端未发送auth-plugin-data数据将只使用SHA1(password) ,如果有发送该部分数据就将结合这部分数据对密码进行加密，这样可以让嗅探工具不能直接查看到密码，起到一定的安全作用
mysql协议中连接的建立大概内容基本就这些，还是需要自己动手来验证，下面写了一个小脚本，直接看代码吧，只做了常规的步骤，过程中的各种异常并未进行处理，仅供参考(吐槽下简书贴代码的格式真不爽就不贴出来了)，脚本放在我github请自行下载。
网友评论