ps：前端very need to 弄 it ，本人也是大概了解了下，有错误地方请指出。tks~
HTTP
HTTP1.1版本
目前为止HTTP1.1版本应用于市场较多，在1.1之前版本还有91年的0.9版本，96年的1.0版本。相比于之前的版本，1.1版本更丰富完善，但也有遗留了些问题需要解决。
1.相比于1.0，每一次 HTTP 请求，就要建立一个 TCP 链接。1.1引入了持久连接，TCP连接默认不关闭，可以被多个请求复用（你要知道新建一个TCP连接很耗的）
2.管道机制（ pipelining），管道化是客户端可以同时发出多个HTTP请求，而在发送过程中不需要等待服务器对前一个请求的响应，只不过，客户端还是要按照发送请求的顺序来接收响应，也就是说，如果第一个请求耗费了服务器很多的处理时间，那么后面的请求都要等待第一个处理完，也就出现了线头阻塞（队首阻塞Head-of-line blocking），很多浏览器默认关闭了管道机制功能。所以现在使用HTTP1.1协议的应用，都是有可能会开多个TCP连接（虽然多个请求可以复用同一个TCP连接，但是在一个连接中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态），现代浏览器会针对单个域名开启 6 个连接，通过各个连接分别发送请求！HTTP2相对解决了这个问题
说到队首阻塞，我再多拉呱几句：
HTTP1.0版本：对于同一个TCP连接，所有请求放入队列中，只有前一个请求的响应收到了，然后才能发送下一个请求。可见，HTTP1.0的队首组塞发生在客户端。
HTTP1.1版本：对于同一个TCP连接，允许一次发送多个请求，也就是说，不必等前一个响应收到，就可以发送下一个请求，这样就解决了HTTP1.0的客户端的队首阻塞。但是，HTTP1.1规定，服务器端的响应的发送要根据请求被接收的顺序排队，也就是说，先接收到的请求的响应也要先发送。这样造成的问题是，如果最先收到的请求的处理时间长的话，响应生成也慢，就会阻塞已经生成了的响应的发送。也会造成队首阻塞。可见，HTTP1.1的队首阻塞发生在服务器端。
HTTP2版本
1.header压缩
2.多路复用
先来理解几个概念：
在过去， HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动
帧：HTTP2 数据通信的最小单位消息，每个帧都有对应流的标识。相比HTTP1.x文本传输解析，二进制帧解析就很方便了
流：存在于连接中的一个虚拟通道，你可以把每个请求当成一个流，流由帧组成
在一个TCP连接上，我们可以向对方不断发送帧，每帧的流标识这一帧属于哪个流，然后在对方接收时，根据标识拼接每个流的所有帧组成一整块数据。
把每个请求都当作一个流，那么多个请求变成多个流，请求响应数据分成多个帧，不同流中的帧交错地发送给对方，这就是 HTTP2 中的多路复用。
流的概念实现了单连接上多请求 - 响应并行，解决了线头阻塞的问题
3.服务端推送
浏览器发送一个请求，服务器主动向浏览器推送与这个请求相关的资源，这样浏览器就不用发起后续请求。
一般要求用HTTP2就得上HTTPS
HTTP2 vs HTTP1.X
1.所有通信都在单个连接上完成，不需要单独开TCP连接，能有效解决高延迟问题
2.header压缩体积更小，减少开销
3.有效解除队首阻塞问题
4.采用二进制格式，非文本格式
5.服务端主动推送响应
TCP
前端面试经常会被问到TCP协议中的三次握手四次挥手这种老生常谈的问题了。我以前也是一知半解，并没有好好去了解它。当然前端需要了解的也不需要太深度。毕竟咱只是切图的。废话不多说，上文：
三次握手
SYA/ACK：标志位，只为1或者0
SYN：1 表示发起连接
ACK：1 表示确认收到
seq：一个随机序号的数据包
ack：确认号，表示对这次数据包的确认，以及对下次收到数据包的期待
需要注意的是：
（A）不要将确认号ack与标志位中的ACK搞混了
（B）确认方ack=发起方seq+1，两端配对
大致过程：
客户端SYN=1发起连接，并发送一个seq=x的数据包（TCP规定SYN=1时必须发送一个序号包）
服务端ACK=1确认收到，ack=x+1表示我方到x为止的数据包已收到，期待客户端下次发我一个seq为x+1的数据包，SYN=1发起连接，并发送一个seq=y的数据包
客户端ACK=1确认收到。ack=y+1表示我方到y为止的数据包已收到，并发送一个seq=x+1的数据包
ok，收~
简单来：
A：你能听到吗？
B：我听得到，你能听到我吗？
A：我也听得到。
四次挥手
你可能会问三次挥手，为啥关闭需要四次？好看图：
核心其实也就多了第二步，保证数据传送完整。其他步骤类似三次挥手。
常见的面试问题二：
为啥不能直接2次握手？
还是以客户端A与服务端B为例。假设A向B发送了A1数据包，但由于传输链路问题滞后导致B没收到，A则没有收到B对A1数据包的确认。继而A向B发送了A2数据包，这时候如果B收到了A1数据包，则B返回一个确认数据包B1给A，但A由于已经丢弃了A1包，进而不能确认B1包，导致一直会保持这个‘僵尸’连接
HTTPS
HTTP vs HTTPS
- HTTP 是明文传输，HTTPS 通过 SSL\TLS 进行了加密，更安全
- HTTP 的端口号是 80，HTTPS 是 443
- HTTPS 需要到 CA 申请数字证书，一般需要交费
SSL握手
引用下阮一峰的原文
第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。
数字证书一般是用来确保公钥是属于服务器的，防止中间人攻击修改。
对称密钥与非对称密钥以及数字证书
1.对称密钥
就是加密和解密使用的是同一个密钥
这种对称密钥的弊端就是，可能被中间人拦截进行窥视和篡改
2.非对称密钥
看图就知道非对称密钥（RSA非对称加密算法）就是一对私钥和公钥，私钥只能自己知道，用来解密，公钥给大胖对信息数据加密。用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据， 只有对应的私钥才能解密。
这种非对称密钥的弊端就是，RSA算法贼慢~。也存在中间人拦截公钥的可能，如果拦截并修改了公钥，那么大胖如果想给bill发信息就尴尬了。所以就找可信的CA机构去搞一个数字证书（CA私钥+bill公钥（服务器公钥）+一些基本信息一起加密生成）。那么以C端和服务器通信为例：
服务器发送数字证书给C端，C端在浏览器里查看证书管理器，根据‘受信任的根证书颁发机构’查找解开数字证书的公钥，如果有，则解开数字证书，获得服务器公钥从而对数据进行加密进行通信。
