国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

18143453325 或 在線咨詢 在線咨詢
18143453325 或 在線咨詢
所在位置： 首頁 > 營銷資訊 > 建站知識 > 全面理解 DNS 及 HTTPDNS

全面理解 DNS 及 HTTPDNS

時間：2023-02-02 03:20:02 | 來源：建站知識

時間：2023-02-02 03:20:02 來源：建站知識

移動場景下DNS解析開銷是整個網(wǎng)絡請求中不可忽略的一部分。在弱網(wǎng)環(huán)境下，基于UDP的LocalDNS解析非常容易出現(xiàn)解析超時的問題，并且即使解析成功會消耗數(shù)百毫秒乃至更甚，對我們整個業(yè)務請求而言是非常不利的，它直接影響了客戶的體驗。

對于一個比較大眾的應用而言，DNS的優(yōu)化對整個應用的網(wǎng)絡優(yōu)化所占的權(quán)重是很大的。我們接下來從以下幾個方面全面理解DNS，相信對我們開發(fā)中的網(wǎng)絡優(yōu)化會有不小的幫助。

1. DNS

1.1 認識DNS

DNS(Domain Name System)是域名“系統(tǒng)”的英文縮寫，是一種組織成域?qū)哟谓Y(jié)構(gòu)的計算機和網(wǎng)絡服務命名系統(tǒng)，它用于TCP/IP網(wǎng)絡，它所提供的服務是用來將主機名和域名轉(zhuǎn)換為IP地址的工作。

作為網(wǎng)絡通信的最靠前的一個環(huán)節(jié)，其在整個網(wǎng)絡通信的過程中的重要性不言而喻。







ios10之后，apple提供的原生http請求方法能返回http請求各個階段的時間指標，其中就包含DNS解析時間。







1.2 DNS解析相關概念

1.2.1 DNS域名層次結(jié)構(gòu)

DNS是一種分層結(jié)構(gòu)，在整個互聯(lián)網(wǎng)中組成一個樹狀系統(tǒng)，頂層是系統(tǒng)的根域名，下層為TLD以及二級域名，葉子就構(gòu)成了所謂的FQDN（Fully Qualified Domain Names），根域名通常使用"."來表示，其實際上也是由域名組成，全世界目前有13組域名根節(jié)點，由少數(shù)幾個國家進行管理，而國內(nèi)僅有幾臺根節(jié)點鏡像。







1.2.2 權(quán)威DNS

