我們知道，不同膚色的人外貌差別很大，而雙胞胎的辨識很難。有意思的是 Web 服務(wù)器/Web 容器/Web 應(yīng)用程序服務(wù)器/反向代理有點像四胞胎，在網(wǎng)絡(luò)上經(jīng)常一起出現(xiàn)。本文將對這四個概念進行區(qū)分。

Web 服務(wù)器概念與基本原理

Web 服務(wù)器的歷史

1989 年，互聯(lián)網(wǎng)之父 Berners-Lee 向其雇主 CERN 提出了一個新項目，目的是通過使用超文本系統(tǒng)來緩解科學(xué)家之間的信息交流。

該項目導(dǎo)致 Berners-Lee 在 1990 年編寫了兩個方案：

• 一個名為 World Wide Web 的瀏覽器。
• 網(wǎng)絡(luò)服務(wù)器后來被稱為 CERN httpd，它運行在 NeXTSTEP 上在 1991 年至 1994 年期間，用于通過萬維網(wǎng)沖浪和交換數(shù)據(jù)的早期技術(shù)的簡單性和有效性有助于將其移植到許多不同的操作系統(tǒng)，并將其用于科學(xué)組織和大學(xué)，然后傳播到行業(yè)。

1994 年，Berners-Lee 決定組建萬維網(wǎng)聯(lián)盟(W3C)，通過標(biāo)準(zhǔn)化過程來管理涉及的許多技術(shù)(HTTP，HTML 等)的進一步發(fā)展。

就是這臺服務(wù)器：

[[265111]]

Web 服務(wù)器的主要功能是存儲，處理和傳遞網(wǎng)頁給客戶。客戶端和服務(wù)器之間的通信使用超文本傳輸協(xié)議(HTTP)進行。

交付的頁面最常見的是 HTML 文檔，除了文本內(nèi)容之外，還可能包含圖像，樣式表和腳本。

一個用戶代理，通常是 Web 瀏覽器或 Web 爬蟲，通過發(fā)起一個 HTTP 請求以獲取服務(wù)器資源，服務(wù)器根據(jù)請求返回該資源或由于某種原因響應(yīng)錯誤消息。

該資源通常是服務(wù)器輔助存儲上的真實文件，但這不一定是這種情況，取決于 Web 服務(wù)器的實現(xiàn)方式。

雖然主要功能是提供內(nèi)容，但 HTTP 的完整實現(xiàn)還包括從客戶端接收內(nèi)容的方式。此功能用于提交 Web 表單，包括上傳文件。

許多通用 Web 服務(wù)器還支持使用 Active Server Pages(ASP)，PHP 或其他腳本語言的服務(wù)器端腳本。

這意味著 Web 服務(wù)器的行為可以在單獨的文件中腳本化，而實際的服務(wù)器軟件保持不變。

通常，此函數(shù)用于動態(tài)生成 HTML 文檔(“即時”)，而不是返回靜態(tài)文檔。前者主要用于從數(shù)據(jù)庫檢索或修改信息;后者通常快得多，并且更容易被緩存，但不能提供動態(tài)內(nèi)容。

Web 服務(wù)器不僅用于為萬維網(wǎng)服務(wù)。它們也可以被嵌入到諸如打印機，路由器，網(wǎng)絡(luò)攝像機等設(shè)備中，并且僅服務(wù)于本地網(wǎng)絡(luò)。

然后，Web 服務(wù)器可以用于監(jiān)視或管理所討論的設(shè)備的系統(tǒng)的一部分。

這通常意味著客戶端計算機上不需要安裝其他軟件，因為只需要一個網(wǎng)絡(luò)瀏覽器(現(xiàn)在大多數(shù)操作系統(tǒng)都包含在內(nèi))。

Web 服務(wù)器工作原理

HTTP 協(xié)議基于 TCP 協(xié)議上，是一個應(yīng)用層協(xié)議，用于用戶代理和 Web 服務(wù)器進行通信。

Web 服務(wù)器通常采用一問一答的方式進行工作：

• 在用戶代理上用戶發(fā)起資源請求，請求內(nèi)容包括但不限于：指定資源的標(biāo)識 URI，指明動作類型(GET/POST/DELETE/PUT…)
• 用戶代理解析用戶輸入 URI 并從中獲取目標(biāo)域名，交由 DNS 服務(wù)器解析。如果 URI 中指定某 IP 地址，就無需這步。
• 如果與服務(wù)器的會話還沒建立，此時先建立 TCP 連接，并完成 HTTP 協(xié)商(確定雙方均可接受的處理方式，包括協(xié)議版本，是否加密，內(nèi)容格式等等)。
• 用戶代理把請求內(nèi)容封裝成 HTTP 數(shù)據(jù)包向服務(wù)器發(fā)送。
• 服務(wù)器接收到資源請求并以之前協(xié)商好的方式解包并處理。
• 服務(wù)器請求的資源封裝成 HTTP 數(shù)據(jù)包并返回給用戶代理。

