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

Posted 码农翻身

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了图解 | 当内核收到了一个网络包相关的知识,希望对你有一定的参考价值。

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

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

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

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

从网线到网卡

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

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

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

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

最开始就是我们常见的网线插口,之后会经过信号转换的模块 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 猛犸这个问题了。

以上是关于图解 | 当内核收到了一个网络包的主要内容,如果未能解决你的问题,请参考以下文章

Linux网络 - 数据包在内核中接收和发送的过程(转)

趣谈协议基础篇:图解Linux网络包接收过程

网络 IO 模型简单介绍

TCP / IP协议 --- 用户层面

Linux网络协议:当eBPF遇上Linux内核网络 | Linux内核之旅

Linux网络包接收过程的监控与调优