http://www.cnblogs.com/Leo_wl/p/4547928.html

什麼是OWIN

OWIN是Open Web Server Interface for .NET的首字母縮寫，他的定義如下：
OWIN在.NET Web Servers與Web Application之間定義了一套標準介面，OWIN的目標是用於解耦Web Server和Web Application。基於此標準，鼓勵開發者開發簡單、靈活的模組，從而推進.NET Web Development開源生態系統的發展。

正如你看到的這樣，OWIN是介面、契約，而非具體的程式碼實現，僅僅是規範(specifications)，所以要實現自定義基於OWIN的Web Server必須要實現此規範。

歷時兩年（2010-2012），OWIN的規範終於完成並且當前版本是1.0，在OWIN的官網上可以看到更具體的資訊。

OWIN的作用

過去，IIS作為.NET開發者來說是最常用的Web Server（沒有之一），源於微軟產品的緊耦合關係，我們不得不將Website、Web Application、Web API等部署在IIS上，事實上在2010年前並沒有什麼不妥，但隨著近些年來Web的發展，特別是移動網際網路飛速發展，IIS作為Web Server已經暴露出他的不足了。主要體現在兩個方面，ASP.NET (System.Web)緊耦合IIS，IIS緊耦合OS，這就意味著，我們的Web Framework必須部署在微軟的作業系統上，難以跨平臺。

ASP.NET和IIS

我們知道，不管是ASP.NET MVC還是ASP.NET WEB API等都是基於ASP.NET Framework的，這種關係從字首就可以窺倪出來。而ASP.NET的核心正是System.Web這個程式集，而且System.Web緊耦合IIS，他存在於.NET Framework中。所以，這導致了Web Framework嚴重的侷限性：

• ASP.NET的核心System.Web，而System.Web緊耦合IIS
• System.Web是.NET Framework重要組成，已有15年以上歷史，沉重、冗餘，效能差，難於測試，約2.5M
• System.Web要更新和釋出新功能必須等待.NET Framework釋出
• .但NET Framework是Windows的基礎，往往不會隨意更新。

所以要想獲取最新的Web Framework是非常麻煩的，幸運的事，微軟已經意識到了問題的嚴重性，最新的Web Framework都是通過Nuget來獲取。
當然這是一部分原因，還有一層原因是ASP.NET & IIS實在太過於笨重，如何講呢？
複雜的生命週期已成為累贅？簡單來說，當請求到達伺服器時，Windows核心元件HTTP.SYS元件捕獲請求，他會分析請求並決定是否交給IIS來處理，當請求到達IIS之後，IIS會根據處理程式對映來匹配請求並交給對應的程式集（實現了ISAPI介面，比如我們熟知的aspnet_isapi.dll是專門用來處理ASP.NET Application）處理，最後載入了CLR執行環境，將請求交給aspnet_wp.exe去處理，這時複雜的ASP.NET生命週期往往令人頭大，但事實上有很多時候我們並不需要他。

如下圖所示ASP.NET Architecture：

開啟IIS，你會發現他提供了非常豐富的功能：快取、身份驗證、壓縮、加密等。但隨著移動網際網路蓬勃的發展，特別是HTML 5越來越成熟的今天，我們看到越來越多的操作發生在客戶端，而不是沉重的從伺服器產生HTML返回，更多的是通過非同步AJAX返回原生的資料。同理，對於APP來說我們只需要Mobile Service返回資料。顯然IIS顯得笨重了點，而且IIS作為微軟產品系的一環，耦合程度太高。所以我們迫切需要輕量、快速、可擴充套件的宿主來承載Web Application和Web Service。

IIS和OS

IIS必須是安裝並執行在Windows作業系統中，這是微軟產品的一貫風格，環環相套，但不得不考慮他們的限制和侷限性：

• IIS往往和作業系統（Windows Server）繫結在一起，這意味著對於一些新功能如WebSocket Protocol，我們不得不等待作業系統Windows Sever 2012、Windows 8的釋出（IIS 8.0）。
• 為了使用WebSocket這類新特性，他僅被IIS 8.0支援，如下所示：

這時你不得不去升級IIS，但升級作業系統可能會引發舊系統的不穩定性，所以要想平穩的升級IIS並不是簡單的。

• IIS作為經典的Web Server必須安裝在Windows系統中，Windows Server需要授權使用。

