MySQL协议代理 学习日记（2）

2.MySQL数据包

2.1当发送的大小超过16MB

将数据拆分成 大小为（2²⁴-1）字节的数据包       

预先添加每个块的  

客户端和服务器之间的数据以最大 16MByte 大小的数据包交换。

有效载荷

类型	Name	描述
整数<3>	payload_length	有效载荷的长度。数据包中超出构成数据包头的初始 4 个字节的字节数。
整数<1>	sequence_id	序列号
字符串 <var>	payload	[len= payload_length ] 数据包的有效载荷

例子

A COM_QUIT 看起来像这样：

01 00 00 00 01

* 长度：1 * sequence_id：x00 * 有效载荷：0x01

如果有效载荷大于或等于 2 ²⁴ -1 字节，则长度设置为 2 ²⁴ -1 ( ff ff ff) 并且附加的数据包与有效载荷的其余部分一起发送，直到数据包的有效载荷小于 2 ²⁴ -1 字节.

发送 16 777 215 (2 ²⁴ -1) 个字节的有效载荷如下所示：

ff ff ff 00 ...
00 00 00 01  

2.2 序列号

sequence-id 随每个数据包递增，并且可能会环绕。它从 0 开始，并在命令阶段开始新命令时重置为 0 。

 

3.通用响应包

对于客户端发送到服务器的大多数命令，服务器返回以下数据包之一作为响应：

1 OK_Packet

OK 数据包从服务器发送到客户端以表示命令成功完成。从 MySQL 5.7.5 开始，OK 包也用于表示 EOF，不推荐使用 EOF 包。

2 ERR_Packet

该数据包表示发生了错误

3 EOF_Packet

如果 CLIENT_PROTOCOL_41 启用，EOF 数据包包含警告计数和状态标志。

4 状态标志

4.字符集

MySQL 具有非常灵活的字符集支持

5.连接生命周期

MySQL 协议

5.1连接阶段

连接阶段执行以下任务：

• 交换客户端和服务器的能力

• 如果需要，设置 SSL 通信通道

• 针对服务器验证客户端

它从客户端connect()开始到服务器，服务器可能会发送一个ERR 数据包并完成握手或发送 Initial Handshake Packet客户端以 Handshake Response Packet. 在此阶段客户端可以请求 SSL 连接，在这种情况下，在客户端发送其身份验证响应之前建立 SSL 通信通道。在初始握手之后，服务器通知客户端用于身份验证的方法（除非它在握手期间已经建立）并且身份验证交换继续，直到服务器通过发送 接受连接 OK_Packet 或拒绝它 ERR_Packet。

 

 

　　5.1.1初始握手

　　初始握手从服务器发送 Initial Handshake Packet. 在此之后，可选地，客户端可以请求与 建立 SSL 连接 SSL Connection Request Packet，然后客户端发送 Handshake Response Packet.

 

　　5.1.2SSL握手

1. 服务器发送 Initial Handshake Packet

2. 客户回复 SSL Connection Request Packet

3. 导致建立 SSL 连接的常用 SSL 交换

4. 客户端发送 Handshake Response Packet

　　5.1.3 能力协商

为了允许旧客户端连接到新服务器， 初始握手包含MySQL 服务器版本服务器的能力

客户端应该只在 握手响应包中声明它与服务器共有的能力。

他们可以就以下事项达成一致：

• 状态标志的使用

• 使用 SQL 状态作为错误代码

• 认证方法

• SSL 支持

• 压缩 

　　5.1.4 确定认证方法

用于身份验证的方法与用户帐户相关联并存储在表的plugin列中 mysql.user。客户端通知它想要登录的用户帐户 Handshake Response Packet。只有这样服务器才能查找mysql.user表并找到要使用的身份验证方法。

但是，为了节省一些往返，服务器和客户端在初始握手中就已经开始使用对要使用的身份验证方法的乐观猜测的身份验证交换。

服务器使用其默认身份验证方法生成初始身份验证数据有效负载，并将其Initial Handshake Packet与所使用方法的名称一起发送到客户端内部 。客户端可以在Handshake Response Packet其回复中包含 服务器发送的身份验证数据。

在 中包含身份验证回复时 Handshake Response Packet，客户端不必使用与 Initial Handshake Packet. 客户端使用的身份验证方法的名称存储在数据包中。如果客户端或服务器在初始握手中使用的猜测身份验证方法不正确，服务器会通知客户端应使用哪种身份验证方法 Authentication Method Switch Request Packet（请参阅 第 14.2.3 节，“身份验证方法不匹配”）。

在 MySQL 4.0 之前，MySQL 协议仅支持 Old Password Authentication，在 MySQL 4.1Secure Password Authentication中添加了该 方法，在 MySQL 5.5 中可以通过身份验证插件实现任意身份验证方法。

如果客户端或服务器不支持可插拔身份验证（CLIENT_PLUGIN_AUTH 未设置功能标志），则使用的身份验证方法从客户端和服务器功能推断如下：

• 所用的方法是 Old Password Authentication，如果 CLIENT_PROTOCOL_41 或 CLIENT_SECURE_CONNECTION 不设置。

• 使用的方法是 Secure Password Authentication如果 CLIENT_PROTOCOL_41 和 CLIENT_SECURE_CONNECTION 都已设置但未 CLIENT_PLUGIN_AUTH 设置。

认证阶段快速路径

认证成功

认证失败

假设客户端想以用户 U 的身份登录，并且该用户帐户使用身份验证方法 M。如果客户端和服务器都使用方法 M 在初始握手中生成身份验证数据，则使用快速身份验证路径。在这种情况下，第一轮身份验证已经在握手期间开始。现在，根据身份验证方法，可以交换进一步的身份验证数据，直到服务器拒绝或接受连接。

 

成功的快速身份验证路径如下所示：

1. 客户端连接到服务器

2. 服务器Initial Handshake Packet使用 using auth 方法 M 进行 响应

3. 客户端Handshake Response Packet使用相同的方法发送 M

4. 客户端和服务器可能会根据身份验证方法 M 的要求进一步交换数据包

5. 服务器响应 OK_Packet

认证失败

服务器指示不允许客户端通过发送连接 ERR_Packet。这可能在初次握手后的任何时候发生。

认证方式不匹配

1 认证方式变更

2 客户端能力不足

ERR_Packet 如果发现客户端能力不足以完成身份验证， 服务器将拒绝连接 。这可能发生在以下情况：

• 不支持可插入身份验证（CLIENT_PLUGIN_AUTH 未设置标志）的客户端连接到使用不同于Secure Password Authentication或 的 身份验证方法的帐户 Old Password Authentication。

• 不支持安全身份验证（CLIENT_SECURE_CONNECTION 未设置标志）的客户端连接到使用不同于 的身份验证方法的帐户 Old Password Authentication。

• 服务器用于生成身份验证数据的默认身份验证方法 Initial Handshake Packet不同于 Secure Password Authentication客户端不支持可插拔身份验证（CLIENT_PLUGIN_AUTH 未设置标志）。

3. 客户端不知道的新认证方法

4.非 CLIENT_PLUGIN_AUTH 客户端

连接阶段数据包

 能力标志

5.2命令阶段