DNS查询lookupdns程序分析-上—StateThreads示例程序介绍
作者:罗上文,微信:Loken1,公众号:FFmpeg弦外之音
lookupdns
是 StateThreads 官网提供的一个示例程序,用协程来并发查询 多个域名 IP 信息,用法如下:
lookupdns srs.xianwaizhiyin.net ffmpeg.xianwaizhiyin.net
lookupdns
的调试环境搭建请阅读《StateThreads调试环境搭建》
lookupdns
程序主要由两个文件组成 lookupdns .c
跟 res.c
,整体的函数流程如下:
上图查询了两个域名的 dns 信息,由于使用了协程,所以两个 dns 请求几乎是同一时间发出去的,我们可以用 tcpdump + wireshark 抓包看看,命令如下:
sudo tcpdump port 53 -w dns_st.pcap
提示:dns 协议用的默认端口是 53,dns.pcap
可在 GitHub 上进行下载。
从上图可以看出,不是先查询完 srs.xianwaizhiyin.net
再查 ffmpeg.xianwaizhiyin.net
的,而是一起发出查询。从 9.35 ~ 9.40,查询两次 dns 一共花了 0.05 秒。
如果我们修改一下代码,不使用协程,看看整个通信过程是怎样的,代码如下:
tcpdump
抓包如下:
sudo tcpdump port 53 -w dns_notst.pcap
dns.pcap
可在 GitHub 上进行下载。
可以看到,如果不使用协程,需要等到 srs.xianwaizhiyin.net
的查询结果返回,才能再发出第二个请求。从0 ~ 0.07,查询两次 dns 一共花了 0.07 秒,比使用协程慢了一点。
这就是协程的魅力。
虽然 lookupdns
程序开了 2 个协程,但是他整个进程还是只有 1 个线程的。多个协程是占用一个线程里面的时间片的。单个协程占用的内存是低于单个线程的,而且协程切换的上下文消耗会少一些。
上下文切换其实也是执行的一段汇编指令/机器码,假设 从协程A 切换到 协程B 需要执行 10 条汇编指令,而 从 线程A 切换到 线程B 需要执行 20 条汇编指令,那就可以说,线程切换的消耗比协程切换高一倍。
那是不是只有 StateThreads
协程这一种方法,才能实现上面这种单线程并发查询 dns 的效果呢?
其实不是,还有另一种方法,就是自己调用 epoll
来实现这个功能,伪代码如下;
int socket_fd1 = socket(PF_INET, SOCK_DGRAM, 0)
int socket_fd2 = socket(PF_INET, SOCK_DGRAM, 0)
sendto(socket_fd2,www.baidu.net)
sendto(socket_fd1,www.xianwaizhiyin.net)
//监听两个 fd 的状态
epoll(socket_fd1,socket_fd2)
//DNS服务器返回数据了,fd 的状态会变化,然后调 recvform() 读取数据
recvform(socket_fdx)
上面这样,我们自己调 epoll
也是可以实现单线程并发查询 dns 的,而且上面的两次 sendto
中间是没有任何东西的。是连续调用的。不需要切换协程来执行第二次 sendto
,所以他完成 一次DNS查询 所执行的指令数量 应该是比 StateThreads 协程实现的 DNS 查询更少的,有兴趣的读者可以自己做实验验证一下。
但是上面这种 epoll
的用法也有他的局限,在解析复杂协议的时候会让代码的可读性降低(回调地狱),因为他把 request (请求) 跟 response (回调) 分离了。
DNS 域名查询他的协议是很简单的,数据很少,一个 UDP 包就能包含所有的域名信息,他不需要从 UDP 通道多次读数据,他不像 RTMP 那么复杂。
当需要解析复杂协议的时候,StateThreads 协程的优势就会体现出来,具体后面可以看《SRS是怎么解析connect包的》,他只需要一次 expect_message()
调用就完成了 多个 chunk
的合并 跟 connect
请求的解析。
这个优势简单来说是这样的,比如一些复杂协议,头部是 2 个字节,我们需要读够 2 个字节才能解析出来头部,然后再去读 body 的内容,body 大部分时候也要读多次。
假如是 纯 epoll 的写法,假如 UDP 通道里面只有 1 个字节到达,那就会激活 epoll ,然后执行回调函数,然后回调函数判断不够 2 字节,又会重新让 epoll 监听阻塞等待数据。
一些基于 epoll 封装的框架 libevent 会对这个流程进行简化,但还是要靠回调函数去执行任务,只要有回调,这个逻辑就分离开了,无法清晰看到它的全部的逻辑。
推荐读者阅读一下 ZLMediaKit 或者其他项目对 RTMP 协议的解析代码,然后对比 SRS 的 expect_message()
,看看代码可读性是否有提升。
推荐阅读肖志宏分享的《RTC级联和QUIC协议》视频,在第23分钟有对协程的优势进行讲解。肖志宏在视频里面讲了一个 Traditional EDSM 的问题,需要进行专门的状态机管理,但是协程不需要进行 专门的状态机管理。
思考:EDSM 专门的状态机管理 会 抵消 协程切换的上下文开销 吗?这是两种方式,A 还是 B 好?
StateThreads 协程的底层也用了 epoll
,这个我们后面会讲到。
现在我们已经基本了解了 协程的好处,下面让我们继续学习 lookupdns
程序的并发原理,请看《lookupdns程序分析-下》