? ? ? ? 前段時間客戶反饋一個使用pc上的命令行ping無線設備(WiFi4)時,設備平均響應時間(測試時長2小時,1秒Ping一次)相比其它機型偏慢的問題,并上傳上具體的時間的Log.從log中看到,大多數包的響應還是比較快的,只是個別響應時間較長,且響應時間長的包時間幾乎都是一樣的100多ms.如下是部分響應時間截圖.

? ? ? ?整個2小時的測試時間里,總是時不時的出這么上102,104ms的響應時間,這直接導致了平均響應時間被拉大.于是本地測試,也發現了類似的延遲.本地測試時,現象略有不同,具體現象是Pc每ping28包,設備就有一次響應時間100ms的現象出現.連續測試多次都是這樣的規律.將路由設備成open模式,使用抓包卡抓Ping包,發現pc發出echo的時間是很準的,就是默認的1次一包;而設備回復的echo reply則時快時慢,慢的時候也正是有將近100ms的延遲.即收到echo后100多ms才有看到echo reply發出,于是可以確認延遲是設備側的處理問題,與發送側無關.具體抓包的延遲見下圖(下圖不是100ms,而是50ms,是因為這是已經找到了延遲的地方了,所以改了延遲的時間以進一步確認是否找對地方.):

后面就在接收流程上加打印,確認延遲是卡在哪個步驟上.通過步步調試,最終確認延遲是因為接收的802.11數據的seqnum不連續,導致umac層進行了reorder的處理.即umac檢測到丟了一個seqnum,于是將這個新來的數據包放到了一個reorder的隊列(Q_r),而不是放的正常的給到上層(tcpstack)的隊列(Q_t).而reorder隊列會等一段時間(默認100ms),只為了等到那個丟失的seqnum的數據包,之后再將Q_r中的數據重新放回Q_t中,以供上層處理.如果100ms內那個丟失的seqnum來了,會重新排序后立即放回Q_t中,但是這里因為每次那個丟失seqnum都不來,所以每次都是100ms超時.

那么,那個seqnum為什么總是丟?還這么有規律,去哪了?是個什么包呢??繼續抓包看吧!

見上圖,通過加打印丟失的seqnum與抓包對應,發現是本次丟失的seqnum是177,原來是個arp_req!!!

好吧,明白了.

總結

以上是生活随笔為你收集整理的一个响应ping包延迟偏大的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。