Bonjour 中的名称解析缓慢
这看起来太基本了，以至于人们会对此大喊大叫，在网络上搜索什么也找不到，但我已经在几个网络和计算机上测试了它。我们遇到一个问题，即使用 .local url 访问资源非常慢。如果我们使用直接 IP 地址，我们就不会看到这些延迟。
在我们的精简测试设置中，设备和计算机位于同一交换机上，并且是交换机上唯一的设备。当我们不在这个非常有限的网络配置中时，也会发生同样的事情。在 Mac OS X Lion 命令行上，我们得到以下结果：
使用直接 ip：
curl 10.101.62.42 0.01s user 0.00s system 18% cpu 0.059 total
使用 bonjour 名称：
curl http://xrx0000aac0fefd.local 0.01s user 0.00s system 0% cpu 5.063 total
每个请求的解析时间始终略高于 5 秒。无论我们尝试连接到哪个设备，我们的 iPhone 应用程序中似乎都会发生同样的情况，并且使用 Python 脚本时速度很慢。 Safari 似乎能够快速解析名称。
我们可以解析一次，然后使用 IP 地址，但第一个请求仍然会慢得令人无法接受，而且我认为这不是 Bonjour 应该工作的方式。
我们不确定这种情况何时开始发生，但情况并非总是如此。
编辑：另一个数据点。在 Snow Leopard 上，解决问题的速度并不慢：
$ time curl http://hp1320.local > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
101 2848 0 2848 0 0 15473 0 --:--:-- --:--:-- --:--:-- 36512
real 0m0.201s
user 0m0.005s
sys 0m0.009s
This seems so basic that people would be screaming about it, searching the web turned up nothing, but I have tested it on several networks and computers. We are having an issue where we use the .local url to access resources it is very slow. If we use the direct IP address we don’t see these delays.
In our stripped down test setup the device and the computer are on the same switch and are the only devices on the switch. The same thing occurs when we are not in this very limited network configuration. Mac OS X Lion on the command line we are getting these results:
With direct ip:
curl 10.101.62.42 0.01s user 0.00s system 18% cpu 0.059 total
With bonjour name:
curl http://xrx0000aac0fefd.local 0.01s user 0.00s system 0% cpu 5.063 total
It is consistently just above 5 seconds per request to resolve. It does not matter which device we try to connect to, the same seems to be occurring in our iPhone app, and is slow with Python scripts. Safari seems to be able to resolve the names quickly.
We could resolve once and then use the IP address but that first request will still be unacceptably slow, and I don’t think this is the way Bonjour is supposed to work.
We are not exactly sure when this started happening but it was not always this way.
Edit: Another data point. On Snow Leopard it is not slow at resolving:
$ time curl http://hp1320.local > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
101 2848 0 2848 0 0 15473 0 --:--:-- --:--:-- --:--:-- 36512
real 0m0.201s
user 0m0.005s
sys 0m0.009s
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
此问题已在 iOS 5 和 Lion 10.7.2 中得到解决。这是一个巨大的解脱。不幸的是，4.3 应用程序用户将遇到这种缓慢的行为。猜测这是升级的另一个原因。
This is resolved in iOS 5 and Lion 10.7.2. Which is a huge relief. Unfortunate that 4.3 app users will get this slow behavior. Guess it is another reason to upgrade.
当您浏览时，您提到的主机会出现吗？枚举应该很快：
也许有什么东西减慢了名称解析速度。如果您使用
dig查询 IP，它应该会立即返回正确的地址：如果失败，请尝试运行
tcpdump并查看是否有设备在网络上发出多播数据包。Do the hosts you mentioned show up when you browse for them? Enumeration should be pretty quick:
Maybe there's something slowing the name resolution. If you query the IPs with
digit should return the correct address pretty much instantly:Failing that try running
tcpdumpand see if there's a device that's spewing out multicast packets on the network.