应用层协议之DNS协议

一.应用层协议的相关数据传输格式

1.文本字符串格式

应用层主要是自定义协议，以点外卖为例：

客户点开软件，就是应用程序和服务器之间进行网络通信交互。请求和响应可以如下设置

请求：用户信息，位置信息，并使用文本的方式，用逗号分隔->10011，100E，30W。代码中就会构造出这样的字符串，写到TCP/UDP的Socket api中

响应：有多个商家，每个商家都是商家名称+饭菜图+距离+简介+评分，同理用文本的方式，每个商家占一行，用逗号分割。

上述就是自定义协议，方式灵活。而上述通过文本构造协议的方式是比较粗糙的方式，下面就介绍几种开发中常见的格式

2.xml格式

这也算是很老式的一种方式了

该格式的关键是既有开始标签，又有结束标签，结束标签就是在开始标签的前面再加一个反斜杠，例如下面的请求格式

<request>

      <userid>10011</userid>

      <position>100e.30w<</position>

</request>

上下两个request之间就是要传输的数据

xml的优势：让数据的可读性加强

xml的劣势：标签写起来繁琐，同时在网络传输过程中要消耗一定的带宽

3.json格式

这时当下最流行的数据组织格式。格式如下：

{

    userid :"10011",

    position:"100,30"

}

它采用的是键值对结构，外面的花括号把所有的键值对都包裹起来。键（就是key，就是这里的userid）固定使用字符串形式，也就是String类型，值可以是数字，可以是字符串，也可以是数组，还可以是json对象……。两对键值对之间用逗号分隔，键和值之间用冒号分隔，键是字符串但引号可以省略。

优势：可读性好，比xml简洁（因为只有一个标签，没有结束标签）

劣势：在网络传输中消耗一定的带宽（因为key也得传）

虽然有劣势，但是json再网络通信时仍然非常流行，除非性能要求很高的场景

4.protobuffer

这里与json和xml不同的是，它是以二进制的形式组织数据

优势：二进制形式组织，占用带宽最低，传输效率最高，计算机的执行效率最高

劣势：可读性差，降低了开发效率

相比于计算机的执行效率，更重要的还是程序员的开发效率，所以json更流行

二.DNS协议

DNS 即domain name system表示域名解析系统。

1.域名

我们之前说过，在网络上是使用IP地址来表示一个设备在网络上的位置。但是开发网站的关键是有人乐意使用，然而IP这种二进制的形式却不适合进行宣传。

所以就引入了域名的概念：它实际上是用单词组成的，能够表示实际意义，比如www.baidu.com

这就需要有一套自动系统来将域名翻译成IP。

2.hosts文件

最早的域名解析系统，是通过hosts文件实现的

通过这个路径可以找到我们电脑上的host文件

但是打开发现其实里面没啥东西，因为这个机制现在基本上不用了，因为用hosts文件来维护域名与IP地址的映射真的很不方便，每次有一个新的IP地址，就得把每个用户电脑里面的hosts文件进行手动更新。

所以就有了DNS协议

3.工作流程

DNS系统是一组服务器，要想访问某个域名，就要给此DNS服务器发送请求，查询当前域名对应的IP地址。后续若有域名更新，只需要更新这一组服务器即可，不需要修改每个用户的hosts文件

问题：全世界，无时无刻有很多台设备进行DNS请求。那么这一组服务器能抗住这么多请求量吗？一个服务器硬件资源（cpu，内存，硬盘，网络带宽……）优先，单位时间内请求太多，小号的粽子元超过了机器本身的资源上线，就会挂了。那该如何解决？

核心思路：开源，节流

1.开源：搭建DNS的大佬们，号召每个网络运营商都自己搭建一组“DNS镜像服务器”，其中的数据从它们那里同步。此时用户就会邮上线访问离自己最近的DNS镜像服务器。此时，原始DNS服务器就称作根服务器

2.节流：让请求量变少。让美国上网设备，搞一个本地缓存（例如：我的电脑一分钟要访问10次www.baidu.com，那我只让第一次请求DNS即可，然后把结果存到缓存中，后9次都是用第一次的结果