Nginx簡介

1. nginx基礎特性

靜態的web資源服務器html，圖?，js，css，txt等靜態資源 結合FastCGI/uWSGI/SCGI等協議反向代理動態資源請求 http/https協議的反向代理 imap4/pop3協議的反向代理 tcp/udp協議的請求轉發（反向代理）

1.1 特性：

1. 模塊化設計，較好的擴展性
2. ?可靠性
3. ?持熱部署：不停機更新配置?件，升級版本，更換?志?件
4. 低內存消耗：10000個keep-alive連接模式下的?活動連接，僅需2.5M內存
5. event-driven,aio,mmap，sendfile

1.2 基本功能：

1. 靜態資源的web服務器
2. http協議反向代理服務器
3. pop3/imap4協議反向代理服務器
4. FastCGI(LNMP),uWSGI(python)等協議
5. 模塊化（?DSO），如zip，SSL模塊

2. 系統I/O

2.1 服務端I/O

• I/O在計算機中指Input/Output， IOPS (Input/Output Per Second)即每秒的輸?輸出量(或讀寫次數)，是衡量磁盤性能的主要指標之?
• IOPS是指的是在單位時間內系統能處理的I/O請求數量，?般以每秒處理的I/O請求數量為單位，I/O請求通常為讀或寫數據操作請求

2.1.1 機械磁盤的尋道時間、旋轉延遲和數據傳輸時間：

1. 尋道時間：是指磁頭移動到正確的磁道上所花費的時間，尋道時間越短則I/O處理就越快，?前磁盤的尋道時間?般在3-15毫秒左右。
2. 旋轉延遲：是指將磁盤?旋轉到數據所在的扇區到磁頭下?所花費的時間，旋轉延遲取決于磁盤的轉速，通常使?磁盤旋轉?周所需要時間的1/2之?表?，?如7200轉的磁盤平均訓傳延遲?約為601000/7200/2=4.17毫秒，公式的意思為 （每分鐘60秒1000毫秒每秒/7200轉每分鐘/2），如果是15000轉的則為60*1000/15000/2=2毫秒。
3. 數據傳輸時間：指的是讀取到數據后傳輸數據的時間，主要取決于傳輸速率，這個值等于數據??除以傳輸速率，?前的磁盤接?每秒的傳輸速度可以達到600MB，因此可以忽略不計。

2.1.2 常?的機械磁盤平均尋道時間值：

• 7200轉/分的磁盤平均物理尋道時間：9毫秒
• 10000轉/分的磁盤平均物理尋道時間：6毫秒
• 15000轉/分的磁盤平均物理尋道時間：4毫秒

2.1.3 常?磁盤的平均延遲時間：

• 7200轉的機械盤平均延遲：601000/7200/2 = 4.17ms
• 10000轉的機械盤平均延遲：601000/10000/2 = 3ms
• 15000轉的機械盤平均延遲：60*1000/15000/2 = 2ms

2.1.4 每秒最?IOPS的計算?法：

• 7200轉的磁盤IOPS計算?式：1000毫秒/(9毫秒的尋道時間+4.17毫秒的平均旋轉延遲時間)=1000/13.13=75.9 IOPS
• 10000轉的磁盤的IOPS計算?式：1000毫秒/(6毫秒的尋道時間+3毫秒的平均旋轉延遲時間)=1000/9=111 IOPS
• 15000轉的磁盤的IOPS計算?式：15000毫秒/(4毫秒的尋道時間+2毫秒的平均旋轉延遲時間)=1000/6=166.6 IOPS

2.1.5 網絡通信

?次完整的I/O是??空間的進程數據與內核空間的內核數據的報?的完整交換，但是由于內核空間與??空間是嚴格隔離的，所以其數據交換過程中不能由??空間的進程直接調?內核空間的內存數據，?是需要經歷?次從內核空間中的內存數據copy到??空間的進程內存當中

所以簡單說I/O就是把數據從內核空間中的內存數據復制到??空間中進程的內存當中。

??絡通信就是?絡協議棧到??空間進程的IO就是?絡IO

2.1.6 磁盤I/O

磁盤I/O是進程向內核發起系統調?，請求磁盤上的某個資源?如是?件或者是圖?，然后內核通過相應的驅動程序將?標圖?加載到內核的內存空間，加載完成之后把數據從內核內存再復制給進程內存，如果是?較?的數據也需要等待時間。

