http - Tony Bai

标签 http 下的文章

思想实验：如果全球网站一夜之间弃用HTTPS，能为地球节省多少电？

五月 16, 2025
0 条评论

本文永久链接 – 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 的“能源账单”：开销源自何方？

示意图来自bytebytego

要估算节省的电量，首先得理解 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 精进营”知识星球。

img{512x368}

我们星球见！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

从Go路由选择看“标准库优先”：何时坚守？何时拓展？

五月 14, 2025
2 条评论

本文永久链接 – https://tonybai.com/2025/05/14/which-go-router-should-you-use

大家好，我是 Tony Bai。

最近，知名 Go 博主 Alex Edwards 更新了他那篇广受欢迎的文章——“Which Go router should I use?”，特别提到了 Go 1.22 版本对标准库 http.ServeMux 的显著增强。这篇文章再次引发了我们对 Go Web 开发中一个经典问题的思考：在选择路由库时，我们应该坚守标准库，还是拥抱功能更丰富的第三方库？

这个问题，其实并不仅仅关乎路由选择，它更触及了 Go 开发哲学中一个核心原则——“标准库优先” (Standard Library First)。今天，我们就以 Go 路由选择为切入点，聊聊这个原则，以及在实践中我们该如何权衡“坚守”与“拓展”。

“标准库优先”的魅力何在？

Alex Edwards 在他的文章中旗帜鲜明地提出：“Use the standard library if you can”（如果可以，就用标准库）。这并非空穴来风，而是深深植根于 Go 语言的设计哲学和社区实践。为什么“标准库优先”如此有吸引力？

简洁性与零依赖：最直接的好处就是减少了项目的外部依赖。正如我们在之前讨论Rust 依赖管理时所看到的，过多的依赖会增加项目的复杂性、构建体积和潜在的安全风险。使用标准库，意味着你的 go.mod 文件更干净，项目更轻盈。
稳定性与兼容性：Go 语言以其著名的“Go 1 兼容性承诺”著称。标准库作为 Go 的核心组成部分，其 API 稳定性和向后兼容性得到了最高级别的保障。这意味着你可以更放心地升级 Go 版本，而不必担心标准库功能发生破坏性变更。
社区熟悉度与维护性：http.ServeMux 是每个 Gopher 都或多或少接触过的。团队成员对其有共同的认知基础，降低了学习成本和沟通成本。同时，标准库由 Go核心团队维护，其质量和响应速度通常更有保障，这对于应用的长期维护至关重要。
性能保障：虽然基准测试中某些第三方路由可能在特定场景下略胜一筹，但标准库的性能通常已经“足够好”，并且在持续优化。正如 Alex 所说，除非性能分析明确指出路由是瓶颈，否则不应过分追求极致性能而牺牲其他优势。
安全性：标准库经过了广泛的审查和实战检验，相对而言，其安全漏洞的风险更低。引入的第三方依赖越少，潜在的攻击面也就越小。

以 Go 1.22+ 的 http.ServeMux 为例，它引入了方法匹配、主机匹配、路径通配符等一系列强大的路由增强功能。这些增强使得标准库路由在很多常见场景下已经能够满足需求，进一步强化了“标准库优先”的底气。

何时坚守标准库 http.ServeMux？

在 Go 1.22 及更高版本中，http.ServeMux 的能力得到了显著提升。以下是一些典型的增强功能示例，它们展示了标准库路由的灵活性和强大性，也表明了在哪些场景下坚守标准库是理想的选择：

中小型 Web 应用或 API 服务：对于大多数标准的 CRUD 操作、简单的业务逻辑，增强后的 http.ServeMux 完全够用。
追求极致简洁和最小依赖的项目：如果项目的核心诉求是轻量、易维护，且对路由功能没有特别复杂的要求。
团队成员对 Go 标准库有良好掌握：可以充分利用团队的现有知识，快速开发和迭代。
内部工具或原型开发：快速搭建，无需引入额外学习成本。

让我们通过一个整合了多种新特性的示例来看看 Go 1.22+ http.ServeMux 的强大：

package main

import (
    "fmt"
    "net/http"
)

func main() {
    mux := http.NewServeMux()

    // 1. 方法匹配 (Method Matching)
    mux.HandleFunc("GET /api/users", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "获取用户列表 (GET)")
    })
    mux.HandleFunc("POST /api/users", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "创建新用户 (POST)")
    })

    // 2. 主机匹配 (Host Matching)
    mux.HandleFunc("api.example.com/data", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "来自 api.example.com 的数据服务")
    })
    mux.HandleFunc("www.example.com/data", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "来自 www.example.com 的数据展示")
    })

    // 3. 路径通配符 (Path Wildcards)
    // 单段通配符
    mux.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, r *http.Request) {
        id := r.PathValue("id")
        fmt.Fprintf(w, "用户信息 (GET), 用户ID: %s", id)
    })
    // 多段通配符
    mux.HandleFunc("/files/{filepath...}", func(w http.ResponseWriter, r *http.Request) {
        path := r.PathValue("filepath")
        fmt.Fprintf(w, "文件路径: %s", path)
    })

    // 4. 结束匹配符 (End Matcher) 与优先级
    // 精确匹配根路径
    mux.HandleFunc("/{$}", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "精确匹配根路径")
    })
    // 匹配 /admin 结尾
    mux.HandleFunc("/admin/{$}", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "精确匹配 /admin 路径")
    })
    // 匹配所有 /admin 开头的路径 (注意尾部斜杠，优先级低于精确匹配)
    mux.HandleFunc("/admin/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "匹配所有 /admin/ 开头的路径")
    })

    // 5. 优先级规则：更具体的模式优先
    mux.HandleFunc("/assets/images/thumbnails/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "缩略图资源")
    })
    mux.HandleFunc("/assets/images/", func(w http.ResponseWriter, r *http.Request) { // 更一般的模式
        fmt.Fprintf(w, "所有图片资源")
    })

    fmt.Println("Server is listening on :8080...")
    http.ListenAndServe(":8080", mux)
}

