Apache VS Nginx，哪個適合你？你選對了嗎？

Apache VS Nginx，你選對了嗎？

文章來源：企鵝號 - 民工哥Linux運維

有趣有內涵的文章第一時間送達！

Apache和Nginx都屬於Web伺服器，兩者都實現了HTTP 1.1協議。無論是選擇哪個，都是根據應用場景來決定的，所以些檔案僅從應用場景出發，來對比兩者之間的各自特點。要讓正確的工具，做出正確的事。Web伺服器

Web伺服器也稱為WWW(WORLD WIDE WEB)伺服器，主要功能是提供網上資訊瀏覽服務。

應用層使用HTTP協議。

HTML文件格式。

瀏覽器統一資源定位器(URL)。

Web伺服器常常以B/S（Browser/Server）方式提供服務。瀏覽器和伺服器的互動方式如下：

瀏覽器向伺服器發出HTTP請求(Request)。

伺服器收到瀏覽器的請求資料，經過分析處理，向瀏覽器輸出響應資料（Response）。

瀏覽器收到伺服器的響應資料，經過分析處理，將最終結果顯示在瀏覽器中。

Apache

概述

Apache HTTP Server是Apache軟體基金會的一個開放原始碼的網頁伺服器，可以在大多數計算機作業系統中執行，由於其跨平臺和安全性。被廣泛使用，是最流行的Web伺服器端軟體之一。它快速、可靠並且可通過簡單的API擴充，將Perl／Python等直譯器編譯到伺服器中。

Apache元件

Apache是基於模組化設計的，它的核心程式碼並不多，大多數的功能都被分散到各個模組中，各個模組在系統啟動的時候按需載入。

MPM（Multi -Processing Modules，多重處理模組）是Apache的核心元件之一，Apache通過MPM來使用作業系統的資源，對程序和執行緒池進行管理。Apache為了能夠獲得最好的執行效能，針對不同的平臺 (Unix/Linux、Window)做了優化，為不同的平臺提供了不同的MPM，使用者可以根據實際情況進行選擇，其中最常使用的MPM有 prefork和worker兩種。至於您的伺服器正以哪種方式執行，取決於安裝Apache過程中指定的MPM編譯引數,在X系統上預設的編譯引數為 prefork。

由於大多數的Unix都不支援真正的執行緒，所以採用了預派生子程序(prefork)方式，象Windows或者Solaris這些支援 執行緒的平臺，基於多程序多執行緒混合的worker模式是一種不錯的選擇。Apache中還有一個重要的元件就是APR（Apache portable Runtime Library），即Apache可移植執行庫，它是一個對作業系統呼叫的抽象庫，用來實現Apache內部元件對作業系統的使用，提高系統的可移植性。 Apache對於php的解析，就是通過眾多Module中的php Module來完成的。

Apache生命週期

這個生命週期是在perfork工作下的示意，從圖中可以看出，Apache對於每一個請求都要啟動一個單獨的程序來處理。

Apache的工作模式

prefork的工作原理

一個單獨的控制程序(父程序)負責產生子程序，這些子程序用於監聽請求並作出應答。Apache總是試圖保持一些備用的 (spare)或是空閑的子程序用於迎接即將到來的請求。這樣客戶端就無需在得到服務前等候子程序的產生。在Unix系統中，父程序通常以root身份執行以便邦定80埠，而 Apache產生的子程序通常以一個低特權的使用者執行。User和Group指令用於配置子程序的低特權使用者。執行子程序的使用者必須要對他所服務的內容有讀取的許可權，但是對服務內容之外的其他資源必須擁有儘可能少的許可權。

worker的工作原理

每個程序能夠擁有的執行緒數量是固定的。伺服器會根據負載情況增加或減少程序數量。一個單獨的控制程序(父程序)負責子程序的建立。每個子程序能夠建立ThreadsPerChild數量的服務執行緒和一個監聽執行緒，該監聽執行緒監聽接入請求並將其傳遞給服務執行緒處理和應答。Apache總是試圖維持一個備用(spare)或是空閑的服務執行緒池。這樣，客戶端無須等待新執行緒或新程序的建立即可得到處理。在Unix中，為了能夠繫結80埠，父程序一般都是以root身份啟動，隨後，Apache以較低許可權的使用者建立子程序和執行緒。User和Group指令用於配置Apache子程序的許可權。雖然子程序必須對其提供的內容擁有讀許可權，但應該儘可能給予他較少的特權。另外，除非使用了suexec ，否則，這些指令配置的許可權將被CGI指令碼所繼承。

