通俗易懂的Nginx工作原理

Nginx 瀏覽器 DNS 技術 防火牆 GFW Origin Twitter 程序員聖經 2019-05-26
作者:Rick617
原文:https://www.jianshu.com/p/6215e5d24553

1 反向代理

1.1 概念

反向代理(Reverse Proxy)方式是指以代理服務器來接受internet上的連接請求,然後將請求轉發給內部網絡上的服務器,並將從服務器上得到的結果返回給internet上請求連接的客戶端,此時代理服務器對外就表現為一個服務器。

舉個例子,比如我想訪問 http://www.test.com/readme,但www.test.com上並不存在readme頁面,於是他是偷偷從另外一臺服務器上取回來,然後作為自己的內容返回用戶,但用戶並不知情。這裡所提到的 www.test.com 這個域名對應的服務器就設置了反向代理功能。

結論就是,反向代理服務器對於客戶端而言它就像是原始服務器,並且客戶端不需要進行任何特別的設置。客戶端向反向代理的命名空間(name-space)中的內容發送普通請求,接著反向代理服務器將判斷向何處(原始服務器)轉交請求,並將獲得的內容返回給客戶端,就像這些內容原本就是它自己的一樣。

正向代理,既然有反向代理,就肯定有正向代理。什麼叫正向代理呢?

正向代理(Forward Proxy)通常都被簡稱為代理,就是在用戶無法正常訪問外部資源,比方說受到GFW的影響無法訪問twitter的時候,我們可以通過代理的方式,讓用戶繞過防火牆,從而連接到目標網絡或者服務。

正向代理的工作原理就像一個跳板,比如:我訪問不了google.com,但是我能訪問一個代理服務器A,A能訪問google.com,於是我先連上代理服務器A,告訴他我需要google.com的內容,A就去取回來,然後返回給我。從網站的角度,只在代理服務器來取內容的時候有一次記錄,有時候並不知道是用戶的請求,也隱藏了用戶的資料,這取決於代理告不告訴網站。

結論就是,正向代理是一個位於客戶端和原始服務器(origin server)之間的服務器。為了從原始服務器取得內容,客戶端向代理髮送一個請求並指定目標(原始服務器),然後代理向原始服務器轉交請求並將獲得的內容返回給客戶端。

反向代理VS正向代理:

通俗易懂的Nginx工作原理


正向代理示意圖


通俗易懂的Nginx工作原理


反向代理示意圖


1.2 工作流程

  1. 用戶通過域名發出訪問Web服務器的請求,該域名被DNS服務器解析為反向代理服務器的IP地址;
  2. 反向代理服務器接受用戶的請求;
  3. 反向代理服務器在本地緩存中查找請求的內容,找到後直接把內容發送給用戶;
  4. 如果本地緩存裡沒有用戶所請求的信息內容,反向代理服務器會代替用戶向源服務器請求同樣的信息內容,並把信息內容發給用戶,如果信息內容是緩存的還會把它保存到緩存中。


1.3 優點

  1. 保護了真實的web服務器,保證了web服務器的資源安全


通常的代理服務器,只用於代理內部網絡對Internet外部網絡的連接請求,客戶機必須指定代理服務器,並將本來要直接發送到Web服務器上的http請求發送到代理服務器中。不支持外部網絡對內部網絡的連接請求,因為內部網絡對外部網絡是不可見的。當一個代理服務器能夠代理外部網絡上的主機,訪問內部網絡時,這種代理服務的方式稱為反向代理服務。此時代理服務器對外就表現為一個Web服務器,外部網絡就可以簡單把它當作一個標準的Web服務器而不需要特定的配置。不同之處在於,這個服務器沒有保存任何網頁的真實數據,所有的靜態網頁或者CGI程序,都保存在內部的Web服務器上。因此對反向代理服務器的攻擊並不會使得網頁信息遭到破壞,這樣就增強了Web服務器的安全性。

  1. 節約了有限的IP地址資源


企業內所有的網站共享一個在internet中註冊的IP地址,這些服務器分配私有地址,採用虛擬主機的方式對外提供服務。

  1. 減少WEB服務器壓力,提高響應速度


反向代理就是通常所說的web服務器加速,它是一種通過在繁忙的web服務器和外部網絡之間增加一個高速的web緩衝服務器來降低實際的web服務器的負載的一種技術。反向代理是針對web服務器提高加速功能,作為代理緩存,它並不是針對瀏覽器用戶,而針對一臺或多臺特定的web服務器,它可以代理外部網絡對內部網絡的訪問請求。

