機器人使用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重傳次數的實驗：