Web服務器

Web服務器也稱為WWW(WORLD WIDE WEB)服務器，主要功能是提供網(wǎng)上信息瀏覽服務。

我們提供的服務有：網(wǎng)站設計、成都做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、麻陽ssl等。為近千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的麻陽網(wǎng)站制作公司

• 應用層使用HTTP協(xié)議。
• HTML文檔格式。
• 瀏覽器統(tǒng)一資源定位器(URL)。

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

 ? ? ? ? ? ? ? GET /index.php HTTP/1.1
 +---------------+ ? ? +----------------+
 | ? ? ? ? ? ? ? +----> ? ? ? ? ? ? ? ? |
 | ? Browser ? ? | ? ? | ? Server ? ? ? |
 | ? ? ? ? ? ? ? <----+ ? ? ? ? ? ? ? ? |
 +---------------+ ? ? +----------------+
 ? ? ? ? ? ? ? HTTP/1.1 200 OK

• 瀏覽器向服務器發(fā)出HTTP請求(Request)。
• 服務器收到瀏覽器的請求數(shù)據(jù)，經(jīng)過分析處理，向瀏覽器輸出響應數(shù)據(jù)（Response）。
• 瀏覽器收到服務器的響應數(shù)據(jù)，經(jīng)過分析處理，將最終結果顯示在瀏覽器中。

Apache

概述

Apache HTTP Server是Apache軟件基金會的一個開放源代碼的網(wǎng)頁服務器，可以在大多數(shù)計算機操作系統(tǒng)中運行，由于其跨平臺和安全性。被廣泛使用，是最流行的Web服務器端軟件之一。它快速、可靠并且可通過簡單的API擴充，將Perl／Python等解釋器編譯到服務器中。

Apache組件

Apache是基于模塊化設計的，它的核心代碼并不多，大多數(shù)的功能都被分散到各個模塊中，各個模塊在系統(tǒng)啟動的時候按需載入。

 ? ? ? ? +----------+
 ? ? ?+- | Module ? | -----------------+
 ? ? ?| ?+----------+ ? ? ? ? ? ? ? ? ?|
 ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ?+------------+
+-----------+ ? Apache HTTPD ? ? | php module |
| Module ? ?| ? ? ? ? ? ? ? ? ? ?+------------+
+-----------+ ? ? ? ? ? ? ?+----------+|
 ? ? ?+----------+-------- | ?MPM ? ? |+
 ? ? ? ? ? ? ? ? | ? ? ? ? +----+---+-+
 ? ? ? ? ? ? ? +-v-----------+ ?| ? |
 ? ? ? ? ? ? ? | ? ?ARP ? ? ?<--+ ? |
 ? ? ? ? ? ? ? +------+------+ ? ? ?|
 ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? |
 ? ? ?+---------------v-------------v--+
 ? ? ?| ? ? ?Operating ?System ? ? ? ? |
 ? ? ?+--------------------------------+

MPM（Multi -Processing Modules，多重處理模塊）是Apache的核心組件之一，Apache通過MPM來使用操作系統(tǒng)的資源，對進程和線程池進行管理。Apache為了能夠獲得最好的運行性能，針對不同的平臺 (Unix/Linux、Window)做了優(yōu)化，為不同的平臺提供了不同的MPM，用戶可以根據(jù)實際情況進行選擇，其中最常使用的MPM有 prefork和worker兩種。至于您的服務器正以哪種方式運行，取決于安裝Apache過程中指定的MPM編譯參數(shù),在X系統(tǒng)上默認的編譯參數(shù)為 prefork。

由于大多數(shù)的Unix都不支持真正的線程，所以采用了預派生子進程(prefork)方式，象Windows或者Solaris這些支持 線程的平臺，基于多進程多線程混合的worker模式是一種不錯的選擇。Apache中還有一個重要的組件就是APR（Apache portable Runtime Library），即Apache可移植運行庫，它是一個對操作系統(tǒng)調(diào)用的抽象庫，用來實現(xiàn)Apache內(nèi)部組件對操作系統(tǒng)的使用，提高系統(tǒng)的可移植性。 Apache對于php的解析，就是通過眾多Module中的php Module來完成的。

