这里深度理解一下在Linux下网络包的接收过程,为了简单起见,我们用udp来举例,如下:
因为要对百万、千万、甚至是过亿的用户提供各种网络服务,所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发,要理解性能开销,会进行性能优化。而很多时候,如果你对Linux底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务,所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发,要理解性能开销,会进行性能优化。而很多时候,如果你对网络底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。
现在 iptables 这个工具的应用似乎是越来越广了。不仅仅是在传统的防火墙、NAT 等功能出现,在今天流行的的 Docker、Kubernets、Istio 项目中也经常能见着对它的身影。正因为如此,所以深入理解 iptables 工作原理是非常有价值的事情。
在《网络中断下半部处理》一文中介绍过,当网卡接收到网络数据包后,会由网卡驱动通过调用 netif_rx 函数把数据包添加到待处理队列中,然后唤起网络中断下半部处理。
大家好,我是杨玉玺,2011年至今一直从事底层网络研发,先后就职于阿里云、金山云从事 VPC 虚拟化网络研发,对高性能网络优化,复杂网络问题排查有非常丰富的经验。目前就职腾讯云 TKE 团队,专注 K8S 底层网络。
本文作者 / yogazhao 爱自然科学,赞叹于大师级码农高超的艺术境界;爱生命科学,诚服于古圣先贤的天地气象。 可能大多数瓜农都对《艺伎回忆录》比较熟悉,作为一个IT界的码农,当然也有自己类似的经历,该文分为上篇和下篇,此篇为《OVS BUG撸码回忆录•上篇》 回忆录缘起 以前为排查ovs的某个bug,无奈撸了把相关内核流程。当时因为调用链太多,脑袋栈溢出,处理不过来,所以临时用txt比较零散的记录了下关键点,做完了就丢了。后面想起来,无奈用everything找了好久才找到, 再读之,发现忘了很
本文主要讲述了借助 ebpf 工具 skbtracer 分析了容器网桥模式下出现 dup 包问题的根本原因, skbtracer 工具的使用使得原本比较复杂的分析过程变得非常高效且流程化。目前,skbtracer 工具正在不断打磨发展,后续会越来越傻瓜化智能化,希望能够借本次分享推广此分析方法及思路,让更多的人了解、使用 skbtracer 工具。
在《Netfilter & iptables 原理》一文中,我们介绍了 Netfilter 和 iptables 的原理,而本文主要通过源码分析来介绍一下 Netfilter 与 iptables 的实现过程。
导言|nettrace工具自上线以来,受到了业界的广泛关注。特别是复杂的云原生网络环境中,nettrace 工具通过报文跟踪、网络诊断的方式为用户解决了多次疑难网络问题。今天就以OpenCloudOS为例,介绍在云原生场景中nettrace如何快速进行网络故障诊断。 工具简介 1)背景 在一些场景下(特别是云原生场景),Linux 系统中的网络部署变得越来越复杂。一个 TCP 连接,从客户端到服务端,中间可能要经过复杂的 NAT、GRE、IPVS 等过程,网络报文在节点(主机)上的处理路径也变得越来越长
在一些场景下(特别是云原生场景),Linux 系统中的网络部署变得越来越复杂。一个 TCP 连接,从客户端到服务端,中间可能要经过复杂的 NAT、GRE、IPVS 等过程,网络报文在节点(主机)上的处理路径也变得越来越长。在发生网络故障(比如网络丢包)时,如何快速、有效地定位出网络问题成为了一个难题。目前常规的网络故障定位手段,如 tcpdump、dropwatch、ftrace、kprobe 等存在一定的短板:
IP协议 是网络的最重要部分,毫不夸张地说,正是因为有 IP协议 才有了互联网。而 IP协议 最重要的是 IP地址,IP地址 就好像我们的家庭住址一样,用于其他人方便找到我们的位置。
在开源 Linux 操作系统 OpenCloudOS 8.6 中,增加了内核对网络工具 nettrace 的支持,允许开发者通过 bpf 进行网络丢包原因跟踪,内核也同时回合相关的丢包跟踪点。今天,就以 nettrace 为典型,介绍如何在 OpenCloudOS 中利用 nettrace 进行网络故障诊断。 一、工具简介 1. 背景 在一些场景下(特别是云原生场景),Linux 系统中的网络部署变得越来越复杂。一个 TCP 连接,从客户端到服务端,中间可能要经过复杂的 NAT、GRE、IPVS 等过程,网
Ftrace设计作为一个内部的tracer提供给系统的开发者和设计者,帮助他们弄清kernel正在发生的行为,它能够调式分析延迟和性能问题。对于前一章节,我们学习了Ftrace发展到现在已经不仅仅是作为一个function tracer了,它实际上成为了一个通用的trace工具的框架
前言:IPIP隧道是一种三层隧道,通过把原来的IP包封装在新的IP包里面,来创建隧道传输。本篇简单分析Linux(2.6.32版本)中的IPIP隧道的实现过程,期望有所借鉴,造出轮子:-)
本文将介绍在Linux系统中,以一个UDP包的接收过程作为示例,介绍数据包是如何一步一步从网卡传到进程手中的。
转载链接1:http://www.arrowapex.cn/archives/66.html
最近使用tcpdump的时候突然想到这个问题。因为我之前只存在一些一知半解的认识:比如直接镜像了网卡的包、在数据包进入内核前就获取了。但这些认识真的正确么?针对这个问题,我进行了一番学习探究。
在网络包的发送和接收过程中,绝大部分的工作都是在内核态完成的。那么问题来了,我们常用的运行在用户态的程序 tcpdump 是那如何实现抓到内核态的包的呢?有的同学知道 tcpdump 是基于 libpcap 的,那么 libpcap 的工作原理又是啥样的呢。如果让你裸写一个抓包程序,你有没有思路?
Netfilter (配合 iptables)使得用户空间应用程序可以注册内核网络栈在处理数据包时应用的处理规则,实现高效的网络转发和过滤。很多常见的主机防火墙程序以及 Kubernetes 的 Service 转发都是通过 iptables 来实现的。
关于 netfilter 的介绍文章大部分只描述了抽象的概念,实际上其内核代码的基本实现不算复杂,本文主要参考 Linux 内核 2.6 版本代码(早期版本较为简单),与最新的 5.x 版本在实现上可能有较大差异,但基本设计变化不大,不影响理解其原理。
本文翻译自 2019 年 DigitalOcean 的工程师 Nate Sweet 在 KubeCon 的一篇分享: Understanding (and Troubleshooting) the eBPF Datapath in Cilium[1] 。
因为epoll没有论文,就说说kqueue是怎么做的吧,kqueue会根据socket绑定的knote链表(每个监听的kqueue都可能创建一个knote),将knote通过反向指针获得kqueue,将knote加入kqueue的就绪队列末尾。如果此时恰好有进程正在监听的话,将会唤醒进程,kqueue会被扫描,并从就绪队列处获得所有的event,从而了解已经就绪的所有socket。
在 上一篇文章 中,我们介绍了网卡接收和发过数据在 Linux 内核中的处理过程,我们先来回顾一下网卡接收和发送数据的过程,如 图1 所示:
本文翻译自 2019 年 DigitalOcean 的工程师 Nate Sweet 在 KubeCon 的一篇分享:
上篇讲到mac头通过mac头的协议字段决定把数据包分发给上层的哪个协议。这里假设上层协议是ip,ip层处理函数是ip_rcv,代码如下
作为网络领域的开发人员,我们经常要与Linux的数据报文打交道,一定要搞清楚数据报文是从何而来,又是如何离去。以前针对这个主题写过一些文章(主要是从源码角度),这次会更重视流程示意图(在细节上必然有所简化),争取在一篇文章中,就让大家理清数据报文的来龙去脉。
接触过网络开发的人,大抵都知道,上层应用使用send函数发送数据,使用recv来接收数据,而send和recv的实现原理又是怎样的呢?
今天分享一篇经典Linux协议栈文章,主要讲解Linux网络子系统,看完相信大家对协议栈又会加深不少,不光可以了解协议栈处理流程,方便定位问题,还可以学习一下怎么去设计一个可扩展的子系统,屏蔽不同层次的差异。
下面以udp为例看看什么时候会发送destination unreachable包。我们从收到一个udp包开始分析,具体函数是udp_rcv。
接前面这个写起,比较过linux kernel vxlan device和ovs vxlan的性能,很好奇ovs vxlan是怎么实现的,linux kernel vxlan device是用如下命令创建的。
我们可以通过objdump -D看到内核模块或者用户态程序里面的函数开头的指令,以便知道如果想hook它的话,要预先备份多少指令。
封装:当应用程序用 TCP 协议传送数据时,数据首先进入内核网络协议栈中,然后逐一通过 TCP/IP 协议族的每层直到被当作一串比特流送入网络。对于每一层而言,对收到的数据都会封装相应的协议首部信息(有时还会增加尾部信息)。TCP 协议传给 IP 协议的数据单元称作 TCP 报文段,或简称 TCP 段(TCP segment)。IP 传给数据链路层的数据单元称作 IP 数据报(IP datagram),最后通过以太网传输的比特流称作帧(Frame)。
io多路复用有很多种实现,自Linux 2.6内核正式引入epoll以来,epoll已经成为了目前实现高性能网络服务器端的必备技术。相比较select、poll而言,在查询、复制、监听数量上,epoll都有极大优势。
如今服务器虚拟化技术已经发展到了深水区。现在业界已经有很多公司都迁移到容器上了。我们的开发写出来的代码大概率是要运行在容器上的。因此深刻理解容器网络的工作原理非常的重要。只有这样将来遇到问题的时候才知道该如何下手处理。
Below is an example which does exactly what you need: hook received TCP packets and print their payloads. If you want to print some other information from received packet (like binary data), you just need to modify a bit the section under this comment:
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。 大部分高性能网络框架采用的是非阻塞模式。笔者这次就从linux源码的角度来阐述socket阻塞(block)和非阻塞(non_block)的区别。 本文源码均来自采用Linux-2.6.24内核版本。
在数据的发送过程中,从上至下依次是“加头”的过程,每到达一层数据就被会加上该层的头部;与此同时,接受数据方就是个“剥头”的过程,从网卡收上包来之后,在往协议栈的上层传递过程中依次剥去每层的头部,最终到达用户那儿的就是裸数据了。
由于网络协议非常复杂,内核里面用到了大量的面向对象的技巧,所以我们从创建连接开始,一步一步追述到最后代码的调用点。
sk_buff 是一个贯穿整个协议栈层次的结构,在各层间传递时,内核只需要调整 sk_buff 中的指针位置就行。
内核显然需要一个数据结构来表示报文,这个结构就是 sk_buff ( socket buffer 的简称),它等同于在<TCP/IP详解 卷2>中描述的 BSD 内核中的 mbuf。
容器是一种新的虚拟化技术,每一个容器都是一个逻辑上独立的网络环境。Linux 上提供了软件虚拟出来的二层交换机 Bridge 可以解决同一个宿主机上多个容器之间互连的问题,但这是不够的。二层交换无法解决容器和宿主机外部网络的互通。
2. 资源消耗型攻击:攻击者利用协议的缺陷或者模拟应用层协议,构造恶意的攻击报文,这种报文没有作用但是目标服务器又不得不处理,消耗大量系统资源,导致目标服务器异常,影响正常应用。比如SYN Flood,ACK Flood,CC攻击。
就在不久前我也遇到了类似的问题,看似是玄学事件,刚开始归结于网络链路抖动,一段时间后依然存在,虽然影响都是 P99.99 以后的数据,但是扰人心智,最后通过多方面定位,解决了该问题。最后发现跟业务、网络都没有什么关系,而是基础设施自身出了问题,如下文给了一个具体排查方案,并从一定程度上解释了容器、cgroup、CPU 会给网络延迟带来怎样的影响。
通过前面的文章我们已经了解了「数据包从HTTP层->TCP层->IP层->网卡->互联网->目的地服务器」这中间涉及的知识。
本文源码解析参考: 深入理解TCP/IP协议的实现之ip分片重组 – 基于linux1.2.13
领取专属 10元无门槛券
手把手带您无忧上云