1.讲解一下HTTPS的工作原理
HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的简单描述如下：
-
浏览器将自己支持的一套加密规则发送给网站。
-
网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
-
获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
- 网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。
- 浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
2.讲解一下https对称加密和非对称加密
非对称加密： 接收方在发送消息前需要事先生成公钥和私钥，然后将公钥发送给发送方。发送放收到公钥后，将待发送数据用公钥加密，发送给接收方。接收到收到数据后，用私钥解密。 在这个过程中，公钥负责加密，私钥负责解密，数据在传输过程中即使被截获，攻击者由于没有私钥，因此也无法破解。 非对称加密算法的加解密速度低于对称加密算法，但是安全性更高。
几个名词要理清 RSA：非对称加密 AES：对称加密 生成一个随机字符串key 只有客户端和服务端有 他们两个通过这个key对数据加密和传输跟解密 这一个统称对称加密 CA：权威认证机构 服务器在建站的时候 去CA认证机构认证 得到对应的数字签名 相当于身份证号 客户端每次安装浏览器的时候 都会下载最新的CA列表 这个列表有对应的数字签名和服务器IP一一对应的列表 这就是为什么我们自己搭建的localhost没法发https的原因 因为没法进行CA认证 数字证书：包含了数字签名跟RSA公钥 数字签名：保证数字证书一定是服务器传给客户端的 相当于服务器的身份证ID 对称密钥： 对数据进行加密的key 非对称密钥： （k1， k2） k1加密的数据 只有k2能解开 k1位非对称公钥 k2为非对称私钥 非对称公钥：RSA公钥 k1加密的数据 只有k2能解开 非对称私钥：RSA私钥 k1加密的数据 只有k2能解开
3. 三次握手
下面符号的含义 SYN(联机) ACK(确认) FIN(结束)
第一次握手：客户端采用TCP协议将带有SYN标志的数据包发送给服务器，等待服务器的确认。
第二次握手：服务器端在收到SYN的数据包后，必须确认SYN，并发送的ACK标志，同时，自己也将会向客户端发送一个SYN标志。
第三次握手：客户端在接收到服务器段的SYN+ACK包后，自己会向服务器发送ACK包，完成三次握手。那么客户端和服务器正式建立了连接，开始传输数据。
4. 四次挥手
1. 当客户端的数据传输到尾部时，客户端向服务器发送带有FIN标志的数据包，使其明白自己准备断开通信了。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 因为TCP的通信是使用全双工通信的，所以在断开连接的时候也应该是双向的；当服务器收到带有FIN标志的数据包时，
其必不会直接发送FIN标志断开通信的请求，而是先发送一个带有ACK标志的应答信息，使客户端明白服务器还有数据要进行发送。
3. 服务器的数据发送完成后，向客户端发送带有FIN标志的数据包，通知客户端断开连接。
4. 当客户端收到FIN后，担心某些不可控制的因素导致服务器不知道他要断开连接，会发送ACK进行确认，同时把自己设置成TIME_WAIT状态并启动定时器，在TCP的定时器到达后客户端并没有接收到请求，会重新发送；当服务器收到请求后就断开连接；当客户端等待2MLS（两倍报文最大生存时间）后，没有收到请求重传的请求后，客户端这边就断开连接，整个TCP通信就结束了。
5.为什么握手是三次，挥手是四次?
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文。
只有等到我Server端所有的报文都发送完了，才能发送FIN报文，因此不能一起发送。故需要四步握手。
6.为什么不能进行两次握手链接
如果是两次握手，在第二次结束后，服务器并不能保证客户端已经收到了第二次的请求，如此一来的话，服务器会一直保存着这个通信过程，
因为TCP通信都是要占用端口的，造成了一定的资源浪费。所以，就一定要让客户端来发送ACK的确认请求。
7.描述网页从输入url到渲染的过程
1.首先获取url 解析出ip地址 如果本地hosts中有配置优先取出配置 若没有则进行dns解析
2.tcp 三次挥手 建立连接
3.客户端发送http请求
4.服务器处理请求并响应
5.浏览器处理资源文件进行渲染
6.tcp的四次挥手
8.https的传输过程
1.在服务器端存在一个公钥及私钥
2.客户端从服务器取得这个公钥
3.客户端产生一个随机的密钥
4.客户端通过公钥对密钥加密（非对称加密）
5.客户端发送到服务器端
6.服务器端接受这个密钥并且以后的服务器端和客户端的数据全部通过这个密钥加密
9.https和http的区别
1.https需要证书。
2.http是超文本传输协议，是明文传输，https则是具有安全性的ssl加密传输协议。
3.http和https使用的端口不同，前者是80，后者是443。
4.http的连接很简单，无状态；HTTPS是由SSL+HTTP构建的可进行加密传输、身份认证的网络协议，比http协议安全。
10.http1.x和http2.0的区别
HTTP/1.x 有连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷 HTTP/2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能，但是还是存在着问题的
1. http1.0 不能保持连接,每次都要重新三次握手,四次挥手,效率低;虽然http1.1增加了keep-alive保持连接,但是连接数只能在6-8个内,数量有限.
2.http2.0 的优点有:
[1] 头部压缩,可以对比着diff记,每次只传输有差异的部分,头部在浏览器,服务器双方建了一个公共表
[2] 支持服务端推送,在服务器发送html页面时,服务器同时也发送js/css等,减少了请求数,当然也遵循同源策略,浏览器可以拒绝接收,当有浏览器缓存时,发送RST_StREAM拒收.
[3] 多路复用,用帧对数据顺序标记,还有流是一个虚拟的双向通道,有标识,最终会按顺序合并.可以并发,解决了多次连接问题,以及上线之后缓存的问题,可以模块单独上线.
在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。
为了减少这块的资源消耗并提升性能， HTTP/2对这些首部采取了压缩策略：
HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；
首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值
例如下图中的两个请求， 请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销
HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。
11 重点,输入url到页面渲染经历了什么?
1. DNS解析(如果是IP,那么不用解析),先在浏览器缓存中找,没找到就去操作系统的hosts文件中找DNS解析记录,没有就去本地DNS服务器中解析,不行再去根域名服务器上找,不行再主域名,经过DNS迭代找到最终的IP和TTL,TTL是DNS解析记录在本地保留的时间;
2. TCP三次握手;
3. 浏览器发起HTTP请求报文,服务器返回HTTP响应报文;
4. TCP四次挥手;
5. 浏览器对此进行解析和渲染;那么从上至下进行解析;
按照HTMLParser解析DOM树,
1.浏览器通过 HTMLParser 根据深度遍历的原则把 HTML 解析成 DOM Tree。
2.浏览器通过 CSSParser 将 CSS 解析成 CSS Rule Tree（CSSOM Tree）。
3.浏览器将 JavaScript 通过 DOM API 或者 CSSOM API 将 JS代码解析并应用到布局中，按要求呈现响应的结果。
根据 DOM 树和 CSSOM 树来构造 render Tree。
4.layout：重排（也可以叫回流），当 render tree 中任一节点的几何尺寸发生改变，render tree 就会重新布局，重新来计算所有节点在屏幕的位置。
5.repaint：重绘，当 render tree 中任一元素样式属性（几何尺寸没改变）发生改变时，render tree 都会重新画，比如字体颜色，背景等变化。
6.paint：遍历 render tree，并调动硬件图形 API 来绘制每个节点。
6. 遇到defer async则异步加载,到了body标签开始渲染,通过之前解析的DOM树和CSSOM 树合成渲染树;
7. 初次渲染必定会触发回流重绘.
8. 为了限制回流重绘的次数,因此我们要防抖和节流
从浏览器地址栏输入url到显示页面的步骤(以HTTP为例)
1在浏览器地址栏输入URL
2浏览器查看缓存，如果请求资源在缓存中并且新鲜，跳转到转码步骤
3如果资源未缓存，发起新请求
如果已缓存，检验是否足够新鲜，足够新鲜直接提供给客户端，否则与服务器进行验证。
检验新鲜通常有两个HTTP头进行控制Expires和Cache-Control：
HTTP1.0提供Expires，值为一个绝对时间表示缓存新鲜日期
HTTP1.1增加了Cache-Control: max-age=,值为以秒为单位的最大新鲜时间
浏览器解析URL获取协议，主机，端口，path
浏览器组装一个HTTP（GET）请求报文
浏览器获取主机ip地址，过程如下：
浏览器缓存
本机缓存
hosts文件
路由器缓存
ISP DNS缓存
DNS递归查询（可能存在负载均衡导致每次IP不一样）
4打开一个socket与目标IP地址，端口建立TCP链接，三次握手如下：
客户端发送一个TCP的SYN=1，Seq=X的包到服务器端口
服务器发回SYN=1， ACK=X+1， Seq=Y的响应包
客户端发送ACK=Y+1， Seq=Z
5TCP链接建立后发送HTTP请求
6服务器接受请求并解析，将请求转发到服务程序，如虚拟主机使用HTTP Host头部判断请求的服务程序
服务器检查HTTP请求头是否包含缓存验证信息如果验证缓存新鲜，返回304等对应状态码
处理程序读取完整请求并准备HTTP响应，可能需要查询数据库等操作
服务器将响应报文通过TCP连接发送回浏览器
浏览器接收HTTP响应，然后根据情况选择关闭TCP连接或者保留重用，关闭TCP连接的四次握手如下：
主动方发送Fin=1， Ack=Z， Seq= X报文
被动方发送ACK=X+1， Seq=Z报文
被动方发送Fin=1， ACK=X， Seq=Y报文
主动方发送ACK=Y， Seq=X报文
浏览器检查响应状态吗：是否为1XX，3XX， 4XX， 5XX，这些情况处理与2XX不同
如果资源可缓存，进行缓存
对响应进行解码（例如gzip压缩）
根据资源类型决定如何处理（假设资源为HTML文档）
解析HTML文档，构件DOM树，下载资源，构造CSSOM树，执行js脚本，这些操作没有严格的先后顺序，以下分别解释
构建DOM树：
Tokenizing：根据HTML规范将字符流解析为标记
Lexing：词法分析将标记转换为对象并定义属性和规则
DOM construction：根据HTML标记关系将对象组成DOM树
解析过程中遇到图片、样式表、js文件，启动下载
构建CSSOM树：
Tokenizing：字符流转换为标记流
Node：根据标记创建节点
CSSOM：节点创建CSSOM树
根据DOM树和CSSOM树构建渲染树:
从DOM树的根节点遍历所有可见节点，不可见节点包括：1）script,meta这样本身不可见的标签。2)被css隐藏的节点，如display: none
对每一个可见节点，找到恰当的CSSOM规则并应用
发布可视节点的内容和计算样式
js解析如下：
浏览器创建Document对象并解析HTML，将解析到的元素和文本节点添加到文档中，此时document.readystate为loading
HTML解析器遇到没有async和defer的script时，将他们添加到文档中，然后执行行内或外部脚本。这些脚本会同步执行，并且在脚本下载和执行时解析器会暂停。这样就可以用document.write()把文本插入到输入流中。同步脚本经常简单定义函数和注册事件处理程序，他们可以遍历和操作script和他们之前的文档内容
当解析器遇到设置了async属性的script时，开始下载脚本并继续解析文档。脚本会在它下载完成后尽快执行，但是解析器不会停下来等它下载。异步脚本禁止使用document.write()，它们可以访问自己script和之前的文档元素
当文档完成解析，document.readState变成interactive
所有defer脚本会按照在文档出现的顺序执行，延迟脚本能访问完整文档树，禁止使用document.write()
浏览器在Document对象上触发DOMContentLoaded事件
此时文档完全解析完成，浏览器可能还在等待如图片等内容加载，等这些内容完成载入并且所有异步脚本完成载入和执行，document.readState变为complete,window触发load事件
显示页面（HTML解析过程中会逐步显示页面）
