Sec-WebSocket-Accept not found以及 Sec-WebSocket-Protocol問題
我希望通過 AsyncTcpConnection連接到“wss://premws-pt2.365lpodds.com/zap/?uid=896502538598419”這個(gè)地址。當(dāng)我將$transport設(shè)置為”ssl”時(shí)，會報(bào)錯(cuò)。
關(guān)鍵代碼:
執(zhí)行結(jié)果：
后來將$transport設(shè)置成 “sslv3”，不報(bào)”Sec-WebSocket-Accept not found”錯(cuò)誤了，但是只觸發(fā)了 onConnect和onClose回調(diào)，沒有觸發(fā)onWebSocketConnect回調(diào)。
執(zhí)行結(jié)果：
另外，在瀏覽器中可以連接( 需要設(shè)置子協(xié)議 )，以下是在chrome下的測試。
因此，我不知道問題出在哪？是不是沒有設(shè)置”Sec-Websocket-Protocol:zap-protocol-v1”的原因，如果是這個(gè)原因，那么在何處設(shè)置，希望群主幫忙看一下這個(gè)問題。
4個(gè)回答
打賞
應(yīng)該是你請求的服務(wù)端需要Sec-WebSocket-Protocol 和 Sec-WebSocket-Extensions這2個(gè)http頭，你可以這樣寫。
$ws_connection = new AsyncTcpConnection("ws://premws-pt2.365lpodds.com:443/zap/?uid=896502538598419");
$ws_connection->transport = 'ssl';
$ws_connection->headers = [
'Sec-WebSocket-Extensions: permessage-deflate',
'Sec-WebSocket-Protocol: zap-protocol-v1',
];
承上。
環(huán)境PHP 7.0.23，Workerman 3.5.24
第一個(gè)問題解決了，但是又碰到了新的問題。我預(yù)期通過wss連接獲取的數(shù)據(jù)如下(下面截圖來自于正常瀏覽器調(diào)界面)：
藍(lán)色高亮部分的文本對應(yīng)圖中第二個(gè)紅框，紅框里面有兩個(gè)小圓點(diǎn)，這是目標(biāo)網(wǎng)站使用的消息分隔符(不可見，我在這里特意說明，是懷疑問題可能是這些不可見字符造成的，這兩個(gè)字符分別是\X14和\X01)。
我通過workerman 3.5.24 + PHP7.0.23獲取執(zhí)行腳本(test.php)，截圖如下：
里面有部分消息亂碼，將這段響應(yīng)保存到txt文件，以Hex View方式觀看，可以看到第一條數(shù)據(jù) ( “·__time·|...” )是沒有問題的，而后面接受的數(shù)據(jù)是亂碼
緊接著的數(shù)據(jù)應(yīng)該是"·CONFIG_2_0·F|CG;AD=..."才是。
我另外從王網(wǎng)上找了一個(gè)python程序，也是通過websocket連接該URL，獲取的數(shù)據(jù)是正常的，如下圖：(最開始我懷疑是站點(diǎn)做的反爬蟲措施，重要數(shù)據(jù)故意擾亂了，但這個(gè)程序證明了不是。因?yàn)橹笆褂脀orkerman也不是所有的數(shù)據(jù)都獲取不到，部分較短的消息是可以獲取的。)
由于對方的業(yè)務(wù)數(shù)據(jù)里面會出現(xiàn)一些\x00,\x01,\0x14,\x015這些不可見字符作為分隔符，所以是否會對解析數(shù)據(jù)產(chǎn)生影響。
后來，我考慮有可能是PHP版本的問題，于是安裝了PHP7.3。再次運(yùn)行，效果如下：
出現(xiàn)了上個(gè)問題所描述的那個(gè)問題：當(dāng)獲取一個(gè)服務(wù)器的握手消息，并且客戶端發(fā)送一個(gè)響應(yīng)消息后，服務(wù)器不再發(fā)送消息，卡住了。(這次是在添加了前一個(gè)問題中服務(wù)器要求的header “'Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits'”)情況下。
不知道是否遇到了workerman的一個(gè)bug或者是我有哪些地方?jīng)]有設(shè)置正確。請群主幫忙看一下。腳本文件已經(jīng)作為附件上傳(test.rar)。
- 暫無評論
它的數(shù)據(jù)應(yīng)該是被壓縮了，還有數(shù)據(jù)應(yīng)該是用了zap-protocol-v1協(xié)議又打包了一次。
你要自己研究下怎么破解它的壓縮和zap-protocol-v1協(xié)議。
承上。
問題已經(jīng)找到了，當(dāng)前Workerman沒有處理Sec-WebSocket-Extension的情況。我所遇到的問題是服務(wù)端啟用了 permessage-deflate擴(kuò)展(這個(gè)擴(kuò)展已經(jīng)是在IANA注冊了的，很多瀏覽器都已經(jīng)實(shí)現(xiàn)了)，因此服務(wù)端發(fā)送的ws數(shù)據(jù)負(fù)載部分可能會通過deflate算法進(jìn)行壓縮(表現(xiàn)在WS頭部則為: RSV1比特位設(shè)置為1)，而workerman的ws客戶端在decode()接口中尚未處理之。
原decode()函數(shù)如下：
下面我針對上面我描述的問題修改了一decode()方法，足以解決我自己的問題了。但是對于permessage-deflate擴(kuò)展，還有很多細(xì)節(jié)沒有處理( 不能通用，因此不能提交代碼，項(xiàng)目太緊 )。
修改的文件是：Workerman\Protocols\Ws.php
增加了一個(gè)方法 convertCharsToBinStr($chars)，修改了方法 decode()
ws壓縮相關(guān)RFC文檔鏈接為：
https://tools.ietf.org/html/rfc7692#page-12
希望樓主能夠抽空升個(gè)級。握爪。
