高频前端面试题汇总之计算机网络篇

前端掘金者H
1,250 阅读54分钟

01. HTTP 是什么

HTTP 是超文本传输协议，是一个简单的请求-响应协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口，它使用 TCP 作为传输层协议，保证了数据传输的可靠性。

02. HTTP有哪些方法，作用是什么

HTTP1.0定义了三种请求方法： GET, POST 和 HEAD

HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT

  1. GET，表示向服务器获取资源
  2. POST，表示向服务器提交信息，通常用于产生新的数据，比如注册
  3. PUT，表示希望修改服务器的数据，通常用于修改
  4. OPTIONS，发生在跨域的预检请求中，表示客户端向服务器申请跨域提交
  5. TRACE，回显服务器收到的请求，主要用于测试和诊断
  6. CONNECT，用于建立连接管道，通常在代理场景中使用，网页中很少用到

03. 幂等性，哪些请求属于幂等操作

幂等性：幂等通俗来说是指不管进行多少次重复操作，都是实现相同的结果（最终对服务器造成的影响都是一样的），GET，PUT，DELETE 都是幂等操作，而 POST 不是。

04. GET和POST的请求的区别

  1. GET请求会被浏览器主动缓存，POST不会，要手动设置
  2. GET请求参数会被完整保留在浏览器历史记录里，POST中的参数不会
  3. GET请求在URL中传送的参数是有长度限制的，而POST没有限制
  4. GET参数暴露在地址栏不安全，POST放在报文内部更安全
  5. GET一般用于查询信息、从服务器上获取信息，POST一般用于创建新资源

05. POST和PUT请求的区别

  1. POST用于在服务器上创建新资源，PUT用于更新现有资源
  2. PUT是幂等的，这意味着多个相同的请求将具有相同的结果，而POST不是幂等的，因为每个请求都会创建一个新的资源
  3. 由于POST请求将请求参数放在请求体中，安全性更好，PUT 请求可以使用 URL 中的ID参数来更新资源，存在安全隐患
  4. PUT请求需要客户端发送完整的资源内容，而POST请求可以只发送部分数据

06. PUT和PATCH请求的区别？

PUT 用于替换整个资源，而 PATCH 用于部分更新资源。

比如我们有一篇文章的地址https://www.jianshu.com/articles/820357430，这篇文章的可以表示为:

article = {
    author: 'dxy',
    creationDate: '2019-6-12',
    content: '我写文章像蔡徐坤',
    id: 820357430
}

当我们要修改文章的作者时，我们可以直接发送PUT https://www.jianshu.com/articles/820357430，这个时候的数据应该是:

{
    author:'蔡徐坤',
    creationDate: '2019-6-12',
    content: '我写文章像蔡徐坤',
    id: 820357430
}

这种直接覆盖资源的修改方式应该用put，但是每次都带有这么多无用的信息，那么可以发送PATCH https://www.jianshu.com/articles/820357430，这个时候只需要:

{
    author:'蔡徐坤',
}

07. HTTP请求报文是什么样的？

  • 请求行
  • 请求头部
  • 空行
  • 请求体

2019-06-14-11-24-10

2019-06-14-11-33-37

08. HTTP响应报文是什么样的？

  • 响应行
  • 响应头
  • 空行
  • 响应体

2019-06-14-11-37-02

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

常见的请求头：

  • Accept-Language：客户端接受的语言类型，用于告诉服务器在响应中使用何种语言
  • Connection：控制是否保持持久连接，可以设置为 keep-alive
  • Cookie：当前页面设置的Cookie
  • Host：发出请求的页面所在的域
  • Referer：发出请求的页面的URL
  • User-Agent：浏览器的用户代理标识
  • Content-Type: 指定请求体的类型
  • Content-Length: 指定请求体的长度

常见的响应头：

  • Date：响应创建的日期和时间
  • server: 服务器的名称和版本号
  • Cache-Control：控制HTTP缓存
  • Content-Type: 指定响应体的类型
  • Content-Length: 指定响应体的长度
  • Expires、ETag
  • Access-Control-Allow-Origin: 指定哪些域名可以访问资源

10. Content-Type 属性值有哪些？

  1. application/x-www-form-urlencoded：通常在 HTML 表单中使用，将表单数据编码为 URL 查询字符串形式
  2. multipart/form-data：通常用于表单上传文件
  3. application/json：JSON 格式的数据
  4. text/plain: 纯文本
  5. text/css: CSS 样式文件

11. HTTP状态码304是多好还是少好

304 是一种重定向状态码，用于告知客户端其缓存的资源仍然有效，无需重新下载。

