1. RSA 和 Diffie-Hellman (DH) 只是实现相似目标的两种不同算法。对于大多数目的，没有压倒性的理由更喜欢一种算法而不是另一种算法（RSA vs Diffie-Hellman）。它们确实有一些不同的性能特征。RSA 是标准选择，也是一个不错的选择。

2. 很难就密钥大小给出一刀切的建议，因为这可能取决于您站点的安全需求，而且密钥大小会影响性能。我的默认建议是使用 1536 位 RSA 密钥。1024 位 RSA 密钥应该是绝对最低限度；但是，1024 位 RSA 密钥在短期内可能会被破解，因此通常不建议现代使用，所以如果可能的话，我会推荐 1536 位或 2048 位 RSA 密钥。

   请注意，截至 2010 年 12 月 31 日，许多 CA 最近开始弃用 1024 位最终实体证书：如果您询问，他们可能会出于遗留目的向您颁发 1024 位 RSA 密钥的证书，但他们正在鼓励人们过渡到 2048 位 RSA。一些 CA 需要 2048 位密钥，没有例外。就我个人而言，我认为 2048 位 RSA 对大多数用途来说太过分了，而 1536 位 RSA 可能还不错，但 2048 位 RSA 正在积累一些惯性。

3. 密钥越大，初始连接建立的速度就越慢。最可能的影响是对服务器负载的影响，因为服务器必须为连接到它的每个新设备执行一些公钥操作（在 24 小时左右的时间内）。公钥加密只会产生一次性费用，在创建连接时支付一次（大约 24 小时左右不会再为任何新连接支付）；通过连接传输的数据量无关紧要。

因此，我的默认建议是：选择 1536 位 RSA 密钥，然后在典型的低端客户端（例如 iPhone）上进行测试以确保性能正常，然后测试您的服务器是否可以处理每个客户端的连接数与该密钥大小相关的日期。如果您在服务器上遇到性能问题，请考虑使用加密加速器来加快服务器的性能。如果您仍然有严重的性能问题，您可以考虑降低到 1024 位 RSA。如果您有一个安全关键站点，例如银行站点，请使用 2048 位 RSA。

1. DH 和 RSA 是不同的公钥算法，但在公钥大小相同的情况下，安全性没有明显差异。DH证书相当少见，您无需担心它们。

2. 执行 RSA 操作所需的时间大约随着模数大小的立方而增加，即 2048 位密钥比 1024 位密钥慢大约 8 倍。这主要影响服务器在 SSL 中的性能，因为 RSA 公开操作（解密、签名）比私有操作（加密、验证）要快得多，并且在大多数密码套件中，客户端只需要使用服务器的公钥执行公共 RSA 加密。

3. 在您的第一种情况下，使用 SSL 会话恢复会极大地影响性能。如果客户端使用 SSL 重新连接到同一台服务器，它可以选择“恢复”先前的会话，这允许它跳过昂贵的 RSA 密钥交换。在第二种情况下，长时间传输完全不受服务器密钥大小的影响，因为 SSL 中的应用程序数据是使用对称密码加密的，而不是服务器的 RSA 密钥。对于第三种情况，见上文（2）。

这个页面有一些有趣的基准，显示了密钥大小对性能的影响：https ://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/

1. 我不相信 Diffie-Hellman (DH) 选择是legacy，这意味着过时和被取代，它只是不经常使用。在我看来，这是因为在提出证书请求时选择加密服务提供商时，它不是下拉列表中的第一个。但是，如果某人在做出选择时实际上是在做功课，那么他们仍然可能不会选择DH。根据 Microsoft 的说法，选择其中之一的原因是您会：

“当您必须通过不安全的网络交换密钥并且您之前没有与另一方通信时，请选择 Microsoft DH SChannel Cryptographic Provider。”

参考： https ://technet.microsoft.com/en-us/library/cc725579%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

对我来说，这也将导致大多数人只使用 RSA，因为通常您不会通过不安全的网络交换密钥 - 您正在使用您的 Intranet（如果自签名）或加密的电子邮件将您的密钥传递给您的证书颁发机构或与第 3 方提供商证书颁发站点通信时跨 SSL。当你不需要的时候，为什么要买更豪华/非标准的东西？

2. 3. 我个人的经验是当你有更长的比特长度时，你需要更多的处理时间/速度/功率来解密你的通信。这意味着服务器上的负载增加，内存缓冲区在处理时堵塞的可能性更大，CPU/RAM 的峰值等等。您必须在这与安全通信的需求之间取得平衡。通常，您希望获得硬件可以处理的最高位长度，这通常取决于您的组织所需的安全性 - 即通常银行、金融机构、政府机构等会为这种由于信息的敏感性，需要支持更高位长度（2048+）的硬件。但是，高于 2048 会在您的标准现成服务器硬件（即 那些按照操作系统构建器建议运行其服务器操作系统的最低操作规范构建的服务器。我的经验是双核处理器，4 GB RAM，即使只是启动位长> 2048的站点也会给您带来问题。

而且，当然，您还必须根据预期的用户群和并发连接来平衡您的位长和规格，其公式为：

Concurrent Connections = Number of Sessions Per Hour x Average Session Duration (in seconds) / 3,600

参考： http: //support.loadimpact.com/knowledgebase/articles/265461-calculating-the-number-of-concurrent-users-to-test

我不知道这个数字和你可能想要的 CPU GHz 之间的直接关系——或者如果这作为你想要遵守的标准比率存在，因为它可能会因 CPU 架构、缓存/缓冲区大小、FSB、制造商而异（AMD vs. Intel）等。但我认为很明显，数字越大，防止CPU陷入困境所需的RAM越多，并且需要更快的CPU速度来满足需求. 显然，提供服务的数据量会影响这个因素 - 提供服务所需的时间称为延迟，您拥有的延迟越少（内部网络越快）和传输的数据越多，它可能太快而且太多如果您的 CPU 不够强大，无法在需求下工作（读取、加密），则您的 CPU 将通过 SSL 进行处理。

对于问题 3 下的个人问题：

1. 一个拥有强大客户端频繁连接和断开会话的网站

这对服务器端的加密加速有影响，但就 SSL 而言，断开连接的成本实际上是微不足道的 - 这就像一个电灯开关被关闭。这更多地追溯到同时开始连接的连接数量。您将在连接打开期间监控您的 CPU 和 RAM 使用情况，如果它在您的 Process Monitor 中达到峰值，您知道您可能需要更短的位长度或更多的资源，或两者兼而有之。

2. 维持长时间高 IO 数据传输的 WCF 网站

这取决于 - 传输是一个带有大量数据的请求，还是带有小数据包的多次传输？前者在 CPU/RAM 上通常比后者更容易。您还更多地谈论带宽而不是加密处理，因为这很可能是您的瓶颈，而不是 SSL 加密/解密所占用的处理能力。

3. 面向客户的网站，适用于 iPhone 和台式机

如果我们谈论的是电话，我们谈论的是 4G 连接，只要我们谈论的是 2048 或更低，这可能会成为您的瓶颈，而不是其解密位的处理能力。如果程序员物有所值，那么面向手机的网站通常会涉及更少的图形/数据，因此加密和传输的内容应该更少。桌面站点是另一种动物，因为桌面通常会硬连线到网络，并且（通常）比电话具有更多的处理能力。对于服务器而言，处理/服务 SSL 加密位的仍然是 CPU/RAM 与位长度，如果您谈论的是移动设备站点与标准站点，情况会有所不同。一个移动设备站点应该（理论上）有更少的比特来加密，因此需要更少的处理能力，允许更高的位长。相反的情况适用于一个完整的、面向桌面的网站。