机器人使用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重传次数的实验：
cd /proc/sys/net/ipv4/
# cat tcp_retries2
15
echo 5 > tcp_retries2
操作机器人走到走廊，信号中断，然后退回，WiFi信号恢复，数据很快恢复，与重传15次对比，恢复速度明显加快
原文地址：https://www.cnblogs.com/yangzifb/p/10222677.html