正是由於微軟產品系緊耦合的關係，才造成跨平臺上的不足，這也是被飽受詬病。所以我們需要OWIN來解耦，在物件導向的世界裡，介面往往是解耦的關鍵，如下圖所示：

使用OWIN，Web Framework不再依賴IIS和OS，這意味著你能使用任何你想的來替換IIS(比如：Katana或者Nowin)，並且在必要時隨時升級，而不是更新作業系統。當然，如果你需要的話，你可以構建自定義的宿主和Pipeline去處理Http請求。
這一切的改變都是由於OWIN的出現，他提供了明晰的規範以便我們快速靈活的去擴充套件Pipeline來處理Http請求，甚至可以不寫任何一句程式碼來切換不同的Web Server，前提是這些Web Server遵循OWIN規範。

OWIN的規範

現在我們已經瞭解了什麼是OWIN以及為什麼需要OWIN，現在是時候來分析一下OWIN的規範了。

OWIN Layers

實際上，OWIN的規範非常簡單，他定義了一系列的層（Layer），並且他們的順序是以堆（Stack）的形式定義，如下所示。OWIN中的介面被稱之為應用程式委託或者AppFunc，用來在這些層之間通訊。

OWIN定義了4層：
Host：主要負責應用程式的配置和啟動程式，包括初始化OWIN Pipeline、執行Server。
Server：這是實際的Http Server，繫結套接字並監聽的HTTP請求然後將Request和Response的Body、Header封裝成符合OWIN規範的字典併傳送到OWIN Middleware Pipeline中，最後Application為Response Data填充合適的欄位輸出。
Middleware：稱之為中介軟體、元件，位於Server與Application之間，用來處理髮送到Pipeline中的請求，這類元件可以是簡單的Logger或者是複雜的Web Framework比如Web API、SignalR，只要Sever連線成功，Middleware中介軟體可以是任何實現應用程式委託的元件。
Application：這是具體的應用程式程式碼，可能在Web Framework之上。對於Web API、SignalR這類Web Framework中介軟體而言，我們僅僅是改變了他們的託管方式，而不是取代ASP.NET WEB API、SignalR原先的應用程式開發。所以該怎麼開發就怎麼開發，只不過我們將他們註冊到OWIN Pipeline中去處理HTTP請求，成為OWIN管道的一部分，所以此處的Application即正在意義上的處理程式程式碼。

Application Delegate

OWIN規範另一個重要的組成部分是介面的定義，用於Server和Middleware的互動。他並不是嚴格意義上的介面，而是一個委託並且每個OWIN中介軟體元件必須提供。

從字面上理解，每個OWIN中介軟體在必須有一個方法接受型別了IDictionary<string,object>的變數（俗稱環境字典），然後必須返回Task來非同步執行。

Environment Dictionary

環境字典包含了Request、Response所有資訊以及Server State。通過Pipeline，每個中介軟體元件和層都可以新增額外的資訊，但環境字典定義了一系列強制必須存在的Key，如下所示：
Request Data:

Required	Key Name	Value Description
Yes	owin.RequestBody	A Stream with the request body, if any. Stream.Null MAY be used as a placeholder if there is no request body. See Request Body.
Yes	owin.RequestHeaders	An IDictionary<string, string[]> of request headers. See Headers.
Yes	owin.RequestMethod	A string containing the HTTP request method of the request (e.g., “GET”, “POST”).
Yes	owin.RequestPath	A string containing the request path. The path MUST be relative to the “root” of the application delegate. See Paths.
Yes	owin.RequestPathBase	A string containing the portion of the request path corresponding to the “root” of the application delegate; see Paths.
Yes	owin.RequestProtocol	A string containing the protocol name and version (e.g. “HTTP/1.0” or “HTTP/1.1“).
Yes	owin.RequestQueryString	A string containing the query string component of the HTTP request URI, without the leading “?” (e.g., “foo=bar&amp;baz=quux“). The value may be an empty string.
Yes	owin.RequestScheme	A string containing the URI scheme used for the request (e.g., “http”, “https”); see URI Scheme.

Response Data:

