rtmp协议

合集下载

RTMP协议分析及推流过程

RTMP协议分析及推流过程

RTMP协议分析及推流过程1.RTMP(实时消息传输协议)是Adobe 公司开发的⼀个基于TCP的应⽤层协议。

2.RTMP协议中基本的数据单元称为消息(Message)。

3.当RTMP协议在互联⽹中传输数据的时候,消息会被拆分成更⼩的单元,称为消息块(Chunk)。

RTMP 握⼿(Handshake):1.握⼿开始于客户端发送C0、C1块。

服务器收到C0或C1后发送S0和S1。

2.当客户端收齐S0和S1后,开始发送C2。

当服务器收齐C0和C1后,开始发送S2。

3.当客户端和服务器分别收到S2和C2后,握⼿完成。

在实际⼯程应⽤中,⼀般是客户端先将C0, C1块同时发出,服务器在收到C1 之后同时将S0, S1, S2发给客户端。

之后客户端向服务器端发送C2块,简单握⼿完成。

建⽴⽹络连接(NetConnection):1. 客户端发送命令消息中的“连接”(connect)到服务器,请求与⼀个服务应⽤实例建⽴连接。

2. 服务器接收到连接命令消息后,发送确认窗⼝⼤⼩(Window Acknowledgement Size)协议消息到客户端,同时连接到连接命令中提到的应⽤程序。

3. 服务器发送设置带宽协议消息到客户端。

4. 客户端处理设置带宽协议消息后,发送确认窗⼝⼤⼩(Window Acknowledgement Size)协议消息到服务器端。

5. 服务端向客户端发送“流开始”(Stream Begin)。

6. 服务器发送命令消息中的“结果”(_result),通知客户端连接的状态。

建⽴⽹络流(Create Stream):1. 客户端发送命令消息中的“创建流”(CreateStream)命令到服务器端。

2. 服务器端接收到“创建流”命令后,发送命令消息中的“结果”(_result),通知客户端流的状态。

播放(Play):1. 客户端发送命令“播放”给服务器2. 接收到播放命令后,服务器发送设置块⼤⼩(ChunkSize)协议消息给客户端3. 服务器发送“stream begin”给客户端,告诉客户端流的id4. 播放命令成功的话,服务器发送命令消息中的“响应状态” NetStream.Play.Start & NetStream.Play.Reset,告知客户端“播放”命令执⾏成功5. 服务器发送客户端要播放的⾳频和视频数据⼩结:关系图:播放⼀个RTMP协议的流媒体需要经过以下⼏个步骤:下⾯⽤wireshark 抓包来分析⼀下过程:RTMP 消息结构:RTMP消息块:在⽹络上传输数据时,消息需要被拆分成较⼩的数据块,才适合在相应的⽹络环境上传输。

rtmp协议

rtmp协议

rtmp协议第一篇:RTMP协议的基础概念及特点RTMP(Real Time Messaging Protocol)是一种实时消息传递协议,属于Adobe公司开发的一种流媒体协议。

RTMP 协议使用TCP进行数据传输,适用于音视频流的实时播放、互动、互传等方面,被广泛应用于视频直播、在线教育、网络会议等领域。

RTMP协议具有以下特点:1. 实时传输:RTMP协议传输数据的速度非常快,能够满足实时传输音视频流的要求。

2. 跨平台:RTMP协议支持多种操作系统和平台,包括Windows、Mac OS X、Linux等。

3. 支持多种编码方式:RTMP协议支持多种编码方式,如H.264、VP6、Sorenson Spark等,可以适应不同的数据类型和网络环境。

4. 安全性高:RTMP协议支持加密传输,可以保证数据的安全性。

5. 支持多种传输方式:RTMP协议支持多种传输方式,包括点对点传输、客户端和服务器之间的传输等。

6. 支持多种数据格式:RTMP协议支持多种数据格式,如FLV、MP4等,可以适应不同的数据类型和网络环境。

总之,RTMP协议具有高效、可靠、跨平台、安全等特点,是现今流媒体传输的主流协议之一。

第二篇:RTMP协议的工作原理及实现RTMP协议的工作原理是,客户端向服务器发送连接请求,并进行握手验证,验证通过后,建立连接,开始实时传输数据。

