《云原生网络数据面可观测性最佳实践》—— 一、容器网络内核原理——3.tc子系统(上)

简介: 《云原生网络数据面可观测性最佳实践》—— 一、容器网络内核原理——3.tc子系统(上)

Linux Traffic Control (TC) 子系统是Linux操作系统中用于对从网络设备驱动进出的流量进行分配,整形,调度以及其他修改操作的子系统,借助对数据包比较直接的处理,可以实现流量控制,过滤,行为模拟和带宽限制等功能。

 

1) Linux Traffic Control的核心原理

对于网络数据报文,网络设备驱动通过将二层的以太网数据报文按照Linux内核定义的网络设备驱动规范,以sk_buff结构体的方式进行接收或者发送,即通常我们所描述的报文的最小单元skb。

 

内核通过将网络设备缓冲区环形队列中skb取出,并按照以太网层,网络层,传输层顺序处理后,将报文数据放置到对应Socket缓冲区中,通知用户程序进行读取,从而完成收包

内核为Socket缓冲区待发送数据封装为skb,经过传输层,网络层和以太网层依次填充对应报头后,调用网络设备驱动方法将skb发送到网络上,从而完成发包

 

TC子系统通过工作在网络设备驱动操作和内核真正进行每一层的收包与发包动作之间,按照不同的模式对数据包进行处理,实现复杂的功能。

 

TC子系统比较常见的作用是对需要发送的数据包进行操作,由于作为收包一侧的Linux内核,无法控制所有发送方的行为,因此TC子系统主要的功能实现都是围绕着发送方向,以下介绍也都是基于发送方向的TC子系统进行。

TC子系统的关键概念

TC子系统与netfilter框架工作在内核网络数据处理流程的不同位置,相比于netfilter,TC子系统工作的实际更加靠近网络设备,因此,在TC子系统的设计中,是与网络设备密不可分,在TC子系统中,有三个关键的概念用于对TC子系统的工作流程进行描述:

 

Qdisc是queueing discipline简写,与我们理解网卡队列(queue)不同,qdisc是sk_buff报文进行排队等待处理队列,不同类型qdisc有着不同排队规则,TC子系统会为每个网卡默认创建一个根队列,在跟队列基础上,可以通过Class来创建不同子队列,用于对流量进行分类处理

Class,如下图所示,class将流量进行分类,不同分类流量会进入不同qdisc进行处理

Filter,如下图所示,filter通过指定匹配规则来实现将流量进行分类作用,filter与class配合之后就可以将流量按照特征,采用不同qdisc进行处理

 image.png

 

不同的qdisc之间的主要差别就是他们对排队的数据包进行调度的算法的区别,你可以通过一下命令查看网卡的qdisc信息:

# 查看eth0的class为2的流量的默认qdisc,其中handle指代qdisc id, parent指代class id
tc qdisc show dev eth0 handle 0 parent 2

常见的qdisc包含以下几种:

 

mq(Multi Queue),即默认有多个qdisc

fq_codel(Fair Queuing Controlled Delay),一种公平和随机分配流量带宽算法,会根据数据包大小,五元组等信息,尽量公平得分配不同流之间带宽

pfifo_fast,一种不分类常见先进先出队列,但是默认有三个不同band,可以支持简单tos优先级

netem,network emulator队列,常见依赖TC子系统进行延迟,乱序和丢包模拟,都是通过netem来实现

clsact,这是TC子系统专门为了支持eBPF功能而提供一种qdisc队列,在通过class分配到这个qdisc之后,流量会触发已经挂载到TC子系统上对应eBPF程序处理流程

htb,一种通过令牌桶算法对流量进行带宽控制常用qdisc,用于在单个往卡上对不同用户,场景流量进行独立带宽限流

报文在TC子系统的处理

在egress方向,当以太网层完成数据报文skb的报头封装后,一个skb就可以直接调用网卡的方法进行发送了,而在Linux内核中,当以太网层完成封装并调用__dev_queue_xmit时,会将skb放入他所在网络设备的TC队列中:

static inline int c(struct sk_buff *skb, struct Qdisc *q,
         struct net_device *dev,
         struct netdev_queue *txq)
{
  if (q->flags & TCQ_F_NOLOCK) {
    if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
      __qdisc_drop(skb, &to_free);
      rc = NET_XMIT_DROP;
    } else {
            // 对于大多数数据包,都会从这里进入qdisc进行排队
      rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
      qdisc_run(q);
    }
    if (unlikely(to_free))
      kfree_skb_list(to_free);
    return rc;
  }
}

在入队动作发生后,内核一般都会直接进行一次qdisc的发包操作,将队列进行排序并按照规则发送符合条件的数据包:

void __qdisc_run(struct Qdisc *q)
{
  int quota = dev_tx_weight;
  int packets;
  // 每次restart都会发送数据包,直到发送完成,这并不意味着所有数据都发送完了,只是这次发送完成了
  while (qdisc_restart(q, &packets)) {
    quota -= packets;
    if (quota <= 0 || need_resched()) {
      __netif_schedule(q);
      break;
    }
  }
}