你可以使用 curl 来测试上述路由，这里也附上了测试结果：

# 方法匹配
$curl -X GET http://localhost:8080/api/users
获取用户列表 (GET)                                                                                                      

$curl -X POST http://localhost:8080/api/users
创建新用户 (POST)

$curl -X PUT http://localhost:8080/api/users
Method Not Allowed

# 主机匹配 (需要修改 /etc/hosts 或使用 -H 指定 Host)
# 假设已将 api.example.com 和 www.example.com 指向 127.0.0.1
# curl http://api.example.com:8080/data
# curl http://www.example.com:8080/data
# 或者使用 -H

$curl -H "Host: api.example.com" http://localhost:8080/data
来自 api.example.com 的数据服务

$curl -H "Host: www.example.com" http://localhost:8080/data
来自 www.example.com 的数据展示

# 路径通配符

$curl http://localhost:8080/users/123
用户信息 (GET), 用户ID: 123%

$curl http://localhost:8080/files/archive/2025/report.zip
文件路径: archive/2025/report.zip

# 结束匹配符与优先级

$curl http://localhost:8080/
精确匹配根路径

$curl http://localhost:8080/admin/
精确匹配 /admin 路径

$curl http://localhost:8080/admin/settings
匹配所有 /admin/ 开头的路径

# 优先级规则
$curl http://localhost:8080/assets/images/thumbnails/cat.jpg
缩略图资源

$curl http://localhost:8080/assets/images/dog.jpg
所有图片资源

这些示例清晰地展示了 http.ServeMux 在 Go 1.22+ 版本中的强大能力。Alex Edwards 也提到 http.ServeMux 的一个聪明之处在于其处理重叠路由的逻辑——“最精确匹配的路由胜出”（例如 /post/edit 会优先于 /post/{id}）。这种可预测性也让标准库路由在设计上显得更加稳健。

简单来说，如果标准库的功能已经能满足你 80% 的需求，且剩余 20% 可以通过简单的封装或组合模式解决，那么坚守标准库通常是明智的。

何时需要拓展，拥抱第三方路由？

当然，“标准库优先”并非一成不变的教条。当标准库的功能确实无法满足项目需求，或者引入第三方库能显著提升开发效率和代码表现力时，我们就需要考虑“拓展”。

Alex Edwards 的文章也清晰地列出了 http.ServeMux（即使是增强后）与某些第三方库相比仍存在的差距，这些差距往往就是我们选择拓展的理由：

更复杂的路径参数与匹配规则：
- 子段通配符 (Subsegment wildcards)：如 chi 支持的 /articles/{month}-{year}-{day}/{id}。标准库的 {NAME…} 是捕获剩余所有路径段，而非段内复杂模式。
- 正则表达式通配符：如 gorilla/mux, chi, flow 支持的 /movies/{[a-z-]+}。标准库的通配符不直接支持正则表达式。
高级中间件管理：
- 路由组 (Middleware groups)：如 chi 和 flow 提供的，可以为一组路由批量应用中间件，这对于组织大型应用非常有用。虽然 http.ServeMux 也可以通过封装实现类似效果（Alex 也写过相关文章），但第三方库通常提供了更便捷的内建支持。
更细致的 HTTP 行为控制：
- 自定义 404/405 响应：虽然 http.ServeMux 可以通过“捕获所有”路由实现自定义 404，但这可能会影响自动的 405 响应。httprouter, chi, gorilla/mux, flow 等库对此有更好的处理，并能正确设置 Allow 头部。
- 自动处理 OPTIONS 请求：httprouter 和 flow 可以自动为 OPTIONS 请求发送正确的响应。
特定匹配需求：
- 基于请求头 (Header matching) 或 自定义匹配规则 (Custom matching rules)：gorilla/mux 在这方面表现突出，允许根据请求头（如 Authorization, Content-Type）或 IP 地址等进行路由。
其他便利功能：
- 路由反转 (Route reversing)：gorilla/mux 支持类似 Django, Rails 中的路由命名和反向生成 URL。
- 子路由 (Subrouters)：chi 和 gorilla/mux 允许创建子路由，更好地组织复杂应用的路由结构。

选择拓展的时机，关键在于评估“收益与成本”。 如果引入第三方库能让你用更少的代码、更清晰的逻辑实现复杂功能，或者能显著改善开发体验，并且团队愿意承担学习和维护这个新依赖的成本，那么拓展就是合理的。

决策的智慧：在坚守与拓展之间

那么，如何做出明智的决策呢？

清晰定义需求：在动手之前，充分理解你的应用对路由的具体需求是什么。不要为了“可能需要”的功能而过早引入复杂性。
从标准库开始：正如 Alex 建议的，总是先尝试用 http.ServeMux。只有当它确实无法满足需求时，再去评估第三方库。
小步快跑，按需引入：如果标准库满足了大部分需求，只有一小部分特殊路由需要高级功能，可以考虑混合使用，或者仅为那部分功能寻找轻量级解决方案，而不是全盘替换。
评估第三方库的成熟度与社区支持：选择那些经过良好测试、积极维护、文档齐全且社区活跃的第三方库。Alex 文章中提到的筛选标准（如是否包含 go.mod 文件）可以作为参考。
考虑团队技能与偏好：团队成员对特定库的熟悉程度也是一个重要因素。