Apache生命周期

 ? +--------------------------------------------------------------+
 ? | ? ? ? ? ? ? ? ? +---------------------+ ? ? ? 啟動階段 ? ? ? ?|
 ? | ? ? ? ? ? ? ? ? | ? ?系統(tǒng)啟動, 配置 ? ? | ? ? ? ? ? ? ? ? ? ? ?|
 ? | ? ? ? ? ? ? ? ? +----------+----------+ ? ? ? ? ? ? ? ? ? ? ?|
 ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
 ? | ? ? ? ? ? ? ? ? +----------v----------+ ? ? ? ? ? ? ? ? ? ? ?|
 ? | ? ? ? ? ? ? ? ? | ? ? ?模塊的初始化 ? ? | ? ? ? ? ? ? ? ? ? ? ?|
 ? | ? ? ? ? ? ? ? ? +-+--------+--------+-+ ? ? ? ? ? ? ? ? ? ? ?|
 ? | ? ? ? ? ? ? ? ? ? | ? ? ? ?| ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ?|
 ? | ? +-------------+ | +------v-------+| +--------------+ ? ? ? |
 ? | ? | 子進程初始化 ?|<+ | 子進程初始化 ? |+>| ?子進程初始化 ?| ? ? ? |
 ? | ? +------+------+ ? +-------+------+ ?+-------+------+ ? ? ? |
 ? +--------------------------------------------------------------+
 ? | ? ? ? ? ?| ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? | ? ? 運行階段 ?|
 ? | ? ? +----v----+ ? ? ? ?+----v----+ ? ? ? +----v----+ ? ? ? ? |
 ? | ? ? | 請求循環(huán) | ? ? ? ?| ?請求循環(huán) | ? ? ? | 請求循環(huán) | ? ? ? ? |
 ? | ? ? +----+----+ ? ? ? ?+----+----+ ? ? ? +----+----+ ? ? ? ? |
 ? | ? ? ? ? ?| ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ?|
 ? | ? +------v------+ ? ?+------v------+ ? +------v------+ ? ? ? |
 ? | ? | ?子進程結束 ? | ? ?| ?子進程結束 ?| ? | ? 子進程結束 ?| ? ? ? |
 ? | ? +-------------+ ? ?+-------------+ ? +-------------+ ? ? ? |
 ? +--------------------------------------------------------------+

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

Apache的工作模式

prefork的工作原理

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

worker的工作原理

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

Event MPM

這是Apache最新的工作模式，它和worker模式很像，不同的是在于它解決了keep-alive長連接的時候占用線程資源被浪費的問題，在event工作模式中，會有一些專門的線程用來管理這些keep-alive類型的線程，當有真實請求過來的時候，將請求傳遞給服務器的線程，執(zhí)行完畢后，又允許它釋放。這增強了在高并發(fā)場景下的請求處理。在*unix系統(tǒng)中的apache2.4版本使用的就是這個模式。

Apache的運行

啟動階段

在啟動階段，Apache主要進行配置文件解析(例如http.conf以及Include指令設定的配置文件等)、模塊加載(例如mod_php.so,mod_perl.so等)和系統(tǒng)資源初始化（例如日志文件、共享內(nèi)存段等）工作。在這個階段，Apache為了獲得系統(tǒng)資源最大的使用權限，將以特權用戶root（X系統(tǒng)）或超級管理員administrator(Windows系統(tǒng))完成啟動。

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

 ? ? ? +--------+
 ? ? ? | ?開始 ? |
 ? ? ? +----+---+
 ? ? ? ? ? ?|
 +----------v------------+ ? 解析主配置文件http.conf中配置信息，
 | ? ? 解析配置文件 ? ? ? ?| ? 像LoadModule, AddType
 +----------+------------+ ? 等指令被加載至內(nèi)存
 ? ? ? ? ? ?|
 +----------v------------+ ? 依據(jù)AddModule, LoadModule等指令
 | ? 加載靜態(tài)/動態(tài)模塊 ? ? ?| ? 加載Apache模塊，像mod_php5.so被
 +----------+------------+ ? 加載至內(nèi)存，映射到Apache地址空間。
 ? ? ? ? ? ?|
 +----------v------------+ ? 日志文件、共享內(nèi)存段，數(shù)據(jù)庫鏈接
 | ? ? 系統(tǒng)資源初始化 ? ? ?| ? ?等初始化
 +----------+------------+
 ? ? ? ? ? ?|
 ? ? ? ?+---v----+
 ? ? ? ?| ?結束 ? |
 ? ? ? ?+--------+

