1.OSI網絡模型
網絡模型就是 OSI(Open System Interconnect),意思為開放網絡互聯,是由國際標準化組織(ISO)和國際電報電話諮詢委員會(CCITT)共同出版的,他是一種網絡互聯模型,也是一種規範。
網絡模型分為七層,也就是當用戶發起請求到服務器接收,會歷經七道工序,或者說用戶利用互聯網發送消息給另一個用戶,也會歷經七道工序。這七層可以分為如下:
以上七層每層可以與上下相鄰層進行通信。每一層都是非常複雜的,我們不在這裡深究,我們以舉例的形式來闡述每一層是幹嘛的。
- 應用層: 這是面向用戶的,最靠近用戶,為了讓用戶和計算機交互,在計算機裡會有很多軟件,比如eclipse,idea,qq,nginx等,這些都是應用軟件,用戶可以通過這些應用軟件和計算機交互,交互的過程其實就是接口的調用,應用層為用戶提供了交互的接口,以此為用戶提供交互服務。那麼在這一層最常見的協議有:HTTP,HTTPS,FTP,SMTP,POP3等。Nginx在本層,為七層負載均衡。
舉例:我要寄一封信給遠在天邊的老外LiLei,我會打開快遞軟件下單,這個時候我是用戶,快遞軟件就是應用服務,是建立在計算機上的,提供給用戶交互的一種服務或稱之為手段。
- 表示層: 該層提供數據格式編碼以及加密功能,確保請求端的數據能被響應端的應用層識別。
舉例:我寫中文給LiLei,他看不懂,這個時候我就會使用翻譯軟件把中文翻譯成英文,隨後信中涉及到一些比較隱私的信息我會加密一下,這個時候翻譯軟件和加密器就充當了表示層的作用,他用於顯示用戶能夠識別的內容。
- 會話層: 會話可以理解為session,請求發送到接受響應的這個過程之間存在會話,會話層就充當了這一過程的管理者,從創建會話到維護會話最後銷燬會話。
舉例:我每次寫信給LiLei都會記錄在一個小本本上,寄信時間日期,收信時間日期,這本小本本上存有每次通信記錄,這個小本本就相當於是一個會話的管理者。又或者說,我們平時在打電話,首先需要撥打電話,這是建立會話,對方接聽電話,此時正在通話(維持並管理會話),通話結束後會話銷燬,那麼這也是一次會話的生命週期。
- 傳輸層: 該層建立端到端的連接,他提供了數據傳輸服務,在傳輸層通信會涉及到端口號,本層常見的協議為TCP、UDP,LVS就是在傳輸層,也就是四層負載均衡。
舉例:我和LiLei通信過程中會藉助快遞公司,快遞公司會分配快遞員取件和寄件,那麼這個快遞員則充當傳輸層的作用。
- 網絡層: 網絡通信的時候必須要有本機IP和對方的IP,請求端和響應端都會有自己的IP的,IP就相當於你家地址門牌號,在網絡上雲服務器有固定的公網IP,普通計算機也有,只不過是動態IP,運營商每天會分配不同的IP給你的計算機。所以網絡層也能稱之為IP層,IP是互聯網的基礎根本。能提供IP分配的設備則為路由器或交換機。
舉例:對於擁有固定IP的雲服務來說,他們都是由騰訊雲、阿里雲等這樣的供應商提供的,他們為雲服務器提供固定ip;電信、移動、聯調等運營商為你的計算機動態分配ip,每天都不同;則這些供應商和運營商都是網絡層。同理,快遞員由物流公司分配和管理,那麼物流公司就是網絡層咯。
- 數據鏈路層: 這一層會提供計算機MAC地址,通信的時候會攜帶,為了確保請求投遞正確,所以他會驗證檢測MAC地址,以確保請求響應的可靠性。
舉例:快遞員在投遞派送的時候,他(或客服)會預先提前打電話給你,確認你家地址對不對、有沒有人、貨到付款有沒有準備好錢等等,這個時候快遞員(或客服)就充當了數據鏈路層的職責。
- 物理層: 端到端請求響應過程中的媒介,物理介質,比如網線、中繼器等等設備,都是你在端到端交互過程中不可缺少的基礎設備。
舉例:快遞員在投遞的過程中,你寫的信會歷經一些交通運輸工具,比如首先通過飛機運輸到國外,在海關統一拿到信以後會通過汽車運輸到LiLei所在城市的物流集散地,最後快遞員通過三輪電頻車寄到LiLei家裡,這個時候,飛機、汽車、三輪電瓶車都是物理層的媒介。
以上就是七層網絡模型,大家理解其意義即可。需要注意的是Nginx存在於第七層,屬於七層負載均衡;而第四層會有LVS,屬於四層負載均衡。
2.Nginx的集群負載均衡解析
負載均衡:當有大量的併發請求來到服務器的時候,把這些請求分配到多臺計算機節點上,讓更多的節點來處理請求和響應,來大大的減少用戶的等待時間
2.1 負載均衡分類
- 四層負載均衡:ip+端口形式進行負載均衡,通過轉發到後臺的服務器,通過轉發並且會記錄是由哪個服務器處理的,當下一次請求進來時還是讓同一臺服務器來處理請求,相當於長連接,一旦打開就會一直處於連接狀態,是傳輸層基於TCP和UDP
- 七層負載均衡:基於URL或ip的負載均衡,是應用層的,基於HTTP協議的負載均衡
2.2 Nginx配置集群
<code>upstream
tomcats{server
192.168.1.173:8080
;server
192.168.1.174:8080
;server
192.168.1.175:8080
; }server
{listen
80
;server_name
ww.tomcats.com;location
/{proxy_pass
http://tomcats; } } /<code>
2.3 Nginx 負載均衡策略
- 權重配置方式
<code>upstream
tomcats{
server
192.168
.1
.173
:8080
weight=1;
server
192.168
.1
.174
:8080
weight=2;
server
192.168
.1
.175
:8080
weight=3;
}
/<code>
- ip_hash配置方式
<code>upstream
tomcats{
ip_hash
server
192.168
.1
.173
:8080;
server
192.168
.1
.174
:8080;
server
192.168
.1
.175
:8080;
}
/<code>
- least_conn配置方式
<code>upstream
tomcats{
least_conn;
server
192.168
.1
.173
:8080;
server
192.168
.1
.174
:8080;
server
192.168
.1
.175
:8080;
}
/<code>
- fair配置方式
<code>upstream
tomcats{
fair
server
192.168
.1
.173
:8080;
server
192.168
.1
.174
:8080;
server
192.168
.1
.175
:8080;
}
/<code>
- url配置方式
<code>upstream
tomcats{hash
$request_uri
;server
192.168.1.173:8080
;server
192.168.1.174:8080
;server
192.168.1.175:8080
; }/<code>
2.4 upstream指令參數
- max_conns:限制每臺server的連接數,用於保護避免過載,可起到限流作用。
測試參考配置如下:
<code>worker_processes
1
;
upstream
tomcats
{
server
192.168
.1
.173
:8080
max_conns=2;
server
192.168
.1
.174
:8080
max_conns=2;
server
192.168
.1
.175
:8080
max_conns=2;
}
/<code>
- slow_start:使某一臺服務器慢慢的加入到集群當中
注:商業版,需要付費
配置參考如下:
<code>upstream
tomcats
{
server
192.168
.1
.173
:8080
weight=6
slow_start=60s;
server
192.168
.1
.174
:8080
weight=2;
server
192.168
.1
.175
:8080
weight=2;
}
/<code>
注意:該參數不能使用在hash和random load balancing中。如果在 upstream 中只有一臺 server,則該參數失效。
- down:用於標記服務節點不可用
配置參考如下:
<code>upstream
tomcats
{
server
192.168
.1
.173
:8080
down;
server
192.168
.1
.174
:8080
weight=1;
server
192.168
.1
.175
:8080
weight=1;
}
/<code>
- backup:表示當前服務器節點是備用機,只有在其他的服務器都宕機以後,自己才會加入到集群中,被用戶訪問到:
配置參考如下:
<code>upstream
tomcats
{
server
192.168
.1
.173
:8080
backup;
server
192.168
.1
.174
:8080
weight=1;
server
192.168
.1
.175
:8080
weight=1;
}
/<code>
backup:表示當前服務器節點是備用機,只有在其他的服務器都宕機以後,自己才會加入到集群中,被用戶訪問到:
配置參考如下:
<code>upstream
tomcats
{
server
192.168
.1
.173
:8080
backup;
server
192.168
.1
.174
:8080
weight=1;
server
192.168
.1
.175
:8080
weight=1;
}
/<code>
假設目前設置如下:
max_fails=2 fail_timeout=15s
則代表在15秒內請求某一server失敗達到2次後,則認為該server已經掛了或者宕機了,隨後再過15秒,這15秒內不會有新的請求到達剛剛掛掉的節點上,而是會請求到正常運作的server,15秒後會再有新請求嘗試連接掛掉的server,如果還是失敗,重複上一過程,直到恢復。
- Keepalived 提高吞吐量
- keepalived: 設置長連接處理的數量
- proxy_http_version:設置長連接http版本為1.1
- proxy_set_header:清除connection header 信息
<code>upstream
tomcats {keepalive
32
; }server
{listen
80
;server_name
www.tomcats.com;location
/ {proxy_pass
http://tomcats;proxy_http_version
1
.1
;proxy_set_header
Connection""
; } } /<code>
3.ip_hash算法與一致性hash算法
ip_hash:通過對ip進行hash後按照服務器個數取模,然後分配到不同的服務器中,穩定的情況下可以保證每一個ip每次都請求到同一臺服務器上,但是有一個問題:當增加或移除服務器時會導致所有的用戶ip都要在重新計算分配的服務器。
一致性hash算法:將0到2的32次方減一的數做成一個環,將用戶和節點都放到這個環上,把用戶ip順時針放到離他最近的一臺服務器上,這樣增加和減少服務器之後影響到一部分用戶,而不會影響到所有用戶
4.Nginx的跨域問題
4.1 跨域資源共享(CORS)
跨域資源共享(CORS) 是一種機制,它使用額外的 HTTP 頭來告訴瀏覽器 讓運行在一個 origin (domain) 上的Web應用被准許訪問來自不同源服務器上的指定的資源。當一個資源從與該資源本身所在的服務器不同的域、協議或端口請求一個資源時,資源會發起一個跨域 HTTP 請求。
CORS需要瀏覽器和服務器同時支持,才可以實現跨域請求,目前幾乎所有瀏覽器都支持CORS,IE則不能低於IE10。CORS的整個過程都由瀏覽器自動完成,前端無需做任何設置,跟平時發送ajax請求並無差異。so,實現CORS的關鍵在於服務器,只要服務器實現CORS接口,就可以實現跨域通信。
4.2 如何解決跨域問題
目前基本上主流有三種解決方式:JsonP,SpringBoot,Nginx,我們今天來說說Nginx是如何解決跨域問題的
4.3 Nginx通過配置解決跨域問題
<code>在server模塊中添加下面的信息
server
{
listen
88;
server_name
localhost;
add_header
'Access-Control-Allow-Origin' *;
add_header
'Access-Control-Allow-Credentials' 'true';
add_header
'Access-Control-Allow-Methods' *;
add_header
'Access-Control-Allow-Headers' *;
location
/ {
root
html;
index
index.html index.htm;
}
}
/<code>
5.緩存
5.1瀏覽器緩存
加速用戶訪問,提升單個用戶(瀏覽器訪問者)體驗,緩存在本地
<code>location
/{
alias
/home/;
expires
max;最大緩存時間
}
/<code>
5.2 Nginx反向代理緩存
緩存在nginx端,提升所有訪問到nginx這一端的用戶
提升訪問上游(upstream)服務器的速度
用戶訪問仍然會產生請求流量
<code>proxy_cache_path
/usr/local/nginx/upstream_cache keys_zone=mycache:5m
max_size=1g
inactive=1m
use_temp_path=off
;location
/ {proxy_pass
http://tomcats;proxy_cache
mycache;proxy_cache_valid
200
304
8h
; } /<code>
6.Nginx的模塊化設計解析
Nginx的主要模塊構成
- nginx croe:非常核心的內容,為底層提供一些通信協議,也為其他模塊和nginx運行時提供一些條件,可以把他理解成一個jmv
- http:核心中的一部分
- mail:與郵件相關
- event module:事件模塊,在linux下的epllo,操作系統層面的處理機制
- phase handler:處理客戶端的一些請求,處理後負責處理一些響應
- output filter:是一個過濾器,過濾掉一些響應後在返回給客戶端
- upstream:反向代理模塊,會把真正的請求轉發到真實的服務器
- load balancer 負載均衡器
- extend module 繼承模塊,與第三方有關