☰

발굴 +추적을 완료하는 데 몇 초가 걸리는 이유는 무엇입니까?

tag-icon • tag-icon dns dig
발굴 +추적을 완료하는 데 몇 초가 걸리는 이유는 무엇입니까?

다음 dig 명령에 대한 DNS 쿼리의 합계는 완료하는 데 200밀리초 미만이 걸리지만 전체 명령은 4초 이상 걸립니다. 발굴 + 추적이 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

bash 시간 유틸리티의 4초입니다. 발굴 바이너리의 총 실행 시간을 보고합니다.

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#L194dig가 상당히 많은 인프라, 즉 프레임워크에 도구를 바인딩하기 위한 표준 애플리케이션 인프라를 설정했음을 나타내는 것 같습니다. 여기에는 이벤트 처리, 작업(동시성 가능)이 포함됩니다. 이것도 시간이 좀 걸립니다.

다음 단계는 디버그 버전의 dig를 구해 분석하는 것일 수 있습니다. 하지만 먼저, 왜 알아야 할까요? 이 차이는 항상 존재합니까, 아니면 특정 호스트/특정 시스템에만 존재합니까? (내 컴퓨터에서도 차이를 보았지만 20배 정도는 아니고 약 2-3배 정도였습니다.)

답변2

ISC에서 확인한 DNS 조회입니다.이 기사는 ISC.org에서 가져온 것입니다.. 자체 DNS 대기 시간도 중요한 역할을 합니다(캐싱되지 않은 경우).

관련 정보