在建立连接后,客户端可以向服务器发送控制信息、元数据和音视频数据。

控制信息包括连接控制、流控制、消息控制等,用于控制数据的传输。

元数据包含音视频的标题、格式、描述等信息。

音视频数据则包含音视频的编码数据。

RTMP协议的传输方式有三种:直接传输、容器传输和点对点传输。

直接传输和容器传输都是通过服务器进行流媒体传输,只不过采用的传输方法不同。

点对点传输则是直接将数据传输到接收端,实现点对点传输。

实现RTMP协议需要以下步骤:1. 与服务器建立连接首先需要与服务器建立连接,进行握手验证,验证通过后方可进入数据传输阶段。

RTMP协议

RTMP协议

RTMP协议协议名称:RTMP协议一、引言RTMP(Real-Time Messaging Protocol)是一种用于实时数据传输的协议,最初由Adobe公司开发,用于在Flash平台上实现音视频流的传输。

RTMP协议可以通过传输控制协议(TCP)在客户端和服务器之间进行数据传输,支持实时音视频流的传输和即时通讯功能。

二、协议目的RTMP协议的目的是确保高效、稳定、实时的音视频传输和即时通讯功能。

通过该协议,用户可以在客户端和服务器之间传输实时音视频流,并实现实时的双向通讯。

三、协议范围本协议适用于所有使用RTMP协议进行实时音视频传输和即时通讯的应用场景,包括但不限于在线直播、视频会议、游戏实时通讯等。

四、术语定义1. RTMP:Real-Time Messaging Protocol的缩写,即实时消息传输协议。

2. 客户端:指使用RTMP协议进行数据传输的终端用户设备。

3. 服务器:指提供RTMP服务的服务器端设备。

五、协议内容1. 连接建立1.1 客户端通过TCP连接与服务器建立连接。

1.2 客户端发送连接请求到服务器,请求中包含握手信息。

1.3 服务器收到连接请求后,验证握手信息的合法性。

1.4 服务器发送握手响应到客户端,确认连接建立成功。

2. 数据传输2.1 客户端发送音视频流数据到服务器,数据格式为FLV(Flash Video)。

2.2 服务器接收音视频流数据,并进行解码处理。

2.3 服务器将解码后的音视频流数据发送给客户端。

2.4 客户端接收音视频流数据,并进行播放或显示。

3. 控制消息3.1 客户端和服务器之间通过控制消息进行交互。

3.2 控制消息包括连接控制、流控制、用户控制等。

3.3 连接控制消息用于管理连接的建立、断开和状态维护。

3.4 流控制消息用于管理音视频流的传输和控制。

3.5 用户控制消息用于控制音视频流的播放、暂停、停止等操作。

4. 安全性4.1 RTMP协议支持加密传输,可使用SSL/TLS协议进行数据加密。

rtmp协议

rtmp协议

rtmp协议
RTMP协议是一种用于传输音视频流的协议。

它被广泛应
用于直播、视频会议等领域。

RTMP协议使用了TCP作为传输
协议,并且支持多种编码格式。

RTMP协议的传输方式分为两种:直接传输和隧道传输。

直接传输方式是指音视频数据通过TCP直接传输。

隧道传输方式是指音视频数据被封装成RTMP数据包后,通过HTTP或HTTPS协议传输,接收端再将其解包。

RTMP协议中涉及到的一些概念包括:RTMP URL、RTMP消息、RTMP Chunk等。

RTMP URL是指包含协议、主机名、端口
号和应用名称等信息的URL字符串。

RTMP消息是指RTMP协议
中传输的信息,它包含了消息类型、时间戳等信息。

RTMP Chunk是指将RTMP消息进行分块后的数据块,用于在传输过
程中进行拆分和组装。

RTMP协议中包含了多种消息类型,包括连接建立、控制
消息、音视频数据等。

其中,控制消息包含了流控制、窗口大小调整等功能。

音视频数据则需要经过音视频编码器进行编码,然后再进行传输。

在实际应用中,RTMP协议一般用于直播、视频会议等领域。

对于直播来说,RTMP协议可以将视频数据实时传输到服
务器,然后再通过HTTP或HTTPS协议分发给用户。

同时,RTMP协议还提供了多种流媒体控制功能,可以对音视频数据
进行控制、调整。

