記錄一次定位視頻通話 音視頻卡頓的緣由分析過程。

 背景:

咱們組開發一個了跨平臺（Web, Windows, 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來實現單進程實例運行，我以前作Qt5應用時也使用過這個功能。

通過和客戶端開發人員確認，他們確實使用了QLocalSocket建立了一個本地服務器來實現單進程實例運行，參考：Qt運行一個實例進程。

我讓他們把單進程實例的代碼註釋掉，從新編譯了一個客戶端版本，該新版本客戶端運行時，筆記本WiFi網絡沒有出現任何卡頓。

 

到此也不能說是Qt5 QLocalSocket的問題，我又用其它的筆記本用WiFi網絡，測試以前的PC客戶端，都沒有出現WiFi網絡延遲卡頓現象。

 

結論：只有在第一個筆記本用WiFi網絡狀況下，用QLocalSocket纔會出現系統網絡延遲卡頓現象。其它筆記本沒有該現象。

咱們把此筆記本暫時列入黑名單，不使用此筆記本用WiFi網絡作測試，再具體的緣由我沒有進一步分析。