亚欧色一区w666天堂,色情一区二区三区免费看,少妇特黄A片一区二区三区,亚洲人成网站999久久久综合,国产av熟女一区二区三区

  • 發布文章
  • 消息中心
點贊
收藏
評論
分享
原創

Nginx的請求處理

2023-06-20 06:59:30
8
0

Nginx的請求處理流程

    worker進程中,ngx_worker_process_cycle()函數就是這個無限循環的處理函數。在這個函數中,一個請求的簡單處理流程如下:

 (1)操作系統提供的機制(例如epoll, kqueue等)產生相關的事件。

 (2)接收和處理這些事件,如是接受到數據,則產生更高層的request對象。

 (3)處理request的header和body。

 (4)產生響應,并發送回客戶端。

 (5)完成request的處理。

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

為了讓大家更好的了解nginx中請求處理過程,我們以HTTP Request為例,來做一下詳細地說明。

從nginx的內部來看,一個HTTP Request的處理過程涉及到以下幾個階段。

 (1)初始化HTTP Request(讀取來自客戶端的數據,生成HTTP Request對象,該對象含有該請求所有的信息)。

 (2)處理請求頭。

 (3)處理請求體。

 (4)如果有的話,調用與此請求(URL或者Location)關聯的handler。

 (5)依次調用各phase handler進行處理。

在這里,我們需要了解一下phase handler這個概念。phase字面的意思,就是階段。所以phase handlers也就好理解了,就是包含若干個處理階段的一些handler。

    在每一個階段,包含有若干個handler,再處理到某個階段的時候,依次調用該階段的handler對HTTP Request進行處理。通常情況下,一個phase handler對這個request進行處理,并產生一些輸出。通常phase handler是與定義在配置文件中的某個location相關聯的。

一個phase handler通常執行以下幾項任務:

 (1)獲取location配置。

 (2)產生適當的響應。

 (3)發送response header。

 (4)發送response body。

當nginx讀取到一個HTTP Request的header的時候,nginx首先查找與這個請求關聯的虛擬主機的配置。如果找到了這個虛擬主機的配置,那么通常情況下,這個HTTP Request將會經過以下幾個階段的處理(phase handlers):

NGX_HTTP_POST_READ_PHASE:  讀取請求內容階段

NGX_HTTP_SERVER_REWRITE_PHASE:  Server請求地址重寫階段

NGX_HTTP_FIND_CONFIG_PHASE:  配置查找階段:

NGX_HTTP_REWRITE_PHASE:  Location請求地址重寫階段

NGX_HTTP_POST_REWRITE_PHASE:  請求地址重寫提交階段

NGX_HTTP_PREACCESS_PHASE:  訪問權限檢查準備階段

NGX_HTTP_ACCESS_PHASE:  訪問權限檢查階段

NGX_HTTP_POST_ACCESS_PHASE:  訪問權限檢查提交階段

NGX_HTTP_TRY_FILES_PHASE:  配置項try_files處理階段

NGX_HTTP_CONTENT_PHASE:  內容產生階段

NGX_HTTP_LOG_PHASE:   日志模塊處理階段

 

在內容產生階段,為了給一個request產生正確的響應,nginx必須把這個request交給一個合適的content handler去處理。如果這個request對應的location在配置文件中被明確指定了一個content handler,那么nginx就可以通過對location的匹配,直接找到這個對應的handler,并把這個request交給這個content handler去處理。這樣的配置指令包括像,perl,flv,proxy_pass,mp4等。

 

如果一個request對應的location并沒有直接有配置的content handler,那么nginx依次嘗試:

 (1)如果一個location里面有配置 random_index on,那么隨機選擇一個文件,發送給客戶端。

 (2)如果一個location里面有配置 index指令,那么發送index指令指明的文件,給客戶端。

 (3)如果一個location里面有配置 autoindex on,那么就發送請求地址對應的服務端路徑下的文件列表給客戶端。

 (4)如果這個request對應的location上有設置gzip_static on,那么就查找是否有對應的.gz文件存在,有的話,就發送這個給客戶端(客戶端支持gzip的情況下)。

 (5)請求的URI如果對應一個靜態文件,static module就發送靜態文件的內容到客戶端。

 

內容產生階段完成以后,生成的輸出會被傳遞到filter模塊去進行處理。filter模塊也是與location相關的。所有的fiter模塊都被組織成一條鏈。輸出會依次穿越所有的filter,直到有一個filter模塊的返回值表明已經處理完成。

 

