并行资源加载与 DNS 查找速度

发布于 2024-09-11 23:48:09 字数 159 浏览 1 评论 0原文

减少页面加载时间的常用技术是通过从不同的主机名检索多个静态资源下载来并行化它们(即使它们全部解析到同一服务器)。
但是,浏览器需要对每个主机名发出 DNS 查找请求,这可能需要很长时间。
您能否提出一种方法,使用该方法 JavaScript 代码可以动态确定并行资源下载的最佳主机名数量?

A common technique for reducing page loading times is to parallelize multiple static resource downloads by retrieving them from different hostnames (even if they all resolve to the same server).
However, the browser needs to issue a DNS lookup request for each of these hostnames, which could take a significant time.
Can you propose a method using which the JavaScript code could determine on the fly the optimal number of hostnames to parallelize resource downloads over?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

菊凝晚露 2024-09-18 23:48:09

第一次解析给定的 DNS 名称后,该名称应由距离用户非常近的解析器缓存。因此,如果您想获得更多并行连接,请不要使用完全随机的、现成的服务器;使用一组一致的五个左右不同的主机。 DNS 加载只会在用户第一次访问您的网站时发生(或者,如果共享相同缓存解析器的人已经访问过该网站,则即使那时也不会发生),并且会与页面正文的下载同时发生。

JavaScript 无法确定“最佳”数量,因为它不知道 DNS 查询在发出查询之前需要多长时间。

After the first time you resolve a given DNS name, the name should be cached by a resolver very close to the user. So if you want to get more parallel connections, just don't use totally-random, off-the-wall servers; use a consistent set of five or so different hosts. The DNS load will only happen the first time a user hits your site (or, not even then, if someone sharing the same caching resolver has already been there) and will happen in parallel with the download of your page's body.

JavaScript is ill-equipped to determine the "optimal" number, as it has no idea how long the DNS queries will take before issuing them.

说好的呢 2024-09-18 23:48:09

有多种方法可以减少不同主机名的 DNS 加载时间。一个技巧是在 DNS 响应的 AR 部分中包含其他主机名;例如,如果有人请求 a.example.com,我们可以帮助他们告诉他们 b.example.com、c.example.com、d.example.com 等的 DNS 主机名,作为 DNS 回复中的附加记录,在答案中向他们提供 a.example.com 的 IP 时。

这将使用一些(但不是全部)递归 DNS 服务器预先缓存所有其他主机名的答案(出于安全原因,此技巧不适用于我实现的任何一个递归 DNS 服务器,因为出于安全考虑原因,他们不会盲目地缓存 DNS 回复的 AR 部分中的记录)。

最小化 DNS 查找的另一个技巧是让所有名称都在同一个域中(所有名称都以 example.com 结尾:a.example.com、b.example.com 等),确保没有需要遵循无胶记录来解析名称(使您的 NS 记录具有诸如 ns1.example.com 和 ns2.example.com 之类的名称,并且不要使用任何 CNAME 条目),并且,如果您的服务器不经常更改 IP通常,您的服务器的 DNS 条目具有较大的 TTL。

There are a number of ways of reducing DNS load time with different host names. One trick is to have the other host names in the AR section of the DNS response; for example, if someone asks for a.example.com, we can helpfully tell them the DNS hostnames for b.example.com, c.example.com, d.example.com, and so on as additional records in the DNS reply, when giving them the IP for a.example.com in the answer.

This will pre-cache the answers for all of those other host names with some, but not all, recursive DNS servers (for security reasons, this trick doesn't work for either of the recursive DNS servers I have implemented, since, for security reasons, they do not blindly cache records in the AR section of a DNS reply).

Another trick to minimize DNS lookups is to have all of the names in the same domain (have all names end in, for example, example.com: a.example.com, b.example.com, etc.), make sure no glueless records need to be followed to resolve the names (make your NS records have names like ns1.example.com and ns2.example.com, and don't use any CNAME entries), and, if your servers do not change IPs very often, have a large TTL for the DNS entries for your servers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文