图解 | 当内核收到了一个网络包

Posted 2022-02-11 码农翻身

之前两篇文章给这篇做了铺垫，分别讲了。

硬中断的原理：《认认真真聊聊中断》

软中断的原理：《认认真真聊聊软中断》

不了解的朋友可以先回顾一下，不回顾也没关系，跟着本文思路，如果实在顺不下去，再了解也不迟，我们开始吧。

从网线到网卡

现在，就有一个数据包，即将从网线进入网卡。

这个数据包从很遥远的另一台计算机发出，经历重重艰难险阻，到达了这台计算机的网卡，这个过程可以阅读《如果让你来设计网络》，总之现在这个数据包已经过来了。

这个数据包来了之后，现在只是一堆电信号，离内核程序的处理还十万八千里呢，需要先经历网卡这个硬件的折磨。

我们把上图中的网卡放大看看。

最开始就是我们常见的网线插口，之后会经过信号转换的模块 PHY，再经过 MAC 模块，最后到达网卡内的一个缓冲区，注意哦这个是网卡这个硬件设备内的缓冲区，此时和内核代码还一点关系也没有。

总之这个过程，实质上就是把网线中的高低电平，转换到网卡上的一个缓冲区中存储着。

从网卡到内存

上一步，数据到达了网卡这个硬件的缓冲区中，现在要把它弄到内存中的缓冲区，简单一张图就是这样。

而且，这个过程完全不需要 CPU 参与，只需要 DMA 这个硬件设备，配合网卡这个硬件设备即可完成。

当然，这个过程的前提是，网卡驱动需要在内存中申请一个缓冲区叫 sk_buffer，然后把这个 sk_buffer 的地址告诉网卡，这样 DMA 才知道等网卡的缓冲区有数据到来时，把它拷贝到内存的什么位置上。

具体过程展开如下。

注册硬中断处理程序

之前的部分就不展示代码了，比较繁琐，且对主流程的理解帮助不大。总之现在，这份数据包，已经从网卡内的缓冲区，然后通过 DMA 的方式，拷贝到了内存中的 sk_buffer 这个结构中。

由于这个过程完全是由硬件完成的，所以下一步网卡该做的最后一件事，就是通知内核，让内核去处理这个数据。

怎么通知呢？就是中断。

网卡向 CPU 发起中断信号，CPU 打断当前的程序，根据中断号找到中断处理程序，开始执行。

那我们主要去看，这个网卡收包这个中断处理程序是什么，以及它是如何注册到中断向量表中的。

由于各个类型的网卡驱动程序是不同的，这里我们拿 e1000 这个网卡驱动来举例。我们在 e1000_main.c 中找到了这样一行代码。

request_irq(netdev->irq, &e1000_intr, ...);

这段代码的作用就是，当数据包从网卡缓冲区到内存中的 sk_buffer 后发出中断，将会执行到 e1000_intr 这个中断处理函数。

硬中断 e1000_intr 干了什么

drivers\\net\\e1000\\e1000_main.c

// 注册的硬中断处理函数
static irqreturn_t e1000_intr(int irq, void *data, struct pt_regs *regs) 
   __netif_rx_schedule(netdev);

include\\linux\\netdevice.h
static inline void __netif_rx_schedule(struct net_device *dev) 
    list_add_tail(&dev->poll_list, &__get_cpu_var(softnet_data).poll_list);
    // 发出软中断    
    __raise_softirq_irqoff(NET_RX_SOFTIRQ);

没错，几乎啥也没干，将网卡设备 dev 放入 poll_list 里，然后立刻发起了一次软中断，然后就结束了。

软中断原理在《认认真真聊聊软中断》讲过，其实就是修改 pending 的某个标志位，然后内核中有一个线程不断轮询这组标志位，看哪个是 1 了，就去软中断向量表里，寻找这个标志位对应的处理程序，然后执行它。

这是为了尽快响应硬中断，以便计算机可以尽快处理下一个硬中断，毕竟鼠标点击、键盘敲击等需要响应特别及时。而像网络包到来后的拷贝和解析过程，在硬中断面前优先级没那么高，所以就触发一个软中断等着内核线程去执行就好了。

注册软中断处理程序

刚刚代码中我们就触发了一个值为 NET_RX_SOFTIRQ 的软中断，那这个软中断会执行到哪个软中断处理函数呢？

内核早在网络子系统初始化的过程中，把这个软中断对应的处理函数注册好了。

net\\core\\dev.c

static int __init net_dev_init(void) 
    open_softirq(NET_TX_SOFTIRQ, net_tx_action, NULL);
    open_softirq(NET_RX_SOFTIRQ, net_rx_action, NULL);


// transmit 发送
static void net_tx_action(struct softirq_action *h) ...
// receive 接收
static void net_rx_action(struct softirq_action *h) ...

这个 open_softirq 就是注册一个软中断函数，很简单，就是把这个函数赋值给软中断向量表中对应位置的 action 上。还是上面的图。

这里注册了两个软中断，一个发送，一个接收。我们这次是接收，所以软中断触发后，就执行到了 net_rx_action 这个函数。

软中断 net_rx_action 干了什么

直接看！

net\\core\\dev.c

static void net_rx_action(struct softirq_action *h) 
    struct softnet_data *queue = &__get_cpu_var(softnet_data);   
    while (!list_empty(&queue->poll_list)) 
        struct net_device dev = list_entry(
            queue->poll_list.next, struct net_device, poll_list);
        dev->poll(dev, &budget)；
    

遍历 poll_list 取出一个个的设备 dev，然后调用其 poll 函数。

