我可以想象他是如何支持ASP.NET应用模型的，难道他也用ISAPI过滤器做一些事情吗？
是的，他也用它做一些事情。我们也支持一种叫做ASP模块扩展点的技术。他基本上允许你像一个函数那样使用ISAPI过滤器。我们提及的很多例子，如替换Session State等工作都是在那个级别实现的。此外，重定向URL的工作也是在这个级别实现的。例如，我们的许多客户经常要为他们的用户提供个性化的URL，像financial institution站点就可以为他的顾客提供www.financialinstitution.com/scott这样的URL为一个名叫SCOTT的用户，因为他们不想创建太明显的路径，所以要借用重定向技术提供各种各样的不可视的URL，你可以在ASP.NET上实现这样的功能。

带有"/scott" URL，实际上被ASP.NET转换成他要去的地方，是吗？
是的，因此在实际运行前，你会有一些代码解析"/scott" 部分，转换成一个实际地址的页面，实际执行的是一个很普通的页面。这种方式可以使得所有的用户都得到个性化。我们有一个模块中的一个API可以为你解决这个问题。在这个问题上，我们也有一个扩展点。在ASP的时候，我们有一个叫做Global.asa的概念，他可以定义应用开始，应用结束，Session 开始，Session结束等事件。在ASP.NET中我们允许您将ISAPI过滤器功能加入Global.asa中，因此，如果您想继续重定向URL时候，你甚至不需要写一个模块了，你只需要在Global.asa中定义就足够了。
我们做的另一点是，努力提高安全水平并且允许更为灵活的认证，在过去，您使用ASP的时候，您主要用IIS来构建您的认证功能，这种认证实际上依赖NT SAM，在ASP.NET中，我们将安全模块放入ISAPI过滤器中，因此如果您想在一个main frame 或者在你有一些usernames/passwords的数据库中，并且是你自己做这种认证时，你可以在Global.asa中写入相关的信息或者在一个与那个事件同步的组件中加入相关信息。
因此，我可孕匆桓鑫易约河没氖菘饬耍⑶遥勾斜曜嫉娜现す獭?BR>是的，没错。如果你这样做了，你可以获得更多的东西，你不仅可以拥有了用户名字和口令，而且还会有角色（role）这样的东西。你可以将那些用户映射成角色，你可以使用这种方式而不是仅仅使用ACL的方式构建你的站点。你可以知道Joe 和 Mark（用户名）访问了这个页面，相反，你也可以知道这个页面被哪个角色访问了。你在数据库的主要工作就是告诉我们 Mark 的用户名和密码是什么，他在哪一组角色中，其余的工作由安全系统来考虑，以保证它可以访问那些网页或者服务。当然，这里需要提及的是，所有的架构，安全架构、caching架构都为网页和XML服务提供支持。
如果从性能角度来看，增加的这些东西，这些能力，可以提供更好的性能服务吗？
我们的确提供了更好的性能服务，当我们创建ASP.NET项目组时，我们就指定一个开发人员专门负责性能上的工作，我们当时使用的是早期的common language runtime，他每日的工作就是检查每项操作是变快了还是变慢了，并且与运行时(runtime)项目组一起查找问题，加速变慢了的操作。同时，他也指出性能上的问题。这样做的结果是ASP.NET比ASP要更快。所有的代码都是编译过的，编译成本地代码，不再用解释的方式。
是吗，那么说我在ASP.NET中写的程序代码再也不用解释的方式？
正确。此外，更好的是，您仍然可以像您从前那样在编辑器里面编写代码，点击SAVE存盘，然后剩下的事情都交给系统去处理。但是，对于剩下工作ASP与ASP.NET确有不同处理方式。ASP采用的是分析代码然后传给脚本引擎，在程序运行时解释代码；而ASP.NET则是传给编译器，然后在common language runtime上运行。在common language runtime上执行的是本地代码，因此你可以用VB编制程序获得与C++一样级别的性能。
那么，它是在什么时候编译，是在我存储文件并且NT文件系统发现文件变化时，还是页面第一次使用的时候？
当某人请求页面的时候发生。我们将会检查，是否某个页面已经被编译，如果没有编译，我们将会编译他。我们在ASP.NET中作了许多很有趣的工作，使得编译过程更有效率。因为我们编译了他，所以如果你为了使机器更可靠或者性能更好而重起机器或者shut down你的WEB服务器或者shut down你的进程时，你不用再编译你的那个页面了，因为我们已经检测到了该文件已经被编译和加载，这样可以获得更高的响应速度和更强的伸缩性，并且那也是因为把它放在CACHE的某个地方了。

下面我们在谈论一下性能。好，我们谈论一下性能，是的，从整体上看，性能是更优化了。我们也在可扩展性，可靠性，可获取性方面作了很多的工作。我们曾经有一个假设，在一个common language runtime上，即使有一个Session想要和所有与他相关的东西通信的话，应用程序的可靠性仍然变得很高。
我们还可以举些例子。例如，真正强大的类型检查。在一个可管理的环境中，如果出现数组越界的情况，系统将会抛出一个exception而不会产生一个垃圾内存。除此之外，我们还有更多的可靠性机制保证您的使用。例如，我们可以检测内存冲突，也就是内存在某一点徘徊。我们可以检测到死锁，你甚至可以配置系统以便在发生这样的情况的时候，你的机器可以每隔多长时间重起一次。因此，在出现这样的情况的时候，我们可以规定一小时一次、一天一次或者每隔200个请求一次等来启动一个应用程序的新的实例。然后允许旧的应用程序完成相关的任务后，新的程序接着进行。
保持这样的一个可靠性机制使得你不必中断任何为用户工作的服务。我们将会动态地生成一个新的进程，开始接受新的请求，老的进程完成当前运行的所有请求，然后我们将删除老的进程。在这样的过程中，为了提高效率，系统实际上作了RESET的工作。但是这个过程中，你不会看见管理人员的干涉。你的客户也不会感觉到任何变化，他们会认为，嗷，每一件事情都运行的这样好，服务器还在运行。用这样的方式，你就可以获得非常高的可靠性。
此外，我们在Session State上也有了一些改进，Session State不再需要和你的代码运行在同一个进程中。他可以作为一种服务运行在一台机器上，也可以作为一种服务运行在整个WEB服务器群中的某一台机器上，其他的前端机器可以共享该服务。

Session State只能存放在一台机器上吗？
不，不是的，如果需要的话可以在多台机器上保留。Session State可以在多台机器上存储，也可以有多台机器的前端去访问那些存储信息。

我是一个用户，我正在访问一台机器，我的Session State留在这台机器上，如果我下一次要访问另一台机器，Session State中的数据可以共享吗？
是的，这种工作方式是WEB群组最典型的工作方式。一个用户你可以访问机器A，等一会儿，你又会访问机器B，你的Session State保留在另外一台独立的机器上。Session State既可以运行在我们的Session State provider上面也可以运行在SQL Server上面，我们有一种方式可以让SQL Server成为Session信息的服务器。但是，前端的这两台机器，也可以是多台机器，都可以访问同样的Session State。

这样看来，我们可以通过这种方式共享数据了。
是的，正确。但是你可以想象一旦你拥有这种Session State,与你的ASP代码不在一个进程中运行的Session State，无论你的ASP程序遇到下面什么样的问题，程序崩溃、我们终止了你的代码运行、我们检测到某种资源漏洞或者锁定、我们所配置的一些事情（例如一小时一次）遇到问题时，你所有的Session依然是安全的。因为，你将你的Session State保存在另外一台独立的机器上了。
如果你只有一台机器，你也可以利用Session State的这种特点，你可以让他运行的进程与你的代码运行的进程不同，因此，只要进程到来时，他们就可以访问在安全保护进程中的Session State。
正如我们刚才提到的，Session State最重要的几个好处是：（1）可靠性。你不用再担心你的应用程序崩溃或者一个用户数据丢失这样的事情发生。（2）第二个好处是，现在，你的应用程序不必再局限于一台机器。如果你使用了Session State ，你的确可以将你的应用扩展到更多台的机器上，这样，就真的没有什么条件能够限制你了，也就是说，你不必再担心你的应用程序能够在多大范围内或者能够为多少用户提供正常服务这样的问题。
听了上面的讲解，我们好像做了两种不同的事情，一个是ASP.NET提供了许多新的功能和性能，人们可以充分利用这些新的特点；另外一个方面是，在这些功能和性能的后面，ASP.NET做了许多额外的工作，使得这些特征和功能发挥了更大的作用。