一文看懂Web伺服器、應用伺服器、Web容器、反向代理伺服器區別與聯繫

知識 09-14

新媒體管家

點擊上方「

Python開發

」，選擇「置頂公眾號」

關鍵時刻，第一時間送達！

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

1. 一文看懂web伺服器、應用伺服器、web容器、反向代理伺服器區別與聯繫

1.1. Web伺服器概念與基本原理

1.1.1. Web伺服器的歷史

1.1.2. Web伺服器工作原理

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

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

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

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

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

1.4.1. 反向代理基本概念

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

1.5. 總結

1.1. Web伺服器概念與基本原理

1.1.1. Web伺服器的歷史

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

一個名為WorldWideWeb的瀏覽器。

世界上第一個網路伺服器，後來被稱為CERN httpd，它運行在NeXTSTEP上
在1991年至1994年期間，用於通過萬維網衝浪和交換數據的早期技術的簡單性和有效性有助於將其移植到許多不同的操作系統，並將其用於科學組織和大學，然後傳播到行業。

1994年，Berners-Lee決定組建萬維網聯盟（W3C），通過標準化過程來管理涉及的許多技術（HTTP，HTML等）的進一步發展。

就是這台伺服器：

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

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

雖然主要功能是提供內容，但HTTP的完整實現還包括從客戶端接收內容的方式。此功能用於提交Web表單，包括上傳文件。許多通用Web伺服器還支持使用Active Server Pages（ASP），PHP或其他腳本語言的伺服器端腳本。這意味著Web伺服器的行為可以在單獨的文件中腳本化，而實際的伺服器軟體保持不變。通常，此函數用於動態生成HTML文檔（「即時」），而不是返回靜態文檔。前者主要用於從資料庫檢索或修改信息。後者通常快得多，並且更容易被緩存，但不能提供動態內容。

Web伺服器不僅用於為萬維網服務。它們也可以被嵌入到諸如印表機，路由器，網路攝像機等設備中，並且僅服務於本地網路。然後，web伺服器可以用作用於監視或管理所討論的設備的系統的一部分。這通常意味著客戶端計算機上不需要安裝其他軟體，因為只需要一個網路瀏覽器（現在大多數操作系統都包含在內）。

1.1.2. Web伺服器工作原理

HTTP協議基於TCP協議上，是一個應用層協議，用於用戶代理和Web伺服器進行通信。Web伺服器通常採用一問一答的方式進行工作：

1、在用戶代理上用戶發起資源請求，請求內容包括但不限於：指定資源的唯一標識IRI,指明動作類型（GET/POST/DELETE/PUT...）

2、

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

3、

如果與伺服器的會話還沒建立，此時先建立TCP連接，並完成HTTP協商（確定雙方均可接受的處理方式，包括協議版本，是否加密，內容格式等等）。

4、

用戶代理把請求內容封裝成HTTP數據包向伺服器發送。

5、

伺服器接收到資源請求並以之前協商好的方式解包並處理。

6、

伺服器請求的資源封裝成HTTP數據包並返回給用戶代理。

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

TCP監聽模塊

伺服器監聽某個埠（一般默認是8080埠，用戶可以設置其他埠），以建立和用戶代理之間的連接。一旦建立連接，用戶代理的後續HTTP請求將不用再進入監聽模塊。

預處理

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

UR路由

解析URL字元串和動作以確定用戶代理請求的資源，根據匹配規則（通常根據正則表達式+後綴）路由到靜態資源處理模塊或動態資源處理模塊。

靜態資源處理模塊

負責找到靜態資源，比如HTML/Javascript/CSS文件/圖片/圖像，確定內容是字元流或者位元組流，並確定對應MIME,比如HTML生成MIME為text/html的字元流，mpeg視頻文件生成MIME為video/mpeg的位元組流。

動態資源處理模塊

運行業務邏輯處理，動態決定返回的資源內容和類型，內容和類型的處理原則同上。

後處理

根據和用戶協商的協議進行加密，壓縮，安全處理等等。

資源輸出模塊

把處理好的內容和類型封裝成HTTP報文，往TCP連接另一頭的用戶代理髮送TCP報文（內容是HTTP報文）。

主流Web伺服器

包括Apache、IIS 、Nginx，市場佔有率如下

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

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

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

Web伺服器的出現的標誌著WWW時代的帶來，世界變得更加平面化。當初嘗到甜頭的開創者們開始不滿足與在互聯網上獲取靜態資源，於是出現了CGI腳本來動態獲取資源。再後來網路發展方向也是朝著增強Web伺服器動態獲取資源的能力前進。以下是代表性的動態技術：

