Nginx 之三：nginx服務器模塊、web請求處理機制及事件驅動模型、進程功能和進程間通訊

一：Nginx的模塊化結構設計：

一、核心模塊：指的是nginx服務器運行當中必不可少的模塊，這些模塊提供了最基本最核心的服務，好比權限控制、進程管理、錯誤日誌、事件驅動、正則表達式解析等,nginx的源碼模塊位於/root/nginx-1.8.1/src目錄：

[root@Server1 src]# pwd
/root/nginx-1.8.1/src
[root@Server1 src]# ls
core   #核心模塊
event  #事件模塊
http   #http模塊
mail   #郵件模塊
misc   #其餘模塊
os     #系統模塊

二、標準HTTP模塊：默認即被編譯到了Nginx當中，除非使用--with-out-module_name參數聲明不編譯，如：

ngx_http_core  #配置端口、URL分析、服務器響應錯誤處理，別名控制以及其餘HTTP核心事物。
ngx_http_auth_basic_module #基於http的認證
ngx_http_access_module #基於IP地址的訪問控制策略
ngx_http_autoindex_module #處理以「/」結尾的請求並自動生成目錄列表。
ngx_http_browser_module #解析HTTP請求頭中的」User-Agent「 的值。
ngx_http_charset_module#指定網頁的編碼。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

三、可選HTTP模塊：

ngx_http_perl_module #在nginx 的配置文件中可使用perl腳本。
ngx_http_flv_module  #支持flash多媒體信息文件傳輸。
ngx_http_gzip_module #支持時時壓縮
ngx_http_image_filter_module #支持JPEG,GIF和PNG的圖片的尺寸和旋轉方向
ngx_http_ssl_module  #支持對HTTPS/SSL的支持
ngx_http_sub_module  #支持使用指定的字符串替換相應信息的中的信息

四、郵件模塊；默認沒有編譯，使用的場景也很少。

ngx_mail_auth_http_module.c
ngx_mail.c
ngx_mail_core_module.c
ngx_mail.h
ngx_mail_handler.c
ngx_mail_imap_handler.c
ngx_mail_imap_module.c
ngx_mail_imap_module.h
ngx_mail_parse.c
ngx_mail_pop3_handler.c
ngx_mail_pop3_module.c
ngx_mail_pop3_module.h
ngx_mail_proxy_module.c
ngx_mail_smtp_handler.c
ngx_mail_smtp_module.c
ngx_mail_smtp_module.h
ngx_mail_ssl_module.c
ngx_mail_ssl_module.h

五、第三方模塊：

echo-nginx-module #支持在配置文件中使用echo、sleep、time即exec等相似shell命令。
memc-nginx-module #對標準http模塊ngx_http_memcached_module的擴展，支持set、add、delete等命令
lua-nginx-module #支持lua腳本語言

六、安裝 echo-nginx-module 模塊：

6.1：模塊地址： https://github.com/openresty/echo-nginx-module.git

6.2：進到在nginx源碼目錄下，執行編譯安裝echo-nginx-module模塊：

cd nginx-1.8.1
./configure   --prefix=/usr/local/nginx/ --add-module=/home/tianqi/echo-nginx-module-master
make
make install

6.3：配置nginx.conf：