每次IO，都要經由兩個階段：
第?步：將數據從磁盤?件先加載?內核內存空間（緩沖區），此步驟需要等待數據準備完成，時間較?
第?步：將數據從內核緩沖區復制到??空間的進程的內存中，時間較短

2.2 系統I/O模型

同步/異步：關注的是事件處理的消息通信機制，即在等待?件事情的處理結果時，被調?者是否提供完成通知。

• 同步：synchronous，調?者等待被調?者返回消息后才能繼續執?，如果被調?者不提供消息返回則為同步，同步需要調?者主動詢問事情是否處理完成。
• 異步：asynchronous，被調?者通過狀態、通知或回調機制主動通知調?者被調?者的運?狀態

同步：進程發出請求調?后，等內核返回響應以后才繼續下?個請求，即如果內核?直不返回數據，那么進程就?直等。

異步：進程發出請求調?后，不等內核返回響應，接著處理下?個請求,Nginx是異步的。

阻塞/非阻塞：關注調?者在等待結果返回之前所處的狀態

• 阻塞：blocking，指IO操作需要徹底完成后才返回到??空間，調?結果返回之前，調?者被掛起，?不了別的事情。
• ?阻塞：nonblocking，指IO操作被調?后?即返回給???個狀態值，?需等到IO操作徹底完成，最終的調?結果返回之前，調?者不會被掛起，可以去做別的事情。

2.2.1 同步阻塞IO模型

同步阻塞：程序向內核發送IO請求后?直等待內核響應，如果內核處理請求的IO操作不能?即返回,則進程將?直等待并不再接受新的請求，并由進程輪訓查看IO是否完成，完成后進程將IO結果返回給Client，在IO沒有返回期間進程不能接受其他客?的請求，?且是有進程??去查看IO是否完成，這種?式簡單，但是?較慢，?的?較少。

小例子：同步阻塞就好比我點了一份蓋飯，但是廚師不會告訴我飯什么時候做好，同時我忘了帶手機，就只能在前臺干等，不能干別的事情，而且還要一遍一遍問廚師飯什么時候好。

• 優點：程序簡單，在阻塞等待數據期間進程/線程掛起，基本不會占? CPU 資源
• 缺點：每個連接需要獨?的進程/線程單獨處理，當并發請求量?時為了維護程序，內存、線程切換開銷較?，apache 的preforck使?的是這種模式。

2.2.2 同步?阻塞型I/O模型(nonblocking IO)：

同步?阻塞：程序向內核發送請IO求后?直等待內核響應，如果內核處理請求的IO操作不能?即返回IO結果，進程將不再等待，?且繼續處理其他請求，但是仍然需要進程隔?段時間就要查看內核IO是否完成。

同步非阻塞，我點了一份蓋飯，廚師依舊不告訴我什么時候能做好，這時我可以一邊玩手機一邊等著，還會時不時的問飯什么時候好。

2.2.3 異步阻塞I/O模型

異步阻塞：程序進程向內核發送IO調?后，不?等待內核響應，可以繼續接受其他請求，內核收到進程請求后進?的IO如果不能?即返回，就由內核等待結果，直到IO完成后內核再通知進程，apache event模型就是主進程+多進程/多線程+信號驅動

異步阻塞模型就是，我點了一份蓋飯，商家在我點完后說，飯一會就好，先去旁邊坐，我邊玩手機邊等，飯做好后，商家會通知我，我自己去前臺拿飯。

2.2.4 異步非阻塞I/O模型

異步?阻塞：程序進程向內核發送IO調?后，不?等待內核響應，可以繼續接受其他請求，內核調?的IO如果不能?即返回，內核會繼續處理其他事物，直到IO完成后將結果通知給內核，內核在將IO完成的結果返回給進程，期間進程可以接受新的請求，內核也可以處理新的事物，因此相互不影響，可以實現較?的同時并實現較?的IO復?，因此異步?阻塞使?最多的?種通信?式，nginx是異步?阻塞。

異步非阻塞，還是點一份蓋飯，我可以坐在旁邊玩手機等，飯做好后，服務員會把自動飯給我送過來。

3. nginx事件驅動模型

