域名收斂--前端優化(二)

在說域名收斂以前，問你們一個問題.

爲何你手機打開時，白屏時間會這麼長?

答: 網速慢唄~ 怪我咯

這固然不能怪你，確實是網速慢，但另一方面是，若是網速已經很慢了，而你的網頁加載效率又過低~ 形成的結果就是:
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是可靠的協議，傳輸大數據量合適.
因此從這兩點觸發，咱們就能夠總結出一些簡單的應用場景了.

UDP	TCP
app應用	web browsing
DNS查找	email
廣播傳輸,流媒體	文件傳輸
線上遊戲	線上遊戲

這裏須要解釋一下最後一條，爲何二者均可以應用於網絡遊戲. 首先，咱們須要瞭解一下，網絡遊戲的特色是什麼。 咱們通常在玩遊戲時，通常會選擇在高速網絡下，並且網絡狀況條件要好。可是，也不排除，一些手遊，咱們沒有辦法，只能使用3G和4G來燒流量。 另外，網絡遊戲最大的特徵就是，網路堵塞. 形成的結果就是相應變慢，網速變慢。 而，使用TCP和UDP最關鍵的區分點就在這裏，TCP 用來檢測鏈接是否有效時，是根據你帶寬的限制，若是太小的話，則會對發送的包進行節流(throttle). 形成的結果就是延遲，延遲，延遲。
這裏Christoffer提出了一些建議:

• 若是你的遊戲，只是簡單的交互，並無涉及太多的通訊。可使用HTTP/TCP進行設置.

• 若是你的遊戲，有較多的通訊，而且有一點延遲。可使用TCP 建立一個 socket通道進行通訊.(好比，網上撲克等)

• 若是你的遊戲，通訊不少，網絡比較堵塞。則推薦使用UDP（好比，RPG,動做類遊戲）

說道最後

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

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

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

若是你們以爲，嘿, 這哥們寫的文章不錯呀~
能請我喝杯coffee，勉勵寫出更優質的文章嗎？

轉載請註明出處和做者:http://www.javashuo.com/article/p-vmpapofq-hw.html