未來已來，只是不均衡地分佈在當下
大家好，我是菜農，歡迎來到我的頻道。
都說程式設計師是面向Google程式設計，殊不知當你輸入 www.google.com 地址的時候，是否有想過，在回車的一瞬間瀏覽器如何將請求傳送，如何到達目的地為你取得正確的資料。遇到問題我們通常會開啟瀏覽器，輸入 www.google.com 回車，然後搜尋我們的問題，獲取到我們想要的內容後，我們又會心滿意足的關閉瀏覽器。
而在這一個請求的過程中，瀏覽器內部發生了什麼？
我們也許會在某個不經意間發現，輸入 142.251.43.14 這串 IP 也能夠訪問Google網站，而為了讓人覺得高大上一點，你改掉了輸入 google.com 的 "臭毛病"， 而是每次都會在瀏覽器輸入這串IP，畢竟在回車之前別人總是難以琢磨你要訪問的是哪個網站，除非遇到 "志同道合" 的人。
一開始你使用得不亦樂乎，畢竟敲入這串 IP 也能夠熟能生巧，使用速度也不減當年，但某一天你跟往常一樣輸入這串IP 的時候發現怎樣都訪問不到網站了，你開始急了，並尋找問題，懷疑自己的記憶力是否出現了問題，亦或是網站出現了問題，折騰半天后，發現是 Google 網站的 IP 發生了變化，而等待你的就只有兩條路，一是繼續背下新的 IP 地址，但難保某一天又面臨不能訪問的情況，二是迴歸從前，老老實實訪問 google.com 。最終你醒悟了，終於發現背誦 IP 進行日常訪問真是個 "有病" 的行為。
那麼為什麼 www.google.com 能夠透過 142.251.43.14 進行訪問？這裡我們先記住兩個名詞，一個是域名，一個是 IP，www.google.com 是一個域名，而 142.251.43.14 則是一個 IP。概念：域名可以對應有多個 IP 地址。
怎麼理解？很簡單，開啟你的手機通訊錄，可以看到 富婆 就是一個 "域名" 的概念，而具體的電話號碼就可以對應上 "IP"
我們想要給一個人打電話，我們可以輸入富婆，也可以輸入具體的電話號碼，當然富婆的記憶點低，而電話號碼的記憶點高，而為什麼與遇到上面所說的一點時間後再次訪問 IP 就訪問不到網站了，這種情況你可以想象成，富婆換電話了 ~
那麼回到我們的內容，將域名解析為 IP 的這個過程就是 DNS（Domain Name System） 域名系統。
DNS 產生背景
Internet 將數量眾多的主機連線在一起，要讓這些主機能夠進行通訊，就需要有一套名字標識體系，讓主機之間能夠彼此找到對方。實際上，在 Internet 上有多種方式可以進行主機標識，既可以用主機名（域名）標識，也可以使用IP地址進行標識。主機在網際網路上的位置主要靠 IP 地址進行標識，每個 IP 地址都由 4 個位元組組成，有這嚴格的層次結構，以便路由器進行識別和處理。但這種純數字的標識方式對於人類的記憶來說簡直是個噩夢，因此提出了主機名的標識方式，就是上述說到的 www.google.com ，這種名字的好處很直接，就是便於記憶。但是對於喜歡 0 和 1 的計算機來說，肯定更喜歡 IP 的表達方式，因此就出現了計算機喜歡 IP 地址，人喜歡主機名的對立情況，那麼就需要一個介面卡 來完成兩者之間的轉換，這就是主機名與IP地址的對映關係。
在DNS之初，整個網路中只有幾百臺的主機，所有的主機資訊以及主機名與地址的對映記錄都存放在一個名為 HOST.TXT 的檔案中。 HOST.TXT 從一臺名為 SRI-NIC 的主機上分發到整個網路，而維護對映記錄的方式也很粗暴，透過將變更資訊以電子郵件的方式告知管理員，然後進行定期 FTP 到 SRI-NIC 上，獲得最新的 HOST.TXT 檔案。
但這種方式長期來看肯定是不合實際的，網際網路飛速發展，主機的數量日益暴增，存在問題：
- 無法進行分散管理
- 無法及時全網更新與同步
- 維護困難
為了解決以上問題，1984年，南加州大學資訊科學所的 PaulMockaprtris 釋出了描述 DNS 的 RFC 882 和RFC 883的規範，簡單來說就是 DNS 誕生了。
DNS 工作原理
DNS 實際上是一個應用層協議，但它通常被其他的應用層協議所使用，用於將使用者提供的主機名解析為 IP 地址。
當我們在瀏覽器的位址列上輸入 www.google.com 這樣一個 URL時，實際上我們想要瀏覽的網頁內容都存放在網際網路中的某臺伺服器上，而瀏覽器的任務就是找到我們想要訪問的這臺伺服器的 IP 地址，然後向它請求內容，而這一整個過程就是 DNS 工作的內容。
如圖所示，DNS 地址解析服務是在 HTTP 連線建立之前的一個過程。從使用者主機上呼叫應用程式的角度來看，DNS是一個提供簡單、直接的轉換服務的黑盒子，但實際上 DNS 服務系統運轉相當複雜，由分佈於全球的大量 DNS 伺服器以及相關應用層協議共同組成。
域名結構
整個網際網路中的域名空間結構就像是一棵倒置的樹
我們試著將一個 Google 的域名進行拆分，www.google.com
我們驚奇的發現，之前看似簡單的一段域名居然由這麼多部分構成。既然上部分說到，域名空間結構就像是一棵倒置的樹，那麼我們就手動梳理下這棵樹的結構。
每個頂級域由對應的頂級域（TLD）伺服器負責管理，除了以下 7 個頂級域名，還有各個國家的頂級域名（cn、uk、ca和 fr 等）也在這一級別進行管理。
每個頂級域再向下展開分支，每個分支域都是一個子域，比如 google.com 是 com 的子域，而 google.com 也可再包含子域，比如 a.google.com、b.google.com。一個域就是域名空間中的一棵子樹，域的名字也就是這棵子樹的頂端節點的域名。
拆分原理
DNS 承載的流量是全球的流量，那麼將結構設計為層次結構的原因也很簡單，那就是分佈承擔流量
在每個域中，會有一臺或多臺伺服器用來儲存這個域名空間的所有資訊，並且響應關於該域名空間的所有請求，這種伺服器就叫做這個域的 權威域名伺服器（授權域名伺服器） 。它擁有這個域的所有的域名資訊，每個域都可以分為多個子域，而每個權威域名伺服器可以個一個或多個區域進行解析。
google.com 可以被劃分為三個子域，a.google.com、b.google.com和 c.google.com。每個子域都可以自行維護自己的權威域名伺服器，一個域可以有多臺權威域名伺服器，但是隻有一臺是主域名伺服器，這臺主域名伺服器負責向其他輔域名伺服器分發每個域名空間的更新資訊。簡單理解，域名空間就相當於是一個 小叢集
當一個子域被授權出去後，它原本所屬的域就不再包含它的資料，而只留下一些指標，這些指標指向相應子域的授權域名伺服器。如果有一個請求來詢問該子域的資訊，那麼所返回的應該是該子域權威伺服器的列表。
因此，DNS 伺服器層由：根 DNS 伺服器、頂級域名（TLD）伺服器和權威DNS伺服器共同組成 ，共同維護分散式、層次化的DNS資料庫。DNS系統採用樹形設計的一個主要目的就是為了分撒管理，而這種分散管理是透過 授權 來實現的。對域進行授權，就是域管理組織把子域授權給其他組織進行管理，由子域管理者來維護子域中的資料，可以自由改動資料，包括對子域的再次劃分和授權。
在 DNS 系統中還有一類非常重要的域名伺服器，叫做 本地DNS伺服器（LDNS），是使用者所在區域網或 ISP 網路中 的域名伺服器，本地 DNS 伺服器地址是客戶端網路配置的一部分，或者透過 DHCP 方式分配給客戶端。
針對DNS的分佈查詢原理如下:
瀏覽器發出的請求會先傳送到本地DNS伺服器，本地DNS伺服器收到瀏覽器的域名解析請求後，會採用遞迴的方式向 DNS 系統中的其他遠端域名伺服器提出查詢請求。（遞迴方式指每次查詢請求都由本地DNS伺服器發起，收到答覆後再向下一個遠端DNS伺服器提出請求，直到獲得結果。迭代查詢指本地DNS伺服器只將自己知道的最合適的答案返回給查詢者，幫助它把查詢過程繼續下去，而它本身不再做其他任何查詢）
過程： 本地DNS伺服器首先會去根DNS伺服器請求解析（此時條件是本地DNS伺服器並沒有關於這個域名的快取），根域名伺服器中雖然沒有www.google.com這條記錄的，但它可以知道這個URL屬於com 域，於是就找到com域伺服器的IP地址，然後訪問com域伺服器，重複上面的操作，再找到放了google 域的伺服器是哪個，繼續往下，直到找到www.google.com的那條記錄，最後返回對應的IP地址。
快取原理
頻繁使用 DNS 查詢會給使用它的網際網路應用帶來額外的時延，而時延本身不能確定，有可能大有可能小。那麼為了解決這個問題就需要引入 快取 機制。快取是指 DNS 查詢結果在主機中的快取，有了快取就不需要在每次查詢的時候都經過複雜的遞迴過程。當然 DNS 資料有可能過期，因此 DNS 伺服器不能把資料永遠的存放在快取中，管理員會為這些資料設定一個生存期（TTL）。超過 TTL 時間的資料會被清除，重新向 DNS 伺服器進行查詢。
除了DNS伺服器能夠快取 DNS 響應資訊之外，客戶端瀏覽器也可以快取 DNS 響應資訊，當使用者請求頁面域名解析結果在瀏覽器自身的DNS快取彙總能夠查到時，就不會向DNS伺服器發起請求了，這樣可以加快瀏覽網頁的速度。當訊息記錄時間超過瀏覽器設定的 DNS 快取時間時，會重新向DNS伺服器發起域名解析請求，用新的解析結果更新快取。
記錄型別與報文格式
域名伺服器是根據資源記錄來對 DNS 請求進行應答的。在 DNS 系統中，最常見的資源記錄是 Internet 類記錄，資源記錄是一個包含了下列欄位的 4 元組：
- Name
- Value
- Type
- TTL
其中，TTL 是該記錄的生存時間，它決定了資源記錄應當從快取中刪除的時間。Name 和 Value 的值取決於 Type，即記錄型別。而記錄型別分為以下幾類：
我這裡附上一張阿里雲的域名解析配置圖，先有一個大致的概念
- A / AAAA：Address
A 記錄用於描述域名到 IP 地址的對映關係，對同一個域名可以有多條 A 記錄，也就是說一次DNS查詢可以返回多個地址。
- CNAME
CNAME 記錄用於描述別名與域名的對應關係，這種記錄允許你將多個名字對映到同一臺計算機。比如我們有個域名是 cbuc.com，那我可以新增一條 www.cbuc.com 的 CNAME記錄，以便請求 www.cbuc.com 時也能夠訪問到 cbuc.com 。查詢過程也是透過 www.cbuc.com 找到 cbuc.com ，繼而找到對應的 IP 地址，這裡不再贅訴。
- NS：Name Server
NS 記錄是域名伺服器記錄，用於指定該域名由哪個 DNS 伺服器來進行解析。每個區域可以有多個域名伺服器，因此可以有多條NS記錄。
- SOA：Start Of Authority
SOA 記錄用於指定該區域的權威域名伺服器。每個區域允許切只允許有一個 SOA 記錄，它是資源記錄的第一個條目。
- PTR：Pointor Record
PTR 記錄用於描述IP地址到域名的對映關係
DNS 總結
DNS是域名系統的簡稱，它是一種用於將域名和IP地址相互對映的協議。簡單地說，它是一種用於將人類可讀的域名（例如www.google.com）轉換為瀏覽器可以理解的IP地址（例如 142.251.43.14）的方法。這樣，使用者就可以透過輸入域名來訪問網站，而無需記住網站的IP地址。
DNS的設計原理是使用分層的系統將域名和IP地址相互對映。主要包括以下三個部分：
- 域名伺服器（DNS伺服器）：DNS伺服器是網路中的一種特殊伺服器，它儲存了域名和IP地址的對映關係。當使用者訪問一個網站時，瀏覽器會向DNS伺服器發出請求，DNS伺服器則會返回該網站的IP地址。
- 域名系統域（DNS域名空間）：DNS域是用於組織DNS伺服器的層次結構。它以樹型結構組織DNS伺服器，使得每個伺服器都有一個唯一的名稱，這樣就可以方便地查詢到指定的DNS伺服器。
- 域名系統資料庫（DNS資料庫）：DNS資料庫是用於儲存域名和IP地址對映關係的資料庫。它包含了所有域名和IP地址的對映關係，以便DNS伺服器可以根據使用者的請求返回正確的IP地址。
簡而言之，當使用者訪問一個網站時，瀏覽器會向DNS伺服器發出請求，DNS伺服器會查詢DNS資料庫，並根據域名和IP地址的對映關係返回正確的IP地址
DNS系統的設計具有以下幾個亮點：
- 可擴充套件性：DNS系統的分層結構允許新增新的DNS伺服器，從而支援更多的域名和IP地址。
- 可靠性：DNS系統可以透過多臺DNS伺服器進行冗餘儲存，從而提高系統的可靠性。
- 靈活性：DNS系統允許使用者隨時修改域名和IP地址的對映關係，從而使網路更加靈活。
- 可維護性：DNS系統可以使用快取技術，從而減少DNS資料庫的查詢次數，降低系統的維護成本。
好了，以上便是本篇的所有內容，如果覺得對你有幫助的小夥伴不妨點個關注做個伴，便是對小菜最大的支援。不要空談，不要貪懶，和小菜一起做個吹著牛X做架構的程式猿吧~ 我們們下文再見！
今天的你多努力一點，明天的你就能少說一句求人的話！
我是小菜，一個和你一起變強的男人。
?微信公眾號已開啟，菜農曰，沒關注的同學們記得關注哦！