加密世界有两种主流思路，HTTPS 实际用的是「对称 + 非对称」的组合——代理IP链路中真正给内容加密的，就是对称算法这位主力。先认识出场率最高的对称加密：发送方与接收方用同一把密钥，加密解密都靠它——像同一把锁的钥匙，你锁、我开，钥匙相同。代理IP链路中真正给内容加密的，就是这种又快又省的对称算法。
快是它的招牌
对称加密的特点是一个字「快」：它能高速处理海量数据，网页内容动辄几 MB，全靠它来实时加解密——这也是 HTTPS 选择它承担正文加密的原因，代理IP用户体感上的流畅正是它的功劳。这也是 HTTPS 选择它承担「正文加密」的原因——加密速度要跟得上内容的传输速度，体验才不打折。
对称加密的钥匙问题
对称加密有一个绕不开的难题：钥匙怎么安全地交给对方？如果钥匙也走明文传输，被中途截获就等于白加密；可双方原本就在不安全的信道上通信——这个「先有鸡还是先有蛋」的困境，是密码学最经典的问题之一，也是对称加密无法单独撑起 HTTPS 的原因。
密钥的另一个特性是「一次会话一把」：HTTPS 不会长期用同一把钥匙，每次建立连接都会生成一把新的会话密钥，用完即弃。这样即使某次会话的密钥泄露，也只影响那一次通信，不会连累其他会话——代理IP链路上的多次连接因此互不牵连。
钥匙怎么来的：随机生成
会话密钥由双方在握手时共同生成：各自贡献随机数、组合运算得到同一把钥匙。关键在于「共同生成」的过程本身要安全——这就引出另一种加密思路：能在不安全信道上安全交换钥匙的非对称加密。下一篇专门讲它。
对称加密用同一把密钥加解密、速度快适合海量内容——它的难题是钥匙怎么安全送达，解法是每次会话临时生成、用后即弃，再靠非对称加密护送钥匙。
对称加密像一把共用的钥匙：你锁我开都靠它，方便快捷——但怎么把钥匙安全送到对方手上，才是真正费脑筋的事。
对称加密快却苦于送钥匙，那有没有一种方法，能在别人眼皮底下安全地把钥匙交出去？下一篇看非对称加密的巧思。
对代理IP使用者而言，对称加密的知识价值在于理解「为什么 HTTPS 快」：正文加密用的是高速对称算法，握手才动用较慢的非对称运算——如果全程都用慢算法，网页加载会明显变卡。理解了这层搭配，就不会误以为「加密必然拖慢速度」。
对称加密的钥匙还有个安全细节：会话密钥只存在于内存、用完即弃，不落盘保存——即使设备被攻破，也难以翻出历史会话的钥匙。代理IP链路上的每次连接都遵循这个「不留痕」原则，会话之间的隔离因此更干净。
把对称加密的位置记准：它是 HTTPS 的「主力引擎」，承担了几乎全部内容加解密——日常浏览的流畅体验，靠的就是它高速运转；而它的钥匙安全，由非对称加密在握手时护航。引擎与护航各司其职，整套加密体系才又稳又快。