linux報文

⑴ 如何讓linux系統發送dhcp release報文

是redhat？在/etc/sysconfig/network-scripts/ifcfg-eth0加入

DHCPRELEASE=yes

當運行ifdown eth0的時候就會發出dhcprelase報文，看/etc/sysconfig/network-scripts/ifdown-eth腳本中實際上是調用dhclient命令，用下面這個命令應該也可以，試試看吧。
/sbin/dhclient -r eth0

⑵ linux禁用網口收發報文,網卡ip還在

因為禁用的只是網卡對外收發報文功能，並沒有禁用網卡的IP地址，所以網卡的ip地址還在。

⑶ 關於 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命令查詢報文信息

抓包命令tcpmp tcp -A port 22 -w a.cap 將報文內容存在a.cap裡面。a.cap文件是2進制的，需要用ethreal工具專門讀取。

⑸ linux伺服器接收發送報文

它使用狀態的「關聯」（協會），兩對SCTP用戶協議之間的信息交換條款的定義。 SCTP也是一個面向連接的，但在概念上，SCTP「關聯」更廣泛的TCP連接相比，只有一個TCP連接的源地址和目的地址，SCTP提供了另一種方式為每個SCTP端點的運輸提供了一組地址等端點傳輸地址= IP地址+埠號。

繼承的TCP功能的基礎上，SCTP提供了一些額外的功能：

1有序傳輸中的用戶數據的多個「流」（流）

「流」是一系列的TCP中指的位元組，而在SCTP是指某個系列的用戶消息被發送到上層協議，這些消息的順序與在流之內的其他消息。當建立關聯，SCTP的用戶的數據流的數目，可被提供給相關聯的載體。此號碼被商定的流的??數目與源端的用戶相關聯的消息。 SCTP為每個郵件中的鏈接發送給同行的流分配的序列號。在接收端，SCTP，以確保在一個給定的消息流的順序被發送。另一方面，當工作流正在等待的下一個非順序的用戶消息的其他數據流的發送時，將繼續下去。

2根據所發現的路徑MTU（最大傳輸單元）的大小的用戶數據切片

為了確保一致的SCTP報文發送到較低的路徑MTU，SCTP用戶消息分得一杯羹。傳遞給上部SCTP用戶在接收端，切片重組。

3選擇性確認（SACK）和擁塞控制

選擇性確認數據包丟失，TCP序列號被返回給發送者已經成功地接收到的數據位元組的序列號（不包括根據確認的位元組數）的認可，並在SCTP反饋給發件人丟失，並要求序列號的消息重發。

SCTP使用的TCP擁塞控制技術，包括慢啟動，擁塞避免和快速重傳。因此，當一個共存和TCP應用程序時，SCTP的應用程序可以接收部分SCTP的網路資源。

4塊（塊）結合。

選擇性地綁定到??SCTP包，即多個用戶消息的消息發送到一個或多個數據結構的SCTP - 「塊」，SCTP儲備應用程序消息傳遞框架邊界。不同類型的塊可以綁定到一個SCTP報文，但任何一個數據塊之前，必須放在控制塊。

5路徑管理

SCTP路徑管理功能主要是負責為目的地的運輸提供了一個選擇的目標地址的傳輸地址的遠程地址，它是基於兩個方面：SCTP用戶的說明和合格的目的地。當其他流量控制不能提供可達性信息，定期掃描路徑管理功能鏈接到SCTP報告在遠程傳輸地址發生變化的可達性。 SCTP路徑管理功能模塊還負責建立鏈接，該報告的末端的本地地址，傳輸地址告訴SCTP用戶的遠程回報。

6，支持多歸位

當SCTP傳輸的數據包的目的IP地址，如果IP地址是不可達的，SCTP消息重新路由到備用的IP地址。因此，在相關聯，即使在兩端的，可以容忍網路級別的錯誤的一端。

7對拒絕服務攻擊（DoS）

