流媒体协议.pptx

流媒体网络协议介绍contents流媒体MMSHLSRTMP1342流媒体Quisque velit nisi,pretium ut lacinia in,elementum id enim.Cras ultricies ligula sed magna dictum porta.Quisque velit nisi,pretium ut lacinia in,elementum id enim.Vivamus magna justo,lacinia eget consectetur sed.ONEPART流媒体流媒体（Streaming media）是指将一连串的媒体数据压缩后，经过网络分段发送数据，在网络上即时传输影音以供观赏的一种技术与过程，此技术使得数据包得以像流水一样发送；如果不使用此技术，就必须在使用前下载整个媒体文件。流媒体文件一般定义在bit层次结构，因此流数据包并不一定必须按照字节对齐，虽然通常的媒体文件都是按照这种字节对齐的方式打包的。流媒体的三大操作平台是微软公司、RealNetworks、苹果公司提供的。2024/6/26 周三流媒体流媒体主要涉及协议部分。但在考虑到不同的网络环境时会有不同的协议以实现不同的目标。从构成上来看，一般流媒体系统分为：服务器端、分发网络及客户端。服务器端主要负责编码、封装到特定格式；分发端主要负责流式文件服务及网络包分发，这部分可能会涉及到CDN；客户端需要针对不同的平台、操作系统和运行环境而定，比较多样化，最主要的目标是解码渲染及音视频同步，但通常会附加很多增值行为，比如广告、日志分析、运维数据收集、用户习惯收集。2024/6/26 周三主要有三大“流派”：一是微软的ASF（Advanced Stream Format）。这类文件的后缀是.asf和.wmv，与它对应的播放器是微软公司的“Media Player”。用户可以将图形、声音和动画数据组合成一个ASF格式的文件，也可以将其他格式的视频和音频转换为ASF格式，而且用户还可以通过声卡和视频捕获卡将诸如麦克风、录像机等外设的数据保存为ASF格式。二是RealNetworks公司的RealMedia，它包括RealAudio、RealVideo和RealFlash三类文件，其中RealAudio用来传输接近CD音质的音频数据，RealVideo用来传输不间断的视频数据，RealFlash则是RealNetworks公司与Macromedia公司联合推出的一种高压缩比的动画格式，这类文件的后缀是.rm，文件对应的播放器是“RealPlayer”。三是苹果公司的QuickTime。这类文件扩展名通常是.mov，它所对应的播放器是“QuickTime。”此外，MPEG、AVI、DVI、SWF等都是适用于流媒体技术的文件格式。2024/6/26 周三 应用流媒体技术在互联网媒体传播方面起到了重要的作用，它方便了人们在全球范围内的信息、情感交流，其中视频点播、远程教育、视频会议、Internet直播、网上新闻发布、网络广告等方面的应用更空前广泛。2024/6/26 周三RTMPQuisque velit nisi,pretium ut lacinia in,elementum id enim.Cras ultricies ligula sed magna dictum porta.Quisque velit nisi,pretium ut lacinia in,elementum id enim.Vivamus magna justo,lacinia eget consectetur sed.TWOPART Real-Time Messaging Protocol 实时消息协议（英语：Real-Time Messaging Protocol，缩写RTMP）也称实时消息传输协议，是最初由Macromedia为通过互联网在Flash播放器与一个服务器之间传输流媒体音频、视频和数据而开发的一个专有协议。Macromedia后被Adobe Systems收购，该协议也已发布了不完整的规范供公众使用。2024/6/26 周三RTMPS，通过一个TLS/SSL连接传输RTMP。RTMPE，使用Adobe自有安全机制加密的RTMP。虽然实现的细节为专有，但该机制使用行业标准的密码学原函数。RTMPT，用HTTP封装以穿透防火墙。RTMPT通常在TCP通信端口80和443上使用明文请求来绕过大多数的公司流量过滤。封装的会话中可能携带纯粹的RTMP、RTMPS或RTMPE数据包。RTMFP,使用UDP而非TCP的RTMP，取代RTMP Chunk Stream。Adobe Systems开发了安全的实时媒体流协议包，可以让最终用户直接地相互连接（P2P）。默认使用TCP端口1935的纯粹（plain）协议。RTMP协议有许多变种：基本操作 RTMP是一种基于TCP的协议，可以维护持久连接并允许低延迟通信。为了顺利地传输流并传输尽可能多的信息，它将流分成片段，并且它们的大小在客户端和服务器之间动态协商。有时，它保持不变;对于音频数据，默认片段大小为64字节，对于视频数据和大多数其他数据类型，默认片段大小为128字节。然后可以交织来自不同流的片段，并通过单个连接进行多路复用。对于较长的数据块，协议因此每个片段仅携带一个字节的头部，因此产生非常小的开销。然而，实际上，单个片段通常不是交错的。相反，交织和多路复用在分组级别完成，跨越若干不同活动信道的RTMP分组以这样的方式交织，以确保每个信道满足其带宽，等待时间和其他服务质量要求。以这种方式交织的分组被视为不可分割的，并且不在分段级别上交织。2024/6/26 周三 基本操作 RTMP定义了几个可以在其上发送和接收分组的虚拟信道，并且它们彼此独立地操作。例如，存在用于处理RPC请求和响应的信道，用于视频流数据的信道，用于音频流数据的信道，用于带外控制消息的信道（片段大小协商等）等等。在典型的RTMP会话期间，在任何给定时间可以同时激活多个信道。当编码RTMP数据时，生成包头。除其他事项外，包头指定了发送它的信道的ID，生成它的时间戳（如果需要），以及包的有效载荷的大小。然后，此标头后跟数据包的实际有效内容，在通过连接发送之前，根据当前商定的片段大小进行分段。数据包标头本身从不分段，其大小不计入数据包第一个片段中的数据。换句话说，只有实际的数据包有效负载（媒体数据）会受到碎片的影响。2024/6/26 周三加密：可以使用以下两种方法之一加密RTMP会话：使用行业标准的TLS/SSL机制。底层RTMP会话只是包含在普通的TLS/SSL会话中。使用RTMPE，它将RTMP会话包装在更轻量级的加密层中。2024/6/26 周三HTTP隧道 在RTMP隧道（RTMPT）中，RTMP数据通过HTTP 封装和交换，来自客户端（在本例中为媒体播放器）的消息被发送到服务器上的端口80（HTTP的默认值）。虽然由于HTTP标头，RTMPT中的消息大于等效的非隧道RTMP消息，但RTMPT可能有助于在无法使用非隧道RTMP的情况下使用RTMP，例如当客户端落后时一个防火墙阻止非HTTP和非HTTPS出站通信。该协议通过POST URL发送命令，通过POST主体发送AMF消息。2024/6/26 周三 包结构数据包通过TCP连接发送，这些连接首先在客户端和服务器之间建立。它们包含一个标题和一个主体，在连接和控制命令的情况下，它使用动作消息格式（AMF）进行编码。标题分为基本标题（显示为与其余部分分离，在图中）和块消息标题。Basic Header是数据包中唯一的常量部分，通常由单个复合字节组成，其中2个最高有效位是块类型（fmt）在规范中），其余形成流ID。根据前者的值，可以省略消息头的某些字段，并且它们的值从先前的数据包派生，同时取决于后者的值，基本标头可以扩展1或2个额外字节（如案例中所示）图表总共有3个字节（c）。如果是Basic Header的剩余6位的值（BH）（最低有效）为0，则BH为2字节，表示从流ID 64到319（64+255）;如果该值为1，则BH为3个字节（最后2个字节编码为16位Little Endian）并表示从流ID 64到65599（64+65535）;如果该值为2，则BH为1字节，并保留用于低级协议控制消息和命令。块消息头包含元数据信息，例如消息大小（以字节为单位），时间戳增量和消息类型。最后一个值是单个字节，用于定义数据包是音频，视频，命令还是“低级”RTMP数据包，例如RTMP Ping。2024/6/26 周三RTMP包图 协议握手 在建立TCP连接之后，建立RTMP连接，首先通过从每一侧交换3个数据包来执行握手（在官方文档中也称为Chunks）。这些在官方规范中被称为客户端发送的数据包的C0-2和服务器端的S0-2，并且不要与只能在握手完成后才能交换的RTMP数据包混淆。这些分组具有它们自己的结构，并且C1包含设置“纪元”时间戳的字段，但由于这可以设置为零，如在第三方实现中所做的那样，可以简化分组。客户端通过发送具有代表当前协议版本的常量值0 x03的C0数据包来初始化连接。它直接跟随C1而不等待首先接收包含1536字节的S0，前4个代表时期时间戳，第二个4全部为0，其余为随机（并且可以在第三方设置为0）实现）。C2和S2分别是S1和C1的回声，除了第二个4字节是接收相应消息的时间（而不是0）。收到C2和S2后，认为握手完成。2024/6/26 周三 协议连接 此时，客户端和服务器可以通过交换AMF编码的消息来协商连接。这些包括与要建立连接所需的变量相关的键值对。Flash Media Server和其他实现使用“app”的概念来概念性地定义音频/视频和其他内容的容器，实现为服务器根目录上的文件夹，其包含要流式传输的媒体文件。第一个变量包含此应用程序的名称为“sample”，它是Wowza Server为其测试提供的名称。该flashVer字符串与Action-script getversion()函数返回的字符串相同。该audioCodec和videoCodec被编码为双打和他们的意义可以在原有规范中找到。对于videoFunction变量也是如此，在这种情况下，变量是不言自明的SUPPORT_VID_CLIENT_SEEK常量。特别感兴趣的是objectEncoding这将定义通信的其余部分是否将使用扩展的AMF3格式。由于版本3是当前的默认值，因此必须在Action-script代码中明确告知Flash客户端，以便在请求时使用AMF0。然后，服务器回复ServerBW，ClientBW和SetPacketSize消息序列，最后是一个Invoke，带有示例消息。2024/6/26 周三MMSQuisque velit nisi,pretium ut lacinia in,elementum id enim.Cras ultricies ligula sed magna dictum porta.Quisque velit nisi,pretium ut lacinia in,elementum id enim.Vivamus magna justo,lacinia eget consectetur sed.ThreePART Microsoft Media Server MMS（Microsoft Media Server）是一种串流媒体传送协议，用来访问并流式接收Windows Media服务器中.asf文件的一种协议。MMS协议用于访问Windows Media发布点上的单播内容。MMS是连接Windows Media单播服务的默认方法。若观众在Windows Media Player中键入一个URL以连接内容，而不是通过超级链接访问内容，则他们必须使用MMS协议引用该流。MMS的预设埠（端口）是1755。现在除了Windows Media外，如The KMPlayer等流行的播放器也支持该协议，有些播放器已经带有许多的媒体信息地址，用户可以很方便地通过网络看电视、电影等，当然这还是免费的。2024/6/26 周三 Microsoft Media Server与其他协议的关系：MMS协议依赖于TCP来控制流 媒体会话的连接。MMS协议消息由客户端和服务器通过TCP连接发送。由服务器传输的多媒体数据通过TCP或UDP发送。客户端还依赖UDP发送请求服务器重新发送丢失的UDP数据包的请求。MMS协议的功能类似于实时流协议（RTSP）Windows Media Extensions MS-RTSP。但是，RTSP扩展支持MMS中不可用的功能。2024/6/26 周三 Microsoft Media ServerMMS协议使用TCP连接来控制流媒体会话，发起TCP连接的实体称为客户端，响应TCP连接的实体称为服务器。多媒体数据从服务器流向客户端。客户端可以通过TCP连接向服务器发送MMS协议请求消息，请求服务器执行诸如启动和停止多媒体数据流的动作。多媒体数据通过相同的TCP连接或UDP数据包流传输。2024/6/26 周三 Microsoft Media Server当服务器将多媒体数据发送到客户端时，客户端可以向服务器发送MMS协议消息，请求它改变正在发送的流。例如，客户端可以请求服务器用相同视频流的较低比特率版本替换当前发送的视频流。如果UDP协议用于将多媒体数据发送到客户端，则客户端可以向服务器发送MMS协议消息，请求它重新发送UDP分组。如果客户端没有收到服务器传输的UDP数据包，这很有用。与客户端发送的其他MMS协议消息不同，重发UDP数据包的请求是使用UDP发送的。2024/6/26 周三 Microsoft Media Server 当使用 MMS 协议连接到发布点时，使用协议翻转以获得最佳连接。“协议翻转”始于试图通过 MMSU 连接客户端。MMSU 是 MMS 协议结合 UDP 数据传送。如果 MMSU 连接不成功，则服务器试图使用 MMST。MMST 是 MMS 协议结合 TCP 数据传送。2024/6/26 周三 Microsoft Media Server 如果连接到编入索引的.asf 文件，想要快进、后退、暂停、开始和停止流，则必须使用 MMS。不能用 UNC 路径快进或后退。若您从独立的 Windows Media Player 连接到发布点，则必须指定单播内容的 URL。若内容在主发布点点播发布，则 URL 由服务器名和.asf 文件名组成。例如：mms:/windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服务器名，sample.asf 是您想要使之转化为流的.asf 文件名。2024/6/26 周三 Microsoft Media Server运输：MMS协议使用TCP进行控制流媒体会话的连接。MMS服务器侦听来自客户端的传入TCP连接。为实现此目的，1755端口已在IANA注册。允许使用其他TCP端口，但在这种情况下，必须在URL上指定端口。如果服务器使用UDP将多媒体数据传输到客户端，则客户端还使用UDP发送重新发送丢失的UDP数据包的请求。端口1755已在IANA注册，作为此类重新发送请求的目标UDP端口。2024/6/26 周三 Microsoft Media Server消息语法：所有16位，32位和64位整数字段必须以little-endian 字节顺序传输。该协议引用MS-DTYP中定义的常用数据类型。2024/6/26 周三 Microsoft Media Server安全考虑因素:该协议存在攻击风险，攻击者欺骗RequestPacketListResend 数据包，导致服务器使用不必要的重传数据 包充斥客户端。为了帮助缓解攻击，服务器选择LinkMacToViewerReportFunnelInfo 消息中的nCubs字段的值，使攻击者难以预测其值。服务器还可以对每秒重新发送到客户端的数据包数量施加限制。由于MMS是二进制协议，因此建议实施者注意验证数据包和消息结构中的长度字段不指定导致实现访问数据超出范围的值。某些消息结构还具有指定字节偏移的字段，在这种情况下也存在类似的问题。此外，MMS消息中出现的字符串有时不需要以空值终止。2024/6/26 周三HLSQuisque velit nisi,pretium ut lacinia in,elementum id enim.Cras ultricies ligula sed magna dictum porta.Quisque velit nisi,pretium ut lacinia in,elementum id enim.Vivamus magna justo,lacinia eget consectetur sed.FOURPART HTTP Live Streaming HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U(m3u8)playlist文件，用于寻找可用的媒体流。2024/6/26 周三 HTTP Live StreamingHLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。苹果公司把HLS协议作为一个互联网草案（逐步提交），在第一阶段中已作为一个非正式的标准提交到IETF。但是，即使苹果偶尔地提交一些小的更新，IETF却没有关于制定此标准的有关进一步的动作。2024/6/26 周三 HTTP Live Streaming 基于标准HTTP事务，HTTP Live Streaming可以遍历任何允许通过标准HTTP流量的防火墙或代理服务器，这与基于UDP的协议（如RTP）不同。这还允许从传统的HTTP服务器提供内容，并通过广泛可用的基于HTTP的内容传送网络提供内容。该标准还包括标准加密机制和使用HTTPS的安全密钥分发，它们共同提供了一个简单的DRM系统。该协议的后续版本还提供特技模式快进和快退以及字幕集成。2024/6/26 周三 HTTP Live StreamingHLS协议规定：视频的封装格式是TS。视频的编码格式为H264,音频编码格式为MP3、AAC或者AC-3。除了TS视频文件本身，还定义了用来控制播放的m3u8文件（文本文件）。2024/6/26 周三 HTTP Live Streaming苹果要提出HLS这个协议，其实主要是为了解决RTMP协议存在的一些问题。比如RTMP协议不使用标准的HTTP接口传输数据，所以在一些特殊的网络环境下可能被防火墙屏蔽掉。但是HLS由于使用的HTTP协议传输数据，不会遇到被防火墙屏蔽的情况。另外于负载，RTMP是一种有状态协议，很难对视频服务器进行平滑扩展，因为需要为每一个播放视频流的客户端维护状态。而HLS基于无状态协议（HTTP），客户端只是按照顺序使用下载存储在服务器的普通TS文件，做负责均衡如同普通的HTTP文件服务器的负载均衡一样简单。2024/6/26 周三 HTTP Live Streaming另外HLS协议本身实现了码率自适应，不同带宽的设备可以自动切换到最适合自己码率的视频播放。其实HLS最大的优势就是他的亲爹是苹果。苹果在自家的iOS设备上只提供对HLS的原生支持，并且放弃了flash。Android也迫于平果的“淫威”原生支持了HLS。这样一来flv，rtmp这些Adobe的视频方案要想在移动设备上播放需要额外下点功夫。当然flash对移动设备造成很大的性能压力确实也是自身的问题。但HLS也有一些无法跨越的坑，比如采用HLS协议直播的视频延迟时间无法下到10秒以下，而RTMP协议的延迟最低可以到3、4秒左右。所以说对直播延迟比较敏感的服务请慎用HLS。2024/6/26 周三 HLS的INDEX文件2024/6/26 周三如右图所示，客户端播放HLS视频流的逻辑其实非常简单，先下载一级Index file，它里面记录了二级索引文件（Alternate-A、Alternate-B、Alternate-C）的地址，然后客户端再去下载二级索引文件，二级索引文件中又记录了TS文件的下载地址，这样客户端就可以按顺序下载TS视频文件并连续播放。播放模式点播VOD的特点就是当前时间点可以获取到所有index文件和ts文件，二级index文件中记录了所有ts文件的地址。这种模式允许客户端访问全部内容。上面的例子中就是一个点播模式下的m3u8的结构。Live 模式就是实时生成M3u8和ts文件。它的索引文件一直处于动态变化的，播放的时候需要不断下载二级index文件，以获得最新生成的ts文件播放视频。如果一个二级index文件的末尾没有#EXT-X-ENDLIST标志，说明它是一个Live视频流。2024/6/26 周三 播放模式客户端在播放VOD模式的视频时其实只需要下载一次一级index文件和二级index文件就可以得到所有ts文件的下载地址，除非客户端进行比特率切换，否则无需再下载任何index文件，只需顺序下载ts文件并播放就可以了。但是Live模式下略有不同，因为播放的同时，新ts文件也在被生成中，所以客户端实际上是下载一次二级index文件，然后下载ts文件，再下载二级index文件（这个时候这个二级index文件已经被重写，记录了新生成的ts文件的下载地址）,再下载新ts文件，如此反复进行播放。2024/6/26 周三THANKS FOR WATCHING