![Webkit 浏览器加载网页图片/资源不一致](https://linux22.com/image/1395525/Webkit%20%E6%B5%8F%E8%A7%88%E5%99%A8%E5%8A%A0%E8%BD%BD%E7%BD%91%E9%A1%B5%E5%9B%BE%E7%89%87%2F%E8%B5%84%E6%BA%90%E4%B8%8D%E4%B8%80%E8%87%B4.png)
我已经遇到这个问题很长时间了,通过基于 webkit 的浏览器访问网站时,图像加载不一致。所谓不一致,是指在一次试运行中,一张或几张图片可以成功加载,而其他图片则加载不上。在对同一个网站的另一次试运行中,之前未加载的图片会突然加载——而之前加载的图片突然无法加载。这种行为是如此非线性,以至于我很难找出问题的根源。我注意到,、和等浏览器中都可以复制这个问题。jumanji
我dwb
相信vimperator
所有这些浏览器的共同点是它们都使用webkit
。反复重新加载网页有时会导致所有资源都正确加载。
以下是所描述行为的屏幕截图(来自基于 webkit luakit
):
如您所见,这是两个失败的图像,说明了此处的常见行为。我无法使用 Firefox 或 Chrome 等浏览器复制此问题(我相信它们分别使用gecko
和blink
)。如果我右键单击图像/元素并在新窗口中打开它,我就可以毫无问题地查看图像。我正在运行 Arch Linux 内核 3.12.9-1-ck。任何有关可能发生的情况的帮助/见解都将不胜感激。谢谢。
更新:每个损坏的图像,当通过 luakit 中的调试控制台作为元素检查时,会输出以下一般形式的内容:
GET [web address here] Cannot resolve hostname [domain here]
更新2:我尝试通过 在我的系统(基于 debian)上的luakit
virtualbox 安装中进行安装,结果很有趣... 没有出现无法解析的主机名/损坏的图像/失败的资源的症状。在这个虚拟环境中浏览速度也相对较快。kali-linux
apt-get install luakit
解决方案:
按照 @harrymc 的建议(使用 Google 公共 DNS)完全消除了页面加载缓慢的所有症状。据 @harrymc 说,这是由于 DNS 错误/缓慢和/或 DNS 缓存策略不佳造成的。更具体地说,导致此问题的是 DNS 不佳,以及引擎内置的似乎相当仓促的超时协议webkit
。这两个因素是灾难的根源。
更加开放的思路:
另一个结论是 Webkit 浏览器效率低下,因为它们会针对同一个网站发出多个 DNS 查询,而不是记住第一个查询。另一个结论是,ISP 的 DNS 服务器有时似乎无法处理多个并行请求(因为浏览器可能通过线程并行处理多个图像),也许是因为他们现在拥有更多客户端,但 DNS 服务器不够用。 --harrymc
答案1
由于 Webkit 团队武断地决定通过硬编码的隐藏超时 60 秒来限制所有 XML HTTP 请求,我们刚刚被迫重构/重新编码了我们基于 AIR 的 RIA 的很大一部分。此决定不仅影响 AIR,还影响 Safari 和其他基于 Webkit 的浏览器。
虽然这并不一定与您的问题有关,但它确实指出了 Webkit 中存在硬编码超时。
如果您的问题与 Webkit 中的超时时间太短有关,那么问题是,既然您的连接速度很快,为什么您还要等待很长时间才能看到图像。
作为第一次测试,我建议将您的 DNS 服务器更改为 Google 公共 DNS或者开放DNS,看看这是否有区别。如果不同,则问题在于您的 ISP 的 DNS 速度太慢或使用自己的缓存。
另一个参考通过 User-Agent 禁用 HTTP keepalive:
Safari 中长期存在的错误会导致在不正确地重用保持连接时文件上传挂起。
https://bugs.webkit.org/show_bug.cgi?id=5760
在 Apache 中,禁用对 Webkit 的 keepalive 支持可解决这个问题。
如果 Apache Web 服务器仍然禁用 Webkit 的 keepalive(HTTP 长连接),这意味着每张图片都需要单独的 HTTP 连接,而 Firefox 和 Chrome 可以使用页面已经存在的连接来下载图片,而无需重新连接。
由于建立连接通常非常慢,再加上较短的内置超时时间,这或许可以解释 Webkit 在图像方面存在的问题。
我想知道你的 Webkit 浏览器是否有能力改变它们的用户代理 身份 ?
例如,尽管我对 vimperator 一无所知,但我通过谷歌找到了这个插件用户代理切换器精简版。