http应该用于https登录后续页面吗？

Question

我在SO上看过很多线程，他们建议没有SSL就无法安全地传输密码。所以假设我已经https登录页面，但是

1. 用户通过https进行身份验证后，是否应该切换回http（假设登录后没有发送敏感信息）？因为它可能会加快页面加载速度吗？

2. 是否会在开发方面产生额外的开销（使用Zend Framework）？就像维护不同的目录结构一样。

Answer 1

1. 如果数据不敏感，您可以在对用户进行身份验证后切换回http以获得较小的速度优势。如果站点上出现任何类型的敏感数据（如用户配置文件等），则必须记住再次切换到https。实际上，整个会话始终加密可能更容易，因此您不必担心根据页面内容打开和关闭加密。

2. SSL对开发人员来说是透明的，您创建的应用程序与非安全服务器完全相同。您需要拥有可以自己购买或生成的SSL证书，并设置服务器来处理它。然后，根据协议（http或https），您的会话将自动加密或不会加密。因此，需要为需要加密的页面和其他页面的标准http：//链接设置正确的https：//链接。

Answer 2

与传输数据所花费的时间相比，SSL连接加密和解密（初始化后）的时间可以忽略不计。所以不，它甚至不会加快“加速”。

额外的文件夹取决于您的服务器，而不是您的框架。如果服务器通过/ httpsdocs文件夹或其他东西路由所有https请求，则可以在其中放入.htaccess，将其重定向到/ httpdocs文件夹。

Answer 3

VolkerK是对的，但是他的反应是谨慎的。会话可能会受到各种方法的影响。有很多方法（例如使用缓存的javascript客户端来生成针对每个页面生成的挑战的固定盐的哈希），但它们很混乱。到目前为止，最简单的解决方案是始终使用SSL。但是，您可以考虑将摘要式身份验证与会话cookie结合使用。

Tor Valamo错了。目前，带宽非常便宜，但是难以实现的是消除延迟 - 而延迟是HTTP传输速度的主要决定因素（大多数内容相对较小）。对于HTTP请求，服务器至少有两次往返 - TCP握手然后是请求/回复。它将根据文件大小和其他考虑因素而有所不同，但通常往返延迟占获取对象所用时间的50-70％。

使用Keep-alives消除了其中一次往返，因此大大提高了吞吐量。

使用SSL，至少需要一次往返（用于恢复现有SSL会话）和多次初始SSL协商。真正的杀手是微软非标准的SSL实现意味着你在与MSIE客户交谈时不能使用除MSIIS以外的其他任何东西（请参阅mod_ssl文档以获取更多信息）。

Answer 4

1. 是的，您可以在传输用户密码后切换回http。当没有敏感数据时，不需要对所有内容进行篡改。当您加密所有站点时：服务器需要加密所有数据，而您的服务器的性能最差，而不是加密。