搜索引擎蜘蛛会更加青睐内容源更新频繁的网站。通过特定时间内对网站抓取返回的状态码来调节对该网站的抓取频次。若网站在一定时间内一直处于304的状态，那么蜘蛛可能会降低对网站的抓取次数。相反，若网站变化的频率非常之快，每次抓取都能获取新内容，那么回访率也会提高。

12. OPTIONS请求

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

复杂请求会先发送一个预检请求，方法为 OPTIONS，只包含头部信息，不包含请求体，单独一个包发给服务器。包含如下字段：

Origin: 发送请求的页面的源

Access-Control-Request-Methods: 请求希望使用的方法

Access-Control-Request-Headers: (可选)要使用的逗号分隔的自定义头部列表

服务器拿到之后，可以确定是否允许这种类型的请求，然后在响应中发送如下头部信息（预检请求没有请求体和响应体），这个OPTIONS请求的响应状态为200时，才会继续发送真正的请求。

除了简单请求之外的都是复杂请求，简单请求满足的条件如下：

  1. 只可能有GET + POST +HEAD三种请求类型，而且必须满足下面的2和3两个特征
  2. 不能有自定义头字段 ，只能有以下几种：
    • Accept
    • Accept-Language
    • Content-Type
    • Content-Language
  3. Content-Type的值只能是以下三种：
    • text/plain
    • multipart/form-data
    • application/x-www-form-urlencoded

13. http1.0、http2.0、http3.0 之间的区别

http1.0：每次请求都要创建新的 TCP 连接，完成三次握手和四次挥手，网络利用率低；同时规定前一个响应完成后才能发送下一个请求，如果前一个请求被某种原因阻塞了，会导致后续请求无法发送，会造成队头阻塞的问题。

http2.0：

  1. 二进制分帧：将传输的消息分为更小的二进制帧，每帧有自己的标识序号，即便被随意打乱也能在另一端正确组装

  2. 多路复用：基于二进制分帧，在一个 TCP 连接中可以存在多条流，也就是可以发送多个请求，两端可以通过帧中的标识知道属于哪个请求

  3. 头部压缩：通过字典的形式，将头部中的常见信息替换为更少的字符，极大的减少了头部的数据量，从而实现更小的传输量

  4. 服务器推送：允许服务器直接推送消息给客户端

http3.0

http3.0 它完全抛弃了 TCP 协议，转而使用 UDP 协议，是为了进一步提升性能。 虽然 http2.0 进行了大量的优化，但它无法摆脱 TCP 协议本身的问题，比如建立连接时间长、对头阻塞问题等等。为了保证传输的可靠性，http3.0 使用了 QUIC 协议。

14. HTTP/2 服务器推送和 WebSocket的区别

HTTP/2 下服务器主动推送的是静态资源，和 WebSocket 等方式向客户端发送即时数据的推送是不同的。

HTTP2.0服务端推送的缺点就是只能向客户端推送静态资源，而不能推送自定义数据。

所谓的服务端推送，这里举个例子就很容易理解了：

  • HTTP/2 之前访问一个站点：
    • 服务器返回对应的 xxx.html 文件
    • 客户端预解析 xxx.html 文件
    • 根据预解析的识别到的 link、script 标签等并行加载文件资源
    • ...
  • HTTP/2 后访问一个站点:
    • 服务器返回对应的 xxx.html 文件，同时可以返回相应的 x.css、x.js 等资源，即实现了静态资源的提前请求，于是就能加快页面的渲染和显示。

15. 队头阻塞

队头堵塞是由 HTTP 的“请求-应答”模型导致的，HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本。

队头阻塞的解决方案： （1）并发连接：对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。 （2）域名分片：将域名分出很多二级域名，它们都指向同样的一台服务器，能够并发的长连接数变多，解决了队头阻塞的问题。

16. HTTP和HTTPS协议的区别

  • HTTP：超文本传输协议；HTTPS：超文本传输安全协议
  • HTTPS协议需要CA证书，费用较高；而HTTP协议不需要
  • HTTP协议的信息是明文传输的，安全性较差；HTTPS（SSL+HTTP）数据传输过程是加密的，安全性较好
  • HTTP协议端口是80，HTTPS协议端口是443
  • HTTP页面响应速度比 HTTPS 快，因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。

17. GET方法URL长度限制的原因

实际上HTTP协议规范并没有对get方法请求的url长度进行限制，而是特定的浏览器及服务器对它的限制。 IE对URL长度的限制是2083字节，由于IE浏览器对URL长度的允许值是最小的，所以只要URL不超过2083字节，那么在所有浏览器中工作都不会有问题。

18. 当在浏览器中输入网址并且按下回车之后发生了什么？