0條評論
0 / 1000
小謝不用謝
4文章數
0粉絲數
小謝不用謝
4 文章 | 0 粉絲
小謝不用謝
4文章數
0粉絲數
小謝不用謝
4 文章 | 0 粉絲
原創

Nginx的請求處理

2023-06-20 06:59:30
8
0

Nginx的請求處理流程

    worker進程中,ngx_worker_process_cycle()函數就是這個無限循環的處理函數。在這個函數中,一個請求的簡單處理流程如下:

 (1)操作系統提供的機制(例如epoll, kqueue等)產生相關的事件。

 (2)接收和處理這些事件,如是接受到數據,則產生更高層的request對象。

 (3)處理request的header和body。

 (4)產生響應,并發送回客戶端。

 (5)完成request的處理。

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

為了讓大家更好的了解nginx中請求處理過程,我們以HTTP Request為例,來做一下詳細地說明。

從nginx的內部來看,一個HTTP Request的處理過程涉及到以下幾個階段。

 (1)初始化HTTP Request(讀取來自客戶端的數據,生成HTTP Request對象,該對象含有該請求所有的信息)。

 (2)處理請求頭。

 (3)處理請求體。

 (4)如果有的話,調用與此請求(URL或者Location)關聯的handler。

 (5)依次調用各phase handler進行處理。

在這里,我們需要了解一下phase handler這個概念。phase字面的意思,就是階段。所以phase handlers也就好理解了,就是包含若干個處理階段的一些handler。

    在每一個階段,包含有若干個handler,再處理到某個階段的時候,依次調用該階段的handler對HTTP Request進行處理。通常情況下,一個phase handler對這個request進行處理,并產生一些輸出。通常phase handler是與定義在配置文件中的某個location相關聯的。

一個phase handler通常執行以下幾項任務:

 (1)獲取location配置。

 (2)產生適當的響應。

 (3)發送response header。

 (4)發送response body。

當nginx讀取到一個HTTP Request的header的時候,nginx首先查找與這個請求關聯的虛擬主機的配置。如果找到了這個虛擬主機的配置,那么通常情況下,這個HTTP Request將會經過以下幾個階段的處理(phase handlers):

NGX_HTTP_POST_READ_PHASE:  讀取請求內容階段

NGX_HTTP_SERVER_REWRITE_PHASE:  Server請求地址重寫階段

NGX_HTTP_FIND_CONFIG_PHASE:  配置查找階段:

NGX_HTTP_REWRITE_PHASE:  Location請求地址重寫階段

NGX_HTTP_POST_REWRITE_PHASE:  請求地址重寫提交階段

NGX_HTTP_PREACCESS_PHASE:  訪問權限檢查準備階段

NGX_HTTP_ACCESS_PHASE:  訪問權限檢查階段

NGX_HTTP_POST_ACCESS_PHASE:  訪問權限檢查提交階段

NGX_HTTP_TRY_FILES_PHASE:  配置項try_files處理階段

NGX_HTTP_CONTENT_PHASE:  內容產生階段

NGX_HTTP_LOG_PHASE:   日志模塊處理階段

 

在內容產生階段,為了給一個request產生正確的響應,nginx必須把這個request交給一個合適的content handler去處理。如果這個request對應的location在配置文件中被明確指定了一個content handler,那么nginx就可以通過對location的匹配,直接找到這個對應的handler,并把這個request交給這個content handler去處理。這樣的配置指令包括像,perl,flv,proxy_pass,mp4等。

 

如果一個request對應的location并沒有直接有配置的content handler,那么nginx依次嘗試:

 (1)如果一個location里面有配置 random_index on,那么隨機選擇一個文件,發送給客戶端。

 (2)如果一個location里面有配置 index指令,那么發送index指令指明的文件,給客戶端。

 (3)如果一個location里面有配置 autoindex on,那么就發送請求地址對應的服務端路徑下的文件列表給客戶端。

 (4)如果這個request對應的location上有設置gzip_static on,那么就查找是否有對應的.gz文件存在,有的話,就發送這個給客戶端(客戶端支持gzip的情況下)。

 (5)請求的URI如果對應一個靜態文件,static module就發送靜態文件的內容到客戶端。

 

內容產生階段完成以后,生成的輸出會被傳遞到filter模塊去進行處理。filter模塊也是與location相關的。所有的fiter模塊都被組織成一條鏈。輸出會依次穿越所有的filter,直到有一個filter模塊的返回值表明已經處理完成。

 

文章來自個人專欄
文章 | 訂閱
0條評論
0 / 1000
請輸入你的評論
0
0