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