（1）解析URL： 首先会对 URL 进行解析，如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。

（2）缓存判断： 浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求。

（3）DNS解析： 下一步首先需要获取的是输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，如果有则使用，如果没有则向本地 DNS 服务器发起请求。本地 DNS 服务器也会先检查是否存在缓存，如果没有就会先向根域名服务器发起请求，获得负责的顶级域名服务器的地址后，再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，再向权威域名服务器发起请求，最终获得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用户。

（4）获取MAC地址： 当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址。通过将 IP 地址与本机的子网掩码相与，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关进行处理。

（5）TCP三次握手： 首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态，此时双方的连接就建立起来了。

（6）HTTPS握手： 如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。

（7）返回数据： 当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。

（8）页面渲染： 浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制，这个时候整个页面就显示出来了。

（9）TCP四次挥手： 最后一步是 TCP 断开连接的四次挥手过程。若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续一定的时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。

19. HTTP2的头部压缩算法是怎样的？

20. HTTP协议的优缺点

HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口，它使用 TCP 作为传输层协议，保证了数据传输的可靠性。

HTTP协议的优点：

  • 支持客户端/服务器模式
  • 简单快速：客户端向服务器请求时，只需传送请求方法和路径。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
  • 无连接：无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。
  • 无状态：HTTP 协议是无状态协议，这里的状态是指通信过程的上下文信息。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能会导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就比较快。

HTTP协议的缺点：

  • 无状态： HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。
  • 明文传输： 协议中的报文使用的是文本形式，这就直接暴露给外界，不安全。
  • 不安全

（1）通信使用明文（不加密），内容可能会被窃听； （2）不验证通信方的身份，因此有可能遭遇伪装； （3）无法证明报文的完整性，所以有可能已遭篡改；

21. 为什么 HTTP1.1 不能实现多路复用

HTTP/1.1 不是二进制传输，而是通过文本进行传输。由于没有流的概念，在使用并行传输（多路复用）传递数据时，接收端在接收到响应后，并不能区分多个响应分别对应的请求，所以无法将多个响应的结果重新进行组装，也就实现不了多路复用。

22. 简单讲解一下 http2 的多路复用

在 HTTP/2 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。 帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。 多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，两端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

23. http1.0和http1.1的区别

  1. http1.0 是非持久连接，而 http1.1 是持久连接。http1.1 通过使用持久连接来使多个 http 请求复用同一个 TCP 连接，以此来避免使用非持久连接时每次需要建立连接的时延。
  2. 在 http1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，http1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分。
  3. 在 http1.0 中主要使用 If-Modified-Since、Expires 来做为缓存判断的标准，http1.1 则引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match。
  4. http1.1 中新增了host字段，用来指定服务器的域名。
  5. http1.1 新增了一些请求方法，OPTIONS, PUT, DELETE, TRACE 和 CONNECT。

24. HTTP状态码

类别原因描述
1xxInformational(信息性状态码)接受的请求正在处理
2xxSuccess(成功状态码)请求正常处理完毕
3xxRedirection(重定向状态码)需要进行附加操作一完成请求
4xxClient Error (客户端错误状态码)服务器无法处理请求
5xxServer Error(服务器错误状态码)服务器处理请求出错

（1）2XX 成功

  • 200 OK，表示从客户端发来的请求在服务器端被正确处理
  • 204 No content，表示请求成功，但响应报文不含实体的主体部分
  • 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容

（2）3XX 重定向

  • 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
  • 302 found，临时性重定向，表示资源临时被分配了新的 URL

（3）4XX 客户端错误

  • 400 bad request，请求报文存在语法错误
  • 403 forbidden，表示对请求资源的访问被服务器拒绝
  • 404 not found，表示在服务器上没有找到请求的资源

（4）5XX 服务器错误

  • 500 internal sever error，表示服务器端在执行请求时发生了错误
  • 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

问题分析：同样是重定向，307，303，302的区别？

302是http1.0协议的状态码，在http1.1版本的时候为了细化302状态码⼜出来了两个303和307。 303明确表示客户端应当采⽤get⽅法获取资源，他会把POST请求变为GET请求进⾏重定向。 307会遵照浏览器标准，不会从post变为get。

25. 301 和 302 的应用场景分别是什么

301 表示永久重定向，302 表示临时重定向。

如果浏览器收到的是 301，则会缓存重定向的地址，之后不会再重新请求服务器，直接使用缓存的地址请求，这样可以减少请求次数。但如果浏览器收到的是 302，则不会缓存重定向地址，浏览器将来会继续以原有地址请求。

