ARTICLE · 1164607

苹果用了他做的软件 25 年,双方却几乎没联系过?

发布时间：2026-10-12 22:17:37 最近访问：2026-10-12 22:17:37

大家好，我是鸭鸭。

苹果把 curl 装进 Mac，已经 25 年了。

但 curl 作者 Daniel Stenberg 在 9 月 25 日的博客里说，苹果从来不是他们的客户，也没给项目提供过赞助。除了几次大多没成功的尝试，双方几乎没有交流。

光看这个使用年限，我还以为怎么也算老客户了。

curl 就是开发者调接口、下载文件时，经常敲的那个命令。2001 年，苹果把它放进 OS X 10.1，之后每一版 macOS 都带着它。后来，iOS 等系统也用上了 libcurl，让苹果自己的程序调用。

不过，Daniel 没有把这篇文章写成讨债信。他说，代码免费开源，苹果有权拿去用。他为 curl 参与了这么多年的互联网发展感到自豪，也把苹果长期使用它，当作一种认可。

我顺着翻了翻 curl 的历史。它最早要解决的事，比想象中小得多。

1996 年，Daniel 在写一个聊天室机器人，想让它帮大家查汇率。为此，他需要一个小工具，定时从网页上把汇率下载下来。

他找到了另一位开发者 Rafael Sagula 写的 HttpGet，补了几个地方，后来接手维护。工具慢慢添了功能，改过名字，到了 1998 年，正式叫作 curl。

一开始只是想让聊天室里查汇率方便点。

三年后，它被装进了苹果电脑。

但用的人多了，Daniel 并没有马上靠它养活自己。很长一段时间里，他有自己的工作，curl 是业余项目。他在 2019 年的总结里估算，自己已经在上面花了大约 15000 个没有报酬的业余小时。

按一天 8 小时算，是 1875 天。

这还只是他工作之外的时间。

到了 2019 年，他加入 wolfSSL，终于能全职做 curl。他们提供收费的技术支持，帮客户排查问题、开发需要的功能，软件本身继续开源。

2024 年，全职做 curl 满五年时，Daniel 又写了一篇纪念文章。他说，这就是自己梦想中的生活。

从 curl 第一次发布，到有了一份全职维护它的工作，他用了大约 21 年。

今天和大家分享一道计算机网络面试题。

HTTP 和 HTTPS 有什么区别？

回答重点

HTTP 就好比是在教室里传纸条，纸条上写什么，路过的每个人（路由器、运营商）都能看见，甚至还能偷偷改两笔，或者冒充别人给你传。

而 HTTPS 则是把纸条放进了上了锁的保险箱，只有手持钥匙的收件人才能打开，既看不见也改不了。

具体来说，它们的区别主要体现在这四个方面：

1）安全性（这是最本质的区别）

HTTP 是“裸奔”的。数据明文传输，这就带来了三大风险：

被窃听（账号密码泄露）
被篡改（网页被植入广告）
被冒充（钓鱼网站）。

而 HTTPS 是“穿了防弹衣”的。它在 HTTP 下层加入了一个 SSL/TLS 协议。通过加密解决了窃听，通过校验解决了篡改，通过数字证书解决了冒充。

2）性能

HTTP 简单粗暴，三次握手连上就能发数据，速度快。

相比而言 HTTPS 确实会慢一点。因为它在 TCP 握手之后，还得多进行一次 TLS 握手（通常是 4 次交互），而且加密解密计算也会消耗一点 CPU。

💡这里可以补一句加分项

不过现在有了 HTTP/2 的多路复用和 TLS 1.3 的优化（握手只需要 1 个来回甚至 0 个），这个性能差距在现代网络中几乎可以忽略不计了。

3）端口

HTTP 默认 80，HTTPS 默认 443

4）搜索引擎态度 (SEO)

现在谷歌、百度都优先收录 HTTPS 网站。如果你还是 HTTP，浏览器甚至会直接在地址栏标红提示“不安全”，这对用户体验伤害很大。

扩展知识

面试官如果问得深，可以接着聊握手。

HTTPS 使用 TLS 协议进行握手，所以我们主要关注的是 TLS 的握手过程。