反向代理服務器會強制將外部網絡對要代理的服務器的訪問經過它,這樣反向代理服務器負責接收客戶端的請求,然後到源服務器上獲取內容,把內容返回給用戶,並把內容保存到本地,以便日後再收到同樣的信息請求時,它會把本地緩存裡的內容直接發給用戶,以減少後端web服務器的壓力,提高響應速度。因此Nginx還具有緩存功能。

  1. 其他優點


(1)請求的統一控制,包括設置權限、過濾規則等;

(2)區分動態和靜態可緩存內容;

(3)實現負載均衡,內部可以採用多臺服務器來組成服務器集群,外部還是可以採用一個地址訪問;

(4)解決Ajax跨域問題;

(5)作為真實服務器的緩衝,解決瞬間負載量大的問題;

Nginx有五大優點:模塊化、事件驅動、異步、非阻塞、多進程單線程。由內核和模塊組成的,其中內核完成的工作比較簡單,僅僅通過查找配置文件將客戶端請求映射到一個location block,然後又將這個location block中所配置的每個指令將會啟動不同的模塊去完成相應的工作。

2 Nginx模塊

2.1 模塊劃分

Nginx的模塊從結構上分為核心模塊、基礎模塊和第三方模塊:

核心模塊:HTTP模塊、EVENT模塊和MAIL模塊
基礎模塊:HTTP Access模塊、HTTP FastCGI模塊、HTTP Proxy模塊和HTTP Rewrite模塊,
第三方模塊:HTTP Upstream Request Hash模塊、Notice模塊和HTTP Access Key模塊。

Nginx的模塊從功能上分為如下四類:

Core(核心模塊):構建nginx基礎服務、管理其他模塊。
Handlers(處理器模塊):此類模塊直接處理請求,並進行輸出內容和修改headers信息等操作。
Filters (過濾器模塊):此類模塊主要對其他處理器模塊輸出的內容進行修改操作,最後由Nginx輸出。
Proxies (代理類模塊):此類模塊是Nginx的HTTP Upstream之類的模塊,這些模塊主要與後端一些服務比如FastCGI等進行交互,實現服務代理和負載均衡等功能。

Nginx的核心模塊主要負責建立nginx服務模型、管理網絡層和應用層協議、以及啟動針對特定應用的一系列候選模塊。其他模塊負責分配給web服務器的實際工作:

(1) 當Nginx發送文件或者轉發請求到其他服務器,由Handlers(處理模塊)或Proxies(代理類模塊)提供服務;
(2) 當需要Nginx把輸出壓縮或者在服務端加一些東西,由Filters(過濾模塊)提供服務。


2.2 模塊處理

  1. 當服務器啟動,每個handlers(處理模塊)都有機會映射到配置文件中定義的特定位置(location);如果有多個handlers(處理模塊)映射到特定位置時,只有一個會“贏”(說明配置文件有衝突項,應該避免發生)。


處理模塊以三種形式返回:

  • OK
  • ERROR
  • 或者放棄處理這個請求而讓默認處理模塊來處理(主要是用來處理一些靜態文件,事實上如果是位置正確而真實的靜態文件,默認的處理模塊會搶先處理)。


  1. 如果handlers(處理模塊)把請求反向代理到後端的服務器,就變成另外一類的模塊:load-balancers(負載均衡模塊)。負載均衡模塊的配置中有一組後端服務器,當一個HTTP請求過來時,它決定哪臺服務器應當獲得這個請求。


Nginx的負載均衡模塊採用兩種方法:

輪轉法,它處理請求就像紙牌遊戲一樣從頭到尾分發;
IP哈希法,在眾多請求的情況下,它確保來自同一個IP的請求會分發到相同的後端服務器。


  1. 如果handlers(處理模塊)沒有產生錯誤,filters(過濾模塊)將被調用。多個filters(過濾模塊)能映射到每個位置,所以(比如)每個請求都可以被壓縮成塊。它們的執行順序在編譯時決定。


filters(過濾模塊)是經典的“接力鏈表(CHAIN OF RESPONSIBILITY)”模型:一個filters(過濾模塊)被調用,完成其工作,然後調用下一個filters(過濾模塊),直到最後一個filters(過濾模塊)。

過濾模塊鏈的特別之處在於:

每個filters(過濾模塊)不會等上一個filters(過濾模塊)全部完成;
它能把前一個過濾模塊的輸出作為其處理內容;有點像Unix中的流水線;

過濾模塊能以buffer(緩衝區)為單位進行操作,這些buffer一般都是一頁(4K)大小,當然你也可以在nginx.conf文件中進行配置。這意味著,比如,模塊可以壓縮來自後端服務器的響應,然後像流一樣的到達客戶端,直到整個響應發送完成。

