「2023」前端面试知识点复盘——计算机网络篇

写在前面

哈喽，小伙伴们，我是泽南👨‍🎓。近期我会整理一系列针对前端面试的知识点供大家复习，不管你是准备跳槽还是正在面试，都赶快来恶补一下~

本系列文章主要以知识总结为主，不是面试题哈，主要目的是方便自己复习以及为大家提供便利，所以大部分知识点来源于网上，侵权联系删除。如有不对的地方欢迎大家评论区批评指正，一起进步！

此系列会陆续更新如下文章：

「2023」前端面试知识点复盘------浏览器篇

「2023」前端面试知识点复盘------计算机网络篇

「2023」前端面试知识点复盘------JS篇 （整理中。。。）

「2023」前端面试知识点复盘------React篇 （整理中。。。）

「2023」前端面试知识点复盘------CSS篇 （整理中。。。）

「2023」前端面试知识点复盘------工程化篇 （整理中。。。）

一、HTTP协议

• HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法
• HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT

http/1.1规定了以下请求方法(注意，都是大写):

• GET： 请求获取Request-URI所标识的资源
• POST： 一般用于修改Request-URI的资源
• HEAD： 请求获取由Request-URI所标识的资源的响应消息报头
• PUT： 请求服务器存储一个资源
• DELETE： 请求服务器删除对应所标识的资源
• TRACE： 请求服务器回送收到的请求信息，主要用于测试或诊断
• CONNECT： 建立连接隧道，用于代理服务器
• OPTIONS： CORS跨域请求的预检请求；

1. GET和POST的请求的区别

• 应用场景： GET 请求是一个幂等的请求，一般 GET 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作。
• 是否缓存： 因为两者应用场景不同，浏览器一般会对 GET 请求缓存，但很少对 POST 请求缓存。 发送的报文格式： GET 请求的报文中实体部分为空，POST 请求的报文中实体部分一般为向服务器发送的数据。
• 安全性： GET 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 POST 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。
• 请求长度： 浏览器由于对 url 长度的限制，所以会影响 GET 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。
• 参数类型： POST 的参数传递支持更多的数据类型,GET请求一般放在URL中，POST请求放在请求体中，看起来POST比GET安全，但是在抓包的情况下都是一样的（所以面试的时候别再说POST比GET安全了）。
• 编码角度：GET只能进行 url 编码，参数的数据类型只接受ASCII字符，而POST支持更多的编码类型且不对数据类型限制。

2. POST和PUT请求的区别

• PUT请求是向服务器端发送数据，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。（可以理解为时更新数据）
• POST请求是向服务器端发送数据，该请求会改变数据的种类等资源，它会创建新的内容。（可以理解为是创建数据）

3. OPTIONS请求方法及使用场景

OPTIONS是除了GET和POST之外的其中一种 HTTP请求方法。

OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。该请求方法的响应不能缓存。

OPTIONS请求方法的主要用途有两个：

获取服务器支持的所有HTTP请求方法； 用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

4. 常见的HTTP请求头和响应头

HTTP Request Header 常见的请求头：

• Accept:浏览器能够处理的内容类型
• Accept-Charset:浏览器能够显示的字符集
• Accept-Encoding：浏览器能够处理的压缩编码
• Accept-Language：浏览器当前设置的语言
• Connection：浏览器与服务器之间连接的类型
• Cookie：当前页面设置的任何Cookie
• Host：发出请求的页面所在的域
• Referer：发出请求的页面的URL
• User-Agent：浏览器的用户代理字符串

HTTP Responses Header 常见的响应头：

• Date：表示消息发送的时间，时间的描述格式由rfc822定义
• server:服务器名称
• Connection：浏览器与服务器之间连接的类型
• Cache-Control：控制HTTP缓存
• content-type:表示后面的文档属于什么MIME类型

常见的 Content-Type 属性值有以下四种：

• application/x-www-form-urlencoded：浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。该种方式提交的数据放在 body 里面，数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL转码。
• multipart/form-data：该种方式也是一个常见的 POST 提交方式，通常表单上传文件时使用该种方式。
• application/json：服务器消息主体是序列化后的 JSON 字符串。
• text/xml：该种方式主要用来提交 XML 格式的数据。

5. HTTP 1.0 和 HTTP 1.1 之间有哪些区别？

