本文来自SF Video Tech，来自Mux的工程师Nick Chadwick带来了一场演讲，帮助我们快速深入的了解RTMP协议。
若干年前，RTMP的延迟很低，已接近成为事实上的标准。但目前，在HLS，DASH，SRT和RIST等协议之间，业界正在尽最大努力摆脱它。由于RTMP还没有消失，我们仍需花一些时间来了解它是如何工作的。
首先是RTMP的简史。Nick解释了Adobe创建此协议的历史，以帮助理解它为什么有用，以及Adobe发布的规范如何没有发挥应有的作用。RTMP协议由macromedia创建，并由Adobe采纳，为其Flash技术服务，并成为类似RTP等复杂机制的替代。但很长时间以来它都是闭源的，因此从2005年开始，人们前赴后继的逆向此协议并发布了若干开源版本。最终Adobe在2012年发布了RTMP标准，但仍保留了部分技术，如H264先经过一种加密的握手方式才能进行解码播放。Adobe还构建了专利和法律的保护，这些都使得其逐渐远离了潮流。
Nick从高低两个层次概述了该协议。它是一种基于TCP的协议，允许多个双向流，还支持RPC机制。RTMP可以在一个TCP连接上，多路传输更大的消息，比如视频、消息以及非常短的数据请求如RPC。包级的多路复用允许RTMP在发送长消息的同时向另一端询问问题。
具体来说，RTMP的层级可分为streams, messages和chunks。一个逻辑流可分为视频、音频和元信息流，在消息流中每个消息紧挨着发送，每个消息都被切分成一定大小的块，这些块在单个TCP连接中传输。他快速地介绍了块的头，解释不同类型的块是什么，以及如何压缩头以节省比特率。他还描述了RTMP时间戳的工作原理以及控制消息和命令消息机制。通过块的机制，不同的消息流可以交织。最后介绍了RTMP的消息流，包括文档和代码中规定的消息格式，控制消息，类似binary JSON的AMF消息，连接方式，创建流，发布等细节。
最后，他对RTMP协议的未来展开了设想。因为RTMP有一个硬编码的支持的编解码器列表，这在扩展到新的编解码器时产生了困难。他介绍了对协议的改进建议，包括可协商的编码器设置，灵活的编码器支持，动态码率，增加UDP支持，简化规范，支持WebRTC等。
值得注意的是，这个演讲是2017年的。虽然关于RTMP本身的一切仍然会是正确的，但是当下SRT、RIST和Zixi已经取代了很多RTMP工作流程。
