一：什么是Netlink通信機制

Netlink是linux提供的用于內核和用戶態進程之間的通信方式。

但是注意雖然Netlink主要用于用戶空間和內核空間的通信，但是也能用于用戶空間的兩個進程通信。只是進程間通信有其他很多方式，一般不用Netlink。除非需要用到Netlink的廣播特性時。

那么Netlink有什么優勢呢？

一般來說用戶空間和內核空間的通信方式有三種：/proc、ioctl、Netlink。而前兩種都是單向的，但是Netlink可以實現雙工通信。

Netlink協議基于BSD socket和AF_NETLINK地址簇(address family)，使用32位的端口號尋址(以前稱作PID)，每個Netlink協議(或稱作總線，man手冊中則稱之為netlink family)，通常與一個或一組內核服務/組件相關聯，如NETLINK_ROUTE用于獲取和設置路由與鏈路信息、NETLINK_KOBJECT_UEVENT用于內核向用戶空間的udev進程發送通知等。

netlink具有以下特點：

① 支持全雙工、異步通信(當然同步也支持)

② 用戶空間可使用標準的BSD socket接口(但netlink并沒有屏蔽掉協議包的構造與解析過程，推薦使用libnl等第三方庫)

③ 在內核空間使用專用的內核API接口

④ 支持多播(因此支持“總線”式通信，可實現消息訂閱)

⑤ 在內核端可用于進程上下文與中斷上下文

二：用戶態數據結構

首先看一下幾個重要的數據結構的關系：

1.struct msghdr

msghdr這個結構在socket變成中就會用到，并不算Netlink專有的，這里不在過多說明。只說明一下如何更好理解這個結構的功能。我們知道socket消息的發送和接收函數一般有這幾對：recv／send、readv／writev、recvfrom／sendto。當然還有recvmsg／sendmsg，前面三對函數各有各的特點功能，而recvmsg／sendmsg就是要囊括前面三對的所有功能，當然還有自己特殊的用途。msghdr的前兩個成員就是為了滿足recvfrom／sendto的功能，中間兩個成員msg_iov和msg_iovlen則是為了滿足readv／writev的功能，而最后的msg_flags則是為了滿足recv／send中flag的功能，剩下的msg_control和msg_controllen則是滿足recvmsg／sendmsg特有的功能。

2.struct sockaddr_ln

struct sockaddr_ln為Netlink的地址，和我們通常socket編程中的sockaddr_in作用一樣，他們的結構對比如下：

struct sockaddr_nl的詳細定義和描述如下：

(1) nl_pid：在Netlink規范里，PID全稱是Port-ID(32bits)，其主要作用是用于唯一的標識一個基于netlink的socket通道。通常情況下nl_pid都設置為當前進程的進程號。前面我們也說過，Netlink不僅可以實現用戶-內核空間的通信還可使現實用戶空間兩個進程之間，或內核空間兩個進程之間的通信。該屬性為0時一般指內核。

(2) nl_groups：如果用戶空間的進程希望加入某個多播組，則必須執行bind()系統調用。該字段指明了調用者希望加入的多播組號的掩碼(注意不是組號，后面我們會詳細講解這個字段)。如果該字段為0則表示調用者不希望加入任何多播組。對于每個隸屬于Netlink協議域的協議，最多可支持32個多播組(因為nl_groups的長度為32比特)，每個多播組用一個比特來表示。

3.struct nlmsghdr

Netlink的報文由消息頭和消息體構成，struct nlmsghdr即為消息頭。消息頭定義在文件里，由結構體nlmsghdr表示：

消息頭中各成員屬性的解釋及說明：

(1) nlmsg_len：整個消息的長度，按字節計算。包括了Netlink消息頭本身。

(2) nlmsg_type：消息的類型，即是數據還是控制消息。目前(內核版本2.6.21)Netlink僅支持四種類型的控制消息，如下：

a) NLMSG_NOOP-空消息，什么也不做；

b) NLMSG_ERROR-指明該消息中包含一個錯誤；

c) NLMSG_DONE-如果內核通過Netlink隊列返回了多個消息，那么隊列的最后一條消息的類型為NLMSG_DONE，其余所有消息的nlmsg_flags屬性都被設置NLM_F_MULTI位有效。

d) NLMSG_OVERRUN-暫時沒用到。

(3) nlmsg_flags：附加在消息上的額外說明信息，如上面提到的NLM_F_MULTI。

三：用戶空間Netlink socket API

1.創建socket

int socket(int domain, int type, int protocol)

domain指代地址族,即AF_NETLINK;

套接字類型為SOCK_RAW或SOCK_DGRAM,因為netlink是一個面向數據報的服務;

protocol選擇該套接字使用哪種netlink特征。

以下是幾種預定義的協議類型:

NETLINK_ROUTE,

