[网络协议]还在为面试官问到的HTTP协议的面试题而抓耳挠腮吗？

常见的HTTP请求头

1. Accept
   Accept: text/html 浏览器可以接受服务器回发的类型为 text/html。
   Accept: / 代表浏览器可以处理所有类型,(一般浏览器发给服务器都是发这个)。

2. Accept-Encoding
   Accept-Encoding: gzip, deflate 浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate），（注意：这不是只字符编码）。

3. Accept-Language
   Accept-Language:zh-CN,zh;q=0.9 浏览器申明自己接收的语言。

4. Connection
   Connection: keep-alive 当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。
   Connection: close 代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭， 当客户端再次发送Request，需要重新建立TCP连接。

5. Host（发送请求时，该报头域是必需的）
   Host:www.baidu.com 请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的。

6. Referer
   Referer:https://www.baidu.com/?tn=62095104_8_oem_dg 当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。

7. User-Agent
   User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36 告诉HTTP服务器， 客户端使用的操作系统和浏览器的名称和版本。

8. Cache-Control
   Cache-Control:private 默认为private 响应只能够作为私有的缓存，不能再用户间共享
   Cache-Control:public 响应会被缓存，并且在多用户间共享。正常情况, 如果要求HTTP认证,响应会自动设置为 private.
   Cache-Control:must-revalidate 响应在特定条件下会被重用，以满足接下来的请求，但是它必须到服务器端去验证它是不是仍然是最新的。
   Cache-Control:no-cache 响应不会被缓存,而是实时向服务器端请求资源。
   Cache-Control:max-age=10 设置缓存最大的有效时间，但是这个参数定义的是时间大小（比如：60）而不是确定的时间点。单位是[秒 seconds]。
   Cache-Control:no-store 在任何条件下，响应都不会被缓存，并且不会被写入到客户端的磁盘里，这也是基于安全考虑的某些敏感的响应才会使用这个。

9. Cookie
   Cookie是用来存储一些用户信息以便让服务器辨别用户身份的（大多数需要登录的网站上面会比较常见），比如cookie会存储一些用户的用户名和密码，当用户登录后就会在客户端产生一个cookie来存储相关信息，这样浏览器通过读取cookie的信息去服务器上验证并通过后会判定你是合法用户，从而允许查看相应网页。当然cookie里面的数据不仅仅是上述范围，还有很多信息可以存储是cookie里面，比如sessionid等。

10. Range（用于断点续传）
    Range:bytes=0-5 指定第一个字节的位置和最后一个字节的位置。用于告诉服务器自己想取对象的哪部分。八种HTTP请求

八种HTTP请求

• OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*'的请求来测试服务器的功能性。
• HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
• GET：向特定的资源发出请求。
• POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改。
• PUT：向指定资源位置上传其最新内容。
• DELETE：请求服务器删除 Request-URI 所标识的资源。
• TRACE：回显服务器收到的请求，主要用于测试或诊断。
• CONNECT：HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。

get和Post的区别

本质上只有报文头不同，预检请求（框架或者浏览器的行为）。

浏览器定义的区别

长度，参数能否保留在浏览器中，编码类型

OPTIONS预检请求

OPTIONS请求即预检请求，可用于检测服务器允许的http方法。当发起跨域请求时，由于安全原因，触发一定条件时浏览器会在正式请求之前自动先发起OPTIONS请求，即CORS预检请求，服务器若接受该跨域请求，浏览器才继续发起正式请求。

简单请求

不会触发CORS预检的请求称为简单请求，满足以下所有条件的才会被视为简单请求，基本上我们日常开发只会关注前面两点

1. 使用GET、POST、HEAD其中一种方法

2. 只使用了如下的安全首部字段，不得人为设置其他首部字段
   Accept
   Accept-Language
   Content-Language
   Content-Type仅限以下三种
   text/plain
   multipart/form-data
   application/x-www-form-urlencoded
   HTML头部header field字段：DPR、Download、Save-Data、Viewport-Width、WIdth

