HTTPS/TLS协商过程中会话密钥为何不使用非对称加密方案？

我正在学习HTTPS、SSL和TLS的工作原理，据我了解，从认证服务器获取证书时会得到公钥用于加密HTTP请求，但我无法理解的是，为什么浏览器需要生成对称加密的密钥，再用服务器提供的公钥加密该会话密钥。在我的认知中对称加密安全性更低，为什么不能像服务器向客户端下发证书那样，客户端也生成公私钥对发送给服务器？我想了解该实现方案的设计考量。

首先需要纠正一个常见认知偏差：对称加密的安全性并非天然低于非对称加密。在密钥长度足够、算法无公开漏洞的前提下，对称加密（比如AES-256）的破解难度甚至高于同安全级别的非对称加密（比如RSA），二者的核心差异是适用场景不同，而非绝对安全性的高低。

针对你提出的「客户端也生成公私钥对发给服务器，全程用非对称加密通信」的方案，主流TLS协议没有采用该设计主要有以下几方面考量：

• 性能开销差距极大
  非对称加密的计算复杂度是对称加密的数百到数千倍，在高并发的Web服务场景下，如果每个HTTP请求、响应的全量数据都用非对称算法加解密，服务器算力会被快速耗尽，根本无法支撑大规模用户访问。而对称加密运算速度极快，非常适合对大量传输数据做加解密处理。
• 客户端公钥的可信性无法保障
  服务器的公钥嵌在CA机构签发的数字证书中，浏览器可以通过内置的根证书链验证其真实性，避免中间人攻击替换公钥。如果客户端自行生成公私钥对发给服务器，这个客户端公钥没有可信第三方的背书，中间人可以在通信握手阶段直接替换客户端公钥为自己的公钥，同时拿到双方的真实公钥，全程窃听、篡改通信内容，整个加密链路的安全性直接失效。
• 非对称加密的载荷长度限制
  常用的RSA非对称加密算法，单条可加密内容的长度不能超过密钥长度减去填充数据长度，比如2048位的RSA密钥最多只能加密245字节的内容。而HTTP请求和响应的体积往往远大于这个数值，如果用非对称加密传输业务数据，需要额外做分片处理，会进一步拉高运算开销、提升协议复杂度，完全得不偿失。
• 前向安全性的实现成本过高
  现在主流的TLS 1.3协议已经基本放弃RSA密钥交换，改用ECDHE等临时密钥交换方案，会话密钥由双方通过临时参数协商生成，根本不会在链路上传输，即使服务器的长期私钥泄露，历史通信内容也无法被破解。如果用双端非对称加密的方案，要实现同等的前向安全性，需要双方频繁更换公私钥对，开销会高到完全无法落地。

内容的提问来源于stack exchange，提问作者Philz97