機器人使用WiFi通信，實現指令下傳，狀態上傳。而WiFi信道平時帶寬較穩定，但會在某些時候突然中斷，造成ping的延時較高，但可以馬上恢復。如果一直ping，則一般情況下ping值很小，但長時間（數十分鐘）測試，有個別ping出現1s左右延時。並迅速恢復。這種現象對於日常上網、下載文件來說，是不可見的。對於視頻播放來說，這種現象會造成卡頓。所以日常看視頻時，在某次緩沖不足時卡頓，應該是WiFi信道上的短時中斷造成的。

特別是機器人使用websocket傳輸，在無線信道短暫中斷時，tcp連接並不中斷，而是進行了超時重傳。tcp的超時等待時間指數增加，多次重傳後等待時間是數十秒的數量級。所以造成了WiFi信道中斷雖然迅速恢復，但由於偶然的漏掉了tcp的前幾次重傳，導致已存在的tcp連接假死。需等待數十秒才能恢復。而在這漫長的等待過程中，WiFi通信一切良好，只是機器人的控制和狀態顯示卡死了。

實驗了多款路由，均無法避免此問題。所以進行udp對比實驗，使用udp和tcp客戶端連接echo服務器，測試傳輸延時。然後斷開WiFi適配器，重連，模擬信道故障。

用Python腳本建立了udp和tcp兩個客戶端，同時以10Hz的頻率向echo服務器發送4KByte的數據包，並記錄延時時間。將延時時間記錄到日誌文件中。

實驗結果：
udp比tcp恢復速度快很多，tcp受中斷後，一般在4秒、9秒時恢復連接，而udp會提前2秒到4秒恢復。若中斷時間再長，則tcp超時斷開連接，再恢復速度較快。

圖中日誌文件記錄了udp和tcp的延時，空缺部分為TCP的延時導致，可見，udp由於不等待返回，所以只要網絡恢復，就立刻恢復傳輸。但tcp會延時一定時間。

上圖中的鏈路斷開時間較長，tcp超時斷開連接，再恢復速度較快。

但如果反復斷開連接重連，則有可能使tcp未徹底斷開連接，而進入指數退讓。測試中最長出現了18秒的延時。而udp在這段時間中斷續工作了8秒。

實驗結論：
若在真實的低信號質量環境中，tcp不會順利斷開連接，可能會發生更長時間的假死。所以，應調低tcp重傳時間或次數，或改用udp傳輸。

進而在機器人上做了修改tcp重傳次數的實驗：

機器人控制tcp通信參數調優