做無線性能測試這些年我越發(fā)覺得Thread這個網(wǎng)狀網(wǎng)絡(luò)協(xié)議被人低估了。它不像Wi-Fi那樣一出場就帶著高帶寬的光環(huán)也不像傳統(tǒng)藍牙那樣“只點對點”但Thread在智能家居領(lǐng)域的穩(wěn)定性和低功耗表現(xiàn)恰恰是很多高帶寬協(xié)議替代不了的。如果你正在研究設(shè)備掉線、響應(yīng)延遲忽高忽低、網(wǎng)絡(luò)覆蓋死角這些問題或者你正準(zhǔn)備把自己的智能設(shè)備方案從“單點控制”升級成真正的“網(wǎng)狀網(wǎng)絡(luò)”那這篇關(guān)于Thread網(wǎng)絡(luò)性能的拆解應(yīng)該能幫上忙。我會盡量從實測角度出發(fā)把這個網(wǎng)絡(luò)底層的延遲、吞吐量、節(jié)點容量以及那些測完才知道的坑都說清楚。1. Thread網(wǎng)絡(luò)性能到底在測什么1.1 Thread跟Wi-Fi、Zigbee的區(qū)別決定了它的性能邊界先講清楚一件最容易被混淆的事Thread不是一個“互聯(lián)網(wǎng)協(xié)議”它是運行在IEEE 802.15.4低功耗無線通信標(biāo)準(zhǔn)之上的一套完整網(wǎng)絡(luò)協(xié)議棧。市面上經(jīng)常拿來跟它對比的Zigbee同樣基于802.15.4但兩者的網(wǎng)絡(luò)層設(shè)計路徑完全不同。Zigbee用的是自成一體的網(wǎng)絡(luò)層地址和路由機制而Thread采用的是IPv6尋址和6LoWPAN壓縮技術(shù)。這帶來一個直接結(jié)果Thread節(jié)點天然可以獲得IP地址應(yīng)用層可以用我們習(xí)慣的UDP、TCP等方式和節(jié)點通信不需要搞一套私有網(wǎng)關(guān)上專門做協(xié)議轉(zhuǎn)換。正因為Thread跑在IPv6上很多人會下意識拿它跟家里的Wi-Fi比性能。我的實測經(jīng)驗是這種比較沒有意義而且容易讓你忽略Thread真正擅長的地方。Wi-Fi的802.11協(xié)議設(shè)計目標(biāo)是高吞吐一個接入點下面掛幾十個設(shè)備、單個設(shè)備跑到幾十上百Mbps都不是問題。而802.15.4的物理層速率上限只有250kbps一幀數(shù)據(jù)最大127字節(jié)扣掉各種協(xié)議頭之后實際應(yīng)用載荷大概只有七八十個字節(jié)。這是什么概念Thread根本不是為了傳輸視頻或大文件設(shè)計的它更像是“工業(yè)控制總線”的思路報文小、控制可靠、功耗極低、延遲可預(yù)期。所以你在評估Thread網(wǎng)絡(luò)性能時核心指標(biāo)不應(yīng)該是“能跑多快”而應(yīng)該是“控制指令多快能到”“設(shè)備會不會丟命令”“長時間運行穩(wěn)不穩(wěn)”。把評價體系換成這一套之后你會發(fā)現(xiàn)Thread的表現(xiàn)非常扎實。它解決的是智能家居里最老生常談的痛點開關(guān)燈、鎖門、調(diào)溫控這些指令你按下手機的那一刻最希望的是它穩(wěn)定到達而不是帶寬有多富裕。1.2 節(jié)點角色決定體驗路由器、終端設(shè)備與休眠終端設(shè)備Thread網(wǎng)絡(luò)之所以能有好幾年的低功耗表現(xiàn)關(guān)鍵在于它把節(jié)點角色分得很細。一個完整Thread網(wǎng)絡(luò)里有邊界路由器、路由器、終端設(shè)備、休眠終端設(shè)備這幾類角色。理解這些角色是分析任何Thread性能問題的前提。邊界路由器是整個Thread網(wǎng)絡(luò)與外部世界之間的唯一橋梁。它既要維護Thread內(nèi)部的路由信息又要通過以太網(wǎng)、Wi-Fi等方式連接到家中的局域網(wǎng)讓手機、云端能夠訪問Thread網(wǎng)絡(luò)里的設(shè)備。如果這個邊界路由器性能差或者處理能力不足整個網(wǎng)絡(luò)無論里面怎么優(yōu)化對外響應(yīng)都會感覺慢半拍。所以我在搭建測試環(huán)境時邊界路由器的選型通常會用一些CPU性能相對充裕的開發(fā)板或者網(wǎng)關(guān)設(shè)備而不是隨便拿一個低端模組湊數(shù)。路由器角色是Thread網(wǎng)絡(luò)的骨干。它負責(zé)轉(zhuǎn)發(fā)數(shù)據(jù)包、維護路由表、參與網(wǎng)絡(luò)內(nèi)路由決策。要注意這里的“路由器”和家里那種給你轉(zhuǎn)發(fā)Wi-Fi信號的路由器是兩回事但它做的事情類似幫你把數(shù)據(jù)從A點搬到B點。在一個穩(wěn)定的Mesh網(wǎng)絡(luò)里不是所有節(jié)點都能擔(dān)任路由器角色成為路由器需要一定的資源條件而終端設(shè)備只能掛靠在某一個路由器下面不能轉(zhuǎn)發(fā)其他節(jié)點的數(shù)據(jù)休眠終端設(shè)備則在大部分時間里處于深度休眠狀態(tài)需要通信時才喚醒。這幾種角色的性能差異非常明顯。我在測試中遇到過一種典型場景一個終端設(shè)備從掛靠的路由器A切換到了路由器B結(jié)果延遲從原來的20毫秒漲到了80毫秒。查下來原因很簡單——路由器B所在的射頻鏈路本身信號質(zhì)量就差終端設(shè)備切換時只考慮了“能不能連上”沒有考慮“連上之后鏈路質(zhì)量如何”。這類問題在之后章節(jié)我會專門展開。2. 從協(xié)議底層看Thread的性能來源2.1 低功耗無線的不可能三角評估Thread性能之前繞不開一個底層約束低功耗無線通信領(lǐng)域有一個“覆蓋率、功耗、速率”的不可能三角。Thread選擇了其中兩個方向低功耗和一定的覆蓋能力代價就是速率上限很低。802.15.4工作在2.4GHz頻段時理論物理層速率是250kbps。這個數(shù)字看著還行但實際上協(xié)議開銷會吃掉很大一部分。802.15.4的一個物理層協(xié)議數(shù)據(jù)單元最長是127字節(jié)這個長度是固定的。MAC層要占掉幀控制、序列號、尋址這些字段能留給IPv6和UDP層的數(shù)據(jù)已經(jīng)不多再加上6LoWPAN頭部壓縮真正到應(yīng)用層的載荷空間通常在80字節(jié)上下。這個特性決定了Thread網(wǎng)絡(luò)天生的“小報文高頻率”工作模式特別合適比如傳感器定時上送溫度、狀態(tài)或者一兩百字節(jié)的控制幀。反過來如果你想著用Thread傳輸OTA升級固件那就要做好心理準(zhǔn)備一個幾十K字節(jié)的固件包拆成幾百個幀一點點傳再加上每幀的確認開銷整個過程可能要以“分鐘”為單位計算。這也是很多廠商在分布式設(shè)備上升級固件時特意走了另一條通道的原因。2.2 延遲預(yù)算單跳延遲和端到端延遲是怎么累積的延遲是Thread性能指標(biāo)里最敏感的一項因為智能家居控制對延遲的感知非常直接。Thread的單跳延遲理論上取決于射頻幀的傳輸時間、處理時間和MAC層的退避時間。在我用某款2.4GHz 802.15.4模組實測時一包84字節(jié)的應(yīng)用數(shù)據(jù)從節(jié)點發(fā)出到被相鄰路由器完整接收并響應(yīng)單跳往返時間大概在5到10毫秒之間。但真實網(wǎng)絡(luò)的端到端延遲不是簡單地把單跳延遲乘以跳數(shù)。Thread網(wǎng)絡(luò)里數(shù)據(jù)要經(jīng)過選路、排隊、重傳等多個環(huán)節(jié)每多一跳延遲就會增加約幾毫秒到十幾毫秒不等。比如一個掛在最外層的休眠終端設(shè)備要向邊界路由器上報數(shù)據(jù)中間如果經(jīng)過4跳那么理論延遲大概在30到50毫秒之間。這個數(shù)在“感知”層面是可以接受的但你用秒表和眼睛去看會覺得有點“遲滯”。這也是為什么Thread設(shè)備的用戶經(jīng)常反映“開燈有延遲”——不是協(xié)議不行而是物理結(jié)構(gòu)決定了這個延遲必然存在。當(dāng)延遲突然飆到300毫秒甚至500毫秒以上時基本上可以斷定不是正常的排隊延遲了。多數(shù)情況是鏈路質(zhì)量惡化報文觸發(fā)了MAC層重傳。802.15.4的鏈路層允許默認重傳幾次每一次重傳大約要額外付出少則幾毫秒、多則幾十毫秒的時間成本。所以看到延遲異常時第一反應(yīng)應(yīng)該是查丟包率而不是懷疑協(xié)議本身。2.3 吞吐量瓶頸127字節(jié)幀長的無奈與應(yīng)對我用一個具體計算來說明Thread吞吐量為什么有限。假設(shè)應(yīng)用每幀要傳80字節(jié)有效載荷加上MAC層頭部、6LoWPAN壓縮頭、UDP頭之后總幀長大約在115到127字節(jié)之間。在2.4GHz頻段一個127字節(jié)幀的理論發(fā)送時間大約是4.06毫秒。這還不算幀間間隔、ACK確認幀和等待時間。把ACK也算進去的話實際一發(fā)一收大概要花6到8毫秒。算下來單鏈路能實現(xiàn)的“最優(yōu)”吞吐也不過200kbps左右而且這個數(shù)字在真實環(huán)境中基本不可能達到。因為我測過同一房間、無干擾環(huán)境下UDP報文從節(jié)點傳到邊界路由器的速率大概只有140kbps到160kbps穿一堵墻之后掉到七八十kbps再遠一點加上重傳可能連50kbps都不到。如果用TCP傳因為TCP握手和確認報文更重吞吐量還會進一步下降。所以如果要設(shè)計基于Thread的應(yīng)用盡量別做“大塊數(shù)據(jù)傳輸”而要面向“狀態(tài)上報指令下發(fā)”做小包設(shè)計。一個小建議應(yīng)用層每次上送的數(shù)據(jù)能合并就合并能壓縮就壓縮。一幀能搞定的內(nèi)容就不要拆成兩幀因為每一幀都有固定的MAC層開銷和確認成本拆得越碎有效吞吐越低。2.4 可擴展性與網(wǎng)絡(luò)直徑多少節(jié)點才是最舒服的狀態(tài)Thread協(xié)議的標(biāo)稱能力可以支持幾百個節(jié)點這沒問題。但在工程實踐中我建議不要單方面追求“掛得多”。網(wǎng)絡(luò)越大路由表越龐大Leader節(jié)點和路由器的維護壓力越大同時Mesh網(wǎng)絡(luò)的跳數(shù)也會增加網(wǎng)絡(luò)直徑變大后延遲和丟包率都會跟著上升。我個人實測下來的“舒適區(qū)間”是單網(wǎng)絡(luò)不超過150到200個節(jié)點邏輯跳數(shù)控制在10到15跳以內(nèi)。超過這個規(guī)模后你會開始看到一種現(xiàn)象終端設(shè)備明明信號不錯但上報周期變得不穩(wěn)定隔三差五有節(jié)點因為父路由器負荷過高而“被迫”切換切換過程中出現(xiàn)幾十秒的短暫離網(wǎng)。這其實不是節(jié)點壞了而是整體網(wǎng)絡(luò)的負載和拓撲已經(jīng)不健康了。如果你的項目規(guī)模確實很大最好的辦法不是一味擴大單個Thread網(wǎng)絡(luò)而應(yīng)該劃分區(qū)域每個區(qū)域一個Thread網(wǎng)絡(luò)通過多個邊界路由器或上層網(wǎng)關(guān)做互聯(lián)。這樣每個Mesh網(wǎng)絡(luò)保持在一個合理的直徑范圍內(nèi)性能反而更穩(wěn)定。3. 一套可復(fù)制的Thread性能測試方法3.1 測試環(huán)境搭建與節(jié)點部署建議我在實驗室跑Thread性能時第一步不是直接插電開測而是先把測試拓撲畫出來。推薦的最小組網(wǎng)是一個邊界路由器加8到10個路由節(jié)點再掛幾個休眠終端設(shè)備。節(jié)點之間不一定都要互相可見刻意制造一兩條“弱鏈路”反而更貼近實際。部署位置我一般遵循這幾個原則邊界路由器放在實驗室一側(cè)遠離金屬柜和大型電器路由節(jié)點按直線或星型擺放保證相鄰節(jié)點都在視距范圍內(nèi)終端設(shè)備則放在離路由器1到5米的范圍內(nèi)模擬真實家庭里傳感器和開關(guān)的密度。每次測試前我會記錄節(jié)點之間的距離、隔墻情況以及當(dāng)前環(huán)境背景噪聲因為這些變量對結(jié)果影響非常大。如果條件允許把節(jié)點固定高度放在1.2米左右模擬桌面或墻壁開關(guān)的高度。放地上或者緊貼墻角信號損耗會明顯加大測出來的數(shù)據(jù)就不太能反映網(wǎng)絡(luò)的真實水平了。3.2 延遲測試ping6的統(tǒng)計口徑Thread用IPv6所以最簡單的延遲測試方式就是ping6。在邊界路由器上你可以用類似下面的命令直接測到某個終端設(shè)備的往返延遲ping6 -c 50 -i 0.2 設(shè)備IPv6地址關(guān)鍵是把次數(shù)打足。只ping幾次沒意義因為無線信道的不確定性會讓最小值、最大值差別很大。我一般至少ping50次間隔200毫秒然后把回包的min、avg、max以及丟包率記錄下來。判斷標(biāo)準(zhǔn)也不是只看平均值還要看分布如果50個回包里大部分都在20到30毫秒但有五六個突然跳到200毫秒以上那說明鏈路存在間歇性干擾或重傳平均延遲好也不能說明網(wǎng)絡(luò)健康。另外建議同時從兩個方向測一個是在邊界路由器上ping終端節(jié)點另一個是從終端節(jié)點上報數(shù)據(jù)在邊界路由器側(cè)打時間戳。這兩個方向的結(jié)果經(jīng)常不一樣。原因在于上行和下行走的路由路徑、信道競爭狀態(tài)不同感知差異也可能完全不同。3.3 吞吐量測試UDP報文怎么測吞吐量測試我用的是UDP報文。為什么不用TCP因為TCP的擁塞控制和確認機制會引入太多變量測出來的吞吐量反映的是整個機制的綜合表現(xiàn)而不是鏈路本身。UDP更能說明底層承載能力。具體方法是在邊界路由器上開一個接收端服務(wù)從終端節(jié)點以固定速率發(fā)送指定長度、指定數(shù)量的小包。加載一段shell腳本連續(xù)發(fā)送記錄邊界路由器側(cè)接收計數(shù)和時間就能算出一個粗略的吞吐量。實際測試中這個值會隨著跳數(shù)的增加明顯下降我拿一套3跳路徑測過單跳時約140kbps兩跳掉到90kbps左右三跳只剩下55kbps上下。表格整理大概是這樣路徑跳數(shù)實測吞吐UDP80字節(jié)載荷平均往返延遲丟包率1跳140kbps8ms0%2跳92kbps18ms0.1%3跳56kbps35ms0.4%注意這個數(shù)據(jù)只代表我那套特定模組和環(huán)境的數(shù)值不同的射頻方案會有差異但“多一跳吞吐幾乎減半”的變化趨勢是一致的。如果你在規(guī)劃應(yīng)用負載上限可以直接按這個比例來估算。3.4 可靠性與功耗評估除了延遲和吞吐可靠性和功耗是Thread性能里更容易被人忽略、卻也更容易翻車的兩環(huán)?？煽啃詼y試我通常做兩件事一是拉長測試時間連續(xù)跑30分鐘以上的周期性上報統(tǒng)計丟包率二是在網(wǎng)絡(luò)運行中直接拔掉某個關(guān)鍵路由節(jié)點的電源觀察網(wǎng)絡(luò)重新收斂需要多長時間這段時間里有多少包丟失。第一次做這類測試的人往往會被“收斂時間”嚇到。哪怕是規(guī)模不算大的網(wǎng)絡(luò)節(jié)點重新選父路由、更新路由表整個過程可能需要10到60秒不等期間部分終端設(shè)備會短暫離線屬于正?，F(xiàn)象。這時候你不要馬上判定是硬件問題而是先記錄下來看它是否收斂到穩(wěn)定狀態(tài)。功耗評估相對直接用電流探針或萬用表串進節(jié)點電源測節(jié)點的平均電流。休眠終端設(shè)備在深度休眠狀態(tài)下平均電流可能只有幾微安到幾十微安事件觸發(fā)喚醒后瞬時電流可以沖到幾十毫安。如果這個設(shè)備一小時喚醒一次、每次只發(fā)一包數(shù)據(jù)那么電池用一兩年不奇怪。反過來如果一個“休眠設(shè)備”平均電流居高不下那基本可以斷定它沒有真正休眠問題多半出在應(yīng)用層頻繁掃描或網(wǎng)絡(luò)狀態(tài)不佳導(dǎo)致的頻繁重連。4. 影響Thread網(wǎng)絡(luò)性能的施工級因素4.1 射頻布局最容易被低估的工程細節(jié)很多人把Thread性能問題甩鍋給協(xié)議但經(jīng)驗告訴我七成以上的“網(wǎng)絡(luò)慢”“設(shè)備掉線”都是射頻布局問題造成的。2.4GHz信號穿透能力本來就有限水泥墻、金屬門、冰箱這類大物件對信號的衰減非常明顯。一個路由節(jié)點放在電視柜里面和放在開放桌面上鏈路質(zhì)量可能是天壤之別。所以在部署時我會特意強調(diào)“開放空間優(yōu)先”原則。節(jié)點盡量不要塞進密閉的配電箱、金屬底盒或者貼地角落。如果必須在墻內(nèi)安裝也要盡量讓天線口朝外減少墻體遮擋。除此之外還要留意同一空間里是否還有藍牙、無線鼠標(biāo)等設(shè)備。這些設(shè)備雖然和Thread協(xié)議不同但它們都在2.4GHz頻段工作會讓信道里的背景噪聲變高間接拉低Thread鏈路質(zhì)量。還有一個容易被忽略的點同一模組外置天線和PCB天線之間的性能差異非常大。PCB天線對周圍金屬件極其敏感稍微靠近螺絲或銅柱駐波就會變差實際發(fā)射效率可能掉個百分之二三十。做產(chǎn)品選型時如果對通信距離和穩(wěn)定性有要求盡量優(yōu)先考慮帶外置天線的模組。4.2 信道規(guī)劃與干擾規(guī)避Thread在2.4GHz頻段上可用的信道編號范圍是11到26一共16個信道。但實際使用時并不是隨便選一個就行。家里常見的Wi-Fi信號會占用2.4GHz頻段的很大一部分帶寬尤其當(dāng)Wi-Fi路由器配置成20MHz或40MHz帶寬時它會在信道1、6、11這些位置形成很強的干擾帶。我的做法是先做一次頻譜掃描看看整個2.4GHz頻段里哪些區(qū)域噪聲最高然后避開它。如果現(xiàn)場不方便掃描也可以用最土的辦法把Thread網(wǎng)絡(luò)從默認信道換到更高的信道比如25、26因為Wi-Fi最常聚在低頻段高頻段相對干凈。這個操作簡單但對性能提升非常明顯。我在一個辦公室環(huán)境里把Thread信道從默認值切到26之后端到端延遲平均值直接降了30%以上丟包率幾乎歸零。換信道后要記得觀察一段時間。2.4GHz頻段里的環(huán)境是動態(tài)的樓上鄰居的Wi-Fi、會議室臨時開的藍牙音頻都會影響信道質(zhì)量。如果發(fā)現(xiàn)延遲又飆升了可以再掃一遍重新選信。這個“選信道”的運維動作在大型Thread項目里應(yīng)該常態(tài)化和自動化。4.3 邊界路由器的容災(zāi)與負載單邊界路由器是很多智能家居網(wǎng)絡(luò)性能事故的根源。你可能覺得Thread網(wǎng)絡(luò)是Mesh結(jié)構(gòu)每個節(jié)點都能互相轉(zhuǎn)發(fā)邊界路由器掛了換一個就行。但實際上邊界路由器是Thread網(wǎng)絡(luò)與局域網(wǎng)、云端的必經(jīng)之路。邊界路由器一旦停機所有依賴外部控制的下發(fā)指令全部失效內(nèi)部設(shè)備之間不受影響但手機控制必然失靈。所以在項目里我會強烈建議部署至少兩個邊界路由器。Thread協(xié)議本身支持多個邊界路由器同時存在網(wǎng)絡(luò)會選擇一個主用路徑一旦主用邊界路由器失聯(lián)備用邊界路由器能接管對外通信。這個切換過程根據(jù)網(wǎng)絡(luò)規(guī)模會花幾十秒但對用戶來說體驗比徹底癱瘓要好得多。還要留意邊界路由器的“吞吐瓶頸”。一個邊界路由器同時服務(wù)多個網(wǎng)絡(luò)分區(qū)時它本身的CPU和內(nèi)存會成為瓶頸。尤其是在批量設(shè)備同時上報數(shù)據(jù)的密集時刻吞吐瓶頸會導(dǎo)致外部指令排隊表現(xiàn)為“明明網(wǎng)絡(luò)滿格但開關(guān)響應(yīng)遲鈍”。有條件時盡量讓一個邊界路由器服務(wù)的節(jié)點數(shù)不要超過它的能力上限不要指望一臺網(wǎng)關(guān)扛下所有設(shè)備。5. 常見問題與故障排查實錄5.1 網(wǎng)絡(luò)延遲突然飆高先查干擾還是先查拓撲我在實際項目中遇到最多的問題就是“網(wǎng)絡(luò)用了幾天后延遲突然變高丟包也多了不少”。很多人第一反應(yīng)是重新上電、重啟設(shè)備其實這兩個動作在多數(shù)情況下都解決不了問題。我的排查順序是這樣的第一步先確認節(jié)點之間的實時鏈路狀態(tài)。如果設(shè)備支持查看鄰居的信號強度優(yōu)先看節(jié)點與父路由器之間的鏈路質(zhì)量數(shù)值。如果信號強度不差延遲卻高說明可能是干擾而不是距離問題。第二步做一次現(xiàn)場頻譜掃描。如果某個信道下方的背景噪聲基線被整體抬高尤其是持續(xù)出現(xiàn)高占空比的波形那基本就是外部設(shè)備在工作。最常見的就是新拆封的無線攝像頭、無線門鈴這類持續(xù)傳輸?shù)脑O(shè)備。此時手動切換Thread到干凈信道網(wǎng)絡(luò)往往立刻就恢復(fù)。第三步再查拓撲是否發(fā)生了大變化。比如某個路由器節(jié)點離線導(dǎo)致一批終端設(shè)備全部掛到更遠的父路由器上路徑跳數(shù)變多。這類問題單純換信道解決不了要恢復(fù)離線節(jié)點或重新規(guī)劃拓撲。5.2 設(shè)備從離網(wǎng)到重連后性能大幅下跌設(shè)備斷電重啟后性能變差這個問題很有迷惑性。表面看節(jié)點重新上線了、網(wǎng)絡(luò)也正常了但延遲就是比掉線前大了不少。我排查過的是節(jié)點重啟后并沒有回到原來的父路由器而是連到了另一個信號不夠強的路由器上。怎么處理最簡單直接的辦法是手動觸發(fā)一次“離開網(wǎng)絡(luò)再重新加入”讓節(jié)點重新走完整的入網(wǎng)流程這樣它通常會選擇當(dāng)前環(huán)境里最佳的路由器。不過我一般還多做一步檢查重啟前后的路由表信息看看這個節(jié)點的RLOC地址是否發(fā)生了變化。如果發(fā)現(xiàn)地址換了說明它掛到了不同的父路由器下。很多時候你不需要強制它回原位置只要新的父路由器鏈路質(zhì)量能接受性能也能接受但如果你發(fā)現(xiàn)新父路由器的信號質(zhì)量明顯差那就需要考慮調(diào)整設(shè)備的位置或者在附近增加一個路由節(jié)點。這里還要提一個細節(jié)設(shè)備重連后Thread網(wǎng)絡(luò)的Leader節(jié)點可能需要重新計算路由。如果網(wǎng)絡(luò)里路由器數(shù)量多這個收斂過程會持續(xù)一段時間。所以重啟后立刻測延遲得到的數(shù)據(jù)往往偏高。建議等2到3分鐘待路由穩(wěn)定后再開始測試。5.3 網(wǎng)絡(luò)分區(qū)多邊界路由器之間的協(xié)作難題當(dāng)一個區(qū)域范圍很大、工程師為了覆蓋好同時啟用了多個邊界路由器時可能出現(xiàn)一種“網(wǎng)絡(luò)分區(qū)”現(xiàn)象。每個邊界路由器認為自己是主用各自維護了一片子網(wǎng)絡(luò)兩片子網(wǎng)絡(luò)之間無法通信?？雌饋矶寄苷９ぷ鞯O(shè)備之間互相隔離控制指令發(fā)不過去。這個時候最直接的感覺就是“同一個賬號下一部分設(shè)備控制正常另一部分設(shè)備全部離線”。排查時打開邊界路由器的狀態(tài)頁或CLI你會看到存在多個網(wǎng)絡(luò)ID或Leader信息不一致。這不是單純重啟能解決的通常要把多余的邊界路由器暫時關(guān)閉讓整個網(wǎng)絡(luò)重新收斂成一個統(tǒng)一的分區(qū)再依次把其他邊界路由器加回來。這個問題的根源往往出在最初組網(wǎng)時的協(xié)調(diào)流程上。多個邊界路由器在同一條現(xiàn)場總線上啟動時應(yīng)該有一個先后順序先啟動主邊界路由器并等網(wǎng)絡(luò)穩(wěn)定再接入備用邊界路由器完成主備同步。而不是所有設(shè)備同時上電讓Leader競爭過程處于混亂狀態(tài)。這個教訓(xùn)后來變成了我所有部署項目的固定操作規(guī)范。最后說一點個人體會。測試Thread網(wǎng)絡(luò)性能這些年我最大的改變是不再把“速度慢”等同于“性能差”。無線Mesh網(wǎng)絡(luò)的世界里穩(wěn)定性和可預(yù)期性遠比峰值速率重要。Thread用有限的帶寬換來了低功耗、自愈和可靠的網(wǎng)狀結(jié)構(gòu)只要在設(shè)計階段考慮到跳數(shù)、射頻布局、信道干擾和邊界路由器容量它完全能成為智能家居的中堅力量。如果你正在做相關(guān)項目建議先按文章里的方法做一輪完整測試把延遲、吞吐、丟包這些數(shù)據(jù)拿到手再去評估你當(dāng)前的網(wǎng)絡(luò)架構(gòu)是否健康。有了基線后面優(yōu)化才有據(jù)可依。