DoS攻擊的方法有很多種，最基本的DoS攻擊就是利用合理的服務請求來佔用過多的資源，從而使合法用戶無法得到服務的響應。 SYN洪水攻擊是一種拒絕服務攻擊實例，是最好的方式了黑客攻擊。針對SYN Flooding攻擊的目標主機上，SCTP關聯的初始化階段，實施以「Cookie」的安全機制。

8支持多種傳輸模式

嚴格有序轉移（如TCP）的有序轉移（如每流）和無序傳輸（如UDP）的一部分。
2 SCTP報文結構

SCTP分組結構的數據分組，第一部分可以遵循由可變長度的數據塊中的一個或多個。塊類型 - 長度 - 值（TLV）格式。源埠，目的埠，校驗的意義是與TCP類似的意義。確認標簽保存價值的交流，第一次在SCTP握手初始標簽。如果任何SCTP報文不包括聯想這樣的標簽，當到達的時間將是在接收端丟棄。

包含的塊類型，標記的轉讓處理，在每個塊中的塊長度，TLV。不同的塊類型，可用於發送控制信息或數據。

發送序列號（TSN）和流序列號（SSN）是兩個不同的序列號，TSN，以確保可靠性整個關聯的SSN保證整個流的有序性，因此，在發送的數據的可靠性訂貨區分開來。
3 SCTP數據傳輸

4.1 SCTP四次握手的原則，抵制SYN洪水攻擊