server {
        listen       80;
        server_name  hfnginx.chinacloudapp.cn;
        location / {
            root   html;
            index  index.html index.htm;
            echo $remote_addr;
            echo $remote_port;
            echo "zhangjie";
        }

6.4:訪問測試：

6.5:Nginx模塊組織工做圖：

 

二：web請求處理機制：

一、多進程方式：服務器沒接受到一個客戶端請求就有服務器的主進程生成一個子進程響應客戶端，直到用戶關閉鏈接，這樣的優點是處理速度快，子進程之間相互獨立，可是若是訪問過大會致使服務器資源耗盡而沒法提供請求。

二、多線程方式：與多進程方式相似，可是每收到一個客戶端請求會有服務進程派生出一個線程來個客戶方進行交互，一個線程的開銷遠遠小於一個進程，所以多線程方式在很大程度減輕了web服務器對系統資源的要求，可是多線程也有本身的缺點，即當多個線程位於同一個進程內工做的時候，能夠相互訪問一樣的內存地址空間，因此他們相互影響，一旦主進程掛掉則全部子線程都不能工做了，IIS服務器使用了多線程的方式，須要間隔一段時間就重啓一次才能穩定。

 

三：同步和異步、阻塞與非阻塞：

一、同步與異步：主要是針對應用程序與內核的交互方式而言的：

同步：進程發出數據後，等內核返回響應之後才繼續下一個請求，即若是內核一直不返回數據，那麼進程就一直等，直到天荒地老，死機error。

異步：進程發出數據後，不等內核返回響應，接着處理下一個請求,Nginx是異步的。

二、阻塞與非阻塞：

能夠理解爲內核與IO設備的交互方式，當內核收到進程請求IO數據時候的處理方式：

也能夠簡單理解爲內核須要作一件事能不能當即獲得返回應答，若是不能當即得到返回，須要等待，那就阻塞了，不然就能夠理解爲非阻塞。

阻塞：IO調用不能當即返回結果，即一個進程發起的IO請求不能獲得當即知足時，進程就要一直等到內核響應，內核要把數據從IO設備複製到內核空間，再返回給進程，這是阻塞。

非阻塞：IO調用能夠當即返回結果，一個進程發起的IO進程不能當即知足時，不在等待，而是一遍一遍的輪訓查看IO是否完成。

詳細區別以下圖所示：

 

三、混合總結：

3.1：同步阻塞：程序進程向內核發送IO請求後一直等待內核響應，若是內核處理請求的IO操做不能當即返回,則進程將一直等待並再也不接受新的請求，並由進程輪訓查看IO是否完成，完成後進程將IO結果返回給Client，在IO沒有返回期間進程不能接受其餘客戶的請求，並且是有進程本身去查看IO是否完成，這種方式簡單，可是比較慢，用的比較少。

3.2：同步非阻塞：，進程向內核發送請IO求後一直等待內核響應，若是內核處理請求的IO操做不能當即返回IO結果，進程將再也不等待，並且繼續處理其餘請求，可是仍然須要進程隔一段時間就要查看內核IO是否完成。

3.3：異步阻塞：event-diver，進程向內核發送IO調用後，不用等待內核響應，能夠繼續接受其餘請求，內核收到進程請求後進行的IO若是不能當即返回，就由內核等待結果，直到IO完成後內核再通知進程，此方式比較佔用內核，所以也不多使用。

3.4：異步非阻塞：AIO,進程向內核發送IO調用後，不用等待內核響應，能夠繼續接受其餘請求，內核調用的IO若是不能當即返回，內核會繼續處理其餘事物，直到IO完成後將結果通知給內核，內核在將IO完成的結果返回給進程，期間進程能夠接受新的請求，內核也能夠處理新的事物，所以相互不影響，能夠實現較大的同時並實現較高的IO複用，所以異步非阻塞使用最多的一種通訊方式。

 

 四：Nginx支持的事件驅動模型：

 一、select：

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

二、poll：

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

三、epoll：

epoll是庫是Nginx服務器支持的最高性能的事件驅動庫之一，是公認的很是優秀的事件驅動模型，它和select和poll有很大的區別，epoll是poll的升級版，可是與poll的效率有很大的區別.
epoll的處理方式是建立一個待處理的事件列表，而後把這個列表發給內核，返回的時候在去輪訓檢查這個表，以判斷事件是否發生，epoll支持一個進程打開的最大事件描述符的上限是系統能夠打開的文件的最大數，同時epoll庫的IO效率不隨描述符數目增長而線性降低，由於它只會對內核上報的「活躍」的描述符進行操做。

四、rtsig：

不是一個經常使用事件驅動，最大隊列1024，不是很經常使用

五、kqueue：

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

 六、/dev/poll:

用於支持unix衍平生臺的高效事件驅動模型，主要在Solaris 平臺、HP/UX，該模型是sun公司在開發Solaris系列平臺的時候提出的用於完成事件驅動機制的方案，它使用了虛擬的/dev/poll設備，開發人員將要見識的文件描述符加入這個設備，而後經過ioctl()調用來獲取事件通知，所以運行在以上系列平臺的時候請使用/dev/poll事件驅動機制。

七、eventport：

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

 

五：Nginx 進程的功能和進程間的通訊：

一、主進程(woker process)的功能：

讀取Nginx 配置文件並驗證其有效性和正確性
創建、綁定和關閉socket鏈接
按照配置生成、管理和結束工做進程
接受外界指令，好比重啓、升級及退出服務器等指令
不中斷服務，實現平滑升級，重啓服務並應用新的配置
開啓日誌文件，獲取文件描述符
不中斷服務，實現平滑升級，升級失敗進行回滾處理
編譯和處理perl腳本

二、工做進程（woker process）的功能：

接受處理客戶的請求
將請求以此送入各個功能模塊進行處理
IO調用，獲取響應數據
與後端服務器通訊，接收後端服務器的處理結果
緩存數據，訪問緩存索引，查詢和調用緩存數據
發送請求結果，響應客戶的請求
接收主程序指令，好比重啓、升級和退出等

三、Ninx進程間的通訊：

3.1：主進程和工做進程之間的通訊：

    工做進程是有主進程生成的，主進程使用fork()函數，在Nginx服務器啓動過程當中主進程根據配置文件決定啓動工做進程的數量，而後創建一張全局的工做表用於存放當前未退出的全部的工做進程，主進程生成工做進程後會將新生成的工做進程加入到工做進程表中，並創建一個單向的管道並將其傳遞給工做進程，該管道與普通的管道不一樣，它是由主進程指向工做進程的單項通道，包含了主進程想工做進程發出的指令、工做進程ID、工做進程在工做進程表中的索引和必要的文件描述符等信息。
    主進程與外界經過信號機制進行通訊，當接收到須要處理的信號時，它經過管道向相關的工做進程發送正確的指令，每一個工做進程都有能力捕獲管道中的可讀事件，當管道中有可讀事件的時候，工做進程就會從管道中讀取並解析指令，而後採起相應的執行動做，這樣就完成了主進程與工做進程的交互。

 3.2：工做進程與工做進程之間的通訊：

    工做進程之間的通訊原理基本上和主進程與工做進程之間的通訊是同樣的，只要工做進程之間可以取得彼此的信息，創建管道便可通訊，可是因爲工做進程之間是徹底隔離的，所以一個進程想要直到另一個進程的狀態信息就只能經過主進程來設置了。
    爲了實現工做進程之間的交互，主進程在生成工做進程只以後，在工做進程表中進行遍歷，將該新進程的ID以及針對該進程創建的管道句柄傳遞給工做進程中的其餘進程，爲工做進程之間的通訊作準備，當工做進程1向工做進程2發送指令的時候，首先在主進程給它的其餘工做進程工做信息中找到2的進程ID，而後將正確的指令寫入指向進程2的管道，工做進程2捕獲到管道中的事件後，解析指令並進行相關操做，這樣就完成了工做進程之間的通訊。