HTTP与HTTPS区别

为什么要有HTTPS：因为HTTP不安全（因为HTTP是明文传输的）
安全通信需要具备的条件：机密性、完整性、身份认证、不可否认
HTTPS端口号：443 HTTP端口号：80
SSL(Secure Sockets Layer)/TLS(Transprot Layer Security)
HTTP明文传输存在的风险：窃听风险、篡改风险、冒充风险
HTTPS如何解决风险：混合加密实现信息的机密性、摘要算法实现完整性、数字证书解决了冒充的风险
HTTPS采用对称加密和非对称加密的方式：在通信建立之前使用非对称加密的方式，通信建立了之后使用对称加密的方式
摘要算法：用来实现完整性的，用来检验数据的完整性 客户端在发送明文之前通过摘要算法算出一个值，然后连同内容一起发送给服务器，服务器解密之后，用相同的摘要算法算出哈希值
数字证书：将公钥放在数字证书中，只要证书是可信的，公钥就是可信的

SSL/TLS协议流程

客户端向服务器索要并验证服务器的公钥、协商产生会话秘钥，采用会话秘钥进行通信
握手阶段的流程：（RSA算法）

  • ClientHello 客户端向服务器发起加密通信请求（客户端支持的SSL/TLS协议版本；客户端产生的随机数；客户端支持的密码套件列表）
  • ServerHello 确认SSL/TLS协议版本；服务器随机产生随机数；确认密码套件列表；服务器的数字证书
  • 客户端回应 客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的CA公钥对证书进行验证，如果证书没有问题，就提取出公钥，加密报文（一个随机数、加密通信算法改变通知、客户端握手结束通知，同时会把之前所有的内容做一个摘要，用来供服务端校验）
  • 服务器的最后回应 收到第三个随机数之后，通过协商的加密算法，算出本次通信的会话秘钥，然后向客户端发送最后的消息（加密算法改变通知、服务器握手结束通知，同时也会把之前所有的内容做一个摘要，用来供客户端校验）

证书验证：证书验证的过程是层层向下的，先验证根证书，然后在验证下面的证书；验证过程是先使用CA公钥解密签名，然后使用签名里面的Hash算法算出value，判断与签名里面的value是一致
RSA算法的缺陷：不支持向前保密 一旦服务器的私钥泄漏，之前截获的信息都能够被破解
ECDHE算法握手：在第四次握手之前就可以发送加密的HTTP数据

HTTPS优化

产生消耗的两个环节：TLS协议握手环节/对称报文的加密环节
TLS握手环节：会有网络延迟（最多增加2RTT），握手的过程中也会产生性能损耗（ECDHE中需要临时生成椭圆曲线的公私钥、客户端验证证书、双方计算pre-master）
优化方案：硬件优化（由于HTTPS是计算密集型，因此需要提升CPU）；软件优化（软件升级、协议优化）、证书优化、会话复用
协议优化：对秘钥交换过程进行优化
RAS秘钥交换算法的TLS握手过程，不仅慢，而且安全性也不高，因此尽量选用ECDHE交换算法，它支持抢跑，可以将往返由2RTT减少到1RTT，1.3中客户端把Hello和公钥交换这两个消息合并成了一个消息
TLS进行升级，1.2 -> 1.3 1.3完成升级只需要1RTT，而且安全性会更高
证书优化：证书传输、证书验证
证书传输优化：减少证书的大小，应该椭圆（ECDSA）证书，而不是RSA证书
证书验证优化：CRL（证书吊销列表）、OCSP（在线证书协议）、OCSP Stapling
OCSP Staping：服务器向CA周期性地查询证书状态，当有客户端发起连接请求时，服务器会把响应结果在TLS握手过程中发给客户端。
会话复用：Session ID、Session Ticket
Session ID：客户端和服务器首次TLS握手连接后， 双⽅会在内存缓存会话密钥，并⽤唯⼀的 Session ID 来标识，Session ID和会话秘钥相当key-value的关系。
缺点：随着客户端的增多，服务器的内存压力也会越大；网络服务一般都是由多台服务器通过负载均衡提供服务的，客户端再次连接也不一定会命中上次服务器，就还需要走完整的TSL握手过程
Session Ticket：服务器不再缓存每个客户端的会话秘钥，
服务器会加密会话秘钥作为Ticket发给客户端，交换客户端缓存该Ticket
对于集群的服务，要确保每台服务器加密会话密钥是一致的，这样客户端携带ticket访问一台服务器时，都能恢复会话。
Session ID和 Session Ticket都不具备向前的安全性
Pre-shared Key:重连TLS 0RTT，客户端会把Ticket和HTTP请求一同发给服务端

HTTP/1.1 与 HTTP/1.0

使用了TCP长连接的方式改善了HTTP/1.0短连接造成的新能开销；支持管道网络传输，第一个请求发出去之后，不必等其回来，这样可以减少整体的响应时间
HTTP/1.1性能瓶颈

  • 请求/响应头没有压缩就发送，只能压缩Body部分
  • 发送冗长的首部，每次发送相同的首部，浪费较多
  • 服务器是按顺序响应的，如果服务器响应慢，会导致客户端一直请求不到数据
  • 没有请求优先级的控制

  • 只能从客户端开始，服务器只能被动响应

    HTTP/2优化

  • 头部压缩 HPACK算法：客户端和服务器同时维护一张头部信息表，所有的信息都放入这个表中，以后只需要发送索引号就可以了

  • 二进制格式 头信息和数据体都采用了二进制的格式，且统称为帧：头信息帧和数据帧 （增加了数据的传输效率）
  • 数据流 每个请求或者回应的所有数据包称为一个数据流 每个数据流都有这独一无二的编号，客户端发出的数据流为奇数，服务器发送的数据流为偶数；同时可以指定数据流的优先级，优先级高的会被优先响应
  • 多路复用 在一个连接中并发多个请求或者回应，而不用按照顺序一一对应了；移除了HTTP/1.1中的串行请求，也不需要排队等待了，不会出现队头阻塞的问题了
  • 服务器推送 在一定程度上改善了传统的请求-应答的工作模式，服务器不再是被动的响应，也可以主动向客户端发送请求了

静态表编码：客户端和服务器两段都会建立和维护字典， 再⽤ Huffman 编码压缩 数据，可达到 50%~90% 的⾼压缩率
动态表编码：静态表中只包含了61种高频出现在头部的字符串，不在静态表中范围内的头部字符串就要自行构建动态表

HTTP/3

HTTP/2的问题是多个请求会复用一个TCP连接，下层TCP是不知道有多少个HTTP请求的，一旦发生了丢包现象，就会触发TCP的重传机制，这时候所有的HTTP请求都必须等待这个丢了的包被重传回来。
HTTP/3把HTTP下层的TCP协议改成了UDP；使用的是基于UDP的QUIC协议

HTTP/1.1如何优化

  • 避免发送HTTP请求 通过缓存的技术，将请求-响应的数据都缓存在本地；客户端在发送请求的时候带上缓存的字段；如果过期了就带上一个Etag字段向服务器重新发送请求
  • 减少HTTP的请求次数 减少重定向的次数（可以让中间代理的服务器去进行重定向）；合并资源（可以减少头部信息的发送）；延迟发送请求（按需获取，没有必要一次性发送所有的资源）
  • 减少HTTP响应的数据大小 压缩数据（有损压缩、无损压缩）