总之,RTMP协议是一种非常重要的音视频传输协议,它
的广泛应用为直播、视频会议等领域提供了了更加便捷、实时、高效的传输方式。

rtmp协议

rtmp协议

RTMP协议RTMP(Real-Time Messaging Protocol)是一种用于音频、视频和数据传输的协议。

它最初是由Adobe Systems开发,用于在Flash平台上进行实时通信和流媒体传输。

RTMP协议支持实时的音视频传输,可以在互联网上进行高效的视频直播和互动。

概述RTMP协议是一种基于TCP的协议,它通过三个不同的通道进行数据传输:命令通道、音频通道和视频通道。

这种分离的通道使得音视频数据可以独立传输,实现了低延迟、高质量的实时传输。

RTMP协议的特点1. 实时性RTMP协议通过优化传输方式和缓存机制,能够实现低延迟的音视频传输。

这使得它在直播、视频会议等实时场景下得到广泛应用。

2. 强大的流媒体支持RTMP协议支持流媒体传输,可以在互联网上进行高效的视频直播和点播。

它能够根据客户端的带宽情况,动态调整视频的码率和分辨率,保证最佳的观看体验。

3. 安全性RTMP协议可以通过加密和身份验证等方式来保护数据的安全性。

它支持RTMPS(RTMP over SSL/TLS)协议,可以在传输过程中对数据进行加密,防止数据被窃取或篡改。

RTMP协议的工作流程RTMP协议的工作流程可以简单描述为以下几个步骤:1.客户端与服务器建立TCP连接。

2.客户端发送握手请求,服务器返回握手响应。

3.客户端和服务器进行握手确认。

4.客户端发送命令消息,服务器执行相应的操作。

5.客户端发送音频和视频数据,服务器进行解码和处理。

6.服务器将音频和视频数据发送给其他客户端或进行存储。

7.客户端接收到音频和视频数据,进行解码和播放。

RTMP协议的应用场景1. 视频直播RTMP协议在视频直播领域有着广泛的应用。

通过RTMP协议,用户可以将自己的视频内容实时传输到服务器,并且其他用户可以通过使用RTMP协议进行接收和播放。

2. 视频会议RTMP协议支持实时的音频和视频传输,因此在视频会议中也得到了广泛应用。

用户可以通过RTMP协议进行实时的音视频通话,实现远程会议和协作。

直播技术的流媒体传输协议常见的直播流媒体传输协议介绍

直播技术的流媒体传输协议常见的直播流媒体传输协议介绍

直播技术的流媒体传输协议常见的直播流媒体传输协议介绍直播技术在现代社交媒体中的应用越来越广泛,为了实现高质量的流媒体传输,直播平台借助各种流媒体传输协议。

本文将介绍几种常见的直播流媒体传输协议,并对其特点进行分析。

一、RTMP协议RTMP(Real-Time Messaging Protocol)是一种实时消息传输协议,由Adobe开发。

它采用基于TCP的传输方式,在互联网传输中表现出良好的稳定性和实时性。

RTMP协议通过将音频、视频及元数据打包成小块传输,保证了传输的流畅性和稳定性。

RTMP协议被广泛应用于实时直播领域,尤其在低延迟的直播环境下表现出色。

二、HLS协议HLS(HTTP Live Streaming)协议是由Apple提出的流媒体传输协议。

HLS协议基于HTTP协议,将整个视频分成多个小的TS (Transport Stream)文件,通过HTTP协议逐个传输。

HLS协议适应性强,支持多种终端设备播放,并且能够自适应网络环境的变化。

这使得HLS成为了许多直播平台的首选协议。

三、DASH协议DASH(Dynamic Adaptive Streaming over HTTP)协议是一种动态自适应流媒体传输协议,由MPEG联盟制定。

DASH协议无需握手过程,通过HTTP协议动态获取数据,根据客户端自身的网络情况和解码能力选择相应的码率和片段进行播放。

DASH协议具有较好的抗丢包能力和适应性,能够在不同的网络环境下提供良好的用户体验。

四、FLV协议FLV(Flash Video)协议是一种用于传输视频和音频的流媒体传输协议,由Adobe Flash Player支持。

FLV协议将视频和音频数据打包成FLV文件进行传输,常用于Adobe Flash Player播放器的直播功能。

