interview Question
interview Question…
知识复习
无聊经典
- 盒子模型
IE 盒子模型 宽度=内容宽度+padding *2+border *2
w3c 盒子模型 宽度=内容宽度
通过 box-sizing 切换,默认为 content-box(w3c 盒子模型),border-box 时为 IE 盒子模型
八股文
Https
对称——AES DES
非对称——RSA
公钥通常存放在客户端,私钥通常存放在服务器。使用公钥加密的数据只有用私钥才能解密,反过来使用私钥加密的数据也只有用公钥才能解密。
任何正版操作系统都会将所有主流 CA 机构的公钥内置到操作系统当中,所以我们不用额外获取,解密时只需遍历系统中所有内置的 CA 机构的公钥,只要有任何一个公钥能够正常解密出数据,就说明它是合法的。
先用非对称搞个双方知道的密钥,再用该密钥来对称加密传输。。
CA 的作用,,让浏览器能拿到网站的公钥。。。
三次握手
- 发送端首先发送一个带有 SYN(synchronize)标志地数据包给接收方。(SYN(seq=a))
- 接收方接收后,回传一个带有 SYN/ACK 标志的数据包传递确认信息,表示我收到了。(SYNACK(seq=b,ack=a+1))
- 最后,发送方再回传一个带有 ACK 标志的数据包,代表我知道了,表示握手结束。(ACK(seq=a+1,ack=b+1))
四次挥手
- Client 发送一个 FIN,用来关闭 Client 到 Server 的数据传送,Client 进入 FIN_WAIT_1 状态(FIN(seq=a))
- Server 收到 FIN 后,发送一个 ACK 给 Client,确认序号为收到序号+1(与 SYN 相同,一个 FIN 占用一个序号),Server 进入 CLOSE_WAIT 状态。(ACK(seq=a+1))
- Server 发送一个 FIN,用来关闭 Server 到 Client 的数据传送,Server 进入 LAST_ACK 状态。(FIN(seq=b,ack=a+1))
- Client 收到 FIN 后,Client 进入 TIME_WAIT 状态,接着发送一个 ACK 给 Server,确认序号为收到序号+1,Server 进入 CLOSED 状态,完成四次挥手(ACK(seq=b+1))
- HTTP1.0 和 HTTP1.1
HTTP1.0 的每一次请求都伴随着一次三次握手的过程,并且是串行的请求,增加了不必要的性能开销
HTTP1.1 新增了长链接的通讯方式,减少了性能损耗
HTTP1.0 只有串行发送,没有管道
HTTP1.1 增加了管道的概念,使得在同一个 TCP 链接当中可以同时发出多个请求
HTTP1.0 不支持断点续传
HTTP1.1 新增了 range 字段,用来指定数据字节位置,开启了断点续传的时代
HTTP1.0 任务主机只有一个节点,所以并没有传 HOST
HTTP1.1 时代,虚拟机技术越来越发达,一台机器上也有可能有很多节点,故增加了 HOST 信息
在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准
HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag,If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
在 HTTP1.1 中新增了 24 个错误状态响应码,如 410(Gone)表示服务器上的某个资源被永久性的删除等。
- HTTP1.1 和 HTTP2
HTTP 协议的报文是由「Header + Body」构成的,对于 Body 部分,HTTP/1.1 协议可以使用头字段 「Content-Encoding」指定 Body 的压缩方式,比如用 gzip 压缩,这样可以节约带宽,但报文中的另外一部分 Header,是没有针对它的优化手段。
HTTP/2 没使用常见的 gzip 压缩方式来压缩头部,而是开发了 HPACK 算法,客户端和服务器两端都会建立和维护「字典」,用长度较小的索引号表示重复的字符串,再用 Huffman 编码压缩数据,可达到 50%~90% 的高压缩率。
HTTP1.1 采用明文的形式
HTTP/2 全⾯采⽤了⼆进制格式,头信息和数据体都是⼆进制
HTTP/2 的数据包不是按顺序发送的,同⼀个连接⾥⾯连续的数据包,可能属于不同的回应。(对数据包做了标记,标志其属于哪一个请求,其中规定客户端发出的数据流编号为奇数,服务器发出的数据流编号为偶数。客户端还可以指定数据流的优先级,优先级⾼的请求,服务器就先响应该请求)
HTTP/2 可以在⼀个连接中并发多个请求或回应。
如:在⼀个连接中,服务器收到了客户端 A 和 B 的两个请求,但是发现在处理 A 的过程中⾮常耗时,索性就先回应 A 已经处理好的部分,再接着回应 B 请求,最后再回应 A 请求剩下的部分。
服务器可以主动向客户端发送请
- HTTP2 和 HTTP3
HTTP2 是基于 TCP 协议实现的
HTTP3 是基于 UDP 协议实现的
UDP 的无连接,TCP 的连接,唯区别是,UDP 把只管发送,TCP 每次都对发送的数据进行 ACK 确认。
HTTP3 新增了 QUIC 协议来实现可靠性的传输
QUIC(Quick UDP Internet Connection)是谷歌制定的一种基于 UDP 的低时延的互联网传输层协议。
HTTP2 是基于 HTTPS 实现的,建立连接需要先进行 TCP 3 次握手,然后再进行 TLS 3 次握手,总共 6 次握手
HTTP3 只需要 QUIC 的 3 次握手
- HTTP 3.0 基于 udp 的话, 如何保证可靠的传输?
UDP 想要实现可靠性传输,通常的做法是在应用层模拟 TCP 的可靠性传输
HTTP 3.0 用的是 QUIC
并不意味着 QUIC 本身也是不可靠的!在许多方面,QUIC 应该被看作是一个 TCP 2.0。它包括 TCP 的所有特性(可靠性、拥塞控制、流量控制、排序等)的最佳版本,以及更多其他特性。QUIC 还完全集成了 TLS(参见图 6),并且不允许未加密的连接。
2022 年 6 月 6 日,IETF QUIC 和 HTTP 工作组成员 Robin Mark 在推特上宣布,历时 5 年,HTTP/3 终于被标准化为 RFC 9114 ,这是 HTTP 超文本传输协议的第三个主要版本。
- babel 与 polyfill 的关系以及区别
Babel 是一个广泛使用的 ES6 转码器,可以将 ES6 代码转为 ES5 代码。注意:Babel 默认只转换新的 JavaScript 句法(syntax),而不转换新的 API。
Polyfill 的准确意思为,用于实现浏览器并不支持的原生 API 的代码。
js–babel parse–>ast–plugins transforms–>ast–>babel generate –>js
babel-polyfill.js
babel-polyfill 是好东西,能够将新 API 作用在老的浏览器上。
@babel/runtime & @babel/plugin-transform-runtime 按需引入, 打包体积小 不能兼容实例方法
@babel/polyfill 完整模拟 ES2015+ 环境 打包体积过大、污染全局对象和内置的对象原型
@babel/preset-env 按需引入, 可配置性高 不支持 stage-x 插件,没有利用针对特定浏览器的功能
Https 证书 ca 的作用
CA 就有作用了,为了保证客户端获得的公钥是可靠的,不是别人冒充,CA 用于给网站颁发一个可信的证书
CA 就用于保证,你获得的公钥确实是你要访问的可靠网站的公钥,而不是别人冒充的。
证书在网站申请的时候便由 CA 生成。因为生成证书会用到 CA 私钥。
网站申请时,需要提供自己的公钥。 因为正式描述信息里包含了网站的公钥。
冒充因为没有正确私钥,就算得到正牌网站的公钥,也无法解出密文
从在浏览器地址栏中输入 URL 到页面显示,浏览器到底发生了什么
chrome 的主要进程架构
浏览器进程 (Browser Process):负责浏览器的 TAB 的前进、后退、地址栏、书签栏的工作和处理浏览器的一些不可见的底层操作,比如网络请求和文件访问。
渲染进程 (Renderer Process):负责一个 Tab 内的显示相关的工作,也称渲染引擎。
插件进程 (Plugin Process):负责控制网页使用到的插件
GPU 进程 (GPU Process):负责处理整个应用程序的 GPU 任务
首先,当我们是要浏览一个网页,我们会在浏览器的地址栏里输入 URL,这个时候 Browser Process 会向这个 URL 发送请求,获取这个 URL 的 HTML 内容,然后将 HTML 交给 Renderer Process,Renderer Process 解析 HTML 内容,解析遇到需要请求网络的资源又返回来交给 Browser Process 进行加载,同时通知 Browser Process,需要 Plugin Process 加载插件资源,执行插件代码。解析完成后,Renderer Process 计算得到图像帧,并将这些图像帧交给 GPU Process,GPU Process 将其转化为图像显示屏幕。
构建 DOM 过程中,如果遇到