Required	Key Name	Value Description
Yes	owin.ResponseBody	A Stream used to write out the response body, if any. See Response Body.
Yes	owin.ResponseHeaders	An IDictionary<string, string[]> of response headers. See Headers.
No	owin.ResponseStatusCode	An optional int containing the HTTP response status code as defined in RFC 2616 section 6.1.1. The default is 200.
No	owin.ResponseReasonPhrase	An optional string containing the reason phrase associated the given status code. If none is provided then the server SHOULD provide a default as described in RFC 2616 section 6.1.1
No	owin.ResponseProtocol	An optional string containing the protocol name and version (e.g. “HTTP/1.0” or “HTTP/1.1“). If none is provided then the “owin.RequestProtocol” key’s value is the default.

Other Data:

Required	Key Name	Value Description
Yes	owin.CallCancelled	A CancellationToken indicating if the request has been canceled/aborted. See Request Lifetime.
Yes	owin.Version	A string indicating the OWIN version. See Versioning.

小結

這些規範看起來可能簡單到微不足道，但OWIN的思想就是簡單、靈活——通過要求OWIN中介軟體只依賴AppFun型別，為開發基於OWIN的中介軟體提供了的最低門檻。同時，通過使用環境字典在各個中介軟體之間進行資訊的傳遞，而非傳統ASP.NET（System.Web）中使用HttpContext貫穿ASP.NET整個生命週期來傳遞。

既然OWIN是規範，而非真正實現，所以是無法使用在專案中的，若要使用OWIN，必須要實現他，所以這也是接下來我想聊的，OWIN的實現：Katana 。

---

OWIN - Open Web Interface for .NET

1.什麼是 OWIN

OWIN 的全稱是 “Open Web Interface for .NET”， OWIN 在 .NET Web 伺服器和 .NET Web 應用之間定義了一套標準的介面， 其目的是為了實現伺服器與應用之間的解耦， 鼓勵為 .NET Web 應用開發簡單模組。

官方解釋：

OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools.

如果僅從名稱上解析，可以得出這樣的資訊：OWIN是針對.NET平臺的開放Web介面。
那Web介面是誰和誰之間的介面呢？是Web應用程式與Web伺服器之間的介面，OWIN就是.NET Web應用程式與Web伺服器之間的介面。

為什麼需要這樣一個介面呢？因為.NET Web應用程式是執行於Web伺服器之中的，.NET Web應用程式需要通過Web伺服器接收使用者的請求，並且通過Web伺服器將響應內容傳送使用者。如果沒有這樣一個介面，.NET Web應用程式就要依賴於所執行的具體Web伺服器，比如ASP.NET應用程式要依賴於IIS。有了這個介面，ASP.NET應用程式只需依賴這個抽象介面，不用關心所執行的Web伺服器。

所以，OWIN的作用就是通過引入一組抽象介面，解耦了.NET Web應用程式與Web伺服器，再次體現了介面的重要性。在軟體開發中，每次解耦都是一次很大的進步。

OWIN 是一個開源開放的標準， 有助於建設 .NET 開發的開源生態環境，OWIN 定義瞭如下幾個概念：

• 伺服器 (Server)
  HTTP 伺服器直接與客戶端互動， 並用 OWIN 語義處理請求，伺服器需要一個適配層將客戶請求轉換 成 OWIN 語義。 支援 OWIN 的伺服器有 Katana 和 Nowin 。

• Web 框架 (Web Framework)
  構建在 OWIN 之上的自包含的獨立元件， 向 Web 應用提供可用的物件模型或者介面。 Web 框架可 能需要一個適配層來轉換 OWIN 語義。 支援 OWIN 的 Web 框架有：

  Nancy
  SignalR
  WebApi
  FubuMVC
  Simple.Web
  DuoVia.Http

• Web 應用 (Web Application)
  一個特定的 Web 應用， 通常構建在 Web 框架之上， 使用 OWIN 相容的伺服器執行。

• 中介軟體 (Middleware)
  特定目的的伺服器和應用之間的可插拔元件， 可以監視、 路由、 修改請求與響應。

• 宿主 (Host)
  應用與伺服器所在的程式， 主要負責應用的啟動， 有些伺服器自身也是宿主， 比如 Nowin 。

為什麼使用 OWIN

正如上面所說， OWIN 定義了 .NET Web 伺服器與 .NET Web 應用之間的標準介面， 將應用與伺服器 解耦， 使得行動式 .NET Web 應用以及跨平臺的願望成為現實， 標準的 OWIN 應用可以在任何 OWIN 相容的伺服器上執行， 不再依賴與 Windows 和 IIS 。