然而,由于Adobe Flash Player不再被主流浏览器支持,FLV协议的使用范围受到了限制。

五、WebSocket协议WebSocket协议是一种全双工通信协议,它可以在一个TCP连接上实现双向通信。

RTMP协议

RTMP协议

RTMP协议协议名称:Real-Time Messaging Protocol (RTMP) 协议1. 引言本协议描述了 Real-Time Messaging Protocol (RTMP) 的标准格式。

RTMP 是一种用于实时数据传输的协议,最初由 Adobe Systems 开发,用于在 Adobe Flash 平台上传输音频、视频和数据流。

随着时间的推移,RTMP 也被应用于其他实时流媒体应用程序。

2. 目的本协议的目的是规范 RTMP 的通信过程和数据格式,以确保在不同平台和设备之间的兼容性和互操作性。

3. 协议规范3.1 连接建立- 客户端通过 TCP/IP 连接到 RTMP 服务器的默认端口 1935。

- 客户端发送 C0 和 C1 数据包,其中 C0 是一个字节,表示 RTMP 版本号,C1 是一个 1536 字节的随机数据块。

- 服务器接收到 C0 和 C1 数据包后,发送 S0 和 S1 数据包作为响应,其中 S0 是一个字节,表示 RTMP 版本号,S1 是一个 1536 字节的随机数据块。

- 客户端接收到 S0 和 S1 数据包后,发送 C2 数据包,其中包含 S1 数据块的哈希值。

- 服务器验证 C2 数据包,如果匹配成功,连接建立成功。

3.2 握手过程- 客户端发送 C0 和 C1 数据包后,等待服务器响应。

- 服务器接收到 C0 和 C1 数据包后,发送 S0 和 S1 数据包作为响应,等待客户端发送 C2 数据包。

- 客户端接收到 S0 和 S1 数据包后,发送 C2 数据包,等待服务器验证。

- 服务器验证 C2 数据包,如果匹配成功,握手成功。

3.3 数据传输- RTMP 使用消息进行数据传输,每个消息由一个消息头和一个消息体组成。

- 消息头包含了消息的类型、长度、时间戳和流 ID 等信息。

- 消息体包含了实际的数据,可以是音频、视频或其他自定义数据。

- RTMP 支持多种消息类型,如音频消息、视频消息、命令消息等。

RTMP、RTSP、HTTP视频协议详解(附:直播流地址、播放软件)

RTMP、RTSP、HTTP视频协议详解(附:直播流地址、播放软件)

RTMP、RTSP、HTTP视频协议详解(附:直播流地址、播放软件)⼀、RTMP、RTSP、HTTP协议这三个协议都属于互联⽹ TCP/IP 五层体系结构中应⽤层的协议。

理论上这三种都可以⽤来做视频直播或点播。

但通常来说,直播⼀般⽤ RTMP、RTSP。

⽽点播⽤ HTTP。

下⾯分别介绍下三者的特点。

1,RTMP协议(1)是流媒体协议。

(2)RTMP协议是 Adobe 的私有协议,未完全公开。

(3)RTMP协议⼀般传输的是 flv,f4v 格式流。

(4)RTMP⼀般在 TCP 1个通道上传输命令和数据。

2,RTSP协议(1)是流媒体协议。

(2)RTSP协议是共有协议,并有专门机构做维护。

.(3)RTSP协议⼀般传输的是 ts、mp4 格式的流。

(4)RTSP传输⼀般需要 2-3 个通道,命令和数据通道分离。

3,HTTP协议(1)不是是流媒体协议。

(2)HTTP协议是共有协议,并有专门机构做维护。

(3)HTTP协议没有特定的传输流。

(4)HTTP传输⼀般需要 2-3 个通道,命令和数据通道分离。

⼆、可⽤的直播流地址通常我们进⾏ RTMP/RTSP 开发时,除了可以⾃⼰搭建视频服务器来进⾏测试外。

也可以直接使⽤⼀些电视台的直播地址,省时省⼒。

下⾯是我收集汇总的⼀些视频直播地址,亲测可⽤。

