Those who cannot remember the past are condemned to repeat it
George Santayana
最近有同学在Android S(12)上遇到了一个奇怪的网络问题，说自己的audio HAL服务尝试通过以太网创建socket与其他局域网的节点通讯时，总是提示Operation Not Permitted。原先怀疑是Selinux的问题，但是目前在开发版本中selinux是完全关闭的；从问题发生的现象看，只有属于audioserver这个UID的进程才有问题，其他的如system/root的进程则没有问题。
据此，我们可以推断，audioserver这个UID的进程没有相关权限，所以导致无法使用局域网的网络。记得在早前的Android版本中，很多网络系统调用会通过netd代理进行权限检查，比如socket/connect/bind等系统调用都会先通过netdClient这个库的接口进行权限检查，而后才真正进行系统调用。
Work on stuff that matters: - work on something that matters to you more than money - create more value than you capture - take the long view.
Tim O’Reilly
这两天质量的同学反馈说iperf测试时结果很差，跟实际的千兆带宽差别很大。确认了半天，发现内核的各项参数都已经完全按照千兆的目标速率进行配置了，那为什么还是会出现TCP/UDP带宽不足的问题？
记得当时优化参数时，自己摸底测试的TCP结果挺好的，都达到了预期的900Mbps以上，看起来最近有什么修改导致了这个测试结果差异。
偶然的一个机会查看内核配置时，发现最近有人打开了trace功能，看起来很可能是这个修改导致了网络性能的下降了。拿早前未开启trace功能的版本一对比，果真是trace功能影响了TCP的带宽。
创造力 = 能力 × 热情 × 思维方式
- “能力”是指努力学到的知识、经验和技能
- “热情”是指工作时所有的激情和渴望成功等因素
- “思维方式”则指对待工作的心态、精神状态和价值偏好
一个人和一个企业能够取得多大成就，就看三个因素的乘积
稻盛和夫
这是Linux网络优化系列的第四篇文章，也是最后一篇了。最近有点忙，没有抽出时间来梳理这些知识点,
看了下文章历史，这个优化系列文章前后持续了大半年时间，今天总算达成了目标*_*。
背景
自从互联网诞生以来, 音视频(Audio/Video,
AV)在网络上传输已经是稀松平常的事情. 那么,
为什么还需要一个新的基于以太网的协议来传输AV数据了?
传统的音视频传输都是点对点单向连接,
比如音频通常使用I2S或SPDIF/AES;
视频则使用SDI或者HDMI,
这种专用的单向连接在多设备情况下往往容易出现杂乱无章的连接线束:
最近开发投屏功能，需要对H.264视频数据流进行解码，然后显示出来。Android原生的MediaCodec虽然使用了硬件解码，但是延迟较大（超过300ms），无法满足要求。于是研究了下如何基于FFMPEG来做视频流的软解码。这里对整个过程做简要的总结，看下如何在Android Studio中完成FFMPEG的视频解码:
- 简单介绍下FFMPEG框架
- 如何利用交叉编译生成所需要的FFMPEG共享库,
以及如何进行
Android Studio的配置 - FFMPEG解码H264的大致调用流程
看Linux驱动相关的代码， 却没有一个好的调试环境可以跟踪内核相关的调用流程。于是，想着用QEMU虚拟机来搭建一个Linux系统。花了大半天时间，终于能够启动一个简单的Linux系统了。中间踩了不少坑，找了不少资料，这里简单总结下整个过程。
以下操作都是基于Ubuntu 18.04 x86_64平台
最开始参考了如何使用QEMU跑内核，使用系统自带的QEMU工具，结果提示如下错误:
1 |
|
怀疑是QEMU的版本太低导致，于是只好又重新编译QEMU源码，最后总算大功告成。总的说来，大致要做的事情有这么几个:
- 编译Linux内核，利用busybox来生成一个小的rootfs（关于什么是rootfs，可以参考The rootfs FS)
- 编译QEMU，确保正常配置ARM64架构的虚拟环境
- 一切就绪，通过
qemu-system-aarch64跑起来虚拟机来
在前面的一篇文章Linux网络优化之链路层优化中，我们已经看到，随着网卡速率超过1Gbps，增加到10Gbps/100Gbps时，CPU已经很难处理如此大量的数据包了。总结来说，主要有如下瓶颈：
- 内核协议栈处理在
L3(IP)/L4(TCP)的数据处理上，消耗了比较多的时间，会导致网络延迟与传输受限 - 高速网卡会在短时间内产生大量中断，导致CPU频繁发生上下文切换，性能收到影响，进而影响网络吞吐
针对10Gbps/100Gbps等高速网卡中存在的延迟与带宽受限问题，Intel在2010年提出了DPDK(Data Plane Development Kit)基于用户空间的解决方案，并开源了实现方案,
目前DPDK支持包括Intel/ARM等多个芯片架构的指令集;
同样是Intel的工程师在2018年提出了XDP(eXpress Data Path)，与DPDK不一样的是，XDP基于现有内核socket接口，与eBPF相结合实现网卡与用户空间的数据传输，从而避免了内核协议栈的处理延迟。
TCP(Transmision Control Protocol)即传输控制协议,
位于TCP/IP协议栈的第三层(L3), 是一种提供了可靠连接的字节流协议;
TCP是目前使用最为广泛的协议之一,
HTTP/MQTT/FTP等诸多应用层协议都是基于TCP实现的,
更多关于TCP协议相关的具体内容可以参考标准文档RFC793以及早前写的一篇聊一聊TCP协议.
在上一篇文章中讲到了高速以太网如1Gbps/10Gpbs中Linux网络L2(链路层)的一些优化方法,
包括了offload(卸荷)以及scaling(缩放)两种技术.
随着高速网络的不断普及, 1Gbps/10Gpbs以太网已经被广泛使用,
40Gbps/100Gbps也已经制定标准,
TCP也在随着网络带宽的提升而不断进化.这篇文章我们就来看下如何在高速以太网下对TCP相关的参数的进行调优.