接下來重點說說服務(wù)器端的工作原理，如下圖：

TCP 監(jiān)聽模塊：服務(wù)器監(jiān)聽某個端口(一般默認是 8080 端口，用戶可以設(shè)置其他端口)，以建立和用戶代理之間的連接。一旦建立連接，用戶代理的后續(xù) HTTP 請求將不用再進入監(jiān)聽模塊。

預(yù)處理：此處主要做三件事，從 TCP 報文中獲取 HTTP 請求報文，根據(jù)和用戶代理的協(xié)商進行解密，解壓，安全處理等等。根據(jù)服務(wù)器自身的配置進行安全處理，建立會話狀態(tài)等等。

UR 路由：解析 URL 字符串和動作以確定用戶代理請求的資源，根據(jù)匹配規(guī)則(通常根據(jù)正則表達式+后綴)路由到靜態(tài)資源處理模塊或動態(tài)資源處理模塊。

靜態(tài)資源處理模塊：負責(zé)找到靜態(tài)資源，比如 HTML/JavaScript/CSS 文件/圖片/圖像，確定內(nèi)容是字符流或者字節(jié)流，并確定對應(yīng) MIME。

比如 HTML 生成 MIME 為 text/html 的字符流，mpeg 視頻文件生成 MIME 為 video/mpeg 的字節(jié)流。

動態(tài)資源處理模塊：運行業(yè)務(wù)邏輯處理，動態(tài)決定返回的資源內(nèi)容和類型，內(nèi)容和類型的處理原則同上。

后處理：根據(jù)和用戶協(xié)商的協(xié)議進行加密，壓縮，安全處理等等。

資源輸出模塊：把處理好的內(nèi)容和類型封裝成 HTTP 報文，往 TCP 連接另一頭的用戶代理發(fā)送 TCP 報文(內(nèi)容是 HTTP 報文)。

主流 Web 服務(wù)器

包括 Apache、IIS 、Nginx 市場占有率如下圖：

還有比較多使用 Tomcat，Jetty，WebSphere，WebLogic，Kerstrel 等等。

Web 應(yīng)用程序容器概念與基本原理

Web 應(yīng)用程序容器的由來

Web 服務(wù)器的出現(xiàn)標(biāo)志著 WWW 時代的到來，世界變得更加平面化。當(dāng)初嘗到甜頭的開創(chuàng)者們開始不滿足于在互聯(lián)網(wǎng)上獲取靜態(tài)資源，于是出現(xiàn)了 CGI 腳本來動態(tài)獲取資源。

再后來網(wǎng)絡(luò)發(fā)展方向也是朝著增強 Web 服務(wù)器動態(tài)獲取資源的能力前進。以下是代表性的動態(tài)技術(shù)：

Web 應(yīng)用程序容器的基本工作原理

一般情況下，Web 應(yīng)用程序容器是以下構(gòu)成體系：

注：淺藍色的模塊是實現(xiàn)業(yè)務(wù)程序的主要使用模塊

相對于 Web 服務(wù)器，該容器新增或強化了以下模塊：

• 分配線程池資源，容器為每個請求分配一個線程進行處理，通常采取線程池的方式高效率由 CPU 算資源。
• 封裝 Request 上下文，一個請求對應(yīng)一個 Request 上下文，它主要封裝了用戶請求的主要構(gòu)成。

URL，HTTP 請求頭，以及基于請求頭構(gòu)建的 Session，Cookie 等對象，方便編程使用。

• 封裝 Response 上下文，一個請求對應(yīng)一個 Response 上下文，主要用于向用戶代理返回資源。可以在其中寫入輸出流，或者重定向，或者返回錯誤碼等等。
• URL 路由，在容器里，運行開發(fā)人員設(shè)置不同的路由匹配規(guī)則，比如讓 .HTM 返回 .HTML，也可以自定義 .xyz 返回 .HTML 資源。更加靈活的配置可以參考 Java MVC 或者 ASP.NET MVC 的配置方案。
• 動態(tài)資源處理模塊，通常在這里具體的容器和開發(fā)語言都有自己的高效開發(fā)模型，比如 Java 的 Servlet，ASP.NET 的 Web Form，MVC。
• 回收資源，這里會回收剛才的線程資源，為了線程復(fù)用，除非服務(wù)器空閑一般會將線程返回線程池。

