背景
某企业开发环境用户反应，在相同的机房，相同网段，不同IP地址的mysql服务器，相同访问，一个响应很快，一个明显的慢。
纳闷之余，网深科技工程师帮其分析了原因。
分析之前，先约定一下，以下对响应快的简称“很快”，响应慢的简称“很慢”吧。
故障复现
在查看了用户使用mysql连接测试这一操作的演示，的确存在诸如用户的描述的现象。如下：
从用户操作层面，的确存在明显快慢差别，后者让人无法接收，“很慢”的确很慢。
问题分析
接下来，进入信息采集，侦察分析阶段。
客户端抓包分析
在客户端电脑，分别采集了很快和很慢以上操作的报文信息。结论如下。
我是很快客户端的报文
从很快客户端数据看，三步握手后，服务器更新了一下窗口，然后在0.05秒后返回了数据库版本信息。继而后续交换较快，整个连接持续1.2秒时长。
我是很慢的服务器报文
下面看一下很慢同学的表现。
同样，三步握手后，服务器更新了一下窗口信息。
接下来发生了一个异常现象，服务器在22秒后，才发送过来版本信息。
整个连接时长约27秒。
通过比较看到，很慢同学的确很慢。相同操作一个是1.2秒，一个是27秒。
服务器端抓包分析
从上述分析看到，很慢同学网络连接建立时间很快，慢的主要原因是服务器响应回来的信息时间太长。
那么，站着服务器角度，比较分析一下，是否可能由于某些网络因素导致了很慢的存在。
我是很快服务器的报文
在很快服务器上采集数据，从下图看到，第四个未携带数据的ack更新窗口包和第五个payload报文（数据库版本信息）之间时间差约0.秒。
我是很慢的服务器报文
同样，在很慢服务器上，更新窗口包和数据库版本包之间，时间差约22秒。的确很慢。
抓包分析结论
通过上述在客户端和服务器端的对比分析看到，很慢同学慢的原因是，服务器本身发出报文的时间很长，约22秒。
因此，通过抓包分析的结论是，很慢的原因是服务器的原因，与网络无关。
进一步分析
一般情况下，如果是网络运维部门，问题分析到这里，基本就可以停止了，然后理直气壮的把球踢给系统部门，哼，这问题不是我的原因。
而网深科技的技术人员，为了表现出自己的真才实学，带着打破砂锅问到底精神，还想进一步探索，为什么会有这种现象出现？
于是，有了进一步问题分析的环节。
细节决定成败。
在前面服务器抓包分析中，从服务器本身抓包信息来看，服务器本身的IP地址并没有显示为数字格式。与mysql通讯的地址显示如下。
很快：demo.cloudinside.