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

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

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

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

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

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

多網(wǎng)卡,比如之前A服務器的啟動的監(jiān)聽端口都在IPA的,原B服務器遷移進來后監(jiān)聽的端口都在IPB上,這樣就實現(xiàn)了一臺服務器上,監(jiān)聽了多個重復端口的問題,我們只要將IPA和IPB分別綁定到不同的域名上即可實現(xiàn)客戶端無感的服務器遷移
使用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;  # 新的端口,這里有一個關鍵點,如果我們是ssl的,這里使用https的連接,如果沒有ssl,這里需要設置為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和后端服務器也會建立長連接,一旦我們的后端進程重啟了,客戶端還是會感知到.

拓展1: 負載均衡分類

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

4層負載均衡

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

請求的路徑是:

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

響應的路徑是:

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

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

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

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

7層負載均衡

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

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

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

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

請求路徑: