从架构的角度来看，什么是最佳方法Session []或加密Cookie？

Question

我们正在努力决定在Web应用程序中维护状态的最佳决策。我们倾向于在浏览器上使用加密的cookie，但是我们的一些开发人员认为我们应该在服务器上使用Session变量。

我认为Cookie是最佳方法的主要原因仅仅是因为我们不会在负载平衡方案中依赖应用服务器。

反对使用cookie的主要原因是处理cookie可能会很乱。

您对此主题有何看法？

编辑1：

确定。我从第一篇文章中看到，这两种方法都不是最好的。那么愿望的方法是什么？

Answer 1

这里有两个问题。首先是cookie和会话之间的区别。除非您使用的是无Cookie会话（例如URL中的唯一ID），否则会话只是一个非常短的过期cookie。您可以使用状态服务器（ScaleOut，Velocity，SQL Server）轻松配置应用程序以跨多个服务器共享会话

当然，假设您使用用户的cookie来存储唯一的ID，并将其链接回服务器上的所有真实数据，可能在数据库中。但是：

将敏感数据存储在用户的cookie中，即使加密，也不是 安全，因为它必须是可解密的，这意味着它容易受到攻击。无论何时选择在应用程序中使用双向加密，您都会承受更大的加密负担，以保持相同的安全级别。如果您没有可靠的加密专业知识，那么最好采取安全的方法而不是这样做。

所以简而言之，使用内置会话或滚动自己的会话，无论哪种方式，确保您发送给客户端的唯一信息是一个不可思议的ID，您可以绑定到存储在上的数据结束。

  

<强> Remembering a user with a cookie

     

分配...与该用户关联的临时ID，如GUID。由于GUID在天文学上是独特的，实际上是防碰撞的，因此它们几乎不可能从系统外部猜测或预测。

滚动您自己的基于cookie的会话/“记住我”功能的优势在于它可以让您更好地控制信息的持续，分发等等。另一方面，它确实代表了更多的工作，其中一些这是重新实现ASP.NET Session开箱即用的功能。通常情况下，我建议使用已经存在的内容，除非您能清楚地阐明一些驱动业务需求，以此作为一种选择。

Answer 2

从架构的角度来看，您应该考虑的是此应用程序的预期规模。最有可能的是，最聪明的事情就是从ASP.NET内置会话功能开始。稍后，如果您发现自己确实需要，请添加：

1. 低到中等可扩展性：使用粘性会话进行负载平衡，或者根据请求IP地址进行负载平衡（并且仍使用ASP.NET会话）。
2. 中到高可伸缩性：共享的RAM内会话存储，即共享的ASP.NET StateService，项目“Velocity”，ScaleOut SessionServer等。
3. 高可扩展性：自制的基于cookie的会话系统，在Web服务器之间完全“无状态”，因为它基于预先共享的秘密和散列，在不查询中央会话存储的情况下进行验证。如果你走这条路线，那么你应该考虑在cookie中存储非敏感用户设置，以便进行扩展。

完全基于cookie的会话的好处是它可以无限扩展。每当我们得到一个新用户时，我们还会得到一个新的远程PC，可以为我们存储他的会话状态，“免费”。当然，我们的Web前端服务器中的散列需要一些CPU，但前端层是无状态的并且易于扩展。缺点是它的开发工作更多。

询问BjørnHansen概述了cookie in these presentation slides, from around slide 16 and forward中的会话。 Theo Schlossnagle在his book Scalable Internet Architectures中写到了这些。 Here is a good scientific paper制作真正安全的cookie，比Ask和Theo的提议具有更好的安全性，如果内存为我服务的话。

请注意，您可能不需要像您想象的那样具有可扩展性。例如，Stack Overflow仅由2个前端服务器提供服务，负载均衡器按用户IP地址划分流量。这使得每个前端Web服务器上的本地ASP.NET会话正常工作，只要所有Web服务器都可以运行 - 对于大多数具有2-5个Web服务器的站点来说，这是一个可接受且非常简单的解决方案。

有一个考虑因素可能会推翻上述内容。如果您发现其他数据需要共享缓存（SQL查询结果，可重复使用的结果但是非常昂贵的CPU计算），并且你已经要实现这样的缓存，那么只有将会话粘贴到这个缓存中才有意义。我所讨论的共享缓存类型的示例包括Memcached，Microsoft project "Velocity"，Shared Cache，ScaleOut StateServer等。很多网站都不需要这个，但这是一个非常好的解决方案。这个解决方案在价格和价格方面可能更容易获得。一旦项目“Velocity”发布，开发时间取决于微软对“Velocity”的意图。

<强>结论

1. 您是否只需要在前端Web服务器上共享会话，或者您是否还需要其他数据（SQL结果缓存等）？您是否一般需要共享的RAM缓存？如果是这样，您将不得不考虑共享缓存/群集中间件。
2. 如果没有，你知道你将以什么规模经营？如果你这样做，那么应该能够决定会话数据的4个选项中的哪一个（从ASP.NET内置会话到cookie）最适合你。
3. 如果您刚刚开始并且不知道您将吸引多少用户，那么我将从ASP.NET内置会话功能开始，并且仅在需要时添加更复杂的解决方案。< / LI>

Answer 3

我不明白为什么Cookie在这里得到如此糟糕的说唱。我已经看到在一些非常大的系统中使用的Cookie方法，我从来没有看到它被黑客攻击。

Answer 4

传统方法是由SqlSessionStateProvider支持的Session。

现代方法似乎是使用数据库进行存储，并在数据库前使用缓存（memcached）来加速查找。但是会话已经结束，加密的cookie也是如此（除了auth cookie）。

Answer 5

是的，我怀疑你对cookies的处理可能会很混乱。

我建议使用可以在任何计算机上运行的ASP.NET StateService来处理会话。

如果你走的是曲目路线，你需要非常小心你的工作方式，除非你是专家，否则你几乎肯定会做错事。

Answer 6

如果用户在浏览器信息上清除cookie肯定会丢失。会话

不是这种情况