Nginx?持在多種不同的操作系統實現不同的事件驅動模型，但是其在不同的操作系統甚?是不同的系統版本上?的實現?式不盡相同，主要有以下實現?式：

3.1 nginx事件驅動模型分類：

3.1.1 select：

select庫是在linux和windows平臺都基本?持的 事件驅動模型庫，并且在接?的定義也基本相同，只是部分參數的含義略有差異，最?并發限制1024，是最早期的事件驅動模型。

3.1.2 poll：

在Linux 的基本驅動模型，windows不?持此驅動模型，是select的升級版，取消了最?的并發限制，在編譯nginx的時候可以使?–with-poll_module和–without-poll_module這兩個指定是否編譯select庫。

3.1.3 epoll：

epoll是庫是Nginx服務器?持的最?性能的事件驅動庫之?，是公認的?常優秀的事件驅動模型，它和select和poll有很?的區別，epoll是poll的升級版，但是與poll的效率有很?的區別。

epoll的處理?式是創建?個待處理的事件列表，然后把這個列表發給內核，返回的時候在去輪訓檢查這個表，以判斷事件是否發?，epoll?持?個進程打開的最?事件描述符的上限是系統可以打開的?件的最?數，同時epoll庫的IO效率不隨描述符數?增加?線性下降，因為它只會對內核上報的“活躍”的描述符進?操作。

3.1.4 rtsig：

不是?個常?事件驅動，最?隊列1024，不是很常?

3.1.5 kqueue：

?于?持BSD系列平臺的?校事件驅動模型，主要?在FreeBSD 4.1及以上版本、OpenBSD 2.0級以上版本，NetBSD級以上版本及Mac OS X 平臺上，該模型也是poll庫的變種，因此和epoll沒有本質上的區別，都是通過避免輪訓操作提供效率。

3.1.6 /dev/poll:

?于?持unix衍?平臺的?效事件驅動模型，主要在Solaris 平臺、HP/UX，該模型是sun公司在開發Solaris系列平臺的時候提出的?于完成事件驅動機制的?案，它使?了虛擬的/dev/poll設備，開發?員將要?識的?件描述符加?這個設備，然后通過ioctl()調?來獲取事件通知，因此運?在以上系列平臺的時候請使?/dev/poll事件驅動機制。

3.1.7 eventport：

該?案也是sun公司在開發Solaris的時候提出的事件驅動庫，只是Solaris 10以上的版本，該驅動庫看防?內核崩潰等情況的發?。

3.1.8 Iocp：

Windows系統上的實現?式，對應第5種（異步I/O）模型。

3.2 常用模型匯總

3.3 常用模型對比:

• ?平觸發-- 多次通知，需要關?數據是否取完以避免重復通知，效率較低。
• 邊緣觸發-- ?次通知，需要關?數據是否取?以避免數據丟失，效率較?。

3.4 MMAP介紹

mmap(memory mapping)系統調?使得進程之間通過映射同?個普通?件實現共享內存，普通?件被映射到進程地址空間后，進程可以像訪問普通內存?樣對?件進?訪問。

3.4.1 傳統方式copy數據：

傳統方式進程讀取數據是，先將數據包讀取到內核空間（cache緩沖），然后再將內核中的數據包拷貝到進程空間（分頁物理存儲），但是有一個問題是，如果兩個進程讀取一樣的數據包，內核要拷貝兩次到進程空間，造成了內核性能的浪費。

3.4.2 mmap方式

mmap方式為，在將數據包從內核空間拷貝到進程空間中后，會利用類似軟連接的技術，將數據包鏈接到進程中，讓進程讀取，這樣可以大大釋放內核的負載。

4. Nginx組織結構

web請求處理機制：

1. 多進程方式：服務器端主進程生成子進程來響應客戶端請求
   • 優點：響應快，進程之間相互獨立
   • 缺點：當訪問量大時，容易造成擁塞
2. 多線程方式：服務器端主進程生成子進程，子進程中在開線程來處理客戶端響應，一個線程響應一個請求。子進程可以生成多個線程。
   • 優點：加速訪問，可以承受一定程度的高并發。
   • 缺點：線程之間互相影響，主進程掛掉，子進程也會崩潰。

4.1 組織結構