3. 请求中的任意XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload
   对象可以使用 XMLHttpRequest.upload 属性访问

4. 请求中没有使用 ReadableStream 对象

预检请求

需预检的请求要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。“预检请求” 的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响
下面的请求会触发预检请求，其实非简单请求之外的就会触发预检，就不用记那么多了

1. 使用了PUT、DELETE、CONNECT、OPTIONS、TRACE、PATCH方法
2. 人为设置了非规定内的其他首部字段，参考上面简单请求的安全字段集合，还要特别注意Content-Type的类型
3. XMLHttpRequestUpload 对象注册了任何事件监听器
4. 请求中使用了ReadableStream对象

CORS参数

• Access-Control-Allow-Methods 表明服务器允许客户端使用的请求方法
• Access-Control-Allow-Headers 表明服务器允许请求中携带的头部字段
• Access-Control-Max-Age 表明响应的有效时间。在有效时间内，浏览器无须为同一请求再次发起预检请求
• Access-Control-Expose-Headers 服务器允许浏览器访问的头信息白名单
• Access-Control-Allow-Credentials
  指定了当浏览器的credentials设置为true时是否允许浏览器读取response的内容

原生HTTP请求

//创建一个XMLHttpRequest对象
var xhr = new XMLHttpRequest();
//监听statechange事件
xhr.onreadystatechange = function() {
/** * XMLHttpRequest的readystate有五个状态
0 还没有调用open方法
1 已调用open方法，尚未调用send方法
2 已调用send，但尚未接收到响应
3 已接收到部分响应数据
4 已经接收到到全部数据，而且可以在客户端使用
*/
if (xhr.readystate == 4) {
//状态码在200 到 300表示请求成功，状态码304表示资源没有被修改，可以直接使用缓存中的版本
if ((xhr.status >=200 && xhr.status < 300) || xhr.status == 304))
{ alert(xhr.responseText); }
else {
//发生错误打印状态码，
alert("Request was unsuccessful: " + xhr.status); } } }
//打开请求以备发送
xhr.open('post', 'http://example.com', false);
//设置请求头
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
//序列化表单
var form = document.getElementById('test-form');
//发送请求 xhr.send(serialize(form));

• 创建XMLHttpRequest对象(这里需要兼容，IE7之前的是ActiveXObject对象)
• 设置回调函数
• open()
• 设置请求的头部
• send()
• 更新页面显示

http 与 tcp 的关系

http是一种应用层协议，它使用tcp协议提供的服务。tcp协议是一种传输层协议，它使用ip协议提供的服务。ip协议是一种网络层协议。

tcp 可以建立多个连接吗？一个 TCP 连接中 HTTP 请求发送可以一起发送么？

在 HTTP/1.1 存在 Pipelining 技术可以完成这个多个请求同时发送，但是由于浏览器默认关闭，所以可以认为这是不可行的。在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行。

一个 TCP 连接可以对应几个 HTTP 请求？

服务器对 Connection: keep-alive 的 Header 进行了支持。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免。默认情况下建立 TCP 连接不会断开，只有在请求报头中声明 Connection: close 才会在请求完成后关闭连接
(SSL 是指安全套接字层，简而言之，它是一项标准技术，可确保互联网连接安全，保护两个系统之间发送的任何敏感数据)

什么是“3次握手，4次挥手”

TCP是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如ip地址、端口号等。
TCP可以看成是一种字节流，它会处理IP层或以下的层的丢包、重复以及错误问题。在连接的建立过程中，双方需要交换一些连接的参数。这些参数可以放在TCP头部。
TCP提供了一种可靠、面向连接、字节流、传输层的服务，采用三次握手建立一个连接。采用4次挥手来关闭一个连接。

TCP握手协议
在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接.
第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；
SYN：同步序列编号(Synchronize Sequence Numbers)
第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手

UDP 和 TCP 的特点与区别