運行階段

在運行階段，Apache主要工作是處理用戶的服務請求。在這個階段，Apache放棄特權用戶級別，使用普通權限，這主要是基于安全性的考慮，防止由于代碼的缺陷引起的安全漏洞。

由于Apache的Hook機制，Apache 允許模塊(包括內(nèi)部模塊和外部模塊，例如mod_php5.so,mod_perl.so等)將自定義的函數(shù)注入到請求處理循環(huán)中。mod_php5.so/php5apache2.dll就是將所包含的自定義函數(shù)，通過Hook機制注入到Apache中，在Apache處理流程的各個階段負責處理php請求。

Apache將請求處理循環(huán)分為11個階段，依次是：Post-Read-Request，URI Translation，Header Parsing，Access Control，Authentication，Authorization，MIME Type Checking，F(xiàn)ixUp，Response，Logging，CleanUp。

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

Apache處理http請求的生命周期

1. Post-Read-Request階段:在正常請求處理流程中，這是模塊可以插入鉤子的第一個階段。對于那些想很早進入處理請求的模塊來說，這個階段可以被利用。
2. URI Translation階段 : Apache在本階段的主要工作：將請求的URL映射到本地文件系統(tǒng)。模塊可以在這階段插入鉤子，執(zhí)行自己的映射邏輯。mod_alias就是利用這個階段工作的。
3. Header Parsing階段 : Apache在本階段的主要工作：檢查請求的頭部。由于模塊可以在請求處理流程的任何一個點上執(zhí)行檢查請求頭部的任務，因此這個鉤子很少被使用。mod_setenvif就是利用這個階段工作的。
4. Access Control階段 : Apache在本階段的主要工作：根據(jù)配置文件檢查是否允許訪問請求的資源。Apache的標準邏輯實現(xiàn)了允許和拒絕指令。mod_authz_host就是利用這個階段工作的。
5. Authentication階段 : Apache在本階段的主要工作：按照配置文件設定的策略對用戶進行認證，并設定用戶名區(qū)域。模塊可以在這階段插入鉤子，實現(xiàn)一個認證方法。
6. Authorization階段 : Apache在本階段的主要工作：根據(jù)配置文件檢查是否允許認證過的用戶執(zhí)行請求的操作。模塊可以在這階段插入鉤子，實現(xiàn)一個用戶權限管理的方法。
7. MIME Type Checking階段 : Apache在本階段的主要工作：根據(jù)請求資源的MIME類型的相關規(guī)則，判定將要使用的內(nèi)容處理函數(shù)。標準模塊mod_negotiation和mod_mime實現(xiàn)了這個鉤子。
8. FixUp階段 : 這是一個通用的階段，允許模塊在內(nèi)容生成器之前，運行任何必要的處理流程。和Post_Read_Request類似，這是一個能夠捕獲任何信息的鉤子，也是最常使用的鉤子。
9. Response階段 : Apache在本階段的主要工作：生成返回客戶端的內(nèi)容，負責給客戶端發(fā)送一個恰當?shù)幕貜?。這個階段是整個處理流程的核心部分。
10. Logging階段 : Apache在本階段的主要工作：在回復已經(jīng)發(fā)送給客戶端之后記錄事務。模塊可能修改或者替換Apache的標準日志記錄。
11. CleanUp階段 : Apache在本階段的主要工作：清理本次請求事務處理完成之后遺留的環(huán)境，比如文件、目錄的處理或者Socket的關閉等等，這是Apache一次請求處理的最后一個階段。

Nginx

概述

Nginx（發(fā)音同engine x）是一款由俄羅斯程序員Igor Sysoev所開發(fā)輕量級的網(wǎng)頁服務器、反向代理服務器以及電子郵件（IMAP/POP3）代理服務器。起初是供俄國大型的門戶網(wǎng)站及搜索引擎Rambler（俄語：Рамблер）使用。

Nginx的模塊與工作原理