技術名詞	特點
CGI（Common Gateway Interface，公用網關介面）	以獨立進程運行，可以用多種語言開發，比如C,C++,VB,Perl，靈活但效率低，維護複雜
PHP	伺服器端嵌入HTML腳本，開源，功能強大，擴展性較差
JSP	伺服器端嵌入HTML腳本，跨平台，部署前需編譯，主要缺點是編寫JSP比較複雜，需熟悉JAVA及相關技術
ASP	伺服器端嵌入HTML腳本，開發簡單，功能強大，只能在windows下運行

隨後Web伺服器朝著企業級應用方向發展，快速的業務變化，迫使Web開發人員面對新的挑戰：如何快速寫出魯棒，可靠，符合業務需求的程序並順利部署？解決這個挑戰的一個有效的辦法是，創造一個Web程序開發框架（含運行環境，比如解釋執行JSP,Web API），這個框架解決魯棒性，可靠性問題，提供快速開發介面。換言之，開發人員只需要專註於實現業務本身，如有更高的需求還可以對框架進行定製和擴展。這個框架的另外一個名字是Web應用程序容器。

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

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

註：淺藍色的模塊是實現業務程序的主要使用模塊。

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

分配線程池資源

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

封裝Request上下文

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

封裝Response上下文

一個請求對應一個Response上下文，主要用於向用戶代理返回資源。可以在其中寫入輸出流，或者重定向，或者返回錯誤碼等等。

URL路由

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

動態資源處理模塊

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

回收資源

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

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

主流Web容器

包括Tomcat , IIS ,Jetty 。

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

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

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

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

目前，「應用伺服器」和「web伺服器」之間的界線已經變得模糊不清了。但是人們還把這兩個術語區分開來，作為強調使用。

當有人說到「web伺服器」時，你通常要把它認為是以HTTP為核心、web UI為嚮導的應用。當有人說到「應用伺服器」時，你可能想到「高負載、企業級特性、事務和隊列、多通道通信（HTTP和更多的協議）」。但現在提供這些需求的基本上都是同一個產品。

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

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

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

1.4.1. 反向代理基本概念

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

互聯網中的請求發送給反向代理，反向代理把請求轉發到內網中的伺服器。

反向代理的主要作用為：

加密和SSL加速

負載均衡

緩存靜態內容

壓縮

減速上傳

安全防火牆

外網發布

突破互聯網封鎖

解決跨域問題

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

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

左邊淡黃色功能模塊對外網報文進行處理，右邊灰色功能模塊針對內網報文進行處理

TCP監聽模塊

監聽TCP請求，這裡的請求是指報文內容是某應用層協議（比如HTTP,FTP,EMAIL等應用層協議）的請求。至於這裡是否會單獨產生一個線程來開始處理，這個由伺服器自己決定，目前最流行的是先入消息隊列然後非同步處理，這樣能極大提高代理的吞吐量和穩定性。

匹配被代理伺服器

代理伺服器根據一個表（存放外網url和內網伺服器的對應關係，通常需人工進行設置），如果匹配到則繼續處理，否則依據外網協議返回錯誤信息，比如HTTP協議這返回404。

應用負載均衡策略

如果比較大型的互聯網應用，為了整體系統穩定性，解決單點問題，需要根據自定義策略合理的轉發報文給被代理伺服器。簡單的策略是哈希分發或者隨機分發，一般可以由用戶進行配置和選擇。

預處理

這裡依據協商好的外網應用協議進行解密，安全，會話，解壓等處理。

新生成網路報文

這裡依據協商好的內網應用協議生成網路報文，這裡可能會進行加密，安全，會話，壓縮等處理。

轉發給被代理伺服器

把新生成的網路報文發送給內網伺服器（可能是否Web伺服器，Ftp伺服器，郵件伺服器）。

接受網路報文

接受內網伺服器反饋的網路報文。

預處理

這裡依據協商好的外網應用協議進行加密，安全，會話，壓縮等處理。

資源輸出模塊

這時生成滿足外網應用協議要求的報文，並發送到外網連接的另一端（用戶代理）。

常用的反向代理伺服器

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

1.5. 總結

從概念上講：Web伺服器是提供WWW服務的程序；Web容器是提供給開發者的框架；Web應用程序伺服器內容豐富得多，既可用各廠商通常遵循一定的工業標準並自定義擴展功能而成，也可以利用開源組件輕量級拼裝打造；反向代理伺服器在企業級應用中表現突出，具有解決集中式安全，負載均衡等等優點。如今這四個概念的邊界越來模糊，看看這個表就知道了：