Linux網絡 - 數據包的發送過程
繼上一篇介紹了數據包的接收過程后,本文將介紹在Linux系統中,數據包是如何一步一步從應用程序到網卡并最終發送出去的。
如果英文沒有問題,強烈建議閱讀后面參考里的文章,里面介紹的更詳細。
本文只討論以太網的物理網卡,并且以一個UDP包的發送過程作為示例,由于本人對協議棧的代碼不熟,有些地方可能理解有誤,歡迎指正
socket層
- +-------------+
- | Application |
- +-------------+
- |
- |
- ↓
- +------------------------------------------+
- | socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) |
- +------------------------------------------+
- |
- |
- ↓
- +-------------------+
- | sendto(sock, ...) |
- +-------------------+
- |
- |
- ↓
- +--------------+
- | inet_sendmsg |
- +--------------+
- |
- |
- ↓
- +---------------+
- | inet_autobind |
- +---------------+
- |
- |
- ↓
- +-----------+
- | UDP layer |
- +-----------+
- socket(...): 創建一個socket結構體,并初始化相應的操作函數,由于我們定義的是UDP的socket,所以里面存放的都是跟UDP相關的函數
- sendto(sock, ...): 應用層的程序(Application)調用該函數開始發送數據包,該函數數會調用后面的inet_sendmsg
- inet_sendmsg: 該函數主要是檢查當前socket有沒有綁定源端口,如果沒有的話,調用inet_autobind分配一個,然后調用UDP層的函數
- inet_autobind: 該函數會調用socket上綁定的get_port函數獲取一個可用的端口,由于該socket是UDP的socket,所以get_port函數會調到UDP代碼里面的相應函數。
UDP層
- |
- |
- ↓
- +-------------+
- | udp_sendmsg |
- +-------------+
- |
- |
- ↓
- +----------------------+
- | ip_route_output_flow |
- +----------------------+
- |
- |
- ↓
- +-------------+
- | ip_make_skb |
- +-------------+
- |
- |
- ↓
- +------------------------+
- | udp_send_skb(skb, fl4) |
- +------------------------+
- |
- |
- ↓
- +----------+
- | IP layer |
- +----------+
- udp_sendmsg: udp模塊發送數據包的入口,該函數較長,在該函數中會先調用ip_route_output_flow獲取路由信息(主要包括源IP和網卡),然后調用ip_make_skb構造skb結構體,***將網卡的信息和該skb關聯。
- ip_route_output_flow: 該函數會根據路由表和目的IP,找到這個數據包應該從哪個設備發送出去,如果該socket沒有綁定源IP,該函數還會根據路由表找到一個最合適的源IP給它。 如果該socket已經綁定了源IP,但根據路由表,從這個源IP對應的網卡沒法到達目的地址,則該包會被丟棄,于是數據發送失敗,sendto函數將返回錯誤。該函數***會將找到的設備和源IP塞進flowi4結構體并返回給udp_sendmsg
- ip_make_skb: 該函數的功能是構造skb包,構造好的skb包里面已經分配了IP包頭,并且初始化了部分信息(IP包頭的源IP就在這里被設置進去),同時該函數會調用__ip_append_dat,如果需要分片的話,會在__ip_append_data函數中進行分片,同時還會在該函數中檢查socket的send buffer是否已經用光,如果被用光的話,返回ENOBUFS
- udp_send_skb(skb, fl4) 主要是往skb里面填充UDP的包頭,同時處理checksum,然后調用IP層的相應函數。
IP層
- |
- |
- ↓
- +-------------+
- | ip_send_skb |
- +-------------+
- |
- |
- ↓
- +-------------------+ +-------------------+ +---------------+
- | __ip_local_out_sk |------>| NF_INET_LOCAL_OUT |------>| dst_output_sk |
- +-------------------+ +-------------------+ +---------------+
- |
- |
- ↓
- +------------------+ +----------------------+ +-----------+
- | ip_finish_output |<-------| NF_INET_POST_ROUTING |<------| ip_output |
- +------------------+ +----------------------+ +-----------+
- |
- |
- ↓
- +-------------------+ +------------------+ +----------------------+
- | ip_finish_output2 |----->| dst_neigh_output |------>| neigh_resolve_output |
- +-------------------+ +------------------+ +----------------------+
- |
- |
- ↓
- +----------------+
- | dev_queue_xmit |
- +----------------+
- ip_send_skb: IP模塊發送數據包的入口,該函數只是簡單的調用一下后面的函數
- __ip_local_out_sk: 設置IP報文頭的長度和checksum,然后調用下面netfilter的鉤子
- NF_INET_LOCAL_OUT: netfilter的鉤子,可以通過iptables來配置怎么處理該數據包,如果該數據包沒被丟棄,則繼續往下走
- dst_output_sk: 該函數根據skb里面的信息,調用相應的output函數,在我們UDP IPv4這種情況下,會調用ip_output
- ip_output: 將上面udp_sendmsg得到的網卡信息寫入skb,然后調用NF_INET_POST_ROUTING的鉤子
- NF_INET_POST_ROUTING: 在這里,用戶有可能配置了SNAT,從而導致該skb的路由信息發生變化
- ip_finish_output: 這里會判斷經過了上一步后,路由信息是否發生變化,如果發生變化的話,需要重新調用dst_output_sk(重新調用這個函數時,可能就不會再走到ip_output,而是走到被netfilter指定的output函數里,這里有可能是xfrm4_transport_output),否則往下走
- ip_finish_output2: 根據目的IP到路由表里面找到下一跳(nexthop)的地址,然后調用__ipv4_neigh_lookup_noref去arp表里面找下一跳的neigh信息,沒找到的話會調用__neigh_create構造一個空的neigh結構體
- dst_neigh_output: 在該函數中,如果上一步ip_finish_output2沒得到neigh信息,那么將會走到函數neigh_resolve_output中,否則直接調用neigh_hh_output,在該函數中,會將neigh信息里面的mac地址填到skb中,然后調用dev_queue_xmit發送數據包
- neigh_resolve_output: 該函數里面會發送arp請求,得到下一跳的mac地址,然后將mac地址填到skb中并調用dev_queue_xmit
netdevice子系統
- |
- |
- ↓
- +----------------+
- +----------------| dev_queue_xmit |
- | +----------------+
- | |
- | |
- | ↓
- | +-----------------+
- | | Traffic Control |
- | +-----------------+
- | loopback |
- | or +--------------------------------------------------------------+
- | IP tunnels ↓ |
- | ↓ |
- | +---------------------+ Failed +----------------------+ +---------------+
- +----------->| dev_hard_start_xmit |---------->| raise NET_TX_SOFTIRQ |- - - - >| net_tx_action |
- +---------------------+ +----------------------+ +---------------+
- |
- +----------------------------------+
- | |
- ↓ ↓
- +----------------+ +------------------------+
- | ndo_start_xmit | | packet taps(AF_PACKET) |
- +----------------+ +------------------------+
- dev_queue_xmit: netdevice子系統的入口函數,在該函數中,會先獲取設備對應的qdisc,如果沒有的話(如loopback或者IP tunnels),就直接調用dev_hard_start_xmit,否則數據包將經過Traffic Control模塊進行處理
- Traffic Control: 這里主要是進行一些過濾和優先級處理,在這里,如果隊列滿了的話,數據包會被丟掉,詳情請參考文檔,這步完成后也會走到dev_hard_start_xmit
- dev_hard_start_xmit: 該函數中,首先是拷貝一份skb給“packet taps”,tcpdump就是從這里得到數據的,然后調用ndo_start_xmit。如果dev_hard_start_xmit返回錯誤的話(大部分情況可能是NETDEV_TX_BUSY),調用它的函數會把skb放到一個地方,然后拋出軟中斷NET_TX_SOFTIRQ,交給軟中斷處理程序net_tx_action稍后重試(如果是loopback或者IP tunnels的話,失敗后不會有重試的邏輯)
- ndo_start_xmit: 這是一個函數指針,會指向具體驅動發送數據的函數
Device Driver
ndo_start_xmit會綁定到具體網卡驅動的相應函數,到這步之后,就歸網卡驅動管了,不同的網卡驅動有不同的處理方式,這里不做詳細介紹,其大概流程如下:
- 將skb放入網卡自己的發送隊列
- 通知網卡發送數據包
- 網卡發送完成后發送中斷給CPU
- 收到中斷后進行skb的清理工作
在網卡驅動發送數據***程中,會有一些地方需要和netdevice子系統打交道,比如網卡的隊列滿了,需要告訴上層不要再發了,等隊列有空閑的時候,再通知上層接著發數據。
其它
- SO_SNDBUF: 從上面的流程中可以看出來,對于UDP來說,沒有一個對應send buffer存在,SO_SNDBUF只是一個限制,當這個socket分配的skb占用的內存超過這個值的時候,會返回ENOBUFS,所以說只要不出現ENOBUFS錯誤,把這個值調大沒有意義。從sendto函數的幫助文件里面看到這樣一句話:(Normally, this does not occur in Linux. Packets are just silently dropped when a device queue overflows.)。這里的device queue應該指的是Traffic Control里面的queue,說明在linux里面,默認的SO_SNDBUF值已經夠queue用了,疑問的地方是,queue的長度和個數是可以配置的,如果配置太大的話,按道理應該有可能會出現ENOBUFS的情況。
- txqueuelen: 很多地方都說這個是控制qdisc里queue的長度的,但貌似只是部分類型的qdisc用了該配置,如linux默認的pfifo_fast。
- hardware RX: 一般網卡都有一個自己的ring queue,這個queue的大小可以通過ethtool來配置,當驅動收到發送請求時,一般是放到這個queue里面,然后通知網卡發送數據,當這個queue滿的時候,會給上層調用返回NETDEV_TX_BUSY
- packet taps(AF_PACKET): 當***次發送數據包和重試發送數據包時,都會經過這里,如果發生重試的情況的話,不確定tcpdump是否會抓到兩次包,按道理應該不會,可能是我哪里沒看懂
參考