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

Question

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

我认为Cookie是最好的方法的主要原因是，在负载平衡场景中，我们将不依赖于应用服务器。

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

你对这个话题有什么看法？

编辑1：

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

Answer 1

这里有两个问题。首先是cookie和会话之间的区别。除非您正在使用无cookie会话(如URL中的唯一is )，否则session只是一个过期时间非常短的cookie。通过使用状态服务器(ScaleOut、Velocity、SQL Server)，您可以轻松地将应用程序配置为跨多个服务器共享会话

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

在用户的cookie中存储敏感数据，即使是加密的，也不是那么安全，因为它必须是可解密的，这意味着它很容易受到攻击。每当您选择在应用程序中使用双向加密时，您都会承担更重的加密负担，以保持相同级别的安全性。如果您没有相当多的加密专业知识可供使用，那么最好的办法可能是选择安全的路线，而不是这样做。

因此，简而言之，使用内置会话或使用自己的会话，无论哪种方式，都要确保您发送给客户端的唯一信息是无法猜测的ID，并将其与存储在您端的数据绑定在一起。

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

滚动您自己的基于cookie的会话/“记住我”功能的好处是，它让您能够更好地控制信息的持久化、分发等时间长度。另一方面，它确实代表了更多的工作，其中一些工作是通过ASP.NET会话重新实现开箱即用的功能。通常，我建议使用已经存在的内容，除非您能够清楚地表达一些驱动业务需求，从而将其作为一种选择来消除。

Answer 2

从体系结构的角度来看，您应该考虑的是此应用程序的预期规模。最明智的做法是从ASP.NET的内置会话功能开始。稍后，如果您发现确实需要它，则添加以下任一项：

cookie Session).

• Medium低到中可伸缩性:使用粘性会话进行负载平衡，或基于请求IP地址进行负载平衡(仍然使用

1. 来实现高可伸缩性:共享的内存中会话存储，即shared ASP.NET StateService，项目"Velocity"，ScaleOut SessionServer等。
2. 高可伸缩性:基于cookie的自制会话系统在web服务器之间完全“无状态”，因为它基于预先共享的秘密和散列，无需查询中央会话存储即可进行验证。如果您选择此路线，则应考虑将非敏感用户设置也存储在cookie中，以扩展此设置。

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

Ask Bjørn Hansen概述了cookies in these presentation slides, from around slide 16 and forward中的会话。Theo Schlossnagle在his book Scalable Internet Architectures上写了关于它们的文章。Here is a good scientific paper关于制作真正安全的cookies，如果我没记错的话，安全性比Ask和Theo的建议更好。

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

如果你发现other data (SQL查询结果，可重用但非常耗费CPU的计算的结果)需要一个共享缓存，并且你已经打算实现这样一个缓存，那么把会话也放到这个缓存中才是有意义的。我所说的这种共享缓存的例子有Memcached、微软project "Velocity"、Shared Cache、ScaleOut StateServer和其他公司。许多网站不需要这样做，但这是一个非常好的解决方案。一旦"Velocity“项目发布，这个解决方案在价格和开发时间方面可能会变得更容易获得，这取决于微软对"Velocity”的意图。

结论

1. 您是否只需要在前端web服务器之间共享会话，或者您是否也需要将其用于其他数据(SQL结果缓存等)？一般情况下，您是否需要共享的in-RAM缓存？如果是这样的话，你就必须研究一下共享缓存/集群中间件。
2. 如果不是这样，你知道你的操作规模是多少吗？
3. 如果您刚刚起步，不知道会吸引多少用户，那么我将从ASP.NET内置会话功能开始，以后再根据需要添加更复杂的解决方案。

Answer 3

我不明白为什么Cookie在这里的口碑这么差。我见过在一些非常大的系统中使用Cookie方法，但我从未见过它被黑客攻击过。