權(quán)威DNS是經(jīng)過上一級授權(quán)對域名進行解析的服務器，同時它可以把解析授權(quán)轉(zhuǎn)授給其他人，如COM頂級服務器可以授權(quán)xxorg.com這個域名的的權(quán)威服務器為NS.ABC.COM，同時NS.ABC.COM還可以把授權(quán)轉(zhuǎn)授給NS.DDD.COM，這樣NS.DDD.COM就成了ABC.COM實際上的權(quán)威服務器了。平時我們解析域名的結(jié)果都源自權(quán)威DNS。eg: 阿里云云解析 [https://wanwang.aliyun.com/domain/dns](https://wanwang.aliyun.com/domain/dns)

1.2.3 遞歸DNS

遞歸DNS又稱為Local DNS，它沒有域名解析結(jié)果的決定權(quán)，但代理了用戶向權(quán)威DNS獲取域名解析結(jié)果的過程。遞歸DNS上有緩存模塊，當目標域名存在緩存解析結(jié)果并且TTL未過期時（每個域名都有TTL時間，即有效生存時間，若域名解析結(jié)果緩存的時間超過TTL，需要重新向權(quán)威DNS獲取解析結(jié)果），遞歸DNS會返回緩存結(jié)果，否則，遞歸DNS會一級一級地查詢各個層級域名的權(quán)威DNS直至獲取最終完整域名的解析結(jié)果。eg: 我們自己的電腦，運營商提供的dns服務器等等。

1.2.4 公共DNS

公共DNS是遞歸DNS的一種特例，它是一種全網(wǎng)開放的遞歸DNS服務，而傳統(tǒng)的遞歸DNS信息一般由運營商分發(fā)給用戶。

在 DNS 的解析過程中，用戶向遞歸 DNS 發(fā)起請求，遞歸 DNS 向權(quán)威 DNS 請求解析結(jié)果，可以說遞歸 DNS 起到一種轉(zhuǎn)發(fā)的作用。ISP DNS 就是遞歸 DNS；同時一些個人或互聯(lián)網(wǎng)服務提供商也會架設自己的遞歸 DNS 開放給所有人使用，稱為公共 DNS。

運營商anycast官網(wǎng)DNS
全國DNS匯總: http://www.114dns.com/DNS_List.ht… ipip: http://tools.ipip.net/dns.php







1.2.5 轉(zhuǎn)發(fā)DNS

可以理解為遞歸DNS和用戶之間的一個中轉(zhuǎn)站，它不提供直接解析域名的服務，它將請求轉(zhuǎn)發(fā)給遞歸DNS，然后將遞歸DNS的結(jié)果轉(zhuǎn)發(fā)一下，也提供緩存作用。比如，日常家用的路由器，它的DNS服務器一般都是192.168.1.1，只是轉(zhuǎn)發(fā)給遞歸DNS。

如果您正在學習Spring Boot，推薦一個連載多年還在繼續(xù)更新的免費教程：http://blog.didispace.com/spring-boot-learning-2x/

1.3 域名解析記錄方式

域名解析記錄主要分為A記錄、MIX記錄、CNAME記錄、NS記錄和TXT記錄：

1.4 域名解析過程







以下是在終端中dig百度顯示的具體過程：

macdeiMac:~ ethan$ dig +trace www.baidu.com; <<>> DiG 9.10.6 <<>> +trace www.baidu.com;; global options: +cmd. 1615 IN NS a.root-servers.net.. 1615 IN NS g.root-servers.net.. 1615 IN NS f.root-servers.net.. 1615 IN NS l.root-servers.net.. 1615 IN NS m.root-servers.net.. 1615 IN NS j.root-servers.net.. 1615 IN NS k.root-servers.net.. 1615 IN NS c.root-servers.net.. 1615 IN NS b.root-servers.net.. 1615 IN NS d.root-servers.net.. 1615 IN NS i.root-servers.net.. 1615 IN NS e.root-servers.net.. 1615 IN NS h.root-servers.net.;; Received 239 bytes from 114.114.114.114#53(114.114.114.114) in 10 mscom. 172800 IN NS a.gtld-servers.net.com. 172800 IN NS b.gtld-servers.net.com. 172800 IN NS c.gtld-servers.net.com. 172800 IN NS d.gtld-servers.net.com. 172800 IN NS e.gtld-servers.net.com. 172800 IN NS f.gtld-servers.net.com. 172800 IN NS g.gtld-servers.net.com. 172800 IN NS h.gtld-servers.net.com. 172800 IN NS i.gtld-servers.net.com. 172800 IN NS j.gtld-servers.net.com. 172800 IN NS k.gtld-servers.net.com. 172800 IN NS l.gtld-servers.net.com. 172800 IN NS m.gtld-servers.net.com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766com. 86400 IN RRSIG DS 8 1 86400 20191112050000 20191030040000 22545 . Sr1g7h+DSqi+ekBQQS2ZBc/jt0zL+IR+Od/R9TnMjcy8Mw9RxLrMY2pm 1VYNqL5cAME1stSAfRUKwjD/vixnCeVLoJ6idCFOZeB+t/tTFQF/jfk1 td66pW9V/WgLIvslAwEZjidVeUFYERc7hZXr10BgzryZthizHISimuiQ qBjoIQN/uYULTnmePkIW07mnJXc9/AVZrjeI1AmvYC7wE0uR7DWNg1Ig dL4DaLDOM30qN7FBAD7K091uEgctpdxd/8G5XoYclSqroN4G6RibvkWT /vPCFRUzoaxembT5tR7gIz7gxdhN1r8NBD468JTG180MNUvb16Z/87U6 7UkMrg==;; Received 1173 bytes from 192.58.128.30#53(j.root-servers.net) in 77 msbaidu.com. 172800 IN NS ns2.baidu.com.baidu.com. 172800 IN NS ns3.baidu.com.baidu.com. 172800 IN NS ns4.baidu.com.baidu.com. 172800 IN NS ns1.baidu.com.baidu.com. 172800 IN NS ns7.baidu.com.CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAMCK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20191103044815 20191027033815 12163 com. U/FwNWeuKzR/uT2X/8Cf9TQmnaMdWf6XwBrFIIOCQ/kfKaOExEiT8LSQ 13OaEjtvFOOlIPK0XIbsL+dgGPYb/UV6sipBeQ1n8KuK18m3bYk47Ely oe+3VVp0zaiXt9DZrmRRenBB13o0DPqCbRHAHq1pj5zG5VkMufu9L/TT g80XlNukAMcu4GrV4VP8OimOQxz7HJbadci2oYn3beiHqQ==HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN NSEC3 1 1 0 - HPVVN3Q5E5GOQP2QFE2LEM4SVB9C0SJ6 NS DS RRSIGHPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN RRSIG NSEC3 8 2 86400 20191105055359 20191029034359 12163 com. J5Dq0lGkcejjg1vPqWDBvNYaAhqFF3Ck8trKj4tgW5Z1bmoXsHGU6/Cl y3GlLfzb49xjiXzxVLCuAQJ9uLuKSX5cn+kesc8rwYqcVXU4nXbD5jzo u3CK2yHD3FqPDCOKlMSNy3KKkL03bB3DfmvAae/qQs7xSe6VTpCkR6v/ lo3UA/pMfTYBjSIOvR2KmpM9yFLmN5LXAQW3rNH8sW91BA==;; Received 761 bytes from 192.26.92.30#53(c.gtld-servers.net) in 241 mswww.baidu.com. 1200 IN CNAME www.a.shifen.com.a.shifen.com. 1200 IN NS ns2.a.shifen.com.a.shifen.com. 1200 IN NS ns3.a.shifen.com.a.shifen.com. 1200 IN NS ns4.a.shifen.com.a.shifen.com. 1200 IN NS ns5.a.shifen.com.a.shifen.com. 1200 IN NS ns1.a.shifen.com.;; Received 239 bytes from 180.76.76.92#53(http://ns7.baidu.com) in 10 ms

通過上面命令我們可以看到DNS解析的逐步過程，其中最后一步我們可以看到http://www.baidu.com 被CNAME到 http://www.a.shifen.com 所以我們再查一下 http://www.a.shifen.com 即可看到其ip.

;; Received 215 bytes from 220.181.33.31#53(ns2.baidu.com) in 28 mswww.a.shifen.com. 300 IN A 180.101.49.12www.a.shifen.com. 300 IN A 180.101.49.11a.shifen.com. 1200 IN NS ns4.a.shifen.com.a.shifen.com. 1200 IN NS ns5.a.shifen.com.a.shifen.com. 1200 IN NS ns1.a.shifen.com.a.shifen.com. 1200 IN NS ns2.a.shifen.com.a.shifen.com. 1200 IN NS ns3.a.shifen.com.;; Received 236 bytes from 180.76.76.95#53(ns5.a.shifen.com) in 9 ms然后我們再用nslookup命令查看一下百度的ip是不是上面顯示的兩個:

macdeiMac:~ ethan$ nslookup www.baidu.comServer: 114.114.114.114Address: 114.114.114.114#53Non-authoritative answer:www.baidu.com canonical name = www.a.shifen.com.Name: www.a.shifen.comAddress: 180.101.49.11Name: www.a.shifen.comAddress: 180.101.49.12圖示DNS解析baidu的過程：

  1. 終端向 Local DNS發(fā)起域名解析請求
  2. Local DNS在獲取到域名請求后，首先從Root hins獲取根域名服務器的地址(Root hints包含了互聯(lián)網(wǎng)DNS根服務器的地址信息)
  3. 獲取到了根域名服務器地址后，Local DNS向根域名服務器發(fā)起DNS解析請求，根域名服務器返回頂級域名服務器地址(com或者cn或者其它)
  4. 隨后Local DNS向com域名服務器發(fā)起解析請求，并得到http://baidu.com二級域名服務器地址
  5. Local DNS向http://baidu.com二級域名服務器發(fā)起解析請求，并最終貨到了http://www.baidu.com 的ip地址信息
  6. Local DNS將遞歸查詢獲得的IP地址信息緩存并返回給客戶端

3. 全局負載均衡GSLB

GSLB是Global Server load Blance的縮寫，即全局負載均衡。目的是實現(xiàn)互聯(lián)網(wǎng)上不同地域的服務器間的流量調(diào)配，保證使用戶的請求能被離用戶最近或者服務質(zhì)量更好的服務器來處理。從而確保服務質(zhì)量。

能通過判斷服務器的負載，包括CPU占用、帶寬占用等數(shù)據(jù)，決定服務器的可用性，同時能判斷用戶（訪問者）與服務器間的鏈路狀況，選擇鏈路狀況最好的服務器。因此GSLB是對服務器和鏈路進行綜合判斷來決定由哪個地點的服務器來提供服務，實現(xiàn)異地服務器群服務質(zhì)量的保證。







3.1 智能DNS

智能DNS是GSLB的一種應用。







2. DNS解析存在的問題

有時候我們在訪問百度或者在應用中發(fā)出一個http請求時，如果DNS解析被劫持，我們可能最終訪問到的不是我們想要訪問的服務器。

2.1 運營商劫持

DNS劫持 就是通過劫持了 DNS 服務器，通過某些手段取得某域名的解析記錄控制權(quán)，進而修改此域名的解析結(jié)果，導致對該域名的訪問由原 IP 地址轉(zhuǎn)入到修改后的指定 IP，其結(jié)果就是對特定的網(wǎng)址不能訪問或訪問的是假網(wǎng)址，從而實現(xiàn)竊取資料或者破壞原有正常服務的目的。







2.2 DNS解析域名時緩存解析結(jié)果

我們在開發(fā)中有時候會遇到這樣的情況：你是一個聯(lián)通用戶，你在手機瀏覽器中輸入http://baidu.com，由一個LocalDNS服務器像百度權(quán)威服務器查應該訪問哪一臺服務器，權(quán)威把結(jié)果返回給LocalDNS服務器,localDNS服務器返回結(jié)果給用戶。

如果當LocalDNS緩存的有http://baidu.com對應的結(jié)果，那么他就不會像百度的權(quán)威服務器查詢其對應的ip，而是直接返回緩存中的結(jié)果。如果此時權(quán)威服務器中的http://baidu.com對應的ip發(fā)生了變化，LocalDNS沒有及時更新，這樣會導致用戶訪問不到服務器。







2.3 轉(zhuǎn)發(fā)解析

你用手機訪問http://baidu.com時，會到當前運營商的DNS服務器查，然后運營商的DNS服務再去百度權(quán)威服務器去查，最終把權(quán)威服務器中的正確ip返回。

上面是正常的情況，但是如果當前運營商(比如聯(lián)通)的LocalDNS不訪問百度權(quán)威DNS服務器，而是直接訪問了其它運營商(比如電信)的LocalDNS服務器，有些小的運營商就是通過這樣做來降低成本。如果電信的LocalDNS對非自家ip的訪問限了速那么很明顯會影響你的DNS解析時間。如果你應用中的某些服務需要運營商信息isp(eg:只能dns, cdn等服務).

下面截圖是我手機的網(wǎng)路環(huán)境(NetPing開源地址：http://github.com/mediaios/ne…)







我直接ping百度的地址，然后用wireshark抓包結(jié)果，正常結(jié)果如下：







如果發(fā)生了轉(zhuǎn)發(fā)則邏輯如下：







另外，如果您正在學習Spring Cloud，推薦一個連載多年還在繼續(xù)更新的免費教程：https://blog.didispace.com/spring-cloud-learning/

3. HTTPDNS

3.1 什么是HTTPDNS

HTTPDNS使用HTTP與DNS服務器交互，代替?zhèn)鹘y(tǒng)的基于UDP的DNS協(xié)議，域名解析請求直接發(fā)送到HTTPDNS服務端，從而繞過運營商的Local DNS













3.2 HTTPDNS的特性

3.2.1 防止域名劫持

由于 HttpDns 是通過 IP 直接請求 HTTP 獲取服務器 A 記錄地址，不存在向本地運營商詢問 domain 解析過程，所以從根本避免了劫持問題。

3.2.2 精準調(diào)度

HTTPDNS能夠直接獲取到用戶的IP地址，從而實現(xiàn)精確定位與導流

3.2.3 用戶連接失敗率下降

通過算法降低以往失敗率過高的服務器排序，通過時間近期訪問過的數(shù)據(jù)提高服務器排序，通過歷史訪問成功記錄提高服務器排序。

原來的請求地址為 “http://apis.juhe.cn/simpleWeath…”，通過HTTPDNS替換域名后最終的結(jié)果如下：













3.2 HTTPS IP Content

發(fā)送HTTPS請求首先要進行SSL/TLS握手，握手過程大致如下：

  1. 客戶端發(fā)起握手請求，攜帶隨機數(shù)、支持算法列表等參數(shù)。
  2. 服務端收到請求，選擇合適的算法，下發(fā)公鑰證書和隨機數(shù)。
  3. 客戶端對服務端證書進行校驗，并發(fā)送隨機數(shù)信息，該信息使用公鑰加密。
  4. 服務端通過私鑰獲取隨機數(shù)信息。
  5. 雙方根據(jù)以上交互的信息生成session ticket，用作該連接后續(xù)數(shù)據(jù)傳輸?shù)募用苊荑€。