用户数据报协议 UDP（User Datagram Protocol）

是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。

传输控制协议 TCP（Transmission Control Protocol）

是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。

TCP 可靠传输/滑动窗口/流量控制/拥塞控制
为什么要“三次握手，四次挥手”

经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。
TCP连接是双向传输的对等的模式，就是说双方都可以同时向对方发送或接收数据。当有一方要关闭连接时，会发送指令告知对方，我要关闭连接了。这时对方会回一个ACK，此时一个方向的连接关闭。但是另一个方向仍然可以继续传输数据，等到发送完了所有的数据后，会发送一个FIN段来关闭此方向上的连接。接收方发送ACK确认关闭连接。

ES6 fetch 和ajax的区别

Ajax 的本质是使用XMLHTTPRequest对象来请求数据
fetch是window的一个方法，它的主要特点有：
1.第一个参数是URL：
2.第二个参数是可选参数，可以控制不同配置的init对象
3.使用Promise来处理回调
区别：
fetch 因为是返回Promise 即使是400 或者 500 也会正常解决，并且仅在网络故障时或者任何阻止请求完成时才会拒绝
默认情况下fetch在服务端不会发送或接收任何cookies
Fetch 终止 abortController

XSS攻击：用户输入当成脚本执行

输入过滤

做 HTML 转义
对于链接跳转，如 <a href=“xxx” 或 location.href=“xxx”，要检验其内容，禁止以 javascript: 开头的链接，和其他非法的 scheme。
改成纯前端渲染，把代码和数据分隔开。

种类

储存性XSS：攻击者将恶意代码提交到目标网站的数据库中。
反射型 XSS: XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。
DOM 型 XSS :DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

跨站请求伪造

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
GET类型的CSRF
在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。
POST类型的CSRF
这种类型的CSRF利用起来通常使用的是一个自动提交的表单。
POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面。链接类型的CSRF，这种需要用户点击链接才会触发。

防护策略

阻止不明外域的访问

• 同源检测
• Samesite Cookie 提交时要求附加本域才能获取的信息
• CSRF Token
• 双重Cookie验证
  使用Referer Header确定来源域名
  根据HTTP协议，在HTTP头中有一个字段叫Referer，记录了该HTTP请求的来源地址。 对于Ajax请求，图片和script等资源请求，Referer为发起请求的页面地址。对于页面跳转，Referer为打开页面历史记录的前一个页面地址。因此我们使用Referer中链接的Origin部分可以得知请求的来源域名。
  Token是一个比较有效的CSRF防护方法，只要页面没有XSS漏洞泄露Token，那么接口的CSRF攻击就无法成功。
  但是此方法的实现比较复杂，需要给每一个页面都写入Token（前端无法使用纯静态页面），每一个Form及Ajax请求都携带这个Token，后端对每一个接口都进行校验，并保证页面Token及请求Token一致。这就使得这个防护策略不能在通用的拦截上统一拦截处理，而需要每一个页面和接口都添加对应的输出和校验。这种方法工作量巨大，且有可能遗漏。

谈谈http1.0 http1.1 http2.0 http3

TCP是Tranfer Control Protocol的 简称，是一种面向连接的保证可靠传输的协议。通过TCP协议传输，得到的是一个顺序的无差错的数据流。发送方和接收方的成对的两个socket之间必须建 立连接，以便在TCP协议的基础上进行通信，当一个socket（通常都是server socket）等待建立连接时，另一个socket可以要求进行连接，一旦这两个socket连接起来，它们就可以进行双向数据传输，双方都可以进行发送 或接收操作。
UDP是User Datagram Protocol的简称，是一种无连接的协议，每个数据报都是一个独立的信息，包括完整的源地址或目的地址，它在网络上以任何可能的路径传往目的地，因此能否到达目的地，到达目的地的时间以及内容的正确性都是不能被保证的。

HTTP3