可以看出，Web 容器本身具備了做為一個 Web 服務(wù)器的功能，事實上通常實現(xiàn) Web 容器功能的服務(wù)器就是一個 Web 服務(wù)器。比如 Tomcat，IIS，Jetty。

主流 Web 容器

包括 Tomcat，IIS，Jetty 。還有比較多使用 WebSphere，WebLogic 等等。

Web 應(yīng)用程序服務(wù)器概念及基本原理

在 Web 服務(wù)器發(fā)展的同一個時期，應(yīng)用服務(wù)器已經(jīng)存在并發(fā)展很長一段時間了。

一些公司為 Unix 開發(fā)了 Tuxedo(面向事務(wù)的中間件)、TopEnd、Encina 等產(chǎn)品，這些產(chǎn)品都是從類似 IMS 和 CICS 的主機應(yīng)用管理和監(jiān)控環(huán)境衍生而來的。

大部分的這些產(chǎn)品都指定了“封閉的”產(chǎn)品專用通信協(xié)議來互連胖客戶機(“fat” client)和服務(wù)器。

在 90 年代，這些傳統(tǒng)的應(yīng)用服務(wù)器產(chǎn)品開始嵌入 HTTP 通信功能，剛開始要利用網(wǎng)關(guān)來實現(xiàn)。不久后它們之間的界線開始變得模糊了。

同時，Web 服務(wù)器越來越成熟，可以處理更高的負載、更多的并發(fā)和擁有更好的特性;應(yīng)用服務(wù)器開始添加越來越多的基于 HTTP 的通信功能。所有的這些導(dǎo)致了 Web 服務(wù)器與應(yīng)用服務(wù)器的界限變得更窄了。

目前，“應(yīng)用服務(wù)器”和“Web 服務(wù)器”之間的界限已經(jīng)變得模糊不清了。但是人們還把這兩個術(shù)語區(qū)分開來，作為強調(diào)使用。

當(dāng)有人說到“Web 服務(wù)器”時，你通常要把它認為是以 HTTP 為核心、Web UI 為向?qū)У膽?yīng)用。

當(dāng)有人說到“應(yīng)用服務(wù)器”時，你可能想到“高負載、企業(yè)級特性、事務(wù)和隊列、多通道通信(HTTP 和更多的協(xié)議)”。但現(xiàn)在提供這些需求的基本上都是同一個產(chǎn)品。

下圖描述一個典型的 Web 應(yīng)用服務(wù)器的結(jié)構(gòu)圖：

從上圖中可以看到 Web 應(yīng)用服務(wù)器包括了 Web 容器，同時內(nèi)置了支撐企業(yè)應(yīng)用的事務(wù)，安全，集成，通信，高可用等等功能。

極大地減少了重復(fù)開發(fā)量，保障了業(yè)務(wù)系統(tǒng)快速開發(fā)和部署，而它本身也是一個 Web 服務(wù)器。

Web 應(yīng)用服務(wù)器可以選擇使用大廠的 WebLogic 和 WebSphere 這種重量級產(chǎn)品外。

也可以使用類似與 Tomcat、Jetty 這樣的 Web Containner 再加上第三方的框架(Spring，Hibernate等)來構(gòu)建自己的 Application Server;.NET Core 平臺下可以選擇 IIS，Apache，Nginx 與 ASP.NET Core 構(gòu)建。

反向代理概念與基本原理

反向代理基本概念

反向代理是代理服務(wù)器的一種。它根據(jù)客戶端的請求，從后端的服務(wù)器(如Web 服務(wù)器)上獲取資源，然后再將這些資源返回給客戶端。

與前向代理不同，前向代理作為一個媒介將互聯(lián)網(wǎng)上獲取的資源返回給相關(guān)聯(lián)的客戶端，而反向代理是在服務(wù)器端(如 Web 服務(wù)器)作為代理使用，而不是客戶端。

客戶端通過前向代理可以訪問很多不同的資源，反向代理是很多客戶端都通過它訪問不同后端服務(wù)器上的資源，而不需要知道這些后端服務(wù)器的存在，以為所有資源都來自于這個反向代理服務(wù)器。

互聯(lián)網(wǎng)中的請求發(fā)送給反向代理，反向代理把請求轉(zhuǎn)發(fā)到內(nèi)網(wǎng)中的服務(wù)器。

反向代理的主要作用為：