HTTP 1.0和 HTTP 1.1 有以下区别：

• 连接方面：http1.0 默认使用非持久连接，而 http1.1 默认使用持久连接。http1.1 通过使用持久连接来使多个 http 请求复用同一个 TCP 连接，以此来避免使用非持久连接时每次需要建立连接的时延。
• 资源请求方面：在 http1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，http1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
• 缓存方面：在 http1.0 中主要使用 header 里的 If-Modified-Since 、Expires 来做为缓存判断的标准，http1.1 则引入了更多的缓存控制策略，例如 Etag 、If-Unmodified-Since 、If-Match 、If-None-Match 等更多可供选择的缓存头来控制缓存策略。
• http1.1 中新增了 host 字段，用来指定服务器的域名。http1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。因此有了 host 字段，这样就可以将请求发往到同一台服务器上的不同网站。
• http1.1 相对于 http1.0 还新增了很多请求方法，如 PUT 、HEAD 、OPTIONS 等。

6. HTTP 1.1 和 HTTP 2.0 的区别

• 二进制协议：HTTP2.0 是一个二进制协议。在 HTTP1.1 中，报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。HTTP2.0 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"，可以分为头信息帧和数据帧。 帧的概念是它实现多路复用的基础。
• 多路复用： HTTP2.0 实现了多路复用，HTTP2.0 仍然复用 TCP 连接，但是在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一一发送，这样就避免了"队头堵塞"的问题。
• 数据流： HTTP2.0 使用了数据流的概念，因为 HTTP2.0 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的请求。因此，必须要对数据包做标记，指出它属于哪个请求。HTTP2.0 将每个请求或回应的所有数据包，称为一个数据流。每个数据流都有一个独一无二的编号。数据包发送时，都必须标记数据流 ID ，用来区分它属于哪个数据流。
• 头信息压缩： HTTP2.0 实现了头信息压缩，由于 HTTP 1.1 协议不带状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent ，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。HTTP2.0 对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 compress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了。
• 服务器推送： HTTP2.0 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送。使用服务器推送提前给客户端推送必要的资源，这样就可以相对减少一些延迟时间。这里需要注意的是 http2.0 下服务器主动推送的是静态资源，和 WebSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的。

7.HTTP 3.0 有哪些改进

Google搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上

HTTP3 出现原因 & HTTP2 缺点

• 底层协议还是TCP，仍然需要三次握手来确认连接成功，
• TCP的队头阻塞并没有彻底解决，在 HTTP2 中，多个请求是跑在一个TCP连接中的。但当HTTP/2出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该TCP连接中的所有请求。

QUIC

• 实现了快速握手功能。由于QUIC是基于UDP的，不需要三次握手，这意味着QUIC可以用最快的速度来发送和接收数据。
  • 3RTT => 0/1 RTT；根据是否要TLS加密
• 实现了类似TCP的可靠传输，虽然UDP不提供可靠性的传输，但QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。
  • 用的ACK模式，只是QUIC中包丢了就丢了，会重传一个新序号的包，通过包内的offset字段来确定这个包的位置；
• 集成了 TLS 加密功能，目前QUIC使用的是TLS1.3，相较于早期版本TLS1.3有更多的优点，其中最重要的一点是减少了握手所花费的RTT个数。
• 同样也提供了拥塞控制机制，包括慢启动、拥塞避免等；
• 也实现了多路复用，每个请求会在 quic 层面定义为一个 stream，丢包也只影响当前stream；彻底解决 TCP 中队头阻塞的问题（详细可阅读下文）

队头阻塞是由 HTTP 基本的"请求 - 应答"模型所导致的。HTTP 规定报文必须是"一发一收"，这就形成了一个先进先出的"串行"队列。队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。

总结

• HTTP/1.1有两个主要的缺点：安全不足和性能不高。
• HTTP/2完全兼容HTTP/1，头部压缩、多路复用等技术可以充分利用带宽，降低延迟，从而大幅度提高上网体验；
• QUIC 是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议。

二、HTTPS协议

1. 什么是HTTPS协议？

超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，利用SSL/TLS来加密数据包。HTTPS的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTP协议采用 明文传输 信息，存在 信息窃听 、信息篡改 和 信息劫持 的风险，而协议TLS/SSL具有身份验证 、信息加密 和完整性校验的功能，可以避免此类问题发生。

