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