nginx的497状态码
error code 497
解释：当此虚拟站点只允许https访问时，当用http访问时nginx会报出497错误码
思路
利用error_page命令将497状态码的链接重定向到https://test.com这个域名上
月度归档：2017年07月
2.4G和5G的Wi-Fi各自优缺点对比
1.为什么5G信号的穿墙效果比2.4G信号差？
与路由器的距离相同时，5G信号相对2.4G信号较弱，这是由电磁波的物理特性决定的：波长越长衰减越少，也更容易绕过障碍物继续传播。5G信号频率高、波长短，而2.4G信号频率低、波长长，所以5G信号穿过障碍物时衰减更大，穿墙能力比2.4G信号弱，所有双频无线路由器都存在这样的情况。
注意：如下是2.4G和5.8G在自由空间传播的损耗公式（其中F是频率，单位是MHz；D是距离，单位是km）
无线电磁波在自由空间的衰减公式：L=32.5+20lgF+20lgD。
2.4G频段的衰减公式：L1=100+20lgD；
5.8G频段的衰减公式：L2=108+20lgD。
以上公式可以看出5.8G的衰减相对于2.4G要高，相应的覆盖的距离要小一些。
2.如果5G信号比2.4G信号弱，那网速也会慢吗？
不一定，网速不仅与信号强度有关，也与信道质量有很大的关系。穿过一堵墙后，2.4G频段可能有3格信号，5G频段可能只有2格信号，如果周围无线干扰太大，使用3格信号的2.4G频段观看视频经常会缓冲一下，而使用2格信号的5G频段观看视频就比较流畅。对于一些对网速、延迟等要求较高应用，如下载、语音、实时游戏等，使用5G信号更加合适。
3.2.4G和5G Wi-Fi各自的优缺点是什么？
|
频段 |
2.4G |
5G |
|
优点 |
2.4G信号频率低，在空气或障碍物中传播时衰减较小，传播距离更远。 |
5G信号频宽较宽，无线环境比较干净，干扰少，网速稳定，且5G可以支持更高的无线速率。 |
|
缺点 |
2.4G信号频宽较窄，家电、无线设备大多使用2.4G频段，无线环境更加拥挤，干扰较大。 |
5G信号频率较高，在空气或障碍物中传播时衰减较大，覆盖距离一般比2.4G信号小。 |
4.使用哪个频段更合适呢？
通过以上对比可以看到2.4G和5G两个频段的优劣势，但并非二者只能选其一，大多使用环境复杂、终端多样、接入量较多，所以两个频段配合使用才能发挥最大的无线优势。如果您是家庭用户，建议选择双频路由器，网络电视、笔记本等移动较少的物体可以选择2.4G或5G中最合适的频段；移动终端在不同位置可以使用不同频段，从而发挥各频段的优势。
Comodo Secure DNS（科莫多提供） 8.26.56.26/8.20.247.20，对比114dns、dnspod、阿里DNS
Comodo Secure DNS（科莫多提供） 8.26.56.26/8.20.247.20 查询速度非常快，一点也不输给dnspod的119.29.29.29 114DNS：114.114.114.114 阿里DNS：223.5.5.5
测试一下查询速度，Comodo Secure DNS（科莫多提供） 8.26.56.26/8.20.247.20基本在1毫秒到900毫秒，波动很大，但是定位不够准确，广东电信使用了
# time dig @8.26.56.26 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.26.56.26 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16697
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 31 IN A 180.149.134.141
www.weibo.com. 31 IN A 180.149.134.142
;; Query time: 1 msec
;; SERVER: 8.26.56.26#53(8.26.56.26)
;; WHEN: Tue Jul 18 17:56:07 2017
;; MSG SIZE rcvd: 63
real 0m0.006s
user 0m0.002s
sys 0m0.002s
# time dig @8.20.247.20 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.20.247.20 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4081
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 37 IN A 180.149.134.142
www.weibo.com. 37 IN A 180.149.134.141
;; Query time: 2 msec
;; SERVER: 8.20.247.20#53(8.20.247.20)
;; WHEN: Tue Jul 18 17:56:42 2017
;; MSG SIZE rcvd: 63
real 0m0.006s
user 0m0.000s
sys 0m0.004s
# time dig @8.20.247.20 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.20.247.20 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12273
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 527 IN CNAME v.tc.qq.com.
v.tc.qq.com. 1072 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 211 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 128 IN A 58.216.96.21
p21.tcdn.qq.com. 128 IN A 61.155.220.194
p21.tcdn.qq.com. 128 IN A 58.216.96.19
p21.tcdn.qq.com. 128 IN A 58.216.96.18
p21.tcdn.qq.com. 128 IN A 58.216.6.22
p21.tcdn.qq.com. 128 IN A 58.216.96.17
p21.tcdn.qq.com. 128 IN A 221.228.67.166
p21.tcdn.qq.com. 128 IN A 58.216.96.22
p21.tcdn.qq.com. 128 IN A 221.228.67.167
p21.tcdn.qq.com. 128 IN A 221.228.67.146
p21.tcdn.qq.com. 128 IN A 58.216.96.20
p21.tcdn.qq.com. 128 IN A 58.216.6.21
p21.tcdn.qq.com. 128 IN A 58.216.6.20
p21.tcdn.qq.com. 128 IN A 221.228.67.165
;; Query time: 3 msec
;; SERVER: 8.20.247.20#53(8.20.247.20)
;; WHEN: Tue Jul 18 17:58:29 2017
;; MSG SIZE rcvd: 331
real 0m0.007s
user 0m0.002s
sys 0m0.003s
# time dig @8.26.56.26 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.26.56.26 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2198
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 132 IN CNAME v.tc.qq.com.
v.tc.qq.com. 1290 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 439 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 124 IN A 203.205.158.37
p21.tcdn.qq.com. 124 IN A 203.205.158.38
;; Query time: 289 msec
;; SERVER: 8.26.56.26#53(8.26.56.26)
;; WHEN: Tue Jul 18 18:13:52 2017
;; MSG SIZE rcvd: 116
real 0m0.294s
user 0m0.003s
sys 0m0.001s
[root@2 monitor_video]# time dig @8.26.56.26 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.26.56.26 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1656
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 127 IN CNAME v.tc.qq.com.
v.tc.qq.com. 2027 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 434 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 6 IN A 203.205.158.37
p21.tcdn.qq.com. 6 IN A 203.205.158.38
;; Query time: 992 msec
;; SERVER: 8.26.56.26#53(8.26.56.26)
;; WHEN: Tue Jul 18 18:13:57 2017
;; MSG SIZE rcvd: 116
real 0m2.997s
user 0m0.001s
sys 0m0.003s
看看dnspod dns、也就是腾讯DNS，119.29.29.29，定位很准确，返回广东电信ip，查询速度稳定在10几毫秒
# time dig @119.29.29.29 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @119.29.29.29 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9766
;; flags: qr rd ra; QUERY: 1, ANSWER: 19, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 296 IN CNAME v.tc.qq.com.
v.tc.qq.com. 2309 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 296 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 54 IN A 125.94.49.21
p21.tcdn.qq.com. 54 IN A 119.147.33.30
p21.tcdn.qq.com. 54 IN A 119.147.253.19
p21.tcdn.qq.com. 54 IN A 119.147.33.28
p21.tcdn.qq.com. 54 IN A 119.147.253.28
p21.tcdn.qq.com. 54 IN A 119.147.33.29
p21.tcdn.qq.com. 54 IN A 113.105.73.147
p21.tcdn.qq.com. 54 IN A 119.147.227.20
p21.tcdn.qq.com. 54 IN A 119.147.227.22
p21.tcdn.qq.com. 54 IN A 125.94.49.22
p21.tcdn.qq.com. 54 IN A 125.94.49.18
p21.tcdn.qq.com. 54 IN A 113.107.238.105
p21.tcdn.qq.com. 54 IN A 119.147.33.32
p21.tcdn.qq.com. 54 IN A 119.147.227.21
p21.tcdn.qq.com. 54 IN A 119.147.227.18
p21.tcdn.qq.com. 54 IN A 119.147.227.19
;; Query time: 14 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Tue Jul 18 17:59:58 2017
;; MSG SIZE rcvd: 340
real 0m0.018s
user 0m0.001s
sys 0m0.004s
[root@2 monitor_video]# time dig @119.29.29.29 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @119.29.29.29 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32098
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 35 IN A 180.149.134.142
www.weibo.com. 35 IN A 180.149.134.141
;; Query time: 12 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Tue Jul 18 18:00:05 2017
;; MSG SIZE rcvd: 63
real 0m0.016s
user 0m0.000s
看看最早的114DNS，114.114.114.114，返回IP为江苏电信IP不够准确，查询时间也非常快1-2毫秒。
# time dig @114.114.114.114 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @114.114.114.114 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8929
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 238 IN CNAME v.tc.qq.com.
v.tc.qq.com. 349 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 322 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 32 IN A 58.216.6.20
p21.tcdn.qq.com. 32 IN A 58.216.96.19
p21.tcdn.qq.com. 32 IN A 58.216.96.21
p21.tcdn.qq.com. 32 IN A 221.228.67.165
p21.tcdn.qq.com. 32 IN A 58.216.96.18
p21.tcdn.qq.com. 32 IN A 58.216.96.22
p21.tcdn.qq.com. 32 IN A 61.155.220.194
p21.tcdn.qq.com. 32 IN A 58.216.96.17
p21.tcdn.qq.com. 32 IN A 221.228.67.167
p21.tcdn.qq.com. 32 IN A 58.216.6.22
p21.tcdn.qq.com. 32 IN A 58.216.6.21
p21.tcdn.qq.com. 32 IN A 221.228.67.166
p21.tcdn.qq.com. 32 IN A 221.228.67.146
p21.tcdn.qq.com. 32 IN A 58.216.96.20
;; Query time: 2 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Tue Jul 18 18:01:40 2017
;; MSG SIZE rcvd: 331
real 0m0.006s
user 0m0.004s
sys 0m0.000s
[root@2 monitor_video]# time dig @114.114.114.114 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @114.114.114.114 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13642
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 15 IN A 180.149.134.142
www.weibo.com. 15 IN A 180.149.134.141
;; Query time: 1 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Tue Jul 18 18:01:47 2017
;; MSG SIZE rcvd: 63
real 0m0.006s
user 0m0.002s
sys 0m0.002s
最后我们看看阿里DNS，223.5.5.5 223.6.6.6，首先返回ip有时候是湖南电信有时候是江苏电信，不够准确。查询速度10几毫秒，跟腾讯DNS（DNSPod）差不多。
# time dig @223.5.5.5 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @223.5.5.5 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31354
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 40 IN A 180.149.134.142
www.weibo.com. 40 IN A 180.149.134.141
;; Query time: 13 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Tue Jul 18 18:03:01 2017
;; MSG SIZE rcvd: 63
real 0m0.018s
user 0m0.004s
sys 0m0.001s
[root@2 monitor_video]# time dig @223.5.5.5 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @223.5.5.5 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5022
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 168 IN CNAME v.tc.qq.com.
v.tc.qq.com. 168 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 168 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 168 IN A 218.75.176.141
p21.tcdn.qq.com. 168 IN A 218.75.176.143
p21.tcdn.qq.com. 168 IN A 218.75.176.144
p21.tcdn.qq.com. 168 IN A 218.75.177.23
p21.tcdn.qq.com. 168 IN A 218.75.177.25
p21.tcdn.qq.com. 168 IN A 218.75.177.24
p21.tcdn.qq.com. 168 IN A 218.75.176.142
;; Query time: 6 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Tue Jul 18 18:03:05 2017
;; MSG SIZE rcvd: 196
real 0m0.010s
user 0m0.000s
sys 0m0.004s
小结：dnspod dns（腾讯DNS）119.29.29.29，查询定位很准确返回广东电信ip，查询速度稳定在10几毫秒，阿里dns、114dns都很快但是返回ip不是本省ip，可能是递归查询的ip节点不够多导致不准确。而Comodo Secure DNS（科莫多提供） 8.26.56.26/8.20.247.20 查询速度有时候最快，但是不稳定有时候几百毫秒，返回ip也不够精准同运营商不同省份，还是不稳定，不推荐。
114DNS还有拦截钓鱼病毒木马网站,拦截色情网站安全儿童模式DNS
1.纯净 无劫持 无需再忍受被强扭去看广告或粗俗网站之痛苦
服务地址为：114.114.114.114 和 114.114.115.115
2.拦截 钓鱼病毒木马网站 增强网银、证券、购物、游戏、隐私信息安全
拦截钓鱼病毒木马DNS服务地址为：114.114.114.119 和 114.114.115.119
3.学校或家长可选拦截 色情网站 保护少年儿童免受网络色情内容的毒害
拦截色情DNS服务地址为：114.114.114.110 和 114.114.115.110
如果有上述需求的，可以考虑下，效果还可以，延迟基本上在10ms以下，速度很好。
2017公共DNS服务质量评测报告
DNS在平时上网中扮演重要角色，如果不注意的话，可能会导致网速慢、弹窗广告、网址打不开、打开不是自己想要的网站、劫持、墙中墙等一系列问题。针对DNS的问题，今天我们就来总结一下，看看哪个DNS服务器最好用！
注意：本测试仅通过奇云测对服务器进行综合测试，具体使用情况请以用户本地为主。
DNSPod：★★★★★
DNSPod是目前国内第一家支持ECS的公共DNS，可为全网用户提供域名的公共递归解析服务！
DNS 服务器 IP 地址：
首选：119.29.29.29
备选：182.254.116.116
作者点评：查询11毫秒，测试显示Public DNS+国内数据均比114DNS好，强力推荐！
# dig @119.29.29.29 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @119.29.29.29 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25013
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 53 IN A 180.149.134.142
www.weibo.com. 53 IN A 180.149.134.141
;; Query time: 11 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Tue Jul 18 17:29:30 2017
;; MSG SIZE rcvd: 63
114DNS：★★★★
国内用户量巨大的DNS，访问速度快，各省都有节点，可同时满足各运营商用户，有效预防劫持。
DNS 服务器 IP 地址：
首选：114.114.114.114
备选：114.114.114.115
作者点评：15毫秒查询反应，虽然测试结果比不上Public DNS+，但是也是非常不错的DNS
# dig @114.114.114.114 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @114.114.114.114 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49841
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 30 IN A 180.149.134.142
www.weibo.com. 30 IN A 180.149.134.141
;; Query time: 15 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Tue Jul 18 17:25:31 2017
;; MSG SIZE rcvd: 63
阿里 AliDNS：★★★★
阿里公共DNS是阿里巴巴集团推出的DNS递归解析系统，面向用户提供快速、稳定、智能的免费DNS递归解析服务。
DNS 服务器 IP 地址：
首选：223.5.5.5
备选：223.6.6.6
作者点评：查询12毫秒，排名第三的DNS也不是吹的，只是节点貌似有点少。
# dig @223.5.5.5 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @223.5.5.5 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25617
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 15 IN A 180.149.134.141
www.weibo.com. 15 IN A 180.149.134.142
;; Query time: 12 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Tue Jul 18 17:26:12 2017
;; MSG SIZE rcvd: 63
★★★
DNS派是聚流旗下的DNS服务，为个人用户、企业提供各种DNS服务，包括域名解析服务、网站授权解析服务、域名解析服务等
DNS 服务器 IP 地址：
首选（电信/移动/铁通）：101.226.4.6
备选（电信/移动/铁通）：218.30.118.6
首选（联通）：123.125.81.6
备选（联通）：140.207.198.6
作者点评：360出品！测试结果还不错，但是速度需要32毫秒。
# dig @101.226.4.6 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @101.226.4.6 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28341
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 60 IN A 180.149.134.141
www.weibo.com. 60 IN A 180.149.134.142
;; Query time: 32 msec
;; SERVER: 101.226.4.6#53(101.226.4.6)
;; WHEN: Tue Jul 18 17:26:36 2017
;; MSG SIZE rcvd: 63
：★★★
百度旗下云解析服务，依托百度一流基础设施和强大技术实力,为用户提供免费的、超越竞品的服务体验。没有套餐区分,安全,稳定,高效
DNS 服务器 IP 地址：
首选：180.76.76.76
作者点评：暂时不知道百度有多少节点。不过应该也不少吧，但是查询速度也要37毫秒。
# dig @180.76.76.76 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @180.76.76.76 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27682
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 23 IN A 180.149.134.142
www.weibo.com. 23 IN A 180.149.134.141
;; Query time: 37 msec
;; SERVER: 180.76.76.76#53(180.76.76.76)
;; WHEN: Tue Jul 18 17:32:29 2017
;; MSG SIZE rcvd: 63
CNNIC SDNS：★★★
SDNS是由中国互联网络信息中心(CNNIC)推出的免费解析服务(SecureDNS,简称SDNS)。
DNS 服务器 IP 地址：
首选：1.2.4.8
备选：210.2.4.8
作者点评：作为国家出品的DNS，有待测试……（你敢用吗？反正我不敢）查询速度38毫秒，返回内容太多了，注定也慢。
# dig @1.2.4.8 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @1.2.4.8 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12314
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 6
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 48 IN A 180.149.134.141
www.weibo.com. 48 IN A 180.149.134.142
;; AUTHORITY SECTION:
weibo.com. 77931 IN NS ns4.sina.com.cn.
weibo.com. 77931 IN NS ns1.sina.com.cn.
weibo.com. 77931 IN NS ns3.sina.com.cn.
weibo.com. 77931 IN NS ns2.sina.com.cn.
weibo.com. 77931 IN NS ns3.sina.com.
weibo.com. 77931 IN NS ns4.sina.com.
;; ADDITIONAL SECTION:
ns1.sina.com.cn. 73312 IN A 202.106.184.166
ns2.sina.com.cn. 66852 IN A 61.172.201.254
ns3.sina.com. 82970 IN A 61.172.201.254
ns3.sina.com.cn. 82970 IN A 123.125.29.99
ns4.sina.com. 73000 IN A 123.125.29.99
ns4.sina.com.cn. 80179 IN A 121.14.1.22
;; Query time: 38 msec
;; SERVER: 1.2.4.8#53(1.2.4.8)
;; WHEN: Tue Jul 18 17:27:38 2017
;; MSG SIZE rcvd: 283
OpenDNS：★★
OpenDNS创建于2006年，长期以来致力于为广大个人用户以及商务企业用户和公共领域提供免费的域名解析服务。
DNS 服务器 IP 地址：
首选：208.67.222.222
备选：208.67.220.220
作者点评：国内节点少，延迟高，解析结果受GFW的影响不一定准确，66毫秒，跟国内比查了几倍速度了。
# dig @208.67.222.222 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @208.67.222.222 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39469
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 21 IN A 123.125.104.197
;; Query time: 66 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Tue Jul 18 17:28:07 2017
;; MSG SIZE rcvd: 47
Google DNS：★★
谷歌公共域名解析服务（Google Public DNS）是由谷歌于2009年发布的一项DNS服务
DNS 服务器 IP 地址：
首选：8.8.8.8
备选：8.8.4.4
作者点评：国内无节点，延迟高，解析结果受GFW的影响不一定准确，300毫秒，直接放弃使用吧。
# dig @8.8.8.8 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.8.8.8 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14390
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 32 IN A 180.149.134.142
www.weibo.com. 32 IN A 180.149.134.141
;; Query time: 300 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jul 18 17:28:37 2017
;; MSG SIZE rcvd: 63
最后总结
测试结果受用户地区和DNS提供商的服务器等不同因素影响。建议用户在选择DNS时可以依照本排行，ping不同dns服务商的首选DNS地址，一般是哪个延迟最低用哪个。不同地区我也不好发言。建议不要使用运营商默认的DNS！推荐DNSPodDNS:119.29.29.29/182.254.116.116，114DNS:114.114.114.114/114.114.114.115，阿里DNS：223.5.5.5/223.6.6.6
美国、加拿大、英国、日本、韩国、新西兰、泰国、印度DNS服务器地址大全
208.67.222.222 208.67.222.222 IP WHOIS 美国DNS 加利福尼亚州旧金山市OpenDNS有限公司公众DNS服务器
208.67.220.220 208.67.220.220 IP WHOIS 美国DNS 加利福尼亚州旧金山市OpenDNS有限公司公众DNS服务器
165.87.13.129 165.87.13.129 IP WHOIS 美国DNS
165.87.201.244 165.87.201.244 IP WHOIS 美国DNS
205.171.3.65 205.171.3.65 IP WHOIS 美国DNS 科罗拉多州丹佛市Qwest通信有限公司DNS服务器
205.171.2.65 205.171.2.65 IP WHOIS 美国DNS 科罗拉多州丹佛市Qwest通信有限公司DNS服务器
198.41.0.4 198.41.0.4 IP WHOIS 美国DNS 主根域名服务器全球第01OF13号A.ROOT-SERVERS节点(WorldAnycast任播网络VeriSign运作BIND软件)
198.41.0.4 198.41.0.4 IP WHOIS 美国DNS 主根域名服务器全球第01OF13号A.ROOT-SERVERS节点(WorldAnycast任播网络VeriSign运作BIND软件)
198.32.64.12 198.32.64.12 IP WHOIS 圣基茨和尼维斯
192.33.4.12 192.33.4.12 IP WHOIS 美国DNS 主根域名服务器全球第03OF13号C.ROOT-SERVERS节点(WorldAnycast任播网络Cogent Communications运作BIND软件)
192.203.230.10 192.203.230.10 IP WHOIS 美国DNS 主根域名服务器全球第05OF13号E.ROOT-SERVERS节点(WorldAnycast任播网络美国DNS国家航空航天局运作BIND软件) [未知IP0801] 美国DNS
192.5.5.241 192.5.5.241 IP WHOIS 美国DNS 主根域名服务器全球第06OF13号F.ROOT-SERVERS节点(WorldAnycast任播网络互联网系统协会运作BIND9软件)
192.112.36.4 192.112.36.4 IP WHOIS 美国DNS 主根域名服务器全球第07OF13号G.ROOT-SERVERS节点(WorldAnycast任播网络美国DNS国防部国防信息系统局运作BIND软件) [未知IP0801] 美国DNS
192.36.148.17 192.36.148.17 IP WHOIS 瑞典 主根域名服务器全球第09OF13号I.ROOT-SERVERS节点(WorldAnycast任播网络瑞典Netnod运作BIND软件) 美国DNS 瑞典
192.58.128.30 192.58.128.30 IP WHOIS 美国DNS 主根域名服务器全球第10OF13号J.ROOT-SERVERS节点(WorldAnycast任播网络VeriSign运作BIND软件)
192.9.9.3 192.9.9.3 IP WHOIS 美国DNS sun(公司) Oracle
193.0.14.129 193.0.14.129 IP WHOIS 荷兰 主根域名服务器全球第12OF13号L.ROOT-SERVERS节点(WorldAnycast任播网络ICANN运作NSD软件) 英国 荷兰
128.9.0.107 128.9.0.107 IP WHOIS 美国DNS Information Sciences Institute
128.8.10.90 128.8.10.90 IP WHOIS 美国DNS 马里兰大学DNS服务器 美国DNS 马里兰大学 美国DNS 马里兰大学
66.33.206.206 66.33.206.206 IP WHOIS 美国DNS 加利福尼亚州布瑞亚市DreamHost公司
208.96.10.221 208.96.10.221 IP WHOIS 美国DNS 加利福尼亚州旧金山市GoGrid公司
66.33.216.216 66.33.216.216 IP WHOIS 美国DNS 加利福尼亚州布瑞亚市DreamHost公司
205.171.3.65 205.171.3.65 IP WHOIS 美国DNS 科罗拉多州丹佛市Qwest通信有限公司DNS服务器
205.171.2.65 205.171.2.65 IP WHOIS 美国DNS 科罗拉多州丹佛市Qwest通信有限公司DNS服务器
165.87.13.129 165.87.13.129 IP WHOIS 美国DNS
165.87.201.244 165.87.201.244 IP WHOIS 美国DNS
加拿大DNS服务器地址：
209.166.160.36
209.166.160.132
英国DNS服务器地址：
193.0.14.129
日本DNS服务器地址：
202.12.27.33
202.216.228.18
韩国DNS服务器地址：
164.124.101.31
203.248.240.31
168.126.63.60
168.126.63.61
新西兰DNS服务器地址：
202.27.184.3
泰国DNS服务器地址：
209.166.160.132
202.44.8.34
202.44.8.2
印度DNS服务器地址：
202.138.103.100
202.138.96.2
国内域名注册服务商DNS大全
中国万网DNS服务器：
dns19.hichina.com dns20.hichina.com
dns21.hichina.com dns22.hichina.com
万网域名控制面板：diy.hichina.com
新网互联DNS服务器：
ns1.dns.com.cn ns2.dns.com.cn
新网互联域名控制面板：mgt.dns.com.cn
新网DNS服务器：
ns.xinnetdns.com ns.xinnet.cn
新网域名控制面板：dcp.xinnet.com
商务中国DNS服务器：
ns1.4everdns.com ns2.4everdns.com
ns5.cnmsn.net ns6.cnmsn.net
商务中国域名控制面板：bizcn.com/domainportal
中国频道DNS服务器：
ns1.dns-diy.com ns2.dns-diy.com
ns3.dns-diy.com ns4.dns-diy.com
中国频道域名控制面板：www.dns-diy.com
时代互联DNS服务器：
ns3.todayisp.com ns4.todayisp.com
NS7.01ISP.COM NS8.01ISP.NET
NS5002.01ISP.NET NS5001.01ISP.CN
NS5002.01ISP.NET
时代互联域名控制面板：www.todaynic.com/domain-admin/
中资源DNS服务器：
ns1.cnolnic.com ns2.cnolnic.com
NS1.CNOLNIC.NET NS2.CNOLNIC.NET
中资源域名控制面板：domain.cnolnic.com
第一商务DNS服务器
ns1.everdns.com
ns2.everdns.com
ns5.everdns.com
ns6.everdns.com
第一商务域名控制面板：dns.6464.cn
GoDaddy DNS服务器：
ns25.domaincontrol.com
ns26.domaincontrol.com
Godaddy域名控制面板：www.godaddy.com
域名信息查询：whois.domaintools.com、 www.whois-search.com、 www.who.is、 ewhois.cnnic.cn
免费DNS服务器
DNSPod的免费DNS服务器
DNSPod域名控制面板：www.dnspod.com
第一组6台DNS服务器
ns1.dnspod.net
ns2.dnspod.net
ns3.dnspod.net
ns4.dnspod.net
ns5.dnspod.net
ns6.dnspod.net
第二组2台DNS服务器
如果你无法填写6台DNS，请用下面两个代替（看清楚，是“dnspood”）
ns1.dnspood.net
ns2.dnspood.net
DNSPod VIP客户专有 DNS服务器（非VIP客户，不要填写）
ns1.mydnspod.com
ns2.mydnspod.com
几个国外的免费DNS解析服务网站
知识链接：什么是DNS？
DNS，即Domain Name System或者Domain Name Service（域名系统或者域名服务）。域名系统为Internet上的主机分配域名地址和IP地址。用户使用域名地址，该系统就会自动把域名地址转为IP地址。域名服务是运行域名系统的Internet工具。执行域名服务的服务器称之为DNS服务器，通过DNS服务器来应答域名服务的查询。
简单的来说，当您连上一个网址在UR里打上www.xixik.com的时候可以说就是使用了DNS的服务了。但如果您知道这个www.xixik.com的IP地址直接输入60.191.185.54也同样可以到达这个网址。其实电脑使用的只是IP地址而已（最终也是0和1啦）这个www.xixik.com只是让人们容易记忆而设的。因为我们人类对一些比较有意义的文字记忆（如www.xixik.com）比记忆那些毫无头绪的号码（如60.191.185.54）往往容易得多。DNS的作用就是为我们在文字和IP之间担当了翻译而免除了强记号码的痛苦。
比如
1、DNS就是域名服务器，他的任务就是确定域名的解析，比如A记录MX记录等等。
2、任何域名都至少有一个DNS，一般是2个。但为什么要2个以上呢？因为DNS可以轮回处理，第一个解析失败可以找第二个。这样只要有一个DNS解析正常，就不会影响域名的正常使用。
3、如何确定域名的DNS
很简单到www.internic.net/whois.html输入你要查询的域名就可以看到了。这个是国际域名管理中心。唯一的权威。只要这里能查到某个域名，就表示域名是生效的。它说你什么时候到期，就是什么时候到期。
4、有效的DNS表示当前正在起作用的DNS服务器是谁，比如查询结果是NS.XINNETDNS.COM、NS.XINNET.CN（新网信海）就表示当前域名是由NS.XINNETDNS.COM、NS.XINNET.CN（新网信海）负责解析。其他DNS的设置，都是无效的。
5、DNS是可以修改的。修改以后需要24-72小时以后，全世界才能刷新过来。internic的信息一般在24小时以后可以看到。另外，修改的过程，并不表示域名会停止解析，只要你在2边都做好了解析。如果生效了就是新的DNS在起作用。如果没生效。就是旧的DNS在起作用。要么生效，要么不生效。不存在2个都不起作用的时间。所以域名解析，不会中断。前提是两边都做了解析。
6、DNS是有缓存的。
1、访问者的电脑；2、你的ISP接入商。
简单举例:比如你访问www.xixik.com，你的电脑首先查询本机上有没有缓存www.xixik.com的记录。如果有就直接调用不再去查寻。就是说如果你前面刚访问过www.xixik.com，这个时候就算电信的DNS和NS.XINNETDNS.COM、NS.XINNET.CN（新网信海）都不能解析。也是能够正常解析出域名的。
清除本机DNS缓存方法很简单。关闭IE然后清除历史记录，或者重启电脑。
然后还有一个就是isp接入商的DNS的缓存。
isp就是当地网络接入商。比如我们这里的福建电信;福州网通、南平铁通等等。每个地方都是不一样的。isp的DNS和NS.XINNETDNS.COM、NS.XINNET.CN（新网信海）这样的DNS是不同的。NS.XINNETDNS.COM、NS.XINNET.CN（新网信海）只负责具体的解析，不负责缓存。isp的DNS只负责查询和缓存，不负责解析。
简单描述下刚才访问www.xixik.com的情况。如果本机上不存在www.xixik.com的记录。你的电脑就会去查询当地ISP的DNS。isp的DNS只有缓存。就是说他会检查有没有www.xixik.com的缓存。如果有，他就直接把www.xixik.com 的记录发送给用户。用户也就能访问了。如果ISP的缓存里面也没有www.xixik.com 的记录，那么他进一步去查询xixik.com的DNS是什么?然后再到对应的DNS上直接去取得数据，并返回给用户。当第一个用户访问了www.xixik.com以后，isp的dns上也就开始缓存了www.xixik.com 的记录。以后他就不必再去 NS.XINNETDNS.COM、NS.XINNET.CN（新网信海）去找了。除非有新的域名，他才会去查。比如访问kfc.xixik.com的时候，他就要重新去查了。
7、isp的DNS缓存是有时间限制的。一般是1个小时。前后2次间隔1个小时的话，他就去域名的DNS上重新取得数据。这里说的是最前面一次和当前的比较。也就是说如果时间差距较大，就重新去域名的DNS服务器上找。所以刷新就变的很有必要，否则缓存了一次以后。域名记录改了以后。ISP就永远不去找新的记录了。知道了这个原理以后，大家就会明白，为什么原来没有的记录注册并生效会很快。修改的话生效会很慢。就是因为缓存的原因。但如果没有缓存，访问的效率会很低，因为任何一次输入www.xixik.com都得跑到NS.XINNETDNS.COM、NS.XINNET.CN（新网信海）去查询记录。
备注：很多域名商的域名解析系统也不是实时刷新的。一般会设置下时间，比如10分钟.就是说，你设置了一个新的A记录以后，域名服务器会在10分钟内为你添加。目的就是为了节约服务器资源。怕客户的DNS不断的刷新记录。刷新记录肯定需要消耗一定的资源。而且刷新过程中是不能解析的。另外刷新过程大概5秒。就是说这个5秒内域名商的的DNS是不能用的。
全球13个DNS根IP（rootDNS）服务器信息
全球只有13台路由DNS根服务器，在13台路由服务器中，名字分别为“A”至“M”，其中10台设置在美国，另外各有一台设置于英国、瑞典和日本。下表是这些机器的管理单位、设置地点及最新的IP地址。
A.root-servers.net 198.41.0.4 美国（另支持IPv6）
B.root-servers.net 192.228.79.201 美国
C.root-servers.net 192.33.4.12 法国
D.root-servers.net 128.8.10.90 美国
E.root-servers.net 192.203.230.10 美国
F.root-servers.net 192.5.5.241美国（另支持IPv6）
G.root-servers.net 192.112.36.4 美国
H.root-servers.net 128.63.2.53 美国（另支持IPv6）
I.root-servers.net 192.36.148.17 瑞典
J.root-servers.net 192.58.128.30 美国（另支持IPv6）
K.root-servers.net 193.0.14.129 英国（另支持IPv6）
L.root-servers.net 199.7.83.42 美国（另支持IPv6）
M.root-servers.net 202.12.27.33 日本（另支持IPv6）
更新地址：http://www.internic.net/zones/named.root
为什么要设置自己电脑的DNS地址？
为什么电脑每次启机打开宽带连接都非常缓慢？
启动的时候要手动进行宽带连接
最近不知道怎么了电脑启动后点击“宽带连接”，对话框要等1到2分钟才能弹出来
这个需要改个TCP/IP协议上的IP地址
本地连接状态一直是“受限或无连接“ ，因为你没给NIC一个IP如192.168.0.2，这会影响电脑的响应，特别是在进入桌面之后，电脑会自动分配IP给网卡，大约要花一分半钟，在这期间，任何操作都没反映。
告诉你TCP/IP怎么改
192.168.0.2
255.255.255.0
192.168.0.1
DNS地址怎么天呢？那就要看你是哪的了，请看全国DNS地址大全……
Nslookup命令
定义：Nslookup.exe 是命令行管理工具，用于测试或解决 DNS 服务器问题。此工具是通过“控制面板”与 TCP/IP 协议一起安装的。
作用：查询域名所对应的IP地址
nslookup最简单的用法就是查询域名对应的IP地址，包括A记录和CNAME记录，如果查到的是CNAME记录还会返回别名记录的设置情况。其用法是：
nslookup 域名
ex:
nslookup darpple.3322.org
Server: ns.cache.yntel //反向解释获得使用的DNS服务器的名称,昆明电信的DNS
Address: 222.172.200.68
Non-authoritative answer: //这个结果是从服务器的缓存中得到的,所以提醒是没有权威的应答
Name: darpple.3322.org
Address: 116.54.14.188 //我的机器的ip
ps：若目标域名有别记录，你将看到nslookup不同于ping的地方
ex:
nslookup www.google.cn
nslookup darpple.3322.org
Server: ns.cache.yntel
Address: 222.172.200.68
Non-authoritative answer:
name: cn.1.google.com
Address: 203.208.33.101,203.208.11.100 //不同于ping的地方
Alisases: www.google.cn
参数：
nslookup –qt=类型 目标域名
注意qt必须小写。
类型可以是一下字符，不区分大小写：
A 地址记录(Ipv4)
AAAA 地址记录（Ipv6）
AFSDB Andrew文件系统数据库服务器记录（不懂）
ATMA ATM地址记录（不是自动提款机）
CNAME 别名记录
HINFO 硬件配置记录，包括CPU、操作系统信息
ISDN 域名对应的ISDN号码
MB 存放指定邮箱的服务器
MG 邮件组记录
MINFO 邮件组和邮箱的信息记录
MR 改名的邮箱记录
MX 邮件服务器记录
NS 名字服务器记录
PTR 反向记录（从IP地址解释域名）
RP 负责人记录
RT 路由穿透记录（不懂）
SRV TCP服务器信息记录（将有大用处）
TXT 域名对应的文本信息
X25 域名对应的X.25地址记录
Ex:
D:\>nslookup -qt=ns www.google.cn
Server: ns.cache.yntel
Address: 222.172.200.68
Non-authoritative answer:
www.google.cn canonical name = cn.l.google.com
l.google.com
primary name server = g.l.google.com
responsible mail addr = dns-admin.google.com
serial = 1359794
refresh = 900 (15 mins)
retry = 900 (15 mins)
expire = 1800 (30 mins)
default TTL = 60 (1 min)
使用指定的域名解析服务器进行查询：
在默认情况下nslookup使用的是我们在本机TCP/IP配置中的DNS服务器进行查询，但有时候我们需要指定一个特定的服务器进行查询试验。
nslookup [-qt=type] 目标域名 指定的域名服务器
ex:
D:\>nslookup www.google.com a.gtld-servers.net
(root) nameserver = a.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = b.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = g.root-servers.net
(root) nameserver = k.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = i.root-servers.net
a.root-servers.net internet address = 198.41.0.4
a.root-servers.net AAAA IPv6 address = 2001:503:ba3e::2:30
m.root-servers.net internet address = 202.12.27.33
m.root-servers.net AAAA IPv6 address = 2001:dc3::35
j.root-servers.net internet address = 192.58.128.30
j.root-servers.net AAAA IPv6 address = 2001:503:c27::2:30
b.root-servers.net internet address = 192.228.79.201
l.root-servers.net internet address = 199.7.83.42
g.root-servers.net internet address = 192.112.36.4
k.root-servers.net internet address = 193.0.14.129
k.root-servers.net AAAA IPv6 address = 2001:7fd::1
c.root-servers.net internet address = 192.33.4.12
h.root-servers.net internet address = 128.63.2.53
*** Can’t find server name for address 192.5.6.30: No information
Server: UnKnown
Address: 192.5.6.30
Name: www.google.com
Served by:
– ns1.google.com
216.239.32.10
google.com
– ns2.google.com
216.239.34.10
google.com
– ns3.google.com
216.239.36.10
google.com
– ns4.google.com
216.239.38.10
google.com
D:\>nslookup www.xxx.com ns1.dreamhost.com
Server: ns1.dreamhost.com
Address: 66.33.206.206
Name: www.xxx.com
Address: 4.36.66.178
这个命令直接从顶级域名服务器查询www.google.com的NS记录。所有的二级域名的NS记录都存放在顶级域名服务器中，这是最权威的解释。注意这次没有非授 权结果的提示。对于二级域名的NS记录查询来说这肯定是授权结果。顶级域名服务器的名称是a到j.gtld-servers.net共十台服务 器。(gtld是Global Top Level Domain的缩写)。
各种操作系统下清空DNS缓存方法/命令
微软windows下如何清空DNS缓存
In Microsoft Windows, you can use the command ipconfig /flushdns to flush the DNS resolver cache.
在微软windows下，你可以用命令 ipconfig /flushdns 来清空dns 缓存内容。
You can also use the command ipconfig /displaydns to view the DNS resolver cache.
你也可以用命令 ipconfig /displaydns 来查看dns 缓存内容。
ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
How to Flush DNS in Mac OSX
Mac OSX下如何清空DNS缓存
In Mac OSX, you can use the command lookupd -flushcache to flush the DNS resolver cache.
在Mac OSX中，你可以用这个命令lookupd -flushcache来清空保留的缓存。
bash-2.05a$ lookupd -flushcache
How to Flush DNS in Linux
Linux 下如何清空DNS缓存
In Linux, the nscd daemon manages the DNS cache.
在linux中，nscd进程负责管理DNS缓存。
To flush the DNS cache, restart the nscd daemon.
要清空DNS缓存，重启nscd 守护进程就行了。
To restart the nscd daemon, use the command `/etc/rc.d/init.d/nscd restart`.
要重启nscd 进程，使用命令 /etc/rc.d/init.d/nscd restart
RTMP协议直播推流分析
总体介绍
前一段时间写过一篇文章: iOS直播视频数据采集、硬编码保存h264文件，比较详细的记录了在做iOS端进行视频数据采集和编码的过程，下一步要做的就是RTMP协议推流。因为在公司将RTMP协议用Java 和 Swift 分别实现了一遍，所以对这块比较了解，中间遇到了不少坑，记录下来也怕自己忘掉。
RTMP协议是 Adobe 公司开发的一个基于TCP的应用层协议，Adobe 公司也公布了关于RTMP的规范，但是这个协议规范介绍的有些地方非常模糊，很多东西和实际应用是有差别的。网上也有不少关于这个协议的介绍，但都不是太详细。我遇到的比较好的参考资料就是这篇：带你吃透RTMP, 这篇文章只是在理论上对RTMP进行了比较详细的解释，很多东西还是和实际应用有出入。我这篇文章只是把遇到的一些坑记录下来，并不是详解RTMP消息的。
另外懂RTMP消息拆包分包，而不真正的写写的话是很难把RTMP协议弄得的很清楚，关于RTMP协议的实现也是比较麻烦的事，懂和做事两回事。
另外用wireshark 抓一下包的话可以非常直观的看到RTMP通信的过程，对理解RTMP非常有帮助，在调试代码的时候也大量借助wireshark排错，是一个非常有用的工具。
1. RTMP 握手
RTMP 握手分为简单握手和复杂握手，现在Adobe公司使用RTMP协议的产品应该用的都是复杂握手，这里不介绍，只说简单握手。 按照网上的说法RTMP握手的过程如下
握手开始于客户端发送C0、C1块。服务器收到C0或C1后发送S0和S1。
当客户端收齐S0和S1后，开始发送C2。当服务器收齐C0和C1后，开始发送S2。
当客户端和服务器分别收到S2和C2后，握手完成。
在实际工程应用中，一般是客户端先将C0, C1块同时发出，服务器在收到C1 之后同时将S0, S1, S2发给客户端。S2的内容就是收到的C1块的内容。之后客户端收到S1块，并原样返回给服务器，简单握手完成。按照RTMP协议个要求，客户端需要校验C1块的内容和S2块的内容是否相同，相同的话才彻底完成握手过程，实际编写程序用一般都不去做校验。
RTMP握手的这个过程就是完成了两件事：1. 校验客户端和服务器端RTMP协议版本号，2. 是发了一堆数据，猜想应该是测试一下网络状况，看看有没有传错或者不能传的情况。RTMP握手是整个RTMP协议中最容易实现的一步，接下来才是大头。
2. RTMP 分块
创建RTMP连接算是比较难的地方，开始涉及消息分块（chunking）和 AFM（也是Adobe家的东西）格式数据的一些东西，在上面提到的文章中也有介绍为什要进行RTMP分块。
Chunk Size
RTMP是按照chunk size进行分块，chunk size指的是 chunk的payload部分的大小，不包括chunk basic header 和 chunk message header，即chunk的body的大小。客户端和服务器端各自维护了两个chunk size, 分别是自身分块的chunk size 和 对端 的chunk size, 默认的这两个chunk size都是128字节。通过向对端发送set chunk size 消息告知对方更改了 chunk size的大小，即告诉对端：我接下来要以xxx个字节拆分RTMP消息，你在接收到消息的时候就按照新的chunk size 来组包。
在实际写代码的时候一般会把chunk size设置的很大，有的会设置为4096，FFMPEG推流的时候设置的是 60*1000，这样设置的好处是避免了频繁的拆包组包，占用过多的CPU。设置太大的话也不好，一个很大的包如果发错了，或者丢失了，播放端就会出现长时间的花屏或者黑屏等现象。
Chunk Type
RTMP 分成的Chunk有4中类型，可以通过 chunk basic header的 高两位指定，一般在拆包的时候会把一个RTMP消息拆成以 Type_0 类型开始的chunk，之后的包拆成 Type_3 类型的chunk，我查看了有不少代码也是这样实现的，这样也是最简单的实现。
RTMP 中关于Message 分chunk只举了两个例子，这两个例子不是很具有代表性。假如第二个message和第一个message的message stream ID 相同，并且第二个message的长度也大于了chunk size，那么该如何拆包？当时查了很多资料，都没有介绍。后来看了一些源码，发现第二个message可以拆成Type_1类型一个chunk, message剩余的部分拆成Type_3类型的chunk。FFMPEG中好像就是这么做的。
3. RTMP 消息
关于推流的过程，RTMP的协议文档上给了一个示例，而真实的RTMP通信过程和它有较大的差异，只说推流，RTMP播放端我没有做过。
Connect消息
握手之后先发送一个connect 命令消息，命令里面包含什么东西，协议中没有说，真实通信中要指定一些编解码的信息，这些信息是以AMF格式发送的, 下面是用swift 写的connect命令包含的参数信息：
transactionID += 1 // 0x01
let command:RTMPCommandMessage = RTMPCommandMessage(commandName: “connect”, transactionId: transactionID, messageStreamId: 0x00)
let objects:Amf0Object = Amf0Object()
objects.setProperties(“app”, value: rtmpSocket.appName)
objects.setProperties(“flashVer”,value: “FMLE/3.0 (compatible; FMSc/1.0)”)
objects.setProperties(“swfUrl”, value:””)
objects.setProperties(“tcUrl”, value: “rtmp://” + rtmpSocket.hostname + “/” + rtmpSocket.appName)
objects.setProperties(“fpad”, value: false)
objects.setProperties(“capabilities”, value:239)
objects.setProperties(“audioCodecs”, value:3575)
objects.setProperties(“videoCodecs”, value:252)
objects.setProperties(“videoFunction”,value: 1)
objects.setProperties(“pageUrl”,value: “”)
objects.setProperties(“objectEncoding”,value: 0)
这些信息具体什么意思我也不太明白，协议中也没有，都是我在看librtmp，srs-librtmp这些源码，以及用wireshark 抓包的时候看到的。其中参数少一两个貌似也没问题，但是audioCodecs和videoCodecs这两个指定音视频编码信息的不能少。
服务器返回的是一个_result命令类型消息，这个消息的payload length一般不会大于128字节，但是在最新的nginx-rtmp中返回的消息长度会大于128字节，所以一定要做好收包，组包的工作。
关于消息的transactionID是用来标识command类型的消息的，服务器返回的_result消息可以通过 transactionID来区分是对哪个命令的回应，connect 命令发完之后还要发送其他命令消息，要保证他们的transactionID不相同。
发送完connect命令之后一般会发一个 set chunk size消息来设置chunk size 的大小，也可以不发。
Window Acknowledgement Size 是设置接收端消息窗口大小，一般是2500000字节，即告诉客户端你在收到我设置的窗口大小的这么多数据之后给我返回一个ACK消息，告诉我你收到了这么多消息。在实际做推流的时候推流端要接收很少的服务器数据，远远到达不了窗口大小，所以基本不用考虑这点。而对于服务器返回的ACK消息一般也不做处理，我们默认服务器都已经收到了这么多消息。
之后要等待服务器对于connect的回应的，一般是把服务器返回的chunk都读完组成完整的RTMP消息，没有错误就可以进行下一步了。
Create Stream 消息
创建完RTMP连接之后就可以创建RTMP流，客户端要想服务器发送一个releaseStream命令消息，之后是FCPublish命令消息，在之后是createStream命令消息。当发送完createStream消息之后，解析服务器返回的消息会得到一个stream ID, 这个ID也就是以后和服务器通信的 message stream ID, 一般返回的是1，不固定。
Publish Stream
推流准备工作的最后一步是 Publish Stream，即向服务器发一个publish命令，这个命令的message stream ID 就是上面 create stream 之后服务器返回的stream ID，发完这个命令一般不用等待服务器返回的回应，直接下一步发送音视频数据。有些rtmp库 还会发setMetaData消息，这个消息可以发也可以不发，里面包含了一些音视频编码的信息。
4. 发布音视频
当以上工作都完成的时候，就可以发送音视频了。音视频RTMP消息的Payload中都放的是按照FLV-TAG格式封的音视频包，具体可以参照FLV协议文档。
5. 关于RTMP的时间戳
RTMP的时间戳在发送音视频之前都为零，开始发送音视频消息的时候只要保证时间戳是单增的基本就可以正常播放音视频。我读Srs-librtmp的源码，发现他们是用h264的dts作为时间戳的。我在用java写的时候是先获取了下当前系统时间，然后每次发送消息的时候都与这个起始时间相减，得到时间戳。
6. 关于Chunk Stream ID
RTMP 的Chunk Steam ID是用来区分某一个chunk是属于哪一个message的 ,0和1是保留的。每次在发送一个不同类型的RTMP消息时都要有不用的chunk stream ID, 如上一个Message 是command类型的，之后要发送视频类型的消息，视频消息的chunk stream ID 要保证和上面 command类型的消息不同。每一种消息类型的起始chunk 的类型必须是 Type_0 类型的，表明我是一个新的消息的起始。
作者：devzhaoyou
链接：http://www.jianshu.com/p/00aceabce944
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
不看好5G的14个理由（附精彩辩论）
6月18日，一位网名为“蓝色海岸”的业内人士，先后在c114论坛发文《不懂国内为什么那么看好5G？》，阐述了他不看好5G的8个理由，引发众多移动通信业界人士回帖反驳。6月22日，“蓝色海岸”再发文《不懂国内为什么那么看好5G之二—绝地反击》，阐述了他不看好5G的另外6个理由，再次引发众多移动通信业界人士回帖反驳。
这场辩论很精彩，很多地方都说得有理有据，有些观点/说法也具有一定的思辨性，下文就摘录其中的精彩内容，供大家参考。
网名为“蓝色海岸”的业内人士：
1、5G网速达10G， 不可能，即使能达到，也毫无意义，因为没有需要，现在光宽带的网速，EPON是1000兆，GPON是2500兆，可实际开通的一般是20兆，有很少部分用户开通到了100兆，为什么不开通2500兆，因为没必要，没意义，现在高清视频的带宽一般在2至3兆，就算下载需要更快一点，但也有限，因为人眼和人脑是有带宽的，太高了人的眼睛和大脑接受不了，就没意义了。既然光宽带都不需要那么高的网速，手机会需要吗？手机的屏幕就那么小，4K清晰度有意义吗？超过人眼能够识别的极限，标清和4K不是一样吗？
2、千兆无线路由器早已有之，但是市场反映平淡，很显然，只增加最后一公里的带宽，骨干网带宽不增加，也就没有意义了，这就好比只加宽家门口的马路，不加宽主干街道、国道和省道的公路，速度能提高吗？运营商和设备商就是这样愚弄用户的，说是增加到百兆带宽了，可是实际上只是增加了一点点。
3、服务器和手机的处理能力有限，宽带网一端连接的是服务器，也就是电脑吧，一端连接的是手机，电脑的PCIE总线速度已达6G以上，但是硬盘速度也就几百兆，而且这样一台服务器要连接很多用户，就算把电脑的处理能力全部用于一个用户，极限也就几百兆，而手机的处理能力就更弱了，这时候电脑的处理能力变成瓶颈了，网络两端的速度上不去，只是一味的增加中间部分，会有效果吗？
4、现在5G的宣传都说下载一部高清视频只要几秒云云，实际上只要下载视频的速度大于播放的速度，人就感觉不到网速的快慢，手机是一边放视频，一边下载的，你让手机下载那么快干什么呢？让手机几秒钟下载完，就可以歇着了，你心疼它累吗？
5、九几年的时候，上网很卡，后来带宽增加了，上网不卡了，看视频还是很卡，用的很不爽，运营商就告诉用户，是带宽不足，你要把56K猫换成ADSL，有了ADSL，又说要换光宽带，有了光宽带，又说要换4G,这似乎已经形成习惯和趋势了，实际上，上网和看视频，ADSL足够了。为什么ADSL不行，那是骨干网带宽不足，为什么骨干网带宽不足，是因为运营商之间互掐，以及骨干带宽资费不肯下调。接入网的带宽早已远超需要，GPON,EPON,千兆以太网，千兆无线路由器，10G以太网，这些技术早就成熟了，可是下载高清视频的速度也没有说就几秒啊，5G同样是在接入网段的技术，凭什么这么一个接入网段的技术，就能大幅度的提升网速呢？现在有个口号，叫4G改变生活，5G改变社会，的确，3G的带宽只有2兆多一点，而且是很多人分着用，是少了一点儿，但是4G看来是足够了，在没有Iphone的时候，3G搞了10年也发展不起来，那是因为没有需要，同样的5G想要发展起来，需求在哪里呢？
6、现在有了高清视频，有了1080P，甚至有了4K电视,网络快一点，还是有那么一点点道理，离开了大屏电视，就手机那么一个小小的屏幕，它的显示面积就那么一点点，它要那么大带宽干什么呢？再说了，有多少人在室外一边走路一边抱个手机看电影？恐怕没有吧，一般都是看看微信呀，上个网什么的，就这么点需要，难道上百兆的4G还满足不了？恐怕几兆就足够了吧。
7、我们的网速到底有多快，我可以告诉，平均每个用户就100K多一点，但是这是平均值，实际上由于统计复用的原因，并不是所有人都在不停的占用带宽，而是轮流使用的，所以大家使用的实际带宽还是挺大的，几兆应该是有的，如果用户和服务器同处网络边缘，也就是通过CDN加速，再宽一些也是可以达到的。这就好比马路就那么宽，但并不是所有人都站在马路上一样。你要更宽，那就变成经济问题了， 并不是技术实现的问题，试想如果带宽像空气和阳光一样随处可得，尽管没人离得开空气，可是又有谁能把空气变成钱呢？这种事情运营商会干吗？这就是说有价值并不等于有价格，没有价格也就是没有经济趋动力，没有经济趋动力谁肯干呢？骨干网平均带宽100多K，接入网要上一万兆，这意义又在哪里呢？
8、 这些都撤远了，就说通信行业，九十年代炒的火热的ISDN，那时候互联网还不普及，ISDN可以通两部电话，还可以通可视电话，可是可视电话因为视频压缩算法不过关，带宽低图像质量差，画面小，无法激起消费者的购买欲望，很多公司投入几亿几十亿美金，都丢到水里了。阚凯力阚大炮当时看准了ISDN没有未来，ISDN技术可以在一根电话线上装两部电话，可是他认为只要再接一条电话线就可以办到了，那样显然更便宜，何必为这个要搞一代新技术，更何况有多少家庭会需要两部电话啊？接下来是ATM，ATM把主要吸引点放在视频业务上，结果同样因为视频技术不过关，ATM无用武之地，胎死腹中。
楼主并不是说5G永远没价值，至少是在目前能看得见的未来，价值还体现不出来，这就很危险了，你说现在看不到也想不到的应用，就炒得火热，到处宣传到处试点，搞了几个试点是花了好几亿，这是在糊弄老百姓啊，还是在套取国家资金啊?阚大炮当年认为3G是皇帝的新装，结果3G的投资的确打了水漂，有人辩解说3G积累的技术，在5G时代用得上了，还要领先国际水平，可是阚大炮的眼光是很毒的，被他识破的东西要想翻身如同登天，3G时代积累的那些技术能否用在5G上，看来很大的可能性还得落空。
9、 5G现在的确吹的有点邪乎了，刚开始说要搞1G带宽，后来4G+出来了，能上300多兆，这样看来1G带宽好像也不是什么太有吸引力的概念了，然后就搞出个10G出来，这简直就是放卫星了。固网和光宽带现在实用带宽也就几十兆，现在10G的光宽带也已经实用化了，据说到2019 100G的PON标准也将发布，可是用户实际开通的带宽到底有多少呢？这种脱离实际应用，单纯的技术引导能走得远吗？ 论坛里有人说5G是低延迟，这恐怕说的是基站到用户之间100多米的延迟吧，这100多米产生的延迟在整个通信链路中微不足道，基站到城域网，再到骨干网，用的就是光纤了，请问这段延迟是怎么解决的？这早就超过5G技术的范围了。决定延迟的根本原因，还是在于城域网和骨干网，这都不是5G技术能解决的问题了，你说5G能解决，那就明确说明这部分是怎么解决，你不要说那些通信专家肯定考虑到了，他们到底是怎么考虑的？
5G号称低延迟，连郎咸平都出来说话了，说5G的速度快于人的神经的反应速度，在胳膊上扎一针，大脑还没感觉，5G网另一端就已经知道了，这种说法的确够让人震惊，可是光通信的速度早就有这么快了，可就是没人那么说，这不是故弄玄虚糊弄无知群众么？5G厂商够厉害，连著名经济学家都搬出来造势了。5G要想实现低于光宽带的延迟，那得费九牛二虎之力，这一点连任正飞自己都承认还解决不了，可是媒体上都吹的跟真的一样了。
10、5G所使用的频段是毫米波，在这个波段，电波基本是直线传播，绕射和透射能力都很差了，另外5G基站的覆盖范围也很小，可能只有几百米吧，发射功率和带宽呈正相关，带宽加大，发射功率急剧增加，而手机的发射功率是有限的，这就决定了5G基站的覆盖范围很小，大概100多米到几百米的样子吧（网上有文章号称 5G基站能覆盖20公里，到了那个距离，带带还剩多少，还有什么使用价值，有良心的工程师自己知道），这其实比WIFI的覆盖范围也多不了多少了。面积与覆盖半径的平方成正比，这就意味着5G基站的数量和密度可能是4G的5到10倍，这正是设备商努力鼓吹5G的原因了，可是那么密集的基站，手机即使很低的移动速度，也会频繁切换，而切换又会产生很多的延迟和中断，这些问题又怎么解决？这么多的技术缺陷，注定5G如同无线输电一样，描绘的很好，却是个迟早都会破的大泡沫。
11、再说物联网，物联网是5G炒作者最重要的支撑基础，什么万物互联，物物互联。通信说白了，最重要的指标无非就是延迟、带宽和丢包率，这三个指标是基本指标，光通信这三个指标都远优于5G，在这方面有天生的优势，可以说已到了理想化的程度，对5G来说，那是一道永远也不可能突破的墙，现在5G到处宣传，给人感觉好像是什么划时代的技术，可以轻松超越光通信。WIFI加光宽带足以实现物联网的需要，没有WIFI的地方还可以用4G，没有5G物联就实现不了啦，不会吧，不要尽搞些新概念吓唬人好不好。网上有人说5G的频谱利用率有多高，就这一点足以说明5G是个好技术，请问5G提升频谱利用率的最终目的不就是在有限的频谱内提升带宽吗？可是如果连提升带宽都变得没有意义了，那提高频谱利用率的价值何在呢？
12、有人说楼主不懂，服务器和电脑不一样，服务器里面的硬盘早就使用光纤连接了，但是光纤连接的仍然是硬盘啊，硬盘的速度是瓶颈，你用什么连接速度也上不去，这就是木桶理论了。实际上，现在使用的服务器大多仍是PC机，只是PC机集群而已，但也有极少量的小型机，硬盘仍是最主要的存贮介质，你说可以搞个缓存，那样存取速度就会提高，但那毕竟是极少量的，缓存的容量跟硬盘怎么比啊，那是成千上万倍的差距啊，没有大规模推广的技术，证明是没有商业价值的。
13、有人又说到AR,VR，反正这些技术还没走进人们的生活，大家但吹无妨，这两种技术可能需要三十多兆的带宽，4K高清需要16兆带宽，也就是这样了，这也不需要10G带宽啊，有人又说了，基站的带宽是大家共享的，你以为光宽带的带宽就不是共享的吗？这种AR,VR要戴个大眼镜捂住双眼，你不怕在外面走路会撞电线杆吗？这AR,VR恐怕还只能在家里用用吧，在家里用当然是WIFI和光宽带更好了，5G信号要穿透家里的墙，那丢包率和延迟还不得蹭蹭的往上窜啊。回到物联网的问题，物联网所连的物，绝大部分应该还是在室内吧，室内当然是光宽带和WIFI的地盘了，5G信号穿墙到室内，那信号还不知道差到哪里去了？
14、通信行业这些年的走向，让人摸不着头脑了，就说SDH，明明在延迟、带宽、丢包率三个指标上都远优于PTN，也远优于IP网，却被说成是淘汰技术，许多地方拆了SDH上PTN,结果E1线路经常帧失步，你说这不是在开历史的倒车么？这说明一些人的确可以颠倒黑白，指鹿为马啊？我们还要被那些所谓的技术专家糊弄到哪里去？这已经到了对那些技术专家万分警惕的时刻了，弄不好就会被他们带进坑里去了。
网名为“winnyterry”的业内人士：
唉，再见文科生另一神论，其实论调和理据和上一篇一样，只是写得长了一点。回复较为费时。
首先，这篇神论第一段的逻辑就有问题：楼主的逻辑是：任何技术的发展，都必须先有大需求，再去发展技术。否则就是冒天下之大不讳。但我回忆了一下中学小学学过的中国五千年，和世界近两百年的发展。中国和世界都是在矛盾和失败中前行。人类的每一个成功的发明，一开始的需求其实都和移动通信技术很相似，需求不明显，但发明出来后，这个需求就极之可能变种成爆发式的增涨。
其次，楼主纠结国内为什么看好5G，我想说，移动通信技术从电报通信开始，一直到现在的4.5G，就不只是国内的事，而是全世界的事。5G技术也不只是国内在准备，全世界都在准备，看不看好另说。但如果全世界都5G，就中国4G，我就一定不看好了。中国从电报通信到现在，一直在全球通信产业中都处于模仿跟进付专利费的地位，这个局面直到3G开始有了松动，4G开始有点点的话语权，再到5G话语权又会再增加一点。这种进步对于中国通信产业的意义并不是4G有300Mb/s，5G有1Gb/s这么简单的对比可以概括的了。
再次，wifi与5G对比的问题。坦白说，wifi通信和移动数据通信其实分属于两种不同的群组技术,wifi是计算机通信群组技术，5G是传统移动数据通信技术。这两种技术从2G时代起就一直在对抗，希望获得移动通信的话语权。但自己从传统移动通信技术不停的更新迭代，wifi的速率和容量优势早已不复存在。再加上现在全球特别是中国的通信资费以火箭速度下降，wifi注定在未来是小众应用，只剩下企业内网和大型mall用于宣传之用。根本不可能再回复在2G、3G时代的火爆。可以预料，在5G时代，wifi衰落的速度会更快。作为我本人，从2008年起就很少用到wifi了，除非我所在的那个地方完全没有3、4G信号。但这基本上在我全国跑的经历看，这不可能出现。
最后，我实在无法理解楼主说的：“请问5G提升频谱利用率的最终目的不就是在有限的频谱内提升带宽吗？可是如果连提升带宽都变得没有意义了，那提高频谱利用率的价值何在呢？”再次强调，频谱利用率的要考虑是主要是如何在有限的无线频谱下，容纳更多的并发数据。这点比速率的提升更重要。如果GSM一个载扇能容纳200个客户在线，但WCDMA一个载扇能容纳400个客户在线并能保持超过2G的速率，FDD一个载扇能容纳800个客户在线并能保持3G的速率……你还会认为频谱提升没有意义吗？！
网名为“jeffyko”的业内人士：
个人角度，看5G这个问题，如下几点：
（1）相比4G，物理层上没有重大突破，速率的增加无非是通过更高阶mimo更大带宽来实现，
（2）时延上的改进一是架构的优化，二是芯片技术的提高
（3）iot/mtc未来可能会有很大应用价值，毕竟与每个人的生活息息相关
（4）如楼主所述，路铺的宽又如何，应用在哪里？
所以，不要把5g吹的太悬，最终它也要走下神坛。如同volte一样
网名为“winnyterry”的业内人士：
唉，又见文科生神论！通篇的着眼点只有：速度。太片面了。每一代移动通信技术的革新，其它有三点是最重要的，按重要程度排序是：频谱利用率，时延，网速。
频谱资源不论什么时代在移动通信领域都是最为稀缺的，如何在有限不可再生的无线频谱下，容纳更多的并发数据，这是每一代移动通信进步最重要的出发点。特别是物联网时代，万物互联，频谱利用率不提高，一切都是空谈。
其次是时延，现在4g时延基本上能在20毫秒内，对于打游戏，是够了，但如果是VR应用和智能导航呢，又太慢了，测试要在8毫秒内，智能导航才不会错过执行指令的最佳时点。而5g据说时延能控制在5毫秒内。
而网速仅仅是每一代移动通信技术中重要性排在第三位的，可以说只是在提高频谱利用率和降低时延时顺便提高一下而已。对于用户而言，网速的感知最为明显，运营商设备商的宣传着墨于此不难理解，而前面的两点对于用户的感知远远没有第三点的网速明显，但切勿因此就认为移动通信技术就只是网速的提高，这样就大错特错了。
网名为“heipang”的业内人士：
有人说楼主是文科生观点，其实很多通信业内从业多年的人也会有类似观点。说几个自己的想法：
1. 视频是推动宽带发展的需求，但真的作用有限，有些厂商在大肆鼓吹视频和IPTV，其实无非是想多卖设备带宽，体验、运维这些问题在IP网络里没有提供有效的方案解决。
2. 有些需求真的是我们普通上班族体验不到的，每天早出晚归，三四十岁的人了，哪有时间玩游戏，VR/AR这些将来一定对网络的质量要求很高，也许要等到它们渗透到每个生活的角落，你才能感受到。
3. 物联网，个人觉得在部分场景里用处比较大，比如工业、农业、娱乐园区里，家里那点东西真的需要都联网么，有那个精力多陪孩子读点书吧。
4. 法律法规的建设如果不完善，大家怎么放心去联网，家里装个IP摄像头被入侵了咋办，放在云上的视频被流出怎么办：）当然这个担心有点多余，我们的发展模式一直都是野蛮生长再逐步约束。
网名为“risse”的业内人士：
不知道楼主为何这么抵触。带宽大延迟低，不好吗？难道想回到56K的时代？一张图片显示出来都要10来秒！
标清、高清、4K的视频真的是有很大的差别，不要看到现在网站上的在线播放视频，那些都是压缩了的，只是分辨率没有变而已，有机会你下载北京烤鸭完整版的4K视频看看，就知道区别了。
看了你所说的那么多，感觉你就像老一辈的那种没技术的技术而已。
时代的进步，离不开网络的发展，2G的时候你用手机玩游戏？3G的时候你用手机看视频？4G的时候这些都有了吧！5G的时候就不是简简单单的这些应用了。
网名为“jiu_mao”的业内人士：
各位，技术发展和业务的发展是相辅相成的，没有业务强有力的驱动，不会这么快产生一代又一代的通信技术的。5G也是如此，相信现在有很多炒作的概念，但我觉得更主要的动力还是来自于整个社会的进步、人们更高的需求。
楼主，从你鼓吹5G不如wifi加光宽带这一点来看，我觉得你可能是资深的工程师，但绝不会是移动通信相关的工程师！
网名为“frewave”的业内人士：
3GPP定义的5G最大速度是20G，这是指整个基站的速率，分配到个人的没那么多，5G的进步是通过新的技术极大提升频谱效率和基站容量，对于现有的技术，运营商为何不敢像固网那样包月？到了5G极快的的速率，低廉甚至包月的流量，极大的扩展了移动互联网的使用范围（包括万物互联），这些比固网更便利，基础设施上去了，应用才能推广，在2G时代，不可能有微信这类的应用。对于VR、AR这些应用，就像3G时代的智能手机，只有硬件条件到了，才会推广应用。4K的VR只是入门，楼主说的十几兆就够了，这是经过200倍的视频压缩比才能到的，在对延迟不敏感的视频场景问题不大，对直播或游戏就有问题了，这也是为何HTC的VR要有线连接。一两年后8K的VR才是基本配置。
楼主可能只是做固网的，对移动通信的理解还是不深！
网名为“lovebugzhang”的业内人士：
我觉得楼主还是有很多地方没理解上一贴那么多人反驳你的地方，特别是对频谱利用率，还有服务器的传输速度的理解有点问题。5G有很多优势，，低延迟只是其中之一，而且你逻辑并不清晰，低延迟是优势，自动驾驶是应用，不可混为一谈．你不可能因为自动驾驶这个应用距目前太遥远，就认为整个5G是忽悠的．
网名为“winddt”的业内人士：
立场影响观点。
在4G时代，就有wifi+光取代LTE的说法，结果大家都清楚了，各自都发展的很好。这个时代是你可以发展的很好，但你的光芒不是一定要让别人暗淡无光。
5G时代，wifi+光本就已经纳入5G系统的一部分了，这个在去年的IEEE802会议上已经确定了，以前还可以说lte和wifi两者互为补充，5G时代移动宽带和无线宽带深度融合，均成为整个5G系统的的重要组成部分。
网名为“cano”的业内人士：
之前在公众号上看过一篇关于5G的批评文章，有理有据，深以为然。这次本来是抱着寻找同道中人的念头入坑，没想到大失所望。
拜读了LZ第一篇文章之后，我就有了一个猜测，也闻到了一股熟悉的味道。在读了第二篇后，我觉得，我的猜测和那股味道终于被证实了。
楼主应该是搞固网接入和光通信的吧，从这两篇中大谈ISDN、ADSL、EPON、GPON、STN、PTN这些就能看出来。另外，楼主应该是北邮某教授的铁粉吧，第一篇中只是闻到的味道，第二篇中直接就点出了，呵呵。不过自从在某教授狂喷3G的文章中发现一个初中生都不会错的大漏洞后，我和某教授的文章基本就拜拜了。
我觉得LZ对于无线通信的基础知识，对于5G的基本目标和场景都缺乏最基本的认识。
有线通信和无线通信最大的不同在于信道。有线通信可以毫不费力的搞到一组正交信道，无线就要头拱地；有线通信发现一根管子不够了，再加一根就是了，无线还是头拱地……
对于5G的三大场景，或许那些回复也没说清楚，还请LZ自己回去看看。另外，请楼主注意，现在4G的基站也是对用户数和并发业务数有限制的，而且没你想象的那么多。