思想实验：如果全球网站一夜之间弃用HTTPS，能为地球节省多少电？
本文永久链接 – https://tonybai.com/2025/05/16/energy-savings-if-abandon-https
大家好，我是Tony Bai。
如今，当我们浏览网页时，地址栏那把绿色的小锁和 HTTPS 前缀已是司空见惯。从网上银行到个人博客，再到每一个SaaS服务，HTTPS/TLS 加密几乎覆盖了互联网的每一个角落。它像一位忠诚的数字保镖，守护着我们在虚拟世界中的数据安全与隐私。
然而，这位保镖并非“免费服务”。HTTPS/TLS 在带来安全的同时，也无可避免地引入了额外的计算和传输开销，直观感受便是连接速度可能略有减慢，传输数据量也略有增加。而且，随着我们对安全的追求永无止境，为了抵御更强大的计算破解能力，加密算法的密钥长度也在不断增加（例如从 RSA 1024位到2048位甚至更高，ECC 曲线的复杂度也在提升），这无疑进一步加剧了这些开销。
那么，今天我们不妨来做一个大胆的，甚至有些“异想天开”的思想实验：如果在一夜之间，全球所有的网站都决定弃用 HTTPS/TLS，回归到“裸奔”的 HTTP 时代，理论上能为我们的地球节省多少电力呢？
重要声明： 这纯粹是一个思想实验，旨在通过一个极端的假设，引发我们对技术成本（特别是能源成本）和安全效益之间平衡的思考。我们绝非鼓吹放弃 HTTPS/TLS，其在现代互联网安全中的基石地位无可替代。
HTTPS 的“能源账单”：开销源自何方？
要估算节省的电量，首先得理解 HTTPS/TLS 的主要开销在哪里。这些开销主要体现在两个方面：计算开销和数据传输开销。
计算开销 (CPU 的额外负担)
- TLS 握手阶段： 这是计算密集型操作的重灾区。
- 非对称加密/密钥交换： 如 RSA、Diffie-Hellman 或 ECC (椭圆曲线加密)，用于安全地协商后续通信所用的对称密钥。密钥长度的增加，使得这些运算的计算量呈指数级或更高阶的增长。 例如，一个 RSA 2048 位操作的计算量远超 1024 位。
- 证书验证： 客户端需要验证服务器证书链的有效性，这涉及到一系列的数字签名验证操作，同样消耗 CPU 资源。
- 对称密钥生成与哈希计算： 用于生成会话密钥、消息认证码 (MAC) 等。
- 数据传输阶段：
- 对称加解密： 建立连接后，所有应用数据的传输都需要经过对称加密算法（如 AES）的加密和解密。虽然对称加密比非对称加密快得多，但对于海量数据流，累积的 CPU 开销依然可观。
- 消息认证码 (MAC) 计算： 为确保数据完整性，需要为每个数据包计算和验证 MAC。
这些计算开销不仅发生在服务器端（数据中心），也发生在每一个发起 HTTPS 请求的客户端设备上（我们的电脑、手机等）。
数据传输开销 (网络带宽的额外占用)
- TLS 握手数据包： 完整的 TLS 握手过程（尤其是在未使用会话复用或 TLS 1.3 的 0-RTT 时）需要多个数据包的往返，这些数据包承载了证书、加密套件协商信息、密钥交换参数等，本身就构成了额外的网络流量。
- TLS 记录层头部： 每个 TLS 记录包都会增加一个小的头部，指明内容类型、版本和长度。
- 填充数据 (Padding)： 某些块加密模式可能需要填充数据以满足块大小要求。
这些额外的字节虽然对单个请求来说可能不多，但考虑到全球互联网的流量规模，累积起来也是一个惊人的数字。这些额外的数据不仅消耗了网络设备（路由器、交换机、基站）的传输和处理电力，也增加了数据中心内部的存储和带宽压力。
尝试量化：一个极度简化的估算
精确计算全球弃用 HTTPS 能节省多少电量几乎是不可能的，因为这涉及到太多动态和难以获取的数据。但我们可以尝试进行一个基于合理假设的粗略数量级估算，目的在于理解其可能的影响范围。
请注意：以下估算高度简化，仅为引发思考，不代表任何精确的科学结论。
- 假设一：全球每日 HTTPS 请求数。 据一些行业报告估计，全球每日的 HTTP(S) 请求量可能达到数百万亿甚至更高。我们不妨取一个相对保守的中间值。
- 假设二：单次 TLS 握手与数据加解密的平均额外能耗。 这取决于多种因素，包括密钥长度、加密算法、硬件加速能力等。我们可以参考一些研究中关于 CPU 执行加密操作的功耗数据，或者服务器因处理 TLS 产生的额外负载百分比。
- 假设三：TLS 协议的平均数据开销。 TLS 握手通常会增加几KB的开销，后续记录层头部等开销相对较小，我们可以估算一个平均的额外数据传输百分比。
- 假设四：全球数据中心和网络基础设施的总能耗。 这同样是一个巨大的数字，数据中心本身就是能源消耗大户。
基于这些高度简化的假设，即使我们只考虑由于 TLS 计算和额外数据传输导致的 全球数据中心电力消耗增加 1%-5% （这已经是一个非常大胆且可能偏低的估计，因为 TLS 的影响是端到端的），考虑到全球数据中心年耗电量已达数百太瓦时 (TWh，1太瓦时=10亿度电) 的量级，这意味着：
理论上，弃用 HTTPS 每年节省的电力可能达到数个乃至数十个太瓦时。
这是什么概念？一个太瓦时的电力，足以供应数十万个普通家庭一年的用电。数十太瓦时，其能源足迹和碳排放影响将是巨大的。
再次强调，这只是一个非常粗略的“思想实验”级别估算。实际情况远比这复杂，例如：
- 现代 CPU 对 AES 等对称加密有硬件指令加速，大大降低了数据传输阶段的加密开销。
- TLS 1.3 显著优化了握手过程，减少了 RTT 和计算量。
- 会话复用技术能避免重复的完整握手。
- CDN 和边缘节点分担了部分 TLS 终结的压力。
但即便如此，考虑到密钥长度持续增加带来的计算压力，以及全球网络流量的爆炸式增长，HTTPS/TLS 的“能源税”依然是一个不容忽视的议题。
安全的代价：我们为何“心甘情愿”支付这笔账单？
既然 HTTPS/TLS 有如此“隐形”的能源成本，为何我们还要坚定不移地推动全网 HTTPS 化呢？
答案不言而喻：安全！
- 数据保密性： 防止敏感信息（如登录凭证、支付信息、个人隐私）在传输过程中被窃听。
- 数据完整性： 确保数据在传输过程中未被篡改。
- 身份认证： 验证通信对方（主要是服务器）的真实身份，防止中间人攻击。
在一个充斥着网络钓鱼、数据泄露、恶意劫持的数字时代，这些安全保障是我们进行在线活动的基础信任。与可能遭受的经济损失、声誉损害、隐私侵犯相比，HTTPS/TLS 的能源成本可以说是“必要的代价”。
追求平衡：我们能为“绿色安全”做些什么？
这次思想实验的目的，绝非要我们因噎废食，放弃安全。恰恰相反，它应该促使我们更积极地思考：如何在保障同等级别安全的前提下，追求更高的效率和更低的能耗？
- 持续优化协议与算法： TLS 1.3 就是一个很好的例子(Go标准库crypto/tls已经默认采用TLS 1.3)。未来是否还会有更轻量级、更高性能的安全协议或加密算法出现？
- 硬件加速的普及： 推动和利用 CPU、专用加密芯片对加密运算的硬件加速能力。
- 智能的会话管理： 更有效地利用会话复用、0-RTT 等技术，减少不必要的握手开销。
- 内容分发与边缘计算的优化： 在离用户更近的地方进行 TLS 终结，减少长距离加密传输的开销。
- 代码层面的优化： 对于应用开发者，合理设计 API，避免不必要的加密数据传输，选择合适的加密库和配置。
- 关注“适度安全”： 对于某些内部系统或低风险场景，是否可以采用与公网不同强度的、但依然安全的加密策略？（这需要非常谨慎的评估）。
小结：思想实验的价值在于警醒与前瞻
“如果全球网站弃用 HTTPS，能为地球节省多少电？” 这个问题的答案可能永远无法精确计算，但它像一面镜子，照见了我们为构建一个更安全的数字世界所付出的“隐形成本”之一。
这提醒我们，安全并非没有代价，技术进步需要在多个维度上寻求平衡。 在坚定不移地拥抱和强化网络安全的同时，我们也应该持续关注其对性能、资源和环境的影响，积极探索和实践更绿色、更高效的安全技术。
聊一聊，也帮个忙：
- 在你的日常工作中，是否感受过 HTTPS/TLS 带来的性能或资源开销？你是如何应对的？
- 对于未来网络安全技术的发展，你认为在“更安全”与“更高效/更绿色”之间，我们应该如何权衡？
- 除了电力消耗，你认为 HTTPS/TLS 还带来了哪些“隐性”成本或效益？
欢迎在评论区留下你的思考和问题。如果你觉得这篇文章提供了一个有趣的视角，也请转发给你身边的朋友和同事，一起参与这个“思想实验”！
想与我进行更深入的 Go 语言、网络安全与 AI 技术交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。
我们星球见！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.