因此，301 适合地址永久转移的场景，比如域名变更；而 302 适合临时转移的场景，比如首页临时跳转到活动页

26. 什么是HTTPS协议？

HTTPS 也就是超文本传输安全协议，经由HTTP进行通信，利用SSL/TLS来加密数据包。由于 HTTP协议采用明文传输，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。

27. HTTPS加密原理

HTTP的内容是明文传输的，数据传输的过程会经过中间代理服务器、路由器、WiFi热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，那么传输的内容就完全暴露了，甚至劫持者还可以篡改信息而不被通信双方察觉，这就是中间人攻击。所以我们需要对传输的内容进行加密。

加密流程演变：

1.对称加密：通信双方约定好一个密钥，之后每次传输的时候都采用这个密钥进行加密解密即可。但是这其中存在一个问题，就是双方如何约定一个仅双方知晓的密钥。如果服务器生成后传输给浏览器，那么这个密钥仍有被劫持的可能，那么后续的加密显然就失效了。

2.非对称加密：非对称加密采用公钥和私钥两把密钥，服务端将公钥发送给客户端，之后客户端每次传输数据之前都先采用公钥对要传输的数据进行加密，这样就保证了客户端到服务器端信息的安全，因为只有持有私钥的服务端才可以解密出客户端所发送的数据。但是服务器端发送的数据却是无法保证的，因为公钥是公开的，那么其他人就可以截获并解密出服务端发给客户端的数据。

一组公钥私钥可以解决单向的安全，那么其实用两组公钥私钥也可以保证传输的安全，但是非对称加密的效率低

某网站服务器拥有公钥A与对应的私钥A；浏览器拥有公钥B与对应的私钥B

浏览器把公钥B明文传输给服务器

服务器把公钥A明文给传输浏览器

之后浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥A解密。由于只有服务器拥有私钥A，所以能保证这条数据的安全。

同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后用私钥B解密。同时也可以保证这条数据的安全。

3.非对称加密+对称加密：既然非对称加密可以保证客户端发给服务端的信息只有服务端能读取，那么我们不难想到让客户端生成对称传输的密钥，然后用非对称加密中服务端发布的公钥对该密钥进行加密发给服务端，服务端收到之后用非对称加密中的私钥解密即可拿到对称加密的公钥。之后双方就可以采用这个密钥进行对称加密传输了。这样不仅保证了安全，效率也够高（相比于用两组公钥私钥进行数据的传输）

上面的方式看似安全，但其实还是存在一定的问题的。

服务端在发送公钥A给客户端时，如果被截取，那么攻击者可以把服务端本要发送给客户端的公钥A替换成自己生成的公钥B，这个操作对于客户端来说是不可得知的。那么后续客户端生成密钥X再加密发出时其实使用的就是攻击者生成的公钥B去进行加密的，那么攻击者就可以通过自己的私钥B解密出客户端生成的对称加密密钥X，然后再用服务端的公钥A加密后返回给服务端。

4.数字证书：其实之所以会存在上面的问题主要是因为服务端无法保证自己发出的公钥能够不被篡改地发送给客户端，即客户端不能确定接收到的公钥一定是服务端发送的。如果按照之前的方式再次对公钥进行加密，那么加密的密钥的传输仍然还是重复上面的问题。所以在这里引入了第三方机构（CA机构）来解决这样的情况。

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，当然这里还得保证证书本身的真实性。

28. 数字证书是什么？

由于没有办法确定得到的公钥就一定是安全的公钥，可能存在一个中间人，截取了对方发给我们的公钥，然后将他自己的公钥发送给我们，当我们使用他的公钥加密后发送的信息，就可以被他用自己的私钥解密。然后他伪装成我们以同样的方法向对方发送信息，这样我们的信息就被窃取了。为了解决这样的问题，可以使用数字证书。

首先使用一种 Hash 算法来对公钥和其他信息进行加密，生成一个信息摘要，然后让有公信力的认证中心（简称 CA ）用它的私钥对消息摘要加密，形成签名。最后将原始的信息和签名合在一起，称为数字证书。当接收方收到数字证书的时候，先根据原始信息使用同样的 Hash 算法生成一个摘要，然后使用公证处的公钥来对数字证书中的摘要进行解密，最后将解密的摘要和生成的摘要进行对比，就能发现得到的信息是否被更改了。

这个方法最要的是认证中心的可靠性，一般浏览器里会内置一些顶层的认证中心的证书，相当于我们自动信任了他们，只有这样才能保证数据的安全。

