建站
咨詢
售后
建站咨詢
新聞中心
Golang 端口轉(zhuǎn)發(fā)工具
初學(xué)go，寫一個(gè)端口轉(zhuǎn)發(fā)工具。很方便的小工具，希望能對(duì)大家學(xué)習(xí)go語(yǔ)言有所幫助。
創(chuàng)新互聯(lián)建站主要從事網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)江南,十多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):13518219792
```Golang
package main
import(
"fmt"
"io"
"net"
"sync"
)
varlocksync.Mutex
vartrueList[]string
varipstring
varliststring
funcmain(){
ip="0.0.0.0:888"
server()
}
funcserver(){
fmt.Printf("Listening%s",ip)
lis,err:=net.Listen("tcp",ip)
iferr!=nil{
fmt.Println(err)
return
}
deferlis.Close()
for{
conn,err:=lis.Accept()
iferr!=nil{
fmt.Println("建立連接錯(cuò)誤:%v\n",err)
continue
}
fmt.Println(conn.RemoteAddr(),conn.LocalAddr())
gohandle(conn)
}
}
funchandle(sconnnet.Conn){
defersconn.Close()
ip:="127.0.0.1:8888"
dconn,err:=net.Dial("tcp",ip)
iferr!=nil{
fmt.Printf("連接%v失敗:%v\n",ip,err)
return
}
ExitChan:=make(chanbool,1)
gofunc(sconnnet.Conn,dconnnet.Conn,Exitchanbool){
io.Copy(dconn,sconn)
ExitChan-true
}(sconn,dconn,ExitChan)
gofunc(sconnnet.Conn,dconnnet.Conn,Exitchanbool){
io.Copy(sconn,dconn)
ExitChan-true
}(sconn,dconn,ExitChan)
-ExitChan
dconn.Close()
}
WebSocket+SLB（負(fù)載均衡）會(huì)話保持解決重連問(wèn)題
寫在最前面：由于現(xiàn)在游戲基本上采用全球大區(qū)的模式，全球玩家在同一個(gè)大區(qū)進(jìn)行游戲，傳統(tǒng)的單服模式已經(jīng)不能夠滿足當(dāng)前的服務(wù)需求，所以現(xiàn)在游戲服務(wù)器都在往微服務(wù)架構(gòu)發(fā)展。當(dāng)前我們游戲也是利用微服務(wù)架構(gòu)來(lái)實(shí)現(xiàn)全球玩家同服游戲。
玩家每次斷線（包括切換網(wǎng)絡(luò)/超時(shí)斷線）后應(yīng)該會(huì)重新連接服務(wù)器，重連成功的話可以繼續(xù)當(dāng)前情景繼續(xù)游戲，但是之前寫的底層重連機(jī)制一直不能生效，導(dǎo)致每次玩家斷線后重連都失敗，要從賬號(hào)登陸開始重新登陸，該文章寫在已經(jīng)定位了重連問(wèn)題是由SLB引起后，提出的解決方案。
每次重連后，客戶端向SLB發(fā)送建立連接，SLB都會(huì)重新分配一個(gè)網(wǎng)關(guān)節(jié)點(diǎn)，導(dǎo)致客戶端連接到其他網(wǎng)關(guān)，重連失敗。
會(huì)話保持的作用是什么？
開啟SLB會(huì)話保持功能后，SLB會(huì)記錄客戶端的IP地址，在一定時(shí)間內(nèi)，自動(dòng)將同一個(gè)IP的連接轉(zhuǎn)發(fā)到上次連接的網(wǎng)關(guān)。
在網(wǎng)絡(luò)不穩(wěn)定的情況下，游戲容易心跳或者發(fā)包超時(shí)，開啟會(huì)話保持，能解決大部分情況下的重連問(wèn)題。
但是在切換網(wǎng)絡(luò)的時(shí)候，手機(jī)網(wǎng)絡(luò)從Wifi切換成4G，自身IP會(huì)變，這時(shí)候連接必定和服務(wù)器斷開，需要重新建立連接。由于IP已經(jīng)變化，SLB不能識(shí)別到是同一個(gè)客戶端發(fā)出的請(qǐng)求，會(huì)將連接轉(zhuǎn)發(fā)到其他網(wǎng)關(guān)節(jié)點(diǎn)。所以使用TCP連接的情況下，SLB開啟會(huì)話保持并不能解決所有的重連問(wèn)題。
另外某些時(shí)刻，手機(jī)頻繁開啟和斷開WI-FI，有時(shí)候可能不會(huì)斷開網(wǎng)絡(luò)，這并不是因?yàn)?G切換WI-FI時(shí)網(wǎng)絡(luò)沒(méi)斷開，從4G切換到Wi-Fi網(wǎng)絡(luò)，因?yàn)镮P變了，服務(wù)器不能識(shí)別到新的IP，連接肯定是斷開的。這時(shí)候網(wǎng)絡(luò)沒(méi)斷開，主要是因?yàn)楝F(xiàn)在智能手機(jī)會(huì)對(duì)4G和Wi-Fi網(wǎng)絡(luò)做個(gè)權(quán)重判斷，當(dāng)Wi-Fi網(wǎng)絡(luò)頻繁打開關(guān)閉時(shí)，手機(jī)會(huì)判斷Wi-Fi網(wǎng)絡(luò)不穩(wěn)定，所有流量都走4G。所以網(wǎng)絡(luò)沒(méi)斷開是因?yàn)橐恢笔褂?G連接，才沒(méi)有斷開。想要驗(yàn)證，只需要切換Wi-Fi時(shí)，把4G網(wǎng)絡(luò)關(guān)閉，這樣流量就必定走Wi-Fi。
上面說(shuō)過(guò)，四層的TCP協(xié)議主要是基于IP來(lái)實(shí)現(xiàn)會(huì)話保持。但是切換網(wǎng)絡(luò)的時(shí)候客戶端的IP會(huì)變。所以要解決切換網(wǎng)絡(luò)時(shí)的重連問(wèn)題，只有兩個(gè)方法：1. 當(dāng)客戶端成功連接網(wǎng)關(guān)節(jié)點(diǎn)后，記錄下網(wǎng)關(guān)節(jié)點(diǎn)的IP，下次重連后不經(jīng)過(guò)SLB，直接向網(wǎng)關(guān)節(jié)點(diǎn)發(fā)送連接請(qǐng)求。2.使用 SLB的七層（HTTP）轉(zhuǎn)發(fā)服務(wù)。
當(dāng)客戶端經(jīng)過(guò)SLB將連接轉(zhuǎn)發(fā)到網(wǎng)關(guān)時(shí)，二次握手驗(yàn)證成功后向客戶端發(fā)送自己節(jié)點(diǎn)的IP，這樣客戶端下次連接的時(shí)候就能直接連接網(wǎng)關(guān)節(jié)點(diǎn)。但是這樣會(huì)暴露網(wǎng)關(guān)的IP地址，為安全留下隱患。
如果不希望暴露網(wǎng)關(guān)的IP地址，就需要增加一層代理層，SLB將客戶端請(qǐng)求轉(zhuǎn)發(fā)到代理層，代理層再根據(jù)客戶端帶有的key，轉(zhuǎn)發(fā)到正確的網(wǎng)關(guān)節(jié)點(diǎn)上。增加一層代理層，不僅會(huì)增加請(qǐng)求的響應(yīng)時(shí)間，還會(huì)增加整體框架的復(fù)雜度。
阿里云的七層SLB會(huì)話保持服務(wù)，主要是基于cookie的會(huì)話保持?？蛻舳嗽谕?wù)器發(fā)送HTTP請(qǐng)求后，服務(wù)器會(huì)返回客戶端一個(gè)Response，SLB會(huì)在這時(shí)候，將經(jīng)過(guò)的Response插入或者重寫cookie。客戶端獲取到這個(gè)cookie，下次請(qǐng)求時(shí)會(huì)帶上cookie，SLB判斷Request的Headers里面有cookie，就將連接轉(zhuǎn)發(fā)到之前的網(wǎng)關(guān)節(jié)點(diǎn)。
HTTP是短鏈接，我們游戲是長(zhǎng)連接，所以用HTTP肯定不合適。但是可以考慮基于HTTP的WebSocket。
什么是WebSocket？
WSS（Web Socket Secure）是WebSocket的加密版本。
SLB對(duì)WebSocket的支持
查看阿里云SLB文檔對(duì)WS的支持，說(shuō)明SLB是支持WS協(xié)議的，并且SLB對(duì)于WS無(wú)需配置，只需要選用HTTP監(jiān)聽時(shí)，就能夠轉(zhuǎn)發(fā)WS協(xié)議。說(shuō)明WS協(xié)議在SLB這邊看來(lái)就是一個(gè)HTTP，這樣WS走的也是七層的轉(zhuǎn)發(fā)服務(wù)。只要SLB能夠正常識(shí)別WS握手協(xié)議里Request的cookie和正常識(shí)別服務(wù)器返回的Response并且往里面插入cookie，就可以利用會(huì)話保持解決重連問(wèn)題。
Go語(yǔ)言實(shí)現(xiàn)WS服務(wù)器有兩種方法，一種是利用golang.org/x/net下的websocket包，另外一種方法就是自己解讀Websocket協(xié)議來(lái)實(shí)現(xiàn)，由于WS協(xié)議一樣是基于TCP協(xié)議之上，完全可以通過(guò)監(jiān)聽TCP端口來(lái)實(shí)現(xiàn)。
客戶端發(fā)送Request消息
服務(wù)器返回Response消息
其中服務(wù)器返回的Sec-WebSocket-Accept字段，主要是用于客戶端需要驗(yàn)證服務(wù)器是否支持WS。RFC6455文檔中規(guī)定，在WebSocket通信協(xié)議中服務(wù)端為了證實(shí)已經(jīng)接收了握手，它需要把兩部分的數(shù)據(jù)合并成一個(gè)響應(yīng)。一部分信息來(lái)自客戶端握手的Sec-WebSocket-Keyt頭字段：Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==。對(duì)于這個(gè)字段，服務(wù)端必須得到這個(gè)值（頭字段中經(jīng)過(guò)base64編碼的值減去前后的空格）并與GUID"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"組合成一個(gè)字符串，這個(gè)字符串對(duì)于不懂WebSocket協(xié)議的網(wǎng)絡(luò)終端來(lái)說(shuō)是不能使用的。這個(gè)組合經(jīng)過(guò)SHA-1掩碼，base64編碼后在服務(wù)端的握手中返回。如果這個(gè)Sec-WebSocket-Accept計(jì)算錯(cuò)誤瀏覽器會(huì)提示：Sec-WebSocket-Accept dismatch
如果返回成功，Websocket就會(huì)回調(diào)onopen事件
游戲服務(wù)器的使用的TCP協(xié)議，是在協(xié)議的包頭使用4Byte來(lái)聲明本協(xié)議長(zhǎng)度，然后將協(xié)議一次性發(fā)送。但是在WS協(xié)議是通過(guò)Frame形式發(fā)送的，會(huì)將一條消息分為幾個(gè)frame，按照先后順序傳輸出去。這樣做會(huì)有幾個(gè)好處：
websocket的協(xié)議格式：
參數(shù)說(shuō)明如下：
阿里云的SLB開啟HTTP監(jiān)聽后，會(huì)檢查過(guò)往的Request和Response請(qǐng)求，收到服務(wù)器返回的Response后，會(huì)往Response插入一個(gè)Cookie
客戶端收到服務(wù)器的Response后，可以在Header中查到有個(gè)“Set-Cookie”字段，里面是SLB插入的Cookie值
客戶端斷開連接后，下次發(fā)送請(qǐng)求需要往Headers插入Cookie字段
分別在阿里云的兩臺(tái)ECS實(shí)例上部署WS服務(wù)器，打開8000端口，開啟一個(gè)SLB服務(wù)，SLB服務(wù)選擇HTTP方式監(jiān)聽，并且打開會(huì)話保持功能，Cookie處理方式選擇植入Cookie。Demo服務(wù)器沒(méi)有做HTTP健康監(jiān)聽的處理，健康檢查這塊可以先關(guān)掉。
在兩臺(tái)ECS上啟動(dòng)WS服務(wù)器，然后本地運(yùn)行客戶端，分別測(cè)試兩臺(tái)服務(wù)器是否能正常連接，測(cè)試完畢后，測(cè)試SLB能否正常工作。服務(wù)器和SLB都正常的情況下，運(yùn)行客戶端，客戶端會(huì)得到以下結(jié)果
收到的三次Cookie都相同，說(shuō)明Cookie是有正常植入工作的，并且三次都被SLB正確抓取了。
收到的三次serverId也都是同樣的值，說(shuō)明三次都是同一個(gè)ECS上的服務(wù)器響應(yīng)。
至此，驗(yàn)證成功。
Websocket+SLB會(huì)話保持能夠解決超時(shí)重連和切換網(wǎng)絡(luò)時(shí)重連的問(wèn)題。
參考：
阿里云會(huì)話保持
解答Wi-Fi與4G網(wǎng)絡(luò)切換的困惑
WebSocket的實(shí)現(xiàn)原理
阿里云SLB對(duì)WebSocket的支持
HTTP Headers和Cookie
go語(yǔ)言聊天室實(shí)現(xiàn)（六）創(chuàng)建HTTP連接，并升級(jí)為長(zhǎng)連接
我們?cè)趍ian函數(shù)中，首先初始化配置文件，然后新建http連接。
這個(gè)連接創(chuàng)建之后，監(jiān)聽服務(wù)器的9999端口。如果url的路徑后綴為 "/ws",就轉(zhuǎn)發(fā)到ws/ws.go中的IndexHandler方法中。
這個(gè)方法中首先我們創(chuàng)建一個(gè)websocket的Upgrader實(shí)例，然后我們使用Upgrader的upgrade方法來(lái)升級(jí)一下我們的連接為長(zhǎng)連接。
升級(jí)完成之后會(huì)返回一個(gè)*websocket.Conn的連接，我們之后所有的關(guān)于連接的操作，都是基于該conn的。
在該連接完成之后，我們將連接存放到一個(gè)名為Client的map中，以便之后管理更為方便。
之后，我們啟動(dòng)一個(gè)goroutine來(lái)讀取連接中發(fā)送的信息內(nèi)容，再根據(jù)內(nèi)容進(jìn)行相應(yīng)的操作。
基于go的websocket消息推送的集群實(shí)現(xiàn)
目前websocket技術(shù)已經(jīng)很成熟，選型Go語(yǔ)言，當(dāng)然是為了節(jié)省成本以及它強(qiáng)大的高并發(fā)性能。我使用的是第三方開源的websocket庫(kù)即gorilla/websocket。
由于我們線上推送的量不小，推送后端需要部署多節(jié)點(diǎn)保持高可用，所以需要自己做集群，具體架構(gòu)方案如圖：
Auth Service：鑒權(quán)服務(wù)，根據(jù)Token驗(yàn)證用戶權(quán)限。
Collect Service：消息采集服務(wù)，負(fù)責(zé)收集業(yè)務(wù)系統(tǒng)消息，存入MongoDB后，發(fā)送給消息分發(fā)服務(wù)。
Dispatch Service：消息分發(fā)服務(wù)，根據(jù)路由規(guī)則分發(fā)至對(duì)應(yīng)消息推送服務(wù)節(jié)點(diǎn)上。
Push Service：消息推送服務(wù)，通過(guò)websocket將消息推送給用戶。
集群推送的關(guān)鍵點(diǎn)在于，web端與服務(wù)端建立長(zhǎng)連接之后，具體跟哪個(gè)推送節(jié)點(diǎn)保持長(zhǎng)連接的，如果我們能夠找到對(duì)應(yīng)的連接節(jié)點(diǎn)，那么我們就可以將消息推送出去。下面講解一下集群的大致流程：
1. web端用戶登錄之后，帶上token與后端推送服務(wù)（Push Service）保持長(zhǎng)連接。
2. 推送服務(wù)收到連接請(qǐng)求之后，攜帶token去鑒權(quán)服務(wù)（Auth Service）驗(yàn)證此token權(quán)限，并返回用戶ID。
3. 把返回的用戶ID與長(zhǎng)連接存入本地緩存，保持用戶ID與長(zhǎng)連接綁定關(guān)系。
4. 再將用戶ID與本推送節(jié)點(diǎn)IP存入redis，建立用戶（即長(zhǎng)連接）與節(jié)點(diǎn)綁定關(guān)系，并設(shè)置失效時(shí)間。
5. 采集服務(wù)（Collect Service）收集業(yè)務(wù)消息，首先存入mongodb，然后將消息透?jìng)鹘o分發(fā)服務(wù)（Dispatch Service）。
6. 分發(fā)服務(wù)收到消息之后，根據(jù)消息體中的用戶ID，從redis中獲取對(duì)應(yīng)的推送服務(wù)節(jié)點(diǎn)IP，然后轉(zhuǎn)發(fā)給對(duì)應(yīng)的推送節(jié)點(diǎn)。
7. 推送服務(wù)節(jié)點(diǎn)收到消息之后，根據(jù)用戶ID，從本地緩存中取出對(duì)應(yīng)的長(zhǎng)連接，將消息推送給客戶端。
其他注意事項(xiàng)：
新聞名稱：go語(yǔ)言轉(zhuǎn)發(fā)ip Go語(yǔ)言發(fā)展
文章源于：http://fisionsoft.com.cn/article/dodosgg.html