qdisc每次被触发执行,都会将已经进入qdisc的数据进行入队操作,同时选择符合发送条件的数据包进行出队动作,也就是调用网卡的操作方法进行数据的发送,以pfifo_fast为例:

static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc *qdisc)
{
    // 检测 Qdisc 队列数据包数量是否达到 dev 预定的最大值
    if (skb_queue_len(&qdisc->q) < qdisc_dev(qdisc)->tx_queue_len) {
        // 确定数据包需要进入哪个通道
        int band = prio2band[skb->priority & TC_PRIO_MAX];
        struct pfifo_fast_priv *priv = qdisc_priv(qdisc);
        // 获取通道列表的head
        struct sk_buff_head *list = band2list(priv, band);
        priv->bitmap |= (1 << band);
        qdisc->q.qlen++;
        // 添加到通道队尾
        return __qdisc_enqueue_tail(skb, qdisc, list);
    }
    return qdisc_drop(skb, qdisc);
}
static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc)
{
    struct pfifo_fast_priv *priv = qdisc_priv(qdisc);
    int band = bitmap2band[priv->bitmap];
    if (likely(band >= 0)) {
        struct sk_buff_head *list = band2list(priv, band);
        struct sk_buff *skb = __qdisc_dequeue_head(qdisc, list);
        qdisc->q.qlen--;
        if (skb_queue_empty(list))
            priv->bitmap &= ~(1 << band);
        return skb;
    }
    return NULL;
}

 qdisc流量控制由于设计非常复杂,所以很难简单概括其特性,通常在排查网络问题的过程中,我们需要了解的就是常见的qdisc的算法的大致工作原理,以及查看qdisc统计信息。

 

更多精彩内容,欢迎观看:

《云原生网络数据面可观测性最佳实践》—— 一、容器网络内核原理——3.tc子系统(下):https://developer.aliyun.com/article/1221713?groupCode=supportservice

相关文章
|
3月前
|
监控 Cloud Native 安全
浅谈云原生可观测性
【1月更文挑战第23天】
|
3月前
|
缓存 监控 网络性能优化
从内核的视角观测容器——SysOM 容器监控
从内核的视角观测容器——SysOM 容器监控
|
4月前
|
Kubernetes 安全 Cloud Native
云原生|kubernetes|pod或容器的安全上下文配置解析
云原生|kubernetes|pod或容器的安全上下文配置解析
110 0
|
3月前
|
Kubernetes Cloud Native 调度
云原生技术专题 | 云原生容器编排问题盘点,总结分享年度使用Kubernetes的坑和陷阱
随着云原生的兴起,越来越多的应用选择基于Kubernetes进行部署,可以说Kubernetes 是最流行的容器编排和部署平台。它的强大功能特性,可以保障在生产中可靠地运行容器化应用程序,相关的DevOps等工具也应运而生,下面就是小编简单化了一个Kubernetes的逻辑架构图。
325 9
云原生技术专题 | 云原生容器编排问题盘点,总结分享年度使用Kubernetes的坑和陷阱
|
4月前
|
存储 监控 数据安全/隐私保护
Docker网络模式:深度理解与容器网络配置
Docker 的网络模式是容器化应用中一个关键而复杂的方面。本文将深入讨论 Docker 的网络模式,包括基本概念、常用网络模式以及高级网络配置,并通过更为丰富和实际的示例代码,帮助读者全面掌握如何理解和配置容器网络。
|
27天前
|
移动开发 安全 小程序
mpaas常见问题之小程序容器,跑起来后一直提示 "网络不给力, 请稍后再试"如何解决
mPaaS(移动平台即服务,Mobile Platform as a Service)是阿里巴巴集团提供的一套移动开发解决方案,它包含了一系列移动开发、测试、监控和运营的工具和服务。以下是mPaaS常见问题的汇总,旨在帮助开发者和企业用户解决在使用mPaaS产品过程中遇到的各种挑战
19 0
|
2月前
|
Kubernetes 监控 Cloud Native
阿里云云原生容器高级工程师认证(ACP级-Alibaba Cloud Certification Professional)考试大纲
介绍阿里云云原生容器高级工程师认证(ACP级-Alibaba Cloud Certification Professional)所需具备的知识及学习方法等。
171 2
|
3月前
|
Kubernetes Cloud Native 安全
云原生技术专题 | 云原生架构未来发展趋势,探索容器技术未来的发展趋势
云原生架构指的是基于云原生技术的一套架构原则和设计模式,目的是最大限度地去除云应用中的非业务代码部分。这样,云设施可以接管应用中大量原有的非功能性特性(如弹性、韧性、安全性、可观察性、灰度等),使非功能性业务中断不再成为难题,为业务提供轻量化、敏捷、高度自动化的优势。
561 6
云原生技术专题 | 云原生架构未来发展趋势,探索容器技术未来的发展趋势
|
3月前
|
网络协议 Unix Linux
docker网络模式详解及容器间网络通信
docker网络模式详解及容器间网络通信
139 0
|
4月前
|
运维 Cloud Native Linux
【云原生|Docker系列第4篇】Docker的容器的入门实践
【云原生|Docker系列第4篇】Docker的容器的入门实践

热门文章

最新文章