Linux下使用虚拟网卡的ingress流控(入口流控)

kylinos 2013-12-09

Linux内核实现了数据包的队列机制,配合多种不同的排队策略,可以实现完美的流量控制和流量整形(以下统称流控)。流控可以在两个地方实现,分别为egress和ingress,egress是在数据包发出前的动作触发点,而ingress是在数据包接收后的动作触发点。Linux的流控在这两个位置实现的并不对称,即Linux并没有在ingress这个位置实现队列机制。那么在ingress上就几乎不能实现流控了。

虽然使用iptables也能模拟流控,但是如果你就是想用真正的队列实现流控的话,还真要想想办法。也许,就像电子邮件的核心思想一样,你总是能完美控制发送,却对接收毫无控制力,如果吸收了这个思想,就可以理解ingress队列流控的难度了,然而,仅仅是也许而已。

Linux在ingress位置使用非队列机制实现了一个简单的流控。姑且不谈非队列机制相比队列机制的弊端,仅就ingress的位置就能说明我们对它的控制力几乎为0。ingress处在数据进入IP层之前,此处不能挂接任何IP层的钩子,Netfilter的PREROUTING也在此之后,因此在这个位置,你无法自定义任何钩子,甚至连IPMARK也看不到,更别提关联socket了,因此你就很难去做排队策略,你几乎只能看到IP地址和端口信息。

一个现实的ingress流控的需求就是针对本地服务的客户端数据上传控制,比如上传大文件到服务器。一方面可以在底层释放CPU压力,提前丢掉CPU处理能力以外的数据,另一方面,可以让用户态服务的IO更加平滑或者更加不平滑,取决于策略。

既然有需求,就要想法子满足需求。目前我们知道的是,只能在egress做流控,但是又不能让数据真的outgoing,另外,我们需要可以做很多策略,这些策略远不是仅由IP,协议,端口这5元组可以给出。那么一个显而易见的方案就是用虚拟网卡来完成,图示如下:

Linux下使用虚拟网卡的ingress流控(入口流控)

以上的原理图很简单,但是实施起来还真有几个细节。其中最关键是路由的细节,我们知道,即使是策略路由,也必须无条件从local表开始查找,在目标地址是本机情况下,如果希望数据按照以上流程走的话,就必须将该地址从local表删除,然而一旦删除,本机将不再会对该地址回应ARP请求。因此可以用几个方案:

1.使用静态ARP或者使用ebtables更改ARP,或者使用arping主动广播arp配置;

2.使用一个非本机的地址,然后修改虚拟网卡的xmit函数,内部使其DNAT成本机地址,这就绕开了local表的问题。

不考虑细节,仅就上述原理图讨论的话,你可以在常规路径的PREROUTING中做很多事情,比如使用socket match关联socket,也可以使用IPMARK。

下面,我们就可以按照上述图示,实际实现一个能用的。首先先要实现一个虚拟网卡。仿照loopback接口做一个用于流控的虚拟接口,首先创建一个用于ingress流控的虚拟网卡设备

dev = alloc_netdev(0, "ingress_tc", tc_setup);

然后初始化其关键字段

static const struct net_device_ops tc_ops = {
        .ndo_init      = tc_dev_init,
        .ndo_start_xmit= tc_xmit,
};
static void tc_setup(struct net_device *dev)
{
        ether_setup(dev);
        dev->mtu                = (16 * 1024) + 20 + 20 + 12;
        dev->hard_header_len    = ETH_HLEN;    /* 14  */
        dev->addr_len          = ETH_ALEN;    /* 6    */
        dev->tx_queue_len      = 0;
        dev->type              = ARPHRD_LOOPBACK;      /* 0x0001*/
        dev->flags              = IFF_LOOPBACK;
        dev->priv_flags        &= ~IFF_XMIT_DST_RELEASE;
        dev->features          = NETIF_F_SG | NETIF_F_FRAGLIST
                | NETIF_F_TSO
                | NETIF_F_NO_CSUM
                | NETIF_F_HIGHDMA
                | NETIF_F_LLTX
                | NETIF_F_NETNS_LOCAL;
        dev->ethtool_ops        = &tc_ethtool_ops;
        dev->netdev_ops        = &tc_ops;
        dev->destructor        = tc_dev_free;
}

接着构建其xmit函数

static netdev_tx_t tc_xmit(struct sk_buff *skb,
                                struct net_device *dev)
{
    skb_orphan(skb);
    // 直接通过第二层!
    skb->protocol = eth_type_trans(skb, dev);
    skb_reset_network_header(skb);
    skb_reset_transport_header(skb);
    skb->mac_len = skb->network_header - skb->mac_header;
    // 本地接收
    ip_local_deliver(skb);
 
    return NETDEV_TX_OK;
}

接下来考虑如何将数据包导入到该虚拟网卡。有3种方案可选:

方案1:如果不想设置arp相关的东西,就要修改内核了。在此我引入了一个路由标志,RT_F_INGRESS_TC,凡是有该标志的路由,全部将其导入到构建的虚拟网卡中,为了策略化,我并没有在代码中这么写,而是改变了RT_F_INGRESS_TC路由的查找顺序,优先查找策略路由表,然后再查找local表,这样就可以用策略路由将数据包导入到虚拟网卡了。

方案2:构建一个Netfilter HOOK,在其target中将希望流控的数据NF_QUEUE到虚拟网卡,即在queue的handler中设置skb->dev为虚拟网卡,调用dev_queue_xmit(skb)即可,而该虚拟网卡则不再符合上面的图示,新的原理图比较简单,只需要在虚拟网卡的hard_xmit中reinject数据包即可。(事实上,后来我才知道,原来IMQ就是这么实现的,幸亏没有动手去做无用功)

方案3:这是个快速测试方案,也就是我最原始的想法,即将目标IP地址从local表删除,然后手动arping,我的测试也是基于这个方案,效果不错。

不管上面的方案如何变化,终究都是一个效果,那就是既然网卡的ingress不能流控,那就在egress上做,而又不能使用物理网卡,虚拟网卡恰好可以自定义其实现,可以满足任意需求。我们可以看到,虚拟网卡是多么的功能强大,tun,lo,nvi,tc...所有这一切,精妙之处全在各自不同的xmit函数。

相关阅读

相关推荐