• 加密和SSL加速
• 負載均衡
• 緩存靜態(tài)內(nèi)容
• 壓縮
• 減速上傳
• 安全防火墻
• 外網(wǎng)發(fā)布
• 突破互聯(lián)網(wǎng)封鎖
• 解決跨域問題

反向代理基本工作原理

一個反向代理服務(wù)器的構(gòu)成和處理過程如下圖：

左邊功能模塊對外網(wǎng)報文進行處理，右邊灰色功能模塊針對內(nèi)網(wǎng)報文進行處理。

TCP 監(jiān)聽模塊

監(jiān)聽 TCP 請求，這里的請求是指報文內(nèi)容是某應(yīng)用層協(xié)議(比如 HTTP，F(xiàn)TP，Email 等應(yīng)用層協(xié)議)的請求。

至于這里是否會單獨產(chǎn)生一個線程來開始處理，這個由服務(wù)器自己決定，先入消息隊列然后異步處理，這樣能極大提高代理的吞吐量和穩(wěn)定性。

匹配被代理服務(wù)器

代理服務(wù)器根據(jù)一個表(存放外網(wǎng) URI 和內(nèi)網(wǎng)服務(wù)器的對應(yīng)關(guān)系，通常需人工進行設(shè)置)，如果匹配到則繼續(xù)處理，否則依據(jù)外網(wǎng)協(xié)議返回錯誤信息，比如 HTTP 協(xié)議這返回 404。

應(yīng)用負載均衡策略

如果比較大型的互聯(lián)網(wǎng)應(yīng)用，為了整體系統(tǒng)穩(wěn)定性，解決單點問題，需要根據(jù)自定義策略合理的轉(zhuǎn)發(fā)報文給被代理服務(wù)器。簡單的策略是哈希分發(fā)或者隨機分發(fā)，一般可以由用戶進行配置和選擇。

預(yù)處理

這里依據(jù)協(xié)商好的外網(wǎng)應(yīng)用協(xié)議進行解密，安全，會話，解壓等處理。

新生成網(wǎng)絡(luò)報文

這里依據(jù)協(xié)商好的內(nèi)網(wǎng)應(yīng)用協(xié)議生成網(wǎng)絡(luò)報文，這里可能會進行加密，安全，會話，壓縮等處理。

轉(zhuǎn)發(fā)給被代理服務(wù)器

把新生成的網(wǎng)絡(luò)報文發(fā)送給內(nèi)網(wǎng)服務(wù)器(可能是否 Web 服務(wù)器，F(xiàn)TP 服務(wù)器，郵件服務(wù)器)。

接受網(wǎng)絡(luò)報文

接受內(nèi)網(wǎng)服務(wù)器反饋的網(wǎng)絡(luò)報文。

預(yù)處理

這里依據(jù)協(xié)商好的外網(wǎng)應(yīng)用協(xié)議進行加密，安全，會話，壓縮等處理。

資源輸出模塊

這時生成滿足外網(wǎng)應(yīng)用協(xié)議要求的報文，并發(fā)送到外網(wǎng)連接的另一端(用戶代理)。

常用的反向代理服務(wù)器

它們的名字您一定記得，分別是：Ngnix，IIS，Apache。

總結(jié)

從概念上講：

• Web 服務(wù)器是提供 WWW 服務(wù)的程序。
• Web 容器是提供給開發(fā)者的框架。
• Web 應(yīng)用程序服務(wù)器內(nèi)容豐富得多，既可由各廠商通常遵循一定的工業(yè)標(biāo)準(zhǔn)并自定義擴展功能而成，也可以利用開源組件輕量級拼裝打造。
• 反向代理服務(wù)器在企業(yè)級應(yīng)用中表現(xiàn)突出，具有解決集中式安全，負載均衡等等優(yōu)點。

如今這四個概念的邊界越來模糊，看看這個表就知道了

關(guān)于 Kerstrel 是否是 Web 容器，有兩種觀點：

• 由于 Kerstrel 不提供編寫應(yīng)用的框架，所以它不是容器;ASP.NET Core 才是容器，因為它提供了開發(fā)應(yīng)用的框架并提供 Web 應(yīng)用(MVC，Web API)運行環(huán)境。
• Kerstrel 提供了運行環(huán)境。

非常歡迎大家提出自己的有力觀點，幫助我們清晰化這個 ASP.NET Core 容器概念。

參考資料：

• https://en.wikipedia.org/wiki/Web_server
• http://www.cnblogs.com/vipyoumay/p/5853694.html
• https://zh.wikipedia.org/wiki/%E5%8F%8D%E5%90%91%E4%BB%A3%E7%90%86