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证书的形式就解决了身份认证的问题，应用非对称加密传输建设对称加密的密钥就保障了数据的加密。

然而当初是否保证数据不被篡改呢，或者是数据被篡改后客户端/服务端可能感知到，即保证数据的完整性？
答案是不行，黑客即便不晓得内容，但还是能够随便批改数据包的内容，这样客户端/服务端就无奈失去正确的数据包。

这时候就须要散列函数，散列函数给传输内容生成一个数字签名