Event MPM

這是Apache最新的工作模式，它和worker模式很像，不同的是在於它解決了keep-alive長連線的時候佔用執行緒資源被浪費的問題，在event工作模式中，會有一些專門的執行緒用來管理這些keep-alive型別的執行緒，當有真實請求過來的時候，將請求傳遞給伺服器的執行緒，執行完畢後，又允許它釋放。這增強了在高併發場景下的請求處理。在*unix系統中的apache2.4版本使用的就是這個模式。

Apache的執行

啟動階段

在啟動階段，Apache主要進行配置檔案解析(例如http.conf以及Include指令設定的配置檔案等)、模組載入(例如mod_php.so,mod_perl.so等)和系統資源初始化（例如日誌檔案、共享記憶體段等）工作。在這個階段，Apache為了獲得系統資源最大的使用許可權，將以特權使用者root（X系統）或超級管理員administrator(Windows系統)完成啟動。

這個過程可以通過下圖來深入瞭解：

執行階段

在執行階段，Apache主要工作是處理使用者的服務請求。在這個階段，Apache放棄特權使用者級別，使用普通許可權，這主要是基於安全性的考慮，防止由於程式碼的缺陷引起的安全漏洞。

由於Apache的Hook機制，Apache 允許模組(包括內部模組和外部模組，例如mod_php5.so,mod_perl.so等)將自定義的函式注入到請求處理迴圈中。mod_php5.so/php5apache2.dll就是將所包含的自定義函式，通過Hook機制注入到Apache中，在Apache處理流程的各個階段負責處理php請求。

Apache將請求處理迴圈分為11個階段，依次是：Post-Read-Request，URI Translation，Header Parsing，Access Control，Authentication，Authorization，MIME Type Checking，FixUp，Response，Logging，CleanUp。

Apache處理http請求的生命週期:

Apache處理http請求的生命週期

Post-Read-Request階段:在正常請求處理流程中，這是模組可以插入鉤子的第一個階段。對於那些想很早進入處理請求的模組來說，這個階段可以被利用。

URI Translation階段 : Apache在本階段的主要工作：將請求的URL對映到本地檔案系統。模組可以在這階段插入鉤子，執行自己的對映邏輯。mod_alias就是利用這個階段工作的。

Header Parsing階段 : Apache在本階段的主要工作：檢查請求的頭部。由於模組可以在請求處理流程的任何一個點上執行檢查請求頭部的任務，因此這個鉤子很少被使用。mod_setenvif就是利用這個階段工作的。

Access Control階段 : Apache在本階段的主要工作：根據配置檔案檢查是否允許訪問請求的資源。Apache的標準邏輯實現了允許和拒絕指令。mod_authz_host就是利用這個階段工作的。

Authentication階段 : Apache在本階段的主要工作：按照配置檔案設定的策略對使用者進行認證，並設定使用者名稱區域。模組可以在這階段插入鉤子，實現一個認證方法。

Authorization階段 : Apache在本階段的主要工作：根據配置檔案檢查是否允許認證過的使用者執行請求的操作。模組可以在這階段插入鉤子，實現一個使用者許可權管理的方法。

MIME Type Checking階段 : Apache在本階段的主要工作：根據請求資源的MIME型別的相關規則，判定將要使用的內容處理函式。標準模組mod_negotiation和mod_mime實現了這個鉤子。

FixUp階段 : 這是一個通用的階段，允許模組在內容生成器之前，執行任何必要的處理流程。和Post_Read_Request類似，這是一個能夠捕獲任何資訊的鉤子，也是最常使用的鉤子。

Response階段 : Apache在本階段的主要工作：生成返回客戶端的內容，負責給客戶端傳送一個恰當的回復。這個階段是整個處理流程的核心部分。

Logging階段 : Apache在本階段的主要工作：在回復已經傳送給客戶端之後記錄事務。模組可能修改或者替換Apache的標準日誌記錄。

CleanUp階段 : Apache在本階段的主要工作：清理本次請求事務處理完成之後遺留的環境，比如檔案、目錄的處理或者Socket的關閉等等，這是Apache一次請求處理的最後一個階段。

