性能本身就是使用 MAC 的一个原因。

考虑一个 TLS 连接。对于每个数据包，接收方需要验证数据包在传输过程中没有被中间人攻击者修改。因此，对于每个数据包，发送方需要计算 MAC/签名，而接收方需要对其进行验证。例如，如果您想要 10MB/s 的传输速率和平均 10kB/数据包，这意味着您只有 1ms 的时间来计算或验证签名。这对于数字签名来说太慢了。

假设您拥有 PC、服务器或智能手机等高端硬件（它可能是嵌入式设备上的问题）。但是，如果您需要每个数据包执行一次，则它不起作用。

数字签名的优点是它可以由无法生成假签名的一方进行验证。这在 TLS 连接之类的情况下没有用。对于 TLS，双方设置一个会话密钥，这是一个在连接开始时随机生成的对称密钥。之后，唯一知道密钥的两方是客户端和服务器。如果客户端看到一个有效的 MAC（不是它自己生成的），它只能由服务器生成，反之亦然。类似地，一旦生成了会话密钥，它（而不是非对称加密）用于加密。

（正确地说，相同的密钥不应该用于不同的目的，例如 MAC 和加密，即使它恰好具有正确的格式。我在上面简化了一些事情。“会话密钥”实际上是一些秘密材料一个加密密钥和一个 MAC 密钥被派生——或者，在某些密码套件中，一个经过身份验证的加密密钥被派生，尽管 AE 算法然后在内部派生两个密钥。）

HMAC 和签名都可以用来验证数据的完整性和消息的认证。但是签名也提供了不可否认性：给定一条消息及其签名，您可以证明该消息确实是由发送者编写的。

你可能不想要这个属性。例如，您可能想与您不信任的人私下交换消息。如果您的消息已签名，另一方将能够披露有危害的消息并证明是您编写的。使用 HMAC，您仍然可以确保对话的私密性，但对方将无法证明您写了这个有危害的消息，因为他们也可能写了它。

我想我可能已经想到了一个可能的答案。

通过签名，接收者（客户端应用程序）可以确定消息来自发送者（服务器应用程序）。但是，如果客户端应用程序现在将某些内容发送回服务器（另一个 HTTP 请求发布一些数据），则服务器无法确定消息是否真的来自同一个客户端应用程序 - 任何可能的客户端都可以使用服务器的公钥来创建这样的消息.

另一方面，如果他们共享一个秘密（如在 HMAC 中），则至少可以确定消息来自预期的客户端应用程序。

这样做的问题似乎是，对于不可信的客户端（javascript 或移动应用程序）来说，创建 MAC 的秘密盐并不真正有价值，因为它们总是会被破坏。