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

1.1. Web服務器概念與基本原理1.1.1. Web服務器的歷史

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

一個名為WorldWideWeb的瀏覽器。

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

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

就是這臺服務器：

Web服務器的主要功能是存儲，處理和傳遞網(wǎng)頁給客戶。客戶端和服務器之間的通信使用超文本傳輸協(xié)議(HTTP)進行。交付的頁面最常見的是HTML文檔，除了文本內(nèi)容之外，還可能包含圖像，樣式表和腳本。

一個用戶代理，通常是web瀏覽器或web爬蟲，通過發(fā)起一個HTTP請求以獲取服務器資源，服務器根據(jù)請求返回該資源或由于某種原因響應錯誤消息。該資源通常是服務器輔助存儲上的真實文件，但這不一定是這種情況，取決于Web服務器的實現(xiàn)方式。

雖然主要功能是提供內(nèi)容，但HTTP的完整實現(xiàn)還包括從客戶端接收內(nèi)容的方式。此功能用于提交Web表單，包括上傳文件。許多通用Web服務器還支持使用Active Server Pages(ASP)，PHP或其他腳本語言的服務器端腳本。這意味著Web服務器的行為可以在單獨的文件中腳本化，而實際的服務器軟件保持不變。通常，此函數(shù)用于動態(tài)生成HTML文檔(“即時”)，而不是返回靜態(tài)文檔。前者主要用于從數(shù)據(jù)庫檢索或修改信息。后者通常快得多，并且更容易被緩存，但不能提供動態(tài)內(nèi)容。

Web服務器不僅用于為萬維網(wǎng)服務。它們也可以被嵌入到諸如打印機，路由器，網(wǎng)絡攝像機等設備中，并且僅服務于本地網(wǎng)絡。然后，web服務器可以用作用于監(jiān)視或管理所討論的設備的系統(tǒng)的一部分。這通常意味著客戶端計算機上不需要安裝其他軟件，因為只需要一個網(wǎng)絡瀏覽器(現(xiàn)在大多數(shù)操作系統(tǒng)都包含在內(nèi))。

1.1.2. Web服務器工作原理

HTTP協(xié)議基于TCP協(xié)議上，是一個應用層協(xié)議，用于用戶代理和Web服務器進行通信。Web服務器通常采用一問一答的方式進行工作：

1、在用戶代理上用戶發(fā)起資源請求，請求內(nèi)容包括但不限于：指定資源的唯一標識IRI,指明動作類型(GET/POST/DELETE/PUT...)

2、用戶代理解析用戶輸入IRI并從中獲取目標域名，交由DNS服務器解析。如果IRI中指定某IP地址，這無需這步。

3、如果與服務器的會話還沒建立，此時先建立TCP連接，并完成HTTP協(xié)商(確定雙方均可接受的處理方式，包括協(xié)議版本，是否加密，內(nèi)容格式等等)。

4、用戶代理把請求內(nèi)容封裝成HTTP數(shù)據(jù)包向服務器發(fā)送。

5、服務器接收到資源請求并以之前協(xié)商好的方式解包并處理。

6、服務器請求的資源封裝成HTTP數(shù)據(jù)包并返回給用戶代理。

接下來重點說說服務器端的工作原理

TCP監(jiān)聽模塊

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

預處理

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

UR路由

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

靜態(tài)資源處理模塊

負責找到靜態(tài)資源，比如HTML/Java/CSS文件/圖片/圖像，確定內(nèi)容是字符流或者字節(jié)流，并確定對應MIME,比如HTML生成MIME為text/html的字符流，mpeg視頻文件生成MIME為video/mpeg的字節(jié)流。

動態(tài)資源處理模塊

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

后處理

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

資源輸出模塊

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

主流Web服務器

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

1.2. Web應用程序容器概念與基本原理

1.2.1. Web應用程序容器的由來

Web服務器的出現(xiàn)的標志著WWW時代的帶來，世界變得更加平面化。當初嘗到甜頭的開創(chuàng)者們開始不滿足與在互聯(lián)網(wǎng)上獲取靜態(tài)資源，于是出現(xiàn)了CGI腳本來動態(tài)獲取資源。再后來網(wǎng)絡發(fā)展方向也是朝著增強Web服務器動態(tài)獲取資源的能力前進。

以下是代表性的動態(tài)技術：技術名詞特點 CGI(Common Gateway Interface，公用網(wǎng)關接口)以獨立進程運行，可以用多種語言開發(fā)，比如C,C++,VB,Perl，靈活但效率低，維護復雜 PHP服務器端嵌入HTML腳本，開源，功能強大，擴展性較差 JSP服務器端嵌入HTML腳本，跨平臺，部署前需編譯，主要缺點是編寫JSP比較復雜，需熟悉JAVA及相關技術 ASP服務器端嵌入HTML腳本，開發(fā)簡單，功能強大，只能在windows下運行 。

隨后Web服務器朝著企業(yè)級應用方向發(fā)展，快速的業(yè)務變化，迫使Web開發(fā)人員面對新的挑戰(zhàn)：如何快速寫出魯棒，可靠，符合業(yè)務需求的程序并順利部署?解決這個挑戰(zhàn)的一個有效的辦法是，創(chuàng)造一個Web程序開發(fā)框架(含運行環(huán)境，比如解釋執(zhí)行JSP,Web API)，這個框架解決魯棒性，可靠性問題，提供快速開發(fā)接口。換言之，開發(fā)人員只需要專注于實現(xiàn)業(yè)務本身，如有更高的需求還可以對框架進行定制和擴展。這個框架的另外一個名字是Web應用程序容器。

