一次完整的http請求處理過程+MPM工作模式

? 1、建立連接：接收或拒絕連接請求
? 2、接收請求：接收客戶端請求報文中對某資源的一次請求的過程
? Web訪問響應模型（Web I/O）
單進程I/O模型：啟動一個進程處理用戶請求，而且一次只處理一個，多個請求被串
行響應
多進程I/O模型：并行啟動多個進程,每個進程響應一個連接請求
復用I/O結構：啟動一個進程，同時響應N個連接請求
實現方法：多線程模型和事件驅動
多線程模型：一個進程生成N個線程，每線程響應一個連接請求
事件驅動：一個進程處理N個請求
復用的多進程I/O模型：啟動M個進程，每個進程響應N個連接請求，同時接收M*N
個請求

Web訪問響應模型

?3、處理請求：服務器對請求報文進行解析，并獲取請求的資源及請求方法等相
關信息，根據方法，資源，首部和可選的主體部分對請求進行處理
元數據：請求報文首部
<method> <URL> <VERSION>
HEADERS 格式 name:value
<request body>
示例：
Host: www.magedu.com 請求的主機名稱
Server: Apache/2.4.7
? HTTP常用請求方式，Method
GET、POST、HEAD、PUT、DELETE、TRACE、OPTIONS

?4、訪問資源：
服務器獲取請求報文中請求的資源web服務器，即存放了web資源的服務器，
負責向請求者提供對方請求的靜態資源，或動態運行后生成的資源
資源放置于本地文件系統特定的路徑：DocRoot
DocRoot ? /var/www/html
/var/www/html/images/logo.jpg
http://www.magedu.com/images/logo.jpg
? web服務器資源路徑映射方式：
(a) docroot
(b) alias
(c) 虛擬主機docroot
(d) 用戶家目錄docroot

? 5、構建響應報文：
一旦Web服務器識別除了資源，就執行請求方法中描述的動作，并返回響應報文。
響應報文中 包含有響應狀態碼、響應首部，如果生成了響應主體的話，還包括響應主體
1）響應實體：如果事務處理產生了響應主體，就將內容放在響應報文中回送過去。響
應報文中通常包括：
描述了響應主體MIME類型的Content-Type首部
描述了響應主體長度的Content-Length
實際報文的主體內容
2）URL重定向：web服務構建的響應并非客戶端請求的資源，而是資源另外一個訪問路
徑
永久重定向：http://www.360buy.com
臨時重定向：http://www.taobao.com

3）MIME類型：
Web服務器要負責確定響應主體的MIME類型。多種配置服務器的方法可將
MIME類型與資源管理起來
魔法分類：Apache web服務器可以掃描每個資源的內容，并將其與一個已知模
式表(被稱為魔法文件)進行匹配，以決定每個文件的MIME類型。這樣做可能比較
慢，但很方便，尤其是文件沒有標準擴展名時
顯式分類：可以對Web服務器進行配置，使其不考慮文件的擴展名或內容，強
制特定文件或目錄內容擁有某個MIME類型
類型協商： 有些Web服務器經過配置，可以以多種文檔格式來存儲資源。在這
種情況下，可以配置Web服務器，使其可以通過與用戶的協商來決定使用哪種格
式(及相關的MIME類型)”最好”

?6、發送響應報文
Web服務器通過連接發送數據時也會面臨與接收數據一樣的問題。服務器
可能有很多條到各個客戶端的連接，有些是空閑的，有些在向服務器發送數據，還
有一些在向客戶端回送響應數據。服務器要記錄連接的狀態，還要特別注意對持久
連接的處理。對非持久連接而言，服務器應該在發送了整條報文之后，關閉自己這
一端的連接。對持久連接來說，連接可能仍保持打開狀態，在這種情況下，服務器
要正確地計算Content-Length首部，不然客戶端就無法知道響應什么時候結束了
?7、記錄日志
最后，當事務結束時，Web服務器會在日志文件中添加一個條目，來描述
已執行的事務

prefork：多進程I/O模型，每個進程響應一個請求，默認模型
一個主進程：生成和回收n個子進程，創建套接字，不響應請求
多個子進程：工作work進程，每個子進程處理一個請求；系統初始時，預先
生成多個空閑進程，等待請求，最大不超過1024個

?worker：復用的多進程I/O模型,多進程多線程，IIS使用此模型
一個主進程：生成m個子進程，每個子進程負責生個n個線程，每個線程響應
一個請求，并發響應請求：m*n

Event MPM：以上兩種穩定的MPM方式在非常繁忙的服務器應用下都有些不足。盡管HTTP的Keepalive方式能減少TCP連接數量和網絡負載，但是 Keepalive需要和服務進程或者線程綁定，這就導致一個繁忙的服務器會耗光所有的線程。 Event MPM是解決這個問題的一種新模型，它把服務進程從連接中分離出來。在服務器處理速度很快，同時具有非常高的點擊率時，可用的線程數量就是關鍵的資源限 制，此時Event MPM方式是最有效的。一個以Worker MPM方式工作的繁忙服務器能夠承受每秒好幾萬次的訪問量（例如在大型新聞服務站點的高峰時），而Event MPM可以用來處理更高負載。值得注意的是，Event MPM不能在安全HTTP（HTTPS）訪問下工作。

對于Event 模式，apache給出了以下警告：

This MPM is experimental, so it may or may not work as expected .

這種MPM目前處于試驗狀態，他可能不能按照預期的那樣工作。