29. HTTPS握手过程

  • 客户端请求服务器，并告诉服务器自身支持的加密算法以及密钥长度等信息
  • 服务器响应公钥和服务器证书
  • 客户端验证证书是否合法，然后生成一个会话密钥，并用服务器的公钥加密密钥，把加密的结果通过请求发送给服务器
  • 服务器使用私钥解密被加密的会话密钥并保存起来，然后使用会话密钥加密消息响应给客户端，表示自己已经准备就绪
  • 客户端使用会话密钥解密消息，知道了服务器已经准备就绪。
  • 后续客户端和服务器使用会话密钥加密信息传递消息

30. HTTPS 握手过程中，客户端如何验证证书的合法性

  1. 校验证书的颁发机构是否受客户端信任。
  2. 对比系统时间，校验证书是否在有效期内。
  3. 通过校验对方是否存在证书的私钥，判断证书的网站域名是否与证书颁发的域名一致。

31. HTTPS的特点

  • 使用HTTPS协议可以进行加密传输、身份认证，防止数据被窃取、修改
  • HTTPS是目前最安全的解决方案，虽然不是绝对的安全，但是大幅增加了中间人攻击的成本
  • 服务器和客户端双方需要加密和解密处理，耗费更多服务器资源，过程复杂
  • 握手阶段比较费时，增加页面的加载时间
  • SSL证书是收费的，功能越强大的证书费用越高

32. 浏览器同域名请求的最大并发数限制

http2 一次最多能发几个请求：HTTP/2并没有限制一次性发送请求的数量

http1.1：对于同一个域名，浏览器最多只能同时创建 6 ~ 8 个 TCP 连接 (不同浏览器不一样)。因为一个tcp连接一次承载一个请求，也就是说一个时刻最多只能发起6~8个请求。

33. DNS完整的查询过程

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

比如要查询 www.baidu.com 的 IP 地址，首先会在浏览器的缓存中查找是否有该域名的缓存，如果不存在就将请求发送到本地的 DNS 服务器中，本地DNS服务器会判断是否存在该域名的缓存，如果不存在，则向根域名服务器发送一个请求，根域名服务器返回负责 .com 的顶级域名服务器的 IP 地址的列表。然后本地 DNS 服务器再向其中一个负责 .com 的顶级域名服务器发送一个请求，负责 .com 的顶级域名服务器返回负责 .baidu 的权威域名服务器的 IP 地址列表。然后本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，最后权威域名服务器返回一个对应的主机名的 IP 地址列表。

34. 迭代查询与递归查询

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

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

一般我们向本地 DNS 服务器发送请求的方式就是递归查询，因为我们只需要发出一次请求，然后本地 DNS 服务器返回给我 们最终的请求结果。而本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程，因为每一次域名服务器只返回单次查询的结果，下一级的查询由本地 DNS 服务器自己进行。

35. OSI七层模型

ISO为了更好的使网络应用更为普及，推出了OSI参考模型。

（1）应用层

OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。

  • 在客户端与服务器中经常会有数据的请求，这个时候就是会用到http(hyper text transfer protocol)(超文本传输协议)或者https.在后端设计数据接口时，我们常常使用到这个协议。
  • FTP是文件传输协议，在开发过程中，个人并没有涉及到，但是我想，在一些资源网站，比如百度网盘``迅雷应该是基于此协议的。
  • SMTP是simple mail transfer protocol（简单邮件传输协议）。在一个项目中，在用户邮箱验证码登录的功能时，使用到了这个协议。

（2）表示层

表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。

在项目开发中，为了方便数据传输，可以使用base64对数据进行编解码。如果按功能来划分，base64应该是工作在表示层。

（3）会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

（4）传输层

传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，TCP UDP就是在这一层。端口号既是这里的“端”。

（5）网络层

本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。我们可以这样理解，网络层规定了数据包的传输路线，而传输层则规定了数据包的传输方式。

（6）数据链路层

将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。 网络层与数据链路层的对比，通过上面的描述，我们或许可以这样理解，网络层是规划了数据包的传输路线，而数据链路层就是传输路线。不过，在数据链路层上还增加了差错控制的功能。

（7）物理层

实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。

OSI七层模型通信特点：对等通信 对等通信，为了使数据分组从源传送到目的地，源端OSI模型的每一层都必须与目的端的对等层进行通信，这种通信方式称为对等层通信。在每一层通信过程中，使用本层自己协议进行通信。

36. TCP/IP五层模型

从上到下分别为：应用层、传输层、网络层、数据链路层、物理层。在发送消息时，消息从上到下进行打包，每一层会在上一层基础上加包，而接受消息时，从下到上进行解包，最终得到原始信息。

