无处不在的 HTTPS 的主要问题是它基本上使缓存 Web 代理无用（除非您信任该代理并让它为您模拟站点，但这不适用于证书装订，并且在某些司法管辖区可能是非法的）。对于某些用例，例如签名软件更新的分发，HTTP 非常有意义。例如，如果您在公司代理后面有一百个工作站，那么它们使用 HTTP 下载更新将意味着除了一个之外的所有工作站，它将从代理缓存中传递出去。这将比他们每个人都通过 HTTPS 进行的效率高得多......

简而言之，如果有另一个机制来验证内容的真实性和完整性，并且如果机密性无关紧要，那么 HTTP 作为传输层是有意义的……

对于实际人类的网页浏览，我发现在当今时代不使用 HTTPS 是非常困难的。

我不同意@valentinas 的回应。TLS 存在性能损失。是否与您相关取决于您的网站：

• 要建立连接，您首先要在客户端和服务器之间为 HTTP 和 HTTPS 进行 TCP 握手，这需要在客户端和服务器之间进行一次完整的往返。
• 对于 HTTPS，您还有 TLS 握手，在初始会话建立时需要两次往返（如果支持 TLS 错误启动，则只有一次），如果您可以恢复会话，则需要一次往返。
• 虽然 TLS 会话中使用的对称加密很便宜，但初始密钥交换却不是。如果你做得对，你想使用前向保密，这意味着 DHE 或 ECDHE。简单的 DHE 设置起来非常昂贵，ECDHE 便宜得多，但并非所有客户都支持它。有关基准，请参阅http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html。

这些东西结合起来使 TLS 连接的设置成本更高，因此短连接会带来明显的性能损失。更多的硬件不会有太大帮助，因为主要问题是对等点之间的额外交换，它们必须相互等待才能继续。

对于长连接，这种开销不再那么重要，所以如果你使用保持活动（大多数客户端和服务器都这样做）并且只有很少的连接，你可能会没事。但是，很少的连接意味着您不应该包含任何广告网络，因为它们经常在多个主机之间重定向，直到它们到达最终提供广告的主机。严重依赖广告的站点已经因此减慢了速度（TCP 的初始往返），但如果切换到 HTTPS，它们会更慢，因为建立到每个服务器的 TLS 会话还需要两次往返。广告链。

我还没有提到的一个原因是，尽管听起来很古老，但某些客户端可能不支持 TLS/SSL。当然，这是一个专门的案例，通常涉及嵌入式或遗留系统，但不幸的是，有些仍然存在。

想到的第一个例子是我们正在使用的定制微控制器，我们低估了我们需要的空间量，并且无法包含 SSL 库的大小。我们最终需要将其删除并通过标准 HTTP 进行通信，并且非常感谢服务器必须从提供的两种方法中提取数据。

几年前还遇到了阻止使用 TLS/SSL 的遗留系统。我的一个朋友的一个项目被聘用，因为它涉及在一所大学建立一个远程 Web 服务器和一个自动化客户端。客户端脚本在大学里一个过时的沙盒环境中运行——编译的每个部分都由一个自动化系统处理，并且可以访问的库集是一个硬编码列表。

这些是否足够常见，足以保证在正常情况下避免使用 TLS/SSL？我会说不，但有时它们可​​能很重要。如果您正在编写主要用于与嵌入式系统通信的软件，那么在仅提供 TLS/SSL 之前我会三思而后行。

关于这一点的另一个注意事项，因为我没有在你的问题中看到它，是每个人似乎都跳出来暗示当你询问 TLS/SSL 时，你的意思只是 HTTPS。由于您提到了 TCP 通信，您可能还在考虑将 TLS/SSL 用于除 HTTPS 之外运行的其他应用程序。

想到的是 SMTP 使用的 TLS/SSL。当谈到使用 TLS/SSL 进行 SMTP 通信时，我个人永远不会依赖它作为可维护的安全方法（注意，我的意思是 SMTP 通信，而不是使用 TLS/SSL 来提供邮件客户端和邮件之间的安全性）服务器）。我这么说的原因是 TLS/SSL 的固有性质。您正在查看适用于多跳通信机制的点对点安全套接字连接。

因此，即使您强制为您的 SMTP 连接使用 TLS/SSL，您也只能验证连接是否安全，从您的服务器跳出一跳。由于大多数邮件流都有多个跃点，例如：

邮件服务器 -> AV 解决方案 -> 互联网 -> AV 解决方案 -> 邮件服务器

并且在云中使用 3rd 方 AV 解决方案变得越来越突出，很难确保两个组织之间的每一跳都使用 TLS。

为了争论（正如我所做的那样），假设您花时间通过验证站点之间的每个跃点强制 TLS 来保护两个站点之间的 SMTP 流量。这对今天来说一切都很好，但是当基础设施在 5 年后发生变化时会发生什么？例如，如果不小心，当 AV 解决方案被更改/替换时，您可以轻松地留下一跳而不强制 TLS。

只是想把它作为头脑风暴的另一个 TLS 实现扔出去（顺便说一句，如果需要安全的电子邮件，我会走 S/Mime 路线在发送方实际加密消息并在接收方解密）。与任何工具一样，您必须为正确的工作使用正确的工具

“如果你唯一的工具是一把锤子，那么每个问题都会变成钉子”