1700479213
1700479214
与责任链模式中的场景类很相似。读者请注意sh.update（null,recorder）这句代码，这是我们虚拟了观察者触发动作，完整的做法是把场景类作为一个被观察者，然后设置观察者为上海DNS服务器，再进行测试，其结果完全相同，我们这里为减少代码量采用了简化处理，有兴趣的读者可以扩充实现。
1700479215
1700479216
我们来看看运行结果如何，结果如下所示：
1700479217
1700479218
=====域名解析模拟器=====
1700479219
1700479220
请输入域名（输入N退出）：www.xxx.sh.cn
1700479221
1700479222
–-DNS服务器解析结果–-
1700479223
1700479224
域名：www.xxx.sh.cn
1700479225
1700479226
IP地址：197.15.34.227
1700479227
1700479228
解析者：上海DNS服务器
1700479229
1700479230
请输入域名（输入N退出）：www.xxx.com.cn
1700479231
1700479232
–-DNS服务器解析结果–-
1700479233
1700479234
域名：www.xxx.com.cn
1700479235
1700479236
IP地址：201.177.148.99
1700479237
1700479238
解析者：上海DNS服务器
1700479239
1700479240
请输入域名（输入N退出）：www.xxx.com
1700479241
1700479242
–-DNS服务器解析结果–-
1700479243
1700479244
域名：www.xxx.com
1700479245
1700479246
IP地址：251.41.14.230
1700479247
1700479248
解析者：上海DNS服务器
1700479249
1700479250
请输入域名（输入N退出）：n
1700479251
1700479252
可以看出，所有的解析结果都是由上海DNS服务器返回的，这才是真正的DNS解析过程。如何知道它是由上海DNS服务器解析的还是由别的DNS服务器解析的呢？很好办，把代码拷贝过去，然后调试跟踪一下就可以了。或者仔细看看代码，理解一下代码逻辑也可以非常清楚地知道它是如何解析的。
1700479253
1700479254
再仔细看一下我们的代码逻辑，上下两个节点之间的关系很微妙，很有意思。
1700479255
1700479256
❑下级节点对上级节点顶礼膜拜
1700479257
1700479258
比如我们输入的这个域名www.xxx.com，上海域名服务器只知道它是由父节点（中国顶级DNS服务器）解析的，而不知道父节点把该请求转发给了更上层节点（全球顶级DNS服务器），也就是说下级节点关注的是上级节点的响应，只要是上级反馈的结果就认为是上级的。www.xxx.com这个域名最终是由最高节点（全球顶级DNS服务器）解析的，它把解析结果传递给第二个节点（中国顶级DNS服务器）时的签名为“全球顶级DNS服务器”，而第二个节点把请求传递给首节点（上海DNS服务器）时的签名被修改为“中国顶级DNS服务器”。所有从上级节点反馈的响应都认为是上级节点处理的结果，而不追究到底是不是真的是上级节点处理的。
1700479259
1700479260
❑上级节点对下级节点绝对信任
1700479261
1700479262
上级节点只对下级节点负责，它不关心下级节点的请求从何而来，只要是下级发送的请求就认为是下级的。还是以www.xxx.com域名为例，当最高节点（全球顶级DNS服务器）获得解析请求时，它认为这个请求是谁的？当然是第二个节点（中国顶级DNS服务器）的，否则它也不会把结果反馈给它，但是这个请求的源头却是首节点（上海DNS服务器）的。
[
上一页 ]
[ :1.700479213e+09 ]
[
下一页 ]