NETLINK_FIREWALL,

NETLINK_APRD,

NETLINK_ROUTE6_FW。

可以非常容易的添加自己的netlink協議。

為每一個協議類型最多可以定義32個多播組。

每一個多播組用一個bitmask來表示,1<

2.地址綁定bind()

bind(fd, (struct sockaddr*)&, nladdr, sizeof(nladdr));

3.發送netlink消息

為了發送一條netlink消息到內核或者其他的用戶空間進程,另外一個struct sockaddr_nl nladdr需要作為目的地址,這和使用sendmsg()發送一個UDP包是一樣的。

如果該消息是發送至內核的,那么nl_pid和nl_groups都置為0.

如果消息是發送給另一個進程的單播消息,nl_pid是另外一個進程的pid值而nl_groups為零。

如果消息是發送給一個或多個多播組的多播消息,所有的目的多播組必須bitmask必須or起來從而形成nl_groups域。

sendmsg(fd, &, msg, 0);

4.接收netlink消息

一個接收程序必須分配一個足夠大的內存用于保存netlink消息頭和消息負載。然后其填充struct msghdr msg,再使用標準的recvmsg()函數來接收netlink消息。

當消息被正確的接收之后,nlh應該指向剛剛接收到的netlink消息的頭。nladdr應該包含接收消息的目的地址,其中包括了消息發送者的pid和多播組。同時,宏NLMSG_DATA(nlh),定義在netlink.h中,返回一個指向netlink消息負載的指針。調用close(fd)關閉fd描述符所標識的socket

recvmsg(fd, &, msg, 0);

四：內核空間Netlink socket API

1.創建 netlink socket

參數說明：

(1) net：是一個網絡名字空間namespace，在不同的名字空間里面可以有自己的轉發信息庫，有自己的一套net_device等等。默認情況下都是使用 init_net這個全局變量。

(2) unit：表示netlink協議類型，如NETLINK_TEST、NETLINK_SELINUX。

(3) groups：多播地址。

(4) input：為內核模塊定義的netlink消息處理函數，當有消 息到達這個netlink socket時，該input函數指針就會被引用，且只有此函數返回時，調用者的sendmsg才能返回。

(5) cb_mutex：為訪問數據時的互斥信號量。

(6) module：一般為THIS_MODULE。

2.發送單播消息 netlink_unicast

參數說明：

(1) ssk：為函數 netlink_kernel_create()返回的socket。

(2) skb：存放消息，它的data字段指向要發送的netlink消息結構，而 skb的控制塊保存了消息的地址信息，宏NETLINK_CB(skb)就用于方便設置該控制塊。

(3) pid：為接收此消息進程的pid，即目標地址，如果目標為組或內核，它設置為 0。

(4) nonblock：表示該函數是否為非阻塞，如果為1，該函數將在沒有接收緩存可利用時立即返回；而如果為0，該函數在沒有接收緩存可利用定時睡眠。

3.發送廣播消息 netlink_broadcast

前面的三個參數與 netlink_unicast相同，參數group為接收消息的多播組，該參數的每一個位代表一個多播組，因此如果發送給多個多播組，就把該參數設置為多個多播組組ID的位或。參數allocation為內核內存分配類型，一般地為GFP_ATOMIC或GFP_KERNEL，GFP_ATOMIC用于原子的上下文（即不可以睡眠），而GFP_KERNEL用于非原子上下文。

4.釋放 netlink socket

五：用戶態范例一

上面程序首先向內核發送一條消息；“Hello you”，然后進入循環一直等待讀取內核的回復，并將收到的回復打印出來。如果看上面程序感覺很吃力，那么應該首先復習一下UDP中使用sendmsg的用法，特別時struct msghdr的結構要清楚，這里再贅述。下面主要分析與UDP發送數據包的不同點：

1. socket地址結構不同，UDP為sockaddr_in，Netlink為struct sockaddr_nl；
2. 與UDP發送數據相比，Netlink多了一個消息頭結構struct nlmsghdr需要我們構造。

注意代碼注釋中的A、B、C三處分別設置了pid。首先解釋一下什么是pid，網上很多文章把這個字段說成是進程的pid，其實這完全是望文生義。這里的pid和進程pid沒有什么關系，僅僅相當于UDP的port。對于UDP來說port和ip標示一個地址，那對我們的NETLINK_TEST協議（注意Netlink本身不是一個協議）來說，pid就唯一標示了一個地址。所以你如果用進程pid做為標示當然也是可以的。當然同樣的pid對于NETLINK_TEST協議和內核定義的其他使用Netlink的協議是不沖突的（就像TCP的80端口和UDP的80端口）。