Nginx

概述

Nginx（發音同engine x）是一款由俄羅斯程式設計師Igor Sysoev所開發輕量級的網頁伺服器、反向代理伺服器以及電子郵件（IMAP/POP3）代理伺服器。起初是供俄國大型的入口網站及搜尋引擎Rambler（俄語：Рамблер）使用。

Nginx的模組與工作原理

Nginx由內核和模組組成，其中，內核的設計非常微小和簡潔，完成的工作也非常簡單，僅僅通過查詢配置檔案將客戶端請求對映到一個location block（location是Nginx配置中的一個指令，用於URL匹配），而在這個location中所配置的每個指令將會啟動不同的模組去完成相應的工作。

Nginx的模組從結構上分為核心模組、基礎模組和第三方模組：

核心模組：HTTP模組、EVENT模組和MAIL模組

基礎模組：HTTP Access模組、HTTP FastCGI模組、HTTP Proxy模組和HTTP Rewrite模組，

第三方模組：HTTP Upstream Request Hash模組、Notice模組和HTTP Access Key模組。

Nginx的模組從功能上分為如下三類:

Handlers（處理器模組）。此類模組直接處理請求，並進行輸出內容和修改headers資訊等操作。Handlers處理器模組一般只能有一個。

Filters （過濾器模組）。此類模組主要對其他處理器模組輸出的內容進行修改操作，最後由Nginx輸出。

Proxies （代理類模組）。此類模組是Nginx的HTTP Upstream之類的模組，這些模組主要與後端一些服務比如FastCGI等進行互動，實現服務代理和負載均衡等功能。

Nginx本身做的工作實際很少，當它接到一個HTTP請求時，它僅僅是通過查詢配置檔案將此次請求對映到一個location block，而此location中所配置的各個指令則會啟動不同的模組去完成工作，因此模組可以看做Nginx真正的勞動工作者。通常一個location中的指令會涉及一個handler模組和多個filter模組（當然，多個location可以復用同一個模組）。handler模組負責處理請求，完成響應內容的生成，而filter模組對響應內容進行處理。

Nginx架構及工作流程

Nginx架構

上圖是Nginx的架構，這個架構類似於Apache的Worker工作狀態，Nginx的每一個Worker程序都管理著大量的執行緒，真正處理請求的是Worker之下的執行緒。

所有實際上的業務處理邏輯都在worker程序。worker程序中有一個函式，執行無限迴圈，不斷處理收到的來自客戶端的請求，並進行處理，直到整個nginx服務被停止。Worker中這個函式執行內容如下：

作業系統提供的機制（例如epoll, kqueue等）產生相關的事件。

接收和處理這些事件，如是接受到資料，則產生更高層的request物件。

處理request的header和body。

產生響應，併發送回客戶端。

完成request的處理。

重新初始化定時器及其他事件。

Nginx和FastCGI

FastCGI

FastCGI是一個可伸縮地、高速地在HTTP server和動態指令碼語言間通訊的介面。多數流行的HTTP server都支援FastCGI，包括Apache、Nginx和lighttpd等。同時，FastCGI也被許多指令碼語言支援，其中就有PHP。

FastCGI是從CGI發展改進而來的。傳統CGI介面方式的主要缺點是效能很差，因為每次HTTP伺服器遇到動態程式時都需要重新啟動指令碼解析器來執行解析，然後將結果返回給HTTP伺服器。這在處理高併發訪問時幾乎是不可用的。另外傳統的CGI介面方式安全性也很差，現在已經很少使用了。

FastCGI介面方式採用C/S結構，可以將HTTP伺服器和指令碼解析伺服器分開，同時在指令碼解析伺服器上啟動一個或者多個指令碼解析守護程序。當HTTP伺服器每次遇到動態程式時，可以將其直接交付給FastCGI程序來執行，然後將得到的結果返回給瀏覽器。這種方式可以讓HTTP伺服器專一地處理靜態請求或者將動態指令碼伺服器的結果返回給客戶端，這在很大程度上提高了整個應用系統的效能。

Nging和FastCGI合作

Nginx不支援對外部程式的直接呼叫或者解析，所有的外部程式（包括PHP）必須通過FastCGI介面來呼叫。FastCGI介面在Linux下是socket（這個socket可以是檔案socket，也可以是ip socket）。