QUIC 丢掉了 TCP、TLS 的包袱，基于 UDP，并对 TCP、TLS、HTTP/2 的经验加以借鉴、改进，实现了一个安全高效可靠的 HTTP 通信协议。凭借着 0 RTT 建立连接、平滑的连接迁移、基本消除了队头阻塞、改进的拥塞控制和流量控制等优秀的特性，QUIC 在绝大多数场景下获得了比 HTTP/2 更好的效果。

HTTP1.0和1.1现存的一些问题

1. HTTP1.x在传输数据时，每次都需要重新建立连接，无疑增加了大量的延迟时间，特别是在移动端更为突出。
2. HTTP1.x在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，这在一定程度上无法保证数据的安全性。
3. HTTP1.x在使用时，header里携带的内容过大，在一定程度上增加了传输的成本，并且每次请求header基本不怎么变化，尤其在移动端增加用户流量。
4. 虽然HTTP1.x支持了keep-alive，来弥补多次创建连接产生的延迟，但是keep-alive使用多了同样会给服务端带来大量的性能压力，并且对于单个文件被不断请求的服务(例如图片存放网站)，keep-alive可能会极大的影响性能，因为它在文件被请求之后还保持了不必要的连接很长时间。

HTTP2.0的新特性

1. 新的二进制格式（Binary
   Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
2. 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的
   id将request再归属到各自不同的服务端请求里面。
3. header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header
   fields表，既避免了重复header的传输，又减小了需要传输的大小。
4. 服务端推送（server push），HTTP2.0具有server push功能。

http1和http2的区别（多路复用，头部压缩的原理）

• 新的二进制格式（Binary
  Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
• 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的
  id将request再归属到各自不同的服务端请求里面。原理：HTTP/2是基于二进制“帧”的协议，HTTP/1.1是基于“文本分割”解析的协议。帧的字节中保存了不同的信息，前9个字节对于每个帧都是一致的，“服务器”解析HTTP/2的数据帧时只需要解析这些字节，就能准确的知道整个帧期望多少字节数来进行处理信息。如果使用HTTP/1.1的话，你需要发送完上一个请求，才能发送下一个；由于HTTP/2是分帧的，请求和响应可以交错甚至可以复用。HTTP/2连接上独立的、双向的帧序列交换。流ID（帧首部的6-9字节）用来标识帧所属的流
• header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header
  fields表，既避免了重复header的传输，又减小了需要传输的大小。原理：* 维护一份相同的静态字典（Static
  Table），包含常见的头部名称，以及特别常见的头部名称与值的组合；* 维护一份相同的动态字典（Dynamic
  Table），可以动态地添加内容；* 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）；
• 服务端推送：服务器推送（server push）指的是，还没有收到浏览器的请求，服务器就把各种资源推送给浏览器。

优势：

HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升

HTTPS和HTTP

https + 注意点

超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。
HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。
HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
简而言之: HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版
TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

HTTPS原理

• 服务端把自己的信息以数字证书的形式返回给客户端（证书内容有密钥公钥，网站地址，证书颁发机构，失效日期等）。证书中有一个公钥来加密信息，私钥由服务器持有。
• 验证证书的合法性 客户端收到服务器的响应后会先验证证书的合法性（证书中包含的地址与正在访问的地址是否一致，证书是否过期）。
• 生成随机密码（RSA签名） 如果验证通过，或用户接受了不受信任的证书，浏览器就会生成一个随机的对称密钥（session
  key）并用公钥加密，让服务端用私钥解密，解密后就用这个对称密钥进行传输了，并且能够说明服务端确实是私钥的持有者。
• 生成对称加密算法
  验证完服务端身份后，客户端生成一个对称加密的算法和对应密钥，以公钥加密之后发送给服务端。此时被黑客截获也没用，因为只有服务端的私钥才可以对其进行解密。之后客户端与服务端可以用这个对称加密算法来加密和解密通信内容了。

HTTP 与 HTTPS 的区别

