ASP.NET: State Server Gems

ASP.NET state-server(aspnet_state.exe进程)是以windows service的方式启动的，以会话状态(session state)的进程外(out-of-process)的数据存储来服务的。对于这个组件，有一点很重要的地方需要注意： it is important to note that it doesn’t oppose any authentication barrier to requestors。换言之，任何可以访问网络的人都可以潜在的获得所有session的数据。如果要保护session state并只让web server machine访问它，可以使用防火墙和IPSec策略来完成，当然也可以通过更改默认的端口(默认是42424端口)。然而，在web.config里简单的更改这个端口值是不够的(1.x和2.0都一样)，还要修改注册表才可以
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters
把端口值写进port里(DWORD类型)
默认来说，state server只监听连接的本地回调接口(local loopback interface)，如果状态服务器在另一台机器而不是web server上的话，就必须明确的允许远程连接(remote connection)，注册表也是要改的，在上面的注册表的位置下要设置AllowRemoteConnection为一个非零的值。
2005年9月的MSDN Magazine中Fast, Scalable, and Secure Session State Management for Your Web Applications详细讲解了设计和部署高性能和安全会话的解决方案。

关于会话状态的一些需要注意的地方：
默认情况下，ASP.NET 应用程序将会话状态存储在辅助进程的内存中，特别是 Cache 对象的专用槽中。选中 InProc 模式时，会话状态将存储在 Cache 对象内的槽中。此槽被标记为专用槽，无法通过编程方式进行访问。换句话说，如果枚举 ASP.NET 数据缓存中的所有项目，将不会返回类似于给定会话状态的任何对象。Cache 对象提供两类槽：专用槽和公用槽。编程人员可以添加和处理公用槽，但专用槽只能由系统（特别是 system.web 部件中定义的类）专用。
到目前为止，InProc 可能是最快的访问选项。但请记住，会话中存储的数据越多，Web 服务器所消耗的内存就越多，这样会潜在地增加性能降低的风险。如果您计划使用任何进程外解决方案，应该认真考虑一下序列化和反序列化可能带来的影响。进程外解决方案使用 Windows NT 服务 (aspnet_state.exe) 或 SQL Server 表来存储会话值。因此，会话状态保留在 ASP.NET 辅助进程之外，并且需要使用额外的代码层，在会话状态和实际的存储介质之间进行序列化和反序列化操作。只要处理请求就会发生此操作，而且随后必须对其进行最高程度的优化。
因为需要将会话数据从外部储备库复制到本地会话词典中，所以请求导致性能下降了 15%（进程外）到 25% (SQL Server)。请注意，虽然这只是一种粗略的估计，但它应该接近于最低程度的影响，最高程度的影响将远高于此。实际上，这种估计并没有完全考虑到会话状态中实际保存的类型的复杂程度。
在进程外存储方案中，会话状态存活的时间较长，使应用程序的功能更强大，因为它可以防止 Microsoft® Internet 信息服务 (IIS) 和 ASP.NET 失败。通过将会话状态与应用程序相分离，您还可以更容易地将现有应用程序扩展到 Web Farm 和 Web Garden 体系结构中。另外，会话状态存储在外部进程中，从根本上消除了由于进程循环而导致的周期性数据丢失的风险。

附：