引用區塊皆為個人看法,或是延伸查詢到得內容,如有任何錯誤還請見諒。並歡迎直接更改,或是提供建議。
Nginx 最初為網路伺服器,作用為接受客戶端的請求(request),視情況與資料庫協作,回傳客戶端恰當的回應(response)。
隨著網路的蓬勃發展,面對眾多網站流量的恣意增長,超載或是惡意攻擊開始變得頻繁。此時,Nginx開始被當作反向代理伺服器(reverse proxy server),提供基礎資安(security)、負載平衡(load balancing)、網路快取(Http caching, web caching)、資料的壓縮與切割(compression and segmentation)等功能。
由於一個網站可能不只使用一個伺服器,開放所有伺服器接收請求可能會造成上述的諸多問題。此時我們可以利用一個或少量的反向代理伺服器作為入口,並將真正處裡後續作業的伺服器藏之身後。
反向代理伺服器有點像某些大樓的保全一樣,控制哪些人可以進出(資安),人多時將人流導向人數較少的路徑(負載平衡)。當然每個保全職責不盡相同,每個反向代理伺服器的功能同樣如此,其確切功能端看使用者的規劃與設定。而方便設定也是Nginx的一大特點。
既然有反向代理伺服器,那當然就有代理伺服器。代理伺服器指主要服務客服端,讓客戶端ip不會因為發出的請求被識破,提供基礎的安全性保障。不過要特別注意,雖然作用相近,proxy server不是VPN,VPN提供的功能又更多一點。
既然身為伺服端的主要入口,Nginx也經常在此進行基礎的資安驗證。例如,發來的請求是否為HTTPS認證。HTTPS 相較於傳統的HTTP會將傳遞的資料加密,比較不易遇到中間人攻擊(MITM, Man-in-the-middle Attack),被鑲嵌入惡意的內容。
關於 HTTPS 與 HTTP 的一般差異與安全性考量,可以參考cloudfare的入門解說
雖然也可以在各個伺服器上分別驗證,但當系統龐大且複雜時,難保遺漏某一個伺服器的某一個資安檢測。因此在反向代理伺服器安上基本的檢測是為顯學。
顧名思義,為了避免流量超載,將請求導向目前負載較低的伺服器。平衡整個伺服器們的負載,讓伺服器端能正常運作。
當某個檔案被眾多客戶端反覆請求時,反向伺服器得一直傳遞同樣的請求,各個伺服器處理同樣的請求,向資料庫提取資料,回傳到反向伺服器,反向伺服器再傳到客戶端。這樣既耗時間又耗資源,此時便可利用快取的概念來提升效率。
具體作法為,將經常被請求的檔案儲存在反向伺服器上,一有對此檔案的請求,反向伺服器便可直接回傳,不用再傳遞此請求給伺服器們。如此一來,便可節省許多後續伺服器與資料庫的反覆動作。
這種做法就像超商的咖啡機一樣。很多人流量大的超商咖啡機,已經不是放在櫃頭後,由店員接受顧客點單後操作。而是直接將咖啡機搬到商品區,由客戶自己拿杯子,自行按鈕裝咖啡,等裝完杯後再結帳。如此便可節省超商店員的負擔,加速結帳的流程。網路存取便是類似的概念,將流程往客戶端挪動,減少伺服端的壓力。
這種操作常見於靜態檔案(Static files),例如某個流量大的官網首頁等。另外,當然也可以把一個網站拆成不同檔案,部分存於反向伺服器,部分走傳統路徑。一切都是看架構上的取捨。
CDN 基本上就是在做檔案快取的這件事。只不過這裡,反向伺服器只是一個單點,而CDN強調網絡(Network),服務客戶端上更加全面。 cloudfare cdn一文一樣有淺顯易懂的解釋。
網路快取雖然方便,但當然也會帶來資料未跟上最新版本,如何驗證,如何更新等等複雜的問題。同時過度依賴單一快取點,也有可能增加單點故障(single point of failure)的風險。最後,要如何實踐這個快取又是另一個大問題。假設所有常見的檔案都丟到快取裡,快取沒管理好塞爆,這樣還有意義嗎?Space complexity vs time complexity 永遠是個問題。
當檔案過大或是傳輸太慢,網速延遲將是多數人的夢魘。尤其一個美好的週末,本來想好好的看個Netflix,看著永遠都在轉圈圈的螢幕,有時候真的會很不爽。
這時候便是資料壓縮登場的時候了。壓縮會將檔案變小,等到了客戶端實再解壓縮即可。如此便可降低網路的延遲。Nginx不只可以壓縮送往客戶端的檔案,也可以壓縮送往伺服端的請求檔案。
資料切割則是將資料切成很多塊,分批丟給前端。這樣前端變不用等到整包資料都載完再執行下一步,可以執行第一包同時載入後續的資料。讓使用者不會有等很久的感覺,經典案例就是影片。很多時候youtube或是Netflix都是分批丟影片到我們客戶端,因此一個60分鐘的影片一開始其實只載入前10分鐘,在我們觀看這前10分鐘時依序載入後續。
以下皆為為影片內容,但較為淺顯,多數為簡單但難以真正理解形容詞。目前我也不懂真正邏輯。這段看了霧煞煞很正常。
上述功能不少伺服器都能分別做到,尤其是老牌的Apache。然而,Nginx相較之下有幾個優點。
沒錯,就是一開始就說的反向代理伺服器。任何大型的伺服端架構都可使用。
kubernetes 是一個容器(container) 的管理工具,會讓container增加時的結構管理更容易。更多相關資訊可以參考AWS或是k8s自己的解釋。不懂也不影響後續理解,其實我自己也還不大懂。
一個k8s(kubernetes)內可能有很多的容器集(pod),一個容器集中可能含一個或多個容器。當資訊打進一個k8s時,系統怎們知道要將流量導到哪個容器集呢?Nginx這時候就派上用場了。跟作為反向伺服器時非常類似,它可以做到負載平衡的作用。
當然一個k8s通常為雲端服務商內部的一個應用,這些雲端服務商依然會有自己的反向代理伺服器,等他們做完工後,在將需求導至k8s的入口管理器。至於反向代理伺服器和k8s的入口管理器是否使用Nginx就看企業選擇。