Web服務器、應用服務器、Web容器、反向代理服務器區別與聯繫

做者： 帥蟲哥

出處：www.cnblogs.com/vipyoumay/p/7455431.html（點擊尾部閱讀原文前往）

 

咱們知道，不一樣膚色的人外貌差異很大，而雙胞胎的辨識很難。有意思的是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服務器一般採用一問一答的方式進行工做：

 

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

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

三、若是與服務器的會話還沒創建，此時先創建TCP鏈接，並完成HTTP協商（肯定雙方都可接受的處理方式，包括協議版本，是否加密，內容格式等等）。

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

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

六、服務器請求的資源封裝成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應用程序服務器內容豐富得多，既可用各廠商一般遵循必定的工業標準並自定義擴展功能而成，也能夠利用開源組件輕量級拼裝打造；反向代理服務器在企業級應用中表現突出，具備解決集中式安全，負載均衡等等優勢。現在這四個概念的邊界越來模糊，看看這個表就知道了：

 

 

 

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

 

1. 因爲Kerstrel不提供編寫應用的框架，因此它不是容器；asp.net core纔是容器，由於它提供了開發應用的框架並提供web應用（MVC,Web API)運行環境。

2. Kerstrel提供了運行環境。

 

很是歡迎你們提出本身的有力觀點，幫助咱們清晰化這個asp.net core容器概念。

 

資料引用

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