废话不多说，直接上图，以下是对srs-bench主要模块的一个梳理：

srs-bench支持对srs进行压测，其支持的范围有：

rtmp推流

rtmp拉流

hls拉流

http请求

hls拉流：

hls的拉流是，先产生一个http请求并拉去m3u8文件，解析后并顺序请求ts文件，当请求完毕后，下载任务挂起，一般挂起时长为当前模拟播放的ts文件的duration大小。

等挂起被唤醒后，再次请求m3u8文件，并更新未下载的ts文件列表后，开始请求ts文件。若本次更新的m3u8没有发生变化，那么将进行再次挂起，挂起时长不大于当前模拟播放的ts的duration。

http请求：

首先对某个url进行请求，请求之后将会产生挂起，挂起时长主要有进程启动时的入参决定。

rtmp推流：

rtmp推流进程启动时，首先会和srs在rtmp协议上进行协商，协商完成后，会读取入参时指定的flv文件。并按照当前flv tag和下一个flv tag的时间差挂起数据发送任务。

但这里需要注意的是，如果rtmp推流的压测里指定了2个以上的并发，但又由于srs-bench只支持一个flv文件输入，那么文件打开的次数会很多次，并且读取的flv数据在协程中未共享的，因此在该测试中，这一块可以改经一下，毕竟单线程的任务来说，不存在加锁问题，因此也就可以考虑是否做到一次性将数据读到内存里，所有协程共享数据发送；以此来提高测试程序的执行效率。

毕竟协程在io上不是强项。

rtmp拉流（非fast）：

对于非fast的rtmp拉流，其整个协议过程是完整的rtmp client。只不过对拉下来的流不做解码等处理，仅仅是针对协议上做一些校验和处理而已。

rtmp拉流（fast）：

类似非fast的流程来说，只是收到的数据不再做rtmp协议的校验了。