asp.net - IIS 7 中的 session 超时如何工作？

Question

在 web.config 中，我将 sessionState 中的超时设置为 20 分钟。根据 MSDN，此超时指定 session 在放弃之前可以空闲的分钟数。在 IIS 7 中，DefaultWebSite->Session State->Cookie Settings->Time Out 自动填充 web.config 中设置的超时值，在我的情况下为 20 分钟。另外，Application Pools->DefaultAppPool->Advanced Settings->idleTimeout，我设置为10分钟。

然后我做了两个测试:
第一个测试:我在下午 3:45 登录我的 Web 应用程序，空闲 10 分钟。下午 3 点 55 分，我尝试使用我的应用程序，但被踢出局。我认为 idleTimeout 起作用了。

第二个测试:我在下午 4:00 登录我的网络应用程序，在下午 4:05、4:10、4:15 和 4:20 使用该应用程序。我预计会在下午 4 点 20 分被踢出去。但我不是。我认为 IIS 7 中的 session 状态超时(20 分钟)是 Web 代理挑战用户重新进行身份验证之前用户 session 可以处于事件状态的最长时间。显然，从这个测试来看，事实并非如此。谁能给我解释一下？另外，如何为上述情况设置超时？

Answer 1

session 超时是一个滑动超时，用户每次访问服务器时都会将其重置为配置的值。

如果在该时间段内没有对您的应用程序的请求，则应用程序空闲超时开始。

因此，通常的情况是:

Time  | User A       | User B       | Session States
------+--------------+--------------+-------------------------------------------
12:00 | Visits Page1 |              | A: New Session, Time-out: 20 minutes
12:02 | Visits Page2 |              | A: Time-out reset: 20 minutes
12:10 |              | Visits Page1 | A: Time-out: 12 min; B: New: 20 minutes
12:15 |              | Visits Page2 | A: Time-out: 07 min; B: Time-out: 20 min
12:22 |              |              | A: times out; B: 13 min remaining
12:32 |              |              | Application Shuts Down (Idle time reached)
12:35 | Visits Page3 |              | A: New Session Starts

如果用户 A 在 12:22 之后返回站点，他们将拥有一个全新的 session ，并且您之前存储在那里的任何值都将丢失。

确保 session 在应用程序重新启动后持续存在的唯一方法是配置 SessionState 服务或 SQL session 状态，并确保您已 configured the machine.key所以这不是每次服务器重新启动时自动生成。

如果您使用标准 ASP.NET 机制进行身份验证，则 ASP.NET 将向每个用户发出两个 cookie:

身份验证 token :由 Authentication time-out 控制设置，允许用户在 cookie 未过期的情况下自动登录到您的站点，这可以是固定的或滑动的，默认为 30 分钟，这意味着他们的身份验证 token 可以处理比他们更长的“空闲”期 session 。

session token :由 session 超时设置控制，允许您的应用程序在访问生命周期内存储和访问每个用户的值。

这两个 cookie 都使用 MachineKey 进行加密 - 因此，如果您的应用程序回收并生成新 key ，则这两个 token 都无法解密，需要用户登录并创建新 session 。

回复评论:

20 分钟 session 超时与您使用 Session.Add(string, object) 放置在用户 session 对象 ( HttpSessionState ) 中的项目有关。方法。

那要看。如果您正确configured the machine.key , 身份验证 token 仍然有效，如果您的 session 不再是“InProc”，这些 session 也将在应用程序重新启动后持续存在，并且仍然可读 - 请参阅上面的注释。