安全层的主要职责就是 对发起的HTTP请求的数据进行加密操作 和 对接收到的HTTP的内容进行解密操作。

2. TLS/SSL的工作原理

TLS/SSL全称安全传输层协议（Transport Layer Security）, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

TLS/SSL的功能实现主要依赖三类基本算法：散列函数hash、对称加密、非对称加密。这三类算法的作用可以参考作者的另一篇文章 面试官：你能说说常见的前端加密方法吗？

3.HTTPS 和 HTTP 区别

• HTTP 是明文传输，HTTPS 协议是可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。
• HTTPS对搜索引擎更友好，利于 SEO；谷歌、百度优先索引 HTTPS 网页。
• HTTPS 标准端口 443，HTTP 标准端口 80。
• HTTPS 需要用到SSL证书，而 HTTP 不用。

4.HTTPS握手过程

• 客户端发起 HTTPS 请求，发送客户端生成的随机数和支持的加密算法列表；
• 服务端返回证书、服务端生成的随机数、选择的加密方法给客户端；
• 客户端对证书进行合法性验证，验证通过后再生成一个随机数
• 客户端通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数
• 三次握手此时已经完成，之后客户端和服务端都会根据这三个随机数，生成一个随机对称密钥，之后的数据都通过随机对称密钥进行加密传输。

三、HTTP常见状态码

常规状态码和介绍可以看作者另一篇文章

# 面试官：详细说说HTTP 常见的状态码有哪些？

1.Http 状态码 301 和 302 的应用场景分别是什么？

• 301 表示永久重定向，302 表示临时重定向。
• 如果浏览器收到的是 301，则会缓存重定向的地址，之后不会再重新请求服务器，直接使用缓存的地址请求，这样可以减少请求次数。但如果浏览器收到的是 302，则不会缓存重定向地址，浏览器将来会继续以原有地址请求。
• 因此，301 适合地址永久转移的场景，比如域名变更；而 302 适合临时转移的场景，比如首页临时跳转到活动页

2.从输入URL到呈现页面过程

这个流程可以分为两部分来说，第一部分是浏览器请求响应的过程；

• 输入URL：用户在地址栏按下回车，先检查输入的是搜索关键字还是符合url的规则，然后将其组装成完整 URL进行访问；
• 检查缓存：然后会先检查本地强缓存是否可用，如果可用就直接从缓存中返回资源；
• DNS解析：如果强缓存不可用，就会进行DNS解析，通过递归查询和迭代查询解析域名来得到域名对应的IP地址；
  • DNS查询的顺序为：浏览器IP缓存，操作系统IP缓存，Hosts文件，DNS根服务器；
• 建立TCP连接：得到IP地址后，会进行三次握手去建立TCP连接；
• 发送HTTP请求：建立TCP连接后发送 HTTP 请求，发送HTTP请求时会携带上cookie和缓存的标识字段；
• 负载均衡：服务端网关收到HTTP请求后，可能会有一系列的负载均衡处理，通过反向代理分配给对应集群中的服务器去执行；
• 服务器返回响应：服务器收到请求后，先根据请求头的缓存标识来判断缓存是否生效，生效就返回304状态码；不生效就返回资源和200状态码（在返回200的响应报文前，还可能会返回103的响应报文）；
• 浏览器接收HTTP响应：浏览器接受到HTTP响应后根据 connection:keep-alive 的值来选择通过 四次挥手来断开TCP连接，或者保留；
• 同时浏览器还会缓存响应头里的缓存标识字段；

到此为止，浏览器请求响应的过程就结束了；第二部分就是浏览器解析并渲染的过程；

• 构建DOM树：浏览器从上到下解析 HTML 文档生成DOM节点树；
• 构建CSSOM树：浏览器解析遇到样式时，会进行异步下载，下载完成后构建 CSSOM树；
• 值得一提的是，当遇到不带 async 和 defer 的 script 时，会阻止解析HTML并进行下载和执行；
  • 并且CSS和DOM渲染，JS和DOM解析之间是有阻塞关系的；
• 构建渲染树：根据DOM节点树和CSSOM树构建渲染树（Render）；
• 布局（Layout）：根据渲染树将DOM节点树每一个节点布局在屏幕上的正确位置；
• 绘制（Paint）：绘制所有节点，为每一个节点适用对应的样式，绘制到屏幕上；

