【问题标题】:Domain Name Re-resolution issue Firefox域名重新解析问题 Firefox
【发布时间】:2014-08-23 22:50:22
【问题描述】:

如果我在 AWS EC2 上托管了四台相同的服务器,分为两组,每组位于不同的 AWS 区域。每组前面有一个ELB。我配置了两个加权别名记录(不基于延迟)指向 AWS Route53 中每个组的 ELB。

每个服务器都安装了一个简单的apache2 服务器,它显示一个简单的页面,用不同的词来区分彼此。我启动了一个浏览器客户端(由Selenium 库制作)经常使用作为这些服务器域名的 URL 重新加载页面(暂停 1 秒),但我发现浏览器(firefox)总是从服务器返回页面在一组中,而不是像Weighted Round Robin 那样以 50% 的时间从两组返回页面。 我还发现,如果我暂停相对较长的时间,其他组的页面确实会返回,但只要我经常刷新页面。它永远不会改变。请求总是命中一组而不是另一组。

我还编写了一个简单的Java 程序来继续从 AWS Route 53 查询域名,并且我返回的地址确实在两组之间发生了变化,但是浏览器似乎卡在与它第一次连接的组的连接中(如只要我经常刷新)

我怀疑是 TCP 连接仍然存在的问题,但我不确定。顺便说一句,我已经禁用了浏览器缓存,并且我使用的是 Mac OS X 10.9。 (这也发生在 Ubuntu 上)

任何想法都将不胜感激。这个问题对我的作品来说真的很重要,我的截止日期快到了。非常感谢。

【问题讨论】:

    标签: selenium amazon-web-services tcp dns amazon-route53


    【解决方案1】:

    很遗憾,这很正常。

    许多(也许是大多数)浏览器会缓存从操作系统获得的 dns 响应,并且此缓存的时间与 DNS TTL 无关——它由浏览器开发人员自行决定。

    对于 Firefox,默认时间似乎是 60 秒,因此,不太可能与 keepalives 直接相关,尽管这当然也有一些潜力......尽管在某些情况下,时间间隔更短,因为许多服务器会在 60 秒之前断开空闲的保活连接,因为长时间空闲的连接可能会浪费大量资源。

    火狐:http://kb.mozillazine.org/Network.dnsCacheExpiration

    有关问题的讨论和对不同浏览器行为的观察,另请参阅:http://dyn.com/blog/web-browser-dns-caching-bad-thing/

    【讨论】:

    • 非常感谢您的快速响应,但我在笔记本电脑上使用的 firefox 和 Selenium 库启动的浏览器上都将 Network.dnsCacheExpiration 和 Network.dnsCacheExpirationGracePeriod 设置为 0 .没有任何帮助。 Firefox 版本低于 29 似乎有 bug (bugzilla.mozilla.org/show_bug.cgi?id=861273)
    • 这很可能是一个错误,但要确认...您确实使用了小写的network,而不是Network,对吧?另外,您是否确认“0”值并不意味着无限期(尝试非常小的值)?您可以使用tshark 确认保活计时行为。所有这些都让我对您在答案中寻找什么感到有些困惑。这是现状:(W)RR DNS 无法可靠地为站点上已经处于活动状态的所有个人用户提供快速故障转移。即使这是一个错误或糟糕的默认配置,我们(网络平台管理员)也不能(通常)修复或强制要求浏览器配置。
    • 嗨迈克尔,感谢 cmets。是的,我从 firefox about:config 页面复制了配置名称,所以它不应该是我的代码中的拼写错误,并且将其设置为 0 确实是禁用 Firefox 的 DNS 缓存的方法,正如 Internet 上的人们所建议的那样。我想要实现的是模拟用户的网站浏览行为(或继续访问具有相同 URL 的网站),我希望看到用户请求被路由到 2 组服务器我有相同的次数给定更长的时间监控。
    • 由于某种原因,当我经常访问 URL 时,我总是从一个(组)服务器而不是另一个服务器获得响应。我想知道可能是什么原因。我不是试图实现故障转移,而是分发用户请求。
    • 总之,微妙的问题总是很难仅仅通过描述情况来解决。因此,再次感谢您的患者考虑我的问题。再问一个问题,如果你不介意的话:理想情况下,即使浏览器或操作系统缓存 DNS 响应,这种缓存的效果是通过 WRR DNS 负载均衡实现的用户请求分发将在更长的时间内得到反映如果根本没有缓存,而不是立即生效?正确吗?
    猜你喜欢
    • 2019-03-16
    • 2012-02-19
    • 1970-01-01
    • 2011-11-08
    • 2017-02-13
    • 1970-01-01
    • 2021-03-24
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多