1.總述
Linux中用戶空間的網路編程，是以socket為介面，一般創建一個sockfd = socket(family,type,protocol)，之後以該sockfd為參數，進行各種系統調用來實現網路通信功能。其中family指明使用哪種協議域（如INET、UNIX等），protocol指明該協議域中具體哪種協議（如INET中的TCP、UDP等），type表明該介面的類型（如STREAM、DGRAM等），一般設protocol=0，那麼就會用該family中該type類型的默認協議（如INET中的STREAM默認就是TCP協議）。
Linux中利用mole機制，層次分明地實現了這套協議體系，並具有很好的擴展性，其基本模塊構成如下：
先看右邊，頂層的socket模塊提供一個sock_register()函數，供各個協議域模塊使用，在全局的net_family[]數組中增加一項；各個協議域模塊也提供一個類似的register_xx_proto()函數，供各個具體的協議使用，在該協議域私有的xx_proto[]數組中增加一項。這兩個數組中的存放的都是指針，指向的數據結構如下圖所示：
很明顯它們是用來創建不同類型的socket介面的，且是一種分層次的創建過程，可想而知，頂層socket_create()完成一些共有的操作，如分配內存等，然後調用下一層create；協議域內的create()完成一些該協議域內共有的初始化工作；最後具體協議中的create()完成協議特有的初始化。具體的下一節講。
再來看上圖右邊的，也是頂層socket模塊提供的4個函數，前兩個一般由具體協議模塊調用，由於協議棧與應用層的交互，具體的後面會講到。後兩個一般有協議域模塊調用，用於底層設備與協議棧間的交互。但這也不絕對，如在PPPOE協議中，這4個函數都由具體協議模塊調用，這是因為PPPOX協議域內的共有部分不多，各個協議間幾乎獨立。這4個函數的功能及所用到的數據結構，在後面具體用到時會詳細說明。
2.socket插口創建
首先來看一下最終創建好的socket插口由哪些部分組成，該結構是相當龐大的，這里只給出框架：
基本屬性有state（listen、accept等），flags標志（blocked等），type類型，這里family和protocol都沒有了，因為它們再創建時使用過了，已經被融入到socket結構中。
File指針指向一個file結構，在Linux中一個socket也被抽象為一個文件，所以在應用層一般通過標準的文件操作來操作它。
Ops指向一個struct proto_ops結構，它是每種協議特有的，應用層的系統調用，最終映射到網路棧中具體協議的操作方法。
Sk指向一個struct sock結構，而該結構在分配空間時，多分配了一點以作為該協議的私有部分，這里包含了該協議的具體信息，內容相當多。首先是一個struct sock_common結構，包含了協議的基本信息；然後是一個sk_prot_create指針，指向一個struct proto結構體，該結構體就是第一節中所述的，用proto_regsiter()注冊到內核中的，它包含應用層到協議棧的交互操作和信息（也可以說成是Appà transport layer的交互信息）；然後還有一個sk_backlog_rcv函數指針，所指函數在協議棧處理完接收到的包之後調用，一般僅是把數據包放到該socket的接收隊列中，等待APP讀取；最後協議的私有部分里存放該協議的私有信息，如pppoe的sessionID、daddr，tcp的連接4元組等，這些信息很重要，利用它們來區分同一個協議中的多個socket。
附上出處鏈接：http://blog.csdn.net/vfatfish/article/details/9296885
⑵ Linux TCP/IP協議棧封裝方式及核心數據結構代碼實現分析~
這個不是一兩句講清楚的，推薦做法：
1.《Linux源碼分析》或《Linux源碼情景分析》裡面有詳細描述，這兩本書網上很多下載的
2.如果想弄明白原理的話推薦看TCP／IP詳解
⑶ 如何在linux下開啟napi
天重點對linux網路數據包的處理做下分析，但是並不關繫到上層協議，僅僅到鏈路層。
之前轉載過一篇文章，對NAPI做了比較詳盡的分析，本文結合Linux內核源代碼，對當前網路數據包的處理進行梳理。根據NAPI的處理特性，對設備提出一定的要求
1、設備需要有足夠的緩沖區，保存多個數據分組
2、可以禁用當前設備中斷，然而不影響其他的操作。
當前大部分的設備都支持NAPI，但是為了對之前的保持兼容，內核還是對之前中斷方式提供了兼容。我們先看下NAPI具體的處理方式。我們都知道中斷分為中斷上半部和下半部，上半部完成的任務很是簡單，僅僅負責把數據保存下來；而下半部負責具體的處理。為了處理下半部，每個CPU有維護一個softnet_data結構。我們不對此結構做詳細介紹，僅僅描述和NAPI相關的部分。結構中有一個poll_list欄位，連接所有的輪詢設備。還 維護了兩個隊列input_pkt_queue和process_queue。這兩個用戶傳統不支持NAPI方式的處理。前者由中斷上半部的處理函數吧數據包入隊，在具體的處理時，使用後者做中轉，相當於前者負責接收，後者負責處理。最後是一個napi_struct的backlog，代表一個虛擬設備供輪詢使用。在支持NAPI的設備下，每個設備具備一個緩沖隊列，存放到來數據。每個設備對應一個napi_struct結構，該結構代表該設備存放在poll_list中被輪詢。而設備還需要提供一個poll函數，在設備被輪詢到後，會調用poll函數對數據進行處理。基本邏輯就是這樣，下面看下具體流程。
中斷上半部：
非NAPI：
非NAPI對應的上半部函數為netif_rx，位於Dev.,c中
int netif_rx(struct sk_buff *skb)
{
int ret;
/* if netpoll wants it, pretend we never saw it */
/*如果是net_poll想要的，則不作處理*/
if (netpoll_rx(skb))
return NET_RX_DROP;
/*檢查時間戳*/
net_timestamp_check(netdev_tstamp_prequeue, skb);
trace_netif_rx(skb);
#ifdef CONFIG_RPS
if (static_key_false(&rps_needed)) {
struct rps_dev_flow voidflow, *rflow = &voidflow;
int cpu;
/*禁用搶占*/
preempt_disable();
rcu_read_lock();
cpu = get_rps_cpu(skb->dev, skb, &rflow);
if (cpu < 0)
cpu = smp_processor_id();
/*把數據入隊*/
ret = enqueue_to_backlog(skb, cpu, &rflow->last_qtail);
rcu_read_unlock();
preempt_enable();
} else
#endif
{
unsigned int qtail;
ret = enqueue_to_backlog(skb, get_cpu(), &qtail);
put_cpu();
}
return ret;
}
中間RPS暫時不關心，這里直接調用enqueue_to_backlog放入CPU的全局隊列input_pkt_queue
static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
unsigned int *qtail)
{
struct softnet_data *sd;
unsigned long flags;
/*獲取cpu相關的softnet_data變數*/
sd = &per_cpu(softnet_data, cpu);
/*關中斷*/
local_irq_save(flags);
rps_lock(sd);
/*如果input_pkt_queue的長度小於最大限制，則符合條件*/
if (skb_queue_len(&sd->input_pkt_queue) <= netdev_max_backlog) {
/*如果input_pkt_queue不為空，說明虛擬設備已經得到調度，此時僅僅把數據加入
input_pkt_queue隊列即可
*/
if (skb_queue_len(&sd->input_pkt_queue)) {
enqueue:
__skb_queue_tail(&sd->input_pkt_queue, skb);
input_queue_tail_incr_save(sd, qtail);
rps_unlock(sd);
local_irq_restore(flags);
return NET_RX_SUCCESS;
}
/* Schele NAPI for backlog device
* We can use non atomic operation since we own the queue lock
*/
/*否則需要調度backlog 即虛擬設備，然後再入隊。napi_struct結構中的state欄位如果標記了NAPI_STATE_SCHED,則表明該設備已經在調度，不需要再次調度*/
if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) {
if (!rps_ipi_queued(sd))
____napi_schele(sd, &sd->backlog);
}
goto enqueue;
}
/*到這里緩沖區已經不足了，必須丟棄*/
sd->dropped++;
rps_unlock(sd);
local_irq_restore(flags);
atomic_long_inc(&skb->dev->rx_dropped);
kfree_skb(skb);
return NET_RX_DROP;
}
該函數邏輯也比較簡單，主要注意的是設備必須先添加調度然後才能接受數據，添加調度調用了____napi_schele函數，該函數把設備對應的napi_struct結構插入到softnet_data的poll_list鏈表尾部，然後喚醒軟中斷，這樣在下次軟中斷得到處理時，中斷下半部就會得到處理。不妨看下源碼
static inline void ____napi_schele(struct softnet_data *sd,
struct napi_struct *napi)
{
list_add_tail(&napi->poll_list, &sd->poll_list);
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
}
NAPI方式
NAPI的方式相對於非NAPI要簡單許多，看下e100網卡的中斷處理函數e100_intr，核心部分
if (likely(napi_schele_prep(&nic->napi))) {
e100_disable_irq(nic);//屏蔽當前中斷
__napi_schele(&nic->napi);//把設備加入到輪訓隊列
}
if條件檢查當前設備是否 可被調度，主要檢查兩個方面：1、是否已經在調度 2、是否禁止了napi pending.如果符合條件，就關閉當前設備的中斷，調用__napi_schele函數把設備假如到輪訓列表，從而開啟輪詢模式。
分析：結合上面兩種方式，還是可以發現兩種方式的異同。其中softnet_data作為主導結構，在NAPI的處理方式下，主要維護輪詢鏈表。NAPI設備均對應一個napi_struct結構，添加到鏈表中；非NAPI沒有對應的napi_struct結構，為了使用NAPI的處理流程，使用了softnet_data結構中的back_log作為一個虛擬設備添加到輪詢鏈表。同時由於非NAPI設備沒有各自的接收隊列，所以利用了softnet_data結構的input_pkt_queue作為全局的接收隊列。這樣就處理而言，可以和NAPI的設備進行兼容。但是還有一個重要區別，在NAPI的方式下，首次數據包的接收使用中斷的方式，而後續的數據包就會使用輪詢處理了；而非NAPI每次都是通過中斷通知。
下半部：
下半部的處理函數，之前提到，網路數據包的接發對應兩個不同的軟中斷，接收軟中斷NET_RX_SOFTIRQ的處理函數對應net_rx_action
static void net_rx_action(struct softirq_action *h)
{
struct softnet_data *sd = &__get_cpu_var(softnet_data);
unsigned long time_limit = jiffies + 2;
int budget = netdev_budget;
void *have;
local_irq_disable();
/*遍歷輪詢表*/
while (!list_empty(&sd->poll_list)) {
struct napi_struct *n;
int work, weight;
/* If softirq window is exhuasted then punt.
* Allow this to run for 2 jiffies since which will allow
* an average latency of 1.5/HZ.
*/
/*如果開支用完了或者時間用完了*/
if (unlikely(budget <= 0 || time_after_eq(jiffies, time_limit)))
goto softnet_break;
local_irq_enable();
/* Even though interrupts have been re-enabled, this
* access is safe because interrupts can only add new
* entries to the tail of this list, and only ->poll()
* calls can remove this head entry from the list.
*/
/*獲取鏈表中首個設備*/
n = list_first_entry(&sd->poll_list, struct napi_struct, poll_list);
have = netpoll_poll_lock(n);
weight = n->weight;
/* This NAPI_STATE_SCHED test is for avoiding a race
* with netpoll's poll_napi(). Only the entity which
* obtains the lock and sees NAPI_STATE_SCHED set will
* actually make the ->poll() call. Therefore we avoid
* accidentally calling ->poll() when NAPI is not scheled.
*/
work = 0;
/*如果被設備已經被調度，則調用其處理函數poll函數*/
if (test_bit(NAPI_STATE_SCHED, &n->state)) {
work = n->poll(n, weight);//後面weight指定了一個額度
trace_napi_poll(n);
}
WARN_ON_ONCE(work > weight);
/*總額度遞減*/
budget -= work;
local_irq_disable();
/* Drivers must not modify the NAPI state if they
* consume the entire weight. In such cases this code
* still "owns" the NAPI instance and therefore can
* move the instance around on the list at-will.
*/
/*如果work=weight的話。任務就完成了，把設備從輪詢鏈表刪除*/
if (unlikely(work == weight)) {
if (unlikely(napi_disable_pending(n))) {
local_irq_enable();
napi_complete(n);
local_irq_disable();
} else {
if (n->gro_list) {
/* flush too old packets
* If HZ < 1000, flush all packets.
*/
local_irq_enable();
napi_gro_flush(n, HZ >= 1000);
local_irq_disable();
}
/*每次處理完就把設備移動到列表尾部*/
list_move_tail(&n->poll_list, &sd->poll_list);
}
}
netpoll_poll_unlock(have);
}
out:
net_rps_action_and_irq_enable(sd);
#ifdef CONFIG_NET_DMA
/*
* There may not be any more sk_buffs coming right now, so push
* any pending DMA copies to hardware
*/
dma_issue_pending_all();
#endif
return;
softnet_break:
sd->time_squeeze++;
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
goto out;
}
這里有處理方式比較直觀，直接遍歷poll_list鏈表，處理之前設置了兩個限制：budget和time_limit。前者限制本次處理數據包的總量，後者限制本次處理總時間。只有二者均有剩餘的情況下，才會繼續處理。處理期間同樣是開中斷的，每次總是從鏈表表頭取設備進行處理，如果設備被調度，其實就是檢查NAPI_STATE_SCHED位，則調用 napi_struct的poll函數，處理結束如果沒有處理完，則把設備移動到鏈表尾部，否則從鏈表刪除。NAPI設備對應的poll函數會同樣會調用__netif_receive_skb函數上傳協議棧，這里就不做分析了，感興趣可以參考e100的poll函數e100_poll。
而非NAPI對應poll函數為process_backlog。
static int process_backlog(struct napi_struct *napi, int quota)
{
int work = 0;
struct softnet_data *sd = container_of(napi, struct softnet_data, backlog);
#ifdef CONFIG_RPS
/* Check if we have pending ipi, its better to send them now,
* not waiting net_rx_action() end.
*/
if (sd->rps_ipi_list) {
local_irq_disable();
net_rps_action_and_irq_enable(sd);
}
#endif
napi->weight = weight_p;
local_irq_disable();
while (work < quota) {
struct sk_buff *skb;
unsigned int qlen;
/*涉及到兩個隊列process_queue和input_pkt_queue，數據包到來時首先填充input_pkt_queue，
而在處理時從process_queue中取，根據這個邏輯，首次處理process_queue必定為空，檢查input_pkt_queue
如果input_pkt_queue不為空，則把其中的數據包遷移到process_queue中，然後繼續處理，減少鎖沖突。
*/
while ((skb = __skb_dequeue(&sd->process_queue))) {
local_irq_enable();
/*進入協議棧*/
__netif_receive_skb(skb);
local_irq_disable();
input_queue_head_incr(sd);
if (++work >= quota) {
local_irq_enable();
return work;
}
}
rps_lock(sd);
qlen = skb_queue_len(&sd->input_pkt_queue);
if (qlen)
skb_queue_splice_tail_init(&sd->input_pkt_queue,
&sd->process_queue);
if (qlen < quota - work) {
/*
* Inline a custom version of __napi_complete().
* only current cpu owns and manipulates this napi,
* and NAPI_STATE_SCHED is the only possible flag set on backlog.
* we can use a plain write instead of clear_bit(),
* and we dont need an smp_mb() memory barrier.
*/
list_del(&napi->poll_list);
napi->state = 0;
quota = work + qlen;
}
rps_unlock(sd);
}
local_irq_enable();
return work;
}
函數還是比較簡單的，需要注意的每次處理都攜帶一個配額，即本次只能處理quota個數據包，如果超額了，即使沒處理完也要返回，這是為了保證處理器的公平使用。處理在一個while循環中完成，循環條件正是work < quota，首先會從process_queue中取出skb,調用__netif_receive_skb上傳給協議棧，然後增加work。當work即將大於quota時，即++work >= quota時，就要返回。當work還有剩餘額度，但是process_queue中數據處理完了，就需要檢查input_pkt_queue，因為在具體處理期間是開中斷的，那麼期間就有可能有新的數據包到來，如果input_pkt_queue不為空，則調用skb_queue_splice_tail_init函數把數據包遷移到process_queue。如果剩餘額度足夠處理完這些數據包，那麼就把虛擬設備移除輪詢隊列。這里有些疑惑就是最後為何要增加額度，剩下的額度已經足夠處理這些數據了呀？根據此流程不難發現，其實執行的是在兩個隊列之間移動數據包，然後再做處理。
⑷ 嵌入式Linux內核和網路協議棧的特點,和代表性產品有哪些
首先，嵌入Linux內核是可定製的內核：
1 Linux內核的配置系統
2 Linux內核的模塊機制
3 Linux內核的源代碼開放
4 經裁減的 Linux內核最小可達到 150KB以下，尤其適合嵌入式領域中資源受限的實際情況。
其次，它的性能優越：Linux 系統內核精簡、高效和穩定，能夠充分發揮硬體的功能，因此它比其他操作系統的運行效率更高。
再者，它有良好的網路支持：
1 支持 TCP/IP 協議棧
2 提供對包括十兆位、百兆位及千兆位的乙太網，還有無線網路、Tokenring（令牌環）和光纖甚至衛星的支持
3 對現在依賴於網路的嵌入式設備來說是很好的選擇。
至於網路協議的話，有很多種，就目前主流的3種網路協議是：NetBEUI、IPX/SPX及其兼容協議、TCP/IP，而其他的像Lwip、ZigBee、Sip等很多。
1 NetBEUI的前身是NetBIOS，這一協議是IBM1983年開發完成的，早期的微軟OS產品中都選擇該協議作為通信協議。它是一套用於實現僅僅在小型區域網上PC見相互通信的標准。該網路最大用戶數不能超過30個，1985年，微軟對其改進，增加了SMB(Server Message Blocks，伺服器消息塊)的組成部分，以降低網路的通信阻塞，形成了現在的NetBEUI通信協議。
特點：體積小、效率高、速度快、佔用內存少。
2 IPX/SPX及其兼容協議：它的全稱是「Internwork Packet Exchange/Sequence Packet Exchange」即網際包交換/順序包交換。
特點：體積較大、能夠連接多種網路、具有強大的路由功能，適合大型網路的使用。windows網路中無法直接使用該協議。
3 TCP/IP是國際互聯網Internet採用的協議標准，早期用於ARPANet網路，後來開放用於民間。
特點：靈活性，支持任意規模的網路，可以連接所有的計算機，具有路由功能，且TCP/IP的地址是分級的，容易確定並找到網上的用戶，提高了網路代換的利用率。
而其他的像Lwip協議棧的特點：
（1）支持多網路介面的IP轉發
（2）支持ICMP協議
（3）包括實驗性擴展的UDP
（4）包括阻塞控制，RTT估算和快速恢復和快速轉發的TCP
（5）提供專門的內部回調介面用於提高應用程序性能
（6）可選擇的Berkeley介面API
（7）在最新的版本中支持ppp
不知道這些是不是你想要的。
⑸ 什麼是LINUX
簡單的來說，Linux就是一套免費使用和自由傳播的類UNIX操作系統，它是一個基於POSIX和UNIX的多用戶、多任務、支持多線程和多CPU的操作系統。它能運行在主要的UNIX工具軟體、應用程序以及軟體協議，支持32位、64位硬體，是一個性能非常穩定的多用戶網路操作系統。
Linux操作系統的誕生、發展和成長過程始終依賴著五個重要支柱：UNIX 操作系統、MINIX 操作系統、GNU計劃、POSIX 標准和Internet 網路。
Linux可以用來定製比較喜歡的界面，有好的界面，看著心情也是非常不錯的，撰寫代碼的時候舒適度高，提高編寫速度。Linux系統具有自帶的包管理工具，可以很快的找到所需要的安裝包進行安裝，可以根據自己的喜好，搭配各種環境。
⑹ 關於 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網路協議棧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、狀態相關協議處理結構