四、TCP 和 UDP

1.TCP、UDP 的特点

• TCP 和 UDP都是传输层协议，他们都属于TCP/IP协议族：
• TCP是一个面向连接的传输层协议。是可靠的、基于字节流的；TCP还具有超时重传、拥塞控制的机制；
• 而UDP是一个无连接的传输层协议。

2.TCP、UDP 的区别

3. UDP协议为什么不可靠？

UDP在传输数据之前不需要先建立连接，远地主机的运输层在接收到UDP报文后，不需要确认，提供不可靠交付。总结就以下四点：

• 不保证消息交付：不确认，不重传，无超时
• 不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞
• 不跟踪连接状态：不必建立连接或重启状态机
• 不进行拥塞控制：不内置客户端或网络反馈机制

4. TCP的重传机制

由于TCP的下层网络（网络层）可能出现丢失、重复或失序的情况，TCP协议提供可靠数据传输服务。为保证数据传输的正确性，TCP会重传其认为已丢失（包括报文中的比特错误）的包。TCP使用两套独立的机制来完成重传，一是基于时间，二是基于确认信息。

TCP在发送一个数据之后，就开启一个定时器，若是在这个时间内没有收到发送数据的ACK确认报文，则对该报文进行重传，在达到一定次数还没有成功时放弃并发送一个复位信号。

5. TCP的拥塞控制机制

TCP的拥塞控制机制主要是以下四种机制：

• 慢启动（慢开始）：开始的时候不要发送大量数据，先测试一下网络，然后慢慢由小到大的增加拥塞窗口大小；直到达到慢启动阈值；
• 拥塞避免：一旦判断网络出现拥塞，就将慢启动阈值设置为出现拥塞时一半的大小，并把拥塞窗口设为1，再重新开始慢启动算法
• 快速重传：就是接收方在收到一个失序的报文后立即发出重复确认，快重传算法规定发送方只要连续收到三个重复确认就立即重传对方尚未收到的报文段，而不用继续等重传计时器到期；
• 快速恢复：当发送方连续收到三个重复确认时，就不执行慢启动算法而是执行拥塞避免算法；

6. TCP的三次握手和四次挥手

TCP 三次握手流程

• 第一步：客户端发送SYN报文到服务端发起握手
• 第二步：服务端收到SYN报文之后回复SYN和ACK报文给客户端
• 第三步：客户端收到SYN和ACK，向服务端发送一个ACK报文

那为什么要三次握手呢？两次不行吗？

• 为了确认双方的接收能力和发送能力都正常
• 如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

三次握手过程中可以携带数据吗

• 第一次、第二次握手不可以携带数据，因为一握二握时还没有建立连接，会让服务器容易受到攻击（只需要在第一次握手的报文里放大量数据，服务器就会消耗更大的时间和内存空间去处理数据）
• 而第三次握手，此时客户端已经处于 (已建立连接状态) ，对于客户端来说，已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也是没问题的。

TCP四次挥手 & 四次挥手流程

因为TCP是全双工通信，不能单方面完全断开连接

• 第一次挥手，客户端发送FIN给服务端
• 第二次挥手，服务端回复ACK给客户端，服务端还可以继续向客户端发送数据（若数据没有发送完）
• 第三次挥手，服务端发送FIN给客户端
• 第四次挥手，客户端回复ACK给服务端，客户端经过 2MSL 的时间后断开，服务端接收到了客户端发出的ACK后立刻断开了到客户端的连接

至此TCP连接才完全断开。

四次挥手结束等待 2MSL 的意义

• 虽然按道理，四个报文都发送完毕，就可以立即断开，但是我们必须假设网络是不可靠的，有可以最后一个ACK丢失。
• 如果最后一个 ACK 丢失了，那么服务端没有收到 ACK 就会发起重传；再次发送 FIN 给客户端；
• 客户端收到重传的 FIN 后，会重发 ACK 并重新等待 2MSL 的时间来确保服务端收到了自己的 ACK；
• 1 个 MSL 确保第四次挥手中主动关闭方最后的 ACK 报文最终能达到对端
• 1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达

五、WebSocket

作者在之前文章中也涉及到websocket部分知识点，感兴趣的同学可以通过传送门查看：

# 前端如何使用websocket发送消息

# 面试官：你知道websocket的心跳机制吗？

1. 对 WebSocket 的理解