1,RTMP协议直播源⾹港卫视:rtmp:///live/hks2,RTSP协议直播源珠海过澳门⼤厅摄像头监控:rtsp://218.204.223.237:554/live/1/66251FC11353191F/e7ooqwcfbqjoo80j.sdp⼤熊兔(点播):rtsp://184.72.239.149/vod/mp4://BigBuckBunny_175k.mov3,HTTP协议直播源⾹港卫视:/live/hks/playlist.m3u8CCTV1⾼清:/hls/cctv1hd.m3u8CCTV3⾼清:/hls/cctv3hd.m3u8CCTV5⾼清:/hls/cctv5hd.m3u8CCTV5+⾼清:/hls/cctv5phd.m3u8CCTV6⾼清:/hls/cctv6hd.m3u8苹果提供的测试源(点播):/streaming/examples/bipbop_4x3/gear2/prog_index.m3u8三、播放软件推荐:VLC要播放视频直播流,或者测试⼀个直播视频地址是否可以使⽤。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

RTMP:Real Time Messaging Protocol 实时消息传送协议字节序:大端Message Format:Timestamp:4 bytesLength:3 bytesType ID:1 bytesMessage Stream ID:4 bytes 小端Handshakethree static_sized chunksclient:C0 C1 C2server:S0 S1 S2simple handshake:handshake sequence握手开始于客户端发送C0、C1块客户端在发送C2块之前必须等待直到S1块被接收客户端在发送任何其他数据之前必须等待直到S2块被接收服务器在发送S0、S1之前必须等待直到C0被接收或是C1被接收服务器在发送S2之前必须等待直到C1被接收服务器在发送任何其他数据之前必须等待直到C2被接收C0和S0格式一个字节(8bits)本版本是3C1和S1格式1536个字节C2和S2格式1536个字节,是C1和S1的回复响应time:必须包含对等段发送的时间戳(对C2来说是S1,对S2来说是C1)time2:必须包含先前发送的被对端读取的包(S1或C1)的时间戳handshake diagramComplete handshakeChunkingChunk formatA header and data+--------------+----------------+--------------------+----------+ | Basic Header | Message Header | Extended Timestamp | Chunk Data| +--------------+----------------+--------------------+----------+ | ||<------------------- Chunk Header ----------------->|Chunk FormatBasic header:1-3bytes,chunk stream ID and chunk type(fmt) 长度可变type depend on the format of the encoded message headerthe length depend on the chunk stream IDID:3-65599,0\1\2 reserved0:2bytes,ID range 64-319 (the second byte+64)1:3bytes,ID range 64-65599(the third byte*256+the second byte+64)2:low-level protocol2-63:64-319:64-65599:Cs id:6bits 表示2-63的块流ID,0和1表示本字段2或3字节版本Fmt:2bits 表示4种typesCs id-64:块流ID-64的值Message header:0, 3, 7, or 11 bytes ,长度取决于chunk type(fmt)four different formatsType 0:11bytes,块流开始和时间戳返回时必须有这种块Timestamp:3bytes,消息的绝对时间戳在这里发送。

如果时间戳大于或等于16777215(16进制0x00ffffff),该值必须为16777215,并且扩展时间戳必须出现。

Message length:3bytes,数据大小Message type id:1bytes,数据类型Message stream id:4bytes,流IDMessage type:Type 1:7bytes,具有可变大小消息的流(many videoformats),在第一个消息之后的每个消息的第一个块应该使用这个格式。

Type 2:3bytes,具有固定大小消息的流(some audio and data formats),在第一个消息之后的每个消息的第一个块应该使用这个格式。

Type 3:块没有头。

流ID,消息长度,时间戳都不出现。

如果第一个消息和第二个消息的时间增量与第一个消息的时间戳相同,那么0类型的块之后必须是3类型的块而,不需要类型2的块来注册时间增量。

如果类型3的块在类型0的块之后,那么类型3的时间戳增量与0类型的块的时间戳相同。

Timestamp delta:3bytes,对于类型1的块和类型2的块,本字段表示先前块的时间戳与当前块的时间戳的差值。

如果增量大于等于1677215(16进制0x00ffffff),这个值必须是16777215 ,并且扩展时间戳必须出现。

否则这个值就是整个的增量。

Message length:3bytes,对于类型0或类型1的块本字段表示消息的长度。

注意,这个值通常与负载长度是不相同的。