其中：

  • 应用层主要面向互联网中的应用场景，比如网页、邮件、文件中心等等，它的代表协议有 http、smtp、pop3、ftp、DNS 等等
  • 传输层主要面向传输过程，比如 TCP 协议是为了保证可靠的传输，而 UDP 协议则是一种无连接的广播，它们提供了不同的传输方式
  • 网络层主要解决如何定位目标的问题，比如 IP、ICMP、ARP 等等
  • 数据链路层的作用是将数据可靠的传输到目标，比如常见的以太网协议、P2P 协议
  • 物理层是要规范网络两端使用的物理设备，比如蓝牙、wifi、光纤、网线接头等等

37. TCP 和 UDP的概念及特点

（1）UDP：用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。在OSI模型中，在传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。它的特点如下：

面向无连接：首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。

有单播，多播，广播的功能：UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。

不可靠性：首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。

头部开销小，传输数据报文时是很高效的。

（2）TCP传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP 是面向连接的、可靠的流协议。它有以下几个特点：

面向连接：发送数据之前必须在两端建立连接，建立连接的方法是“三次握手”，这样能建立可靠的连接。

仅支持单播传输：每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式。

可靠传输：对于可靠传输，判断丢包、误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

提供拥塞控制：当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞。

38. TCP和UDP的区别

UDPTCP
是否连接无连接面向连接
是否可靠不可靠传输，不使用流量控制和拥塞控制可靠传输（数据顺序和正确性），使用流量控制和拥塞控制
连接对象个数支持一对一，一对多，多对一和多对多交互通信只能是一对一通信
传输方式面向报文面向字节流
首部开销首部开销小，仅8字节首部最小20字节，最大60字节
适用场景适用于实时应用，例如视频会议、直播适用于要求可靠传输的应用，例如文件传输

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

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

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

40. TCP的重传机制

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

41. TCP的拥塞控制机制

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

  • 慢启动（慢开始）
  • 拥塞避免
  • 快速重传
  • 快速恢复

（1）慢启动（慢开始）

  • 在开始发送的时候设置cwnd = 1（cwnd指的是拥塞窗口）

  • 思路：开始的时候不要发送大量数据，而是先测试一下网络的拥塞程度，由小到大增加拥塞窗口的大小。

  • 为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限(ssthresh 状态变量)

    • 当cnwd < ssthresh，使用慢开始算法
    • 当cnwd = ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
    • 当cnwd > ssthresh，使用拥塞避免算法

（2）拥塞避免

  • 拥塞避免未必能够完全避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性增长，使网络不容易出现阻塞。
  • 思路： 让拥塞窗口cwnd缓慢的增大，即每经过一个返回时间RTT就把发送方的拥塞控制窗口加一
  • 无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。如图所示: 其中，判断网络出现拥塞的根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理。

（3）快速重传

  • 快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)。发送方只要连续收到三个重复确认就立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
  • 由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量

（4）快速恢复

  • 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
  • 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

42. TCP的流量控制机制

一般来说，流量控制就是为了让发送方发送数据的速度不要太快，要让接收方来得及接收。TCP采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。这里说的窗口大小其实就是每次传输的数据大小。

  • 当一个连接建立时，连接的每一端分配一个缓冲区来保存输入的数据，并将缓冲区的大小发送给另一端。
  • 当数据到达时，接收方发送确认，其中包含了自己剩余的缓冲区大小。（剩余的缓冲区空间的大小被称为窗口，指出窗口大小的通知称为窗口通告 。接收方在发送的每一确认中都含有一个窗口通告。）
  • 如果接收方应用程序读数据的速度能够与数据到达的速度一样快，接收方将在每一确认中发送一个正的窗口通告。
  • 如果发送方操作的速度快于接收方，接收到的数据最终将充满接收方的缓冲区，导致接收方通告一个零窗口 。发送方收到一个零窗口通告时，必须停止发送，直到接收方重新通告一个正的窗口。

43. TCP的可靠传输机制

44. TCP三次握手

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

  • 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN，此时客户端处于 SYN_SEND 状态。

  • 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

  • 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

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

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

45. TCP四次挥手

刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

  • 第一次挥手： 客户端会发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。

  • 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

  • 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

  • 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

那为什么需要四次挥手呢？

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四次挥手。

TCP 使用四次挥手的原因是因为 TCP 的连接是全双工的，所以需要双方分别释放到对方的连接，单独一方的连接释放，只代表不能再向对方发送数据，连接处于的是半释放的状态。

最后一次挥手中，客户端会等待一段时间再关闭的原因，是为了防止发送给服务器的确认报文段丢失或者出错，从而导致服务器 端不能正常关闭。

46. TCP粘包是怎么回事，如何处理?