还记得我们发起软中断前的一行代码吧？正是把当前有数据包到来的这个网卡设备 dev 放入了这个 poll_list，现在又取出来了。

由于要调用该网卡相应驱动的 poll 函数，那网卡初始化时，e1000 这款网卡的 poll 函数被附上了这个函数地址。

netdev->poll = &e1000_clean;

所以，接下来就看这个函数就好了，听名字就知道是清理这个网卡的数据包的工作。

drivers\\net\\e1000\\e1000_main.c

static int e1000_clean(struct net_device *netdev, int *budget) 
    struct e1000_adapter *adapter = netdev->priv;    
    e1000_clean_tx_irq(adapter);
    e1000_clean_rx_irq(adapter, &work_done, work_to_do);

由于本讲我们只看读数据的过程，所以就看 rx 部分就好了。

这个函数过长，我们只顺着一条线往下跟。

// drivers\\net\\e1000\\e1000_main.c
e1000_clean_rx_irq(struct e1000_adapter *adapter) 
    ...
    netif_receive_skb(skb);
    ...


// net\\core\\dev.c
int netif_receive_skb(struct sk_buff *skb) 
    ...
    list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type)&15], list) 
        ...
        deliver_skb(skb, ptype, 0);
        ...
    
    ...


static __inline__ int deliver_skb(
        struct sk_buff *skb, struct packet_type *pt_prev, int last) 
    ...
    return pt_prev->func(skb, skb->dev, pt_prev);

我们看到，一路跟来，执行了 pt_prev 的 func 函数。

这个函数是干嘛的呢？或者先问，这个函数具体的实现指向的是哪个函数呢？这就涉及到协议栈的注册。

协议栈的注册

IP 协议的注册，在这里。

// net\\ipv4\\ip_output.c
static struct packet_type ip_packet_type = 
    .type = __constant_htons(ETH_P_IP),
    .func = ip_rcv,
;

void __init ip_init(void) 
    dev_add_pack(&ip_packet_type);


// net\\core\\dev.c
void dev_add_pack(struct packet_type *pt) 
    if (pt->type == htons(ETH_P_ALL)) 
        list_add_rcu(&pt->list, &ptype_all);
     else 
        hash = ntohs(pt->type) & 15;
        list_add_rcu(&pt->list, &ptype_base[hash]);
    

我们看到，func 被赋值为了 ip_rcv，那上一步自然就执行到了这个函数，其实就是网络层交给谁来负责解析的意思。

那我们顺便把传输层的协议注册也看了吧，不难想到，ip_rcv 这个函数处理完必然交给传输层继续处理。

module_init(inet_init);

static struct inet_protocol tcp_protocol = 
    .handler =  tcp_v4_rcv,
    .err_handler =  tcp_v4_err,
    .no_policy =    1,
;

static struct inet_protocol udp_protocol = 
    .handler =  udp_rcv,
    .err_handler =  udp_err,
    .no_policy =    1,
;

static int __init inet_init(void) 
    inet_add_protocol(&udp_protocol, IPPROTO_UDP);
    inet_add_protocol(&tcp_protocol, IPPROTO_TCP);
    ip_init();
    tcp_init();

非常直观明了，记住上面两个 handler 分别是 tcp_v4_rcv 和 udp_rcv。

我们回过头，继续看 ip_rcv 这个函数里面。

网络层处理函数 ip_rcv 干了什么

// net\\ipv4\\ip_input.c
int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt) 
    ...
    return NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, dev, NULL,
               ip_rcv_finish);


static inline int ip_rcv_finish(struct sk_buff *skb) 
    ...
    if (skb->dst == NULL) 
        if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
            goto drop; 
    
    ...
    return dst_input(skb);


// include\\net\\dst.h
// rth->u.dst.input= ip_local_deliver;
static inline int dst_input(struct sk_buff *skb) 
    ...
    skb->dst->input(skb);
    ...


// net\\ipv4\\ip_input.c
int ip_local_deliver(struct sk_buff *skb) 
    ...
    return NF_HOOK(PF_INET, NF_IP_LOCAL_IN, skb, skb->dev, NULL,
               ip_local_deliver_finish);


static inline int ip_local_deliver_finish(struct sk_buff *skb) 
    ...
    ipprot = inet_protos[hash];
    ipprot->handler(skb);
    ...

OK，大功告成！最后执行了这个 handler，还记得上一节协议栈中注册的吧？

static struct inet_protocol tcp_protocol = 
    .handler =  tcp_v4_rcv,
    .err_handler =  tcp_v4_err,
    .no_policy =    1,
;

static struct inet_protocol udp_protocol = 
    .handler =  udp_rcv,
    .err_handler =  udp_err,
    .no_policy =    1,
;

由于网络层解析到的传输层协议是 tcp，所以 handler 就指向了处理 tcp 协议的函数，tcp_v4_rcv！

再往后就是 tcp 协议的处理流程，解析出来的数据，由应用程序去接受和处理，就是我们的 socket bind listen read 的流程了。这块又是一片新天地，我还没有研究，就写到这吧！

不过对于 TCP 的原理，可以读这篇文章形象地了解下，《你管这破玩意叫 TCP》。

最后来一张图帮忙理解今天讲的内核收包全过程。

你看，我们常说协议栈不断去掉头部，交给上层协议栈处理，这句话在代码层面其实就是网络层协议解析的方法 ip_rcv 里的末尾调用了传输层协议解析的方法 tcp_v4_rcv，仅此而已。

而说 Linux 处理中断是分上半部和下半部的方案，代码层面就是硬中断处理函数的代码里，直接发起一个软中断，然后便返回，仅此而已。

好啦，大家好好学习！不要再想为什么不 ban 猛犸这个问题了。