Nginx由內(nèi)核和模塊組成，其中，內(nèi)核的設計非常微小和簡潔，完成的工作也非常簡單，僅僅通過查找配置文件將客戶端請求映射到一個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（處理器模塊）。此類模塊直接處理請求，并進行輸出內(nèi)容和修改headers信息等操作。Handlers處理器模塊一般只能有一個。
• Filters （過濾器模塊）。此類模塊主要對其他處理器模塊輸出的內(nèi)容進行修改操作，最后由Nginx輸出。
• Proxies （代理類模塊）。此類模塊是Nginx的HTTP Upstream之類的模塊，這些模塊主要與后端一些服務比如FastCGI等進行交互，實現(xiàn)服務代理和負載均衡等功能。

 ? ? ? ? ? ? ? ? ? ? + ? ? ? ? ? ? ? ? ? ?^
 ? ? ? ?Http Request | ? ? ? ? ? ? ? ? ? ?| ?Http Response
 ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ?|
 ? ?+---------+------v-----+ ? ? ? ? +----+----+
 ? ?| ?Conf ? | Nginx Core | ? ? ? ? | FilterN |
 ? ?+---------+------+-----+ ? ? ? ? +----^----+
 ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ?|
 ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? +----+----+
 ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? | Filter2 |
choose a handler ? ? | ? ? ? ? ? ? ? +----^----+
based conf ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ?|
 ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? +----+----+
 ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? | Filter1 |
 ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? +----^----+
 ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ?| Generate content
 ? ? ? ? ? ? ? +-----v--------------------+----+
 ? ? ? ? ? ? ? | ? ? ? ? ? Handler ? ? ? ? ? ? |
 ? ? ? ? ? ? ? +-------------------------------+

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

Nginx架構及工作流程

Nginx架構

上圖是Nginx的架構，這個架構類似于Apache的Worker工作狀態(tài)，Nginx的每一個Worker進程都管理著大量的線程，真正處理請求的是Worker之下的線程。

所有實際上的業(yè)務處理邏輯都在worker進程。worker進程中有一個函數(shù)，執(zhí)行無限循環(huán)，不斷處理收到的來自客戶端的請求，并進行處理，直到整個nginx服務被停止。Worker中這個函數(shù)執(zhí)行內(nèi)容如下：

• 操作系統(tǒng)提供的機制（例如epoll, kqueue等）產(chǎn)生相關的事件。
• 接收和處理這些事件，如是接受到數(shù)據(jù)，則產(chǎn)生更高層的request對象。
• 處理request的header和body。
• 產(chǎn)生響應，并發(fā)送回客戶端。
• 完成request的處理。
• 重新初始化定時器及其他事件。

Nginx和FastCGI

FastCGI

FastCGI是一個可伸縮地、高速地在HTTP server和動態(tài)腳本語言間通信的接口。多數(shù)流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等。同時，F(xiàn)astCGI也被許多腳本語言支持，其中就有PHP。

FastCGI是從CGI發(fā)展改進而來的。傳統(tǒng)CGI接口方式的主要缺點是性能很差，因為每次HTTP服務器遇到動態(tài)程序時都需要重新啟動腳本解析器來執(zhí)行解析，然后將結果返回給HTTP服務器。這在處理高并發(fā)訪問時幾乎是不可用的。另外傳統(tǒng)的CGI接口方式安全性也很差，現(xiàn)在已經(jīng)很少使用了。

FastCGI接口方式采用C/S結構，可以將HTTP服務器和腳本解析服務器分開，同時在腳本解析服務器上啟動一個或者多個腳本解析守護進程。當HTTP服務器每次遇到動態(tài)程序時，可以將其直接交付給FastCGI進程來執(zhí)行，然后將得到的結果返回給瀏覽器。這種方式可以讓HTTP服務器專一地處理靜態(tài)請求或者將動態(tài)腳本服務器的結果返回給客戶端，這在很大程度上提高了整個應用系統(tǒng)的性能。

Nging和FastCGI合作

Nginx不支持對外部程序的直接調(diào)用或者解析，所有的外部程序（包括PHP）必須通過FastCGI接口來調(diào)用。FastCGI接口在Linux下是socket（這個socket可以是文件socket，也可以是ip socket）。

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

