「2022」寒冬下我的面试知识点复盘【计算机网络】篇

前言

笔者今年2022寒冬下成功跳槽了阿里，这篇文章就是将自己面试的一些准备、知识总结分享出来~

如果这篇文章对你有用，请一键三连（点赞评论+收藏）让更多的同学看到

如果需要转载，请评论区留言，未经允许请不要私自转载；

防杠声明

这篇文章不是纯堆砌面试题，而是以知识总结为主，主观观点和主观总结居多，里面总结的知识点在我这次的面试中也不全都有用到~如果有写错的地方欢迎评论区提出，如果只是要杠那请右上角X掉慢走；

传送门

这个专栏预计要做以下这些内容，可以根据自己的需要跳转查看

面经：「2022面经」：2年前端拿下字节阿里offer总结

专栏：2022寒冬下我的面试知识点复盘：

「2022」寒冬下我的面试知识点复盘【浏览器原理】篇

「2022」寒冬下我的面试知识点复盘【计算机网络】篇

「2022」寒冬下我的面试知识点复盘【JS】篇（加紧编写中）

「2022」寒冬下我的面试知识点复盘【CSS】篇

「2022」寒冬下我的面试知识点复盘【Vue3、Vue2、Vite】篇

「2022」寒冬下我的面试知识点复盘【工程化】篇（加紧编写中）

「2022」寒冬下我的面试知识点复盘【Nodejs】篇（加紧编写中）

「2022」寒冬下我的面试知识点复盘【TypeScript】篇（加紧编写中）

本文标题思维导图

计算机网络 篇

1.HTTP常见状态码

• 1xx: 接受，继续处理

• 101：在HTTP升级为WebSocket的时候，如果服务器同意变更，就会发送状态码 101。

• 103（Early Hints）：客户端应在服务端返回HTML前开始预加载资源

• 200: 成功，并返回数据

• 201: 已创建

• 202: 已接受

• 203: 成功，但未授权

• 204: 成功，无内容

• 205: 成功，重置内容

• 206: 成功，部分内容，用来实现断点续传

• 301: 永久重定向。场景是使用域名跳转，新的URL在响应中给出

• 302: 临时重定向。场景是未登陆的用户跳转登录；浏览器默认使用get方式重新发出请求，会导致第一次以post请求的参数丢失；（才衍生出了307状态码）

• 303: 临时重定向，强制浏览器将请求方法从POST改到GET；

• 304: 资源未修改，可使用缓存（协商缓存）

• 305: 需代理访问

• 307: 307 和 302 一样是临时重定向，唯一的区别在于，307 状态码不允许浏览器将原本为 POST 的请求重定向到 GET 请求上。

• 308: 308 和 301 一样是永久重定向，唯一的区别在于，308 状态码不允许浏览器将原本为 POST 的请求重定向到 GET 请求上。

• 400: 请求语法错误

• 401: 要求身份认证

• 403: 拒绝请求

• 404: 资源不存在

• 405: 请求方法不允许

• 500: 服务器错误

• 502: 网关错误：服务器作为网关或代理出现错误

• 503: 服务不可用：服务器目前无法使用

• 504: 网关超时：网关或代理服务器，未及时获取请求

详细说说 103 状态码 (Early Hints)

2022年 6月Chrome 官方宣布在 chrome 103 版本对 HTTP 103 状态码提供了支持；

Chrome 官方也宣布在 chrome 106 版本对 HTTP/2 Server Push进行禁用；

• 正常情况下，我们需要等待 HTML 页面的返回后，才可以知道下一步需要去加载哪些 JS、CSS文件，这中间有一段的等待时间就被浪费掉了；这尤其在SSR项目中尤为明显；
• HTTP 103 状态码可以返回一个初步的 HTTP 响应，浏览器可以使用这些提示来预连接，并在等待资源响应的同时请求子资源。
• 它在 SSR 项目里面会非常有用；在SPA项目里面，大部分的逻辑都在客户端，HTML 很小，这时候我们只需要用常规的preload、preconnect之类的手段就可以了；

103 状态码和 HTTP2服务器推送 的区别

使用HTTP2服务器推送时，很多资源其实浏览器第一次请求就已经缓存下来了，但是服务端推送仍然会推送已缓存的资源，会导致网络带宽浪费；这是它的一个缺点，所以使用的人也较少；

• HTTP2服务器推送是直接发送资源，而103状态码只是向浏览器发送资源提示，浏览器可以控制是否需要这些资源，因为相同的资源可能已经在浏览器缓存过了；
• 总的来说，HTTP103 Early Hints 它能够解决网络带宽浪费的问题，可以说是 HTTP/2 Server Push 的升级版。不过目前还没有完全覆盖服务器推送的所有用例；