• HTTP 是明文传输，HTTPS 通过 SSL\TLS 进行了加密
• HTTP 的端口号是 80，HTTPS 是 443
• HTTPS 需要到 CA 申请证书，一般免费证书很少，需要交费
• HTTP 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP
  协议安全。

HTTPS主要作用是：

• 对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全
• 对网站服务器进行真实身份认证

HTTPS缺点:

• HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
• https连接缓存不如http高效，如果是大流量网站,则会造成流量成本太高。
• https连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本，如果全部采用https，基于大部分计算资源闲置的假设的VPS的平均成本会上去。
• SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
• SSL证书通常需要绑定IP，不能再同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗(SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows
  XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用)。

dns查询的过程

（迭代/递归）一般采用递归
递归： 递归查询时如果客户端所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他顶级域名服务器继续发出查询，直到查询到结果后，再层层传递回来。
迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。
然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。
顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。
最后，知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机。
递归：客户端只发一次请求，要求对方给出最终结果。
迭代：客户端发出一次请求，对方如果没有授权回答，它就会返回一个能解答这个查询的其它名称服务器列表，
客户端会再向返回的列表中发出请求，直到找到最终负责所查域名的名称服务器，从它得到最终结果。
授权回答：向dns服务器查询一个域名，刚好这个域名是本服务器负责，返回的结果就是授权回答。
从递归和迭代查询可以看出：
客户端-本地dns服务端：这部分属于递归查询。（定义）
本地dns服务端---外网：这部分属于迭代查询。
递归查询时，返回的结果只有两种:查询成功或查询失败。
迭代查询，又称作重指引,返回的是最佳的查询点或者主机地址。

实际上，在DNS查询过程中，客户端和服务器也都会加入缓存的机制，这样可以减少查询的次数，加快域名解析过程。当我们在浏览器中输入一个网站时，会发生如下过程

1. 浏览器中输入想要访问的网站的域名，操作系统会先检查本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2. 如果hosts里没有这个域名的映射，客户端会向本地DNS服务器发起查询。本地DNS服务器收到查询时，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析。
3. 如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置，采用递归或者迭代查询，直至解析完成。

websocket/轮询的好处和缺点（性能、兼容性）

短轮询
定义：其实就是普通的轮询。指在特定的的时间间隔（如每1秒），由浏览器对服务器发出HTTP request，然后由服务器返回最新的数据给客户端的浏览器。
应用场景：传统的web通信模式。后台处理数据，需要一定时间，前端想要知道后端的处理结果，就要不定时的向后端发出请求以获得最新情况。
优点：前后端程序编写比较容易。
缺点：请求中有大半是无用，难于维护，浪费带宽和服务器资源；响应的结果没有顺序（因为是异步请求，当发送的请求没有返回结果的时候，后面的请求又被发送。而此时如果后面的请求比前面的请 求要先返回结果，那么当前面的请求返回结果数据时已经是过时无效的数据了）。
实例：适于小型应用。

长轮询
定义：客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。
优点：在无消息的情况下不会频繁的请求，耗费资源小。
缺点：服务器hold连接会消耗资源，返回数据顺序无保证，难于管理维护。

WebSocket
定义：Websocket是基于HTTP协议的，在和服务端建立了链接后，服务端有数据有了变化后会主动推送给前端。
优点：请求响应快，不浪费资源。（传统的http请求，其并发能力都是依赖同时发起多个TCP连接访问服务器实现的(因此并发数受限于浏览器允许的并发连接数)，而websocket则允许我们在一条ws连接上同时并发多个请求，即在A请求发出后A响应还未到达，就可以继续发出B请求。由于TCP的慢启动特性（新连接速度上来是需要时间的），以及连接本身的握手损耗，都使得websocket协议的这一特性有很大的效率提升；http协议的头部太大，且每个请求携带的几百上千字节的头部大部分是重复的，websocket则因为复用长连接而没有这一问题。）
缺点：主流浏览器支持的Web Socket版本不一致；服务端没有标准的API