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

villainhr

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

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

答: 网速慢呗~ 怪我咯

这当然不能怪你,确实是网速慢,但另外一方面是,如果网速已经很慢了,而你的网页加载效率又太低~ 造成的结果就是:
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 是 操作权限. 基本上只要看ANSWERstatus即可.

  • 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

阅读 10.5k

前端的bigboom
个人博客: [链接] 公众号:前端小吉米
7.7k 声望
2.2k 粉丝
0 条评论
7.7k 声望
2.2k 粉丝
文章目录
宣传栏