總之,過濾模塊鏈以流水線的方式高效率地向客戶端發送響應信息。

  1. 所以總結下上面的內容,一個典型的HTTP處理週期是這樣的:


客戶端發送HTTP請求 –>
Nginx基於配置文件中的位置選擇一個合適的處理模塊 ->
(如果有)負載均衡模塊選擇一臺後端服務器 –>
處理模塊進行處理並把輸出緩衝放到第一個過濾模塊上 –>
第一個過濾模塊處理後輸出給第二個過濾模塊 –>
然後第二個過濾模塊又到第三個 –>
依此類推 –> 最後把響應發給客戶端。

下圖展示了Nginx模塊處理流程:

通俗易懂的Nginx工作原理


Nginx模塊處理流程

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

3 Nginx請求處理

Nginx在啟動時會以daemon形式在後臺運行,採用多進程+異步非阻塞IO事件模型來處理各種連接請求。多進程模型包括一個master進程,多個worker進程,一般worker進程個數是根據服務器CPU核數來決定的master進程負責管理Nginx本身和其他worker進程。如下圖:

通俗易懂的Nginx工作原理


Master進程負責管理Nginx本身和其他worker進程

通俗易懂的Nginx工作原理


Master-Worker模式

從上圖中可以很明顯地看到,4個worker進程的父進程都是master進程,表明worker進程都是從父進程fork出來的,並且父進程的ppid為1,表示其為daemon進程。
需要說明的是,在nginx多進程中,每個worker都是平等的,因此每個進程處理外部請求的機會權重都是一致的。


Master進程的作用是?

讀取並驗證配置文件nginx.conf;管理worker進程;
Worker進程的作用是?
每一個Worker進程都維護一個線程(避免線程切換),處理連接和請求;注意Worker進程的個數由配置文件決定,一般和CPU個數相關(有利於進程切換),配置幾個就有幾個Worker進程。


Nginx如何做到熱部署?

所謂熱部署,就是配置文件nginx.conf修改後,不需要stop Nginx,不需要中斷請求,就能讓配置文件生效!(nginx -s reload 重新加載/nginx -t檢查配置/nginx -s stop)
通過上文我們已經知道worker進程負責處理具體的請求,那麼如果想達到熱部署的效果,可以想象:
方案一:
修改配置文件nginx.conf後,主進程master負責推送給woker進程更新配置信息,woker進程收到信息後,更新進程內部的線程信息。
方案二:
修改配置文件nginx.conf後,重新生成新的worker進程,當然會以新的配置進行處理請求,而且新的請求必須都交給新的worker進程,至於老的worker進程,等把那些以前的請求處理完畢後,kill掉即可。
Nginx採用的就是方案二來達到熱部署的!


Nginx如何做到高併發下的高效處理?

上文已經提及Nginx的worker進程個數與CPU綁定、worker進程內部包含一個線程高效迴環處理請求,這的確有助於效率,但這是不夠的。
作為專業的程序員,我們可以開一下腦洞:BIO/NIO/AIO、異步/同步、阻塞/非阻塞...
要同時處理那麼多的請求,要知道,有的請求需要發生IO,可能需要很長時間,如果等著它,就會拖慢worker的處理速度。
Nginx採用了Linux的epoll模型,epoll模型基於事件驅動機制,它可以監控多個事件是否準備完畢,如果OK,那麼放入epoll隊列中,這個過程是異步的。worker只需要從epoll隊列循環處理即可。


Nginx掛了怎麼辦?

Nginx既然作為入口網關,很重要,如果出現單點問題,顯然是不可接受的。
答案是:Keepalived+Nginx實現高可用。
Keepalived是一個高可用解決方案,主要是用來防止服務器單點發生故障,可以通過和Nginx配合來實現Web服務的高可用。(其實,Keepalived不僅僅可以和Nginx配合,還可以和很多其他服務配合)
Keepalived+Nginx實現高可用的思路:
第一:請求不要直接打到Nginx上,應該先通過Keepalived(這就是所謂虛擬IP,VIP)
第二:Keepalived應該能監控Nginx的生命狀態(提供一個用戶自定義的腳本,定期檢查Nginx進程狀態,進行權重變化,,從而實現Nginx故障切換)


通俗易懂的Nginx工作原理


Keepalived+Nginx

Nginx架構及工作流程圖:

通俗易懂的Nginx工作原理


Nginx架構及工作流程圖