接下來以Nginx下PHP的執行過程來說明。PHP-FPM是管理FastCGI的一個管理器，它作為PHP的外掛存在。

FastCGI程序管理器php-fpm自身初始化，啟動主程序php-fpm和啟動start_servers個CGI 子程序。主程序php-fpm主要是管理fastcgi子程序，監聽9000埠。fastcgi子程序等待來自Web Server的連線。

當客戶端請求到達Web Server Nginx是時，Nginx通過location指令，將所有以php為字尾的檔案都交給127.0.0.1:9000來處理，即Nginx通過location指令，將所有以php為字尾的檔案都交給127.0.0.1:9000來處理。

FastCGI程序管理器PHP-FPM選擇並連線到一個子程序CGI直譯器。Web server將CGI環境變數和標準輸入傳送到FastCGI子程序。

FastCGI子程序完成處理後將標準輸出和錯誤資訊從同一連線返回Web Server。當FastCGI子程序關閉連線時，請求便告處理完成。

FastCGI子程序接著等待並處理來自FastCGI程序管理器（執行在 WebServer中）的下一個連線。

Apache和Nginx比較

功能對比

Nginx和Apache一樣，都是HTTP伺服器軟體，在功能實現上都採用模組化結構設計，都支援通用的語言介面，如PHP、Perl、Python等，同時還支援正向和反向代理、虛擬主機、URL重寫、壓縮傳輸、SSL加密傳輸等。

在功能實現上，Apache的所有模組都支援動、靜態編譯，而Nginx模組都是靜態編譯的，

對FastCGI的支援，Apache對Fcgi的支援不好，而Nginx對Fcgi的支援非常好；

在處理連線方式上，Nginx支援epoll，而Apache卻不支援；

在空間使用上，Nginx安裝包僅僅只有幾百K，和Nginx比起來Apache絕對是龐然大物。

Nginx相對apache的優點

輕量級，同樣起web 服務，比apache 佔用更少的記憶體及資源

靜態處理，Nginx 靜態處理效能比 Apache 高 3倍以上

抗併發，nginx 處理請求是非同步非阻塞的，而apache則是阻塞型的，在高併發下nginx 能保持低資源低消耗高效能。在- - Apache+PHP（prefork）模式下，如果PHP處理慢或者前端壓力很大的情況下，很容易出現Apache程序數飆升，從而拒絕服務的現象。

高度模組化的設計，編寫模組相對簡單

社群活躍，各種高效能模組出品迅速啊

apache相對nginx的優點

rewrite，比nginx 的rewrite 強大

模組超多，基本想到的都可以找到

少bug，nginx的bug相對較多

超穩定

Apache對PHP支援比較簡單，Nginx需要配合其他後端用

選擇Nginx的優勢所在

作為Web伺服器: Nginx處理靜態檔案、索引檔案，自動索引的效率非常高。

作為代理伺服器，Nginx可以實現無快取的反向代理加速，提高網站執行速度。

作為負載均衡伺服器，Nginx既可以在內部直接支援Rails和PHP，也可以支援HTTP代理伺服器對外進行服務，同時還支援簡單的容錯和利用演演算法進行負載均衡。

在效能方面，Nginx是專門為效能優化而開發的，在實現上非常注重效率。它採用核心Poll模型(epoll and kqueue )，可以支援更多的併發連線，最大可以支援對50 000個併發連線數的響應，而且只佔用很低的記憶體資源。

在穩定性方面，Nginx採取了分階段資源分配技術，使得CPU與記憶體的佔用率非常低。Nginx官方表示，Nginx保持10 000個沒有活動的連線，而這些連線只佔用2.5MB記憶體，因此，類似DOS這樣的攻擊對Nginx來說基本上是沒有任何作用的。

在高可用性方面，Nginx支援熱部署，啟動速度特別迅速，因此可以在不間斷服務的情況下，對軟體版本或者配置進行升級，即使執行數月也無需重新啟動，幾乎可以做到7×24小時不間斷地執行。

同時使用Nginx和Apache

由於Nginx和Apache各自的優勢，現在很多人選擇了讓兩者在伺服器中共存。在伺服器端讓Nginx在前，Apache在後。由Nginx做負載均衡和反向代理，並且處理靜態檔案，講動態請求（如PHP應用）交給Apache去處理。