http服務端架構演進

2021-09-29 01:49:40 字數 1809 閱讀 2953

什麼叫正向**,什麼叫反向**

服務**與負載均衡的差別

有了nginx,為啥還需要lvs

都有哪些負載均衡的方式

在前面文章中我們介紹過最簡單的一種客戶端-服務端響應模式,如下

這是http服務最簡單的一種形式,服務端就一層web伺服器。

現在我們服務端變複雜了,使用者數增加了,併發量增加了。對我們服務端要求增加了

為了解決這些問題,我們需要引入中間層也就是**,在客戶端和服務端中間插入乙個中間環節,**服務。**,狹義上講就是不生產內容,只是**上下游的請求和響應。

**服務按照是否匿名可以分為

按照靠近客戶端還是服務端,分為

因為http協議最開始並沒有考慮**服務,設計的協議只是針對客戶端-伺服器模式。根據我們通常的架構標準,http協議層是不用關心使用者是如何使用的,**服務這種中間產物自然不用考慮。服務端有獲取客戶端ip的需求,所以squid這個快取**軟體最先引入x-forwarded-for頭欄位,用來表示 客戶端的真實 ip。

格式如下,從客戶端到各個**服務,記錄下每一層的**

x-forwarded-for: client, proxy1, proxy2
這個需求是如此的普世,所以慢慢變成了標準,被各個**服務廣泛使用,所以後來被寫入到rfc 7239標準之中了

http 協議本身對**服務並沒有什麼說明,所以就衍生出了**協議,**協議是haproxy的作者willy tarreau於2023年開發和設計的乙個internet協議,通過為tcp新增乙個很小的頭資訊,來方便的傳遞客戶端資訊(協議棧、源ip、目的ip、源埠、目的埠等),在網路情況複雜又需要獲取客戶ip時非常有用。

另外由於每一層**服務都需要解析http header 頭x-forwarded-for,然後追加自己的位址,所以這個成本也比較高。所以**協議也變成了剛需,雖然是haproxy提出來的,但是也被各大**伺服器支援了,如nginx、apache、squid。**協議格式

proxy tcp4/tcp6 客戶端ip 應答方ip 請求方埠號  應答方埠號 \r\n
這樣請求方解析第一行就可以拿到客戶端ip,不用再去處理http報文了。

負載均衡,其實就是分發請求。根據osi七層協議

負載均衡分成兩種

nginx是七層負載均衡,lvs是四層負載均衡。

所以小型**,nginx就足夠,當流量足夠大時,負載均衡成為瓶頸了,就可以在前面引入了lvs一層。

當服務的安全性要求沒那麼高時,或者對公司業務發展的roi沒那麼高時,我們通常就在nginx層面配置一些規則即可。需求公升級時,我們就要引入專門的模型,比如modsecurity1。需求再公升級時,引入外部雲廠商提供的waf服務。

http服務端架構演進和我們單應用架構演進有異曲同工之處。在業務不複雜的時候,可以使用單體模組搞定(比如nginx),當請求量增加,需求公升級時,需要引入中間層來解決。當某個模組要求增加時,需要解耦出單獨的模組來處理。

所以整體上看,乙個中型的服務端架構如下圖。

詳解http報文(2)-web容器是如何解析http報文的

HTTP服務端JSON服務端

最後更新日期 2014 5 18 author kagula 內容簡介 cppcms是個開源web開發框架,通過它可以很容易實現http服務和json服務,這裡介紹cppcms開發環境的搭建。寫乙個cppcms測試程式,它建立http服務,向瀏覽器返回hello,world頁面。cppcms依賴的一...

MMORPG 服務端架構隨想

今天因為工作需要,要了解遊戲伺服器端架構設計,看到一篇文章,提到了 eve online 歐洲伺服器重新整理了單台伺服器最高上線人數的世界紀錄,支援 23178 個使用者,它的伺服器架構是 windows os sql server,使用高效能的 iocp 網路 i o模型為網路層,配合 smp s...

HTTP服務端返回狀態詳解

當伺服器響應時,其狀態行的資訊為http的版本號,狀態碼,及解釋狀態碼的簡單說明。現將5類狀態碼詳細列出 客戶方錯誤 100 繼續 101 交換協議 成功 200 ok 201 已建立 202 接收 203 非認證資訊 204 無內容 205 重置內容 206 部分內容 重定向 300 多路選擇 3...