为什么需要 302 307 308 状态码

• 301: 永久重定向。场景是使用域名跳转，新的URL在响应中给出
• 302: 临时重定向。场景是未登陆的用户跳转登录；浏览器默认使用get方式重新发出请求，会导致第一次以post请求的参数丢失；（才衍生出了307状态码）
• 303: 临时重定向，强制浏览器将请求方法从POST改到GET；
• 307: 307 和 302 一样是临时重定向，唯一的区别在于，307 状态码不允许浏览器将原本为 POST 的请求重定向到 GET 请求上。
• 308: 308 和 301 一样是永久重定向，唯一的区别在于，308 状态码不允许浏览器将原本为 POST 的请求重定向到 GET 请求上。

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）：绘制所有节点，为每一个节点适用对应的样式，绘制到屏幕上；
  • 绘制的过程中还有很多细节，包括说：
  • 构建图层树：需要对布局树进行分层，生成图层树（比如说Z轴排序）
  • 生成绘制列表：将图层的绘制拆分为很多的绘制指令，并按顺序组成绘制列表，并提交到合成线程中；
  • 光栅化（栅格化）生成位图：合成线程将图层划分成图块，并在光栅化线程池中将图块转换成位图。
    • 同时因为用户只能看到视口的这一部分，所以合成线程就会按照视口附近的图块来优先生成位图，
  • 显示：一旦所有的图块都被光栅化，合成线程就会提交绘图指令给浏览器进程；浏览器进程生成页面并显示到屏幕上；

3.TCP、UDP

TCP、UDP 的特点

• TCP是一个面向连接的传输层协议。是可靠的、基于字节流的；TCP还具有超时重传、拥塞控制的机制；
• 而UDP是一个无连接的传输层协议。

面向连接指的是需要三次握手建立链接

可靠性指 TCP 具有 确认应答ACK 和 序列号来实现可靠传输；

基于字节流指的是：UDP的传输是将一个完整的用户消息发送一个UDP报文；而TCP是将一条用户消息根据滑动窗口的字节大小，拆分成多个TCP报文段（TCP将数据看作一连串字节流）

TCP 和 UDP 的区别

• TCP 是面向连接的，UDP 是无连接的即发送数据前不需要先建立链接
• TCP 是可靠传输，保证数据正确且有序；UDP是不可靠的，可能丢包或乱序
• TCP 是面向字节流，UDP 面向报文，并且网络出现拥塞不会使得发送速率降低
• TCP 首部开销大，最小20字节最大60字节，而 UDP 首部开销小，仅8字节
• TCP 只能是 1 对 1 的，UDP 支持 1 对 1,1 对多；

HTTP 和 TCP 的不同

• HTTP的责任是去定义数据，在两台计算机相互传递信息时，HTTP规定了每段数据以什么形式表达才是能够被另外一台计算机理解。
• 而TCP所要规定的是数据应该怎么传输才能稳定且高效

TCP 的可靠性

• 序列号：TCP给每一个包一个序号，保证接收端的按序接受；
• 确认应答ACK：接收端收到包就会回一个相应的确认ACK，如果发送端在一个往返时延内未收到确认就会重传；
• 流量控制：通过控制发送者的发送速度来缓解接收者的拥塞；
• 拥塞控制：当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞；

流量控制 和 拥塞控制 的区别

• 流量控制 是作用于接收者的，它是控制发送者的发送速度从而使接收者来得及接收，防止丢失数据包的。
• 拥塞控制 是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况

流量控制机制 & 滑动窗口

• 对于发送端和接收端来说，TCP需要将发送的数据放到发送缓冲区，接收的数据放到接收缓冲区；
• 而流量控制的目的，就是为了提供一种机制：让发送端可以根据接收端的实际接受能力控制发送的数据量；
• TCP通过滑动窗口实现流量控制的机制，而滑动窗口大小是通过TCP首部的窗口大小字段来通知对方；
• TCP协议的头部信息中，有一个16位字段的窗口大小，窗口大小的内容就是接收端接收数据缓冲区的剩余大小；当接收端缓冲区面临溢出时，就会设置成一个更小值取告诉发送端要控制发送的数据量；发送端收到后就会对数据发送量进行调整，形成完整的流量控制；

拥塞控制机制

体现在四个方面

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

