FaceTime 音频不仅使用简单、可靠，而且音质令人难以置信。

那么苹果是如何做到这一点的呢？我们需要通过不同级别的网络抽象在两个设备之间建立连接，包括 ISP 级别和家庭级别。这种连接需要足够安全、足够可靠以维持对话，并且在考虑到现代蜂窝数据限制和家庭互联网数据上限的情况下，还需要足够低的带宽才能可行。所有这些都需要在 CPU 非常出色但电池容量有限的设备上运行。

我们对 FaceTime 了解多少？

我们关于 FaceTime 工作原理的许多最佳信息来自于该功能发布时的相关方，所以大约在 2010 年的时间范围内。在此期间，感兴趣的各方做了很多很好的数据包捕获工作，我们对协议的运作方式有了一定的了解。对于那些在其职业生涯中从事 VoIP 技术工作的人来说，它看起来与您之前可能看到的非常相似。以下是 2010 年左右 FaceTime 通话的步骤：

• 通过端口 5223 与 Apple 服务器建立 TCP 连接。我们知道 5223 被很多东西使用，但对于 Apple 来说，它用于他们的推送通知服务。有趣的是，它也用于 XMPP 连接，稍后会出现。
• iOS 设备和 Apple 服务器之间在端口 16385 和 16386 上的 UDP 流量。使用过防火墙的人可能熟悉这些端口。这些是与音频和视频 RTP 相关的端口，这是有道理的。RTP 或实时传输协议旨在以低延迟促进互联网上的视频和音频通信。
• RTP 依赖于其他东西来建立会话，而 Apple似乎依赖于 XMPP。此 XMPP 连接依赖于 Apple 颁发的设备上的客户端证书。这就是非 iOS 设备无法使用 FaceTime 的原因，即使他们可以对没有证书的连接进行逆向工程。
• Apple 使用 ICE、STUN 和 TURN 来协商这两种设备直接相互通信的方式。这些是用于协商 NAT 之间的对等连接的常用工具，以便没有公共 IP 地址的设备仍然可以相互通信。
• 通过在 Apple 服务器上注册电话号码或电子邮件地址来识别设备本身。这与 STUN 信息一起，是 Apple 知道如何连接两个设备的方式。STUN 或用于 NAT 的会话遍历实用程序是指设备访问公共可用服务器并且服务器确定如何访问该客户端。
• 在所有这些协商和网络穿越结束时，发送一个 SIP INVITE 消息。这具有人名以及带宽要求和呼叫参数。
• 一旦建立呼叫，就会有一系列 SIP MESSAGE 数据包可能用于对设备进行身份验证。然后建立实际连接，FaceTimes 协议使用前面讨论的 UDP 端口接管。
• 最后，呼叫结束时使用 SIP 协议终止。这里假设是 FaceTime 音频与视频的区别很小，主要区别在于用于音频的编解码器 AAC-ELD。Apple 使用这种编解码器并没有什么神奇之处，但它被广泛认为是一个很好的选择。

这就是这个过程的运作方式。但我们知道，在后来的几年里，Apple 改变了 FaceTime，增加了更多的功能和容量。根据他们的端口要求，这些是现在需要的。

视频和音频质量

视频 FaceTime 通话包含通话中的 4 个媒体流。音频是如上所述的 AAC-ELD，在每个方向上观察到 68 kbps（或大约 136 kbps 发送或接收）消耗。视频是 H.264，质量有很大差异，这大概取决于通过 SIP 传递的带宽计算。我们知道 SIP 允许有关总消耗带宽的 H.264 信息，尽管我仍然不知道 FaceTime 如何实时计算终端可用容量的细节。

您可以通过从蜂窝网络切换到 wifi 进行视频通话来观察这种行为，在切换过程中通常可以看到视频压缩（但有趣的是，通话并未中断，这证明了 iOS 内部网络接口的有效切换）。然而，对于音频呼叫，这种行为不会被复制，呼叫要么大致保持，要么完全掉线，这表明灵活性较低

那么FaceTime 还能这样工作吗？

并不完全确定 XMPP 组件是否仍然存在。然而，经过更多阅读后，相信这仍然是它的工作方式，并且确实是 Apple 的 iOS 基础架构的许多工作方式。虽然 Apple 没有很多关于 FaceTime 内部结构的可用文档。

