《云原生网络数据面可观测性最佳实践》—— 一、容器网络内核原理——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

相关文章
|
10月前
|
XML Java 测试技术
《深入理解Spring》:IoC容器核心原理与实战
Spring IoC通过控制反转与依赖注入实现对象间的解耦,由容器统一管理Bean的生命周期与依赖关系。支持XML、注解和Java配置三种方式,结合作用域、条件化配置与循环依赖处理等机制,提升应用的可维护性与可测试性,是现代Java开发的核心基石。
|
10月前
|
XML Java 应用服务中间件
【SpringBoot(一)】Spring的认知、容器功能讲解与自动装配原理的入门,带你熟悉Springboot中基本的注解使用
SpringBoot专栏开篇第一章,讲述认识SpringBoot、Bean容器功能的讲解、自动装配原理的入门,还有其他常用的Springboot注解!如果想要了解SpringBoot,那么就进来看看吧!
803 2
|
10月前
|
Kubernetes Cloud Native 区块链
Arista cEOS 4.35.0F 发布 - 针对云原生环境设计的容器化网络操作系统
Arista cEOS 4.35.0F 发布 - 针对云原生环境设计的容器化网络操作系统
333 0
|
Cloud Native 中间件 调度
云原生信息提取系统:容器化流程与CI/CD集成实践
本文介绍如何通过工程化手段解决数据提取任务中的稳定性与部署难题。结合 Scrapy、Docker、代理中间件与 CI/CD 工具,构建可自动运行、持续迭代的云原生信息提取系统,实现结构化数据采集与标准化交付。
1429 1
云原生信息提取系统:容器化流程与CI/CD集成实践
|
Docker 容器
Docker网关冲突导致容器启动网络异常解决方案
当执行`docker-compose up`命令时,服务器网络可能因Docker创建新网桥导致IP段冲突而中断。原因是Docker默认的docker0网卡(172.17.0.1/16)与宿主机网络地址段重叠,引发路由异常。解决方法为修改docker0地址段,通过配置`/etc/docker/daemon.json`调整为非冲突段(如192.168.200.1/24),并重启服务。同时,在`docker-compose.yml`中指定网络模式为`bridge`,最后通过检查docker0地址、网络接口列表及测试容器启动验证修复效果。
1966 39
|
存储 缓存 分布式计算
StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
本文将深入探讨基于 StarRocks 和 Iceberg 构建的云原生湖仓分析技术,详细解析两者结合如何实现高效的查询性能优化。内容涵盖 StarRocks Lakehouse 架构、与 Iceberg 的性能协同、最佳实践应用以及未来的发展规划,为您提供全面的技术解读。 作者:杨关锁,北京镜舟科技研发工程师
StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
|
存储 Linux 容器
【Container App】在容器中抓取网络包的方法
本文介绍在Azure Container App中安装tcpdump抓取网络包,并通过Storage Account上传抓包文件的方法。内容包括使用curl和nc测试外部接口连通性、长Ping端口、安装tcpdump、抓取网络包、以及通过crul命令上传文件至Azure Storage。适用于需要分析网络请求和排查网络问题的场景。
355 0
|
Kubernetes Cloud Native 区块链
Arista cEOS 4.30.10M - 针对云原生环境设计的容器化网络操作系统
Arista cEOS 4.30.10M - 针对云原生环境设计的容器化网络操作系统
485 0
|
负载均衡 容灾 Cloud Native
云原生应用网关进阶:阿里云网络ALB Ingress 全面增强
云原生应用网关进阶:阿里云网络ALB Ingress 全面增强
527 6
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
938 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档