Node.js dns.resolve()vs dns.lookup() [英] Node.js dns.resolve() vs dns.lookup()

查看:471
本文介绍了Node.js dns.resolve()vs dns.lookup()的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要在Node.js中查找给定的主机到其对应的IP。似乎有两种本机方法:

I need to lookup a given host to its corresponding IP in Node.js. There seems to be two native methods of doing this:

> dns.resolve('google.com', (error, addresses) => { console.error(error); console.log(addresses); });
QueryReqWrap {
  bindingName: 'queryA',
  callback: { [Function: asyncCallback] immediately: true },
  hostname: 'google.com',
  oncomplete: [Function: onresolve],
  domain:
   Domain {
     domain: null,
     _events: { error: [Function] },
     _eventsCount: 1,
     _maxListeners: undefined,
     members: [] } }
> null
[ '216.58.194.174' ]

And:

> dns.lookup('google.com', (error, address, family) => { console.error(error); console.log(address); console.log(family); });
GetAddrInfoReqWrap {
  callback: { [Function: asyncCallback] immediately: true },
  family: 0,
  hostname: 'google.com',
  oncomplete: [Function: onlookup],
  domain:
   Domain {
     domain: null,
     _events: { error: [Function] },
     _eventsCount: 1,
     _maxListeners: undefined,
     members: [] } }
> null
216.58.194.174
4

都返回相同的IPv4地址。 dns.lookup() dns.resolve()之间有什么区别?而且,对于每秒的大量请求来说,性能更好?

Both return the same IPv4 address. What is the difference between dns.lookup() and dns.resolve()? Also, which is more performant for lots of requests per second?

推荐答案

dns 文档已经描述了区别:

The dns documentation already describes the difference:


尽管dns.lookup()和各种dns.resolve *()/ dns.reverse()函数具有将网络名称与网络地址相关联的相同目标(或反之亦然),他们的行为是完全不同的。这些差异可能对Node.js程序的行为产生微妙但重大的影响。



dns.lookup()


在引擎盖下,dns.lookup()使用与大多数其他程序相同的操作系统设施。例如,dns.lookup()几乎总是以与ping命令相同的方式解析给定的名称。在大多数类似POSIX的操作系统上,可以通过更改nsswitch.conf(5)和/或resolv.conf(5)中的设置来修改dns.lookup()函数的行为,但请注意,更改这些文件将会更改在同一操作系统上运行的所有其他程序的行为。



虽然对dns.lookup()的调用从JavaScript的角度来看是异步的,但它被实现为在libuv的线程池上运行的getaddrinfo(3)的同步调用。因为libuv的线程池具有固定大小,这意味着如果由于任何原因getaddrinfo(3)的调用需要很长时间,可以在libuv的线程池(如文件系统操作)上运行的其他操作将遭遇降级的性能。为了减轻此问题,一个潜在的解决方案是通过将UV_THREADPOOL_SIZE环境变量设置为大于4的值(其当前的默认值)来增加libuv的线程池的大小。有关libuv的线程池的更多信息,请参阅官方libuv文档。



dns.resolve(),dns.resolve *()和dns.reverse()


这些功能与dns.lookup()的功能完全不同。他们不使用getaddrinfo(3),他们总是在网络上执行DNS查询。这种网络通信始终是异步执行的,不使用libuv的线程池。



因此,这些函数不能对dns.lookup()可以在libuv的线程池上发生的其他处理产生相同的负面影响。



它们不使用与dns.lookup()使用的相同的配置文件集。例如,它们不使用/ etc / hosts中的配置。
Although dns.lookup() and the various dns.resolve*()/dns.reverse() functions have the same goal of associating a network name with a network address (or vice versa), their behavior is quite different. These differences can have subtle but significant consequences on the behavior of Node.js programs.

dns.lookup()
Under the hood, dns.lookup() uses the same operating system facilities as most other programs. For instance, dns.lookup() will almost always resolve a given name the same way as the ping command. On most POSIX-like operating systems, the behavior of the dns.lookup() function can be modified by changing settings in nsswitch.conf(5) and/or resolv.conf(5), but note that changing these files will change the behavior of all other programs running on the same operating system.

Though the call to dns.lookup() will be asynchronous from JavaScript's perspective, it is implemented as a synchronous call to getaddrinfo(3) that runs on libuv's threadpool. Because libuv's threadpool has a fixed size, it means that if for whatever reason the call to getaddrinfo(3) takes a long time, other operations that could run on libuv's threadpool (such as filesystem operations) will experience degraded performance. In order to mitigate this issue, one potential solution is to increase the size of libuv's threadpool by setting the 'UV_THREADPOOL_SIZE' environment variable to a value greater than 4 (its current default value). For more information on libuv's threadpool, see the official libuv documentation.

dns.resolve(), dns.resolve*() and dns.reverse()
These functions are implemented quite differently than dns.lookup(). They do not use getaddrinfo(3) and they always perform a DNS query on the network. This network communication is always done asynchronously, and does not use libuv's threadpool.

As a result, these functions cannot have the same negative impact on other processing that happens on libuv's threadpool that dns.lookup() can have.

They do not use the same set of configuration files than what dns.lookup() uses. For instance, they do not use the configuration from /etc/hosts.

根据并发,您最好使用 dns.resolve *() / code>因为这些请求不会在线程池中结束,而 dns.lookup()请求 do 因为它们调用对于通常阻止(尽管现在有某种异步接口)的OS DNS解析器,但是它们并不一定在任何地方实现。

As far as concurrency goes, you are better off using dns.resolve*() because those requests do not end up in the thread pool, whereas dns.lookup() requests do because they call out to the OS DNS resolver which typically blocks (although there are some kind of-async interfaces now -- but they are not necessarily implemented everywhere).

目前,节点内部使用任何自动DNS解析的 dns.lookup(),例如将主机名传递给 http.request()时。

Currently, node internally uses dns.lookup() for any automatic DNS resolution, like when you pass a hostname to http.request().

这篇关于Node.js dns.resolve()vs dns.lookup()的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