路由表在內核中存在路由表fib_table_hash和路由緩存表rt_hash_table。路由緩存表主要是為了加速路由的查找， 每次路由查詢都會先查找路由緩存，再查找路由表。這和cache是一個道理，緩存存儲最近使用過的路由項，容量小

內核版本：2.6.34前篇路由表http://blog.csdn.net/qy532846454/article/details/6423496說明了路由表的結構及路由 表的創建。下面是一些路由表的使用的細枝末節，作補充說明。路由可以分

內核版本：2.6.34802.1q1. 注冊vlan網絡系統子空間，err = register_pernet_subsys(&vlan_net_ops); static struct pernet_operations

看完了路由表，重新回到netif_receive_skb ()函數，在提交給上層協議處理前，會執行下面一句，這就是網橋的相關操作 ，也是這篇要講解的內容。skb = handle_bridge(skb, &pt_prev, &a

內核版本：2.6.34NetFilter在2.4.x內核中引入,成為linux平台下進行網絡應用的主要擴展，不僅包括防火牆的實現 ，還包括報文的處理(如報文加密、報文分類統計等)等。NetFilter數據結構

內核版本：2.6.34這篇是關於IP層協議接收報文時的處理，重點說明了路由表的查找，以及IP分片重組。ip_rcv 進入IP層報文接收函數丟棄掉不是發往本機的報文，skb->pkt_type在網卡接收報文處理以太網頭時會根據dst

內核版本：2.6.34在前一篇”IP協議”中對報文接收時IP層的處理進行了分析，本篇分析將針對報文發送時IP層的處理。傳輸層處理完後，會調用ip_push_pending_frames()將報文傳遞給IP層：ip

內核版本：2.6.34這部分的重點是三個核心的數據結構-鄰居表、鄰居緩存、代理鄰居表，以及NUD狀態轉移圖。總的來說，要成功添加一條鄰居表項，需要滿足兩個條件：1.　本機使用該表項；2.　對方主機進行了確認。同時，表項的添加 引入了NU

內核版本：2.6.34雜談一：重復地址檢測Linux協議棧中處理重復地址檢測報文的是arp_process()中的一段代碼， RFC2131是DHCP的草案，相應的sip==0是DHCP服務器用來檢測它所分發的地址是否重復的。/* Sp

內核版本：2.6.34ICMP模塊比較簡單，要注意的是icmp的速率限制策略，向IP層傳輸數據ip_append_data()和 ip_push_pending_frames()。在net/ipv4/af_inet.c中的inet_in

內核版本：2.6.34這部分內容在於說明socket創建後如何被內核協議棧訪問到，只關注兩個問題：sock何時插入內核 表的，sock如何被內核訪問的。對於核心的sock的插入、查找函數都給出了流程圖。sock如何插入內核表socket

內核版本：2.6.34UDP報文接收UDP報文的接收可以分為兩個部分：協議棧收到udp報文，插入相應隊列中；用戶 調用recvfrom()或recv()系統調用從隊列中取出報文，這裡的隊列就是sk->sk_receive_queu

內核版本：2.6.34報文的IP校驗和、ICMP校驗和、TCP/UDP校驗和使用相同的算法，在RFC1071中定義，網上這方面的 資料和例子很多，就不解釋算法流程了，而是側重於在實現的變化和技巧。The checksum algorit

內核版本：2.6.34在發送報文時，可以調用函數setsockopt()來設置相應的選項，本文主要分析IP選項的生成，發送以及 接收所執行的流程，選取了LSRR為例子進行說明，主要分為選項的生成、選項的轉發、選項的接收三部分。先看一個源

內核版本：2.6.34陸由表作為三層協議的核心數據結構，理解它是至關重要的。前面已經分析過路由表，有興趣的可以參考：第一篇：路由表 http://blog.csdn.net/qy532846454/article/details /64

內核：2.6.34TCP是應用最廣泛的傳輸層協議，其提供了面向連接的、可靠的字節流服務，但 也正是因為這些特性，使得TCP較之UDP異常復雜，還是分兩部分[創建與使用]來進行分析。這篇主要包括TCP的創建及三次握手 的過程。編程時一般用

內核版本：2.6.34前面章節介紹過Netfilter的框架，地址見： http://blog.csdn.net/qy532846454/article/details/6605592，本章節介紹的連接跟蹤就是在Netfilter的框架

本文只是一個內核網絡協議的實踐的例子，先說明添加的目的，下篇開始具體的實現。內核版本：2.6.34；在支持802.1主機上，報文的一般格式：現在需要支持一種新的協議[二層] – BRCM協議，與IP等協議不同，它位於2層，擁

內核版本：2.6.34實現思路：報文在網絡協議棧中的流動，對於接收來講，是 對報文的脫殼的過程，由於報文是已知的輸入，只要逐個解析協議號；對於發送來講，是各層發送函數的嵌套調用，由於沒有已 知的輸入，只能按事先設計好的協議進行層層構造。

內核版本：2.6.34接上篇《添加網絡協議》。為了用戶方便查看brcm設備的工作狀態，使用proc文件系統是很好的方 式。一個網絡協議模塊可以注冊到網絡空間中register_pernet_subsys()，這個函數會為子空間分配一個i