繼上一篇介紹了數據包的接收過程后，本文將介紹在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是否會抓到兩次包，按道理應該不會，可能是我哪里沒看懂