SCTP關聯定義為：主機A的IP地址] + [主機的埠] + [IP地址的主機B] + [B主機埠。因此，相應的組的每個端部中的IP地址的任何一個可以是標記相關的，通過四向握手，作為相應的源/目的地地址和結束SCTP主機交換通信狀態。

SYN洪水利用所固有的脆弱性，TCP / IP，TCP三次握手面向連接的SYN洪水的存在基礎。 SYN Flooding攻擊原理是：大量的惡意攻擊者向伺服器發送一個SYN包，伺服器發出一個SYN + ACK數據包無法收到客戶端的ACK包（第三次握手無法完成），伺服器端將保持一個非常大名單的半連接，消耗大量的CPU時間和內存資源，也能保持此列表中的IP SYN + ACK的重試。伺服器端將忙於處理攻擊者偽造的TCP連接請求以及沒有時間忽略正常的客戶請求，從正常的客戶的角度來看，伺服器失去了響應。

在SCTP四次握手的INIT消息，接收端不保存任何狀態信息或分配的任何資源，這樣你就可以防止DoS攻擊，如SYN洪水。 INIT-ACK消息發送，使用了一種機制 - 「狀態曲奇」的cookie的發送者建立自己的國家所需的全部信息。

SCTP產生一個Cookie狀態過程如下：

1。收到的INIT發出的INIT ACK數據塊的信息來創建一個關聯的TCB（傳輸控制塊）。

在TCB中，生存在協議參數設置為「有效的Cookie時間，創建日期設置為當前日期。

3根據TCB收集重建的TCB所需的最小的子集的信息，這個子集和密鑰來產生一個MAC（消息認證碼）。

用最小的子集的信息和MAC產生狀態Cookie。

5。在發送的INIT ACK（含狀態cookie參數），發送者必須刪除TCB，以及任何相關的新的關聯的本地資源。

INIT和INIT ACK必須包含建立初始狀態所需的參數：一組IP地址，以確保可靠的傳輸的初始TSN，每一個收到的SCTP包中必須包含初始標簽，每一端的請求發出的數據流的數量並在每一端可以支持接收的數據流的數量。交換這些消息，INIT COOKIE-ECHO消息的發送者被送回的狀態Cookie。接收端在接收COOKIE-ECHO餅乾的狀態，完成重建自己的國家和回送COOKIE-ACK確認該協會已成立。 COOKIE-ECHO和COOKIE-ACK的用戶數據信息可以綁定到每個包。

因此，使用上述的以這樣的方式，即使接收INIT消息，接收終端，也沒有任何的資源消耗：它既不分配任何系統資源，並且不保存的新的關聯的狀態，它是只對口援建的狀態狀態的Cookie作為一個參數，它包含每一個回送的INIT-ACK消息，並最終狀態cookie COOKIE-ECHO消息發送回。

2.2 SCTP的數據交換

正常的兩個SCTP主機之間的數據交換。 SCTP主機發送SACK塊，用來確認每一個收到的SCTP報文。 SACK的完全描述的接收側的狀態，可以使發送側決定的重發，因此，在根據對SACK。 SCTP支持TCP快速重傳和超時重傳演算法類似。

SCTP和TCP數據包丟失，使用不同的機制：TCP序列號空缺已被填補缺口，直到收到，發送丟失的數據包數據的序列號是高於之前。但是，SCTP即使收到訂單的序列號空缺，並會不斷發回數據。

3.3 SCTP關聯關閉

面向連接的傳輸協議，SCTP還可以使用與TCP的三次握手關閉相關，但有一點不同：在「關聯關閉」的過程中保持連接打開一個TCP終端，新的數據來自對等體，但不支持TCP SCTP這個「半封閉」狀態。 1日發布由主機A「OFF」（關閉）塊終止與主機B，主機A就會進入「SHUTDOWN-PENDING」狀態，相應的動作是：不再接受上層應用的數據，並且只發送隊列中剩餘的數據，進入「SHUTDOWN-SENT」狀態。

一旦主機B接收到「OFF」擋，進入「SHUTDOWN-RECEIVED」狀態，與主機A，不再接受上層應用的數據，只發送隊列中剩餘的數據。

主機A再發送「關閉」塊，剩餘的數據已經達到主機B發出的通知，並重申，該協會正在關閉。

當第二個獲得「關閉」塊，主機B發送確認關閉「塊。

隨後的主機發送「關閉」結束「塊完成關閉的關聯。

4結論

SCTP是開發用於傳輸信令流量，但它有一定的優勢，先進的TCP協議機制，如選擇性確認，快速重傳，無序提交，因此，它也滿足高性能傳輸的需求，這將賦予它更廣泛的應用的要求。目前，有各種各樣的操作系統都支持SCTP，如Linux，AIX和Solaris上，Windows中，FressBSD。不同的協議之間的互操作性測試取得成功，揭示了SCTP正走向商業產品的道路。

IEFT致力於SCTP進一步的，以使其更好地滿足下一代應用的需求，如支持IPv6地址，解決對端的IPv6站點本地和鏈路本地地址不連接的問題，以及在現有的關聯動態添加或刪除IP地址，而無需重新啟動關聯。

此外，在第三代移動通信，SCTP信令承載層的選擇之一，它的應用及其性能評價是還待研究。
參考文獻：

⑹ 怎麼實現linux報文截獲功能

可以用logger命令發送日誌信息到本地的/var/log/message，小設備 可以編譯個rsyslog上去 這樣發日誌比較好弄一些。 系統調用man 2 syslog 庫函數看看man 3 syslog

⑺ Linux裡面icmp是什麼

ICMP是Internet控制報文協議。它是TCP/IP協議族的一個子協議，用於在IP主機、路由器之間傳遞控制消息。

ping是DOS命令，通常用於檢測網路連接和故障。Ping是Internet包資源管理器，用於測試網路連接量的程序。Ping向目的地發送ICMP回聲清除消息，並報告是否接收到所需的ICMP回聲響應。

⑻ linux系統怎麼抓報文

修改系統拒收ICMP重定向報文 在linux下可以通過在防火牆上拒絕ICMP重定向報文或者是修改內核選項重新編譯內核來拒絕接收ICMP重定向報文。 在win2000下可以通過防火牆和IP策略拒絕接收ICMP報文。

⑼ 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、狀態相關協議處理結構