下面分析這三處設置pid分別有什么作用，首先A和B位置的比較好理解，這是在地址（sockaddr_nl）上進行的設置，就是相當于設置源地址和目的地址（其實是端口），只是注意B處設置pid為0，0就代表是內核，可以理解為內核專用的pid，那么用戶進程就不能用0做為自己的pid嗎？這個只能說如果你非要用也是可以的，只是會產生一些問題，后面在分析。

接下來看為什么C處的消息頭仍然需要設置pid呢？這里首先要知道一個前提：內核不會像UDP一樣根據我們設置的原、目的地址為我們構造消息頭，所以我們不在包頭寫入我們自己的地址（pid），那內核怎么知道是誰發來的報文呢？當然如果內核只是處理消息不需要回復進程的話舍不設置這個消息頭pid都可以。

所以每個pid的設置功能不同：A處的設置是要設置發送者的源地址，有人會說既然源地址又不會自動填充到報文中，我們為什么還要設置這個，因為你還可能要接收回復啊。就像寄信，你連“門牌號”都沒有，即使你在寫信時候寫上你的地址是100號，對方回信目的地址也是100號，但是郵局發現根本沒有這個地址怎么可能把信送到你手里呢？所以A的主要作用是注冊源地址，保證可以收到回復，如果不需要回復當然可以簡單將pid設置為0；B處自然就是收信人的地址，pid為0代表內核的地址，假如有一個進程在101號上注冊了地址，并調用了recvmsg，如果你將B處的pid設置為101，那數據包就發給了另一個進程，這就實現了使用Netlink進行進程間通信；C相當于你在信封上寫的源地址，通常情況下這個應該和你的真實地址（A）處注冊的源地址相同，當然你要是不想收到回信，又想惡搞一下或者有特殊需求，你可以寫成其他進程注冊的pid（比如101）。這和我們現實中寄信是一樣的，你給你朋友寫封情書，把寫信人寫成你的另一個好基友，然后后果你懂得……

好了，有了這個例子我們就大概知道用戶態怎么使用Netlink了。

六：內核態程序范例一

附上內核代碼的Makefile文件：

我們將內核模塊insmod后，運行用戶態程序，結果如下：

這個結果復合我們的預期，但是運行過程中打印出“state_smg”卡了好久才輸出了后面的結果。這時候查看客戶進程是處于D狀態的（不了解D狀態的同學可以google一下）。這是為什么呢？因為進程使用Netlink向內核發數據是同步，內核向進程發數據是異步。什么意思呢？也就是用戶進程調用sendmsg發送消息后，內核會調用相應的接收函數，但是一定到這個接收函數執行完用戶態的sendmsg才能夠返回。我們在內核態的接收函數中調用了10次回發函數，每次都等待3秒鐘，所以內核接收函數30秒后才返回，所以我們用戶態程序的sendmsg也要等30秒后才返回。相反，內核回發的數據不用等待用戶程序接收，這是因為內核所發的數據會暫時存放在一個隊列中。

再來回到之前的一個問題，用戶態程序的源地址（pid）可以用0嗎？我把上面的用戶程序的A和C處pid都改為了0，結果一運行就死機了。為什么呢？我們看一下內核代碼的邏輯，收到用戶消息后，根據消息中的pid發送回去，而pid為0，內核并不認為這是用戶程序，認為是自身，所有又將回發的10個消息發給了自己（內核），這樣就陷入了一個死循環，而用戶態這時候進程一直處于D。

另外一個問題，如果同時啟動兩個用戶進程會是什么情況？答案是再調用bind時出錯：“Address already in use”，這個同UDP一樣，同一個地址同一個port如果沒有設置SO_REUSEADDR兩次bind就會出錯，之后我用同樣的方式再Netlink的socket上設置了SO_REUSEADDR，但是并沒有什么效果。

七：用戶態范例二

之前我們說過UDP可以使用sendmsg／recvmsg也可以使用sendto／recvfrom，那么Netlink同樣也可以使用sendto／recvfrom。具體實現如下：

熟悉UDP編程的同學看到這個程序一定很熟悉，除了多了一個Netlink消息頭的設置。但是我們發現程序中調用了bind函數，這個函數再UDP編程中的客戶端不是必須的，因為我們不需要把UDP socket與某個地址關聯，同時再發送UDP數據包時內核會為我們分配一個隨即的端口。但是對于Netlink必須要有這一步bind，因為Netlink內核可不會為我們分配一個pid。再強調一遍消息頭（nlmsghdr）中的pid是告訴內核接收端要回復的地址，但是這個地址存不存在內核并不關心，這個地址只有用戶端調用了bind后才存在。

我們看到這兩個例子都是用戶態首先發起的，那Netlink是否支持內核態主動發起的情況呢？

當然是可以的，只是內核一般需要事件觸發，這里，只要和用戶態約定號一個地址（pid），內核直接調用netlink_unicast就可以了。