這幾天寫gb28181平台接入層**，對收到的ps包進行解包時，總是出現誤碼，最終導致rtsp點播服務中畫面花屏。
分析了碼流抓包資料之後，發現網路上沒有丟包，遂認為ps流解包**有bug，於是埋頭分析了2個小時的解包函式後，沒有發現問題。將抓包rtp負載中的ps包資料匯出之後，專門利用ps解包**寫了乙個小程式，對匯出的資料進行處理，又沒有問題——後來事實證明解包**的確沒有問題，而且這部分的**是在其他專案中用過的。自己有些迷糊了，一時想不明白問題出在**。
冷靜後分析一下，認為抓包結果中的資料不代表應用實際所接收到的資料，二者之間應該是有差別的，比如資料順序可能會不一樣。遂在收包入口函式中，列印每個收到的rtp包的序號，根據序號終於發現：順序沒有亂，但是不間斷的有包丟了。這可是問題了，**資料是直接進行ps包封裝後再在rtp上傳輸的，丟了少量的包，會導致整個ps包都難以恢復。好在已經知問題是因為收包丟包導致的，現在又繼續分析收包丟包的原因。
問題具體情況是採用udp承載rtp包，rtp包負載部分是ps格式封包的h264碼流，每收到乙個rtp包，應用就立即對負載中的ps流進行嘗試解包（包括必需的緩衝操作），處理完乙個rtp包之後再回頭繼續收包。這樣就導致了每次收包之間，間隔比較明顯了。用「udp收包 丟包」作為關鍵字在網上搜尋了一些之後，了解到
採用udp進行資料通訊，若實際流量較大，但recv buffer又不夠大，且沒有及時進行收包時，則容易造成recv buffer滿而丟包udp收發包畢竟還是太簡單，只在ip層之上簡單提供收發包介面功能，不像tcp有擁塞控制和自動重傳機制，相比之下應用層就需要額外做對應的收發包控制工作，而使用tcp就省事簡單很多（當然實現高效的tcp通訊也不是簡單的事情）。
結尾吐槽一句：那些制定gb28181標準的磚家們，你們採用ps over rtp的封包格式時，是不是腦子進水了？要知道ps流只是適合**資料儲存的，而不是網路傳輸啊，要進行網路傳輸，幹嘛不用ts封包？
~~ end ~~
UDP丟包及無序的問題
最近在做乙個專案,在這之前,做了個驗證程式.發現客戶端連續發來1000個1024位元組的包,伺服器端出現了丟包現象.糾其原因,是服務端在還未完全處理掉資料,客戶端已經資料傳送完畢且關閉了.有沒有成熟的解決方案來解決這個問題.我用過sleep 1 暫時解決這個問題,但是這不是根本解決辦法,如果資料量大...
linux 系統 UDP 丟包問題分析思路
序言 在開始之前，我們先用一張 釋 linux 系統接收網路報文的過程。首先網路報文通過物理網線傳送到網絡卡 網路驅動程式會把網路中的報文讀出來放到 ring buffer 中，這個過程使用 dma direct memory access 不需要 cpu 參與 核心從 ring buffer 中讀...
UDP丟包及無序的現象
發現客戶端連續發來1000個1024位元組的包,伺服器端出現了丟包現象.糾其原因,是服務端在還未完全處理掉資料,客戶端已經資料傳送完畢且關閉了.有沒有成熟的解決方案來解決這個問題.我用過sleep 1 暫時解決這個問題,但是這不是根本解決辦法,如果資料量大而多,網路情況不太好的話,還是有可能丟失.你...