而 TLS 的握手根据密钥交互算法的不同，可以分为两种

RSA 算法
ECDHE 算法。

这里推荐讲 ECDHE 算法，因为它是主流且具备前向安全性（即使私钥泄露，以前的消息也解不开）。

HTTPS ECDHE 算法握手流程

HTTPS 的握手过程，其实就是客户端和服务端在不安全的网络里，商量出一个谁也猜不到的“会话密钥”。

简单来说，分为四步（以 TLS 1.2 ECDHE 为例）：

1）打招呼 (Client Hello)：客户端说：“我支持这些加密算法，这是我的随机数 A。”

2）亮身份 (Server Hello)：服务端回应：“好，用这个算法。这是我的随机数 B，还有我的证书（身份证）。” 同时，服务端还会把计算密钥需要的参数（ECDHE 参数）发过去，并签个名防止被改。

3）对暗号 (Client Key Exchange)：客户端验证证书没问题后，也把自己的计算参数发过去。

关键点来了：这时候，双方都有了随机数 A + 随机数 B + 双方交换的参数。利用算法，双方就能算出同一个“会话密钥”。客户端喊话：“后面的消息我都要用这个密钥加密了哦！（Change Cipher Spec）”

4）握手结束 (Server Finished)：服务端也喊话：“好，我也加密了！（Change Cipher Spec）”

我们看下详细分析：

1）客户端问候（ClientHello）

客户端向服务器发送一个 ClientHello 消息，包含：

TLS 版本
加密算法套件（Cipher Suites）
随机数。

这步和 RSA 一致。

2）服务器问候（ServerHello）+ 密钥交换（Key Exchange）

服务器接收到 ClientHello 后，会认证 TLS 版本号是否支持，选择一个加密算法套件，确认客户端的随机数，再生成一个随机数。所以 ServerHello 的消息包含：

确认的 TLS 版本
确认的加密算法套件（Cipher Suite），这里会选 ECDHE 相关的套件
随机数。

同样，服务器也会向客户端发送自己的数字证书，内含公钥，用于证明其身份，这个步骤是服务器证书（Server Certificate）

ECDHE 实际上是基于椭圆曲线特性的算法，此时服务器需要确认选择的椭圆曲线以及一个随机数作为服务器椭圆曲线私钥，基于椭圆曲线和私钥算出椭圆曲线公钥。

为了防止公钥被修改，服务器通过 RSA 给公钥签名，最终利用（Server Key Exchange）发送给客户端。【椭圆曲线点这方面的知识仅做了解即可】

小结下 Server Key Exchange 消息的内容，包含：

椭圆曲线（如果客户端未指定）。
服务器的椭圆曲线公钥（用于 Diffie-Hellman 密钥交换）。
签名：服务器使用其私钥对相关参数进行签名（包括椭圆曲线参数和公钥），以确保这些参数没有被篡改。

最后，服务器会发送 服务器完成（ServerHelloDone），表示握手的初步阶段结束。

3）客户端密钥交换（Client Key Exchange） + 开始使用加密（Change Cipher Spec）+ 客户端完成（Client Finished）

同样，客户端通过 CA（证书认证机构）验证服务端传递过来的服务器证书可信后，生成一个随机数作为客户端椭圆曲线私钥，基于椭圆曲线和私钥算出椭圆曲线公钥。

将这个公钥通过客户端密钥交换（Client Key Exchange）发送给服务端。

此时客户端和服务端拥有【客户端随机数+服务端随机数+共享密钥（对方公钥+自己私钥计算得到）】，这三个元素生成最终的会话密钥。

紧接着再发送开始使用加密（Change Cipher Spec）给服务器端。这个步骤后，后续的传输数据都是加密的。

发送完（Change Cipher Spec）后，客户端再发送客户端完成（Client Finished），这个 Finished 会带上 Encrypted Handshake Message，这个 message 就是之前发送的所有数据的摘要，并且还用生成的对称加密密钥加密了，传递给服务器端验证，预防握手过程中的握手信息被修改。

4）服务器发送开始使用加密（Change Cipher Spec） + 服务器完成（Server Finished）

