然后我做了两个测试：
第一个测试：我在下午3:45登录我的网络应用程序，闲置10分钟。下午3:55，我试图用我的应用程序，我被踢出了。我认为idleTimeout发挥作用。
第二个测试：我在下午4点登录我的网络应用程序，在下午4点05分，下午4点10分，下午4点15分，下午4点20点播放应用程序。我预计在下午4点20分被踢出。但我没有我认为IIS 7中的会话状态超时(20分钟)是Web Agent挑战用户重新认证之前，用户会话可以处于活动状态的最大时间。显然从这个测试，它不是。有人可以向我解释吗？另外，如何设置上述情况下的超时时间？
解决方法
如果在这段时间内没有请求您的应用程序，应用程序空闲超时将会启动。
因此，通常的情况是：
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之后返回该站点，那么他们将有一个全新的会话，您之前存储的任何值都将丢失。
确保会话持续通过应用程序重新启动的唯一方法是配置SessionState服务或sql会话状态，并确保您具有configured the machine.key，这样每次服务器重新启动时都不会自动生成。
如果您使用标准ASP.NET机制进行身份验证，则ASP.NET将向每个用户发出两个Cookie：
>认证令牌：由Authentication time-out设置控制，如果cookie尚未过期，则允许用户自动登录到您的站点，这可以修复或滑动，默认为30分钟，这意味着他们的认证令牌可以应对比他们的会话更长的“闲置”期间。
>会话令牌：由会话超时设置控制，允许您的应用程序在访问期间存储和访问每个用户的值。
这两个Cookie都使用MachineKey进行加密，因此如果您的应用程序回收并生成新密钥，那么这些令牌都不能被解密，要求用户登录并创建一个新的会话。
回应评论：
> 20分钟的会话超时与您使用Session.Add(string，object)方法放置在用户会话对象(HttpSessionState)中的项目相关。
>这取决于如果你正确地使用了configured the machine.key，认证令牌仍然是有效的，如果你的会话不再是“InProc”，这些也将通过应用程序重新启动而持续下去，并且仍然是可读的 – 参见上面的注释。