WebSocket 是 HTML5 提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于TCP传输协议，并复用HTTP的握手通道。浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。

WebSocket 的出现就解决了半双工通信的弊端。它最大的特点是：服务器可以向客户端主动推动消息，客户端也可以主动向服务器推送消息。

WebSocket原理：客户端向 WebSocket 服务器通知（notify）一个带有所有接收者ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件。

2.WebSocket 特点的如下：

• 支持双向通信，实时性更强
• 可以发送文本，也可以发送二进制数据
• 建立在TCP协议之上，服务端的实现比较容易
• 数据格式比较轻量，性能开销小，通信高效
• 没有同源限制，客户端可以与任意服务器通信
• 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL
• 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

3.WebSocket 心跳

可能会有某些未知情况导致 socket 断开，而客户端和服务端却不知道，需要客户端定时发送一个 心跳 ping 让服务端知道自己在线

服务端也需要回答一个 心跳 pong 告诉客户端自己可用，否则视为断开。

4.WebSocket 状态

WebSocket 对象中的 readyState 属性有四种状态：

• 0(WebSocket.CONNECTING)：表示正在连接
• 1(WebSocket.OPEN)：表示连接成功，可以通信了
• 2(WebSocket.CLOSING)：表示连接正在关闭
• 3(WebSocket.CLOSED)：表示连接已经关闭，或者打开连接失败

5.HTTP 与 WebSocket

相同点：

• 都是一样基于TCP的应用层协议，都是可靠性传输协议。

不同点：

• WebSocket 请求的地址不是类似/path/，而是以ws://开头的地址；
• WebSocket 是全双工通信协议，通信双方可以实时且同时发送和接收消息。而HTTP是单向的；
• WebSocket 没有了 Request 和 Response 的概念
• WebSocket 需要依赖 HTTP 协议进行一次握手。握手成功过后数据就直接从 TCP 通道传输，与 HTTP 无关；
• WebSocket 数据格式比较轻量，它的据包头部较小，而HTTP协议每次通信都需要携带完整的头部
• WebSocket 无跨域问题

6.即时通信方案

即时通信方案，也就是指两个客户机能够同时的收发消息；

方案选择

• 短轮询：前端用定时器每隔一段时间就ajax向后端获取更新；
• 长轮询：长轮询是短轮询的改进，请求到服务端后会被挂起，直到有新的消息才会返回响应；然后再重新发起请求；
• 基于流：基于流的推送技术就是指 SSE；SSE是一个H5的属性，它只能由服务器向浏览器发送数据，所以协作式通过 http 发送消息，sse 接受消息；
• Websocket：WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通信的协议；钉钉表格就是用的原生WebSocket；
• Socket.io：其实 Socket.IO 只是为了解决 websocket 的兼容性的一个解决方案，因为websocket出现的较新，所以一些老的浏览器兼容性不好，而 Socket.IO就是将websocket、长轮询两种通信方式封装成了统一的通信接口进行降级兼容；

7.单工、半双工和全双工通信

• 单工通信是指消息只能单方向传输的工作方式，数据信息从一端到另一端是单方向的。例：广播。
• 半双工通信可以实现双向的通信，但是不能在两个方向同时进行，必须交替进行。这中模式下，接收端和发送端可以互相转换。例：对讲机。
• 全双工通信是指在通信的任意时刻，都允许数据同时在两个方向上传输，在这个模式下，通信系统的每一端都设置了发送器和接收器

8.WebSocket 优点

• 较少的控制开销

  • 在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。

• 更强的实时性

  • 由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于 HTTP 请求需要等待客户端发起请求服务端才能响应，延迟明显更少。

• 保持连接状态

  • 与 HTTP 不同的是，WebSocket 需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。

• 更好的二进制支持。

  • WebSocket 定义了二进制帧，相对 HTTP，可以更轻松地处理二进制内容。

• 可以支持扩展。

  • WebSocket 定义了扩展，用户可以扩展协议、实现部分自定义的子协议。

六、DNS协议

1. DNS 协议是什么

概念： DNS 是域名系统 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务，就是我们常说的域名系统。它是一个由分层的 DNS 服务器组成的分布式数据库，是定义了主机如何查询这个分布式数据库的方式的应用层协议。能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。

作用： 将域名解析为IP地址，客户端向DNS服务器（DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的 IP 地址。

