apache 工作過程和模式
常見web程序服務器（靜態網站服務器）
應用程序服務器（能直接讀取網站動態元素） IIS tomcat，jetty，jboss，resin
webshpere
seblogic，oc4 //orcale
一個完整的http請求過程 //網絡通信就是進程之間的通信
1 建立或處理鏈接； 接受請求或者拒絕請求
2接受請求
接受來自王珞丹請求報文中對某一資源的一次請求過程
並發訪問相應模型
一：單線程I/O結構 // 一個請求斷開才能接受下一個請求，多個請求被串行響應，一次只能處理一個； 串行相應體系
二 ： 多線程IO結構 // 並行啟動多個進程，每個進程相應一個請求；
三 ： 復用I/O ： 一個進程響應n個請求 //基於事件驅動
多線程模型： 一個進程生成多個線程，每個線程響應一個用戶的請求
事件驅動
：復用的多進程I/O結構： 啟動多個（m） 進程，每個進程響應n個請求；
3 處理請求： 多請求報文進行解析，並獲取請求的資源及請求方法等相關信息
元數據： 請求報文首部
host： 請求的主機
<methoud> <URL> <VERSION>
Host: www.baidu.com 請求主機名字
Connection:
4 訪問資源: 獲取請求報文中的請求資源：
web服務器，即存放了web資源的服務器，負責向請求者返回請求的資源
，或動態運行後生成的資源，這些資源放置於本地文件系統某路徑下，此路徑通常叫DocRoot
/var/www/html
也就是web服務器的家目錄
web服務器資源路徑映射方式
a： docroot
b： alias
c： 虛擬主機docroot
d： 用戶家目錄docroot
5 構建響應報文
構建相應報文的前提是找了資源，並允許用戶訪問
資源的MIME類型：
顯示分類
魔法分類
協商分類
URL重定向 //對請求的url重寫，訪問改變之後的url
永久重定向
臨時重定向
6發送響應報文
7 記錄日誌
a patchy server = apache
ASF: apache software doundation 阿帕奇基金會
httpd的特性：
高度模塊化： core + modules
DOS： dynamic shared object理模塊
MPM: multipath processing modules 多路處理模塊。該模塊有三種工作模式 Prefork MPM，Work MPM，Event MPM塊
prefork : 多進程模型，每個進程相應一個請求；
一個主進程（不負責處理用戶請求），負責生成n個子進程，子進程也成為工作進程，每個子進程處理一個用戶的請求: 即便麽有用戶請求，也會預先生成多個空閑進程（提高效率），隨時等待客戶請求；最大不會超過1024個（由此限制不能實現高並發）；
這個多路處理模塊(MPM)實現了一個非線程型的、預派生的web服務器，它的工作方式類似於Apache 1.3。它適合於沒有線程安全庫，需要避免線程兼容性問題的系統。它是要求將每個請求相互獨立的情況下最好的MPM，這樣若一個請求出現問題就不會影響到其他請求。
Worker MPM : 此多路處理模塊(MPM)使網絡服務器支持混合的多線程多進程。由於使用線程來處理請求，所以可以處理海量請求，而系統資源的開銷小於基於進程的MPM。但是，它也使用了多進程，每個進程又有多個線程，以獲得基於進程的MPM的穩定性。
每個進程可以擁有的線程數量是固定的。服務器會根據負載情況增加或減少進程數量。一個單獨的控制進程(父進程)負責子進程的建立。每個子進程可以建立ThreadsPerChild數量的服務線程和一個監聽線程，該監聽線程監聽接入請求並將其傳遞給服務線程處理和應答。
不管是Worker模式或是Prefork 模式，Apache總是試圖保持一些備用的(spare)或者是空閑的子進程（空閑的服務線程池）用於迎接即將到來的請求。這樣客戶端就不需要在得到服務前等候子進程的產生。
Event MPM：以上兩種穩定的MPM方式在非常繁忙的服務器應用下都有些不足。盡管HTTP的Keepalive方式能減少TCP連接數量和網絡負載，但是 Keepalive需要和服務進程或者線程綁定，這就導致一個繁忙的服務器會耗光所有的線程。 Event MPM是解決這個問題的一種新模型，它把服務進程從連接中分離出來。在服務器處理速度很快，同時具有非常高的點擊率時，可用的線程數量就是關鍵的資源限 制，此時Event MPM方式是最有效的。一個以Worker MPM方式工作的繁忙服務器能夠承受每秒好幾萬次的訪問量（例如在大型新聞服務站點的高峰時），而Event MPM可以用來處理更高負載。值得註意的是，Event MPM不能在安全HTTP（HTTPS）訪問下工作
apache 工作過程和模式