Mysql DNS Reverse resolution causes connection Timeout process analysis (skip-name-resolve) _mysql

MySQL database received a network connection, first get the IP address of the other side, and then the IP address for the reverse DNS resolution to get this IP address corresponding host name. Use the host name in the permission system to determine the permissions. Reverse DNS parsing is time-consuming and can make users feel slow. Even sometimes, the reverse resolution of the host name does not point to this IP address, this time can not connect successfully.

You can disable MySQL for reverse DNS resolution in the configuration file simply by adding the following line to the MY.CNF [MYSQLD] paragraph:

Skip-name-resolve (Windows is the same as Linux)

When the device is connected to MySQL, waiting for the server's banner information needs about 4s, affecting the MySQL service connection speed.
Validation is done in the following ways:

1. Telnet Port Verification

By using devices and virtual machines (Linux systems) to Telnet MySQL service ports Separately, a symptom occurs:

Device (Uag/scanner): After telnet, waiting for MySQL server-side response will probably need to wait around 10s.

[Dptech-developer-shell]telnet 10.101.0.206 3308
Trying 10.101.0.206 ...
Connected to 10.101.0.206.
Escape character is ' ^] '.
E
5.0.67-community-nt-log? Hc95
Virtual Machine (Ubuntu): Telnet, immediately get the MySQL server back

[root]~# telnet 10.101.0.206 3308
Trying 10.101.0.206 ...
Connected to 10.101.0.206.
Escape character is ' ^] '.
E
5.0.67-community-nt-log? d% (; 1$]+,￠! ZDH '?   G) 6r]yconnection closed by foreign host. It takes a short time here.

2, through the program to verify

Specific source code See attachment: Validator Source code
The source code is basically set the recv timeout, after establishing a socket connection to accept data, after receiving the timer and output.

The results on the device and in the virtual machine are as follows:
Equipment:

[Dptech-developer-shell]/tcpclient_mips 10.101.0.1 3306
Cost Time: 19553
recved bytes
@
5.5.2-m2-community%ud3q ' N)

Virtual machine:

[root]tcp_demo#./tcpclient 10.101.0.1 3306
Cost Time: 10525
recved bytes
@
5.5.2-m2-communitd~k~y "; B

It can be found that the device is about 9s more time-consuming than a Linux server, where 10 seconds may be the time that the recv itself timed out.

3. Telnet verification through different operating systems

Through the Windows system and Linux virtual machines, devices, respectively, through the Telnet connection attempt, through the packet analysis that only the device is time-consuming, other time-consuming are relatively short.
Grab the packet found in the device socket, the MySQL server needs to send many times after the NBNS message, will transmit banner information, and Linux virtual machine and Windows System host in this process did not appear this problem.
Looked up some information about the MySQL NBNS packet problem:

MySQL Forum's Questions:

http://forums.mysql.com/read.php?11,250982,250982

The answer to the question
http://forums.mysql.com/read.php?11,250982,254683

From the answer, appears to be some version of the problem, the temporary solution is to the MySQL server configuration, do not enable named Pipes, that is, named pipe function can solve this problem.

After the search for relevant information that the remote connection timeout may be due to MySQL default on the DNS reverse resolution, each time the server tries to resolve the connection client host name, resulting in a longer time.

The workaround is to configure a skip-name-resolve in the server-side My.ini file to turn off MySQL Default-enabled DNS reverse parsing.

Once again telnet through the device and virtual machine or Windows system, you can see that the connection timeout is obviously non-existent.

In addition, the same problem exists when you connect by the C code you write yourself, after modifying Skip-name-resolve, you can actually find that the problem is no longer there:

Equipment:

[Dptech-developer-shell]/tcpclient_mips 10.101.0.1 3306
Cost Time: 10520
recved bytes
@
5.5.2-M2-COMMUNITY[Z44E>G)
Virtual machine:
[root]tcp_demo#./tcpclient 10.101.0.1 3306
Cost Time: 10521
recved bytes
@
5.5.2-m2-community7eve5wyx

Telnet through the virtual machine to connect to another IP 10.101.0.206 time to find the speed is also relatively slow, the consumption of time is basically the same as the device, may be due to the virtual machine and host host does not need to perform reverse domain name resolution, Or you should know the host name of the virtual machine IP address (NAT mode) for the system itself, so there is no need for DNS reverse resolution, resulting in a special situation in the virtual machine.
Finally, it is possible that this problem is actually not much related to devices or virtual machines, Linux systems, Windows systems, primarily because of server reverse DNS resolution. cannot be addressed from the client side, which means that our device cannot handle this situation.