快捷導(dǎo)航

如何使用nginx代理ws或是wss的請求

更新時間：2024年11月30日 14:42:17 作者：daiyunchao

這篇文章主要為大家詳細介紹了如何使用nginx代理ws或是wss的請求,文中的示例代碼講解詳細,感興趣的小伙伴可以跟隨小編一起學(xué)習(xí)一下

遇到的問題: 如何使用nginx代理ws或是wss的請求

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

因為服務(wù)器的時間比較舊了,所以客戶端并沒有先連負載均衡再連服務(wù)器針對這個問題我們提供了下面兩個方案

多網(wǎng)卡,比如之前A服務(wù)器的啟動的監(jiān)聽端口都在IPA的,原B服務(wù)器遷移進來后監(jiān)聽的端口都在IPB上,這樣就實現(xiàn)了一臺服務(wù)器上,監(jiān)聽了多個重復(fù)端口的問題,我們只要將IPA和IPB分別綁定到不同的域名上即可實現(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;  # 新的端口,這里有一個關(guā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的這層反向代理看著是透明的,因為客戶端和nginx建立長連接,而nginx和后端服務(wù)器也會建立長連接,一旦我們的后端進程重啟了,客戶端還是會感知到.

拓展1: 負載均衡分類

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

4層負載均衡

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

請求的路徑是:

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

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

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

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

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

非HTTP的時候
需要較高的性能
場景簡單

7層負載均衡

例如nginx IIS就是7層的負載均衡

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

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

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

請求路徑: