os層面：在早期的linux（2.4以前），還是採用早期的「純中斷「處理機制，中斷的開銷太大而且還要經過幾次記憶體搬運；後來採用了在napi機制以後（第乙個中斷發生後接連polling一段時間），有所好轉，但仍然距離理想差很遠，特別是小包（但報告顯示512b的包最成問題，pcap在linux 2.6丟包率在100mbps線速可以到97%+）；
pcap層面：他的問題主要出在buff的搬移拷貝，從網絡卡到使用者層，需要經過很多kernel的資料結構和queues，訪問其中的一些會有很多lock和拷貝；採用了mmap（http://public.lanl.gov/cpw/）來對映和管理buff之後，效能有了明顯的改善，但資料顯示改善仍然有限，丟包仍然大幅度多於正確接受的包（特別是小包和512b的包）；
ntop（www.ntop.org）project裡面介紹了一種簡化從adapter到userspace渠道的lib, pf_ring；這個lib不但利用mmap，而且將資料通道簡化到只有乙個ring buffer，driver把device來的資料寫入ring buffer，使用者程式通過mmap直接可以訪問這個ring buffer。但這個設計只允許使用者「讀」網路資料，一旦這個device被按照pf_ring方式開啟，這個device就變成「唯讀「，不能傳送，只可以作為sniffer..據說這樣改良之後，大包小包效能明顯改善，64b丟包<30%，1500丟包更是小於10%，唯有512b還是50%左右丟包，但也比原來好了幾倍。
接收RTCP包的流程
先看下webrtc中跟接收rtcp包相關的類圖 上面的類圖畫的是videoreceivestream，對於videosendstream來說也是差不多的。流程如下 從上面可以知道，接收到乙個rtcp包之後，會分發給videoreceivestream和videosendstream，然後再傳遞給他們...
QUIC接收包處理
接收包處理 quic process packet inte ce.h 這個標頭檔案中有個只包含乙個類 a class to process each incoming packet.意思是乙個處理所有到來包的類 class processpacketinte ce virtual void pro...
Linux網路程式設計 UDP接收資料丟包解決方案
收到資料報後進行包計數。記錄收端處理資料耗時，對比發端耗時。最大容量下耗時超過了發包耗時 2 recvfrom 接收到資料之後處理速度太慢 udp是沒有流量控制的 因此，如果socket接收快取設定過小，就會因為udp包過大或者發包速率過快而丟包 2 解決方法 重新設定udp接收緩衝區大小 udp接...