JasonWang's Blog

JasonWang's Blog

Android如何进行DNS解析

DNS(Domain Name System)即域名解析系统,是网络访问时用于将域名解析成对应IP地址的一种分布式网络服务。比如,要访问www.google.com这个域名,Android系统会首先发送一个UDP请求到标准的53端口系统的域名解析服务器,拿到对应的IP地址后才会与服务端建立连接。除了标准的DNS服务外,目前还有HttpDNS(DNS over Https, DoH)以及基于TSLDNS服务(DNS over TLS, DoT)。

那么,AndroidDNS解析的大致框架是怎么的?整个DNS解析的流程又是怎么样的? 在看具体实现细节之前,我们不妨思考一下几个问题,想一想,如果我们自己从零开始为Android设计一个DNS系统,应该怎么做?

Android中HAL服务无法使用网络的问题

最近有同学在Android S(12)上遇到了一个奇怪的网络问题,说自己的audio HAL服务尝试通过以太网创建socket与其他局域网的节点通讯时,总是提示Operation Not Permitted。原先怀疑是Selinux的问题,但是目前在开发版本中selinux是完全关闭的;从问题发生的现象看,只有属于audioserver这个UID的进程才有问题,其他的如system/root的进程则没有问题。

据此,我们可以推断,audioserver这个UID的进程没有相关权限,所以导致无法使用局域网的网络。记得在早前的Android版本中,很多网络系统调用会通过netd代理进行权限检查,比如socket/connect/bind等系统调用都会先通过netdClient这个库的接口进行权限检查,而后才真正进行系统调用。

为什么iperf测试时UDP会出现高丢包率

这两天质量的同学反馈说iperf测试时结果很差,跟实际的千兆带宽差别很大。确认了半天,发现内核的各项参数都已经完全按照千兆的目标速率进行配置了,那为什么还是会出现TCP/UDP带宽不足的问题? 记得当时优化参数时,自己摸底测试的TCP结果挺好的,都达到了预期的900Mbps以上,看起来最近有什么修改导致了这个测试结果差异。

偶然的一个机会查看内核配置时,发现最近有人打开了trace功能,看起来很可能是这个修改导致了网络性能的下降了。拿早前未开启trace功能的版本一对比,果真是trace功能影响了TCP的带宽。

再见2022

创造力 = 能力 × 热情 × 思维方式

  • “能力”是指努力学到的知识、经验和技能
  • “热情”是指工作时所有的激情和渴望成功等因素
  • “思维方式”则指对待工作的心态、精神状态和价值偏好

一个人和一个企业能够取得多大成就,就看三个因素的乘积

稻盛和夫

flow on the sea

Linux网络优化之AVB/TSN

这是Linux网络优化系列的第四篇文章,也是最后一篇了。最近有点忙,没有抽出时间来梳理这些知识点, 看了下文章历史,这个优化系列文章前后持续了大半年时间,今天总算达成了目标*_*。

背景

自从互联网诞生以来, 音视频(Audio/Video, AV)在网络上传输已经是稀松平常的事情. 那么, 为什么还需要一个新的基于以太网的协议来传输AV数据了? 传统的音视频传输都是点对点单向连接, 比如音频通常使用I2SSPDIF/AES; 视频则使用SDI或者HDMI, 这种专用的单向连接在多设备情况下往往容易出现杂乱无章的连接线束:

如何用FFmpeg在Android上实现音视频解码

最近开发投屏功能,需要对H.264视频数据流进行解码,然后显示出来。Android原生的MediaCodec虽然使用了硬件解码,但是延迟较大(超过300ms),无法满足要求。于是研究了下如何基于FFMPEG来做视频流的软解码。这里对整个过程做简要的总结,看下如何在Android Studio中完成FFMPEG的视频解码:

  • 简单介绍下FFMPEG框架
  • 如何利用交叉编译生成所需要的FFMPEG共享库, 以及如何进行Android Studio的配置
  • FFMPEG解码H264的大致调用流程
如何通过QEMU启动Linux系统

看Linux驱动相关的代码, 却没有一个好的调试环境可以跟踪内核相关的调用流程。于是,想着用QEMU虚拟机来搭建一个Linux系统。花了大半天时间,终于能够启动一个简单的Linux系统了。中间踩了不少坑,找了不少资料,这里简单总结下整个过程。

以下操作都是基于Ubuntu 18.04 x86_64平台

最开始参考了如何使用QEMU跑内核,使用系统自带的QEMU工具,结果提示如下错误:

1
2
3

qemu-system-aarch64 rom check and register reset failed

怀疑是QEMU的版本太低导致,于是只好又重新编译QEMU源码,最后总算大功告成。总的说来,大致要做的事情有这么几个:

  • 编译Linux内核,利用busybox来生成一个小的rootfs(关于什么是rootfs,可以参考The rootfs FS)
  • 编译QEMU,确保正常配置ARM64架构的虚拟环境
  • 一切就绪,通过qemu-system-aarch64跑起来虚拟机来
Linux网络优化之DPDK与XDP

在前面的一篇文章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相结合实现网卡与用户空间的数据传输,从而避免了内核协议栈的处理延迟。

avatar
JasonWang
生命短暂,莫空手而归