同理，服务器也是一样发送（Change Cipher Spec），代表后续要用加密数据传输了，且发送握手摘要给客户端验证，一切正常的话， ECDHE TLS 握手就结束了。

所以 ECDHE 和 RSA 主要差别在第二次握手，服务端需要发送（Server Key Exchange）。

HTTPS RSA 算法握手流程

RSA 握手的核心逻辑非常简单，就是客户端和服务端通过三次交换，凑齐了三个随机数，然后用这三个随机数生成了最终的会话密钥。

整个过程也是四次握手：

1）第一次握手：Client Hello（打招呼）

客户端说：“你好，我支持这些加密算法，这是我的随机数 A。”(此时：客户端有 A，服务端有 A)

2）第二次握手：Server Hello（亮身份）

服务端回应：“你好，我们用这个算法。这是我的随机数 B，还有我的证书（公钥在里面）。” 说完服务端就发了个 ServerHelloDone，表示“我说完了”。(此时：双方都有了 A 和 B)

3）第三次握手：Client Key Exchange（关键一步！）

客户端先验证证书，确认服务端是正规军。然后，客户端生成第三个随机数（叫 Pre-master Secret）。

重点来了：客户端用证书里的公钥把这个 Pre-master Secret 加密，发给服务端。因为只有服务端的私钥能解开，所以这个随机数绝对安全。

发完后，客户端喊话：“好了，三个随机数齐了，我生成会话密钥了，以后的消息我都加密发！（Change Cipher Spec）”(此时：双方都凑齐了 A、B、Pre-master，都算出了同样的会话密钥)

4）第四次握手：Server Finished（确认）

服务端用私钥解密拿到 Pre-master Secret，也算出了会话密钥。服务端喊话：“收到，我也加密了！（Change Cipher Spec）”双方验证一下刚才握手过程的摘要，没问题就开始加密通信。

内部还有一些细节交互，我们看下详细分析：

1）客户端问候（ClientHello）

客户端向服务器发送一个 ClientHello 消息，包含：

TLS 版本
加密算法套件（Cipher Suites）
随机数。

2）服务器问候（ServerHello）

服务器接收到 ClientHello 后，会认证 TLS 版本号是否支持，选择一个加密算法套件，保证客户端的随机数，再生成一个随机数。所以 ServerHello 的消息包含：

确认的 TLS 版本
确认的加密算法套件（Cipher Suite）
随机数。

除此之外，服务器还需向客户端发送自己的数字证书，内含公钥，用于证明其身份，这个步骤是服务器证书（Server Certificate）

最后，服务器会发送 服务器完成（ServerHelloDone），表示握手的初步阶段结束。

3）客户端密钥交换（Client Key Exchange） + 开始使用加密（Change Cipher Spec）+ 客户端完成（Client Finished）

客户端通过 CA（证书认证机构）验证服务端传递过来的服务器证书可信后，再次生成一个随机数（pre-master），通过证书得到的公钥，加密通过客户端密钥交换（Client Key Exchange）发送给服务端。

紧接着再发送开始使用加密（Change Cipher Spec）给服务器端。因为此时不论是客户端还是服务端都拿到了三个随机数（第一次客户端给的、第二次服务端给的、第三次客户端的 pre-master）。

因此这三个随机数就可以作为对称加密的密钥，用户后续传输的加解密。这个步骤后，后续的传输数据都是加密的。

4）服务器发送开始使用加密（Change Cipher Spec） + 服务器完成（Server Finished）

同理，服务器也是一样发送（Change Cipher Spec），代表后续要用加密数据传输了，且发送握手摘要给客户端验证，一切正常的话， RSA TLS 握手就结束了。

HTTPS RSA 和 ECDHE 区别

可以从三个角度来看：

安全性：ECDHE 提供前向安全性，而 RSA 不具备。如果服务器的私钥泄露，基于 ECDHE 的握手不会影响之前的会话，而基于 RSA 的握手会导致之前的通信被解密。
计算复杂度：ECDHE 由于涉及椭圆曲线数学运算，相比 RSA 的操作更复杂，但提供更高的安全性。
使用场景：现代 HTTPS 实践中，ECDHE 已成为首选，因为它能够提供前向安全性，同时结合 RSA 或 ECDSA 用于签名和认证。