Nginx真正處理請求業務的是Worker之下的線程。worker進程中有一個ngx_worker_process_cycle()函數,執行無限循環,不斷處理收到的來自客戶端的請求,並進行處理,直到整個Nginx服務被停止。

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

  • 操作系統提供的機制(例如 epoll, kqueue 等)產生相關的事件。
  • 接收和處理這些事件,如是接收到數據,則產生更高層的 request 對象。
  • 處理 request 的 header 和 body。
  • 產生響應,併發送回客戶端。
  • 完成 request 的處理。
  • 重新初始化定時器及其他事件。


3.1 多進程處理模型

下面來介紹一個請求進來,多進程模型的處理方式:

首先,master進程一開始就會根據我們的配置,來建立需要listen的網絡socket fd,然後fork出多個worker進程。
其次,根據進程的特性,新建立的worker進程,也會和master進程一樣,具有相同的設置。因此,其也會去監聽相同ip端口的套接字socket fd。
然後,這個時候有多個worker進程都在監聽同樣設置的socket fd,意味著當有一個請求進來的時候,所有的worker都會感知到。這樣就會產生所謂的“驚群現象”。為了保證只會有一個進程成功註冊到listenfd的讀事件,nginx中實現了一個“accept_mutex”類似互斥鎖,只有獲取到這個鎖的進程,才可以去註冊讀事件。其他進程全部accept 失敗。
最後,監聽成功的worker進程,讀取請求,解析處理,響應數據返回給客戶端,斷開連接,結束。因此,一個request請求,只需要worker進程就可以完成。

進程模型的處理方式帶來的一些好處就是:進程之間是獨立的,也就是一個worker進程出現異常退出,其他worker進程是不會受到影響的;此外,獨立進程也會避免一些不需要的鎖操作,這樣子會提高處理效率,並且開發調試也更容易。

如前文所述,多進程模型+異步非阻塞模型才是勝出的方案。單純的多進程模型會導致連接併發數量的降低,而採用異步非阻塞IO模型很好的解決了這個問題;並且還因此避免的多線程的上下文切換導致的性能損失。

worker進程會競爭監聽客戶端的連接請求:這種方式可能會帶來一個問題,就是可能所有的請求都被一個worker進程給競爭獲取了,導致其他進程都比較空閒,而某一個進程會處於忙碌的狀態,這種狀態可能還會導致無法及時響應連接而丟棄discard掉本有能力處理的請求。這種不公平的現象,是需要避免的,尤其是在高可靠web服務器環境下。

針對這種現象,Nginx採用了一個是否打開accept_mutex選項的值,ngx_accept_disabled標識控制一個worker進程是否需要去競爭獲取accept_mutex選項,進而獲取accept事件

ngx_accept_disabled值:nginx單進程的所有連接總數的八分之一,減去剩下的空閒連接數量,得到的這個ngx_accept_disabled。
當ngx_accept_disabled大於0時,不會去嘗試獲取accept_mutex鎖,並且將ngx_accept_disabled減1,於是,每次執行到此處時,都會去減1,直到小於0。不去獲取accept_mutex鎖,就是等於讓出獲取連接的機會,很顯然可以看出,當空閒連接越少時,ngx_accept_disable越大,於是讓出的機會就越多,這樣其它進程獲取鎖的機會也就越大。不去accept,自己的連接就控制下來了,其它進程的連接池就會得到利用,這樣,nginx就控制了多進程間連接的平衡了。


3.2 一個簡單的HTTP請求

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

初始化 HTTP Request(讀取來自客戶端的數據,生成 HTTP Request 對象,該對象含有該請求所有的信息)。
處理請求頭。
處理請求體。
如果有的話,調用與此請求(URL 或者 Location)關聯的 handler。
依次調用各 phase handler 進行處理。

在建立連接過程中,對於nginx監聽到的每個客戶端連接,都會將它的讀事件的handler設置為ngx_http_init_request函數,這個函數就是請求處理的入口。在處理請求時,主要就是要解析http請求,比如:uri,請求行等,然後再根據請求生成響應。下面看一下nginx處理的具體過程:

通俗易懂的Nginx工作原理


Nginx處理的具體過程

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

在每一個階段,包含有若干個 handler,再處理到某個階段的時候,依次調用該階段的 handler 對 HTTP Request 進行處理。

通常情況下,一個 phase handler 對這個 request 進行處理,併產生一些輸出。通常 phase handler 是與定義在配置文件中的某個 location 相關聯的

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

獲取 location 配置。
產生適當的響應。
發送 response header。
發送 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 依次嘗試:

如果一個 location 裡面有配置 random_index on,那麼隨機選擇一個文件,發送給客戶端。
如果一個 location 裡面有配置 index 指令,那麼發送 index 指令指明的文件,給客戶端。
如果一個 location 裡面有配置 autoindex on,那麼就發送請求地址對應的服務端路徑下的文件列表給客戶端。
如果這個 request 對應的 location 上有設置 gzip_static on,那麼就查找是否有對應的.gz文件存在,有的話,就發送這個給客戶端(客戶端支持 gzip 的情況下)。
請求的 URI 如果對應一個靜態文件,static module 就發送靜態文件的內容到客戶端。

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

這裡列舉幾個常見的 filter 模塊,例如:

server-side includes。
XSLT filtering。
圖像縮放之類的。
gzip 壓縮。

在所有的 filter 中,有幾個 filter 模塊需要關注一下。按照調用的順序依次說明如下:

copy: 將一些需要複製的 buf(文件或者內存)重新複製一份然後交給剩餘的 body filter 處理。
postpone: 這個 filter 是負責 subrequest 的,也就是子請求的。
write: 寫輸出到客戶端,實際上是寫到連接對應的 socket 上。

3.3 請求完整處理過程

根據以上請求步驟所述,請求完整的處理過程如下圖所示:

通俗易懂的Nginx工作原理


請求完整的處理過程

3.4 keepalive 長連接

當然,在nginx中,對於http1.0與http1.1也是支持長連接的。

什麼是長連接呢?我們知道,http請求是基於TCP協議之上的,那麼,當客戶端在發起請求前,需要先與服務端建立TCP連接,而每一次的TCP連接是需要三次握手來確定的,如果客戶端與服務端之間網絡差一點,這三次交互消費的時間會比較多,而且三次交互也會帶來網絡流量。當然,當連接斷開後,也會有四次的交互,當然對用戶體驗來說就不重要了。而http請求是請求應答式的,如果我們能知道每個請求頭與響應體的長度,那麼我們是可以在一個連接上面執行多個請求的,這就是所謂的長連接,但前提條件是我們先得確定請求頭與響應體的長度。

對於請求來說,如果當前請求需要有body,如POST請求,那麼nginx就需要客戶端在請求頭中指定content-length來表明body的大小,否則返回400錯誤。也就是說,請求體的長度是確定的,那麼響應體的長度呢?先來看看http協議中關於響應body長度的確定:

對於http1.0協議來說,如果響應頭中有content-length頭,則以content-length的長度就可以知道body的長度了,客戶端在接收body時,就可以依照這個長度來接收數據,接收完後,就表示這個請求完成了。而如果沒有content-length頭,則客戶端會一直接收數據,直到服務端主動斷開連接,才表示body接收完了。
而對於http1.1協議來說,如果響應頭中的Transfer-encoding為chunked傳輸,則表示body是流式輸出,body會被分成多個塊,每塊的開始會標識出當前塊的長度,此時,body不需要通過長度來指定。如果是非chunked傳輸,而且有content-length,則按照content-length來接收數據。否則,如果是非chunked,並且沒有content-length,則客戶端接收數據,直到服務端主動斷開連接。

從上面,我們可以看到,除了http1.0不帶content-length以及http1.1非chunked不帶content-length外,body的長度是可知的。此時,當服務端在輸出完body之後,會可以考慮使用長連接。能否使用長連接,也是有條件限制的。如果客戶端的請求頭中的connection為close,則表示客戶端需要關掉長連接,如果為keep-alive,則客戶端需要打開長連接,如果客戶端的請求中沒有connection這個頭,那麼根據協議,如果是http1.0,則默認為close,如果是http1.1,則默認為keep-alive。如果結果為keepalive,那麼,nginx在輸出完響應體後,會設置當前連接的keepalive屬性,然後等待客戶端下一次請求。

當然,nginx不可能一直等待下去,如果客戶端一直不發數據過來,豈不是一直佔用這個連接?所以當nginx設置了keepalive等待下一次的請求時,同時也會設置一個最大等待時間,這個時間是通過選項keepalive_timeout來配置的,如果配置為0,則表示關掉keepalive,此時,http版本無論是1.1還是1.0,客戶端的connection不管是close還是keepalive,都會強制為close。

如果服務端最後的決定是keepalive打開,那麼在響應的http頭裡面,也會包含有connection頭域,其值是”Keep-Alive”,否則就是”Close”。如果connection值為close,那麼在nginx響應完數據後,會主動關掉連接。所以,對於請求量比較大的nginx來說,關掉keepalive最後會產生比較多的time-wait狀態的socket。一般來說,當客戶端的一次訪問,需要多次訪問同一個server時,打開keepalive的優勢非常大,比如圖片服務器,通常一個網頁會包含很多個圖片。打開keepalive也會大量減少time-wait的數量。

相關推薦

推薦中...