linux協議棧分層設計思想
linux分層究竟對報文做了什麼總結
本人所從事開發以來，一直在做資料面相關。資料面是乙個通訊裝置最終好不好用最直接的體現。寫這個標題我心裡其實非常發虛，為毛？因為這個概念實在有點大，好比小時候我們談到理想，要成為**人一樣。到後面就會發現，**人這個概念很大，這些年一直做的事情其實就是學習，工作，賺錢，買房結婚等等。因為乙個網路裝置，好不好用，資料**快不快，資料**穩定不穩定，全部都是使用者最直接體
現。所以工作八年以來，對linux核心協議棧業也積累了自己的一些心得。現在想通過系列博文，
寫出來，也算是對自己的乙個好的總結。如果有人看到該系列博文，而且有所幫助，那也是我的
最大的榮幸所在了。
同樣，linux協議棧很大。最開始我們接觸tcp/ip中提到過乙個概念，就是分層。比如比較認可的分層方法如下圖：
除此之外，還有比較經典的osi七層模型。不管是tcpip中的分層或者是osi的分層，都無所謂。這裡我們會不會問乙個問題：為什麼需要分層？不分行不行？
關於這個問題，我試圖從以下兩個方面來說下我自己對這個問題的看法:
沒錯，不那麼好看，和我們想象中真的不太一樣。然而，這就是真實的報文。仔細看會發現，乙個乙太網資料報，拿tcp為例子，包含以下資訊:
這個例子中的是乙個tcp報文，不同報文的結構是不一樣的，從上面的圖中可以發現，報文像是穿了一層層的衣服，剝開這一層層的衣服，才可以看到裡面的奧妙。這就是協議棧採用分層後的效果。這些也就是我接下來要系統寫的協議棧內容。
為了更加清晰的看到協議棧分層思想，我們不妨從乙個報文從進入linux機器網絡卡開始追蹤報文的一生。人總有一死，或重於泰山，或輕於鴻毛。報文也一樣，從生到死，一樣精彩，一樣要不停的選路，走路。那麼究竟乙個報文從進入linux中之後，要經歷怎樣的有趣旅程呢？看下面這一附圖:
因為linux每個層面只用關心本層需要的報文資訊和內容，不需要關心其它的任何多餘資訊。舉例來說，l2層中，主要就是linux的bridge**處理。那麼只需要關注報文的eth_headr中的內容，就可以完成學習，**。也就是只關心報文的mac位址以及下一層的協議號即可。（l2**後續會詳細寫文分析）。
其實，總體說來，就是一年四季來回變化，我們不得不加衣服，去衣服。
對於linux核心來說，協議棧處理網路報文也是這麼乙個類似過程。首先我們要知道，每一層都有對應的協議頭，比如l2層是eth頭，l3層是ip頭/arp頭。等等。
那麼，我把linux接收報文流程稱作上行，傳送乙個報文稱作下行。上行就是**服的過程，報文從驅動進入時候，穿的非常齊整，經過l2層要去掉eth頭，經過l3層要去掉ip頭，再後面就是依次脫掉tcp/udp頭，接下來是具體應用層協議頭比如ftp/http等等。
詳細可以參考下圖:
經過這樣的處理，乙個訊息就傳送出去了。可以看到，這樣傳送流程其實就是層層加頭的流程。當然了，這幅圖畫的僅僅是個粗略的大概括，真實情況的封包**遠比這幅圖複雜多了，後面我會詳細寫到。
同樣道理，收包流程就是層層去頭的過程。
linux協議棧，就是乙個報文從進入驅動開始，經過層層**傳輸處理，最終達到報文終點，這一些列的流程，都是協議棧處理範圍。也是我之後要重點寫的內容。
協議棧和OS理解之一
剛開始學習zstack,真的不知如何下手，因為手邊還是有不少資料的，於是就這本看看那本看看，但是由於每種資料的思路不一樣，因此我看了很久也沒搞清楚osal的作用，什麼是繫結，為什麼要新增任務等等，今天看了一本書叫 zigbee技術實踐教程 裡面講作業系統講的特別通俗易懂。現在我將自己的一些理解寫下來...
LINUX協議棧詳解 ARP協議
arp協議負責從ip位址到物理mac位址的轉換。arp格式 this structure defines an ethernet arpheader.struct arphdr 接收arp的函式是arp rcv，在跑完nfproto arp鉤子後，呼叫arp process處理arp請求，簡單考慮，...
TCP IP協議棧（一）
tcp ip協議 為行業提供基礎理論標準 方便業內人士交流 osi封裝是乙個為資料報加入定址資訊的過程 打包過程 埠號用於標識不同的應用，面向終端使用者 ip位址用於唯一標識通訊裝置，面向路由器 mac位址用於唯一標識區域網裝置，面向交換機 osi模型是乙個理論標準，tcp ip協議棧是乙個事實標準...