FaceTime 是 Apple 的视频和音频通话服务。与 iMessage 一样，FaceTime 通话使用 Apple 推送通知服务 (APN) 与用户注册的设备建立初始连接。FaceTime 通话的音频/视频内容受端到端加密保护，因此除了发送方和接收方之外没有人可以访问它们。Apple 无法解密数据。

所以我们知道端口 5223 (TCP) 被 Apple 的推送通知服务和 XMPP over SSL 使用。我们从较早的数据包转储中了解到，Apple 过去曾使用 5223 建立与他们自己的 Jabber 服务器的连接，作为整个过程的初始起点。我的怀疑是 Apple 的推送通知的工作方式类似于正常的 XMPP pubsub 设置。

• 苹果在这里的文档中也说了同样多的话。

这很有趣，因为它表明许多 Apple 后端的底层技术是 XMPP，令人惊讶的是，对于我们大多数人来说，XMPP 被认为是一种较旧的、较少使用的技术。正如稍后所讨论的，我不确定这是 XMPP 还是只是使用相同的端口。好的，所以消息被交换了，但是密钥共享呢？这些通信是加密的，但没有上传或共享公钥（似乎也无法访问上述密钥）。

我以为我们在谈论电话

Apple 的一大卖点是安全性，而 iMessage 以加密文本消息交换而闻名。传统的 SMS 没有加密，很多（大多数）基于文本的通信也没有加密，包括电子邮件。加密在计算上是昂贵的，并且在 Apple 真正将其作为文本通信对话的很大一部分之前并没有被视为高优先级。但是为什么加密没有成为消费者计算机生态系统的主流呢？

简而言之：因为管理密钥很糟糕。如果我想向您发送加密消息，我需要先知道您的公钥。然后我可以加密消息的正文，你可以解密它。传统上，这个过程是超级手动的，坦率地说，非常糟糕。

因此，Apple 必须有某种方式来生成密钥（大概是在设备上）然后共享公钥。事实上，他们有一项名为 IDS 或 Apple Identity Service 的服务。这是将你的电话号码或电子邮件地址链接到该设备的公钥的工具。

Apple 有一个很好的小图来解释流程：

FaceTime 通话的过程与 iMessage 通话的过程大致相同，但音频/视频通道有一些细微差别。证书用于建立共享机密，实际媒体通过 SRTP 流式传输。

不完全相同，但仍能说明问题

Apple 的某个人阅读了 SSL 书

SIP 本身有一个如何处理加密的机制，但是 FaceTime 和 iMessage 在一直可以用到之前 iPhone 4 的设备上工作。但为什么我们没有看到大量适用于 Android 的 iMessage 克隆。如果有数十亿台 Apple 设备四处飘荡，而且其中大部分都依赖于本地客户端协商，难道没有办法伪造吗？

好吧，这就是它变得有点奇怪的地方。因此，有一种定义的发送客户端证书的方式，如 RFC 5246 中所述。Apple似乎曾经这样做过，但他们已经改变了他们的流程。现在它通过应用程序发送，连同一个公共令牌、一个随机数和一个签名。我们将暂时关注令牌和证书。

令牌

• 256 位二进制字符串

NSLog(@"%@", deviceToken);
// Prints "<965b251c 6cb1926d e3cb366f dfb16ddd e6b9086a 8a3cac9e 5f857679 376eab7C>"

示例

• “记录”在这里 – Apple Developer Docs
• https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622958-application
• 服务器端生成

证书

• 在设备 APN 激活时生成
• 证书请求发送到 albert.apple.com
• 使用两个 TLS 扩展，APLN 和服务器名称

那么为什么我没有一堆很棒的 Android 应用程序能够发送这些东西呢？

主要问题有两个方面。首先，建立连接的协议不是标准的。苹果使用APLN处理协商，客户端使用协议 apns-pack-v1 来处理这个。因此，如果您想编写自己的应用程序来与 Apple 的服务器交互，您首先需要获得 x509 客户端证书（这似乎是在激活时生成的）。然后您需要能够使用 APLN 传递服务器名称建立与服务器的连接，不知道 Android 是否支持。您也不能只生成一次，因为 Apple 只允许每个设备进行一次连接。因此，如果您使用取自真实 Mac 或 iOS 设备的值制作应用程序，我认为它只会导致实际的 Apple 设备掉线。如果您的 Mac 已连接，那么假设备就会掉落。

