摘要

在詳解http報(bào)文相關(guān)文章中我們介紹了http協(xié)議是如何工作的，那么構(gòu)建一個(gè)真實(shí)的網(wǎng)站還需要引入組件呢?一些常見的名詞到底是什么含義呢礁哄？

1. 什么叫正向代理尤蛮，什么叫反向代理
2. 服務(wù)代理與負(fù)載均衡的差別
3. 有了nginx屡律，為啥還需要LVS
4. 都有哪些負(fù)載均衡的方式

服務(wù)端演進(jìn)

在前面文章中我們介紹過最簡單的一種客戶端-服務(wù)端響應(yīng)模式掩驱，如下

image

這是http服務(wù)最簡單的一種形式，服務(wù)端就一層web服務(wù)器穿剖。

現(xiàn)在我們服務(wù)端變復(fù)雜了蚤蔓，用戶數(shù)增加了，并發(fā)量增加了糊余。對我們服務(wù)端要求增加了

• 服務(wù)能力：一臺(tái)服務(wù)器滿足不了這么多的http的請求了秀又。我們需要增加機(jī)器了，進(jìn)行服務(wù)擴(kuò)容了
• 安全防護(hù)：開始有人對我們的服務(wù)進(jìn)行網(wǎng)絡(luò)攻擊了贬芥，需要保護(hù)服務(wù)端服務(wù)器吐辙，限制ip地址
• 網(wǎng)站升級: 網(wǎng)站上線后，需要提供7*24小時(shí)無間斷服務(wù)了蘸劈，發(fā)布新的版本昏苏，需要保證網(wǎng)站的可用。

代理服務(wù)

為了解決這些問題，我們需要引入中間層也就是代理捷雕，在客戶端和服務(wù)端中間插入一個(gè)中間環(huán)節(jié)，代理服務(wù)壹甥。代理救巷，狹義上講就是不生產(chǎn)內(nèi)容，只是轉(zhuǎn)發(fā)上下游的請求和響應(yīng)句柠。

代理服務(wù)按照是否匿名可以分為

• 匿名代理： 外部不知道真實(shí)機(jī)器浦译，只知道代理服務(wù)器
• 透明代理： 外界知道代理，也知道真實(shí)服務(wù)器

按照靠近客戶端還是服務(wù)端溯职，分為

• 正向代理： 代理客戶端精盅，代表著客戶端向服務(wù)器端發(fā)送請求
• 反向代理： 代理服務(wù)端，代表著服務(wù)器向客戶端發(fā)送請求谜酒。

http協(xié)議對代理的支持

因?yàn)閔ttp協(xié)議最開始并沒有考慮代理服務(wù)叹俏，設(shè)計(jì)的協(xié)議只是針對客戶端-服務(wù)器模式。根據(jù)我們通常的架構(gòu)標(biāo)準(zhǔn)僻族，http協(xié)議層是不用關(guān)心使用者是如何使用的粘驰，代理服務(wù)這種中間產(chǎn)物自然不用考慮。服務(wù)端有獲取客戶端ip的需求述么，所以Squid這個(gè)緩存代理軟件最先引入X-Forwarded-For頭字段蝌数，用來表示 客戶端的真實(shí) IP。

格式如下度秘，從客戶端到各個(gè)代理服務(wù)顶伞，記錄下每一層的轉(zhuǎn)發(fā)

X-Forwarded-For: client, proxy1, proxy2

這個(gè)需求是如此的普世，所以慢慢變成了標(biāo)準(zhǔn)剑梳，被各個(gè)代理服務(wù)廣泛使用唆貌，所以后來被寫入到RFC 7239標(biāo)準(zhǔn)之中了

代理協(xié)議

HTTP 協(xié)議本身對代理服務(wù)并沒有什么說明，所以就衍生出了代理協(xié)議阻荒，代理協(xié)議是haproxy的作者Willy Tarreau于2010年開發(fā)和設(shè)計(jì)的一個(gè)Internet協(xié)議挠锥，通過為tcp添加一個(gè)很小的頭信息，來方便的傳遞客戶端信息（協(xié)議棧侨赡、源IP蓖租、目的IP、源端口羊壹、目的端口等)蓖宦，在網(wǎng)絡(luò)情況復(fù)雜又需要獲取客戶IP時(shí)非常有用。

