请求方式
1. http 的请求方式有哪些?分别用在哪些场景下?*
- GET:用于向服务器请求指定资源,一般用于获取数据。
- POST:用于向服务器提交数据,一般用于提交表单数据、上传文件等。
- PUT:用于向服务器更新指定资源,一般用于更新数据。
- DELETE:用于向服务器删除指定资源,一般用于删除数据。
- OPTIONS:用于获取目标资源所支持的通信选项,一般用于跨域请求前的预检请求。
2. GET 和 POST 有什么区别?*
-
使用场景:
GET 请求只能进行简单的查询操作,而 POST 请求可以进行更复杂的操作,如上传文件、提交表单等。
-
参数传递 GET 请求通过 URL 传递数据,而 POST 请求通过请求体传递数据,GET 请求的数据量有限制,因为 URL 的长度有限制,一般为 2048 个字符,而 POST 请求的数据量没有限制。
-
缓存 GET 请求的数据可以被缓存,因为 GET 请求的 URL 可以被浏览器缓存,而 POST 请求的数据不会缓存。
-
安全性 GET 请求对数据安全性要求低,因为 GET 请求的数据会暴露在 URL 中,可以被他人轻易获取,而 POST 请求的数据在请求体中,相对而言更加安全。
3. POST 和 PUT 有什么区别?*
- POST 请求用于向服务器提交数据,通常会创建新的资源,而 PUT 请求用于向服务器更新数据,通常会修改已有的资源。
4. OPTIONS请求方法以及使用场景?*
OPTIONS 请求通常用于跨域资源共享(CORS)中的预检操作,它会在实际请求之前发送到服务器,以便查看服务器是否支持实际请求的方法和头部信息等。
在跨域请求中,浏览器会先发送一个 OPTIONS 请求到目标服务器,请求中包含了 Origin 头部字段,询问服务器是否支持跨域请求。服务器在接收到 OPTIONS 请求后,可以根据请求头中的信息来判断是否支持跨域请求,并在响应头中返回对应的信息。如果服务器返回的信息表明支持跨域请求,浏览器才会继续发送实际的请求。
因此,OPTIONS 请求可以理解为一种预检请求,用于测试服务器是否允许实际请求。在发送 OPTIONS 请求后,服务器会返回 Allow、Access-Control-Allow-Methods、Access-Control-Allow-Headers 等响应头字段,来告诉浏览器服务器支持的请求方法和头部信息等。
总的来说,OPTIONS 请求通常用于跨域资源共享中的预检操作,以便查看服务器是否支持实际请求的方法和头部信息等,从而提高跨域请求的安全性。
5. 了解http协议的头部算法吗?如何降低开销的?**
HTTP 协议头部压缩算法可以减少 HTTP 报文的大小,从而降低网络传输的开销。常见的 HTTP 头部压缩算法有两种:HPACK 和 SDCH。
-
HPACK:HTTP/2 压缩算法。它使用二进制编码来表示头部字段,可以有效地减少报文的大小。HPACK 压缩算法可以通过动态表和静态表来缓存头部字段,以便更快地进行压缩和解压缩操作。
-
SDCH:Shared Dictionary Compression over HTTP。SDCH 压缩算法是基于字典的压缩算法,它可以通过缓存整个页面的字典来压缩 HTTP 报文。在客户端和服务器之间共享字典可以有效地减少报文的大小。
降低 HTTP 头部压缩开销的方法包括:
-
优化头部字段的大小,尽量减少冗余字段和长字段,可以使用缩写或者简写来代替一些常用的字段。
-
采用压缩算法,如 HPACK 和 SDCH 等,可以对头部进行压缩,减少传输的数据量。
-
采用 HTTP/2 协议,HTTP/2 协议支持头部压缩,可以大幅降低 HTTP 报文的大小。
总的来说,HTTP 协议头部压缩算法可以减少 HTTP 报文的大小,从而降低网络传输的开销。采用优化头部字段大小、压缩算法和 HTTP/2 协议等方法可以降低头部压缩开销
请求头 & 响应头
1. 你了解的请求和响应头分别有哪些?*
HTTP 请求头常见字段:
- Host:指定请求的主机名和端口号
- Method:指定请求方式(例如:POST)
- Accept:指定客户端能够接收的响应类型
- Accept-*:指定浏览器的能力
- User-Agent:指定发送请求的浏览器、操作系统和设备等信息
- Connection:指定客户端与服务器之间的连接状态。
- Cache-Control:指定请求或响应的缓存策略,如 no-cache、max-age 等。
- Content-type:指示请求体中的数据类型和编码方式
- Cookie:它用于在客户端和服务器之间传递数据,以便客户端可以记住用户的状态和行为
HTTP 响应头常见字段:
- Server:指定服务器软件的名称和版本号。
- Content-Type:指定响应的内容类型和编码方式。
- Content-Length:指定响应的内容长度。
- Content-Encoding:指定响应的编码方式,如 gzip、deflate 等。
- Cache-Control:指定响应的缓存策略,如 no-cache、max-age 等。
- Set-Cookie:指定响应中的 Cookie。
- Location:指定要重定向到的 URL。
- Last-Modified:指定响应的最后修改时间。
- ETag:指定响应的实体标签,用于缓存验证。
- Connection:指定客户端与服务器之间的连接状态。
2. 常见的Content-Type有哪些?*
- text/plain:指示文本格式数据,没有特殊格式,例如纯文本文件、log 日志等。
- text/html:指示 HTML 格式数据,例如网页文件,包含 HTML 格式的文本、图片、链接等。
- text/css:指示 CSS 格式数据,例如网页样式文件,包含 CSS 格式的样式代码。
- text/javascript:指示 JavaScript 格式数据,例如网页脚本文件,包含 JavaScript 格式的脚本代码。
- application/json:指示 JSON 格式数据,用于传输结构化数据。
- application/xml:指示 XML 格式数据,用于传输结构化数据,例如 RSS、Atom 等。
- application/x-www-form-urlencoded:指示 URL 编码格式数据,例如表单提交数据。
- multipart/form-data:指示多部分格式数据,例如文件上传。
- image/jpeg, image/png, image/gif:指示图片格式数据,用于传输图片文件。
总的来说,HTTP Content-Type 字段用于指示实体主体的媒体类型,常见的 Content-Type 包括了文本、HTML、CSS、JavaScript、JSON、XML、URL 编码格式、多部分格式和图片格式等。在使用 Content-Type 时,应根据具体的业务需求来选择合适的类型。
3. 请求头和响应头里的connection 有哪些?*
HTTP 请求头和响应头中的 Connection 字段用于指示客户端和服务器之间的连接状态。常见的 Connection 字段包括:
在请求头中:
- Connection: keep-alive:指示客户端请求后保持与服务器的连接状态,以便重用连接。
- Connection: close:指示客户端请求后关闭与服务器的连接。
- Connection: Upgrade:指示客户端希望将当前连接升级为其他协议,例如 WebSocket。
在响应头中:
- Connection: keep-alive:指示服务器响应后保持与客户端的连接状态,以便重用连接。
- Connection: close:指示服务器响应后关闭与客户端的连接。
- Connection: Upgrade:指示服务器已经将当前连接升级为其他协议,例如 WebSocket。
其中,Connection: keep-alive 是 HTTP/1.1 默认的连接方式,它允许客户端和服务器之间保持长连接,以便重用 TCP 连接和减少连接开销。而 Connection: close 则表明客户端或服务器要求关闭连接,通常用于短连接场景。
总的来说,HTTP 请求头和响应头中的 Connection 字段用于指示客户端和服务器之间的连接状态,常见的 Connection 包括 keep-alive、close 和 Upgrade 等。在使用 Connection 时,应根据具体的业务需求来选择合适的连接方式。
Http 状态码
1. http 的状态码有哪些?*
HTTP 状态码是 HTTP 协议中用于表示客户端请求的处理结果的三位数字代码。以下是常见的 HTTP 状态码:
1xx:信息响应类,服务端接受请求并正在处理
2xx:成功响应类
- 200 OK:请求已成功,请求所希望的响应头或数据体将随此响应返回。
- 201 Created:请求已经被实现,且一个新资源已经依据请求的需要而建立。
- 204 No Content:服务器成功处理了请求,但不需要返回任何实体内容,并且希望返回更新了的元信息。
3xx:重定向响应类
- 301 Moved Permanently:请求的网页已永久移动到新位置。服务器返回此响应,客户端应该更新所保存的网址。
- 302 Found:请求的网页已临时移动到新位置,服务器返回此响应,客户端应该继续使用原有网址。
- 304 Not Modified:客户端发送了一个带条件的请求,服务器允许访问资源,但是请求的资源未被修改。
4xx:客户端错误响应类
- 400 Bad Request:服务器无法理解请求的格式,客户端不应当尝试再次使用相同的内容发起请求。
- 401 Unauthorized:请求要求身份验证。客户端需要进行身份验证才能获得响应。
- 403 Forbidden:服务器拒绝请求,客户端没有访问权限。
- 404 Not Found:服务器找不到请求的资源。
5xx:服务器错误响应类
- 500 Internal Server Error:服务器内部错误,无法完成请求。
- 502 Bad Gateway:作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了无效的响应。
http 版本能力
1. http 1.0 和 http 1.1 有什么区别?*
-
持久连接:HTTP 1.0 默认使用短连接方式,即每次请求都需要建立连接和关闭连接,效率较低;而 HTTP 1.1 默认使用长连接方式,即客户端和服务器之间可以保持连接不断开,以便多次请求复用同一个TCP连接,提高了效率。
-
缓存机制:
在 HTTP 1.0 中,缓存机制是可选的,需要使用 Expires 和 Last-Modified 字段来控制缓存的过期时间和缓存策略。
具体来说,当客户端第一次请求一个资源时,服务器会将资源的内容和 Last-Modified 字段一起返回给客户端。Last-Modified 字段表示资源的最后修改时间,客户端会将这个值保存在缓存中。之后客户端再次请求这个资源时,会将 If-Modified-Since 字段带上,告诉服务器它上次获取资源的最后修改时间。如果服务器发现资源的最后修改时间没有变化,就会返回一个 304 Not Modified 的响应,告诉客户端使用缓存中的资源即可,否则会返回新的资源内容和 Last-Modified 字段。
同时,HTTP 1.0 还支持 Expires 字段,它表示资源的过期时间,即告诉客户端在过期时间之前可以直接从缓存中获取资源,而无需再次请求服务器。如果客户端在过期时间之后请求资源,服务器会返回新的资源内容和 Last-Modified 字段。
需要注意的是,HTTP 1.0 的缓存机制是基于 Last-Modified 和 Expires 字段的,缓存的有效性依赖于服务器和客户端的实现。缓存时间的控制也比较粗糙,只能通过 Expires 字段来控制资源的过期时间,而不能精细地控制缓存时间
在 HTTP 1.1 中,缓存机制是默认启用的,支持更多的缓存控制方式,包括 Cache-Control、ETag 和 If-None-Match 等。
具体来说,HTTP 1.1 中的缓存控制主要通过 Cache-Control 头部字段来实现。Cache-Control 字段可以有多个参数,用逗号分隔,常见的参数包括:
- public:表示资源可以被任何缓存进行缓存,包括客户端和代理服务器。
- private:表示资源只能被客户端进行缓存,不能被代理服务器缓存。
- max-age:表示资源可以被缓存的最长时间,单位是秒。例如:
- no-cache:表示缓存需要重新验证,即客户端需要向服务器发送一个请求,检查资源是否有更新。
- must-revalidate:表示客户端必须向服务器发送一个请求,检查缓存的资源是否过期。如果资源已经过期,服务器就会返回新的资源。
此外,HTTP 1.1 还引入了 ETag 和 If-None-Match 字段,用于检查资源是否有更新。当客户端请求一个资源时,服务器会返回一个 ETag 字段,表示资源的版本号。客户端再次请求这个资源时,会带上 If-None-Match 字段,值为上次返回的ETag值,请求服务器检查资源是否有更新。如果资源没有更新,服务器会返回 304 Not Modified 的响应,告诉客户端使用缓存中的资源即可,否则会返回新的资源内容和新的 ETag 值。
-
Host 头部字段:HTTP 1.0 中,每个 Web 服务器只能提供一个网站,因此不需要 Host 头部字段,但是在 HTTP 1.1 中,一台 Web 服务器可以提供多个网站,因此需要使用 Host 头部字段来标识请求的目标网站。
-
请求方式:HTTP 1.0 只支持 GET 和 POST 请求方式;而 HTTP 1.1 还支持 PUT、DELETE、HEAD、OPTIONS、TRACE 等请求方式。
-
分块传输编码:HTTP 1.1 支持分块传输编码(Chunked Transfer Encoding),可以将实体分成多块进行传输,提高传输效率。
2. http 1.1 和 http 2.0 有什么区别?*
HTTP 1.1 和 HTTP 2.0 是 HTTP 协议的两个主要版本,它们之间有以下区别:
-
传输方式:HTTP 1.1 使用文本传输格式,每个请求和响应都是一条文本消息,需要进行解析,效率较低;而 HTTP 2.0 使用二进制传输格式,将请求和响应分成多个二进制帧进行传输,效率更高。
-
多路复用:HTTP 1.1 中每个连接只能处理一个请求和响应,需要建立多个连接来实现并发处理;而 HTTP 2.0 支持多路复用,可以在一个连接上同时处理多个请求和响应,提高了并发处理能力和效率。
-
头部压缩:HTTP 2.0 支持头部压缩,可以减少请求和响应的头部大小,节省带宽和传输时间。
-
服务器推送:HTTP 2.0 支持服务器推送,可以在客户端请求一个资源时,同时将该资源依赖的其他资源一起推送给客户端,提高了性能和响应速度。
-
流量控制:HTTP 2.0 支持流量控制,可以控制数据的传输速度和流量大小,避免了因网络拥塞导致的效率下降和数据丢失等问题。
总的来说,HTTP 2.0 相对于 HTTP 1.1 支持更快的传输速度、更高的并发处理能力、更低的延迟和更好的性能。但是,HTTP 2.0 的实现需要客户端和服务器都支持,否则无法享受其带来的性能提升。同时,HTTP 2.0 的头部压缩和服务器推送等新特性也需要谨慎使用,以免引发兼容性问题和安全性问题。
3. http2.0中的多路复用和http1.1中的持久链接的区别?**
HTTP 1.1 中的持久连接允许多个请求和响应在同一个 TCP 连接中传输,从而减少了连接建立和关闭的时间,提高了网络传输效率。但是,在 HTTP 1.1 中,多个请求和响应之间仍然需要按顺序进行传输,因此如果其中某个请求或响应出现延迟或阻塞,就会影响后续请求或响应的传输。
而在 HTTP 2.0 中,采用了多路复用技术,可以在同一个 TCP 连接上同时传输多个请求和响应,而且这些请求和响应之间没有先后顺序的限制,可以任意交错传输。HTTP 2.0 中的多路复用可以将一个 TCP 连接看作是一个虚拟的管道,可以在这个管道中并行传输多个 HTTP 消息,从而提高网络传输效率,同时也可以避免一个请求或响应的延迟影响到后续请求或响应的传输。
因此,HTTP 1.1 的持久连接和 HTTP 2.0 的多路复用都是为了减少网络传输的时延和提高传输效率,但是多路复用相比持久连接具有更高的并发性和更好的性能。同时,HTTP 2.0 还支持头部压缩和二进制传输等特性,进一步提高了性能和安全性。TTP 1.1 中的持久连接允许多个请求和响应在同一个 TCP 连接中传输,从而减少了连接建立和关闭的时间,提高了网络传输效率。但是,在 HTTP 1.1 中,多个请求和响应之间仍然需要按顺序进行传输,因此如果其中某个请求或响应出现延迟或阻塞,就会影响后续请求或响应的传输。
而在 HTTP 2.0 中,采用了多路复用技术,可以在同一个 TCP 连接上同时传输多个请求和响应,而且这些请求和响应之间没有先后顺序的限制,可以任意交错传输。HTTP 2.0 中的多路复用可以将一个 TCP 连接看作是一个虚拟的管道,可以在这个管道中并行传输多个 HTTP 消息,从而提高网络传输效率,同时也可以避免一个请求或响应的延迟影响到后续请求或响应的传输。
Keep-Alive
1. 什么是Keep-Alive?*
Keep-Alive 是 HTTP 协议中的一种机制,它可以使客户端和服务器在一个 TCP 连接上进行多次 HTTP 通信,而不是每次通信都建立和关闭一个连接。
http 1.0 中默认是短连接的形式,需要主动在Connection中设置keep-alive
http 1.1 中默认是长连接的形式,需要主动关闭连接。
2. Keep-Alive的建立过程?*
- 客户端向服务端发送请求是,在请求头中携带Connection: Keep-Alive的配置。
- 服务端在响应客户端的请求时,在响应头中携带Connection: Keep-Alive的配置。
- 客户端维持当前的连接状态。
3. Keep-Alive 是如何断开的?**
长连接的断开可以由客户端或服务器发起,有以下几种情况:
- 客户端主动断开:客户端可以在任何时候发送 Connection: close 头部,通知服务器关闭连接。在收到客户端的请求后,服务器会在响应头部中也添加 Connection: close 头部,表示已经同意关闭连接。
- 服务器主动断开连接:服务器也可以在任何时候发送 Connection: close 头部,通知客户端关闭连接。在收到服务器的响应后,客户端会关闭连接。
- 长连接有可能因为网络故障、服务器负载过高或应用程序错误等原因而导致连接超时。一般情况下,客户端和服务器都会设置一个超时时间,如果在这个时间内没有通信,则会自动断开连接。
4. Keep-Alive 的优缺点?**
优点:
-
减少连接建立和关闭的时间:使用 Keep-Alive 可以在一个 TCP 连接上进行多次 HTTP 通信,避免了每次通信都建立和关闭连接的时间开销,从而提高了网络传输效率。
-
减轻服务器的负担:使用 Keep-Alive 可以减少连接建立和关闭的次数,从而降低了服务器的负担,避免了大量的连接建立和关闭对服务器性能的影响。
-
支持长连接和复用连接:使用 Keep-Alive 可以支持长连接和复用连接的功能,从而可以在一个连接上进行多次 HTTP 通信,提高了网络传输效率和性能。
缺点:
-
占用连接资源:使用 Keep-Alive 会占用一定的连接资源,因为每个 Keep-Alive 连接都需要保持打开状态,等待下一次通信。
-
可能会导致拥塞:使用 Keep-Alive 可能会导致拥塞,因为多个请求和响应都在同一个连接上进行传输,如果其中一个请求或响应出现延迟或阻塞,就会影响后续请求或响应的传输。
-
可能会导致安全问题:使用 Keep-Alive 可能会导致安全问题,因为连接保持打开状态的时间更长,可能会使得攻击者有更多的时间来进行攻击。
https 和 websocket
1. 了解 https 吗?https 和 http 有哪些区别?*
https 是 http的一种安全版,其主要特点是在 HTTP 应用层协议和 TCP/IP 网络传输层之间加入一层 SSL 或 TLS 安全协议,对传输的数据进行加密和认证,从而保证数据的机密性和完整性。
主要区别:
- 安全性:HTTPS 采用 SSL 或 TLS 协议对数据进行加密和认证,确保数据传输的安全性。而 HTTP 传输的数据是明文传输的,容易被窃听、篡改和伪造等安全问题。
- 网站访问速度:HTTPS 通信需要进行加密和解密等操作,会多花费一定的时间和计算资源,因此相对于 HTTP,HTTPS 访问速度会稍微慢一些。
- 端口号:HTTPS 默认使用 443 端口进行通信,而 HTTP 默认使用 80 端口进行通信。因此,使用 HTTPS 的网站需要申请并配置 SSL 证书,以支持 443 端口的安全访问。
2. SSL/TLS 是什么?作用以及工作原理是什么?*
SSL(Secure Sockets Layer)/TLS(Transport Layer Security)是一种用于保护网络通信安全的协议。它位于应用层和传输层之间,通过对数据进行加密和认证,确保数据传输的机密性和完整性。 SSL/TLS 的主要作用如下:
-
数据加密:SSL/TLS 使用对称加密和公钥加密等技术,对数据进行加密,保证数据传输的机密性。
-
数据认证:SSL/TLS 使用数字证书对服务器进行认证,防止攻击者伪造和欺骗。
-
数据完整性:SSL/TLS 使用哈希算法等技术,对数据进行完整性校验,确保数据在传输过程中没有被篡改。
SSL/TLS 的工作原理如下:
-
协商算法:客户端和服务器首先协商使用的加密算法、密钥长度、消息认证码等参数。
-
证书验证:服务器向客户端发送数字证书,客户端使用根证书和中间证书验证服务器的身份和可信度。
-
密钥交换:客户端使用服务器的公钥加密一个随机数,发送给服务器,服务器使用私钥解密该随机数,然后客户端和服务器使用该随机数生成对称加密算法的密钥。
-
数据传输:客户端和服务器使用密钥对数据进行加密和解密,并使用消息认证码对数据进行完整性校验。
对称加密算法
对称加密算法(AES、DES等等)的原理是使用相同的秘钥进行加密和解密。具体来说,有以下几个步骤:
- 密钥生成:双方需要协商好相同的密钥,该密钥需要保密。
- 加密:发送方使用密钥对明文进行加密,生成密文。
- 传输:发送方将密文发送给接收方,可能需要使用其他安全措施(如 SSL/TLS 协议)确保传输过程的安全性。
- 解密:接收方使用相同的密钥对密文进行解密,生成明文。
缺点:秘钥在传输过程中可能被窃取
非对称加密算法
非对称加密算法是一种使用一对不同的密钥进行加密和解密的算法。该算法由公钥加密和私钥解密两部分组成,具体来说,非对称加密算法分为以下几个步骤:
-
密钥生成:加密方生成一对密钥,包括公钥和私钥。公钥可公开发布,私钥需要保密。
-
加密:发送方使用接收方的公钥对明文进行加密,生成密文。
-
传输:发送方将密文发送给接收方,可能需要使用其他安全措施(如 SSL/TLS 协议)确保传输过程的安全性。
-
解密:接收方使用自己的私钥对密文进行解密,生成明文。
在非对称加密算法中,公钥和私钥是一对不同的密钥,可以通过公钥加密和私钥解密,也可以通过私钥加密和公钥解密。由于公钥可以公开发布,因此可以实现密文的安全传输,同时避免了密钥分发和管理上的困难。常用的非对称加密算法包括 RSA、DSA、ECC 等。
哈希算法(散列函数)
哈希算法是一种将任意长度的输入数据映射成固定长度输出的算法。哈希算法的原理可以分为以下几个步骤:
-
输入数据分块:对于输入数据,哈希算法会将其分块,每个块的大小一般为几十到几百字节。
-
初始向量生成:哈希算法会生成一个初始向量(IV),一般是一些固定的常数或者随机数。
-
压缩函数计算:哈希算法会使用压缩函数对每个分块进行计算,输出一个哈希值。
-
哈希值组合:对于多个分块的哈希值,哈希算法会使用哈希函数将它们组合成一个固定长度的哈希值。
-
输出哈希值:哈希算法将最终的哈希值输出,作为输入数据的唯一标识符或者摘要。
不同的哈希算法使用的压缩函数和哈希函数不同,但是它们的基本原理都是将一个任意长度的输入数据映射成固定长度的哈希值。常用的哈希算法包括 MD5、SHA-1、SHA-256、SHA-512 等。
总的来说,哈希算法是一种常用的密码学算法,其原理是将任意长度的输入数据映射成固定长度的哈希值。在实际应用中,需要根据具体需求选择合适的哈希算法和哈希值长度,并采取措施确保哈希值的安全性。
3. websocket是什么?工作原理?
WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议。它提供了在 Web 应用程序中进行实时通信的能力,例如聊天室、游戏等。它建立在 HTTP 协议之上,但是它不像 HTTP 协议那样是一种请求/响应协议,而是一种带有状态的协议,它能够保持服务器和客户端之间的长连接,实现实时通信。
WebSocket 的工作原理如下:
-
连接建立:客户端通过 HTTP 请求与服务端进行连接,服务端进行握手确认,如果握手成功,则建立连接。
-
数据传输:连接建立之后,客户端和服务端可以通过 WebSocket 进行实时双向通信,发送和接收数据,数据格式可以是文本或者二进制数据。
-
连接关闭:当客户端或者服务端需要关闭连接时,可以发送关闭帧进行关闭,WebSocket 会进行确认关闭。
-
WebSocket 的优点在于它提供了一个持久化的连接,可以保持服务器和客户端之间的长时间通信,避免了 HTTP 协议的频繁连接和断开,从而提高了通信效率,减少了网络带宽和服务器资源的消耗。同时,WebSocket 也提供了一些安全措施,例如对数据进行加密和认证,保证了通信的安全性。
总的来说,WebSocket 是一种基于 HTTP 协议的全双工通信协议,通过保持长连接实现实时通信,具有高效、低延迟、安全等优点,被广泛应用于 Web 应用程序中。
DNS
1. 了解DNS的作用和传输机制吗?**
DNS(Domain Name System)是一种将域名(例如 www.example.com)解析为 IP 地址(例如 192.0.2.1)的分布式数据库系统。DNS 一般由多个服务器组成,分为根域名服务器、顶级域名服务器、权威域名服务器和本地域名服务器等,它们共同完成域名解析的功能。
DNS 的作用主要有以下几个方面:
-
域名解析:DNS 将域名解析为 IP 地址,使得客户端可以通过域名访问服务器和服务。
-
负载均衡:通过 DNS 服务器的配置,可以将访问请求分配到多个服务器上,实现负载均衡。
-
安全性:通过 DNSSEC(DNS Security Extensions)对 DNS 数据进行签名和验证,保证 DNS 数据的完整性和可信性。
DNS 的传输机制一般使用 UDP 或者 TCP 协议进行传输,具体来说,DNS 的传输过程分为以下几个步骤:
-
发送查询请求:客户端向本地 DNS 服务器发送查询请求,请求解析域名的 IP 地址。
-
递归查询:本地 DNS 服务器收到查询请求后,如果本地 DNS 缓存中没有相应的数据,则向根域名服务器发送查询请求,以获取顶级域名服务器的信息。
-
迭代查询:顶级域名服务器收到查询请求后,返回权威域名服务器的地址,本地 DNS 服务器则继续向权威域名服务器发送查询请求,直到获取到域名的 IP 地址。
-
返回结果:本地 DNS 服务器将查询结果返回给客户端,客户端可以根据返回的 IP 地址访问服务器或者服务。
总的来说,DNS 是一种将域名解析为 IP 地址的分布式数据库系统,它通过 UDP 或者 TCP 协议进行传输,实现域名解析、负载均衡和安全性等功能。
迭代查询
迭代查询是 DNS 查询过程中的一种方式,它由客户端发起查询请求,并进行逐层查询,直到获取到查询结果。具体来说,迭代查询的过程如下:
-
客户端向本地 DNS 服务器发送查询请求,请求解析域名的 IP 地址。
-
本地 DNS 服务器收到查询请求后,在本地 DNS 缓存中查找是否存在相应的 IP 地址。如果本地 DNS 缓存中没有相应的数据,则向 Root DNS 服务器发送查询请求。
-
Root DNS 服务器收到查询请求后,返回顶级域名服务器的地址。
-
本地 DNS 服务器根据 Root DNS 服务器返回的顶级域名服务器地址,向顶级域名服务器发送查询请求。
-
顶级域名服务器收到查询请求后,返回权威域名服务器的地址。
-
本地 DNS 服务器根据顶级域名服务器返回的权威域名服务器地址,向权威域名服务器发送查询请求。
-
权威域名服务器收到查询请求后,在自己的 DNS 数据库中查找域名对应的 IP 地址,然后将查询结果返回给本地 DNS 服务器。
-
本地 DNS 服务器将查询结果缓存,并将查询结果返回给客户端,客户端可以根据返回的 IP 地址访问服务器或者服务。
迭代查询过程中,客户端向本地 DNS 服务器发送查询请求,本地 DNS 服务器则通过向 Root DNS 服务器、顶级域名服务器和权威域名服务器的逐层查询,最终获得域名对应的 IP 地址。由于迭代查询需要进行多次查询和返回结果,因此相较于递归查询来说,迭代查询的效率较低。
递归查询
DNS递归查询是DNS查询过程的一种方式,它由客户端发起查询请求,直到获取到查询结果。具体来说,递归查询的过程如下:
-
客户端向本地 DNS 服务器发送查询请求,请求解析域名的 IP 地址。
-
如果本地 DNS 缓存中没有相应的数据,则本地 DNS 服务器向 Root DNS 服务器发送查询请求。
-
Root DNS 服务器收到查询请求后,返回顶级域名服务器的地址。
-
本地 DNS 服务器根据 Root DNS 服务器返回的顶级域名服务器地址,向顶级域名服务器发送查询请求。
-
顶级域名服务器收到查询请求后,返回权威域名服务器的地址。
-
本地 DNS 服务器根据顶级域名服务器返回的权威域名服务器地址,向权威域名服务器发送查询请求。
-
权威域名服务器收到查询请求后,在自己的 DNS 数据库中查找域名对应的 IP 地址,然后将查询结果返回给本地 DNS 服务器。
-
本地 DNS 服务器将查询结果缓存,并将查询结果返回给客户端,客户端可以根据返回的 IP 地址访问服务器或者服务。
在递归查询过程中,客户端向本地 DNS 服务器发送查询请求,本地 DNS 服务器则通过向 Root DNS 服务器、顶级域名服务器和权威域名服务器的逐层查询,最终获得域名对应的 IP 地址,将查询结果返回给客户端。由于递归查询过程中,DNS服务器会代替客户端进行多次查询和返回结果,因此相较于迭代查询来说,递归查询的效率较高。