⑴ 為什麼linux不像Windows學習，將網路協議棧在用戶態實現
說明linux
和windows存在很多不同
⑵ 求助linux內核sctp協議棧怎麼使用
進程管理、內存管理、網路協議棧、驅動管理、虛擬文件系統、系統調用、還有架構。我沒有記錯應該是這7大功能。
⑶ 請教大家，linux下C開發協議棧，一般是怎麼樣的調試的我用的GDB，b 函數斷點，p 變數。這樣感覺挺慢的哦
模塊調試，前提是你要特別熟悉代碼，並且能估計或者預測他的結果，然後列印信息，查看效果唄，要是開發板子上的協議棧時，要有串口才能列印程序運行過程中的輸出。模塊注釋。找出問題所在的地方。
⑷ Linux網路協議棧7--ipsec收發包流程
流程路徑：ip_rcv() --> ip_rcv_finish() --> ip_local_deliver() --> ip_local_deliver_finish()
解封側一定是ip報文的目的端，ip_rcv_finish中查到的路由肯定是本機路由（RTCF_LOCAL），調用 ip_local_deliver 處理。
下面是貼的網上的一張圖片。
ip_local_deliver_finish中 根據上次協議類型，調用對應的處理函數。inet_protos 中掛載了各類協議的操作集，對於AH或者ESP來說，是xfrm4_rcv，對於ipsec nat-t情況下，是udp協議的處理函數udp_rcv，內部才是封裝的ipsec報文（AH或者ESP）。
xfrm4_rcv --> xfrm4_rcv_spi --> xfrm4_rcv_encap --> xfrm_input
最終調用 xfrm_input 做收包解封裝流程。
1、創建SKB的安全路徑；
2、解析報文，獲取daddr、spi，加上協議類型（esp、ah等），就可以查詢到SA了，這些是SA的key，下面列出了一組linux ipsec的state（sa）和policy，方便一眼就能看到關鍵信息；
3、調用SA對應協議類型的input函數，解包，並返回更上層的協議類型，type可為esp,ah,ipcomp等。對應的處理函數esp_input、ah_input等；
4、解碼完成後，再根據ipsec的模式做解封處理，常用的有隧道模式和傳輸模式。對應xfrm4_mode_tunnel_input 和 xfrm4_transport_inout，處理都比較簡單，隧道模式去掉外層頭，傳輸模式只是設置一些skb的數據。
5、協議類型可以多層封裝，如ESP+AH，所以需要再次解析內存協議，如果還是AH、ESP、COMP，則解析新的spi，返回2，查詢新的SA處理報文。
6、經過上面流程處理，漏出了用戶數據報文（IP報文），根據ipsec模式：
流程路徑如下圖，這里以轉發流程為例，本機發送的包主要流程類似。
轉發流程：
ip_forward 函數中調用xfrm4_route_forward，這個函數：
1、解析用戶報文，查找對應的Ipsec policy（__xfrm_policy_lookup）；
2、再根據policy的模版tmpl查找對應最優的SA（xfrm_tmpl_resolve），模版的內容以及和SA的對應關系見上面貼出的ip xfrm命令顯示；
3、最後根據SA生成安全路由，掛載再skb的dst上； 一條用戶流可以聲明多個安全策略（policy），所以會對應多個SA，每個SA處理會生成一個安全路由項struct dst_entry結構（xfrm_resolve_and_create_bundle），這些安全路由項通過 child 指針鏈接為一個鏈表，其成員 output掛載了不同安全協議的處理函數，這樣就可以對數據包進行連續的處理，比如先壓縮，再ESP封裝，再AH封裝。
安全路由鏈的最後一個路由項一定是普通IP路由項，因為最終報文都得走普通路由轉發出去，如果是隧道模式，在tunnel output封裝完完成ip頭後還會再查一次路由掛載到安全路由鏈的最後一個。
註： SA安全聯盟是IPsec的基礎，也是IPsec的本質。 SA是通信對等體間對某些要素的約定，例如使用哪種協議、協議的操作模式、加密演算法、特定流中保護數據的共享密鑰以及SA的生存周期等。
然後，經過FORWARD點後，調用ip_forward_finish()-->dst_output，最終調用skb_dst(skb)->output(skb)，此時掛載的xfrm4_output
本機發送流程簡單記錄一下，和轉發流程殊途同歸：
查詢安全路由： ip_queue_xmit --> ip_route_output_flow --> __xfrm_lookup
封裝發送： ip_queue_xmit --> ip_local_out --> dst_output --> xfrm4_output
註：
1). 無論轉發還是本地發送，在查詢安全路由之前都會查一次普通路由，如果查不到，報文丟棄，但這條路由不一定需要指向真實的下一跳的出介面，只要能匹配到報文DIP即可，如配置一跳其它介面的defualt。
2). strongswan是一款用的比較多的ipsec開源軟體，協商完成後可以看到其創建了220 table，經常有人問裡面的路由有啥用、為什麼有時有有時無。這里做個測試記錄： 1、220中貌似只有在tunnel模式且感興趣流是本機發起（本機配置感興趣流IP地址）的時候才會配置感興趣流相關的路由，路由指定了source；2、不配置也沒有關系，如1）中所說，只要存在感興趣流的路由即可，只不過ping的時候需要指定source，否者可能匹配不到感興趣流。所以感覺220這個表一是為了保證
ipsec封裝發送流程：
xfrm4_output-->xfrm4_output_finish-->xfrm_output-->xfrm_output2-->xfrm_output_resume-->xfrm_output_one
xfrm4_output 函數先過POSTROUTING點，在封裝之前可以先做SNAT。後面則調用xfrm_output_resume-->xfrm_output_one 做IPSEC封裝最終走普通路由走IP發送。
貼一些網上的幾張數據結構圖
1、安全路由
2、策略相關協議處理結構
3、狀態相關協議處理結構
⑸ 關於 Linux 網路，你必須知道這些
我們一起學習了文件系統和磁碟 I/O 的工作原理，以及相應的性能分析和優化方法。接下來，我們將進入下一個重要模塊—— Linux 的網路子系統。
由於網路處理的流程最復雜，跟我們前面講到的進程調度、中斷處理、內存管理以及 I/O 等都密不可分，所以，我把網路模塊作為最後一個資源模塊來講解。
同 CPU、內存以及 I/O 一樣，網路也是 Linux 系統最核心的功能。網路是一種把不同計算機或網路設備連接到一起的技術，它本質上是一種進程間通信方式，特別是跨系統的進程間通信，必須要通過網路才能進行。隨著高並發、分布式、雲計算、微服務等技術的普及，網路的性能也變得越來越重要。
說到網路，我想你肯定經常提起七層負載均衡、四層負載均衡，或者三層設備、二層設備等等。那麼，這里說的二層、三層、四層、七層又都是什麼意思呢？
實際上，這些層都來自國際標准化組織制定的開放式系統互聯通信參考模型（Open System Interconnection Reference Model），簡稱為 OSI 網路模型。
但是 OSI 模型還是太復雜了，也沒能提供一個可實現的方法。所以，在 Linux 中，我們實際上使用的是另一個更實用的四層模型，即 TCP/IP 網路模型。
TCP/IP 模型，把網路互聯的框架分為應用層、傳輸層、網路層、網路介面層等四層，其中，
為了幫你更形象理解 TCP/IP 與 OSI 模型的關系，我畫了一張圖，如下所示：
當然了，雖說 Linux 實際按照 TCP/IP 模型，實現了網路協議棧，但在平時的學習交流中，我們習慣上還是用 OSI 七層模型來描述。比如，說到七層和四層負載均衡，對應的分別是 OSI 模型中的應用層和傳輸層（而它們對應到 TCP/IP 模型中，實際上是四層和三層）。
OSI引入了服務、介面、協議、分層的概念，TCP/IP借鑒了OSI的這些概念建立TCP/IP模型。
OSI先有模型，後有協議，先有標准，後進行實踐；而TCP/IP則相反，先有協議和應用再提出了模型，且是參照的OSI模型。
OSI是一種理論下的模型，而TCP/IP已被廣泛使用，成為網路互聯事實上的標准。
有了 TCP/IP 模型後，在進行網路傳輸時，數據包就會按照協議棧，對上一層發來的數據進行逐層處理；然後封裝上該層的協議頭，再發送給下一層。
當然，網路包在每一層的處理邏輯，都取決於各層採用的網路協議。比如在應用層，一個提供 REST API 的應用，可以使用 HTTP 協議，把它需要傳輸的 JSON 數據封裝到 HTTP 協議中，然後向下傳遞給 TCP 層。
而封裝做的事情就很簡單了，只是在原來的負載前後，增加固定格式的元數據，原始的負載數據並不會被修改。
比如，以通過 TCP 協議通信的網路包為例，通過下面這張圖，我們可以看到，應用程序數據在每個層的封裝格式。
這些新增的頭部和尾部，增加了網路包的大小，但我們都知道，物理鏈路中並不能傳輸任意大小的數據包。網路介面配置的最大傳輸單元（MTU），就規定了最大的 IP 包大小。在我們最常用的乙太網中，MTU 默認值是 1500（這也是 Linux 的默認值）。
一旦網路包超過 MTU 的大小，就會在網路層分片，以保證分片後的 IP 包不大於 MTU 值。顯然，MTU 越大，需要的分包也就越少，自然，網路吞吐能力就越好。
理解了 TCP/IP 網路模型和網路包的封裝原理後，你很容易能想到，Linux 內核中的網路棧，其實也類似於 TCP/IP 的四層結構。如下圖所示，就是 Linux 通用 IP 網路棧的示意圖：
我們從上到下來看這個網路棧，你可以發現，
這里我簡單說一下網卡。網卡是發送和接收網路包的基本設備。在系統啟動過程中，網卡通過內核中的網卡驅動程序注冊到系統中。而在網路收發過程中，內核通過中斷跟網卡進行交互。
再結合前面提到的 Linux 網路棧，可以看出，網路包的處理非常復雜。所以，網卡硬中斷只處理最核心的網卡數據讀取或發送，而協議棧中的大部分邏輯，都會放到軟中斷中處理。
我們先來看網路包的接收流程。
當一個網路幀到達網卡後，網卡會通過 DMA 方式，把這個網路包放到收包隊列中；然後通過硬中斷，告訴中斷處理程序已經收到了網路包。
接著，網卡中斷處理程序會為網路幀分配內核數據結構（sk_buff），並將其拷貝到 sk_buff 緩沖區中；然後再通過軟中斷，通知內核收到了新的網路幀。
接下來，內核協議棧從緩沖區中取出網路幀，並通過網路協議棧，從下到上逐層處理這個網路幀。比如，
最後，應用程序就可以使用 Socket 介面，讀取到新接收到的數據了。
為了更清晰表示這個流程，我畫了一張圖，這張圖的左半部分表示接收流程，而圖中的粉色箭頭則表示網路包的處理路徑。
了解網路包的接收流程後，就很容易理解網路包的發送流程。網路包的發送流程就是上圖的右半部分，很容易發現，網路包的發送方向，正好跟接收方向相反。
首先，應用程序調用 Socket API（比如 sendmsg）發送網路包。
由於這是一個系統調用，所以會陷入到內核態的套接字層中。套接字層會把數據包放到 Socket 發送緩沖區中。
接下來，網路協議棧從 Socket 發送緩沖區中，取出數據包；再按照 TCP/IP 棧，從上到下逐層處理。比如，傳輸層和網路層，分別為其增加 TCP 頭和 IP 頭，執行路由查找確認下一跳的 IP，並按照 MTU 大小進行分片。
分片後的網路包，再送到網路介面層，進行物理地址定址，以找到下一跳的 MAC 地址。然後添加幀頭和幀尾，放到發包隊列中。這一切完成後，會有軟中斷通知驅動程序：發包隊列中有新的網路幀需要發送。
最後，驅動程序通過 DMA ，從發包隊列中讀出網路幀，並通過物理網卡把它發送出去。
多台伺服器通過網卡、交換機、路由器等網路設備連接到一起，構成了相互連接的網路。由於網路設備的異構性和網路協議的復雜性，國際標准化組織定義了一個七層的 OSI 網路模型，但是這個模型過於復雜，實際工作中的事實標准，是更為實用的 TCP/IP 模型。
TCP/IP 模型，把網路互聯的框架，分為應用層、傳輸層、網路層、網路介面層等四層，這也是 Linux 網路棧最核心的構成部分。
我結合網路上查閱的資料和文章中的內容，總結了下網卡收發報文的過程，不知道是否正確：
當發送數據包時，與上述相反。鏈路層將數據包封裝完畢後，放入網卡的DMA緩沖區，並調用系統硬中斷，通知網卡從緩沖區讀取並發送數據。
了解 Linux 網路的基本原理和收發流程後，你肯定迫不及待想知道，如何去觀察網路的性能情況。具體而言，哪些指標可以用來衡量 Linux 的網路性能呢？
實際上，我們通常用帶寬、吞吐量、延時、PPS（Packet Per Second）等指標衡量網路的性能。
除了這些指標，網路的可用性（網路能否正常通信）、並發連接數（TCP 連接數量）、丟包率（丟包百分比）、重傳率（重新傳輸的網路包比例）等也是常用的性能指標。
分析網路問題的第一步，通常是查看網路介面的配置和狀態。你可以使用 ifconfig 或者 ip 命令，來查看網路的配置。我個人更推薦使用 ip 工具，因為它提供了更豐富的功能和更易用的介面。
以網路介面 eth0 為例，你可以運行下面的兩個命令，查看它的配置和狀態：
你可以看到，ifconfig 和 ip 命令輸出的指標基本相同，只是顯示格式略微不同。比如，它們都包括了網路介面的狀態標志、MTU 大小、IP、子網、MAC 地址以及網路包收發的統計信息。
第一，網路介面的狀態標志。ifconfig 輸出中的 RUNNING ，或 ip 輸出中的 LOWER_UP ，都表示物理網路是連通的，即網卡已經連接到了交換機或者路由器中。如果你看不到它們，通常表示網線被拔掉了。
第二，MTU 的大小。MTU 默認大小是 1500，根據網路架構的不同（比如是否使用了 VXLAN 等疊加網路），你可能需要調大或者調小 MTU 的數值。
第三，網路介面的 IP 地址、子網以及 MAC 地址。這些都是保障網路功能正常工作所必需的，你需要確保配置正確。
第四，網路收發的位元組數、包數、錯誤數以及丟包情況，特別是 TX 和 RX 部分的 errors、dropped、overruns、carrier 以及 collisions 等指標不為 0 時，通常表示出現了網路 I/O 問題。其中：
ifconfig 和 ip 只顯示了網路介面收發數據包的統計信息，但在實際的性能問題中，網路協議棧中的統計信息，我們也必須關注。你可以用 netstat 或者 ss ，來查看套接字、網路棧、網路介面以及路由表的信息。
我個人更推薦，使用 ss 來查詢網路的連接信息，因為它比 netstat 提供了更好的性能（速度更快）。
比如，你可以執行下面的命令，查詢套接字信息：
netstat 和 ss 的輸出也是類似的，都展示了套接字的狀態、接收隊列、發送隊列、本地地址、遠端地址、進程 PID 和進程名稱等。
其中，接收隊列（Recv-Q）和發送隊列（Send-Q）需要你特別關注，它們通常應該是 0。當你發現它們不是 0 時，說明有網路包的堆積發生。當然還要注意，在不同套接字狀態下，它們的含義不同。
當套接字處於連接狀態（Established）時，
當套接字處於監聽狀態（Listening）時，
所謂全連接，是指伺服器收到了客戶端的 ACK，完成了 TCP 三次握手，然後就會把這個連接挪到全連接隊列中。這些全連接中的套接字，還需要被 accept() 系統調用取走，伺服器才可以開始真正處理客戶端的請求。
與全連接隊列相對應的，還有一個半連接隊列。所謂半連接是指還沒有完成 TCP 三次握手的連接，連接只進行了一半。伺服器收到了客戶端的 SYN 包後，就會把這個連接放到半連接隊列中，然後再向客戶端發送 SYN+ACK 包。
類似的，使用 netstat 或 ss ，也可以查看協議棧的信息：
這些協議棧的統計信息都很直觀。ss 只顯示已經連接、關閉、孤兒套接字等簡要統計，而 netstat 則提供的是更詳細的網路協議棧信息。
比如，上面 netstat 的輸出示例，就展示了 TCP 協議的主動連接、被動連接、失敗重試、發送和接收的分段數量等各種信息。
接下來，我們再來看看，如何查看系統當前的網路吞吐量和 PPS。在這里，我推薦使用我們的老朋友 sar，在前面的 CPU、內存和 I/O 模塊中，我們已經多次用到它。
給 sar 增加 -n 參數就可以查看網路的統計信息，比如網路介面（DEV）、網路介面錯誤（EDEV）、TCP、UDP、ICMP 等等。執行下面的命令，你就可以得到網路介面統計信息：
這兒輸出的指標比較多，我來簡單解釋下它們的含義。
其中，Bandwidth 可以用 ethtool 來查詢，它的單位通常是 Gb/s 或者 Mb/s，不過注意這里小寫字母 b ，表示比特而不是位元組。我們通常提到的千兆網卡、萬兆網卡等，單位也都是比特。如下你可以看到，我的 eth0 網卡就是一個千兆網卡：
其中，Bandwidth 可以用 ethtool 來查詢，它的單位通常是 Gb/s 或者 Mb/s，不過注意這里小寫字母 b ，表示比特而不是位元組。我們通常提到的千兆網卡、萬兆網卡等，單位也都是比特。如下你可以看到，我的 eth0 網卡就是一個千兆網卡：
我們通常使用帶寬、吞吐量、延時等指標，來衡量網路的性能；相應的，你可以用 ifconfig、netstat、ss、sar、ping 等工具，來查看這些網路的性能指標。
小狗同學問到： 老師，您好 ss —lntp 這個 當session處於listening中 rec-q 確定是 syn的backlog嗎？
A: Recv-Q為全連接隊列當前使用了多少。 中文資料里這個問題講得最明白的文章： https://mp.weixin.qq.com/s/yH3PzGEFopbpA-jw4MythQ
看了源碼發現，這個地方講的有問題.關於ss輸出中listen狀態套接字的Recv-Q表示全連接隊列當前使用了多少,也就是全連接隊列的當前長度,而Send-Q表示全連接隊列的最大長度
⑹ 【網路】Linux 跨機網路通信和本機網路通信
一個報文的產生和發送，都需要硬體和軟體的完美配合。
硬體層面接收到報文之後，做一系列的初始化操作，之後驅動才開始把一個封包封裝為skb。
當然這是在x86架構下，如果是在cavium架構下，封包是wqe形式存在。
不管是skb還是wqe，都僅僅是一種手段，一種達到完成報文傳輸所採用的一種解決方案，一種方法而已。
或許處理方案的具體實現細節差別萬千，但是基本的原理，都是殊途同歸，萬變不離其宗。
skb的產生，讓Linux協議棧旅程的開啟，具備了最基本的條件，接下來的協議棧之旅，才會更加精彩。
寫作本文的原因是現在本機網路 IO 應用非常廣。
在 php 中 一般 nginx 和 php-fpm 是通過 127.0.0.1 來進行通信的；
在微服務中，由於 side car 模式的應用，本機網路請求更是越來越多。
所以，如果能深度理解這個問題在各種網路通信應用的技術實踐中將非常的有意義。
今天咱們就把 127.0.0.1 本機網路通信相關問題搞搞清楚！
為了方便討論，我把這個問題拆分成3問：
1）127.0.0.1 本機網路 IO 需要經過網卡嗎？
2）和外網網路通信相比，在內核收發流程上有啥差別？
3）使用 127.0.0.1 能比 192.168.x.x 更快嗎？
在上面這幅圖中，我們看到用戶數據被拷貝到內核態，然後經過協議棧處理後進入到了 RingBuffer 中。隨後網卡驅動真正將數據發送了出去。當發送完成的時候，是通過硬中斷來通知 CPU，然後清理 RingBuffer。
當數據包到達另外一台機器的時候，Linux 數據包的接收過程開始了。
當網卡收到數據以後，CPU發起一個中斷，以通知 CPU 有數據到達。
當CPU收到中斷請求後，會去調用網路驅動注冊的中斷處理函數，觸發軟中斷。
ksoftirqd 檢測到有軟中斷請求到達，開始輪詢收包，收到後交由各級協議棧處理。
當協議棧處理完並把數據放到接收隊列的之後，喚醒用戶進程（假設是阻塞方式）。
關於跨機網路通信的理解，可以通俗地用下面這張圖來總結一下：
前面，我們看到了跨機時整個網路數據的發送過程 。
在本機網路 IO 的過程中，流程會有一些差別。
為了突出重點，本節將不再介紹整體流程，而是只介紹和跨機邏輯不同的地方。
有差異的地方總共有兩個，分別是路由和驅動程序。
對於本機網路 IO 來說，特殊之處在於在 local 路由表中就能找到路由項，對應的設備都將使用 loopback 網卡，也就是我們常見的 lO。
從上述結果可以看出，對於目的是 127.0.0.1 的路由在 local 路由表中就能夠找到了。
對於是本機的網路請求，設備將全部都使用 lo 虛擬網卡，接下來的網路層仍然和跨機網路 IO 一樣。
本機網路 IO 需要進行 IP 分片嗎？
因為和正常的網路層處理過程一樣，如果 skb 大於 MTU 的話，仍然會進行分片。
只不過 lo 的 MTU 比 Ethernet 要大很多。
通過 ifconfig 命令就可以查到，普通網卡一般為 1500，而 lO 虛擬介面能有 65535。
為什麼我把「驅動」加個引號呢，因為 loopback 是一個純軟體性質的虛擬介面，並沒有真正意義上的驅動。
在鄰居子系統函數中經過處理，進入到網路設備子系統，只有觸發完軟中斷，發送過程就算是完成了。
在跨機的網路包的接收過程中，需要經過硬中斷，然後才能觸發軟中斷。
而在本機的網路 IO 過程中，由於並不真的過網卡，所以網卡實際傳輸，硬中斷就都省去了。直接從軟中斷開始，送進協議棧。
網路再往後依次是傳輸層，最後喚醒用戶進程，這里就不多展開了。
我們來總結一下本機網路通信的內核執行流程：
回想下跨機網路 IO 的流程：
通過本文的敘述，我們確定地得出結論，不需要經過網卡。即使了把網卡拔了本機網路是否還可以正常使用的。
總的來說，本機網路 IO 和跨機 IO 比較起來，確實是節約了一些開銷。發送數據不需要進 RingBuffer 的驅動隊列，直接把 skb 傳給接收協議棧（經過軟中斷）。
但是在內核其它組件上可是一點都沒少：系統調用、協議棧（傳輸層、網路層等）、網路設備子系統、鄰居子系統整個走了一個遍。連「驅動」程序都走了（雖然對於回環設備來說只是一個純軟體的虛擬出來的東東）。所以即使是本機網路 IO，也別誤以為沒啥開銷。
先說結論：我認為這兩種使用方法在性能上沒有啥差別。
我覺得有相當大一部分人都會認為訪問本機server 的話，用 127.0.0.1 更快。原因是直覺上認為訪問 IP 就會經過網卡。
其實內核知道本機上所有的 IP，只要發現目的地址是本機 IP 就可以全走 loopback 回環設備了。
本機其它 IP 和 127.0.0.1 一樣，也是不用過物理網卡的，所以訪問它們性能開銷基本一樣！
How SKBs work - Linux kernel
http://vger.kernel.org/~davem/skb.html
一篇解讀Linux網路協議棧
https://zhuanlan.hu.com/p/475319464
你真的了解127.0.0.1和0.0.0.0的區別？
http://www.52im.net/thread-2928-1-1.html
深入操作系統，徹底搞懂127.0.0.1本機網路通信
http://www.52im.net/thread-3590-1-1.html
⑺ linux 網路路徑中網路協議棧有幾種
看這本書： 書中給出了約500個圖例，大量實際操作的C代碼， 採用舉例教學的方法幫助你掌握TCP/IP實現。
⑻ 為什麼Linux不像Windows學習，將網路協議棧在用戶態實現
區別太多，只列舉部分： windows 是桌面系統， Linux一般是命令行系統， 也有桌面版本，如ubuntu， redhat。 windows 適用於普通用戶， 傻瓜操作；linux主要用於作伺服器，由專業人員使用和維護，一般使用的人都是開發者或專家，學習者一般使用l...
⑼ Linux TCP/IP協議棧數據包處理流程及代碼實現分析
好吧，我來回答吧，首先是網卡驅動程序捕獲到數據包，做檢驗無誤後，和DMA以及CPU交互，然後由DMA和驅動程序創建BD表，然後分配skbuf（LINUX下）數據結構保存獲得的數據幀，內核通過協議棧處理這個skbuf，通常是層層剝離每個層的首部，然後傳到上一層，細節就是一個變數做偏移量，每次做一個首部偏移讀取首部數據，識別本層協議類型以及下一層協議類型，具體過程就是這個網路原理的過程，請參考《TCP/IP詳解卷一》《linux設備驅動程序》《understanding linux network internals》《Unix網路編程卷一》等。
⑽ Linux TCP/IP協議棧封裝方式及核心數據結構代碼實現分析~
這個不是一兩句講清楚的，推薦做法：
1.《Linux源碼分析》或《Linux源碼情景分析》裡面有詳細描述，這兩本書網上很多下載的
2.如果想弄明白原理的話推薦看TCP／IP詳解