使用nginx作為websocket的proxy server

blog.csdn.net/zhx6044/article/details/50278765

WebSocket

WebSocket協議為創建客戶端和服務器端需要實時雙向通訊的webapp提供了一個選擇。其為HTML5的一部分，WebSocket相較於原來開發這類app的方法來說，其能使開發更加地簡單。大部分現在的瀏覽器都支持WebSocket，比如Firefox，IE，Chrome，Safari，Opera，並且越來越多的服務器框架現在也同樣支持WebSocket。

在實際的生產環境中，要求多個WebSocket服務器必須具有高性能和高可用，那么WebSocket協議就需要一個負載均衡層，NGINX從1.3開始支持WebSocket，其可以作為一個反向代理和為WebSocket程序做負載均衡。

WebSocket協議不同於HTTP協議，但是WebSocket握手是通過HTTP來完成的，使用HTTP的Upgrade設施來升級連接從HTTP到WebSocket。這個允許WebSocket程序能夠更簡單地融入現有的基礎設施。比如，WebSocket程序可以使用80和443標准的HTTP端口，從而允許使用存在的防火牆策略。

一個WebSocket程序持有一個長時間運行的在客戶端和服務器端之間打開的連接，促進實時應用程序的開發(這個翻譯有問題)。被用來升級連接從HTTP到WebSocket的HTTP Upgrade機制使用Upgrade和Connection頭部來完成。在反向代理服務器支持WebSocket中，需要面臨一些挑戰。第一個是WebSocket是一個hop-by-hop協議，所以當代理服務器攔截來至於客服端的一個Upgrade請求時，代理服務器需要發送它自己的Upgrade請求給后端服務器，包括一些合適的頭部。同樣，因為WebSocket是長時間存活，相反的，HTTP連接是典型的短連接，反向代理服務器必須允許這些連接保持打開，而不是在它們看起來閑置時關閉它們。

nginx

NGINX通過允許一個在客戶端和后端服務器之間建立的隧道來支持WebSocket。為了NGINX發送來至於客戶端Upgrade請求到后端服務器，Upgrade和Connection頭部必須被設置明確。

示例，這個例子在我前面文章中使用過–chatRobot。上次是客戶端直接連的express程序，這里我們使用nginx來做代理。

 upstream wsbackend {
        server 127.0.0.1:3000;
    }

    server {
        listen       8090;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        # location / {
        #    root   html;
        #    index  index.html index.htm;
        # }

        location / {
            proxy_pass http://wsbackend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
    }

 

我們將qt程序中的鏈接改一下

const char* server_url = "ws://localhost:8090";

 

我們的chatRobot還是一樣的可以運行。

其實這只是一個簡單地接合nginx和nodejs的例子。
這里我總結了幾點我們為什么把nginx放在前面的。

• nodejs適合做為restful api接口和動態的頁面生成，雖然也有靜態資源托管模塊，但是會大幅度影響nodejs的性能，但是nginx適合處理靜態資源。所以讓它們做自己擅長的事。
• 安全，直接在外網暴露nodejs會有很大的風險。
• 卸HTTPS，nginx與客戶端連接加密，后端的nodejs和nginx處於內網環境下，可以不加密，這樣省去了nodejs卸https的負載。
• nginx作為反向代理和負載均衡，方便后台nodejs的橫向擴展。

使用nginx是為了更好地使用nodejs來提供服務。