開啟了 text協(xié)議的端口 5778,5779用于內(nèi)部通信,但是用http協(xié)議也能訪問,如圖:
該如何調(diào)整。
1、先說下為什么能用http協(xié)議訪問:
text協(xié)議要求是發(fā)送來的數(shù)據(jù)包只要碰到換行符\n、那就認(rèn)為是一個完整的數(shù)據(jù)包、再看http協(xié)議的請求包過來以后其請求頭和請求行都是符合text協(xié)議的解析要求、所以看上去好像就是跨協(xié)議訪問了一樣,但是這受限限于不同的客戶端解析實現(xiàn);http協(xié)議和text協(xié)議是完全不同的協(xié)議、而且http協(xié)議的請求和響應(yīng)也有自己嚴(yán)格的封包要求、比如你用瀏覽器客戶端去訪問基于text協(xié)議的服務(wù)發(fā)現(xiàn)明顯是無法正常解析的。
2、可能措施有:
比如是內(nèi)網(wǎng)那就將監(jiān)聽地址切換為內(nèi)網(wǎng)IP、或者是從防火墻層面進(jìn)行協(xié)議過濾、也可以在onMessage里面進(jìn)行協(xié)議scheme解析攔截處理等等
3、最后服務(wù)端監(jiān)聽了什么協(xié)議、那客戶端必須配套用什么協(xié)議來訪問,這就好比我講中文你和我講西班牙語、偶爾彼此能聽懂兩句、說的多了終究還是都聽不懂。
大佬,也可以在onMessage里面進(jìn)行協(xié)議scheme解析攔截處理等等,這句scheme解析攔截如何理解,有相關(guān)的參考文檔嗎?我現(xiàn)在折中的辦法就是在onMessage里邊判斷它請求的數(shù)據(jù),如果格式不對就直接onClose了。
比如針對http協(xié)議、在onmessage里可以根據(jù)http協(xié)議規(guī)則去解析數(shù)據(jù)包($data)里的scheme、據(jù)此攔截處理,但要是其他協(xié)議也可能面臨這種處理、所以開銷還是比較大; 個人建議既然已經(jīng)定性為內(nèi)網(wǎng)通信、最好還是監(jiān)聽內(nèi)網(wǎng)IP開銷最小;