owin出现之前，为什么ASP.NET只能在IIS上发布？

在Owin出现之前，ASP.NET应用程序的发布一直牢牢地绑定在IIS（Internet Information Services）的土壤里，这其中的原因可以从ASP.NET的设计哲学、Web服务器的职责以及微软生态系统的紧密耦合来细致地解读。

首先，我们得明白ASP.NET诞生的初衷。它被设计为一个构建在.NET Framework之上的Web开发框架，而.NET Framework本身就是微软打造的一个强大的平台，旨在简化Windows上的应用程序开发。ASP.NET的目标是提供一个高效、灵活、易于使用的模型来创建动态网站和Web应用程序。然而，要把这些应用程序交付给用户，就需要一个能够接收HTTP请求、处理请求并将其分发给ASP.NET应用程序的“中间人”，也就是Web服务器。

在那个时代，IIS是Windows服务器平台上占主导地位的Web服务器。微软在IIS中深度集成了一个称为“ASP.NET ISAPI”（Internet Server Application Programming Interface）的组件。你可以将ISAPI想象成一个桥梁，它允许IIS与ASP.NET运行时进行通信。当IIS接收到一个指向ASP.NET应用程序的请求时，它会将这个请求通过ISAPI传递给ASP.NET。ASP.NET运行时则负责解析这个请求，找到对应的ASP.NET处理程序（比如一个`.aspx`页面或者一个`.ashx`处理程序），执行相关的代码逻辑，生成响应，然后通过ISAPI将响应再传回IIS，最终由IIS发送给客户端浏览器。

这种紧密的耦合带来了一些显而易见的便利性。IIS提供了许多IIS特有的功能，例如：

请求过滤和模块化： IIS拥有强大的请求过滤能力，可以根据URL、HTTP头等信息来决定是否处理某个请求，或者将其转交给特定的模块处理。ASP.NET ISAPI组件可以利用这些IIS的内置能力，使得ASP.NET应用程序能够受益于IIS的成熟的请求处理管道。
进程模型和管理： IIS提供了一个成熟的进程模型，能够管理ASP.NET应用程序的进程，包括进程的启动、回收、监控等。这对于保证应用程序的稳定性和可用性至关重要。IIS能够确保ASP.NET工作进程（`w3wp.exe`）按照预设的规则运行，一旦进程出现问题，IIS能够自动重启它。
安全性： IIS提供了丰富的安全配置选项，例如身份验证、授权、SSL/TLS加密等。ASP.NET应用程序可以轻松地利用IIS的安全特性，将安全相关的配置从应用程序代码中分离出来，提高安全性。
资源共享和多站点托管： IIS允许多个ASP.NET应用程序（甚至不同类型的Web应用程序）在同一台服务器上共存，并能够对这些应用程序进行隔离和资源分配。这使得服务器管理员能够更有效地管理Web服务器资源。

更重要的是，当时ASP.NET的运行时本身就是围绕着IIS的请求处理流程来设计的。ASP.NET的生命周期、请求的处理方式、应用程序域的管理等等，都与IIS的ISAPI紧密相关。你可以想象成，ASP.NET运行时就像是为IIS量身定做的一套“插件”，它被设计成在IIS这个“宿主”中运行得最好。

因此，当开发者想要发布一个ASP.NET应用程序时，他们自然而然地会将IIS配置为Web服务器，并且将ASP.NET ISAPI模块注册到IIS中，以便IIS能够识别并处理ASP.NET的请求。这种模式成为了ASP.NET发布和部署的标准流程，也被广泛接受和遵循。

换句话说，在Owin出现之前，ASP.NET并没有一个独立于Web服务器的“托管模型”。它的运行机制和生命周期都与Web服务器（主要是IIS）的请求处理管道深度绑定。IIS不仅仅是提供了一个网络接口，它还提供了ASP.NET运行所需的整个基础设施，包括进程管理、安全上下文、请求分发等等。所以，如果脱离了IIS，ASP.NET就像是失去了它的“家”，无法独立地接收和处理Web请求。

Owin的出现，正是为了打破这种紧密的耦合。它引入了一个标准化的、与Web服务器无关的“托管接口”（Hosting Interface），使得ASP.NET（及其后续的ASP.NET Core）可以运行在各种不同的Web服务器上，甚至是自托管的应用程序中，而不再强制依赖于IIS。但在那之前，IIS作为微软生态系统中的核心Web服务器，以及ASP.NET与其ISAPI的深度集成，共同塑造了ASP.NET只能在IIS上发布的局面。

当然可以脱离IIS跑，和OWIN没啥关系，只是很多程序员吃多了快餐忘了做饭了。

https:// msdn.microsoft.com/zh-c n/library/system.web.hosting(v=vs.110).aspx