默认情况下, TCP 连接会启⽤延迟传送算法 (Nagle 算法), 在数据发送之前缓存他们. 如果短时间有多个数据发送, 会缓冲到⼀起作⼀次发送 (缓冲⼤⼩⻅ socket.bufferSize ), 这样可以减少 IO 消耗提⾼性能.

如果是传输⽂件的话, 那么根本不⽤处理粘包的问题, 来⼀个包拼⼀个包就好了。但是如果是多条消息, 或者是别的⽤途的数据那么就需要处理粘包.

下面看⼀个例⼦, 连续调⽤两次 send 分别发送两段数据 data1 和 data2, 在接收端有以下⼏种常⻅的情况: A. 先接收到 data1, 然后接收到 data2 . B. 先接收到 data1 的部分数据, 然后接收到 data1 余下的部分以及 data2 的全部. C. 先接收到了 data1 的全部数据和 data2 的部分数据, 然后接收到了 data2 的余下的数据. D. ⼀次性接收到了 data1 和 data2 的全部数据.

其中的 BCD 就是我们常⻅的粘包的情况. ⽽对于处理粘包的问题, 常⻅的解决⽅案有:

  • 多次发送之前间隔⼀个等待时间：只需要等上⼀段时间再进⾏下⼀次 send 就好, 适⽤于交互频率特别低的场景. 缺点也很明显, 对于⽐较频繁的场景⽽⾔传输效率实在太低，不过⼏乎不⽤做什么处理.
  • 关闭 Nagle 算法：关闭 Nagle 算法, 在 Node.js 中你可以通过 socket.setNoDelay() ⽅法来关闭 Nagle 算法, 让每⼀次 send 都不缓冲直接发送。该⽅法⽐较适⽤于每次发送的数据都⽐较⼤ (但不是⽂件那么⼤), 并且频率不是特别⾼的场景。如果是每次发送的数据量⽐较⼩, 并且频率特别⾼的, 关闭 Nagle 纯属⾃废武功。另外, 该⽅法不适⽤于⽹络较差的情况, 因为 Nagle 算法是在服务端进⾏的包合并情况, 但是如果短时间内客户端的⽹络情况不好, 或者应⽤层由于某些原因不能及时将 TCP 的数据 recv, 就会造成多个包在客户端缓冲从⽽粘包的情况。 (如果是在稳定的机房内部通信那么这个概率是⽐较⼩可以选择忽略的)
  • 进⾏封包/拆包： 封包/拆包是⽬前业内常⻅的解决⽅案了。即给每个数据包在发送之前, 于其前/后放⼀些有特征的数据, 然后收到数据的时 候根据特征数据分割出来各个数据包。

47. 为什么UDP不会粘包？

  • TCP协议是⾯向流的协议，UDP是⾯向消息的协议。UDP段都是⼀条消息，应⽤程序必须以消息为单位提取数据，不能⼀次提取任意字节的数据
  • UDP具有保护消息边界，在每个UDP包中就有了消息头（消息来源地址，端⼝等信息），这样对于接收端来说就容易进⾏区分处理了。传输协议把数据当作⼀条独⽴的消息在⽹上传输，接收端只能接收独⽴的消息。接收端⼀次只能接收发送端发出的⼀个数据包,如果⼀次接受数据的⼤⼩⼩于发送端⼀次发送的数据⼤⼩，就会丢失⼀部分数据，即使丢失，接受端也不会分两次去接收。

48. webSocket 协议是什么

websocket 协议 HTML5 带来的新协议，相对于 http，它是一个持久连接的协议，它利用 http 协议完成握手，然后通过 TCP 连接通道发送消息，使用 websocket 协议可以实现服务器主动推送消息。

首先，客户端若要发起 websocket 连接，首先必须向服务器发送 http 请求以完成握手，请求行中的 path 需要使用ws:开头的地址，请求头中要分别加入upgrade、connection、Sec-WebSocket-Key、Sec-WebSocket-Version标记

然后，服务器收到请求后，发现这是一个 websocket 协议的握手请求，于是响应行中包含Switching Protocols，同时响应头中包含upgrade、connection、Sec-WebSocket-Accept标记

当客户端收到响应后即可完成握手，随后使用建立的 TCP 连接直接发送和接收消息。

49. 即时通讯的实现：短轮询、长轮询、SSE 和 WebSocket 间的区别？

短轮询和长轮询的目的都是用于实现客户端和服务器端的一个即时通讯。