拥塞窗口 是指发送端还可以传输的数据量大小，上文提到有通过流量控制机制来限制发送窗口的大小，而最终会取两者之间的较小值；

三次握手

TCP 三次握手流程

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

TCP 快速打开（TFO）

TFO 就是为了减少三次握手带来的延时，

• 在 TFO 的流程中，首轮三次握手服务端会计算得到一个 TFO cookie，放到 TCP 报文的 Fast Open里面
• 客户端拿到这个 cookie 后缓存下来，并完成正常的三次握手；
• 下一次的三次握手，客户端就会将之前的 cookie 和 HTTP请求、SYN 发给服务端
• 服务端验证 cookie 是否合法，如果合法就正常返回 SYN+ACK；并且返回HTTP响应；
• 最后完成三次握手的剩余流程；

三次握手的意义

客户端和服务端都需要直到各自可收发，因此需要三次握手

• 第一次握手成功让服务端知道了客户端具有发送能力
• 第二次握手成功让客户端知道了服务端具有接收和发送能力，但此时服务端并不知道客户端是否接收到了自己发送的消息（如果服务端这时立刻给客户端发送数据，这个时候客户端可能还没有准备好接收数据）
• 第三次握手让服务端知道了客户端做好了接收自己发送的消息的准备

为什么 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 报文可以到达

4.HTTP

HTTP 是超文本传输协议，HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

HTTP 的特点

特点：无连接、无状态、灵活

• 无连接：每一次请求都要连接一次，请求结束就会断掉，不会保持连接（HTTP1.1后可以保持连接长连）；
• 无状态：每一次请求都是独立的，请求结束不会记录连接的任何信息，减少了网络开销，这是优点也是缺点
• 灵活：通过http协议中头部的Content-Type标记，可以传输任意数据类型的数据对象(文本、图片、视频等等)，非常灵活

缺点：无状态、不安全、明文传输、队头阻塞

• 无状态：请求不会记录任何连接信息，就无法区分多个请求发起者身份是不是同一个客户端的；
• 不安全：明文传输可能被窃听，缺少身份认证也可能遭遇伪装，还有缺少报文完整性验证可能遭到篡改
• 明文传输：报文(header部分)使用的是明文，直接将信息暴露给了外界，WIFI陷阱就是复用明文传输的特点，诱导你连上热点，然后疯狂抓取你的流量，从而拿到你的敏感信息
• 队头阻塞：开启长连接(下面有讲)时，只建立一个TCP连接，同一时刻只能处理一个请求，那么当请求耗时过长时，其他请求就只能阻塞状态(如何解决下面有讲)

HTTP 报文组成

http报文：由请求报文和响应报文组成

请求报文：由请求行、请求头、空行、请求体四部分组成

响应报文：由状态行、响应头、空行、响应体四部分组成

• 请求行：包括请求的方法，路径和协议版本
• 请求头/响应头：包含了请求的一些附加的信息，一般是以键值的形式成对存在
• 空行：协议中规定请求头和请求主体间必须用一个空行隔开，用来区分首部与实体，因为请求头都是key:value的格式，当解析遇到空行时，服务端就知道下一个不再是请求头部分，就该当作请求体来解析了；
• 请求体：对于post请求，所需要的参数都不会放在url中，这时候就需要一个载体了，这个载体就是请求主体
• 状态行：包含http协议及版本、数字状态码、状态码英文名称
• 响应体：服务端返回的数据

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跨域请求的预检请求；

GET 和 POST的区别

• 从Restful语义来看：GET用来无副作用的请求资源，理应幂等，POST用来新资源；
• 从参数角度来看：GET请求一般放在URL中，POST请求放在请求体中，看起来post比get安全，但是在抓包的情况下都是一样的（所以面试的时候别再说POST比GET安全了）。
• 从编码角度看：GET只能进行 url 编码，参数的数据类型只接受ASCII字符，而POST支持更多的编码类型且不对数据类型限制。
• 从回退角度来看：GET在浏览器回退时是无害的，而POST会再次发起请求
• 从记录角度来看：GET请求参数会被完整保留在浏览器的历史记录里，而POST中的参数不会被保留
• 从发送角度来看：GET请求会一次性发送请求报文，POST请求通常分为两个TCP数据包，首先发 header 部分，如果服务器响应 100， 然后发 body 部分。

是什么限制了GET方法的URL长度

从HTTP协议规范层面说，规范没有对URL的长度进行限制，是浏览器、代理服务器的读取有限制；

POST方法真的不能被缓存吗

默认情况下，post不会被缓存，但是如果我们有中间代理服务器（Node），也是可以实现缓存的；

