现在车内网络都开始内卷到1Gbps了,
有同学给我反馈说以太网的吞吐量上不来, 跟理论带宽差距很大,
之前虽然优化了一波TCP相关的参数, 但估计不能解决全部问题.
遂决定重新学习下网络优化, 从底层链路对开发平台上的网络进行改善.
趁着这个机会, 索性写一个系列文章-Linux网络优化,
用来总结下Linux网络优化的一些方法与技术,
目前计划从如下几篇文章展开(希望不要放飞了):
L2的优化,
如何从收发两个方面优化网卡吞吐量，即本篇。L3协议栈优化DPDK/XDP解决高速网络传输延迟问题TSN/AVB协议这篇文章主要讲第一个话题:
Linux是如何在数据链路层L2对网络数据的接收与发送进行优化的.
断断续续看了Bjarne Stroustrup的’C++之旅(a tour of C++)’,
作者把很多原本看起来复杂的概念模型都讲的比较清晰, 也有不少好的代码示例,
有种拨云见雾的感觉. 于是想着写一篇文章来总结重新学习C++的一些经验,
主要阐述下现代C++(>=C++11)中那些容易让人混淆而觉得陌生的技术.
了解C++历史的人都知道,
Bjarne Stroustrup是在Bell实验室(就是Unix操作系统与C语言诞生的地方)发明了C++,
初衷是在C中加入类(class)的概念, 增强C语言在系统编程上的效率与灵活性,
也正式因为这个原因, C++在1979年最初的名字是带类的C(c with
class), 直到1984年才改名为C++. 到今天,
C++的发展历经了快40年历史,
但真正一次大的标准修改是在2011年,
这个版本也称为C++11(C++11之后的版本也统称为Modern C++).接下来我们就来一起来回顾下现代C++中那些曾经让人头疼的技术吧.
在优化网络性能时, 不可避免要对网络的带宽进行测试.
通常大家可能都会使用iperf来执行网络链路的吞吐量测试,
但iperf只能测试TCP/IP协议层的速度,
这个带宽数据跟TCP/UDP协议的参数配置以及应用层缓冲区的大小都有关系.
有时, 我们希望直接测试网卡本身的实际吞吐量, 看看网卡实际的发包能力.
Linux内核提供了pktgen工具用以产生数据包,
向网卡注入TCP/UDP数据. 这里,
我们就来看下具体如何通过pktgen来测试网卡性能.
最近因为公司安全的需求, 要修改openssh的源码,
将其移植到一个ARM的嵌入式系统上, 替换原有的预编译的版本.
参考了网上的一些移植openssh的资料, 如openssl官网编译安装说明;
移植openssh到arm-linux,
但是由于目标平台不一样, 实践起来并不能完全参考, 会有细微的差异.
这里把整个流程写下来, 总结一下, 方便后面移植相关开发工具.
深度学习(Deep Learning)是近年来人工智能的热门研究领域,
广泛地应用在工业与商业领域, 如计算机视觉(Computer Vision),
语音识别(Speech Recognition),
自然语言处理(Natural Language Processing),
机器翻译(Machine Translation), 以及医学图像分析,
药物发现等领域都采用了深度学习方法. 从本质上来说,
深度学习属于机器学习(Machine Learning)的一个分支,
是一种从大规模数据进行学习然后能在新数据集进行推理泛化的数学模型.
相比人工智能, 深度学习只是最近十来年才出现的概念, 但为何会在在最近几年(2010开始)内出现井喷式的增长, 成为人工智能领域炙手可热的研究方向了? 总结来说主要有如下几个原因:
天之道, 利而不害; 圣人之道, 为而不争
老子
Android从9.0版本开始全面支持eBPF(extended Berkeley Packet Filters),
其主要用在流量统计上, 也可以用来监控CPU/IO/内存等模块的状态.简单来说,
eBPF可以与内核的kprobe/tracepoints/skfilter等模块相结合,
将eBPF的函数hook到内核事件从而监控相应的系统状态.
Android为eBPF提供了许多封装的库,
并提供了eBPF加载器bpfloader:
bpfloader: 位于/system/bpf/bpfloader,
系统启动时负责加载位于/system/etc/bpf 中的eBPF目标文件libbpf_android:
位于/system/bpf/libbpf_android提供创建bpf容器/加载bpf目标文件的接口libbpf: 位于/external/bcc,
封装了bpf的系统调用, 提供如attach/dettach程序的接口libnetdbpf: 位于/system/netd/libnetdbpf,
实现了netd流量统计功能的函数目前在Android(Q)上有两处eBPF的代码:
一个是/system/netd/bpf_progs/netd.c,
主要是用于流量统计；一个是/system/bpfprogs/time_in_state.c用于监控CPU运行频率以及上下文切换的耗时.
接下来我们就从三个部分来深入理解下Android是如何利用eBPF的:
ARP(Address Resolution Protocol)即地址解析协议,
用于将网络层L3的IP地址转换成数据链路层的L2地址(MAC地址),
常用在诸如以太网, 无线网络等局域网中, 但对如点对点(P2P)网络,
组播与多播IP地址, 都无需使用ARP协议.
一般来说,
L3-L2地址的转换通常被成为邻区协议(neighboring protocol),
这种发现邻居节点(neighbor)的协议被统称为邻居发现协议(Neighbor Discovery Protocol,
ND).
ARP可以看作是ND的ipv4版本(参考RFC826),
在ipv6中则直接称为ND(参考RFC4861).
邻居节点(
neighbor)指的是跟主机在同一局域网(LAN)的其他节点
ND协议有两种消息类型:
Solicitation Request(也称为Neighbor Solicitation):
用于主机发送消息到网络中查询是否有主机拥有某个L3的IP地址,
该消息可以是单播, 组播或者广播形式.Solicitation Reply(又称为Neighbor Advertisement):
收到Solicitation Request包时发出的回应包(有可能是HOST本身发出的,
也有可能是ARP代理服务器发送的)那么, 什么是Gratuitous ARP(简称GARP,
免费ARP)了? 简单来说,
GARP是一种用于告知网络中其他节点某些特定信息的ARP请求包,
但无须其他节点发送回应包, 常用于如下三种情况:
最近碰到了一个很奇怪的问题, Android系统(Linux内核4.15)唤醒后,
SoC(高通平台)跟TBox(Telematics Box)TCP的连接会偶发变慢,
需要等超过10s才能连接上. 发送ping包给TBox,
通过strace看进程一直提示EAGAIN的错误.从字面意义来说EAGAIN(Resource temporarily unavailable)是内核告知ping进程当前没有可用的数据包可以接收.
可是, 问题来了:
EAGAIN的错误?
内核在什么时候会返回该错误?幸亏好这个问题比较容易重现, 折腾了两天才最终把问题的的来龙去脉搞清楚. 接下来就来看看这个问题的现象以及背后发生的根因, 最后给出几个相应的对策.
看到左耳朵耗子的一篇文章程序员如何把控自己的职业, 里边提到了Google SRE的评分卡, 用于招聘时软件工程师对自己技能水平的评估, 总共分为11个等级:
