遇到的問題: 如何使用nginx代理ws或是wss的請(qǐng)求

起因是,為了降本增效要做服務(wù)器合并的需求,但兩個(gè)服務(wù)器之間的進(jìn)程存在對(duì)外連接的端口沖突,如果我們改了端口,客戶端也會(huì)涉及到修改,但客戶端的版本太舊了,想改變和重新發(fā)版流程會(huì)拉的很長,所以我們嘗試別的方法來解決端口修改的問題

因?yàn)榉?wù)器的時(shí)間比較舊了,所以客戶端并沒有先連負(fù)載均衡再連服務(wù)器 針對(duì)這個(gè)問題我們提供了下面兩個(gè)方案

• 多網(wǎng)卡,比如之前A服務(wù)器的啟動(dòng)的監(jiān)聽端口都在IPA的,原B服務(wù)器遷移進(jìn)來后監(jiān)聽的端口都在IPB上,這樣就實(shí)現(xiàn)了一臺(tái)服務(wù)器上,監(jiān)聽了多個(gè)重復(fù)端口的問題,我們只要將IPA和IPB分別綁定到不同的域名上即可實(shí)現(xiàn)客戶端無感的服務(wù)器遷移
• 使用nginx做端口映射

最終我們選擇了成本更低的nginx端口映射的做法 具體的代碼如下:

server {
    listen 7865 ssl; #監(jiān)聽的端口(客戶端連接的原端口)
    server_name a.b.com;  #監(jiān)聽的域名,非必須
    ssl_certificate      /etc/nginx/a.pem;   #證書
    ssl_certificate_key  /etc/nginx/a.key; #證書
        ssl_session_timeout 20m;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_verify_client off;
    location / {
        proxy_pass https://127.0.0.1:7899;  # 新的端口,這里有一個(gè)關(guān)鍵點(diǎn),如果我們是ssl的,這里使用https的連接,如果沒有ssl,這里需要設(shè)置為http
        proxy_http_version 1.1;  # 必須使用 HTTP 1.1
        proxy_redirect off;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

這里我們可以把nginx的這層反向代理看著是透明的,因?yàn)榭蛻舳撕蚽ginx建立長連接,而nginx和后端服務(wù)器也會(huì)建立長連接,一旦我們的后端進(jìn)程重啟了,客戶端還是會(huì)感知到.

拓展1: 負(fù)載均衡分類

我們按照起作用的ISO7層模式的層來區(qū)分的話,可以分為4層負(fù)載均衡和7層負(fù)載均衡

4層負(fù)載均衡

例如LVS或是AWS的NLB就是4層負(fù)載均衡 它的原理: 分別獲取包中的源IP地址和端口和目標(biāo)IP地址和端口,對(duì)后端做負(fù)載均衡(算法可能是輪詢或是權(quán)重等)后修改包中的目標(biāo)IP地址和端口,使其流量能得到轉(zhuǎn)發(fā)

請(qǐng)求的路徑是:

• 客戶端發(fā)出情況,數(shù)據(jù)包被送到負(fù)載均衡器
• 負(fù)載均衡通過源IP地址+端口和目標(biāo)IP+端口確定請(qǐng)求最后轉(zhuǎn)發(fā)到哪一臺(tái)后端服務(wù)器
• 負(fù)載均衡器通過修改目標(biāo)IP和端口
• 數(shù)據(jù)包被轉(zhuǎn)發(fā)到指定的后端服務(wù)器

響應(yīng)的路徑是:

• 后端程序進(jìn)行業(yè)務(wù)處理
• 如果負(fù)載均衡器做了NAT(為了讓后端進(jìn)程透明,目的是隱藏后端服務(wù)器,原理就是將源IP地址和源端口修改成負(fù)載均衡器的IP地址和端口),數(shù)據(jù)包會(huì)回到負(fù)載均衡器中
• 返回給客戶端

如果負(fù)載均衡器沒有NAT功能,或是配置為直連的方式,則響應(yīng)的數(shù)據(jù)包是不會(huì)經(jīng)過負(fù)載均衡器的,這個(gè)可以通過分析流量包的源IP地址和端口來確認(rèn)

4層負(fù)載均衡器的好處 4層負(fù)載均衡器不會(huì)解傳輸數(shù)據(jù)包,只會(huì)解header包從而獲取IP地址和端口,所以相對(duì)來說速度更快 什么時(shí)候我們需要使用4層負(fù)載均衡呢

• 非HTTP的時(shí)候
• 需要較高的性能
• 場(chǎng)景簡(jiǎn)單

7層負(fù)載均衡

例如nginx IIS就是7層的負(fù)載均衡

主要用于處理HTTP/HTTPS等應(yīng)用層協(xié)議。它不僅可以基于傳輸層信息（如IP地址和端口）進(jìn)行負(fù)載均衡，還可以深入解析應(yīng)用層數(shù)據(jù)，提供更靈活和高級(jí)的流量管理。

原理: 7層負(fù)載均衡器可以解析和檢查HTTP頭、URL、cookie、SSL信息等應(yīng)用層數(shù)據(jù)。這使得它能根據(jù)這些內(nèi)容做出智能的流量路由決策。 因?yàn)楸容^上層,所以可以做的事情比較多

• 基于內(nèi)容轉(zhuǎn)發(fā): 可以根據(jù)特定的URL路徑、域名、HTTP方法或其他應(yīng)用層數(shù)據(jù)，將請(qǐng)求定向到不同的服務(wù)器池。例如，將所有以"/images"結(jié)尾的請(qǐng)求路由到圖片服務(wù)器
• session保持: 通過使用cookie或其他機(jī)制，確保來自同一客戶端的所有請(qǐng)求都被轉(zhuǎn)發(fā)到同一個(gè)后端服務(wù)器，從而維護(hù)用戶會(huì)話的連續(xù)性
• 請(qǐng)求重定向: 能夠修改請(qǐng)求內(nèi)容或路徑，或?qū)⒄?qǐng)求重定向到其他資源或服務(wù)器
• 數(shù)據(jù)壓縮和緩存: 處理請(qǐng)求時(shí)，可以對(duì)響應(yīng)內(nèi)容進(jìn)行壓縮，減少傳輸?shù)臄?shù)據(jù)量。同時(shí)，還能緩存常見請(qǐng)求的響應(yīng)，降低后端服務(wù)器負(fù)擔(dān)

請(qǐng)求路徑:

• 客戶端發(fā)送請(qǐng)求到負(fù)載均衡器
• 負(fù)載均衡器通過分析內(nèi)容進(jìn)行轉(zhuǎn)發(fā)
• 請(qǐng)求達(dá)到具體的后端進(jìn)程

響應(yīng)路徑:

• 后端處理業(yè)務(wù)邏輯
• 響應(yīng)經(jīng)過負(fù)載均衡器
• 負(fù)載均衡器做一些優(yōu)化處理 例如緩存/壓縮等
• 響應(yīng)給客戶端

可以發(fā)現(xiàn),響應(yīng)是會(huì)經(jīng)過負(fù)載均衡器的,實(shí)際上客戶端和nginx建立了連接,nginx和后端進(jìn)程建立了連接實(shí)現(xiàn)了請(qǐng)求的轉(zhuǎn)發(fā)和請(qǐng)求的響應(yīng)

拓展2: 還有哪些負(fù)載均衡

使用rabbitMQ多個(gè)消費(fèi)者也可以實(shí)現(xiàn)負(fù)載均衡的作用

grpc+etcd實(shí)現(xiàn)的負(fù)載均衡

到此這篇關(guān)于如何使用nginx代理ws或是wss的請(qǐng)求的文章就介紹到這了,更多相關(guān)nginx代理ws或wss內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！