Message type id:1bytes,对于0类型和1类型的块,本字段发送消息类型。

Message stream id:4bytes,对于0类型的块,本字段存储消息流ID Extended timestamp:0-4bytes,只有当块消息头中的普通时间戳设置为0x00ffffff时,本字段才被传送。

如果普通时间戳的值小于0x00ffffff,那么本字段一定不能出现。

如果时间戳字段不出现本字段也一定不能出现。

类型3的块一定不能含有本字段。

Chunk data:默认长度为128bytes,块的大小可配置,最大65535bytes,最小128bytes,块越大CPU使用率越低,但是也导致大的写入,在低带宽下产生其他内容的延迟。

总结:RTMP协议由包头和包体(数据)组成,包头可以是四种长度:12、8、4、1bytes,即basic header + message header。

Basic header:1bytes(官方文档即上面说可能不止1byte,但实际情况只用1byte 就够了,原因:chunk basic head的长度为1~3个字节,具体长度主要是依赖chunk stream ID的长度,所谓chunk stream ID是flash server用来管理连接的客户端的信令交互的标识,在red5的文档中称之为channel ID,协议最大支持65597个streamID 从3~65599。

ID 0,1,2为协议保留,0代表ID是64~319(第二个byte + 64);1代表chunk stream ID为64~65599((第三个byte)* 256 + 第二个byte + 64)(小端表示);2代表该消息为低层的协议(在RTMP协议中控制信令的chunk stream ID都是2)。

3~63的chunk stream ID就是该byte的值。

没有附加的字段来标识chunk stream streamID。

在这里要指出的是虽然RTMP 的chunk stream ID理论是可以达到65599,但是目前使用的chunk stream ID 很少,2~7都是约定的,8是用来传输publish play等命令,其他的chunk stream ID目前好像没有使用,所以目前chunk basic head的长度一般为1个字节),由chunk type和chunk channel ID组成。

Chunk type占据前两个bit,决定message header的大小,即type0,type1,type2,type3,分别为11,7,3,0bytes,它可以用掩码0xC0进行与运算。

Chunk channel id占据后面6个bits,Stream ID和Channel ID对应关系为:StreamID=(ChannelID-4)/5-1其可以为以下内容:02 ping和ByteRead通道03 invoke通道,我们的connect() publish()和自字写的NetConnection.Call() 数据都是在这个通道的04 audio和vedio通道05、06、07 服务器保留,经观察FMS2用这些channel也用来传送音频或视频在rtmp包中经常看见的0xC2,就表示type为type3,channel Id为2。

Message header:(11,7,3,0bytes)Timestamp:3bytesLength:3bytes,数据实际长度,可超过最大长度128bytes,如果超过128bytes,那么由多个后续RTMP封包组合,每个后续的RTMP封包头只占1bytes,一般以0xC?开头。

Type ID:1bytesStream ID:4bytes,little-endian,是音视频流的ID,如果TypeID!=0x08或!=0x09,那么streamID为0。

streamID与ChannelID之间计算公式为:streamID=(channelID-4)/5+1;前面说包头有几种长度,第一个长度是12bytes,包含了全部的头信息,第一个数据流也就是流的开始必须是这个长度。

第二种8bytes的包,没有了streamID,发这种包,对方就默认此streamID和上次相同,一个视频数据在第一个流之后都可以使这种格式,比如一个1M的视频,第一次发128bytes用12bytes的包,之后每次发的数据都应该用8bytes的包。

当然如果每次都用12bytes也没有问题。

第三种为4bytes,只有chunk_type和时间戳,缺少的对方认为与之前的一样,实际应用中很难出现。

第四中就只有chunk_type一个byte。

如果一次数据超过了长度(默认是128bytes),就要分块,第一个块是12bytes或者8bytes的,之后的块就是1byte。

因为分的N 块,每一块的信息都是一样的,所以只需要告诉对方此次包的长度就行了。

RTMP message format有两部分:a header and payload(message data)Message header:Message type:1bytes,1-6用于protocol control messageLength:3bytes,payload的大小,大端Timestamp:4bytes,大端Message stream ID:3bytes,大端Payload:message dataProtocol control messageMessage stream ID 必须为0,chunk stream ID必须为2。

Message type ID为1、2、3、5、6。

相关文档
最新文档