動態資源處理模塊
運行業務邏輯處理，動態決定返回的資源內容和類型，內容和類型的處理原則同上。
後處理
根據和用戶協商的協議進行加密，壓縮，安全處理等等。
資源輸出模塊
把處理好的內容和類型封裝成HTTP報文，往TCP連接另一頭的用戶代理發送TCP報文（內容是HTTP報文）。
主流Web服務器
包括Apache、IIS 、Nginx，市場佔有率如下
還有比較多使用Tomcat，Jetty，WebSphere，WebLogic，Kerstrel等等。
1.2. Web應用程序容器概念與基本原理
1.2.1. Web應用程序容器的由來
Web服務器的出現的標誌著WWW時代的帶來，世界變得更加平面化。當初嚐到甜頭的開創者們開始不滿足與在互聯網上獲取靜態資源，於是出現了CGI腳本來動態獲取資源。再後來網絡發展方向也是朝著增強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容器，有兩種觀點：
- 由於Kerstrel不提供編寫應用的框架，所以它不是容器；asp.net core才是容器，因為它提供了開發應用的框架並提供web應用（MVC,Web API)運行環境。
- Kerstrel提供了運行環境。
非常歡迎大家提出自己的有力觀點，幫助我們清晰化這個asp.net core容器概念。
資料引用
https://en.wikipedia.org/wiki/Web_serverhttp://www.cnblogs.com/vipyoumay/p/5853694.htmlhttps://zh.wikipedia.org/wiki/%E5%8F%8D%E5%90%91%E4%BB%A3%E7%90%86
閱讀更多 java面試筆試 的文章