2. 迭代查询与递归查询

实际上，DNS解析是一个包含迭代查询和递归查询的过程。

• 递归查询指的是查询请求发出后，域名服务器代为向下一级域名服务器发出请求，最后向用户返回查询的最终结果。使用递归查询，用户只需要发出一次查询请求。
• 迭代查询指的是查询请求后，域名服务器返回单次查询的结果。下一级的查询由用户自己请求。使用迭代查询，用户需要发出 多次的查询请求。

3. DNS完整的查询过程

在客户端查找DNS缓存也就是递归查询；

以 Chrome浏览器 为例，当你在浏览器中想访问 www.baidu.com 时，会通过进行以下操作：

• Chrome 先查看浏览器自身有没有该域名的 IP 缓存
• Chrome 再查看操作系统有没有该域名的 IP 缓存
• Chrome 再查看 Host 文件有没有该域名的解析配置

如果在hosts文件中也没有找到对应的条目，浏览器就会请求本地域名服务器localDNS（LDNS）来解析这个域名。（这是递归查询的流程）

• 如果 LDNS 也没有该域名的记录，就会进行迭代查询：
• LDNS 先去 DNS根域名服务器查询，这一步查询会找出负责 com 这个一级域名的服务器
• LDNS 再去该服务器查询 baidu.com 这个二级域名
• LDNS 再去查询 www.baidu.com 这个三级域名的地址
• LDNS 返回给浏览器，并缓存起来

去查找服务端的就是迭代查询

• 首先会在浏览器的缓存中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步
• 将请求发送给本地DNS服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步
• 本地DNS服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址
• 本地DNS服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址
• 本地DNS服务器向权威域名服务器发送请求，域名服务器返回对应的结果
• 本地DNS服务器将返回结果保存在缓存中，便于下次使用
• 本地DNS服务器将返回结果返回给浏览器

4.DNS 实现负载平衡

某些大型网站一般都会使用多台服务器提供服务，因此一个域名可能对应多个服务器地址；

• 当用户发起网站域名的 DNS 请求的时候，DNS 服务器返回这个域名所对应的服务器 IP 地址的集合
• 在每个响应中，会循环这些 IP 地址的顺序，用户一般会选择排在前面的地址发送请求。
• 以此将用户的请求均衡的分配到各个不同的服务器上，这样来实现负载均衡。

还有一种负载均衡的方式，使用反向代理，用户的请求都发送到反向代理服务上，然后由反向代理服务器来转发请求到真实的服务器上，以此来实现集群的负载平衡。

5.DNS 为什么选择 UDP 协议作为传输层协议

为了得到一个域名的 IP 地址，往往会向多个域名服务器查询，而TCP协议存在三次握手，会造成DNS服务变得很慢

七、计算机网络模型

本篇文章主要介绍TCP/IP五层协议

• 应用层 (application layer) ：直接为应用进程提供服务。应用层协议定义的是应用进程间通讯和交互的规则，不同的应用有着不同的应用层协议，如 HTTP协议（万维网服务）、FTP协议（文件传输）、SMTP协议（电子邮件）、DNS（域名查询）等。
• 传输层 (transport layer)：有时也译为运输层，它负责为两台主机中的进程提供通信服务。该层主要有以下两种协议：
  • 传输控制协议 (Transmission Control Protocol，TCP)：提供面向连接的、可靠的数据传输服务，数据传输的基本单位是报文段（segment）；
  • 用户数据报协议 (User Datagram Protocol，UDP)：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性，数据传输的基本单位是用户数据报。
• 网络层 (internet layer) ：它负责为两台主机提供通信服务，并通过选择合适的路由将数据传递到目标主机。
• 数据链路层 (data link layer)：负责将网络层交下来的 IP 数据报封装成帧，并在链路的两个相邻节点间传送帧，每一帧都包含数据和必要的控制信息（如同步信息、地址信息、差错控制等）。
• 物理层 (physical Layer)：确保数据可以在各种物理媒介上进行传输，为数据的传输提供可靠的环境。

在每一层都工作着不同的设备，比如我们常用的交换机就工作在数据链路层的，一般的路由器是工作在网络层的。 在每一层实现的协议也各不同，即每一层的服务也不同，下图列出了每层主要的传输协议： 同样，TCP/IP五层协议的通信方式也是对等通信：