? libnl 庫提供了壹套應用於Linux系統基於Netlink協議通信的API接口。從本質上看，Netlink其實是壹種典型的IPC機制，只不過此IPC主要是介於用戶空間與內核空間之間的通信，而非傳統意義上用戶空間進程之間的通信。Netlink是設計出來替換 ioctl 機制，就目前的使用情況，這壹點顯然還沒有完全達到。
? libnl 在設計上被分割為若幹個小型庫( small libraries )，應用程序在鏈接時可以擇庫鏈接，無需將所有庫鏈接到應用程序中。
libnl提供的主要頭文件為 <netlink/netlink.h> ，此外還提供了壹些其他頭文件，可以視應用程序的需要酌情增刪。
可以在gcc中直接鏈接libnl庫
?Netlink 協議是基於套接字的進程間通信（IPC）機制，它可用於用戶空間進程和內核之間或者用戶空間進程之間的通信。Netlink協議基於BSD套接字並使用AF_NETLINK地址簇。每壹個Netlink協議都有自己的協議號（比如：NETLINK_ROUTE、NETLINK_NETFILTER等）。它的尋址方案是基於 32 位的端口號（之前被稱為 PID），此端口號用於唯壹地標識每壹個對等通信節點。
?Netlink 地址（端口）由壹個 32 位的整數組成。端口（port）零保留給內核使用，表示每個Netlink協議簇中內核部分的套接字，其他的端口則通常指的是用戶空間的套接字。
? 註意： 最初通常使用進程標識符（PID）作為本地端口號，但這種方式隨著線程化Netlink應用程序的引入而失效，因為這類進程需要多個套接字。為解決此項沖突，libnl以進程標識符為基數再加上壹個偏移量來生成唯壹的端口號，此方式可以讓壹個進程使用多個套接字。出於向後兼容方面的考慮，第壹個套接字還是以進程標識符作為端口號。
?Netlink最常見的應用場景就是用戶空間應用程序發送請求給內核，比如設置/讀取接口的IP地址，然後接受並處理內核返回的信息，這個回復信息要麽是請求出錯的信息，要麽就是請求成功的通知信息。
?Netlink也可以直接作為用戶空間應用程序之間的進程間通信機制，但這種方式並不常見，通常會代之以unix域套接字。這種通信並不限制在兩個對等通信節點之間，任意壹個節點都可以和其他的對等點進行通信。此外因為Netlink支持多播，壹條消息可以由多個節點同時接收到。
?註意：為了讓套接字對通信雙方可見，這兩個套接字必須在同壹個Netlink協議簇下創建。
?此類Netlink通信是壹種非常常見的應用方式，此方式可以讓用戶空間那些需要處理特定內核事件的的守護進程偵聽內核反饋的消息/事件。這些應用程序進程通常會訂閱內核使用的某個多播組，內核則在某些事件發生的時候通過它來通知訂閱該組播組的進程。
?相對於直接尋址來說，多播（組播）尋址是壹個更好的方式，因為它有更高的靈活性，可以在無需通知內核的情況下隨時與用戶空間應用組件交換信息。
?Netlink協議通常是基於消息的，消息則通常是由Netlink消息頭部（struct nlmsghdr）加上有效載荷組成。雖然有效載荷可以由任何數據組成，但是它通常的格式是壹 個固定大小的協議相關頭部後面緊跟壹系列的屬性。
?Netlink 在請求消息（requests）、通知消息（notifications）和應答消息（replies）的 處理上是有區別的。請求消息設有 NLM_F_REQUEST 標誌位，它用來向接收方請求某種響應 。壹般來說請求消息都是從用戶空間發送到內核的。雖然不是強制規定，但每次發送的請求 消息序列號都應該是上壹個序列號加壹。
?由於請求自身的特性，接收方在收到請求消息之後可能會發送另壹條 netlink 消息來響應 這個請求。應答消息的序列號必須和它響應的那條請求消息的序列號壹致。
?通知消息則沒有那麽嚴謹，它不需要應答，所以序列號通常是被設置成 0 的。
消息的類型主要是由消息頭部中 16 位的消息類型字段確定的。Netlink 定義了如下標準消息類型：
?每個 netlink 協議都可以自由的定義自己的消息類型。需要註意的是小於 NLMSG_MIN_TYPE(0x10) 的類型是保留的，所以不能使用。通常我們會定義自己的消息類型來實現 RPC 模式。假設妳的 netlink 協議的目的是允許妳 配置壹個網絡設備的某些部分，所以妳想要提供各種配置選項的讀/寫訪問。完成這項任務 典型的 “netlik 解決方案” 是定義兩種消息類型 MSG_SETCFG，MSG_GETCFG :
?發送壹條 MSG_GETCFG 請求消息通常會收到壹條包含當前配置信息的類型為 MSG_SETCFG 的應答消息。用面向對象的術語來說這叫做 “內核在用戶空間設置了配置信息的本地拷貝”
?理論上壹條 netlink 消息的最大長度是 4GiB，但是套接字的緩沖區壹般不會設置有如此大的空間來容納4GiB消息。通常情況下，消息的長度被限制在頁的大小（PAGE_SIZE ）之內，然後使用分片機制把大消息分割為多個消息。分片消息設有 NLM_F_MULTI 標誌位，接收者需要不斷的接收和解析消息，直至收到壹個消息類型為 NLMSG_DONE 的消息為止。
?和分片之後的ip包不壹樣，分片之後的Netlink消息無需重組，但是如果協議需要重組，也可以執行重組動作。分片消息經常會被用來發送對象列表或者是對象樹，這種情況下消息段只是簡單的承載幾個對象，壹般允許單獨處理每個消息分片。
?錯誤消息可以作為請求消息的響應發送回去，錯誤消息必須使用標準的消息類型 NLMSG_ERROR ，它的有效載荷是由錯誤碼和原來的請求消息頭部組成。
?發送方可以通過設置 NLM_F_ACK 標誌位來要求接收方為處理過的每壹個請求消息都發送壹 個ACK消息。這種方式通常是用來讓發送方在請求被接收方處理之後同步下壹步的操作。
? NLM_F_ECHO 標誌和 NLM_F_ACK 標誌類似，它可以和 NLM_F_REQUEST 標誌位壹起使 用，使得發送者能夠收到作為這條請求消息的響應而產生的通知信息，無論發送者是否訂閱過相應的多播組。
GET 請求還定義了壹些額外的通用標誌位：
?這些標誌的使用是完全可選的，許多netlink協議都只使用NLM_F_DUMP標誌。這個標誌通常用來請求接收者發送壹個包含所有對象的列表，而這個列表則通常是壹系列的消息分片。
?還有壹些和 NEW 或者是 SET 請求相關的標誌。這些標誌和 GET 的那些標誌是彼此互斥的 ：
這些標誌含義在不同的 netlink 協議中可能會有細微的差別。
?Netlink允許通過序列號來關聯回復和請求。需要註意的是，這裏的序列號和 TCP 這類的協議的序列號是不壹樣的，Netlink的序列號並不強制使用。序列號唯壹的用途就是把壹條應答消息和相應的請求消息聯系起來，序列號是以單個套接字為基礎來管理。