HTTP请求复用TCP连接问：与服务器建立HTTP连接后，TCP连接会断开吗，下次请求需要重新建立连接吗？答：在HTTP1.0中，HTTP连接建立后，默认会断开TCP连接，除非在请求头中设置COnnection=keep-alive，但keep-alive需要服务器支持。后续HTTP1.1默认支持长连接，除非在请求头中设置Connection=close。HTTP连接可以在TCP连接中一起发送吗？HTTP1.1存在问题。一个TCP连接一次只能处理一个请求，也就是说只有在上一个请求得到响应后才能发送下一个请求。HTTP1.1使用流水线技术解决了这个问题。可以先发送所有的请求，不等待响应，但是对应的结果必须和请求的顺序一致，但是还有一个问题就是后面的请求响应必须等待前面的响应。在处理开始之前完成。这也称为队头阻塞。测试中，请求1和请求2顺序发送，请求1在服务端延迟2000ms后返回。按照这个流水线理论，在请求1返回结果之前，请求2应该没有得到响应，但是实际上请求2的响应没有被阻塞，然后发现请求2建立了单独的连接，发现是express关系.测试发送了两次请求1，发现第二次发送复用了第一次请求建立的TCP，第一次响应成功，只有第二次响应，总等待时间为4000ms。第二个请求在开始处理之前等待第一个响应。同一个浏览器对同一个主机建立的TCP连接数有限制吗？是的，HTTP1.1时代的chrome一般是6个，http1.0到1.1做的优化就是默认长连接，一个连接可以发送多个http请求。HTTP2使用多路复用技术来解决同时发送请求的问题。Strongcache###Strongcache在命中缓存请求时不会重新发起，直接从浏览器中获取缓存。Expires设置缓存过期时间。http1.0的产品Cache-Control设置缓存规则。取值可以是public,private,max-age,s-max-age,no-cache,no-store,http1.1cache的产物-控制优先级高于Expires###强制缓存后无效，将启用协商缓存Last-modified和if-modified-since。服务器响应返回Last-modified值作为文件修改时间。再次请求该资源时，会设置请求头if-modified-since为Last-modified的值，若无差异则返回304和空响应体。ETag和If-None-MatchETag是资源的唯一标识，由服务器返回。当浏览器请求同一个资源时，会将这个值放入If-None-Match中。ETag是基于资源内容，而Last-modified是基于资源修改时间，ETag的准确率和优先级更高。###实际如何使用缓存策略对于经常变化的资源，设置no-cache强缓存策略不加强缓存，使用ETag协商缓存。对于不经常变化的资源，通过强缓存策略的max-age设置http1.1存在队头阻塞的问题。虽然可以同时发送多个请求，但是仍然需要等待上一个响应完成后才能处理下一个响应。http1可以同时发送多个请求。对于同一个域名，同一时间只能发送固定数量的请求，其他请求均被屏蔽。,知道服务器有响应了，其他的请求其实就可以发出来了，等待其他请求的时间就是stalled时间。http2升级了什么多路复用，解决了队头阻塞的问题。您可以在响应时发送请求，无需等待。http2在二进制帧中发送多个请求。与http1.1的文本传输相比，二进制传输分析性能高效。头部压缩同一字段多次请求不会发送重复HTTPSHTTP通信问题内容为明文，容易被窃听，无法证明内容的完整性，容易被篡改，无法验证通信的身份党，容易伪装什么是HTTPSHTTPS在传输层和应用层封装了一层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证书解决身份认证问题，通过非对称加密传输建立对称加密密钥来保证数据的加密。但是现在是不是可以保证数据不被篡改，或者说数据被篡改后client/server能不能感知到，即保证数据的完整性呢？答案是否定的，即使黑客不知道其中的内容，他仍然可以随意修改数据包的内容，从而使客户端/服务器无法获取到正确的数据包。这时候就需要一个哈希函数，哈希函数为传输内容生成数字签名
