前端優化--域名收斂

在說域名收斂之前，問大家一個問題.

為什么你手機打開時，白屏時間會這么長?

答: 網速慢唄~ 怪我咯

這當然不能怪你，確實是網速慢，但另外一方面是，如果網速已經很慢了，而你的網頁加載效率又太低~ 造成的結果就是:
go die~
一個網頁白屏時間是由下面幾部分決定的

所以，網頁的優化就可以從上述幾個部分開始. 這里我們要提及的就是DNS 優化, 即，域名收斂.

Why should we choose domain of convergence?

對于PC 上的DNS 通常情況下就是幾十ms. 因為PC可以存儲很多的域名地址,而且TTL長著呢. 但是，對于手機端來說, 由于我們良心的3G和4G網絡運營商節省開支的緣由, 一般在手機端上解析DNS 會到1s+. 所以，這樣算下來， 首屏3s的最佳時間，你就已經沒了1/3, 那還玩個屁. 不過，我們可以用很多預加載技術，比如localstorage,session,manifest等預先存儲資源. 在PC上極度推崇domian sharding時, 在手機端上，此法不見得能行得通了.
所以, 一般來說，在手機端上的域名數不能超過5個。 基本上的分配就是
html +1
css +1
img +1
js +1
fonts +1
當然，這得看具體應用場景了. 眾所周知, 我們的網頁是緊緊和TCP聯系在一起的, 而DNS 則是和UDP 同根生。 但現實意義是, UDP 就像 playboy, 他只管將DNS query發出去， 你收沒收到，那就各安天命了。
小哥，你說了這么多，那到底什么是UDP 什么是DNS呢?
恩~ 我們接下來看看具體的釋義.

What's the DNS?

在回答這個問題之前，我有個問題:

你有沒有使用過DNS呢？

大部分童鞋，可能會搖搖頭，又點點頭。(艸，你到底用沒用過呢)
en~ 不管是搖頭還是點頭的前端童鞋。 你一定使用過DNS。
為什么呢？為什么呢？為什么呢？
很簡單, 因為你線上部署的域名，一定會經由DNS處理, 從而別人才能找到你網頁真正的地址. 其實DNS是我們找到域名的一個必不可少的環節，有疑問的同學請看--網頁解析過程.這里我們需要明白一個道理， 別人訪問你的域名，并不是真正就能通過那個https://www.google.com來訪問到, 而是 通過ip地址訪問的。 可以說，網絡世界中，ip地址就像 我們的電話號碼， 只有撥對了號碼，這才能找到你要找的那個人。
所以，DNS 的作用就是 一個翻譯(更確切的說就是數據庫).

How does DNS work?

先給大家看一個萌一點的流程圖.

估計大家看見這個圖會有點懵逼，其實，DNS的起點和終點都是在你的客戶端上。
這個圖，應該能更加清晰的說明了.

ok~ 我們按照這個圖，來一步一步梳理一下.

