参考http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol（我也参与这个页面的编辑）
请参见sql-common/client.c的CLI_MYSQL_REAL_CONNECT函数。
客户端接下来的流程可分为三个阶段：
服务器启动的时候是在sql/mysqld.cc的network_init函数建立socket，然后bind。服务器专门有一个线程（可称为Connection Manager）处理新来的网络连接。这个线程的主函数是sql/mysqld.cc的handle_connections_sockets_thread，主要的逻辑在sql/mysqld.cc的handle_connections_sockets。handle_connections_sockets的逻辑就是典型的select()/accept()/dispatch。每个客户端连接最终会对应着一个线程以及一个THD对象。THD类不是一个通用的描述任意线程的类，它就是专门为处理客户端的的TCP连接而设计的。这个类非常大，在sql/sql_class.h中定义。
每个worker线程的入口函数是在sql/sql_connect.cc中的handle_one_connection。sql/sql_parse.cc的do_command从网络连接上读一个command，并执行。handle_one_connection函数是以while循环的方式执行do_command。
客户端发给服务器的包可分为两种：登录时的一个auth包，以及身份验证结束后的command包。
服务器发给客户端的包可分为四种：登录时的握手包、数据包、数据流结束包、成功包(OK Packet)、错误信息包。
所有的包都具有统一的格式，由统一的函数(sql/net_serv.cc:my_net_write(…))写入buffer等待发送。
| 长度 | 描述 |
| 3 | 包长度（单位：字节）。按低字节低址的规则存放。因为一共就3个字节，所以单个包的最大长度是(2的16次方-1)字节，约等于16MB。最小长度是0。 |
| 1 | 序号。第一个是0。 |
| n | data。 |
实际上，包长等于 2的16次方-1的包也会被拆成2个包发送。因为Mysql最初没有考虑突破16M，也没有预留任何字段做标志这个包的数据不完整。所以只好把长度为2的16次方-1的包视做不完整的包，直到后面收到一个长度小于2的16次方-1的包，然后拼起来。所以最后一个包的长度有可能是0。
服务器在每收到一个新的连接的时候，会使用sql/sql_connect.cc的login_connection函数作身份验证。先根据IP做acl，然后才进入用户名密码验证阶段。mysql的登录协议是经典的CHAP协议，sql/sql_acl.cc的native_password_authenticate函数的注释简单了解释了这个协议：
random scramble在4.1之前的版本中是8字节整数，在4.1以及后续版本是20字节整数。它是由password.c的create_random_string函数生的，因为它采用的是rand()%94+33这样的方式生的，所以scramble的每个字节一定是[33,127)之间的ASCII字符，在协议中发送时，是加上’/0’之后发的(这个后面会详细解释）。
在身份验证之后，服务器和客户端之间处于一问一答的模式。 截至到Mysql 5.5.9，mysql server一共支持30种command，sql/sql_parse.cc的 dispatch_command函数写了一个大大的switch…case来处理它们。
客户端执行recv，会收到一个来自server的包，其中第一个字节是协议的版本号。其它的重要信息还有connection id、scramble
41 00 00 00
0A 35 2E 30 2E 32 30 2D 73 74 61 6E 64 61 72 64 2D 6C 6F 67 00 44 8E 4E 00 5A 66 72 2A 79 43 24 27 00 2C A2 08 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 36 7B 29 58 5E 50 56 41 21 7C 73 4C 00
其格式如下：（来自sql_acl.cc的send_server_handshake_packet函数的注释）
| 长度 | 说明 |
| 1 | 协议的版本号 (0x0A) |
| n | 以0结尾的字符串。描述服务器版本 |
| 4 | thread id |
| 8 | scramble的前8个字节 |
| 1 | 0x00。也就是说让scramble看起来是一个以0结尾的字符串 |
| 2 | server capabilities的低两个字节。 |
| 1 | server character set |
| 2 | server status |
| 2 | server capabilities的高两个字节。 |
| 1 | scramble的总长度 |
| 10 | 保留。必须以0填充。 |
| n(至少12） | scramble的剩余部分。（不包含’/0’） |
| 1 | 0x00。也就是说让scramble看起来是一个以0结尾的字符串 |
server capabilities表：
| 名字 | 从右往左数第几位 | 说明 |
| CLIENT_LONG_PASSWORD | 1 | new more secure passwords |
| CLIENT_FOUND_ROWS | 2 | Found instead of affected rows |
| CLIENT_LONG_FLAG | 3 | Get all column flags |
| CLIENT_CONNECT_WITH_DB | 4 | One can specify db on connect |
| CLIENT_NO_SCHEMA | 5 | Don’t allow database.table.column |
| CLIENT_COMPRESS | 6 | Can use compression protocol |
| CLIENT_ODBC | 7 | Odbc client |
| CLIENT_LOCAL_FILES | 8 | Can use LOAD DATA LOCAL |
| CLIENT_IGNORE_SPACE | 9 | Ignore spaces before ‘(‘ |
| CLIENT_PROTOCOL_41 | 10 | New 4.1 protocol |
| CLIENT_INTERACTIVE | 11 | This is an interactive client |
| CLIENT_SSL | 12 | Switch to SSL after handshake |
| CLIENT_IGNORE_SIGPIPE | 13 | IGNORE sigpipes |
| CLIENT_TRANSACTIONS | 14 | Client knows about transactions |
| CLIENT_RESERVED | 15 | Old flag for 4.1 protocol |
| CLIENT_SECURE_CONNECTION | 16 | New 4.1 authentication |
| CLIENT_MULTI_STATEMENTS | 17 | Enable/disable multi-stmt support |
| CLIENT_MULTI_RESULTS | 18 | Enable/disable multi-results |
| CLIENT_PS_MULTI_RESULTS | 19 | Multi-results in PS-protocol |
| CLIENT_PLUGIN_AUTH | 20 | Client supports plugin authentication |
| CLIENT_SSL_VERIFY_SERVER_CERT | 31 | |
| CLIENT_REMEMBER_OPTIONS | 32 |
客户端根据服务器发给的scramble对原始密码进行散列，然后和其它参数一起发给服务器
发送登录数据:
00000000 3A 00 00 01 85 A6 03 00 00 00 00 01 08 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020 00 00 00 00 72 6F 6F 74 00 14 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 长度 | 说明 |
| 4 | client capabilities |
| 4 | max packet size |
| 1 | charset number |
| 23 | 保留。必须以0填充。 |
| n | user name。以0结尾的字符串 |
| n | hash过的密码。length (1 byte) coded |
| n | database name,以0结尾的字符串。只有client capabilities中有CLIENT_CONNECT_WITH_DB时，此字段才有效。 |
| n | client auth plugin name。以0结尾的字符串。只有client capabilities中有CLIENT_PLUGIN_AUTH时，此字段才有效。如果使用mysql默认的auth机制，此处应该为mysql_native_password |
sql-common/client.c的send_client_reply_packet函数构造这个答复包然后发送。散列算法的实现在password.c的scramble(char *to, const char *message, const char *password)函数。
授权信息已经发送过去了，服务器可以会回答说OK（发回一个OK_PACKET)，也有可能会要求再度发送scrambled password。
如果要再度发送，服务器会返回一个1字节的包，如果第一个字节是0xFE且mysql.server_capabilities设置了CLIENT_SECURE_CONNECTION，那么
就需要再度发送scrambled password
这个似乎是为了和以前老版本兼容，这次需要使用3.23版的scramble对password进行加密然后发送。
scramble_323(buff, mysql->scramble, passwd);
如：
0x8059000: 0x09 0x00 0x00 0x03 0x4d 0x45 0x46 0x4c
0x8059008: 0x4f 0x44 0x4b 0x4b 0x00
这个包的格式很简单，包头，然后是9个字节的scramble(其中最后一个字节必须是0x00)
不过要注意，此处包头的第4个字节是0x03,因为这是认证过程是双方来回发送的第三个包了。
0x20,0x00,0x00,0x00, 包头
0x03 //命令的类型，COM_QUERY
select * from xxx where xxx //arg
========================================================
MYSQL认证漏洞：
1、构造0长度的scramble绕过密码校验
这几乎可以算是mysql目前发现的危害性最严重的安全漏洞了。
出问题的代码：
my_boolcheck_scramble_323(constchar*scrambled,constchar*message,ulong*hash_pass){structrand_structrand_st;ulonghash_message[2];charbuff[16],*to,extra;/* Big enough for check */constchar*pos;hash_password(hash_message,message,SCRAMBLE_LENGTH_323);randominit(&rand_st,hash_pass[0]^hash_message[0],hash_pass[1]^hash_message[1]);to=buff;for(pos=scrambled;*pos;pos++)*to++=(char)(floor(my_rnd(&rand_st)*31)+64);extra=(char)(floor(my_rnd(&rand_st)*31));to=buff;while(*scrambled){if(*scrambled++!=(char)(*to++^extra))return1;/* Wrong password *