但是 Hackintoshes 是如何工作的呢？对于那些不知道的人，这些是运行 MacOS 的普通 x86 计算机。据推测，他们将拥有建立这些连接所需的扩展，并且还能够生成所需的证书。这就是它变得有点奇怪的地方。Mac 序列号似乎是此过程如何运作的关键部分，大概是通过 Apple 方面的一些检查来确定“是否应该允许此设备发起连接”。

这样做的方法是生成此处概述的假 Mac 序列号。这个过程似乎相当令人担忧，取决于几个因素。首先，Apple ID 似乎需要通过其他设备激活，显然 ID 的年龄很重要。这可能是某种权重系统，以防止流程被虚假请求淹没。然而，似乎在 Apple 完成注册过程之前，它会查看设备的 plist 并尝试确定“这是一台真正的 Apple 设备”。

Apple 设备序列号虽然不是随机值，但它们实际上是一种非常有趣的数据格式，其中包含大量信息。据推测，这样做是为了使服务更容易，让 AppleCare 网站和 Apple Stores 能够快速确定型号和年龄，而无需检查某些“主 Apple 序列号服务器”。您可以在此处查看旧的 Apple 序列号格式：链接。

怀疑这种强力强制新序列号的能力是 Apple 决定更改序列号格式的原因。通过从可以生成的值切换到长度不同的完全随机值， Apple 将能够以更高的确定性说“是的，这是带有 x 序列号的 MacBook Pro”在内部数据库上查找。这几乎不可能为这几代设备生成假序列号，因为您需要非常幸运地获得型号、MAC 地址信息、逻辑板 ID 和序列号。

这一切有多安全？

它与 Apple 一样安全，无论其好坏。Apple 完全控制注册、令牌生成、证书验证和交换以及 TLS 握手过程。用户无法提供自己的加密密钥并不奇怪（这是 Apple，为用户上传公钥对他们来说似乎不是品牌），但令人惊讶的是没有任何方法可以显示用户密钥。这似乎是针对中间人攻击的合乎逻辑的保护措施。

因此，如果 Apple 想要注册另一个电子邮件地址并将其与 Apple ID 相关联，并允许它接收 FaceTime 的 APN 通知/接听电话，那么我看不到任何可以阻止他们这样做的东西。我并不是建议他们这样做或会这样做，只是因为它在技术上似乎可行（因为我们已经知道多个设备同时接收 FaceTime 呼叫，并且通知的新目标的注册更多地取决于该部分的特定 URI Apple ID 的电话号码或电子邮件地址）。

那么这是否都是 XMPP？

不完全确定。端口是一样的，在消息订阅方面也有一些相似之处，但是处理实际消息传输的大量修改说明，如果这是幕后的XMPP，它已经被大量修改。我怀疑最初的设计可能更接近历史设计，但多年来，Apple 已经对秘密武器的运作方式进行了重大改变。

它看起来仍然很像期望的功能，带有一个庞大的分布式消息队列。您连接到随机 APN 服务器，rand(0,255)-courier.push.apple.com启动 TLS 握手，然后将消息推送到您的设备，由您的令牌标识。据推测，在 Apple 的数十亿条消息始终流动的规模下，后端的过程更加复杂，但很多概念是相似的。

结论

FaceTime 是一项很棒的服务，它似乎依赖于 Apple 生态系统中一个非常容易理解和经过实战考验的部分，即他们的推送通知服务以及他们的 Apple ID 注册服务。这个过程也被非 Apple 应用程序用来接收通知，它允许单个设备快速协商客户端证书，启动安全连接，使用正常的网络协议允许 Apple 帮助它们绕过 NAT，然后在它们之间建立连接。使用标准 SIP 协议的设备。质量是 Apple 授权好的编解码器并使设备能够利用这些编解码器的结果。

FaceTime 和 iMessage 与其他 Apple ID 服务链接在一起，允许用户将电话号码或电子邮件地址注册为唯一的目的地。

更多互联网精彩资讯、工作效率提升关注【飞鱼在浪屿】（日更新）