现在很多人都在诟病Linux内核协议栈收包效率低,不管他们是真的懂还是一点都不懂只是听别人说的,反正就是在一味地怼Linux内核协议栈,他们的武器貌似只有DPDK。
pktgen是Linux内核里包含的一个高性能发包工具,主要用来测试网络性能。一般情况下,使用pktgen就可以满足千兆网卡的测试需要,不必花钱购买昂贵的硬件发包设备。 pktgen运行在“内核态”,并不占用太多的系统资源,就可以达到非常高的发包速率。 pktgen只支持UDP发包(端口9)。因为pktgen是一个非常底层测试工具,而且一般是测试网络设备的性能,并不涉及到应用层面。 如果要测试高级的网络应用的性能,请使用其它的测试工具。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务,所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发,要理解性能开销,会进行性能优化。而很多时候,如果你对Linux底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。
pktgen是Linux内核里包含的一个高性能发包工具,主要用来测试网络性能。一般情况下,使用pktgen就可以满足千兆网卡的测试需要。 pktgen运行在“内核态”,并不占用太多的系统资源,就可以达到非常高的发包速率。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务,所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发,要理解性能开销,会进行性能优化。而很多时候,如果你对网络底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。
转载链接1:http://www.arrowapex.cn/archives/66.html
今天分享一篇经典Linux协议栈文章,主要讲解Linux网络子系统,看完相信大家对协议栈又会加深不少,不光可以了解协议栈处理流程,方便定位问题,还可以学习一下怎么去设计一个可扩展的子系统,屏蔽不同层次的差异。
我们可以使用BPF对Linux内核进行跟踪,收集我们想要的内核数据,从而对Linux中的程序进行分析和调试。与其它的跟踪技术相比,使用BPF的主要优点是几乎可以访问Linux内核和应用程序的任何信息,同时,BPF对系统性能影响很小,执行效率很高,而且开发人员不需要因为收集数据而修改程序。
作者:Hcamael@知道创宇 404 实验室 时间:2019 年 6 月 26 日 英文版本:https://paper.seebug.org/967/
上周Linux内核修复了4个CVE漏洞[1],其中的CVE-2019-11477感觉是一个很厉害的Dos漏洞,不过因为有其他事打断,所以进展的速度比较慢,这期间网上已经有相关的分析文章了。[2][3]
这里深度理解一下在Linux下网络包的接收过程,为了简单起见,我们用udp来举例,如下:
伯克利数据包过滤器(BPF)机制自2014年被重写和扩展(eBPF)以来,一直在各种内核子系统中发挥作用。事实证明,通过在内核虚拟机,允许在不编写内核自身代码的情况下实现任意策略的方式,存在着巨大的价值。最近一个将BPF推向网络驱动程序的补丁集显示了这种机制的一些潜力—以及集成一种经得起时间考验的方式的设计难度。如果成功的话,它可能会改变Linux系统上的实现高性能网络方式。
BPF (Berkeley Packet Filter) 最早是用在 tcpdump 里面的,比如 tcpdump tcp and dst port 80 这样的过滤规则会单独复制 tcp 协议并且目的端口是 80 的包到用户态。整个实现是基于内核中的一个虚拟机来实现的,通过翻译 BPF 规则到字节码运行到内核中的虚拟机当中。最早的论文是这篇,这篇论文我大概翻了一下,主要讲的是原本的基于栈的过滤太重了,而 BPF 是一套能充分利用 CPU 寄存器,动态注册 filter 的虚拟机实现,相对于基于内存的实现更高效,不过那个时候的内存比较小才几十兆。bpf 会从链路层复制 pakcet 并根据 filter 的规则选择抛弃或者复制,字节码是这样的,具体语法就不介绍了,一般也不会去直接写这些字节码,然后通过内核中实现的一个虚拟机翻译这些字节码,注册过滤规则,这样不修改内核的虚拟机也能实现很多功能。
作者 linxinsnow 应用场景 我们在进行安全性监控、测试的过程中,难免会遇到这样的问题:需要部署大量基于镜像流量的安全设备,如IPS,异常流量,数据库审计,流量分析等,可是交换机上可以做镜像流
本文介绍了如何编写一个简单的驱动程序,该驱动程序可以控制硬件设备。首先介绍了驱动程序的基本结构和组成,包括驱动程序、设备、设备文件、操作系统和硬件之间的交互。然后详细讲解了驱动程序的开发过程,包括设备树、设备驱动、设备驱动的加载和运行,以及如何使用驱动程序开发工具编写驱动程序。最后,介绍了驱动程序在实际开发中的应用,包括驱动程序开发中的常见问题和解决方法,以及如何在生产环境中部署驱动程序。通过本文的学习,可以加深对驱动程序的理解,掌握驱动程序开发的基本技能,为后续的驱动程序开发工作打下坚实的基础。","summary_detail":[{"title":"本文介绍了如何编写一个简单的驱动程序,该驱动程序可以控制硬件设备。","summary":"本文介绍了如何编写一个简单的驱动程序,该驱动程序可以控制硬件设备。首先介绍了驱动程序的基本结构和组成,包括驱动程序、设备、设备文件、操作系统和硬件之间的交互。然后详细讲解了驱动程序的开发过程,包括设备树、设备驱动、设备驱动的加载和运行,以及如何使用驱动程序开发工具编写驱动程序。最后,介绍了驱动程序在实际开发中的应用,包括驱动程序开发中的常见问题和解决方法,以及如何在生产环境中部署驱动程序。通过本文的学习,可以加深对驱动程序的理解,掌握驱动程序开发的基本技能,为后续的驱动程序开发工作打下坚实的基础。
Linux 具有功能丰富的网络协议栈,并且兼顾了非常优秀的性能。但是,这是相对的。单纯从网络协议栈各个子系统的角度来说,确实做到了功能与性能的平衡。不过,当把多个子系统组合起来,去满足实际的业务需求,功能与性能的天平就会倾斜。
我其实并不想讨论微内核的概念,也并不擅长去阐述概念,这是百科全书的事,但无奈最近由于鸿蒙的发布导致这个话题过火,也就经不住诱惑,加上我又一直比较喜欢操作系统这个话题,就来个老生常谈吧。
原文链接:https://blog.csdn.net/dog250/article/details/46666029
忽然想起的回忆,那是2007上周五在冬季,我看我的老湿调试Linux堆IP层,只看到他改变路由查找的逻辑,然后直接make install上的立竿见影的效果有点,我只知道,,这种逻辑必须再次更改编译内核。再一次,他没有编译,就像刚才编译的文件…时又无聊的工作阻碍了我对Linux内核的探索进度,直到今天,我依旧对编译内核有相当的恐惧,不怕出错,而是怕磁盘空间不够,initrd的组装拆解之类,太繁琐了。我之所以知道2007年的那天是周五,是由于第二天我要加班。没有谁逼我。我自愿的,由于我想知道师父是怎么做到不又一次编译内核就能改变非模块的内核代码处理逻辑的。第二天的收获非常多,不但知道了他使用了“镜像协议栈”。还额外赚了一天的加班费。我还记得周六加完班我和老婆去吃了一家叫做石工坊的羊排火锅。人家赠送了一仅仅绿色的兔子玩偶。
传统数据中心中硬件服务器上运行linux,linux用硬件网卡收发包,硬件网卡有broadcom的有mellanox的有intel的等各式各样的,硬件网卡连接到硬件交换机上,硬件交换机有H3C的有cisco的,交换机进行包转发实现服务器之间互通。在云计算环境下,对计算资源进行了切分,服务器上运行的是一个个虚拟机,虚拟机也要有网卡实现互连互通,但虚拟机的网卡不是物理的,是虚拟的网卡,虚拟的网卡连接到虚拟的交换机上,虚拟的交换机对同一个服务器上的虚拟机之间流量进行转发,如果虚拟交换机再连接到服务器的硬件网卡,那么虚拟机就可以和服务器外面通信了。
今天看到有人发了CVE-2017-1000112-UFO的分析,就把之前的学习报告整理一下,做个对比学习。 别人的分析报告: https://securingtomorrow.mcafee.com/mcafee-labs/linux-kernel-vulnerability-can-lead-to-privilege-escalation-analyzing-cve-2017-1000112/
1. NSH-SFC概述 当前SFC的实现方案主要分为两种:一种基于NSH(network service header)。数据封装时,在L2或者L3数据后添加NSH头,然后进行L3或L4的封装。转发时,根据nshheader去转发SFC中的数据,整个过程都是依据同一个SPI(service path id)和递减的SI(service index);另一种无NSH头,在转发过程中,SFF需要不停对新来的数据包进行判断,确定是否属于某个SFC。ODL的子项目SFC就是第一种的实现。 1.1 NSH-SFC组
本文作者 / yogazhao 爱自然科学,赞叹于大师级码农高超的艺术境界;爱生命科学,诚服于古圣先贤的天地气象。 可能大多数瓜农都对《艺伎回忆录》比较熟悉,作为一个IT界的码农,当然也有自己类似的经历,该文分为上篇和下篇,此篇为《OVS BUG撸码回忆录•上篇》 回忆录缘起 以前为排查ovs的某个bug,无奈撸了把相关内核流程。当时因为调用链太多,脑袋栈溢出,处理不过来,所以临时用txt比较零散的记录了下关键点,做完了就丢了。后面想起来,无奈用everything找了好久才找到, 再读之,发现忘了很
在评估漏洞影响时,人们关注的往往是漏洞风险,而实际上,漏洞潜伏的时间也是一个非常重要的因素。时间跨度大,也就意味着在此期间使用这些含有漏洞的软件的设备更多,影响的设备就更多;而时间跨度长,也就意味着被
本文分享嵌入式Linux系统使用的操作手册,其中详细内容,主要涵盖了:LinuxSDK安装、Linux系统镜像编译/生成、Linux系统文件替换说明、U-Boot命令说明和环境说明、内存分配说明、Linux设备驱动说明、主频调节说明、文件系统使用说明等,感兴趣的嵌入式工程师朋友可以查阅。
Linux内核网络 UDP 协议层通过调用 ip_send_skb 将 skb 交给 IP 协议层,本文通过分析内核 IP 协议层的关键函数来分享内核数据包发送在 IP 协议层的处理,并分享了监控IP层的方法。
我在公众号菜单里面新加一个“看图写话”的入口。内容么,顾名思义,就是看着图聊聊。控制字数真的很难,我尽量。
许庆伟:龙蜥社区eBPF技术探索SIG组 Maintainer & Linux Kernel Security Researcher
0.前言 为提升信鸽基础服务质量,笔者就网络收包全流程进行了内容整理。 网络编程中我们接触得比较多的是socket api和epoll模型,对于系统内核和网卡驱动接触得比较少,一方面可能我们的系统没有需要深度调优的需求,另一方面网络编程涉及到硬件,驱动,内核,虚拟化等复杂的知识,使人望而却步。网络上网卡收包相关的资料也比较多,但是比较分散,在此梳理了网卡收包的流程,分享给大家,希望对大家有帮助,文中引用了一些同事的图表和摘选了网上资料,在文章最后给出了参考文献与部分来源,感谢这些作者的分享。 1.整体流程
最近要给团队做一个长期的内部分享,主题就是Linux内核中数据包的处理流程。
本文列举四个比较经典的 Linux 收包引擎,如果还有其他你觉得ok的可以留言。这四个分别是:
Linux内核主要由 进程管理、内存管理、设备驱动、文件系统、网络协议栈 外加一个 系统调用。
现在 iptables 这个工具的应用似乎是越来越广了。不仅仅是在传统的防火墙、NAT 等功能出现,在今天流行的的 Docker、Kubernets、Istio 项目中也经常能见着对它的身影。正因为如此,所以深入理解 iptables 工作原理是非常有价值的事情。
本文翻译自 KubeCon+CloudNativeCon Europe 2022 的一篇分享:Better Bandwidth Management with eBPF。
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/117744.html原文链接:https://javaforall.cn
在数据的发送过程中,从上至下依次是“加头”的过程,每到达一层数据就被会加上该层的头部;与此同时,接受数据方就是个“剥头”的过程,从网卡收上包来之后,在往协议栈的上层传递过程中依次剥去每层的头部,最终到达用户那儿的就是裸数据了。
作为网络领域的开发人员,我们经常要与Linux的数据报文打交道,一定要搞清楚数据报文是从何而来,又是如何离去。以前针对这个主题写过一些文章(主要是从源码角度),这次会更重视流程示意图(在细节上必然有所简化),争取在一篇文章中,就让大家理清数据报文的来龙去脉。
用户态进程通过write()系统调用切到内核态将用户进程缓冲区中的HTTP报文数据通过Tcp Process处理程序为HTTP报文添加TcpHeader,并进行CPU copy写入套接字发送缓冲区,每个套接字会分别对应一个Send-Q(发送缓冲区队列)、Recv-Q(接收缓冲区队列),可以通过ss -nt语句获取当前的套接字缓冲区的状态;
IP层叫分片,TCP/UDP层叫分段。网卡能做的事(TCP/UDP组包校验和分段,IP添加包头校验与分片)尽量往网卡做,网卡不能做的也尽量迟后分片(发送)或提前合并片(接收)来减少在网络栈中传输和处理的包数目,从而减少数据传输和上下文切换所需要的CPU计算时间。
TCP有限状态机 TCP服务 创建TCP服务的四个基本步骤: socket – 创建socket套接字。 bind – 绑定要监听的IP地址。 listen – 开始监听客户端连接请求。 accept
接前面这个写起,比较过linux kernel vxlan device和ovs vxlan的性能,很好奇ovs vxlan是怎么实现的,linux kernel vxlan device是用如下命令创建的。
本文翻译自 2019 年 DigitalOcean 的工程师 Nate Sweet 在 KubeCon 的一篇分享:
前言: ICMP比较基础,说简单不简单,说难不难。 简单在于字段少,不能携带用户数据,没什么地方可以玩出太多花样;一般和它相关的就是ping和traceroute程序。 难在于它并不是工作在用户态,向基于TCP/UDP的echo服务一样,listen一个port,收到数据就存到buffer,再一模一样的返回数据。它到底怎样工作的呢?怎样能清晰的描述出来呢? 分析: 代码:linux-4.0.4/net/ipv4/icmp.c 1,在分析icmp之前,先分析一下:linux-4.0.4/net/ipv4/af
Linux内核对网络驱动程序使用统一的接口,并且对于网络设备采用面向对象的思想设计。
在网络包的发送和接收过程中,绝大部分的工作都是在内核态完成的。那么问题来了,我们常用的运行在用户态的程序 tcpdump 是那如何实现抓到内核态的包的呢?有的同学知道 tcpdump 是基于 libpcap 的,那么 libpcap 的工作原理又是啥样的呢。如果让你裸写一个抓包程序,你有没有思路?
云网络发展早期,很多厂商的虚拟化网路方案基于内核模块来实现,这时的带宽通常从千兆到万兆,一般情况下还能够满足要求(SDWAN厂商华夏创新的网络加速就是在内核的PREROUTING上做的,性能还可以)。再后来,进入到25G时代了,基于内核的一些实现已经不能满足业务对网络吞吐的性能要求了,大约在2013~2018左右,很多厂商转向用DPDK实现,着实火了一段时间。到现在逐渐进入100G时代,会发现,无论大厂小厂,都逐渐开始转向智能网卡,网络特性offload到硬件,基本是当前和今后一段时间的主流。
领取专属 10元无门槛券
手把手带您无忧上云