网上说浏览器在握手阶段拿到服务器的公钥之后，双方始协议出一个随机 token，之后就采用对称加密了。
请问这样做，仅仅是为了减少性能开销吗？
我感觉，真正的原因，会不会是，基于 rsa 的非对称加密本来就不适合双向的数据传输？试想，浏览器往服务器传送内容，这边用公钥加密，服务器那边用私钥解，这没问题。但反过来，服务器下发数据，那边用私钥加密，中间人可能有公钥，服务器传给浏览器的数据，就能被中间人解开了。
这才是 ssl 使用对称加密的原因？
请各位轻喷，我是小白。
对称加密确实就是为了性能，计算速度快，密钥长度短。RSA 都已经普遍 2048bit 了， AES 基本还是 256 对吧
第三点是公钥加密自然不能达到的，如果要做到同时具有保密性和完整性则需要客户端、服务端分别有公钥加密算法和签名算法，需要 4 对密钥。
前两点对自然定义不成立，因为用公钥+私钥加密混合形成的混合加密也是公钥加密算法，且也可以获得前两个优点。
> 但反过来，服务器下发数据，那边用私钥加密，中间人可能有公钥，服务器传给浏览器的数据，就能被中间人解开了。
这段话“连错误都算不上”，因为它不合语法（即这句话类型检查失败）。如果一个东西“用私钥加密”，那么这个东西一定是对称加密算法而不是非对称加密算法，因此“中间人有公钥”里的“公钥”和前文的“私钥”不能存在有意义的关系，更不可能用公钥去解密东西。
主可以比较下两者的运算性能。
更何况用非对称加密需要做两次运算，用自己的私钥签名后再用对方公钥加密。对称加密只需要做一次运算。
参考 cloudflare 文章：对称加密的效率 是 非对称加密的几万倍
A laptop can only perform a couple hundred RSA encryptions a second versus around ten million per second of the symmetric cipher AES.
https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/
典型的加密传输场景，服务器向客户端发信息不可能用自己的私钥加密，依然是用客户端的公钥加密。只有一种情况服务端会用自己的私钥，那就是数字签名。