1.2.2. Web應用程序容器的基本工作原理

一般情況下Web應用程序容器是以下構成體系：

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

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

分配線程池資源

容器為每個請求分配一個線程進行處理，通常采取線程池的方式高效理由CPU算資源。

封裝Request上下文

一個請求對應一個Request上下文，它主要封裝了用戶請求的主要構成：URL,HTTP請求頭，以及基于請求頭構建的Session,Cookie等對象，方便編程使用。

封裝Response上下文

一個請求對應一個Response上下文，主要用于向用戶代理返回資源�？梢栽谄渲袑懭胼敵隽鳎�或者重定向，或者返回錯誤碼等等。

URL路由

在容器里，運行開發(fā)人員設置不同的路由匹配規(guī)則，比如讓.HTM返回.HTML,也可以自定義.xyz返回.HTML資源。更加靈活的配置可以參考JAVA MVC或者ASP.NET MVC的配置方案。

動態(tài)資源處理模塊

通常在這里具體的容器和開發(fā)語言都有自己的高效開發(fā)模型，比如JAVA的Servlet,ASP.NET的Web Form,MVC。

回收資源

這里會回收剛才的線程資源，為了線程復用，除非服務器空閑一般會將線程返回線程池。

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

主流Web容器

包括Tomcat , IIS ,Jetty 。

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

1.3. Web應用程序服務器概念及基本原理

在Web服務器發(fā)展的同一個時期,應用服務器已經(jīng)存在并發(fā)展很長一段時間了。一些公司為Unix開發(fā)了Tuxedo(面向事務的中間件)、TopEnd、Encina等產(chǎn)品，這些產(chǎn)品都是從類似IMS和CICS的主機應用管理和監(jiān)控環(huán)境衍生而來的。大部分的這些產(chǎn)品都指定了“封閉的”產(chǎn)品專用通信協(xié)議來互連胖客戶機(“fat” client)和服務器。在90年代，這些傳統(tǒng)的應用服務器產(chǎn)品開始嵌入HTTP通信功能，剛開始要利用網(wǎng)關來實現(xiàn)。不久后它們之間的界線開始變得模糊了。

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

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

當有人說到“web服務器”時，你通常要把它認為是以HTTP為核心、web UI為向?qū)У膽�用。當有人說到“應用服務器”時，你可能想到“高負載、企業(yè)級特性、事務和隊列、多通道通信(HTTP和更多的協(xié)議)”。但現(xiàn)在提供這些需求的基本上都是同一個產(chǎn)品。

下圖描述一個典型的Web應用服務器的結構圖:

從上圖中可以看到Web應用服務器包括了Web容器,同時內(nèi)置了支撐企業(yè)應用的事務,安全,集成,通信,高可用等等功能,極大了減少了重復開發(fā)量,保障了業(yè)務系統(tǒng)快速開發(fā)和部署,而它本身也是一個Web服務器。Web應用服務器可以選擇使用大廠的WebLogic和WebSphere這種重量級產(chǎn)品外，也可以使用類似與Tomcat、jetty這樣的web containner 再加上第三方的框架(spring,hibernate等)來構建自己的Application Server;.NET Core平臺下可以選擇IIS, Apache,Nginx 與ASP.NET Core構建。

1.4. 反向代理概念與基本原理1.4.1. 反向代理基本概念

反向代理是代理服務器的一種。它根據(jù)客戶端的請求，從后端的服務器(如Web服務器)上獲取資源，然后再將這些資源返回給客戶端。與前向代理不同，前向代理作為一個媒介將互聯(lián)網(wǎng)上獲取的資源返回給相關聯(lián)的客戶端，而反向代理是在服務器端(如Web服務器)作為代理使用，而不是客戶端。客戶端通過前向代理可以訪問很多不同的資源，而反向代理是很多客戶端都通過它訪問不同后端服務器上的資源，而不需要知道這些后端服務器的存在，而以為所有資源都來自于這個反向代理服務器。

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

反向代理的主要作用為：

加密和SSL加速

負載均衡

緩存靜態(tài)內(nèi)容

壓縮

減速上傳

安全防火墻

外網(wǎng)發(fā)布

突破互聯(lián)網(wǎng)封鎖

解決跨域問題

1.4.2. 反向代理基本工作原理

一個反向代理服務器的構成和處理過程如下圖：

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

TCP監(jiān)聽模塊

監(jiān)聽TCP請求，這里的請求是指報文內(nèi)容是某應用層協(xié)議(比如HTTP,FTP,EMAIL等應用層協(xié)議)的請求。至于這里是否會單獨產(chǎn)生一個線程來開始處理，這個由服務器自己決定，目前最流行的是先入消息隊列然后異步處理，這樣能極大提高代理的吞吐量和穩(wěn)定性。

匹配被代理服務器

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

應用負載均衡策略

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

預處理

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

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

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

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

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

接受網(wǎng)絡報文

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

預處理

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

資源輸出模塊

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

常用的反向代理服務器

它們的名字您一定記得：Ngnix,IIS,Apache。

1.5. 總結

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

關于Kerstrel是否web容器，有兩種觀點：

1. 由于Kerstrel不提供編寫應用的框架，所以它不是容器;asp.net core才是容器，因為它提供了開發(fā)應用的框架并提供web應用(MVC,Web API)運行環(huán)境。

2. Kerstrel提供了運行環(huán)境。

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

本文鏈接：http://m.51huadong.com/cloundnews/11001450.html