rtmp 是比较古老，但也比较流行的直播协议，rtmp 的标准文档 下载地址：百度网盘，提取码：xeiu
RTMP 协议会 把一个 大的数据，切分成小的 chunk 来发送，例如 把 NALU 结构 拆成小的 chunk 发送。标准文档里面说，拆成小的 chunk 可以不阻塞一些小的数据传输，例如 声音，或者控制指令。
这个我是这样理解，例如一个 I 帧 编码成 NALU 之后是 100Kb大小，100kb 拆成 100个 chunk，这个是视频线程在拆，然后把chunk 写到 TCP。
然后音频线程，控制指令线程，也是两个独立的线程。
假如，此时，视频线程 拆 100kb 的数据，正好拆到 第50个chunk，已经写了50个chunk给TCP，此时此刻，一个控制指令chunk也出现，他也写到TCP里面了。
所以在 TCP 流里面 ，第51个 chunk 是 控制指令。
然后服务器接受数据的时候，接受了前50个chunk，并不能传递给上层调用，因为50个chunk不完整，但是第 51 个chunk是单独的完整的数据，第51个chunk就可以提前丢给调用层。这样就实现了，小数据不会被大数据阻塞。
以上就是 chunk 分片 的好处之一，把大数据分成小分，然后小数据就能在中间插进去。大数据不完整，就不能处理，小数据完整可以优选处理。
但是在实际实现中，有些客户端实现并没有把大数据跟小数据分开线程处理。而是一起顺序处理，发完所有大数据的chunk，再发小数据的chunk。
POSIX 标准里面规定 send/recv 函数是一个原子操作（atomic operations），所以可以多线程同时调用 send() 往 TCP fd 写数据，不需要加锁。
声明：这篇文章对chunk优势的观点可能有点问题，我有空再校验一番。
©版权所属：知识星球：弦外之音，QQ：2338195090。
由于笔者的水平有限， 加之编写的同时还要参与开发工作，文中难免会出现一些错误或者不准确的地方，恳请读者批评指正。如果读者有任何宝贵意见，可以加我微信 Loken1。