目前在處理盒子產品時，發現wan口和lan口收發報文時還在走核心路由邏輯,因為從wan口進來的包如果**只能從lan口**出去，所以此時路由查詢是個多餘動作！！
此處應該是乙個可以優化點，來試一試吧！！mark，也不想不通為啥乙個產品這麼多年都沒有人去思考這些！！！
工作中還是要多想一想為什麼？不要隨波逐流的接受！！ 思考內在的原因，說不定這些看起來正確的東西實際上是錯誤！最起碼在目前場景下是錯誤的！！
從這裡進入l4傳輸層
/** ip_local_deliver_finish()將輸入資料報從網路層傳遞
* 到傳輸層。過程如下:
* 1)首先，在資料報傳遞給傳輸層之前，去掉ip首部
* 2)接著，如果是raw套接字接收資料報，則需要
* 複製乙份副本，輸入到接收該資料報的套接字。
* 3)最後，通過傳輸層的接收例程，將資料報傳遞
* 到傳輸層，由傳輸層進行處理。 */
/*ip 層處理報文過程中，回複製乙份報文到raw_socket中去；有的是ipproto_tcp/ipproto_raw
當 socket(af_inet, sock_raw, ipproto_raw)時，它會接收所有協議的資料報，並且
ip_hdrincl 是預設開啟的，即是說應用層要提供 l3 和 l4 層的頭。再如，如果是
ipproto_tcp 時，它只接收到 tcp 包。而 ip_hdrincl 是預設不開啟的，即系統會處理 l3
的頭部*/
static
int ip_local_deliver_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
nf_reset(skb);
}ret = ipprot->handler(skb);//
這裡面會進入udp tcp傳輸層
if (ret < 0
) __ip_inc_stats(net, ipstats_mib_indelivers);
} else
kfree_skb(skb);
} else}}
out: rcu_read_unlock();
return0;
}可以看到：ip_rcv_finish ip_local_deliver_finish涉及到路由的邏輯主要是：
對於此時產品下:可以判定的是報文肯定會上tcp/ip協議棧，所以對transparent 流量，我們可以直接簡單的忽略掉路由系統，直接上傳報文到協議棧！！！
對於tcp l4來說 不會涉及到路由功能；
所以：可知對於tproxy 功能收包時 可以不需要路由邏輯，即可以去掉相關冗餘邏輯！！！
tcp udp收發包的機制
tcpudp 傳送安全送達 只管傳送 接收與建立連線 是 三次握手 否 有資料報,無需連線 資料大小 無限制每個資料報64k 可靠性可靠 不可靠速度 慢 三次握手才能完成連線 快 無需連線 應用流 qq 握手次數 具體情況 1建立連線時,客戶端傳送同步序列編號到伺服器,並進入傳送狀態,等待伺服器確認...
網絡卡收發包的offload總結
網絡卡的offload是指將cpu對資料報的一些處理操作轉到硬體網絡卡上進行，由此釋放出cpu的計算資源。offload也被稱為硬體解除安裝。從2012年起，offload技術開始在網絡卡上使用。發展至今，網絡卡上已經支援多種形式的offload。目前，在收發方向上，網絡卡各自支援不同的offloa...
交換晶元收發包的 DMA 實現原理
交換晶元支援 報文 計數 表項3種dma型別，其中報文dma包括系統從晶元到接收報文或傳送報文到交換晶元，計數dma用來從片上獲取統計計數，表項dma功能分為slam dma 系統記憶體dma到片上交換晶元表項內 和table dma 從晶元的表項內獲取內容dma到系統記憶體 是ram和交換晶元之間...