一文入門DNS？從訪問GitHub開始
前言
大家都是做開發的，都有GitHub的賬號，在日常使用中肯定會遇到這種情況，在不修改任何配置的情況下，有時可以正常訪問GitHub，有時又直接未響應，來一起捋捋到底是為啥。
GitHub訪問的千層套路
以我家里的電腦為例，在不修改任何配置，不啟用什么代理工具的情況下，訪問GitHub會得到以下結果：
?
?
雖然很戳心，但好歹能展示一部分。
從網上搜了一堆亂七八糟的攻略，知道了可以通過修改電腦的Hosts文件達到正常訪問的能力，于是胡搜了一通，
步驟：百度經驗
效果如下：
?
?
訪問效果依然很感人，最近活動數據不顯示，整個界面加載都快接近2分鐘了，有什么辦法沒有咧~
站長工具 PING PING PING
都是搞開發的，都會用F12看看網絡或者資源請求的地址是什么，以上面耗時最慢的地址為例，域名為：github.githubassets.com
打開站長工具的PING功能，地址為：http://ping.chinaz.com/github.githubassets.com
結果如下：
?
?
我發現 185.199.108.154 這個IP地址速度快的一批，于是立馬更換 Hosts中該域名對應的IP地址
再次訪問，效果如下：
?
?
那句話怎么說的來著?如什么什么般絲滑，我感覺這就非常絲滑~ ??
GitHub項目定時發布最新Hosts
當然了，如果每次訪問都得折騰一次，那滋味，簡直不要太難受，所以網上已經有人開源了相關的項目，會定時發布最新的 GitHub IP地址，鏈接：https://github.com/521xueweihan/GitHub520
本文撰寫時的Hosts
# github
185.199.108.154 github.githubassets.com
199.232.68.133 camo.githubusercontent.com
52.168.24.190 github.map.fastly.net
199.232.69.194 github.global.ssl.fastly.net
140.82.112.4 github.com
140.82.112.5 api.github.com
199.232.68.133 raw.githubusercontent.com
199.232.68.133 user-images.githubusercontent.com
199.232.68.133 favicons.githubusercontent.com
199.232.68.133 avatars5.githubusercontent.com
199.232.68.133 avatars4.githubusercontent.com
199.232.68.133 avatars3.githubusercontent.com
199.232.68.133 avatars2.githubusercontent.com
199.232.68.133 avatars1.githubusercontent.com
199.232.68.133 avatars0.githubusercontent.com
該項目會自動發布在指定的地址上，結合軟件使用，可以完全自動化，無需持續更新
當然也可以自行手動更改
為什么改了Hosts就能訪問GitHub
平常都是百度 + 谷歌，今天非要探究一下原理!咱們一步一步來，首先大家都需要明確一點，在網絡的世界中 域名 只是為了便于記憶和識別而存在的一個唯一地址，真正工作的仍然是 IP
Hosts文件是干嗎的
簡單來說，Hosts文件是存儲本機網址域名與其對應的IP地址的一個文件，在網絡請求階段發揮作用
為什么改了Hosts就能生效
這就涉及到了域名解析，因為Hosts文件存放的就是 域名 和 IP 的對應關系，因此它可以在域名解析階段發揮作用，為什么呢?因為在域名解析的流程中 本機Hosts 解析處于順序二
即：瀏覽器解析 -》本機解析 -》XXXX(后面的稍后再提)
所以有時候我們白嫖軟件，都會改一下 Hosts，因為需要把它在線驗證的域名指向錯誤的地址去，另外可能存在一定的瀏覽器緩存或者本機緩存，可以通過重開瀏覽器或者 PING域名來檢查更改是否生效。
DNS解析到底是什么玩意?
上文中多次提到解析，其實說的就是 DNS解析
同時上文也提到過，在網絡世界中真正發揮作用的是 IP，而一般情況下我們訪問的都是域名，為什么能實現這種效果，就是因為域名與IP地址的對應關系存儲在一個叫做 DNS(Domain Name System) 的系統里。DNS是一個全球化的分布式數據庫，它所提供的服務就是將域名轉換為互聯網IP地址。
DNS解析的全部流程
網上的關于流程的圖很多，我從中借鑒了一副，如下所示：
?
?
- 瀏覽器緩存：一次請求會首先通過瀏覽器緩存信息尋找域名映射的IP地址，這也是為什么有時候我們改了本機hosts，需要關閉再打開瀏覽器才能正常使用，如果找到則返回，沒找到則繼續到下一級
- 本機系統緩存：即上文中提到的，通過 hosts 文件來映射域名和IP，在上古時期有很多垃圾軟件會悄咪咪的修改系統的 hosts文件，達到 DNS劫持 的目的，即把淘寶域名指向另一個 IP，然后部署一個高仿的淘寶商城，靜靜等你輸入賬號，密碼，然后涼涼...
- 本地域名解析服務系統：本地域名系統LDNS一般都是本地區的域名服務器。離你的位置都比較近，Windows系統使用命令ipconfig 就可以查看，在Linux和Mac系統下，直接使用命令 cat /etc/resolv.conf 來查看LDNS服務地址。LDNS一般都緩存了大部分的域名解析的結果，大部分的解析工作到這里就差不多已經結束了
- 以下即是所謂的 遞歸解析
- 根域名解析：本地域名解析服務系統無法解析時，會向 13根 發起域名解析請求
- 說明： 所謂的 13根，指的是根域名服務器，是架構因特網所必須的基礎設施。根服務器主要用來管理互聯網的主目錄，由于DNS解析中采用的是UDP協議，僅能傳遞512字節的有效報文，因此只能構建出A-M 13個根服務器，而真正工作運行肯定不止13臺服務器，而是包含很多服務器鏡像的
- 根域名解析服務器返回 gTLD (Generic top-level domain) 給本地解析服務器，即該域名所屬的頂級域及其所在的服務器，頂級域名即如：.com .cn等等
- 本地解析服務器已知頂級域名服務器地址后，發起解析請求
- 頂級域名解析服務器返回 權限域名服務器 信息給本地解析服務器，權限域名服務器 即如：taobao.com
- 本地解析服務器已知權限域名服務器地址后，發起解析請求
- 權限域名服務器返回域名對應的IP地址給本地解析服務器
- 本地解析服務器緩存相關信息，并返回給用戶
是不是有點繞?咱們來整個圖吧，遞歸解析 如下所示：
?
?
再問一遍為什么改Hosts就可以訪問GitHub
了解了上文之后，對于這個問題就更好回答了，因為GitHub畢竟為外國的網站，咱們訪問時有一層 DNS污染，即把對應的域名指向了不可達的IP上，或者禁止訪問的IP上，因此很多時候無法使用
修改Hosts文件后即避免了DNS污染，直達目標IP，即可正常訪問了，當然了，這種方法是全部通用嗎?
答案：肯定不是，因為剛才也提到了，網關層是可以控制某些IP禁止訪問的
整一個工具來驗證一下猜想，順便看看我們的整個請求流程：
軟件名：BestTrace
??
我請求的域名是 github.githubassets.com，最終請求接收方IP和我Hosts配置的IP一致，那我換一個 facebook.com
?
?
可以看到，當請求到達 221.183.46.249 這個IP時，整個請求就被攔截下來了，因此這并不是萬能的辦法
除了訪問GitHub，還有什么時候可能用到呢?
比如下載 IDEA插件時，如果發現老是刷新不出來插件庫，或者下載失敗，就可以通過PING工具去配置最佳IP，方便下載~
DNS除了解析還能做什么智能DNS網絡請求交由域名解析服務器來處理，分配到最佳的服務器IP上
例如：請求的源頭是電信還是聯通等，如果是電信則將解析的IP分流到電信對應的IP上，或者返回距離最近的服務器IP地址
反向代理水平擴展典型的互聯網架構中，可以通過增加web-server來擴充web層的性能，但反向代理nginx仍是整個系統的唯一入口
如果系統吞吐超過nginx的性能極限，那么將難以擴容，此時就需要dns-server來配合水平擴展。
即DNS解析服務器有序的把域名解析到不同的網關層，每次DNS解析請求，輪詢返回不同的ip，這樣就能實現nginx的水平擴展，這個方法叫 “DNS輪詢”
本文轉載自微信公眾號「是Kerwin啊」，可以通過以下二維碼關注。轉載本文請聯系是Kerwin啊公眾號。
?
?