HTTP 1.0

• http1.0只支持POST/GET/HEAD命令
• 不支持断点续传，也就是说，每次都会传送全部的页面和数据。
• 只使用 header 中的Last-Modified、If-Modified-Since（协商缓存） 和 Expires（强缓存） 作为缓存失效的标准。

HTTP 1.1

• 引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive；
• 引入了管道机制，即在同一个TCP连接里，客户端不用等待请求响应就可以发送多个请求，但要求服务端要按发送顺序返回；
• 支持断点续传，通过使用请求头中的 Range 来实现（206状态码）。
• HTTP 1.1 中新增加了 E-tag、If-None-Match、Cache-Control 等缓存控制标头来控制缓存失效。
• 使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。
• 新增方法：PUT、 OPTIONS、 DELETE等。
• 更多的缓存标识：Cache-Control、ETag、If-None-Match

缺点：

• 由于队头阻塞带来的高延迟
• 巨大的http头部
• 不支持服务器推送消息

HTTP 2.0

• 二进制分帧：在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP/2 中信息和数据体都是二进制，并且统称为"帧"：用头信息帧放头部字段，用数据帧放请求数据体，是一堆乱序的二进制帧，它们不存在先后关系，因此不需要排队等待，是HTTP2多路复用的基础。
• 头部压缩 HTTP2使用 HPACK算法 压缩头部然后再发送，并在两端维护了索引表，用于记录出现过的 header，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。
• 多路复用 在一个连接里，可以同时发送多个请求或回应，且不用按顺序一一对应，这样子解决了HTTP队头阻塞的问题。
• 服务器推送 允许浏览器发送一个请求后，服务器主动向浏览器推送与这个请求相关的资源，这样浏览器就不用发起后续请求去获取一些资源。但是Chrome106版本禁用了，改为103状态码；
  • 服务器推送时，客户端的特点：
    • 客户端可以缓存推送的资源
    • 客户端可以拒收推送过来的资源
    • 服务器可以按照优先级推送资源

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 中队头阻塞的问题（详细可阅读下文）

队头阻塞问题

队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞

TCP 队头阻塞

• TCP是可靠传输协议，当前一个数据丢失时，后面到的数据将在接收端等待到前一个丢失的数据被发送端重传并到达接收端为止
• 这种机制保证了数据的有序正确，但也有可能造成 TCP队头阻塞；

HTTP 队头阻塞

• HTTP1.1 允许在持久连接上可选的使用请求管道
• 管道允许客户端在已发送请求后就发送下一个请求，不需要等待前一个请求响应，借此来减少等待时间；
• 但是客户端要求服务端按照请求发送的顺序返回响应，原因很简单：HTTP请求和响应并没有序列号标识，无法将乱序的响应与请求关联起来；
• 也就意味着如果一个响应返回延迟了，那么后续的响应都会延迟；这就造成了 HTTP队头阻塞；

解决方法

• TCP队头阻塞问题是 TCP 自身的机制决定的，无法避免，所以 google 才推出 QUIC协议，也就是所谓的 HTTP3；

• HTTP2使用帧和流来传输数据，因为流的概念是虚拟的，所以HTTP2可以在一个TCP连接上用流同时发送多个帧，也就是所谓的多路复用：多个请求都复用一个连接来处理；

• 在流的层面上看，同个流的帧是严格有序的，而从连接的层面上看，传输的都是乱序的帧；多个请求、响应之间没有的顺序关系；也就不需要排队等待，避免了队头阻塞的问题；

• 简单来说：就是HTTP2通过帧、流、多路复用的方式，让请求和响应不用按顺序一一对应，解决队头阻塞的问题；

• 对于 HTTP1来说，可以使用 并发连接 和 域名分片 来一定程度上解决问题，chrome对单域名 限制并发6个TCP持久连接；而域名分片我们可以在一个域名下分出多个二级域名，而它们最终指向同一个服务器，这样可以并发的数量就更多；

总结

• HTTP/1.1有两个主要的缺点：安全不足和性能不高。

• HTTP/2完全兼容HTTP/1，头部压缩、多路复用等技术可以充分利用带宽，降低延迟，从而大幅度提高上网体验；

• QUIC 是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议。

5.HTTPS

实际上， HTTPS 并不是一个新的协议，它只是在 HTTP 和 TCP 的传输中建立了一个安全层，它其实就是 HTTP + SSL/TLS 协议组合而成，而安全性的保证正是 SSL/TLS 所做的工作。

HTTPS 的优缺点

优点

