![为什么 dig +trace 需要几秒钟才能完成?](https://linux22.com/image/174166/%E4%B8%BA%E4%BB%80%E4%B9%88%20dig%20%2Btrace%20%E9%9C%80%E8%A6%81%E5%87%A0%E7%A7%92%E9%92%9F%E6%89%8D%E8%83%BD%E5%AE%8C%E6%88%90%EF%BC%9F.png)
以下 dig 命令的 DNS 查询总和需要不到 200 毫秒才能完成,但整个命令需要 4 秒以上。为什么 dig +trace 花费的时间比 DNS 查询的总和长得多?
time dig @1.1.1.1 google.com +trace
; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 google.com +trace
; (1 server found)
;; global options: +cmd
. 518226 IN NS a.root-servers.net.
. 518226 IN NS b.root-servers.net.
. 518226 IN NS c.root-servers.net.
. 518226 IN NS d.root-servers.net.
. 518226 IN NS e.root-servers.net.
. 518226 IN NS f.root-servers.net.
. 518226 IN NS g.root-servers.net.
. 518226 IN NS h.root-servers.net.
. 518226 IN NS i.root-servers.net.
. 518226 IN NS j.root-servers.net.
. 518226 IN NS k.root-servers.net.
. 518226 IN NS l.root-servers.net.
. 518226 IN NS m.root-servers.net.
. 518226 IN RRSIG NS 8 0 518400 20200611050000 20200529040000 48903 . UPDRbakA0IKukt7UAHMmcGhNsg7QHWkEifKreuLASnSxAYH4N+i4EDLy RniJQJswKaBaZJS1Eput7i1RUKKaryv57q4ZxgjFbQOSiwvJJAgJqoUe n/XTH8SAUwbJHFVMkpi0XlctOeeX9uLv438khUJyPkxMyTUxTHBeqRev i5kboRwLWwXA7ui+q/lNTt9NCSnBKZSk9qULvOi3WuxVCOCYrQerLDgH UKVzhDxfoS7sIGNSKw7cIq2Cq7txU1sI9A5DZLzfGZzHNFNgZVWzYmS9 gFMyDepVljc4c0RJpnzFVACKUYjAMC/wqTtybgwIhL9h+TwBiT4+323k 0gpqog==
;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 12 ms
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20200611050000 20200529040000 48903 . Vloranh+Ko0eMmq+QYgOK+yTHESioE5rM6rMNCH001IQqlQ2QkHGTqbI 7V4m2gLaPRgWBcnVe6MzaiVICjs0XupPqXMoZ4NvPCpEzM/QpfVSjjZ+ EKOxxZQ+A9jn9KH36OKEoS/XIJnke2Q/liFXJwRmcw8Wac501YORtUZP H4r/N4BEkWI+jIcYbzIqeZ+PcMaRB2Of+b1loNZ9MrOb+UdVUa0qT/0i 13sop9ynCs5Zfpds15L1lFnj6Lym244KjfYnPJQjjLlWtdk17DCW9TwY KFWM/BaPUJ/6m3qveENjAnsqVu+0GBqZTdPSwpkGjIGVzGOHd1ohdr0B wRE1hA==
;; Received 1198 bytes from 192.112.36.4#53(g.root-servers.net) in 68 ms
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200602045009 20200526034009 39844 com. B2EYsHhknBbnBb/ztws9dVndTXw1YepK2JNj7oyVOa+YSrPZXGMn9VTs X0+TGRlQolc5paKNQQF110lip0laiACz8TNQ/R4NX3rqvYeu240/9zBZ B48qzQO/Gz4lQX8XMhv4RuLKiaeKEj/G2lN7tWT4PEo+pDZ7FLwABENi CZTfy7xE7/7xmDnt2O2NEhG0+qlDXjldIQ4uuUAFEia2eQ==
S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN NSEC3 1 1 0 - S84CDVS9VPREADFD6KK7PDADH0M6IO8H NS DS RRSIG
S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN RRSIG NSEC3 8 2 86400 20200603044553 20200527033553 39844 com. HsP3w9+t2VkMhtbIPXbZIodkSYKGnhaGahxdKz1oF3tYiHF80j/rZKQJ pbdDpHdQJ4ucc4IzUs2+Hfs9vJLZjLwGzt7LvWyq0hEfpPElWnkf+St8 Mf/vqhr99ji17WQR9LHoPympEdod4+FUOC25eITgKfK+KXXYCzs1sWs4 KbguhA6wV2YCZp0oUeQb2h+kDb9OqucJzdgtJnlcuOUVxA==
;; Received 836 bytes from 192.41.162.30#53(l.gtld-servers.net) in 88 ms
google.com. 300 IN A 172.217.17.110
;; Received 55 bytes from 216.239.38.10#53(ns4.google.com) in 16 ms
dig @1.1.1.1 google.com +trace 0,01s user 0,02s system 0% cpu 4,214 total
答案1
4s 来自 bash time 实用程序。它报告 dig 二进制文件的总运行时间。
12ms、68ms……是挖掘本身报告的时间。 dig 的文档有点稀疏(这可能是你来到这里的原因),但这很可能是请求的纯粹运行时。围绕这些,dig 做了其他一些事情,导致总运行时间为 4 秒。
有关更多详细信息和确认,我们可以查看源代码。在https://gitlab.isc.org/isc-projects/bind9/-/blob/master/bin/dig/dig.c#L387,我们可以看到单个请求的打印时间是两个时间戳(query->time_recv 和 query->time_sent)之间的差异。它们设置在哪里?这有点复杂。在https://gitlab.isc.org/isc-projects/bind9/-/blob/master/bin/dig/dighost.c#L2949,query->time_sent 已设置。在recv_done()中,设置了query->time_recv。然而,recv_done() 被事件作为回调调用:在第 2941 行,recv_done() 作为回调传递给 isc_socket_recv()。这是从第 2954 行触发的。
此部分之前或之后发生的所有事情都计入 4 秒,但不计入各个查询时间。这将是像启动线程这样的一般事情,这需要非常长的时间。粗略地检查 dig.c 和https://gitlab.isc.org/isc-projects/bind9/-/blob/master/lib/isc/app.c#L194似乎表明 dig 建立了相当多的基础设施,显然是用于绑定框架中的工具的标准应用程序基础设施。这包括事件处理、任务(可能用于并发)。这也需要一些时间。
下一步可能是获取 dig 的调试版本并对其进行分析。但首先:你为什么需要知道?这种差异是始终存在还是仅针对某些主机/某些机器? (我的机器上也发现了差异,但只有 2-3 倍左右,而不是您看到的 20 倍左右。)
答案2
这些是 ISC 确认的 DNS 查找这篇文章来自 ISC.org。您自己的 DNS 延迟也有影响(如果没有缓存)。