为什么不使用HTTPS的一切？
如果我正在build立一个服务器，并且拥有SSL证书，那么为什么我不会在整个站点上使用HTTPS，而只是为了购买/login？ 我认为只需要encryption整个网站，并完全保护用户就可以了。 这样可以防止诸如确定必须保证什么的问题，因为一切都是这样，对用户来说并不是真正的不便。
如果我已经使用HTTPS作为网站的一部分，为什么我不想在整个网站上使用它？
这是一个相关的问题： 为什么https只用于login？ ，但答案并不理想。 答案假定您无法将https应用于整个网站。
我可以想到几个原因。
- 有些浏览器可能不支持SSL。
- SSL可能会降低性能。 如果用户正在下载大型的公共文件，则每次encryption这些文件可能会有系统负担。
除了其他原因（特别是与性能有关的）之外，使用HTTPS时，每个IP地址只能托pipe一个域。
单个服务器可以支持HTTP中的多个域，因为服务器 HTTP头允许服务器知道要响应哪个域。
使用HTTPS，服务器必须在初始TLS握手期间（在HTTP启动之前）向客户端提供证书。 这意味着服务器头还没有被发送，所以服务器没有办法知道哪个域被请求以及哪个证书（www.foo.com或者www.bar.com）响应。
*脚注：从技术上讲，如果您将它们托pipe在不同的端口上，则可以托pipe多个域，但这通常不是一个选项。 如果您的SSL证书具有通配符，您也可以托pipe多个域。 例如，您可以使用证书* .example.com托pipefoo.example.com和bar.example.com
超越系统负载的最大原因是它打破了基于名称的虚拟主机。 使用SSL，它是一个站点 – 一个IP地址。 这是相当昂贵的，以及难以pipe理。
为什么不能通过挂号邮件将防伪信封发送给每一个邮件？ 来自邮局的人总是会有个人的监护权，所以你可以确信没有人会偷听你的邮件。 显然，答案是，虽然有些邮件是值得的，大多数邮件不是。 我不在乎有没有人读我“很高兴你从监狱里出来！” 明信片给乔叔叔。
encryption不是免费的，并不总是有帮助的。
如果一个会话（例如购物，银行等）将要使用HTTPS结束，没有理由不尽早地使整个会话HTTPS。
我的观点是，HTTPS只能在不可避免的必要时才使用，要么是因为请求或响应需要被中间监听所保护。 举个例子，看看Yahoo! 主页。 即使您已经login，您的大部分交互都将通过HTTP进行。 您通过HTTPS进行身份validation并获取certificate您身份的cookie，因此您不需要使用HTTPS来阅读新闻报道。
SSL / TLS几乎不被使用。 HTTPS必须用于整个会话 ，在任何时候都不能通过HTTP发送会话ID。 如果您仅使用httpslogin，那么您显然违反了2010年 “A3：破坏的身份validation和会话pipe理” OWASP前10名 。
对于高延迟链路，初始TLS握手需要额外的往返validation证书链（包括发送任何中间证书），同意密码套件并build立会话。 一旦会话build立，后续的请求可以利用会话caching来减less往返次数，但即使在这种最好的情况下，仍然比普通的HTTP连接需要更多的往返次数。 即使encryption操作是免费的，往返旅行也不是，并且可以通过较慢的networking链接来显示，特别是如果网站不利用httpstream水线。 对于networking连接良好的部分中的宽带用户，这不是一个问题。 如果你在国际上做生意，那么https很容易造成明显的延迟。
还有一些额外的考虑因素，如会话状态的服务器维护需要潜在的更多内存，当然还有数据encryption操作。 任何小型网站实际上都不需要担心服务器function与当今硬件的成本之间的关系。 任何大型网站都可以轻松支付CPU / W AES卸载或附加卡，以提供类似的function。
随着时间的推移以及硬件和networkingfunction的提高，所有这些问题变得越来越不成问题。 在大多数情况下，我怀疑今天有什么可察觉的区别。
可能存在运营方面的考虑，例如对httpsstream量的pipe理限制（考虑中间内容filter等），可能是一些公司或政府的规定。 一些企业环境需要在周边进行数据解密，以防止信息泄露…干扰热点和类似的基于Web的访问系统，无法在https事务中注入消息。 在我看来，在一天结束的时候，默认情况下不启用https的原因可能很小。
https比普通的http更耗资源。
它对服务器和客户端都提出了更高的要求。
如果整个会话被encryption，那么您将无法使用caching来获取代理级别上的图像和js等静态资源，例如ISP。
您应该在任何地方使用HTTPS，但是您将失去以下内容：
-
由于BREACH和CRIME攻击，您绝对不能使用SSL压缩或HTTP压缩。 因此，如果您的响应包含会话或csrf标识符，则无法压缩。 您可以通过将静态资源（图像，js，css）放在无cookie的域上，并在其中使用压缩来缓解这种情况。 您也可以使用HTML缩小。
-
一个SSL证书，一个IP地址，除非使用SNI，它不适用于所有的浏览器（旧的Android，黑莓6等）。
-
您不应在您的网页上托pipe不通过SSL的任何外部内容。
-
当浏览器转到HTTP页面时，您会丢失出站HTTP Referer标头，这对您而言可能并不是问题。
那么明显的原因就是性能：所有的数据在传输之前都要经过服务器的encryption，然后在收到的时候由客户端解密，如果没有敏感数据，这是浪费时间。 这也可能会影响您的网站caching了多less。
如果所有的地址都使用https://而不是熟悉的http://那么最终用户也可能会感到困惑。 另外，看到这个答案：
包含js文件时为什么不总是使用https？
https要求服务器encryption和解密客户端请求和响应。 如果服务器正在服务许多客户端，则性能影响将相加。 这就是为什么https的大多数实现仅限于密码authentication。 但随着计算能力的提高，这可能会改变，毕竟Gmail使用SSL的整个网站。
除了WhirlWind的回应之外，您应该考虑SSL证书的成本和适用性，访问问题（可能，尽pipe不太可能，客户端可能无法通过SSL端口进行通信）等。
使用SSL不是一个安全的保证。 这种types的保护需要被构build到应用程序的体系结构中，而不是试图依靠一些神奇的子弹。
有人告诉我，在我们公司的一个项目中，他们发现SSL消息占用的带宽明显多于普通消息。 我相信有人告诉我这是一个惊人的12倍的数据。 我自己也没有validation过，这听起来很高，但是如果每个页面都添加了某种标题，而且大多数页面都有less量的内容，那么这个标题可能并不是那么遥远。
这就是说，在http和https之间来回的麻烦，并跟踪哪些页面，这似乎是太多的努力给我。 我只有一次试图build立一个混合他们的网站，当我们被诸如JavaScript创build的popup窗口等错综复杂的东西绊倒在他们身上时，我们放弃了这个计划。 我们结束了只是使整个网站https减less麻烦。 我想在简单的情况下，你只需要一个login屏幕和付款屏幕需要保护，他们是简单的页面，混合和匹配不是一个大问题。
我不会担心客户解密的负担。 通常，客户将花费更多的时间等待数据通过networking来处理。 在用户通常具有千兆/秒的互联网连接之前，客户端处理能力可能是相当不相关的。 由服务器请求encryption页面的CPU功率是一个不同的问题。 有可能是它无法跟上数百或数千用户的问题。
另一个小点（也许有人可以validation），如果用户input数据到表单项（如文本框），然后由于某种原因刷新页面或服务器崩溃了一秒钟，用户input的数据丢失HTTPS，但使用HTTP保留。
注意：我不确定这是否是浏览器特定的，但肯定会发生在我的Firefox浏览器中。
带有IIS 8.0的Windows Server 2012现在提供了SNI，即服务器名称指示，它允许IIS中的多个SSL Web应用程序托pipe在一个IP地址上。
