1. 為什么要在易語言里折騰WebSocket易語言這門語言圈內(nèi)人對(duì)它的感情挺復(fù)雜的。上手快、中文關(guān)鍵字、拖控件就能出界面做點(diǎn)小工具、上位機(jī)、內(nèi)部管理軟件效率極高。但一碰到網(wǎng)絡(luò)通訊尤其是長連接、實(shí)時(shí)推送這類需求很多人第一反應(yīng)就是易語言搞不定吧。我早年也這么想直到手上一個(gè)設(shè)備監(jiān)控項(xiàng)目必須做服務(wù)端主動(dòng)推送才硬著頭皮把WebSocket在易語言里從頭到尾擼了一遍。這篇東西就是那次折騰的完整復(fù)盤。核心講的是易語言WebSocket通訊源碼的解析從客戶端發(fā)起握手、協(xié)議幀的封裝與解析一直到斷線之后怎么自動(dòng)重連。適合兩類人看一類是手里有易語言項(xiàng)目、需要接入實(shí)時(shí)通訊但不想換語言的開發(fā)者另一類是想搞明白WebSocket底層到底怎么跑、不想只會(huì)調(diào)庫的同行。哪怕你用的是別的語言握手和幀格式這部分邏輯是通用的看懂了照樣能遷移。先把結(jié)論擺前面易語言做WebSocket完全可行難點(diǎn)不在語言本身而在于易語言沒有現(xiàn)成的原生Socket異步回調(diào)機(jī)制你得自己用多線程或者定時(shí)輪詢?nèi)ヲ?qū)動(dòng)收發(fā)。握手、掩碼、幀解析這些協(xié)議細(xì)節(jié)反而是死的照著RFC規(guī)范一步步來就行。真正讓人掉頭發(fā)的是斷線重連的狀態(tài)管理——什么時(shí)候算斷、重連幾次、重連期間消息怎么緩存這些才是源碼里最值錢的部分。我下面會(huì)按整體設(shè)計(jì)思路→協(xié)議細(xì)節(jié)拆解→實(shí)操實(shí)現(xiàn)→問題排查這個(gè)順序展開中間穿插我自己踩過的坑和參數(shù)選擇的依據(jù)。你如果只是想快速跑通可以直接跳到第3節(jié)的實(shí)操部分想徹底搞懂建議從頭看。2. 整體架構(gòu)設(shè)計(jì)與方案選型拆解2.1 為什么不用輪詢而選WebSocket項(xiàng)目背景是設(shè)備狀態(tài)監(jiān)控幾十臺(tái)設(shè)備每隔幾秒上報(bào)一次心跳和狀態(tài)數(shù)據(jù)服務(wù)端要實(shí)時(shí)匯總并推送到管理界面。最開始的方案是HTTP輪詢界面每隔兩秒發(fā)一次請(qǐng)求拉數(shù)據(jù)。實(shí)測下來問題很明顯一是延遲高最壞情況要等一個(gè)輪詢周期才能看到狀態(tài)變化二是無效請(qǐng)求多大部分輪詢返回的都是沒變化白白消耗連接資源三是每次HTTP請(qǐng)求都要重新建連雖然可以keep-alive但易語言的HTTP組件對(duì)長連接支持一般開銷不小。換成WebSocket之后一條TCP連接建立起來就一直掛著服務(wù)端有數(shù)據(jù)直接推客戶端收到就更新界面延遲從秒級(jí)降到毫秒級(jí)。這就是選WebSocket的核心理由全雙工、低延遲、連接復(fù)用。它不是銀彈如果只是偶爾查一次數(shù)據(jù)HTTP反而更簡單但只要涉及高頻、雙向、實(shí)時(shí)WebSocket的優(yōu)勢就壓不住了。這里有個(gè)選型細(xì)節(jié)值得說易語言生態(tài)里做WebSocket大致三條路。第一條是用現(xiàn)成的模塊或支持庫省事但黑盒出問題不好查第二條是調(diào)用系統(tǒng)自帶的WinHTTP/WinInet但這兩個(gè)對(duì)WebSocket的支持在舊系統(tǒng)上不完整第三條就是自己用Socket組件手?jǐn)]協(xié)議。我選的是第三條原因很直接——可控。設(shè)備監(jiān)控這種場景連接穩(wěn)定性比開發(fā)速度重要自己寫的代碼每一行都知道在干嘛斷線了能精確控制重連邏輯這是黑盒模塊給不了的。2.2 客戶端與服務(wù)端的職責(zé)劃分易語言在這套方案里主要承擔(dān)客戶端角色服務(wù)端我用的是另一套成熟框架這里不展開重點(diǎn)講客戶端。客戶端要干的事拆開看就四件建立TCP連接、完成WebSocket握手、維持心跳與收發(fā)幀、斷線后重連。這四件事對(duì)應(yīng)源碼里的四個(gè)核心模塊。連接模塊負(fù)責(zé)Socket的創(chuàng)建和連接握手模塊負(fù)責(zé)拼裝HTTP Upgrade請(qǐng)求并校驗(yàn)服務(wù)端返回幀處理模塊負(fù)責(zé)把業(yè)務(wù)數(shù)據(jù)封裝成WebSocket幀發(fā)出去、把收到的字節(jié)流還原成業(yè)務(wù)數(shù)據(jù)重連模塊則是一個(gè)狀態(tài)機(jī)監(jiān)控連接健康度并在異常時(shí)拉起重連。為什么這么分因?yàn)樗鼈兊纳芷诓灰粯印CP連接可能斷但握手邏輯是固定的幀處理是高頻調(diào)用的熱路徑要盡量輕量重連是低頻但關(guān)鍵的兜底邏輯要獨(dú)立出來避免和正常收發(fā)耦合。模塊化之后調(diào)試的時(shí)候能快速定位是哪一層出的問題——是連不上、握手失敗、還是幀解析錯(cuò)位一目了然。2.3 多線程驅(qū)動(dòng)模型的選擇易語言沒有事件驅(qū)動(dòng)的異步IOSocket的接收要么阻塞等要么非阻塞輪詢。我最終采用的是雙線程模型一個(gè)接收線程死循環(huán)調(diào)用recv讀數(shù)據(jù)讀到就丟進(jìn)緩沖區(qū)交給解析邏輯主線程負(fù)責(zé)業(yè)務(wù)處理和發(fā)送。發(fā)送本身在易語言里相對(duì)簡單因?yàn)閟end一般不會(huì)長時(shí)間阻塞除非發(fā)送緩沖區(qū)滿。為什么不搞單線程輪詢因?yàn)檩喸冮g隔不好定。間隔太短CPU空轉(zhuǎn)太長延遲高。而且輪詢模型下接收和業(yè)務(wù)處理擠在一個(gè)線程里一旦業(yè)務(wù)處理卡住接收就停了容易觸發(fā)服務(wù)端的心跳超時(shí)。雙線程把接收和業(yè)務(wù)解耦接收線程只管收收完往隊(duì)列一放業(yè)務(wù)線程慢慢處理互不干擾。注意易語言的多線程要小心共享變量。接收線程往緩沖區(qū)寫、業(yè)務(wù)線程從緩沖區(qū)讀必須加鎖或者用線程安全的隊(duì)列否則會(huì)出現(xiàn)數(shù)據(jù)錯(cuò)亂甚至程序崩潰。我一開始圖省事直接共享一個(gè)字節(jié)集變量跑了兩天偶發(fā)崩潰查了很久才定位到是并發(fā)讀寫。3. 握手階段的協(xié)議細(xì)節(jié)與實(shí)現(xiàn)要點(diǎn)3.1 握手請(qǐng)求的拼裝邏輯WebSocket握手本質(zhì)是一次HTTP Upgrade請(qǐng)求?？蛻舳税l(fā)一個(gè)帶特殊頭部的HTTP請(qǐng)求服務(wù)端如果同意升級(jí)返回101狀態(tài)碼之后這條連接就從HTTP協(xié)議切換到WebSocket協(xié)議。這個(gè)切換是協(xié)議層面的約定不是真的換了條連接還是原來那條TCP。請(qǐng)求行是GET /path HTTP/1.1關(guān)鍵是幾個(gè)頭部。Upgrade: websocket和Connection: Upgrade告訴服務(wù)端我要升級(jí)協(xié)議Sec-WebSocket-Key是一個(gè)Base64編碼的16字節(jié)隨機(jī)數(shù)服務(wù)端會(huì)拿它做一次固定算法的運(yùn)算再返回用來證明它真的懂WebSocket協(xié)議而不是隨便回了個(gè)101Sec-WebSocket-Version: 13聲明協(xié)議版本現(xiàn)在基本都用13。Sec-WebSocket-Key的生成有個(gè)細(xì)節(jié)必須是16字節(jié)隨機(jī)數(shù)再Base64。易語言里可以用取隨機(jī)數(shù)填充字節(jié)集但要注意隨機(jī)源的質(zhì)量。我見過有人直接用時(shí)間戳拼字符串當(dāng)key雖然大多數(shù)服務(wù)端不校驗(yàn)key的隨機(jī)性只校驗(yàn)運(yùn)算結(jié)果但規(guī)范要求隨機(jī)穩(wěn)妥起見還是老老實(shí)實(shí)生成16字節(jié)隨機(jī)數(shù)。生成完做Base64編碼拼進(jìn)請(qǐng)求頭。請(qǐng)求拼好后通過Socket發(fā)出去然后等響應(yīng)。這里有個(gè)坑響應(yīng)可能不是一次recv就能收全的。HTTP響應(yīng)頭可能分多個(gè)TCP包到達(dá)尤其是網(wǎng)絡(luò)狀況差的時(shí)候。所以接收邏輯要循環(huán)讀直到讀到\r\n\r\n這個(gè)頭部結(jié)束標(biāo)志才能認(rèn)為響應(yīng)頭收完了。我第一版就是假設(shè)一次recv能收全結(jié)果在弱網(wǎng)環(huán)境下偶發(fā)握手失敗后來改成循環(huán)讀才穩(wěn)定。3.2 響應(yīng)校驗(yàn)與101狀態(tài)碼處理收到響應(yīng)后要校驗(yàn)三件事。第一狀態(tài)行是不是HTTP/1.1 101 Switching Protocols101是協(xié)議切換成功的標(biāo)志其他狀態(tài)碼都算失敗。第二Upgrade頭是不是websocket。第三也是最容易被忽略的Sec-WebSocket-Accept的值對(duì)不對(duì)。Accept的計(jì)算方法是把客戶端發(fā)的Key和一個(gè)固定的GUID字符串258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接做SHA-1哈希再Base64編碼。服務(wù)端返回的Accept必須和這個(gè)算出來的值一致。為什么要校驗(yàn)因?yàn)橛行┲虚g層比如某些代理可能會(huì)錯(cuò)誤地返回101但實(shí)際沒升級(jí)成功校驗(yàn)Accept能確認(rèn)對(duì)面真的是個(gè)WebSocket服務(wù)端。雖然實(shí)際項(xiàng)目里很多客戶端偷懶不校驗(yàn)但我建議還是加上成本很低能擋掉一類詭異問題。易語言里做SHA-1和Base64都有現(xiàn)成命令拼接字符串后依次調(diào)用即可。算出來的值和響應(yīng)頭里的Accept做字符串比較注意大小寫和首尾空格響應(yīng)頭解析時(shí)要把值trim一下再比。3.3 握手階段的常見失敗原因握手失敗的原因五花八門我整理了幾類高頻的。第一類是請(qǐng)求頭拼錯(cuò)比如Upgrade寫成upgrade雖然HTTP頭不區(qū)分大小寫但有些簡陋的服務(wù)端實(shí)現(xiàn)會(huì)嚴(yán)格匹配或者Connection只寫了Upgrade沒寫keep-alive。第二類是路徑不對(duì)服務(wù)端可能要求特定的URL路徑路徑錯(cuò)了直接返回404。第三類是服務(wù)端不支持WebSocket返回普通HTTP響應(yīng)這時(shí)候要看狀態(tài)碼判斷。還有一類比較隱蔽握手成功但立即斷開。這種情況往往是服務(wù)端在握手后馬上做了鑒權(quán)發(fā)現(xiàn)token無效就關(guān)了連接。排查方法是抓包看握手響應(yīng)之后有沒有緊跟一個(gè)關(guān)閉幀有的話就是應(yīng)用層主動(dòng)斷的得去查鑒權(quán)邏輯。實(shí)操心得調(diào)試握手階段最有效的辦法是把發(fā)出去的請(qǐng)求原文和收到的響應(yīng)原文都打到日志里。易語言調(diào)試輸出有限我一般寫到一個(gè)文本文件里出問題時(shí)直接看原文比猜快得多。請(qǐng)求原文里Key是明文響應(yīng)原文里Accept是明文對(duì)照著一算就知道對(duì)不對(duì)。4. 數(shù)據(jù)幀的封裝、解析與心跳維持4.1 WebSocket幀結(jié)構(gòu)逐字段拆解握手完成后所有數(shù)據(jù)都以幀的形式傳輸。一個(gè)WebSocket幀的頭部最少2字節(jié)最多14字節(jié)后面跟負(fù)載數(shù)據(jù)。理解幀結(jié)構(gòu)是解析的核心我按字段順序講。第一個(gè)字節(jié)拆成兩部分最高位FIN標(biāo)志1位表示這是不是消息的最后一幀WebSocket允許一條消息拆成多幀發(fā)分片F(xiàn)IN1表示結(jié)束后面3位是保留位一般全0低4位是opcode操作碼決定這幀是什么類型。opcode常見值0x1文本幀、0x2二進(jìn)制幀、0x8關(guān)閉幀、0x9 ping、0xA pong。0x0是延續(xù)幀用于分片的后續(xù)部分。第二個(gè)字節(jié)最高位是MASK標(biāo)志表示負(fù)載是否用掩碼處理?？蛻舳税l(fā)給服務(wù)端的幀必須掩碼服務(wù)端發(fā)給客戶端的幀必須不掩碼這是規(guī)范強(qiáng)制的。后面7位是負(fù)載長度。這里有個(gè)設(shè)計(jì)如果負(fù)載長度小于126這7位直接就是長度如果等于126后面跟2字節(jié)表示真實(shí)長度16位如果等于127后面跟8字節(jié)64位。這個(gè)變長設(shè)計(jì)是為了省頭部開銷小包只花2字節(jié)頭。如果MASK1掩碼標(biāo)志后面跟4字節(jié)掩碼key。然后是負(fù)載數(shù)據(jù)如果掩碼了負(fù)載每個(gè)字節(jié)要和掩碼key循環(huán)異或才能還原。掩碼的作用是防止某些中間緩存把WebSocket流量誤當(dāng)成HTTP緩存同時(shí)也增加了一點(diǎn)安全性。4.2 客戶端發(fā)送幀的封裝實(shí)現(xiàn)客戶端發(fā)幀重點(diǎn)是必須加掩碼。封裝流程先確定opcode發(fā)文本用0x1發(fā)二進(jìn)制用0x2算負(fù)載長度按長度區(qū)間決定長度字段占幾字節(jié)生成4字節(jié)隨機(jī)掩碼key把負(fù)載逐字節(jié)和掩碼key異或最后按第一字節(jié)第二字節(jié)擴(kuò)展長度掩碼key掩碼后負(fù)載的順序拼成完整幀發(fā)出去。長度計(jì)算這里容易出錯(cuò)。假設(shè)負(fù)載是200字節(jié)超過125但小于65536那第二字節(jié)的低7位要填126后面跟2字節(jié)的200。如果負(fù)載是70000字節(jié)超過65535低7位填127后面跟8字節(jié)。易語言里處理字節(jié)序要注意WebSocket規(guī)定多字節(jié)長度用大端序網(wǎng)絡(luò)字節(jié)序而易語言默認(rèn)的整數(shù)轉(zhuǎn)字節(jié)集可能是小端得手動(dòng)調(diào)換字節(jié)順序。我第一版就是忘了調(diào)字節(jié)序發(fā)小包正常一發(fā)大包服務(wù)端就報(bào)協(xié)議錯(cuò)誤查了半天才發(fā)現(xiàn)是長度字段字節(jié)序反了。掩碼異或的實(shí)現(xiàn)對(duì)負(fù)載字節(jié)集的每個(gè)字節(jié)取掩碼key對(duì)應(yīng)位置索引對(duì)4取模的字節(jié)做異或。易語言里用計(jì)次循環(huán)逐字節(jié)處理雖然效率不如批量操作但勝在直觀不易錯(cuò)。負(fù)載一般不大性能可以接受。4.3 接收幀的解析與粘包處理接收比發(fā)送麻煩因?yàn)門CP是流式的一次recv可能收到半個(gè)幀也可能收到一個(gè)半幀。所以解析不能假設(shè)一次recv就是一個(gè)完整幀必須維護(hù)一個(gè)接收緩沖區(qū)把收到的數(shù)據(jù)追加進(jìn)去然后循環(huán)嘗試從緩沖區(qū)頭部解析完整幀解析出一個(gè)就消費(fèi)掉對(duì)應(yīng)字節(jié)直到剩余數(shù)據(jù)不夠一個(gè)完整幀為止。這就是所謂的粘包/半包處理。解析步驟先看緩沖區(qū)夠不夠2字節(jié)不夠就等下次夠的話讀第一字節(jié)拿opcode和FIN讀第二字節(jié)拿MASK和長度根據(jù)長度字段判斷還需不需要讀擴(kuò)展長度再判斷需不需要讀掩碼key服務(wù)端發(fā)來的幀MASK0不需要最后算出負(fù)載長度檢查緩沖區(qū)剩余數(shù)據(jù)夠不夠負(fù)載不夠就等夠了就取出負(fù)載。如果MASK1還要做異或還原。這里有個(gè)易錯(cuò)點(diǎn)長度字段的讀取位置是動(dòng)態(tài)的。不能寫死偏移量必須根據(jù)前面的字段一步步往后推。我見過有人寫死負(fù)載從第6字節(jié)開始結(jié)果遇到不帶掩碼的服務(wù)端幀就全錯(cuò)位了。正確做法是維護(hù)一個(gè)游標(biāo)讀一個(gè)字段游標(biāo)往后移最后游標(biāo)位置就是負(fù)載起點(diǎn)。注意緩沖區(qū)消費(fèi)完已解析的幀后剩余數(shù)據(jù)要保留。易語言里操作字節(jié)集刪除頭部比較方便但頻繁刪除大字節(jié)集有性能開銷。如果數(shù)據(jù)量大可以用讀指針的方式記錄已消費(fèi)位置定期整理緩沖區(qū)避免每次都重建字節(jié)集。4.4 心跳機(jī)制的設(shè)計(jì)與參數(shù)選擇長連接最怕的是假死——TCP連接看起來還在實(shí)際上中間鏈路已經(jīng)斷了但雙方都沒察覺。WebSocket協(xié)議自帶ping/pong機(jī)制來解決這個(gè)問題一方發(fā)ping幀另一方必須回pong幀。如果發(fā)了ping在一定時(shí)間內(nèi)沒收到pong就判定連接失效主動(dòng)斷開重連。參數(shù)怎么定我實(shí)測下來心跳間隔30秒、超時(shí)判定90秒比較合適。間隔太短比如5秒會(huì)增加無謂流量尤其設(shè)備多的時(shí)候太長比如5分鐘則故障發(fā)現(xiàn)慢。90秒超時(shí)意味著連續(xù)3次心跳沒回應(yīng)才判定斷開能容忍偶發(fā)的網(wǎng)絡(luò)抖動(dòng)避免誤判。這個(gè)值可以根據(jù)實(shí)際網(wǎng)絡(luò)質(zhì)量調(diào)整弱網(wǎng)環(huán)境可以放寬到120秒。心跳由誰發(fā)起客戶端和服務(wù)端都可以但一般約定由客戶端定時(shí)發(fā)ping。我在接收線程里加了個(gè)計(jì)時(shí)器邏輯每30秒往發(fā)送隊(duì)列塞一個(gè)ping幀。收到pong幀時(shí)更新最后活躍時(shí)間。另一個(gè)線程定期檢查當(dāng)前時(shí)間減最后活躍時(shí)間超過90秒就觸發(fā)重連。這樣即使沒有業(yè)務(wù)數(shù)據(jù)連接的健康狀態(tài)也能被持續(xù)監(jiān)控。有個(gè)細(xì)節(jié)ping幀的負(fù)載可以帶數(shù)據(jù)最多125字節(jié)pong幀要原樣帶回。我一般不帶負(fù)載簡單。但要注意收到ping幀時(shí)必須回pong這是規(guī)范要求不回的話對(duì)端可能判定你失效。服務(wù)端發(fā)來的ping也要處理別只顧著自己發(fā)。5. 斷線重連的狀態(tài)機(jī)與消息補(bǔ)償5.1 連接狀態(tài)的劃分與轉(zhuǎn)換斷線重連是整個(gè)源碼里邏輯最繞的部分核心是搞清楚當(dāng)前處于什么狀態(tài)。我把連接狀態(tài)分成五個(gè)未連接、連接中、已握手、已斷開、重連等待。狀態(tài)之間的轉(zhuǎn)換由事件驅(qū)動(dòng)發(fā)起連接→連接中TCP連上且握手成功→已握手檢測到斷開或主動(dòng)關(guān)閉→已斷開進(jìn)入重連流程→重連等待等待結(jié)束→連接中循環(huán)。為什么要分這么細(xì)因?yàn)椴煌瑺顟B(tài)下能做的事不一樣。比如連接中的時(shí)候不能發(fā)業(yè)務(wù)數(shù)據(jù)得排隊(duì)已握手才能正常收發(fā)重連等待期間要決定是繼續(xù)等還是放棄。狀態(tài)清晰了代碼里的分支判斷才不會(huì)亂。我第一版沒分狀態(tài)用一個(gè)布爾變量表示是否連接結(jié)果重連過程中各種邊界情況處理得一團(tuán)糟后來重構(gòu)成狀態(tài)機(jī)才理順。狀態(tài)變量要用全局的但讀寫要加鎖因?yàn)榻邮站€程、發(fā)送線程、重連線程都可能碰它。易語言里可以用臨界區(qū)或者簡單的標(biāo)志位配合原子操作穩(wěn)妥起見我用臨界區(qū)保護(hù)狀態(tài)讀寫。5.2 指數(shù)退避重連策略重連不能傻乎乎地一直高頻重試那樣服務(wù)端掛了的時(shí)候會(huì)把人家打垮自己也被防火墻拉黑。標(biāo)準(zhǔn)做法是指數(shù)退避第一次斷開后等1秒重連失敗等2秒再失敗等4秒以此類推直到一個(gè)上限比如30秒之后一直按上限間隔重試。為什么用指數(shù)而不是固定間隔因?yàn)閿嗑€原因可能是服務(wù)端重啟很快恢復(fù)短間隔能快速重連上也可能是網(wǎng)絡(luò)故障恢復(fù)慢長間隔避免無效重試。指數(shù)退避兼顧了兩種情況初期快速試探后期降低頻率。上限30秒是經(jīng)驗(yàn)值太長了恢復(fù)慢太短了壓力大。還有個(gè)優(yōu)化重連成功后退避計(jì)數(shù)要清零。否則連接穩(wěn)定運(yùn)行一段時(shí)間后又?jǐn)鄷?huì)直接從上次的高間隔開始等不合理。我一般在握手成功后把重試計(jì)數(shù)重置為0。5.3 重連期間的消息緩存與補(bǔ)償斷線期間業(yè)務(wù)層可能還在產(chǎn)生要發(fā)的消息這些消息不能丟。我的做法是維護(hù)一個(gè)發(fā)送隊(duì)列正常連接時(shí)消息直接發(fā)斷線時(shí)消息進(jìn)隊(duì)列暫存重連成功后把隊(duì)列里的消息按順序補(bǔ)發(fā)出去。隊(duì)列要有上限不然斷線久了內(nèi)存撐爆。我設(shè)的是1000條超了就丟最老的或者按業(yè)務(wù)重要性丟棄。補(bǔ)發(fā)的時(shí)候要注意順序WebSocket本身保證幀的順序但補(bǔ)發(fā)是應(yīng)用層行為得自己保證先入先出。接收方向也有補(bǔ)償問題。斷線期間服務(wù)端推的消息客戶端收不到重連后服務(wù)端會(huì)不會(huì)重發(fā)這取決于業(yè)務(wù)協(xié)議。我的做法是重連成功后客戶端主動(dòng)發(fā)一個(gè)同步請(qǐng)求讓服務(wù)端把斷線期間的狀態(tài)快照推過來這樣就不依賴服務(wù)端的消息重發(fā)機(jī)制更可靠。實(shí)操心得重連邏輯最容易出的bug是重連風(fēng)暴——多個(gè)線程同時(shí)檢測到斷線各自發(fā)起重連結(jié)果建了一堆連接。解決辦法是重連動(dòng)作只由一個(gè)線程負(fù)責(zé)其他線程只負(fù)責(zé)把狀態(tài)置為已斷開重連線程看到狀態(tài)變化才行動(dòng)。加個(gè)重連中標(biāo)志位防止重復(fù)發(fā)起。6. 實(shí)操過程與關(guān)鍵環(huán)節(jié)落地6.1 環(huán)境準(zhǔn)備與Socket組件初始化動(dòng)手之前先把環(huán)境理清楚。易語言版本建議用較新的老版本對(duì)多線程和字節(jié)集操作的支持有差異。Socket組件用系統(tǒng)自帶的或者第三方穩(wěn)定組件都行核心是要支持非阻塞或者能配合線程使用。我用的是一個(gè)支持設(shè)置超時(shí)的TCP客戶端組件超時(shí)設(shè)置很關(guān)鍵——連接超時(shí)設(shè)5秒接收超時(shí)設(shè)短一點(diǎn)比如1秒這樣接收線程能定期醒來檢查狀態(tài)不會(huì)永久阻塞。初始化流程創(chuàng)建Socket對(duì)象→設(shè)置服務(wù)器地址和端口→設(shè)置各項(xiàng)超時(shí)→發(fā)起連接。連接是異步的發(fā)起后要輪詢或者等回調(diào)確認(rèn)連上了。連上之后立即進(jìn)入握手流程拼請(qǐng)求、發(fā)送、等響應(yīng)、校驗(yàn)。這一整套封裝成一個(gè)建立連接的函數(shù)返回成功或失敗。參數(shù)上服務(wù)器地址和端口建議做成配置項(xiàng)方便切換環(huán)境。超時(shí)值我前面說了連接5秒、接收1秒發(fā)送超時(shí)設(shè)3秒。這些值不是死的網(wǎng)絡(luò)差的環(huán)境適當(dāng)放大。6.2 接收線程的循環(huán)結(jié)構(gòu)與退出條件接收線程是整個(gè)客戶端的發(fā)動(dòng)機(jī)結(jié)構(gòu)要寫扎實(shí)?；竟羌苁茄h(huán)判斷 是否退出 → 否 → 調(diào)用recv讀數(shù)據(jù) → 讀到數(shù)據(jù)追加到緩沖區(qū) → 調(diào)用解析函數(shù)處理緩沖區(qū) → 處理解析出的幀 → 繼續(xù)循環(huán)。recv返回0或者報(bào)錯(cuò)說明連接斷了置狀態(tài)為已斷開退出循環(huán)。退出條件要設(shè)計(jì)好。不能只靠recv報(bào)錯(cuò)因?yàn)橛行┣闆r下recv會(huì)一直阻塞。所以recv要設(shè)超時(shí)超時(shí)返回后檢查一個(gè)退出標(biāo)志標(biāo)志為真就跳出循環(huán)。這個(gè)標(biāo)志由主線程在關(guān)閉連接時(shí)設(shè)置。線程退出前要清理資源關(guān)閉Socket。解析函數(shù)是熱路徑要寫得高效。我前面說的游標(biāo)法解析每次從緩沖區(qū)頭開始嘗試解析解析出一個(gè)幀就消費(fèi)掉循環(huán)直到解析不出完整幀。解析出的幀按opcode分發(fā)文本幀和二進(jìn)制幀交給業(yè)務(wù)回調(diào)ping幀回pongpong幀更新活躍時(shí)間關(guān)閉幀觸發(fā)斷開流程。6.3 發(fā)送隊(duì)列與線程安全實(shí)現(xiàn)發(fā)送這塊我用了一個(gè)隊(duì)列加一個(gè)發(fā)送線程。業(yè)務(wù)層調(diào)發(fā)送消息接口時(shí)把消息封裝成幀塞進(jìn)隊(duì)列發(fā)送線程從隊(duì)列取幀往Socket寫。為什么要單獨(dú)一個(gè)發(fā)送線程因?yàn)閟end在某些情況下也會(huì)阻塞發(fā)送緩沖區(qū)滿如果在業(yè)務(wù)線程里直接send會(huì)卡住業(yè)務(wù)。獨(dú)立發(fā)送線程能隔離這個(gè)風(fēng)險(xiǎn)。隊(duì)列的線程安全是重點(diǎn)。業(yè)務(wù)線程寫隊(duì)列、發(fā)送線程讀隊(duì)列必須加鎖。易語言里用臨界區(qū)進(jìn)隊(duì)列和出隊(duì)列都包在臨界區(qū)里。隊(duì)列用數(shù)組或者鏈表實(shí)現(xiàn)都行我用的是循環(huán)數(shù)組固定大小滿了就阻塞或者丟棄看業(yè)務(wù)需求。發(fā)送線程的邏輯循環(huán) → 隊(duì)列空則等待用延時(shí)或事件→ 非空則取出幀 → send → 檢查send結(jié)果 → 失敗則觸發(fā)重連。send失敗通常意味著連接已斷這時(shí)候要把狀態(tài)置為已斷開讓重連線程接手。6.4 完整重連流程的串聯(lián)把前面幾塊串起來重連的完整流程是這樣的接收線程或發(fā)送線程檢測到連接異?！脿顟B(tài)為已斷開→重連線程獨(dú)立線程檢測到狀態(tài)變化→進(jìn)入重連等待→按指數(shù)退避計(jì)算等待時(shí)間→等待結(jié)束→置狀態(tài)為連接中→調(diào)用建立連接函數(shù)→成功則置已握手、清零退避計(jì)數(shù)、補(bǔ)發(fā)隊(duì)列消息、發(fā)同步請(qǐng)求失敗則退避計(jì)數(shù)加一回到重連等待。這個(gè)流程里重連線程是唯一的決策者其他線程只負(fù)責(zé)報(bào)告異常。這樣避免了多線程搶著重連的問題。重連線程本身也是個(gè)循環(huán)定期檢查狀態(tài)狀態(tài)是已斷開就推進(jìn)重連流程。補(bǔ)發(fā)消息和同步請(qǐng)求要在握手成功之后、正式對(duì)外聲明已連接之前完成這樣業(yè)務(wù)層感知到的連接狀態(tài)是干凈的——要么沒連上要么連上了且數(shù)據(jù)已同步。7. 常見問題與排查技巧實(shí)錄7.1 握手成功但收不到數(shù)據(jù)這個(gè)現(xiàn)象很迷惑握手返回101Accept校驗(yàn)也過了但之后就是收不到任何業(yè)務(wù)數(shù)據(jù)。排查下來常見原因有兩個(gè)。一是服務(wù)端在等客戶端先發(fā)數(shù)據(jù)有些服務(wù)端實(shí)現(xiàn)要求客戶端握手后立即發(fā)一個(gè)訂閱或認(rèn)證消息不發(fā)就不推數(shù)據(jù)。解決辦法是看服務(wù)端文檔握手后主動(dòng)發(fā)一條初始化消息。二是幀解析錯(cuò)位收到的數(shù)據(jù)其實(shí)在緩沖區(qū)里但解析邏輯因?yàn)槟硞€(gè)字段讀錯(cuò)導(dǎo)致一直認(rèn)為數(shù)據(jù)不完整。排查方法是把緩沖區(qū)原始字節(jié)打印出來手動(dòng)按幀結(jié)構(gòu)對(duì)一遍看解析游標(biāo)是不是卡在某個(gè)位置。7.2 大消息發(fā)送導(dǎo)致連接斷開發(fā)小消息正常一發(fā)大消息比如超過64KB連接就斷。這多半是長度字段字節(jié)序問題。前面說過WebSocket長度用大端序易語言整數(shù)轉(zhuǎn)字節(jié)集默認(rèn)可能是小端。負(fù)載超過125字節(jié)時(shí)長度字段開始用擴(kuò)展字節(jié)超過65535時(shí)用8字節(jié)這兩個(gè)地方如果字節(jié)序反了服務(wù)端解析出的長度會(huì)是個(gè)天文數(shù)字直接判定協(xié)議錯(cuò)誤斷開連接。解決辦法是顯式做字節(jié)序轉(zhuǎn)換把整數(shù)的字節(jié)順序調(diào)過來再拼進(jìn)幀頭。7.3 重連后消息重復(fù)或丟失重連補(bǔ)償邏輯沒寫對(duì)會(huì)出現(xiàn)重復(fù)或丟失。重復(fù)的原因通常是補(bǔ)發(fā)隊(duì)列沒清空重連成功后把已經(jīng)發(fā)過的消息又發(fā)了一遍。丟失的原因可能是斷線瞬間正在發(fā)送的消息既沒發(fā)成功也沒進(jìn)隊(duì)列。解決辦法是發(fā)送確認(rèn)機(jī)制消息進(jìn)隊(duì)列時(shí)標(biāo)記待發(fā)發(fā)送成功后標(biāo)記已發(fā)補(bǔ)發(fā)時(shí)只發(fā)待發(fā)的。斷線瞬間的消息在send失敗時(shí)重新入隊(duì)。7.4 常見問題速查表現(xiàn)象可能原因排查方向解決思路握手返回非101路徑錯(cuò)、服務(wù)端不支持、請(qǐng)求頭拼錯(cuò)打印請(qǐng)求和響應(yīng)原文對(duì)照規(guī)范逐頭檢查握手101但Accept校驗(yàn)失敗服務(wù)端實(shí)現(xiàn)不規(guī)范或中間層干擾手動(dòng)算Accept對(duì)比確認(rèn)服務(wù)端真實(shí)支持WebSocket收不到數(shù)據(jù)服務(wù)端等初始化消息、解析錯(cuò)位打印緩沖區(qū)原始字節(jié)補(bǔ)發(fā)初始化消息、修正解析游標(biāo)大消息斷開長度字段字節(jié)序錯(cuò)檢查擴(kuò)展長度字節(jié)順序顯式轉(zhuǎn)大端序頻繁誤判斷線心跳超時(shí)太短看斷線時(shí)間間隔放寬超時(shí)到90秒以上重連風(fēng)暴多線程重復(fù)發(fā)起重連看日志重連次數(shù)重連動(dòng)作單線程化消息重復(fù)補(bǔ)發(fā)隊(duì)列未清看補(bǔ)發(fā)日志發(fā)送確認(rèn)隊(duì)列清理消息丟失斷線瞬間消息未入隊(duì)看發(fā)送失敗處理send失敗重新入隊(duì)7.5 幾個(gè)不寫在文檔里的避坑經(jīng)驗(yàn)第一個(gè)經(jīng)驗(yàn)日志要帶時(shí)間戳和線程標(biāo)識(shí)。多線程環(huán)境下沒有線程標(biāo)識(shí)的日志根本沒法分析時(shí)序你不知道哪條日志是接收線程打的、哪條是重連線程打的。時(shí)間戳精確到毫秒能看出事件先后。第二個(gè)經(jīng)驗(yàn)緩沖區(qū)大小要設(shè)合理。接收緩沖區(qū)太小會(huì)頻繁觸發(fā)擴(kuò)容太大浪費(fèi)內(nèi)存。我一般初始設(shè)8KB按需增長上限設(shè)1MB超過說明有問題可能是解析卡住了導(dǎo)致數(shù)據(jù)堆積。第三個(gè)經(jīng)驗(yàn)測試要模擬弱網(wǎng)和斷網(wǎng)。正常網(wǎng)絡(luò)下跑通不代表穩(wěn)定我專門寫了個(gè)測試工具能模擬延遲、丟包、隨機(jī)斷開跑一晚上看重連邏輯扛不扛得住。很多重連的邊界bug都是這么測出來的。第四個(gè)經(jīng)驗(yàn)關(guān)閉連接要優(yōu)雅。主動(dòng)關(guān)閉時(shí)先發(fā)關(guān)閉幀opcode 0x8等對(duì)方回關(guān)閉幀或者超時(shí)再關(guān)TCP。直接關(guān)TCP可能導(dǎo)致對(duì)方收到RST日志里一堆錯(cuò)誤。雖然不影響功能但優(yōu)雅關(guān)閉能讓日志干凈很多排查問題時(shí)少干擾。這套源碼我前后迭代了三四版從最初只能跑通握手到后來能扛住整晚的弱網(wǎng)測試中間踩的坑基本都寫在上面的排查表里了。WebSocket協(xié)議本身不復(fù)雜復(fù)雜的是工程上的健壯性——連接會(huì)斷、網(wǎng)絡(luò)會(huì)抖、消息會(huì)亂序把這些邊界情況都想到并處理好才算真正能用。易語言雖然在這方面生態(tài)弱一些但協(xié)議是死的照著規(guī)范一步步實(shí)現(xiàn)配合清晰的狀態(tài)管理和充分的測試做出來的東西一樣穩(wěn)。