• 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器
• HTTPS 协议是可进行加密传输、身份认证的网络协议，要比 http 协议安全
• HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本（除非用户主动信任了伪造证书）

缺点

• 证书费用以及更新维护。
• https 加密解密需要消耗更多服务器资源；
• https 握手阶段比较费时，

HTTPS 和 HTTP 区别

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

HTTPS 握手

握手过程

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

客户端如何验证证书的合法性

• 首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验。
• 浏览器接着判断证书中的颁发者CA是否受信任，用以校验证书是否为合法机构颁发；
• 如果证书不可信，浏览器就会提示证书不可信。
• 如果证书可信，那么浏览器就会用 CA机构 的公钥对证书里面的签名进行解密，得到hash值和加密算法。
• 再用证书里提到的加密算法，将证书的明文内容加密成另一个hash值，对比两个hash值是否相同；相同则证明服务器发来的证书合法，没有被篡改。
• 再比对一下证书中的域名和当前请求的域名是否一致，以确保证书不会被掉包。
• 此时浏览器就可以读取证书中的公钥，用于后续加密了。

为什么需要三个 随机数

因为随机数是伪随机的，三个伪随机数就十分随机了

6.DNS

DNS 的作用

DNS 的作用就是通过域名查询到具体的 IP。是应用层协议，通常该协议运行在UDP协议之上，使用的是53端口号。

DNS 查询流程

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

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

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

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

递归查询 和 迭代查询

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

所以一般而言，本地DNS服务器查询是递归查询，而本地DNS服务器向其他域名服务器请求的过程是迭代查询的过程

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

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

DNS 实现负载平衡

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

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

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

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

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

7.计算机网络模型

OSI、TCP/IP、5层模型

各层基本作用

• 应用层：为应用程序提供网络服务；

• 表示层：数据格式化、加密、解密；

• 会话层：建立、维护、管理会话连接；

• 传输层：建立、维护、管理到端连接；

• 网络层：IP寻址和路由选择；

• 数据链路层：控制网络层与物理层之间通信；

• 物理层：通过光缆、无线电波等方式连接组网；传输比特流0和1；

网络层 IP寻址 和 路由

寻址就是根据IP地址找到具体的设备。

• 因为IPv4的网络是一个树状模型，顶层网络下方有多个子网，子网下方还有子网，最后才是设备；IP协议的寻址过程就是要逐级找到网络，最后定位设备；

路由就是选择数据传输的线路

• 在寻址过程中，数据总是存在于某个局域网中。如果目的地在局域网中，就可以直接定位到设备了；但是如果目的地不在局域网中，这个时候就需要再去往其它网络。
• 由于网络和网络之间是网关在链接，所以如果目的地IP不在局域网中，就要为IP封包选择通往下一个网络的路径，也就是选择其中一个网关；
• 当包去往下一个节点后，就进入了新的路由节点，然后就继续上述过程，直到最终定位到设备；

网络层就是通过IP寻址找到最终的设备，又要借助路由在每个节点选择数据传输的线路，所以路由和寻址是相辅相成的关系；

8.WebSocket

• WebSocket 是 Html5 定义的一个新协议，出现的目的是即时通讯，替代轮询
• 与传统的 http 协议不同，它实现了浏览器与服务器全双工通信。

HTTP 与 WebSocket

相同点：

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

不同点：

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

WebSocket 握手协议 与 Http握手 的区别

WebSocket 的握手协议相比 Http原本的握手协议 ，多了两个属性：

• Upgrade:webSocket
• Connection:Upgrade

客户端发送的握手协议，带有两个额外的属性，服务端就会返回101状态码，客户端收到101状态码后就成功

WebSocket 心跳

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

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

WebSocket 状态

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

• 0：表示正在连接
• 1：表示连接成功，可以通信了
• 2：表示连接正在关闭
• 3：表示连接已经关闭，或者打开连接失败

Websocket 和 socket 的区别

• Socket是应用层与TCP/IP协议通信的中间软件抽象层，它是一组接口。
• 而WebSocket则不同，它是一个完整的应用层协议，包含一套标准的API。

9.即时通信方案

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

方案选择

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

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

• 单工通信是指消息只能单方向传输的工作方式，数据信息从一端到另一端是单方向的。例：广播。

• 半双工通信可以实现双向的通信，但是不能在两个方向同时进行，必须交替进行。这中模式下，接收端和发送端可以互相转换。例：对讲机。

• 全双工通信是指在通信的任意时刻，都允许数据同时在两个方向上传输，在这个模式下，通信系统的每一端都设置了发送器和接收器