用mysql client访问tidb在输错密码或者不输密码的情况，tidb需要等待10s左右后才返回报错信息

[DongKing]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】v4.0.9

【问题描述】
mysql client版本 ：5.7.24
用mysql client访问tidb server(v4.0.9)在输错密码或者不输密码的情况，tidb需要等待10s后才返回报错信息,而在v4.0.8版本没有这个问题，对比了两个版本tidb相关的参数并没有发现有不同的设置，不知道是哪的问题，麻烦大佬们帮忙看看

v.4.0.9截图

v4.0.8截图

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[北京大爷]

用 strace 看下 具体慢在哪里吧
https://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/strace.html
正常 tidb 只支持 native_password 密码格式 ，如果是其他密码模式会有不支持情况
具体参看
https://docs.pingcap.com/zh/tidb/v3.0/security-compatibility-with-mysql#与-mysql-安全特性差异

[DongKing]

跟native_password没有关系啊，刚发现用127.0.0.1访问的时候输错密码或者密码为空的情况下没有问题，
这是strace的部分信息：
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc705dc9000
read(3, “# /etc/services:\ # $Id: services”…, 4096) = 4096
read(3, " 74/udp “…, 4096) = 4096
read(3, " # Quick Mail Transfer Proto”…, 4096) = 4096
read(3, " 636/udp “…, 4096) = 4096
read(3, " # Microsoft-SQL-Monito”…, 4096) = 4096
read(3, " # discp s"…, 4096) = 4096
close(3) = 0
munmap(0x7fc705dc9000, 4096) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7fc7046d1400}, {SIG_DFL, [], 0}, 8) = 0
stat("/usr/local/mysql/share/charsets/Index.xml", 0x7ffd6429d370) = -1 ENOENT (No such file or directory)
futex(0xa4ac00, FUTEX_WAKE_PRIVATE, 2147483647) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(4000), sin_addr=inet_addr(“xxxxxx”)}, 16) = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
recvfrom(3, “V\0\0\0\ 5.7.25-TiDB-v4.0.9\0t\0\0\0\26\1Y|”…, 16384, 0, NULL, NULL) = 90
sendto(3, “\311\0\0\1\205\246\377\1\0\0\0\1-\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0”…, 205, 0, NULL, 0) = 205
recvfrom(3, “S\0\0\2\377\25\4#28000Access denied for u”…, 16384, 0, NULL, NULL) = 87
shutdown(3, SHUT_RDWR) = 0
close(3) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 12), …}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc705dc9000
write(2, "ERROR 1045 (28000): ", 20ERROR 1045 (28000): ) = 20
write(2, “Access denied for user 'xxxx”…, 74Access denied for user ‘xxx’@‘xxxxx’ (using password: YES)) = 74
write(2, “\ ”, 1
) = 1
write(1, “\7”, 1) = 1
rt_sigaction(SIGQUIT, {SIG_IGN, [QUIT], SA_RESTORER|SA_RESTART, 0x7fc7046d1400}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN, [INT], SA_RESTORER|SA_RESTART, 0x7fc7046d1400}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTORER|SA_RESTART, 0x7fc7046d1400}, {SIG_DFL, [], 0}, 8) = 0
exit_group(1) = ?
+++ exited with 1 +++

srace会卡在这个地方：
sendto(3, “\311\0\0\1\205\246\377\1\0\0\0\1-\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0”…, 205, 0, NULL, 0) = 205
recvfrom(3
看起来是卡在了用户校验

[北京大爷]

可以加 -C -T 输出带有统计信息的 trace 记录

鉴于你刚才说的 127.0.0.1 没有出现此问题。
问题应更多出在服务器网络层面。包括 防火墙、安全控管、网络审计等等服务工具上
127.0.0.1 是本地回环地址，及不会走网卡外部访问链路。

或者更好其他 客户端服务器进行测试

[DongKing]

已排除了tidb 的问题，原因我们在分析一下，多谢

[Lucien]

感谢反馈结论，有问题可以创建新的帖子