短轮询的基本思路： 浏览器每隔一段时间向浏览器发送 http 请求，服务器端在收到请求后，不论是否有数据更新，都直接进行响应。这种方式实现的即时通信，本质上还是浏览器发送请求，服务器接受请求的一个过程，通过让客户端不断的进行请求，使得客户端能够模拟实时地收到服务器端的数据的变化。这种方式的优点是比较简单，易于理解。缺点是这种方式由于需要不断的建立 http 连接，严重浪费了服务器端和客户端的资源。当用户增加时，服务器端的压力就会变大，这是很不合理的。

长轮询的基本思路： 首先由客户端向服务器发起请求，当服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断服务器端数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则到达一定的时间限制才返回。客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。长轮询和短轮询比起来，它的优点是明显减少了很多不必要的 http 请求次数，相比之下节约了资源。长轮询的缺点在于，连接挂起也会导致资源的浪费。

SSE 的基本思想： 服务器使用流信息向服务器推送信息。严格地说，http 协议无法做到服务器主动推送信息。但是，有一种变通方法，就是服务器向客户端声明，接下来要发送的是流信息。也就是说，发送的不是一次性的数据包，而是一个数据流，会连续不断地发送过来。这时，客户端不会关闭连接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。SSE 就是利用这种机制，使用流信息向浏览器推送信息。它基于 http 协议，目前除了 IE/Edge，其他浏览器都支持。它相对于前面两种方式来说，不需要建立过多的 http 请求，相比之下节约了资源。

WebSocket 是 HTML5 定义的一个新协议议，与传统的 http 协议不同，该协议允许由服务器主动的向客户端推送信息。使用 WebSocket 协议的缺点是在服务器端的配置比较复杂。WebSocket 是一个全双工的协议，也就是通信双方是平等的，可以相互发送消息，而 SSE 的方式是单向通信的，只能由服务器端向客户端推送信息，如果客户端需要发送信息就是属于下一个 http 请求了。

上面的四个通信协议，前三个都是基于HTTP协议的。

对于这四种即使通信协议，从性能的角度来看： WebSocket > 长连接（SEE） > 长轮询 > 短轮询 但是，我们如果考虑浏览器的兼容性问题，顺序就恰恰相反了： 短轮询 > 长轮询 > 长连接（SEE） > WebSocket 所以，还是要根据具体的使用场景来判断使用哪种方式。

50. 介绍下如何实现 token 加密

以最常见的 token 格式 jwt 为例, token 分为三段，分别是 header、payload、signature。 其中，header 标识签名算法和令牌类型；payload 标识主体信息，包含令牌过期时间、发布时间、发行者、主体内容等；signature 是使用特定的算法对前面两部分进行加密，得到的加密结果。

token 有防篡改的特点，如果攻击者改动了前面两个部分，就会导致和第三部分对应不上，使得 token 失效。而攻击者不知道加密秘钥，因此又无法修改第三部分的值。

所以，在秘钥不被泄露的前提下，一个验证通过的 token 是值得被信任的。

51. http1.1 是如何复用 tcp 连接的

客户端请求服务器时，通过请求行告诉服务器使用的协议是 http1.1，同时在请求头中附带connection:keep-alive（为保持兼容），告诉服务器这是一个长连接，后续请求可以重复使用这一次的 TCP 连接。

这样做的好处是减少了三次握手和四次挥手的次数，一定程度上提升了网络利用率。但由于 http1.1 不支持多路复用，响应顺序必须按照请求顺序抵达客户端，不能真正实现并行传输，因此在 http2.0 出现之前，实际项目中往往把静态资源，比如图片，分发到不同域名下的资源服务器，以便实现真正的并行传输。

52. HTTP 劫持、DNS 劫持

http 劫持是指攻击者在客户端和服务器之间同时建立了连接通道，通过某种方式，让客户端请求发送到自己的服务器，然后自己就拥有了控制响应内容的能力，从而给客户端展示错误的信息，比如在页面中加入一些广告内容。

DNS 劫持是指攻击者劫持了 DNS 服务器，获得了修改 DNS 解析记录的权限，从而导致客户端请求的域名被解析到了错误的 IP 地址，攻击者通过这种方式窃取用户资料或破坏原有正常服务。

53. 进程和线程

进程：分配资源的基本单位，进程可以理解为我们在电脑上正在运行的一个个应用，例如：QQ，微信

线程：操作系统进行运算调度的最小单位，它被包含在进程中，是进程中的实际运作单位

通俗的讲：进程是一座正在运作的工厂，那么线程就是工厂里面的生产线

54. 端口的作用

作用是对TCP/IP体系的应用进程进行统一的标志，使运行不同操作系统的计算机的应用进程能够互相通信。简单来说，端口就相当于是进程的门牌号码。每个进程都可以绑定一个或多个端口，以便在与其他进程通信时被识别和访问。

avatar
文章
阅读
粉丝