Chrome使用域名访问局域网服务响应慢的问题

服务部署在局域网上的机器中，同一局域网通过Chrome浏览器访问服务时载入花了很长的时间。

这里看到初始连接就花了21秒，这很奇怪。

排查过程

初步怀疑是服务出了问题，然后开始直接使用telnet去连接服务端口

这里没有感觉到响应延迟，开始检查变量。

这里两次响应速度结果的差异在于客户端不同，一个是Chrome，一个是telnet。

开始怀疑是Chrome的问题，换其他浏览器再看看是否出现不一样的结果，换Firefox试试。

使用Firefox并没有出现响应时间长的问题，那估计问题就出在Chrome上了。

再次使用Chrome去访问内网服务，这次不使用域名

发现居然响应时间长的现象不存在了，又发现一组变量：域名与IP。

现在的问题变成了，为什么Chrome使用域名访问与直接用IP访问会出现差异？

使用nslookup查询一下域名，发现了端倪

响应的地址有两个，其中有一个是无效的IP地址！

这里感觉大概就找到了问题所在，回去查看一下路由器的DNS设置，确实如此，看来之前是自己加了重复映射而且还打错了IP…

删除了错误的IP映射后，问题解决了。

事后

为何Chrome会显示在初始连接这么耗时呢？去看Chrome对于耗时指标的说明

建立连接…TCP握手或重试以及协商SSL，这里看来是重试在耗时。

Chrome在对着无效的IP尝试进行连接然后失败，再重试，然后耗时21秒，但这里就不得不提Firefox了。

Firefox并没有受到错误IP的影响，依然能快速的返回正确的服务响应，这里体现了Chrome与Firefox对于多IP的处理方式的不同。

我猜测Firefox对于多IP会进行一个并发的请求处理，而Chrome则是进行轮询处理，可以做下实验测试一下猜想。(也可以看源码对这一块的处理)

将正确的IP设置在第一位，错误的IP设置到第二位，然后去通过域名访问服务

发现长时间响应问题不存在了，可以证实Chrome是采用顺位轮询的方式来处理多IP的情况。

这样看来Firefox做的比Chrome要好啊…