上述過程中，和HTTPDNS有關的是第3步，客戶端需要驗證服務端下發(fā)的證書，驗證過程有以下兩個要點：

  1. 客戶端用本地保存的根證書解開證書鏈，確認服務端下發(fā)的證書是由可信任的機構(gòu)頒發(fā)的。
  2. 客戶端需要檢查證書的domain域和擴展域，看是否包含本次請求的host。
如果上述兩點都校驗通過，就證明當前的服務端是可信任的，否則就是不可信任，應當中斷當前連接。

當客戶端使用HTTPDNS解析域名時，請求URL中的host會被替換成HTTPDNS解析出來的IP，所以在證書驗證的第2步，會出現(xiàn)domain不匹配的情況，導致SSL/TLS握手不成功。

4.問題

4.1 主機是如何知道DNS服務器地的IP地址的？

通過DHCP動態(tài)獲得，或者手工配置的。

DHCP協(xié)議：DHCP（Dynamic Host Configuration Protocol，動態(tài)主機配置協(xié)議）通常被應用在大型的局域網(wǎng)絡環(huán)境中，主要作用是集中的管理、分配IP地址，使網(wǎng)絡環(huán)境中的主機動態(tài)的獲得IP地址、Gateway地址、DNS服務器地址等信息，并能夠提升地址的使用率。

4.1 為什么DNS采用UDP協(xié)議 ？

TCP通信過程太復雜并且開銷大，一次TCP交換需要9個包：三個連接包，四個斷開包，一個request包，一個響應包。

UDP通信過程簡單，只需要一個查詢包和一個響應包。

關鍵詞：理解

74
73
25
news

版權(quán)所有? 億企邦 1997-2025 保留一切法律許可權(quán)利。

為了最佳展示效果，本站不支持IE9及以下版本的瀏覽器，建議您使用谷歌Chrome瀏覽器。 點擊下載Chrome瀏覽器
關閉