• FastCGI進程管理器php-fpm自身初始化，啟動主進程php-fpm和啟動start_servers個CGI 子進程。主進程php-fpm主要是管理fastcgi子進程，監(jiān)聽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環(huán)境變量和標準輸入發(fā)送到FastCGI子進程。
• FastCGI子進程完成處理后將標準輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關閉連接時，請求便告處理完成。
• FastCGI子進程接著等待并處理來自FastCGI進程管理器（運行在 WebServer中）的下一個連接。

Apache和Nginx比較

功能對比

Nginx和Apache一樣，都是HTTP服務器軟件，在功能實現(xiàn)上都采用模塊化結構設計，都支持通用的語言接口，如PHP、Perl、Python等，同時還支持正向和反向代理、虛擬主機、URL重寫、壓縮傳輸、SSL加密傳輸?shù)取?/p>

• 在功能實現(xiàn)上，Apache的所有模塊都支持動、靜態(tài)編譯，而Nginx模塊都是靜態(tài)編譯的，
• 對FastCGI的支持，Apache對Fcgi的支持不好，而Nginx對Fcgi的支持非常好；
• 在處理連接方式上，Nginx支持epoll，而Apache卻不支持；
• 在空間使用上，Nginx安裝包僅僅只有幾百K，和Nginx比起來Apache絕對是龐然大物。

Nginx相對apache的優(yōu)點

• 輕量級，同樣起web 服務，比apache 占用更少的內(nèi)存及資源
• 靜態(tài)處理，Nginx 靜態(tài)處理性能比 Apache 高 3倍以上
• 抗并發(fā)，nginx 處理請求是異步非阻塞的，而apache則是阻塞型的，在高并發(fā)下nginx 能保持低資源低消耗高性能。在- - Apache+PHP（prefork）模式下，如果PHP處理慢或者前端壓力很大的情況下，很容易出現(xiàn)Apache進程數(shù)飆升，從而拒絕服務的現(xiàn)象。
• 高度模塊化的設計，編寫模塊相對簡單
• 社區(qū)活躍，各種高性能模塊出品迅速啊

apache相對nginx的優(yōu)點

• rewrite，比nginx 的rewrite 強大
• 模塊超多，基本想到的都可以找到
• 少bug，nginx的bug相對較多
• 超穩(wěn)定
• Apache對PHP支持比較簡單，Nginx需要配合其他后端用

選擇Nginx的優(yōu)勢所在

• 作為Web服務器: Nginx處理靜態(tài)文件、索引文件，自動索引的效率非常高。
• 作為代理服務器，Nginx可以實現(xiàn)無緩存的反向代理加速，提高網(wǎng)站運行速度。
• 作為負載均衡服務器，Nginx既可以在內(nèi)部直接支持Rails和PHP，也可以支持HTTP代理服務器對外進行服務，同時還支持簡單的容錯和利用算法進行負載均衡。
• 在性能方面，Nginx是專門為性能優(yōu)化而開發(fā)的，在實現(xiàn)上非常注重效率。它采用內(nèi)核Poll模型(epoll and kqueue )，可以支持更多的并發(fā)連接，最大可以支持對50 000個并發(fā)連接數(shù)的響應，而且只占用很低的內(nèi)存資源。
• 在穩(wěn)定性方面，Nginx采取了分階段資源分配技術，使得CPU與內(nèi)存的占用率非常低。Nginx官方表示，Nginx保持10 000個沒有活動的連接，而這些連接只占用2.5MB內(nèi)存，因此，類似DOS這樣的攻擊對Nginx來說基本上是沒有任何作用的。
• 在高可用性方面，Nginx支持熱部署，啟動速度特別迅速，因此可以在不間斷服務的情況下，對軟件版本或者配置進行升級，即使運行數(shù)月也無需重新啟動，幾乎可以做到7×24小時不間斷地運行。

同時使用Nginx和Apache

由于Nginx和Apache各自的優(yōu)勢，現(xiàn)在很多人選擇了讓兩者在服務器中共存。在服務器端讓Nginx在前，Apache在后。由Nginx做負載均衡和反向代理，并且處理靜態(tài)文件，將動態(tài)請求（如PHP應用）交給Apache去處理。