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

在说域名收敛之前，问大家一个问题.

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

答: 网速慢呗~ 怪我咯

这当然不能怪你，确实是网速慢，但另外一方面是，如果网速已经很慢了，而你的网页加载效率又太低~ 造成的结果就是:
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，勉励写出更优质的文章吗？

转载请注明出处和作者:https://segmentfault.com/a/1190000004641599