• 多層NAT網(wǎng)絡(luò)
• TCP代理（四層）或多層tcp代理
• https反向代理http(某些情況下由于Keep-alive導(dǎo)致不是每次請求都傳遞x-forword-for)
• https通信加密油猫，不允許修改原始報(bào)文

另外由于每一層代理服務(wù)都需要解析http header 頭X-Forwarded-For稠茂，然后追加自己的地址，所以這個(gè)成本也比較高。所以代理協(xié)議也變成了剛需,雖然是haproxy提出來的睬关，但是也被各大代理服務(wù)器支持了诱担，如nginx、apache电爹、squid蔫仙。代理協(xié)議格式

PROXY TCP4/TCP6 客戶端ip 應(yīng)答方ip 請求方端口號  應(yīng)答方端口號 \r\n

這樣請求方解析第一行就可以拿到客戶端ip,不用再去處理http報(bào)文了。

負(fù)載均衡

負(fù)載均衡丐箩，其實(shí)就是分發(fā)請求摇邦。根據(jù)OSI七層協(xié)議

image

負(fù)載均衡分成兩種

• 4層負(fù)載均衡，即工作在第四層傳輸層屎勘，利用ip地址端口進(jìn)行請求轉(zhuǎn)發(fā)施籍，因?yàn)闆]有其他操作，所以效率比較高
• 七層負(fù)載均衡概漱，即工作在第七層應(yīng)用層丑慎，根據(jù)HTTP請求頭，URL信息轉(zhuǎn)發(fā)特定的主機(jī)犀概。效率相對低一點(diǎn)立哑。

nginx是七層負(fù)載均衡，LVS是七層負(fù)載均衡姻灶。

所以小型網(wǎng)站铛绰，nginx就足夠，當(dāng)流量足夠大時(shí)产喉，負(fù)載均衡成為瓶頸了捂掰，就可以在前面引入了LVS一層。

關(guān)于具體的負(fù)載均衡算法曾沈，參考這邊文章,這里不再贅述

安全防護(hù)

前面我們提到過安全防護(hù)也是代理服務(wù)的一大重要功能这嚣。為了應(yīng)對外部攻擊，需要引入網(wǎng)絡(luò)防火墻塞俱，WAF(Web Application Firewall)姐帚。工作在OSI 第七層，主要是對http報(bào)文進(jìn)行更細(xì)致的審核障涯，也就是各種filter罐旗。
比如

• IP 黑白名單
• DDOS攻擊
• 各種注入

當(dāng)服務(wù)的安全性要求沒那么高時(shí)，或者對公司業(yè)務(wù)發(fā)展的ROI沒那么高時(shí)唯蝶，我們通常就在nginx層面配置一些規(guī)則即可九秀。需求升級時(shí)，我們就要引入專門的模型粘我，比如ModSecurity1鼓蜒。需求再升級時(shí)，引入外部云廠商提供的WAF服務(wù)。

最終架構(gòu)形式

http服務(wù)端架構(gòu)演進(jìn)和我們單應(yīng)用架構(gòu)演進(jìn)有異曲同工之處都弹。在業(yè)務(wù)不復(fù)雜的時(shí)候娇豫，可以使用單體模塊搞定（比如Nginx），當(dāng)請求量增加畅厢，需求升級時(shí)锤躁，需要引入中間層來解決。當(dāng)某個(gè)模塊要求增加時(shí)或详，需要解耦出單獨(dú)的模塊來處理。

所以整體上看郭计，一個(gè)中型的服務(wù)端架構(gòu)如下圖霸琴。

image

參考

https://juejin.im/post/5ccaaf0af265da035e213490

https://www.cnblogs.com/xybaby/p/7867735.html

關(guān)注公眾號【方丈的寺院】，第一時(shí)間收到文章的更新昭伸，與方丈一起開始技術(shù)修行之路

在這里插入圖片描述

相關(guān)閱讀
詳解http報(bào)文

詳解http報(bào)文（2）-web容器是如何解析http報(bào)文的