實戰：幾十萬的 AP 增補項目，無線傳感器接入后竟無法同時下載？很簡單的問題卻復雜化了！

作者：小云君網絡 2025-05-09 08:05:00

某企業接到了某政企單位的網絡增補項目—種植棚規模擴大，需要增加“自動噴水器”、“數據采集器”等無線2.4G頻段的傳感器設備，所以無線網咯規模的增加是免不了的。本期分享的案例是無線網絡的相關問題。

本期分享的案例是無線網絡的相關問題。

某企業是一家致力于智能農業科技的工作，近期接到了某政企單位的網絡增補項目—種植棚規模擴大，需要增加“自動噴水器”、“數據采集器”等無線2.4G頻段的傳感器設備，所以無線網咯規模的增加是免不了的。因此在擴容區域，增加了無線AP的點位，但品牌不一樣。原有的AP采用H3C，新增AP采用某P。

現場傳感器設備的升級方式都是通過HTTP協議下載文件到內部完成升級的。HTTP服務器是固定的172.16.1.208。但是新增區域下的傳感器無法并發（多臺）升級，而原有區域的傳感器怎可以同時多臺一起升級。如下：

同是一個項目下的同型號傳感器，為何新增的某J AP不行，而原有的H3C AP正常呢？有朋友就說了，某J AP垃圾唄。好吧，下定論之前，我們先診斷一下。

使用手機或筆記本接入某J AP無線2.4G長ping服務器，可以確認基本無延時和丟包，大抵上看有線/有線通信應該沒有問題才對。

http下載文件很簡單，只需要電腦打開瀏覽器，輸入服務器地址URL下載就行了。因為傳感器下載有問題，所以嘗試對比多臺筆記本同時下載試試：

結果發現，確實有且僅有1臺PC才可以下載成功，其它的PC均無法建立連接并下載文件。而對比接入到原有的H3C AP無線網絡則沒這個問題。下一步就要比對下雙方無線AP設置的異同了。

無線配置無非是那么幾項：SSID、加密方式、無線模式、信道、頻寬、安全防護（隔離、帶寬控制等）、漫游等等，所以對比如下：

看不出起來任何區別。下一步則是要確認現場干擾情況，是否是新增AP的抗干擾能力差導致會話建立不成功頻繁斷流。

由于是2.4G無線接入使用，故首先懷疑競爭干擾導致，現場可以明顯看到同信道造成的強干擾，新增AP和H3C AP所在的工作的1信道存在很多SSID，評估存在多方競爭干擾：

（截圖：網絡百寶箱WIFI干擾測試）

但是通過修改信道問題依舊。下一步抓下異常的數據交互，看看是否有什么端倪。

因為是新增區域下的出現的問題，所以在新增區域的“二級路由器”上抓包，配置監控端口抓取異常傳感器與服務器交互的數據流：

【異常數據流1】終端的IP是10.168.1.55/24

【異常數據流2】終端的IP是10.168.1.22/24

根據數據包分析發現：

異常的TCP握手成功后，終端請求下載時會收到服務器的HTTP 429報文，然后就主動FIN掉該連接了，并不存在丟包問題。所以大致判斷無線鏈路和有線鏈路的通信質量是正常的。對比，我們來看看正常的數據流，服務器并沒有回復HTTP 429報文：

OK，差不多定性到是服務器的HTTP會包導致會話建立失敗的問題了，由于HTTP是明文，我們看下相關內容。

HTTP 429報文內容如下：

我翻譯一下：“即此服務器上的同時下載數量有限制，已達到限制。稍后再試。”也就是說會話限制存在于服務器端而并非網絡層的問題。

那么問題來了：

H3C也是多終端接入啊，為什么那邊服務器不拒絕，而新增AP則拒絕呢？通過現場的全局摸排，發現H3C AP和新增AP實際所處的位置是不一樣的！新增AP加了二級路由器是經過NAT的，而H3C AP沒有！如下：

所以合理懷疑HTTP服務器與終端建立會話只認源IP，經過了NAT后就只有1個源IP和服務器交互了，所以只能一對一，因此做了如下有效的對比測試：

問題總結：

根本原因是HTTP服務器存在只認一個源IP的會話限制，從而讓經過了NAT 的新增某J AP和H3C AP表現不同，一開始如果從全局看，就是一個很簡單的問題；

解決方案：

責任編輯：趙寧寧來源：小云君網絡