Nginx是多進程組織模型，?且是?個由Master主進程和Worker?作進程組成。

主進程(master process)的功能：

• 讀取Nginx 配置?件并驗證其有效性和正確性
• 建?、綁定和關閉socket連接
• 按照配置?成、管理和結束?作進程
• 接受外界指令，?如重啟、升級及退出服務器等指令
• 不中斷服務，實現平滑升級，重啟服務并應?新的配置
• 開啟?志?件，獲取?件描述符
• 不中斷服務，實現平滑升級，升級失敗進?回滾處理
• 編譯和處理perl腳本

?作進程（woker process）的功能：

• 接受處理客?的請求
• 將請求以此送?各個功能模塊進?處理
• IO調?，獲取響應數據
• 與后端服務器通信，接收后端服務器的處理結果
• 緩存數據，訪問緩存索引，查詢和調?緩存數據
• 發送請求結果，響應客?的請求
• 接收主程序指令，?如重啟、升級和退出等

4.2 進程間通信

主進程與工作進程之間的通信：

?作進程是有主進程?成的，主進程使?fork()函數，在Nginx服務器啟動過程中主進程根據配置?件決定啟動?作進程的數量，然后建??張全局的?作表?于存放當前未退出的所有的?作進程，主進程?成?作進程后會將新?成的?作進程加?到?作進程表中，并建??個單向的管道并將其傳遞給?作進程，該管道與普通的管道不同，它是由主進程指向?作進程的單項通道，包含了主進程向?作進程發出的指令、?作進程ID、?作進程在?作進程表中的索引和必要的?件描述符等信息。

主進程與外界通過信號機制進行通信

當接收到需要處理的信號時，它通過管道向相關的?作進程發送正確的指令，每個?作進程都有能?捕獲管道中的可讀事件，當管道中有可讀事件的時候，?作進程就會從管道中讀取并解析指令，然后采取相應的執?動作，這樣就完成了主進程與?作進程的交互。

工作進程之間的通信：

?作進程之間的通信原理基本上和主進程與?作進程之間的通信是?樣的，只要?作進程之間能夠取得彼此的信息，建?管道即可通信，但是由于?作進程之間是完全隔離的，因此?個進程想要直到另外?個進程的狀態信息就只能通過主進程來設置了。

為了實現?作進程之間的交互，主進程在?成?作進程只之后，在?作進程表中進?遍歷，將該新進程的ID以及針對該進程建?的管道句柄傳遞給?作進程中的其他進程，為?作進程之間的通信做準備，當?作進程1向?作進程2發送指令的時候，?先在主進程給它的其他?作進程?作信息中找到2的進程ID，然后將正確的指令寫?指向進程2的管道，?作進程2捕獲到管道中的事件后，解析指令并進?相關操作，這樣就完成了?作進程之間的通信。

5. nginx模塊介紹

• 核?模塊：是 Nginx 服務器正常運? 必不可少 的模塊，提供 錯誤?志記錄 、 配置?件解析 、 事件驅動機制 、進程管理等核?功能
• 標準HTTP模塊：提供 HTTP 協議解析相關的功能，?如： 端?配置 、 ??編碼設置 、HTTP響應頭設置等等
• 可選HTTP模塊：主要?于擴展標準的 HTTP 功能，讓 Nginx 能處理?些特殊的服務，?如： Flash 多媒體傳輸 、解析 GeoIP 請求、 ?絡傳輸壓縮 、 安全協議 SSL ?持等
• 郵件服務模塊：主要?于?持Nginx 的 郵件服務 ，包括對 POP3 協議、 IMAP 協議和 SMTP協議的?持
• 第三?模塊：是為了擴展 Nginx 服務器應?，完成開發者?定義功能，?如： Json ?持、 Lua ?持等

?于擴展標準的 HTTP 功能，讓 Nginx 能處理?些特殊的服務，?如： Flash 多媒體傳輸 、解析 GeoIP 請求、 ?絡傳輸壓縮 、 安全協議 SSL ?持等

• 郵件服務模塊：主要?于?持Nginx 的 郵件服務 ，包括對 POP3 協議、 IMAP 協議和 SMTP協議的?持
• 第三?模塊：是為了擴展 Nginx 服務器應?，完成開發者?定義功能，?如： Json ?持、 Lua ?持等