背景:
我们组开发一个了跨平台（Web, PC, Linux, Android, iOS)的音视频对讲、会议SDK。应用开发组基于此SDK开发Web版, PC, Android, iOS版客户端应用。
公司测试人员在某个笔记上用PC客户端和其它客户端对讲或会议时音视频效果非常不好，卡顿严重，在网络速度很好的内网测试也会出现此问题。
然后我用SDK demo版应用在同样的环境下测试却不能复现此问题，音视频通话效果非常好，没有任何卡顿，这引起了我的好奇。
我经过反复测试摸索终于发现了问题必然出现的规律，过程如下：
此笔记本是使用 WiFi 连接公司网络的，笔记本上不运行任何程序，然后用命令ping内网服务器，ping 192.168.1.65 -t，ping时间都是1ms，网络非常好。
这时，运行PC客户端（使用Qt5开发的），什么也不做，保持在登录界面，
这时发现之前ping的命令出现了延迟，每隔10秒就会出现一个接近2秒的延迟，过了延迟的时间点，又变成1ms，非常有规律。
把PC客户端关闭，ping延迟现象消失，再运行PC客户端，ping延迟现象再次出现，只要PC客户端运行（即使在登录界面，什么也不做），就会出现网络延迟现象。
此时还没用到任何SDK的功能，可以基本排除是SDK的问题，但我还需要定位出问题出现的原因。
同时在客户端和服务器上抓包，然后登录PC客户端，和其它客户端视频通话，在客户端上找到一个ping延迟的时间点，如下图：
953, 961是ping的请求和回复，中间隔了两秒（45.81~47.80），在953, 954之间接近有2秒（45.81~47.50）没有任何网络包。
此时查看服务端的抓包，服务器收到ping请求后，立即回复了，没有任何延迟。
此时退出PC客户端，重新运行PC客户端保持在登录界面，再运行QQ、微信、声网或其它视频聊天软件，和好友视频聊天，
所有视频软件每10秒也都会出现2秒的卡顿，过了卡2秒的时间点，视频马上恢复正常不卡了。
退出我们PC客户端，再继续用其它的视频聊天软件，长时间运行没有出现任何卡顿。
这时关闭WiFi连接，用网线把笔记本接入公司网络，用有线网络重复之前的测试，发现用我们的PC客户端视频通话，再同时用其它视频软件同时通话，都不会出现延迟卡顿现象。
此时得出规律，在此笔记本上用WiFi网络，只要我们PC客户端在运行，就会导致系统整个网络每10秒出现2秒卡顿。用有线网络不会出现任何延迟卡顿现象。
接下来尝试分析为什么会出现这个现象。
用WiFi网络，再运行我们PC客户端保持在登录界面复现该问题。
运行工具ProcessHacker.exe查看PC客户端的网络IO。
发现我们PC客户端在登录界面就监听了好几个本地端口。
继续用ProcessHacker查看PC客户端的线程，依次尝试暂停线程运行，再恢复线程运行。
在暂停下图中的线程后，发现ping延迟现象消失了，查看此线程调用stack，可以看到该线程内调用了WaitForMultipleObjects函数，
等待多个Event信号的函数。
暂停该线程后登录客户端，发现客户端可以正常使用，再视频通话，音视频也没有任何延迟卡顿。
就是此线程的运行导致了整个系统会定时出现2秒卡顿，而且暂停该线程运行似乎对客户端功能也没有任何影响。
我也做过Qt5开发，根据上述现象，我猜测Qt5客户端可能使用了Qt的QLocalSocket来实现单进程实例运行。
经过和客户端开发人员确认，他们确实使用了QLocalSocket创建了一个本地服务器来实现单进程实例运行，参考：Qt运行一个实例进程。
我让他们把单进程实例的代码注释掉，重新编译了一个客户端版本，该新版本客户端运行时，系统网络没有出现任何卡顿。
到此也不能说是Qt5 QLocalSocket的问题，我又用其它的笔记本用WiFi网络，测试之前的PC客户端，都没有出现系统网络延迟卡顿现象。
结论：只有在第一个笔记本用WiFi网络情况下，用QLocalSocket才会出现系统网络延迟卡顿现象，我们把此笔记本暂时列入黑名单，不使用此笔记本用WiFi网络做测试。