HTTP 申请复用 TCP 连贯
问：与服务端建设 HTTP 连贯后会断开 TCP 连贯吗，下一次申请须要从新建设连贯吗？
答：在 HTTP1.0 的时候建设 HTTP 连贯后默认会断开 TCP 连贯，除非在申请头设置 COnnection=keep-alive，然而 keep-alive 须要服务器反对。在之后的 HTTP1.1 中默认反对长连贯，除非申请头中设置 Connection=close。
一个 TCP 连贯中 HTTP 连贯能够一起发送吗
HTTP1.1 存在一个问题，单个 TCP 连贯同一时刻只能解决一个申请，意思是只能等到上一个申请相应了能力发送下一个申请。HTTP1.1 应用了 pipelining 技术来解决这个问题，能够先发送所有的申请而不必期待相应，然而相应后果必须和申请的程序统一，然而这样也会有一个问题就是前面的申请响应必须等到后面的响应完能力开始解决。这也称为 队头阻塞
在测试中，申请 1 和申请 2 顺次发送，申请 1 在服务端提早 2000ms 才返回，依照这个 pipelining 实践，申请 1 返回后果之前申请 2 不应该失去响应，但实际上申请 2 的响应并未被阻塞，而后发现申请 2 独自建设了连贯，发现是 express 的关系，测试发送两个申请 1，发现第二次发送复用了第一次申请的建设的 TCP 并且第一次响应胜利，第二次才响应，并且总共等待时间为 4000ms, 第二次申请期待第一次响应完才开始解决
同一浏览器对同一 host 建设 TCP 连贯数量有限度吗
有，HTTP1.1 时代 chrome 个别是 6 个。
http1.0 到 1.1 做的优化就是默认长连贯和一个连贯能够发送多个 http 申请
HTTP2 中应用多路复用技术解决同时发送申请的问题
强缓存
### 强缓存在命中缓存时不会从新发动申请，间接从浏览器获取缓存。
- Expires 设置缓存过期工夫 http1.0 的产物
- Cache-Control 设置缓存规定，取值可能是 public，private，max-age，s-max-age，no-cache，no-store，http1.1 的产物
- cahe-control 优先级高于 Expires
### 强制缓存生效后，会启用协商缓存 - Last-modified 和 if-modified-since 服务器响应返回 Last-modified 值为文件批改工夫，当再次申请这个资源时，申请头会设置 if-modified-since 值为 Last-modified 的值，如果没有区别会返回 304 和空的响应体。
- ETag 和 If-None-Match ETag 是资源的惟一标识，由服务端返回，浏览器申请同一资源时，会将这个值放在 If-None-Match 中
- ETag 是基于资源内容的，Last-modified 是基于资源批改工夫的，精度及优先级上 ETag 的形式更高。
### 理论如何应用缓存策略 - 对于频繁变动的资源，强缓存策略设置 no-cache 不走强缓存，在通过 ETag 走协商缓存
- 对于不常常变动的资源，通过强缓存策略的 max-age 设置
http1.1 存在问题
- 线头阻塞 尽管能够同时发送多个申请，然而还是要期待上一个响应完了，再解决下一个响应
-
http1 同时发送多个申请，针对同一域名只能同时发送固定个数的申请，其余申请被阻塞，晓得服务端有响应，其余申请能力真正被收回去，其余申请期待的工夫就是 stalled 工夫。
http2 降级了什么
- 多路复用 用于解决线头阻塞问题，能够边响应边发送申请，不必期待，http2 发送多个申请
- 二进制分帧 绝对与 http1.1 的文本传输，二进制传输解析性能高效
- 头部压缩 同一个字段屡次申请不会反复发送
HTTPS
HTTP 通信存在的问题
- 内容为明文，容易被窃听
- 无奈证实内容的完整性，容易被篡改
- 无奈验证通信方的身份，容易被假装
什么是 HTTPS
HTTPS 是在传输层和应用层封装了一层 SSL 或者 TLS 层
- 加密：应用对称加密算法和协商密钥进行数据加密
- 完整性：基于散列函数验证信息的完整性
- 认证：应用非对称加密实现身份认证
HTTPS 如何解决加密问题
对称加密
加密的密钥和解密的密钥必须是同一个，没有密钥就无奈解密，同理，只有有密钥谁都能够解密，但在互联网如何平安的传输密钥就是个问题
非对称加密
加密的密钥和解密的密钥不雷同。解密方公开公钥，本人保留对应的私钥，加密方依据公钥加密内容，解密方用私钥解密内容。这个过程即便两头被人拦挡内容，晓得了加密算法，没有私钥也无奈实现解密。参考求模运算。
齐全应用非对称加密也无奈解决完整性和平安问题，并且非对称加密性能低。
解决形式
HTTPS 应用非对称加密传输对称加密的密钥，而后应用对称加密传输内。因而，对称加密的密钥无奈被拦挡，所以无奈取得对称加密的密钥，因而保障了内容加密无奈破解。
HTTPS 如何解决
客户端先申请服务器的公钥 PK，而后发送一个随机数 num1，应用公钥加密后发送给服务端，服务端用本人的私钥解密拿到 num1；之后的通信服务端和客户端通信都应用 num1 进行对称加密，因为 num1 只有客户端和服务端晓得，两头被拿到了没有服务端的私钥就无奈解密拿到 num1。
但问题出在客户端须要先申请服务端的公钥，这个过程如何保障平安？
如果黑客两头拦挡了申请，并向客户端发送了本人的公钥，而后客户端用黑客的公钥加密发送数据给黑客，黑客用本人的私钥进行解密，客户端实际上和黑客在通信。
问题就出在客户端申请服务端 PK 的过程可能会被伪造，所以要将申请 PK 的过程也加密。想方法不去申请 PK，而是将 PK 内置到操作系统中。因而引入第三方 CA 证书，当时内置了第三方证书的 PK。
服务端须要请机构给本人颁发 lic，lic 是 CA 将服务端的 PK 应用私钥加密后的后果。
当初，客户端申请服务端时，服务端返回 CA 颁发给本人的 lic，客户端拿到 lic 后，能够应用 CA 的 pk 进行解密失去服务端的 PK
这时候如果黑客在服务端返回 lic 时候拦挡申请，即便能够通过 CA 的 pk 进行解密，如果试图批改服务端的 PK 然而没有 CA 的私钥无奈对数据进行加密，这样就保障了 PK 无奈被批改。
通过 CA 证书的形式就解决了身份认证的问题，应用非对称加密传输建设对称加密的密钥就保障了数据的加密。
然而当初是否保证数据不被篡改呢，或者是数据被篡改后客户端 / 服务端可能感知到，即保证数据的完整性？
答案是不行，黑客即便不晓得内容，但还是能够随便批改数据包的内容，这样客户端 / 服务端就无奈失去正确的数据包。
这时候就须要散列函数，散列函数给传输内容生成一个数字签名