## 簡介
**Nginx是一個跨平臺的Web服務器,可運行在Linux、FreeBSD、Solaris、AIX、Mac OS、 Windows等操作系統上**,并且它還可以使用當前操作系統特有的一些高效API來提高自己的性能
* 例如,對于高效處理大規模并發連接,**它支持Linux上的epoll**(epoll是Linux上處理大并 發網絡連接的利器)、Solaris上的event ports和 FreeBSD上的kqueue等
* 又如,對于Linux,**Nginx支持其獨有的sendfile系統調用**,這個系統調用可以高效地把硬 盤中的數據發送到網絡上(不需要先把硬盤數據復制到用戶態內存上再發送),這極大地減少了內核態與用戶態數據間的復制動作
* 種種跡象都表明,**Nginx以性能為王**
* **Nginx的參考手冊,在里面對每個模塊都有介紹:**[http://nginx.org/en/docs/](http://nginx.org/en/docs/)
## 使用場景
1. 高性能的靜態web服務器;
2. 反向代理(將請求轉發到動態服務器);
3. 負載均衡;
## 與其他服務器的對比
* **來看看Nginx的競爭對手——Apache、Lighttpd、Tomcat、 Jetty、IIS**。它們都是Web服務器,或者叫做WWW(World Wide Web)服務器,相應地也都具備Web服務器的基本功能:基于REST架構風格,以統一資源描述符(URI)或者統一資源定位符(URL)作為溝通依據,通過HTTP為瀏覽器等客戶端程序提供各種網絡服務
* **由于這些Web服務器在設計階段就受到許多局限,**例如當時的互聯網用戶規模、網絡帶寬、產品特點等局限,并且各自的定位與發展方向都不盡相同,**使得每一款Web服務器的特點與應用場合都很鮮明:**
* **Tomcat和Jetty面向Java語言**,先天就是重量級的Web服務器,它的性能與Nginx沒有可比性,這里略過
* **IIS只能在Windows操作系統上運行**。Windows作為服務器在穩定性與其他一些性能上都 不如類UNIX操作系統,因此,在需要高性能Web服務器的場合下,IIS可能會被“冷落”
* **Apache的發展時期很長**,而且是目前毫無爭議的世界第一大Web服務器。
* Apache有許多優點,如穩定、開源、跨平臺等,但它出現的時間太長了,在它興起的年代,互聯網的產業規模遠遠比不上今天,所以它被設計成了一個重量級的、不支持高并發的 Web服務器。在Apache服務器上,如果有數以萬計的并發HTTP請求同時訪問,就會導致服 務器上消耗大量內存,**操作系統內核對成百上千的Apache進程做進程間切換也會消耗大量 CPU資源,并導致HTTP請求的平均響應速度降低,這些都決定了Apache不可能成為高性能 Web服務器,這也促使了Lighttpd和Nginx的出現**
* **Lighttpd和Nginx一樣,都是輕量級、高性能的Web服務器**,歐美的業界開發者比較鐘愛Lighttpd,而國內的公司更青睞Nginx,Lighttpd使用得比較少;
## Nginx的特點
> ### ①更快
>
> * 這表現在兩個方面:一方面,在正常情況下,單次請求會得到更快的響應
> * 另一方面, 在高峰期(如有數以萬計的并發請求),Nginx可以比其他Web服務器更快地響應請求
> ### ②高擴展性
>
> * Nginx的設計極具擴展性,它完全是由多個不同功能、不同層次、不同類型且耦合度極 低的模塊組成。因此,當對某一個模塊修復Bug或進行升級時,可以專注于模塊自身,無須 在意其他。而且在HTTP模塊中,還設計了HTTP過濾器模塊:一個正常的HTTP模塊在處理 完請求后,會有一串HTTP過濾器模塊對請求的結果進行再處理。這樣,當我們開發一個新 的HTTP模塊時,不但可以使用諸如HTTP核心模塊、events模塊、log模塊等不同層次或者不 同類型的模塊,還可以原封不動地復用大量已有的HTTP過濾器模塊。這種低耦合度的優秀 設計,造就了Nginx龐大的第三方模塊,當然,公開的第三方模塊也如官方發布的模塊一樣 容易使用
> * Nginx的模塊都是嵌入到二進制文件中執行的,無論官方發布的模塊還是第三方模塊都 是如此。這使得第三方模塊一樣具備極其優秀的性能,充分利用Nginx的高并發特性,因 此,許多高流量的網站都傾向于開發符合自己業務特性的定制模塊。
> ### ③高可靠性
>
> * 高可靠性是我們選擇Nginx的最基本條件,因為Nginx的可靠性是大家有目共睹的,很多 家高流量網站都在核心服務器上大規模使用Nginx。Nginx的高可靠性來自于其核心框架代碼 的優秀設計、模塊設計的簡單性;另外,官方提供的常用模塊都非常穩定,每個worker進程 相對獨立,master進程在1個worker進程出錯時可以快速“拉起”新的worker子進程提供服務
> ### ④低內存消耗
>
> * 一般情況下,10000個非活躍的HTTP Keep-Alive連接在Nginx中僅消耗2.5MB的內存,這 是Nginx支持高并發連接的基礎
> ### ⑤單機支持10萬以上的并發連接
>
> * 這是一個非常重要的特性!隨著互聯網的迅猛發展和互聯網用戶數量的成倍增長,各大 公司、網站都需要應付海量并發請求,一個能夠在峰值期頂住10萬以上并發請求的Server, 無疑會得到大家的青睞。理論上,Nginx支持的并發連接上限取決于內存,10萬遠未封頂。 當然,能夠及時地處理更多的并發請求,是與業務特點緊密相關的
> ### ⑥熱部署
>
> * master管理進程與worker工作進程的分離設計,使得Nginx能夠提供熱部署功能,即可以 在7×24小時不間斷服務的前提下,升級Nginx的可執行文件。當然,它也支持不停止服務就 更新配置項、更換日志文件等功能
> ### ⑦最自由的BSD許可協議
>
> * 這是Nginx可以快速發展的強大動力。BSD許可協議不只是允許用戶免費使用Nginx,它 還允許用戶在自己的項目中直接使用或修改Nginx源碼,然后發布。這吸引了無數開發者繼 續為Nginx貢獻自己的智慧
* 以上7個特點當然不是Nginx的全部,擁有無數個官方功能模塊、第三方功能模塊使得 Nginx能夠滿足絕大部分應用場景,這些功能模塊間可以疊加以實現更加強大、復雜的功 能,有些模塊還支持Nginx與Perl、Lua等腳本語言集成工作,大大提高了開發效率。這些特 點促使用戶在尋找一個Web服務器時更多考慮Nginx;
## 總結
* 當然,選擇Nginx的核心理由還是它能在支持高并發請求的同時保持高效的服務。
* 如果Web服務器的業務訪問量巨大,就需要保證在數以百萬計的請求同時訪問服務時, 用戶可以獲得良好的體驗,不會出現并發訪問量達到一個數字后,新的用戶無法獲取服務, 或者雖然成功地建立起了TCP連接,但大部分請求卻得不到響應的情況
* 通常,高峰期服務器的訪問量可能是正常情況下的許多倍,若有熱點事件的發生,可能 會導致正常情況下非常順暢的服務器直接“掛死”。然而,如果在部署服務器時,就預先針對 這種情況進行擴容,又會使得正常情況下所有服務器的負載過低,這會造成大量的資源浪 費。因此,我們會希望在這之間取得平衡,也就是說,在低并發壓力下,用戶可以獲得高速 體驗,而在高并發壓力下,更多的用戶都能接入,可能訪問速度會下降,但這只應受制于帶 寬和處理器的速度,而不應該是服務器設計導致的軟件瓶頸
* 事實上,由于中國互聯網用戶群體的數量巨大,致使對Web服務器的設計往往要比歐美 公司更加困難。例如,對于全球性的一些網站而言,歐美用戶分布在兩個半球,歐洲用戶活 躍時,美洲用戶通常在休息,反之亦然。而國內巨大的用戶群體則對業界的程序員提出更高 的挑戰,早上9點和晚上20點到24點這些時間段的并發請求壓力是非常巨大的。尤其節假 日、寒暑假到來之時,更會對服務器提出極高的要求
* 另外,國內業務上的特性,也會引導用戶在同一時間大并發地訪問服務器。例如,許多 SNS網頁游戲會在固定的時間點刷新游戲資源或者允許“偷菜”等好友互動操作。這些會導致 服務器處理高并發請求的壓力增大
* 上述情形都對我們的互聯網服務在大并發壓力下是否還能夠給予用戶良好的體驗提出了 更高的要求。若要提供更好的服務,那么可以從多方面入手,例如,修改業務特性、引導用 戶從高峰期分流或者把服務分層分級、對于不同并發壓力給用戶提供不同級別的服務等。但 最根本的是,Web服務器要能支持大并發壓力下的正常服務,這才是關鍵
* 快速增長的互聯網用戶群以及業內所有互聯網服務提供商越來越好的用戶體驗,都促使 我們在大流量服務中用Nginx取代其他Web服務器。Nginx先天的事件驅動型設計、全異步的 網絡I/O處理機制、極少的進程間切換以及許多優化設計,都使得Nginx天生善于處理高并發 壓力下的互聯網請求,同時Nginx降低了資源消耗,可以把服務器硬件資源“壓榨”到極致
- NginX簡述
- 什么是中間件
- NginX概述
- 選擇NginX的理由
- NginX環境安裝
- 四項確認
- NginX安裝
- 安裝
- 安裝目錄詳解
- 編譯參數詳解
- Nginx主目錄
- 基于NginX的中間件架構
- Nginx日志類型
- Nginx變量
- 常見NginX中間架構
- 靜態資源web服務
- 概述
- 靜態資源服務場景-CDN
- 瀏覽器緩存原理
- 跨站訪問
- 防盜鏈
- 代理服務
- 概述
- 配置語法
- 其他配置語法
- 負載均衡調度器SLB
- 概述
- 配置
- 動態緩存
- ====分割線====
- Nginx初體驗
- nginx簡介
- 請求全流程
- nginx核心優勢
- 安裝第一個rpm包nginx
- Nginx進程結構與熱部署
- 進程結構
- 信號量管理nginx
- 配置文件重載原理真相
- nginx熱部署
- nginx模塊化管理機制
- nginx編譯安裝的配置參數
- nginx配置文件結構
- 虛擬主機的分類
- Nginx核心指令基礎應用
- main段核心參數用法
- events段核心參數用法
- HTTP段核心參數用法
- server_name
- server_name指令用法優先級
- root和alias的區別
- location的基礎用法
- location指令中匹配規則的優先級
- 深入理解location中URL結尾的反斜線
- stub_status模塊用法
- Nginx應用進階
- connection和request
- 對connection做限制的limit_conn模塊
- 對request處理速率做限制的limit_req模塊
- 限制特定IP或網段訪問的access模塊
- 限制特定用戶訪問的auth_basic模塊
- 基于HTTP響應狀態碼做權限控制的auth_request模塊
- rewrite模塊
- return指令
- rewrite指令
- return和rewrite指令執行順序
- if指令
- autoindex模塊用法
- Nginx的變量
- 變量分類
- TCP連接相關變量
- 發送HTTP請求變量
- 處理HTTP請求變量
- 反向代理
- 基礎原理
- 動靜分離
- nginx作為反向代理支持的協議
- 用于定義上游服務的upstream模塊
- upstream模塊指令用法詳解
- 配置一個可用的上游應用服務器
- proxy_pass常見誤區
- 代理場景下nginx接受用戶請求包體的處理方式
- 代理場景下Nginx更改發往上游的用戶請求
- 代理場景下Nginx與上游服務建立連接細節
- 基于fastcgi的反向代理
- 負載均衡
- 負載均衡基礎
- 實現nginx對上游服務負載均衡
- 負載均衡hash算法
- 負載均衡ip_hash算法
- 負載均衡最少連接數算法
- 針對上游服務器返回異常時的容錯機制
- Nginx緩存
- 緩存基礎
- 緩存相關指令
- 緩存用法配置示例
- 配置nginx不緩存上游服務特定內容
- 緩存失效降低上游壓力機制1-合并源請求
- 緩存失效降低上游壓力機制2-啟用陳舊緩存
- 第三方清除模塊ngx_cache_purge介紹
- ngx_cache_purge用法配置示例
- Nginx和HTTPS
- https原理基礎
- https如何解決信息被竊聽的問題
- https如何解決報文被篡改以及身份偽裝問題
- 配置私有CA服務器
- 組織機構向CA申請證書及CA簽發證書
- 深入Nginx架構
- Nginx性能優化