• step1: 首先，我們在搜索欄中輸入我們想去的地址。接著, 瀏覽器會尋找 本地的DNS Cache. 如果存在那就好了，如果沒有，那就得向DNS Server 發送一個請求，找到你想要的IP地址。 本地的DNS Cache有沒有你的域名映射就得看TLL][3了.

• step2: 首先他會向你的ISP(internet server provider)相關的DNS servers 發送 DNS query. 然后這些DNS 進行遞歸查詢(recursive). 所謂的遞歸查詢，就是能夠直接返回對應的IP地址，而不是其他的DNS server地址.

• step3: 如果上述的DNS Servers 沒有你要的域名地址. 則就會發送迭代查詢，即，會先從root nameservers 找起。 即, 假如你要查詢,www.example.com. 會先從包含.的13臺最高級域名服務器開始.(注意哦，我沒有寫錯，確實是., .就是最高的域名地址).

• step4: 接著,從右->左. 找到 com. 然后向包含com的 TLD(top-level domain) nameservers發送DNS請求. 接著找到包含example的DNS server

• step5: 現在進入到了example.com部分. 即，現在正在詢問的是權威服務器. 該服務器里面包含了你想要的域名信息。
  到這里，我們大致就可以梳理一下，迭代查詢的過程.

流程: .=>com.=>.exampl.com.=>www.example.com.=>IP adress
ok~ 老子終于拿到我想要的了. 然后 開始retrieve the record.

• step6: 遞歸 查詢的DNS Server接受到這record之后, 會將該record 保存一份到本地. 如果,下一次你再請求這個domain時，我就可以直接返回給你了.由于每條記錄都會存在TLL, 所以server 每隔一段時間都會發送一次請求，獲取新的record.

• step7: 最后，再經由最近的DNS Server 將該條record返回。 同樣，你的computer也會存一份該record的副本。 之后，就是TCP的事了.

現在，我們再反觀上面圖可以發現，它只包含了從遞歸查詢就獲得信息的process. 沒有到TLD和 權威服務器.
其實，說太多理論是很干的，我們來實踐一下. 這里，我們需要使用一個*nx 的命令, dig.
說明一下,dig就是用來進行DNS查詢的一個很重要的命令.
ok~ 我們來試一試查詢DNS吧.
dig http://girls.hustonline.net
輸出的結果為:

; <<>> DiG 9.8.3-P1 <<>> girls.hustonline.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10833
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 10

;; QUESTION SECTION:
;girls.hustonline.net.        IN    A

;; ANSWER SECTION:
girls.hustonline.net.    600    IN    A    202.114.18.44

;; AUTHORITY SECTION:
hustonline.net.        64824    IN    NS    f1g1ns2.dnspod.net.
hustonline.net.        64824    IN    NS    f1g1ns1.dnspod.net.

;; ADDITIONAL SECTION:
f1g1ns2.dnspod.net.    149356    IN    A    115.236.151.191
f1g1ns2.dnspod.net.    149356    IN    A    182.140.167.188
f1g1ns2.dnspod.net.    149356    IN    A    101.226.30.224
f1g1ns2.dnspod.net.    149356    IN    A    112.90.82.194
f1g1ns2.dnspod.net.    149356    IN    A    115.236.137.40
f1g1ns1.dnspod.net.    149356    IN    A    125.39.208.193
f1g1ns1.dnspod.net.    149356    IN    A    180.153.9.189
f1g1ns1.dnspod.net.    149356    IN    A    182.140.167.166
f1g1ns1.dnspod.net.    149356    IN    A    183.232.126.141
f1g1ns1.dnspod.net.    149356    IN    A    113.108.80.138

;; Query time: 52 msec
;; SERVER: 202.114.0.242#53(202.114.0.242)
;; WHEN: Fri Mar 18 21:08:23 2016
;; MSG SIZE  rcvd: 265

wtf... 這些都是些什么鬼.
咳咳~ 來我們慢慢看看》

• part_1:
  ; <<>> DiG 9.8.3-P1 <<>> girls.hustonline.net
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10833
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 10
  這一部分就是簡單的DNS查詢簡介. 全局選項cmd. 得到的answer的情況是 noerror. falgs 是 操作權限. 基本上只要看ANSWER和status即可.

• part_2:

  ;; QUESTION SECTION:

  ;girls.hustonline.net. IN A

  請求部分，要求獲得girls.hustonline.net.的IP 地址

• part_3:

  ;; ANSWER SECTION:

  girls.hustonline.net. 600 IN A 202.114.18.44
  返回信息，表示成功獲得IP信息

• part_4:

  ;; AUTHORITY SECTION:

  hustonline.net. 64824 IN NS f1g1ns2.dnspod.net.
  查詢的權威服務器的域名地址.

• part_5:

  ;; ADDITIONAL SECTION:

  f1g1ns2.dnspod.net. 149356 IN A 115.236.151.191
  f1g1ns2.dnspod.net. 149356 IN A 182.140.167.188**
  獲得的權威服務器的地址, 用來進行遞歸查詢.

ok~ 上面就只涉及遞歸查詢的部分，關于迭代查詢的部分，其實，和上面類似。
可以使用
dig girls.hustonline.net +trace 來進行路徑跟蹤查詢. 接下來，你就會看到 DNS是如何從.開始解析的.
另外，再補一個trick--有效的DNS query.
即,我們在f1g1ns2.dnspod.net. 149356 IN A 115.236.151.191里看到的A以及上文出現的NS等的含義

• A(獲取到IP地址)

• TXT (text的內容信息)

• MX (mail exchanges)

• NS (nameserver 權威服務器)

另外我們需要知道,上述的傳輸過程全部是依賴于UDP進行傳輸了。 在前文，我說過，UDP其實就是個playboy. 不可靠. 但是，他正好對于這類比較小的DNS query是非常適合的. 那UDP 到底怎么工作的呢?

How does UDP work?

當我們談及UDP時，總是喜歡和TCP進行對比比較。 因為這兩者的差異性確實很大。 也可以理解為他們就是不同的東西。
UDP數據結構圖.

TCP的圖為:

我們可以從這個地方可以很直觀的看出，UDP 就兩個字--簡單.
他 們兩個雖然都是傳輸層上，但是，兩者的通信方式是完全不一樣的。首先,UDP不需要建立可靠的連接，所以他的限制就是發送一些比較小的包文件，而且沒有錯 誤處理機制。 包沒了就是沒了。 當然，某些dev 會對UDP做一些處理，比如 超時重發等。 而TCP 則是比較靠譜的，首先他會建立可靠的連接(3次握手), 然后可以互相信任的進行數據發送，這樣的保密性強一些，而且自從HTTPS的出現更是提升了網絡的安全性。 但HTTP的網絡成本較高，所以對于一些小文件包使用HTTP傳輸的話，有點得不償失.那~ TCP和UDP 的應用場景分別有哪些呢？

TCP和UDP應用場景

UDP是一個不可靠的協議，但傳輸小數據量合適.
而TCP是可靠的協議，傳輸大數據量合適.
所以從這兩點觸發，我們就可以總結出一些簡單的應用場景了.

這里需要解釋一下最后一條，為什么兩者都可以應用于網絡游戲. 首先，我們需要了解一下，網絡游戲的特點是什么。 我們一般在玩游戲時，一般會選擇在高速網絡下，而且網絡情況條件要好。但是，也不排除，一些手游，我們沒有辦法，只能使用3G和4G來燒流量。 另外，網絡游戲最大的特征就是，網路堵塞. 造成的結果就是相應變慢，網速變慢。 而，使用TCP和UDP最關鍵的區分點就在這里，TCP 用來檢測連接是否有效時，是根據你帶寬的限制，如果過小的話，則會對發送的包進行節流(throttle). 造成的結果就是延遲，延遲，延遲。
這里Christoffer提出了一些建議:

• 如果你的游戲，只是簡單的交互，并沒有涉及太多的通信。可以使用HTTP/TCP進行設置.

• 如果你的游戲，有較多的通信，并且有一點延遲。可以使用TCP 創建一個 socket通道進行通信.(比如，網上撲克等)

• 如果你的游戲，通信很多，網絡比較堵塞。則推薦使用UDP（比如，RPG,動作類游戲）

說道最后

其實上面逼逼這么多，想說的只有一句話:

手機端請使用域名收斂策略

哎~ 前端優化之路漫漫呀~ 特別是手機端的優化，感覺又回到以前PC 洪荒時代了.
加油吧~ 各位.

如果大家覺得，嘿, 這哥們寫的文章不錯呀~
能請我喝杯coffee，勉勵寫出更優質的文章嗎？

原文 https://segmentfault.com/a/1190000004641599