域名收敛--前端优化(二)

在说域名收敛以前，问你们一个问题.

为何你手机打开时，白屏时间会这么长?

答: 网速慢呗~ 怪我咯

这固然不能怪你，确实是网速慢，但另一方面是，若是网速已经很慢了，而你的网页加载效率又过低~ 形成的结果就是:
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