1. 简介
Adobe 公司的实时消息传输协议 (RTMP) 通过一个可靠地流传输提供了一个双向多通道消息服务，比如 TCP [RFC0793]，意图在通信端之间传递带有时间信息的视频、音频和数据消息流。实现通常对不同类型的消息分配不同的优先级，当运载能力有限时，这会影响等待流传输的消息的次序。
本文档将对实时流传输协议 (Real Time Messaging Protocol) 的语法和操作进行描述。
1.1. 术语
本文档中出现的关键字，"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 、"OPTIONAL"，都将在 [RFC2119] 中进行解释。
2. 贡献者
Rajesh Mallipeddi，Adobe Systems 原成员，起草了本文档原始规范，并提供大部分的原始内容。
Mohit Srivastava，Adobe Systems 成员，促成了本规范的开发。
3. 名词解释
Payload (有效载荷)：包含于一个数据包中的数据，例如音频采样或者压缩的视频数据。payload 的格式和解释，超出了本文档的范围。
Packet (数据包)：一个数据包由一个固定头和有效载荷数据构成。一些个底层协议可能会要求对数据包定义封装。
Port (端口)："传输协议用以区分开指定一台主机的不同目的地的一个抽象。TCP/IP 使用小的正整数对端口进行标识。" OSI 传输层使用的运输选择器 (TSEL) 相当于端口。
Transport address (传输地址)：用以识别传输层端点的网络地址和端口的组合，例如一个 IP 地址和一个 TCP 端口。数据包由一个源传输地址传送到一个目的传输地址。
Message stream (消息流)：通信中消息流通的一个逻辑通道。
Message stream ID (消息流 ID)：每个消息有一个关联的 ID，使用 ID 可以识别出流通中的消息流。
Chunk (块)：消息的一段。消息在网络发送之前被拆分成很多小的部分。块可以确保端到端交付所有消息有序 timestamp，即使有很多不同的流。
Chunk stream (块流)：通信中允许块流向一个特定方向的逻辑通道。块流可以从客户端流向服务器，也可以从服务器流向客户端。
Chunk stream ID (块流 ID)：每个块有一个关联的 ID，使用 ID 可以识别出流通中的块流。
Multiplexing (合成)：将独立的音频/视频数据合成为一个连续的音频/视频流的加工，这样可以同时发送几个视频和音频。
DeMultiplexing (分解)：Multiplexing 的逆向处理，将交叉的音频和视频数据还原成原始音频和视频数据的格式。
Remote Procedure Call (RPC 远程方法调用)：允许客户端或服务器调用对端的一个子程序或者程序的请求。
Metadata (元数据)：关于数据的一个描述。一个电影的 metadata 包括电影标题、持续时间、创建时间等等。
Application Instance (应用实例)：服务器上应用的实例，客户端可以连接这个实例并发送连接请求。
Action Message Format (AMF 动作消息格式协议)：一个用于序列化 ActionScript 对象图的紧凑的二进制格式。AMF 有两个版本：AMF 0 [AMF0] 和 AMF 3 [AMF3]。
4. 字节序、对齐和时间格式
所有整数型属性以网络字节顺序传输，字节 0 代表第一个字节，零位是一个单词或字段最常用的有效位。字节序通常是大端排序。关于传输顺序的更多细节描述参考 IP 协议 [RFC0791]。除非另外注明，本文档中的数值常量都是十进制的 (以 10 为基础)。
除非另有规定，RTMP 中的所有数据都是字节对准的；例如，一个十六位的属性可能会在一个奇字节偏移上。填充后，填充字节应该有零值。
RTMP 中的 Timestamps 以一个整数形式给出，表示一个未指明的时间点。典型地，每个流会以一个为 0 的 timestamp 起始，但这不是必须的，只要双端能够就时间点达成一致。注意这意味着任意不同流 (尤其是来自不同主机的) 的同步需要 RTMP 之外的机制。
因为 timestamp 的长度为 32 位，每隔 49 天 17 小时 2 分钟和 47.296 秒就要重来一次。因为允许流连续传输，有可能要多年，RTMP 应用在处理 timestamp 时应该使用序列码算法 [RFC1982]，并且能够处理无限循环。例如，一个应用假定所有相邻的 timestamp 都在 2^31 - 1 毫秒之内，因此 10000 在 4000000000 之后，而 3000000000 在 4000000000 之前。
timestamp 也可以使用无符整数定义，相对于前面的 timestamp。timestamp 的长度可能会是 24 位或者 32 位。
5. RTMP 块流
本节介绍实时消息传输协议的块流 (RTMP 块流)。 它为上层多媒体流协议提供合并和打包的服务。
当设计 RTMP 块流使用实时消息传输协议时，它可以处理任何发送消息流的协议。每个消息包含 timestamp 和 payload 类型标识。RTMP 块流和 RTMP 一起适合各种音频-视频应用，从一对一和一对多直播到点播服务，到互动会议应用。
当使用可靠传输协议时，比如 TCP [RFC0793]，RTMP 块流能够对于多流提供所有消息可靠的 timestamp 有序端对端传输。RTMP 块流并不提供任何优先权或类似形式的控制，但是可以被上层协议用来提供这种优先级。例如，一个直播视频服务器可能会基于发送时间或者每个消息的确认时间丢弃一个传输缓慢的客户端的视频消息以确保及时获取其音频消息。
RTMP 块流包括其自身的带内协议控制信息，并且提供机制为上层协议植入用户控制消息。
5.1 消息格式
可以被分割为块以支持组合的消息的格式取决于上层协议。消息格式必须包含以下创建块所需的字段。
Timestamp：消息的 timestamp。这个字段可以传输四个字节。
Length：消息的有效负载长度。如果不能省略掉消息头，那它也被包括进这个长度。这个字段占用了块头的三个字节。
Type Id：一些类型 ID 保留给协议控制消息使用。这些传播信息的消息由 RTMP 块流协议和上层协议共同处理。其他的所有类型 ID 可用于上层协议，它们被 RTMP 块流处理为不透明值。事实上，RTMP 块流中没有任何地方要把这些值当做类型使用；所有消息必须是同一类型，或者应用使用这一字段来区分同步跟踪，而不是类型。这一字段占用了块头的一个字节。
Message Stream ID：message stream (消息流) ID 可以使任意值。合并到同一个块流的不同的消息流是根据各自的消息流 ID 进行分解。除此之外，对 RTMP 块流而言，这是一个不透明的值。这个字段以小端格式占用了块头的四个字节。
客户端必须等待接收到 S1 才能发送 C2。
客户端必须等待接收到 S2 才能发送任何其他数据。
服务器端必须等待接收到 C0 才能发送 S0 和 S1，也可以等待接收到 C1 再发送 S0 和 S1。服务器端必须等待接收到 C1 才能发送 S2。服务器端必须等待接收到 C2 才能发送任何其他数据。
5.2.2. C0 和 S0 的格式
C0 和 S0 包都是一个单一的八位字节，以一个单独的八位整型域进行处理：
以下是 C0/S0 包中的字段：
版本号 (八位)：在 C0 中，这一字段指示出客户端要求的 RTMP 版本号。在 S0 中，这一字段指示出服务器端选择的 RTMP 版本号。本文档中规范的版本号为 3。0、1、2 三个值是由早期其他产品使用的，是废弃值；4 - 31 被保留为 RTMP 协议的未来实现版本使用；32 - 255 不允许使用 (以区分开 RTMP 和其他常以一个可打印字符开始的文本协议)。无法识别客户端所请求版本号的服务器应该以版本 3 响应，(收到响应的) 客户端可以选择降低到版本 3，或者放弃握手。
5.2.3. C1 和 S1 的格式
C1 和 S1 数据包的长度都是 1536 字节，包含以下字段：
Time (四个字节)：这个字段包含一个 timestamp，用于本终端发送的所有后续块的时间起点。这个值可以是 0，或者一些任意值。要同步多个块流，终端可以发送其他块流当前的 timestamp 的值。
Zero (四个字节)：这个字段必须都是 0。
Random data (1528 个字节)：这个字段可以包含任意值。终端需要区分出响应来自它发起的握手还是对端发起的握手，这个数据应该发送一些足够随机的数。这个不需要对随机数进行加密保护，也不需要动态值。
5.2.4. C2 和 S2 的格式
C2 和 S2 数据包长度都是 1536 字节，基本就是 S1 和 C1 的副本 (分别)，包含有以下字段：
Time (四个字节)：这个字段必须包含终端在 S1 (给 C2) 或者 C1 (给 S2) 发的 timestamp。
Time2 (四个字节)：这个字段必须包含终端先前发出数据包 (s1 或者 c1) timestamp。
Random echo (1528 个字节)：这个字段必须包含终端发的 S1 (给 C2) 或者 S2 (给 C1) 的随机数。两端都可以一起使用 time 和 time2 字段再加当前 timestamp 以快速估算带宽和/或者连接延迟，但这不太可能是有多大用处。
5.2.5. 握手示意图
下面描述了握手示意图中提到的状态：
Uninitialized (未初始化)：协议的版本号在这个阶段被发送。客户端和服务器都是 uninitialized (未初始化) 状态。之后客户端在数据包 C0 中将协议版本号发出。如果服务器支持这个版本，它将在回应中发送 S0 和 S1。如果不支持呢，服务器会才去适当的行为进行响应。在 RTMP 协议中，这个行为就是终止连接。
Version Sent (版本已发送)：在未初始化状态之后，客户端和服务器都进入 Version Sent (版本已发送) 状态。客户端会等待接收数据包 S1 而服务器在等待 C1。一旦拿到期待的包，客户端会发送数据包 C2 而服务器发送数据包 S2。(客户端和服务器各自的)状态随即变为 Ack Sent (确认已发送)。
Ack Sent (确认已发送)：客户端和服务器分别等待 S2 和 C2。
Handshake Done (握手结束)：客户端和服务器可以开始交换消息了。
5.3. 分块
握手之后，连接开始对一个或多个块流进行合并。创建的每个块都有一个唯一 ID 对其进行关联，这个 ID 叫做 chunk stream ID (块流 ID)。这些块通过网络进行传输。传递时，每个块必须被完全发送才可以发送下一块。在接收端，这些块被根据块流 ID 被组装成消息。
分块允许上层协议将大的消息分解为更小的消息，例如，防止体积大的但优先级小的消息 (比如视频) 阻碍体积较小但优先级高的消息 (比如音频或者控制命令)。
分块也让我们能够使用较小开销发送小消息，因为块头包含包含在消息内部的信息压缩提示。
块的大小是可以配置的。它可以使用一个设置块大小的控制消息进行设置 (参考 5.4.1)。更大的块大小可以降低 CPU 开销，但在低带宽连接时因为它的大量的写入也会延迟其他内容的传递。更小的块不利于高比特率的流化。所以块的大小设置取决于具体情况。
5.3.1. 块格式
每个块包含一个头和数据体。块头包含三个部分：
Basic Header (基本头，1 到 3 个字节)：这个字段对块流 ID 和块类型进行编码。块类型决定了消息头的编码格式。(这一字段的) 长度完全取决于块流 ID，因为块流 ID 是一个可变长度的字段。
Message Header (消息头，0，3，7，或者 11 个字节)：这一字段对正在发送的消息 (不管是整个消息，还是只是一小部分) 的信息进行编码。这一字段的长度可以使用块头中定义的块类型进行决定。
Extended Timestamp (扩展 timestamp，0 或 4 字节)：这一字段是否出现取决于块消息头中的 timestamp 或者 timestamp delta 字段。更多信息参考 5.3.1.3 节。
Chunk Data (有效大小)：当前块的有效负载，相当于定义的最大块大小。
5.3.1.1. 块基本头
块基本头对块流 ID 和块类型 (由下图中的 fmt 字段表示) 进行编码。块基本头字段可能会有 1，2 或者 3 个字节，取决于块流 ID。
一个 (RTMP) 实现应该使用能够容纳这个 ID 的最小的容量进行表示。
RTMP 协议最多支持 65597 个流，流 ID 范围 3 - 65599。ID 0、1、2 被保留。0 值表示二字节形式，并且 ID 范围 64 - 319
Adobe 公司的实时消息传输协议 (RTMP) 通过一个可靠地流传输提供了一个双向多通道消息服务，比如 TCP [RFC0793]，意图在通信端之间传递带有时间信息的视频、音频和数据消息流。实现通常对不同类型的消息分配不同的优先级，当运载能力有限时，这会影响等待流传输的消息的次序。
本文档将对实时流传输协议 (Real Time Messaging Protocol) 的语法和操作进行描述。
1.1. 术语
本文档中出现的关键字，"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 、"OPTIONAL"，都将在 [RFC2119] 中进行解释。
2. 贡献者
Rajesh Mallipeddi，Adobe Systems 原成员，起草了本文档原始规范，并提供大部分的原始内容。
Mohit Srivastava，Adobe Systems 成员，促成了本规范的开发。
3. 名词解释
Payload (有效载荷)：包含于一个数据包中的数据，例如音频采样或者压缩的视频数据。payload 的格式和解释，超出了本文档的范围。
Packet (数据包)：一个数据包由一个固定头和有效载荷数据构成。一些个底层协议可能会要求对数据包定义封装。
Port (端口)："传输协议用以区分开指定一台主机的不同目的地的一个抽象。TCP/IP 使用小的正整数对端口进行标识。" OSI 传输层使用的运输选择器 (TSEL) 相当于端口。
Transport address (传输地址)：用以识别传输层端点的网络地址和端口的组合，例如一个 IP 地址和一个 TCP 端口。数据包由一个源传输地址传送到一个目的传输地址。
Message stream (消息流)：通信中消息流通的一个逻辑通道。
Message stream ID (消息流 ID)：每个消息有一个关联的 ID，使用 ID 可以识别出流通中的消息流。
Chunk (块)：消息的一段。消息在网络发送之前被拆分成很多小的部分。块可以确保端到端交付所有消息有序 timestamp，即使有很多不同的流。
Chunk stream (块流)：通信中允许块流向一个特定方向的逻辑通道。块流可以从客户端流向服务器，也可以从服务器流向客户端。
Chunk stream ID (块流 ID)：每个块有一个关联的 ID，使用 ID 可以识别出流通中的块流。
Multiplexing (合成)：将独立的音频/视频数据合成为一个连续的音频/视频流的加工，这样可以同时发送几个视频和音频。
DeMultiplexing (分解)：Multiplexing 的逆向处理，将交叉的音频和视频数据还原成原始音频和视频数据的格式。
Remote Procedure Call (RPC 远程方法调用)：允许客户端或服务器调用对端的一个子程序或者程序的请求。
Metadata (元数据)：关于数据的一个描述。一个电影的 metadata 包括电影标题、持续时间、创建时间等等。
Application Instance (应用实例)：服务器上应用的实例，客户端可以连接这个实例并发送连接请求。
Action Message Format (AMF 动作消息格式协议)：一个用于序列化 ActionScript 对象图的紧凑的二进制格式。AMF 有两个版本：AMF 0 [AMF0] 和 AMF 3 [AMF3]。
4. 字节序、对齐和时间格式
所有整数型属性以网络字节顺序传输，字节 0 代表第一个字节，零位是一个单词或字段最常用的有效位。字节序通常是大端排序。关于传输顺序的更多细节描述参考 IP 协议 [RFC0791]。除非另外注明，本文档中的数值常量都是十进制的 (以 10 为基础)。
除非另有规定，RTMP 中的所有数据都是字节对准的；例如，一个十六位的属性可能会在一个奇字节偏移上。填充后，填充字节应该有零值。
RTMP 中的 Timestamps 以一个整数形式给出，表示一个未指明的时间点。典型地，每个流会以一个为 0 的 timestamp 起始，但这不是必须的，只要双端能够就时间点达成一致。注意这意味着任意不同流 (尤其是来自不同主机的) 的同步需要 RTMP 之外的机制。
因为 timestamp 的长度为 32 位，每隔 49 天 17 小时 2 分钟和 47.296 秒就要重来一次。因为允许流连续传输，有可能要多年，RTMP 应用在处理 timestamp 时应该使用序列码算法 [RFC1982]，并且能够处理无限循环。例如，一个应用假定所有相邻的 timestamp 都在 2^31 - 1 毫秒之内，因此 10000 在 4000000000 之后，而 3000000000 在 4000000000 之前。
timestamp 也可以使用无符整数定义，相对于前面的 timestamp。timestamp 的长度可能会是 24 位或者 32 位。
5. RTMP 块流
本节介绍实时消息传输协议的块流 (RTMP 块流)。 它为上层多媒体流协议提供合并和打包的服务。
当设计 RTMP 块流使用实时消息传输协议时，它可以处理任何发送消息流的协议。每个消息包含 timestamp 和 payload 类型标识。RTMP 块流和 RTMP 一起适合各种音频-视频应用，从一对一和一对多直播到点播服务，到互动会议应用。
当使用可靠传输协议时，比如 TCP [RFC0793]，RTMP 块流能够对于多流提供所有消息可靠的 timestamp 有序端对端传输。RTMP 块流并不提供任何优先权或类似形式的控制，但是可以被上层协议用来提供这种优先级。例如，一个直播视频服务器可能会基于发送时间或者每个消息的确认时间丢弃一个传输缓慢的客户端的视频消息以确保及时获取其音频消息。
RTMP 块流包括其自身的带内协议控制信息，并且提供机制为上层协议植入用户控制消息。
5.1 消息格式
可以被分割为块以支持组合的消息的格式取决于上层协议。消息格式必须包含以下创建块所需的字段。
Timestamp：消息的 timestamp。这个字段可以传输四个字节。
Length：消息的有效负载长度。如果不能省略掉消息头，那它也被包括进这个长度。这个字段占用了块头的三个字节。
Type Id：一些类型 ID 保留给协议控制消息使用。这些传播信息的消息由 RTMP 块流协议和上层协议共同处理。其他的所有类型 ID 可用于上层协议，它们被 RTMP 块流处理为不透明值。事实上，RTMP 块流中没有任何地方要把这些值当做类型使用；所有消息必须是同一类型，或者应用使用这一字段来区分同步跟踪，而不是类型。这一字段占用了块头的一个字节。
Message Stream ID：message stream (消息流) ID 可以使任意值。合并到同一个块流的不同的消息流是根据各自的消息流 ID 进行分解。除此之外，对 RTMP 块流而言，这是一个不透明的值。这个字段以小端格式占用了块头的四个字节。
5.2 握手
一个 RTMP 连接以握手开始。RTMP 的握手不同于其他协议；RTMP 握手由三个固定长度的块组成，而不是像其他协议一样的带有报头的可变长度的块。
客户端 (发起连接请求的终端) 和服务器端各自发送相同的三块。便于演示，当发送自客户端时这些块被指定为 C0、C1 和 C2；当发送自服务器端时这些块分别被指定为 S0、S1 和 S2。
5.2.1. 握手顺序
客户端必须等待接收到 S1 才能发送 C2。
客户端必须等待接收到 S2 才能发送任何其他数据。
服务器端必须等待接收到 C0 才能发送 S0 和 S1，也可以等待接收到 C1 再发送 S0 和 S1。服务器端必须等待接收到 C1 才能发送 S2。服务器端必须等待接收到 C2 才能发送任何其他数据。
5.2.2. C0 和 S0 的格式
C0 和 S0 包都是一个单一的八位字节，以一个单独的八位整型域进行处理：
以下是 C0/S0 包中的字段：
版本号 (八位)：在 C0 中，这一字段指示出客户端要求的 RTMP 版本号。在 S0 中，这一字段指示出服务器端选择的 RTMP 版本号。本文档中规范的版本号为 3。0、1、2 三个值是由早期其他产品使用的，是废弃值；4 - 31 被保留为 RTMP 协议的未来实现版本使用；32 - 255 不允许使用 (以区分开 RTMP 和其他常以一个可打印字符开始的文本协议)。无法识别客户端所请求版本号的服务器应该以版本 3 响应，(收到响应的) 客户端可以选择降低到版本 3，或者放弃握手。
5.2.3. C1 和 S1 的格式
C1 和 S1 数据包的长度都是 1536 字节，包含以下字段：
Time (四个字节)：这个字段包含一个 timestamp，用于本终端发送的所有后续块的时间起点。这个值可以是 0，或者一些任意值。要同步多个块流，终端可以发送其他块流当前的 timestamp 的值。
Zero (四个字节)：这个字段必须都是 0。
Random data (1528 个字节)：这个字段可以包含任意值。终端需要区分出响应来自它发起的握手还是对端发起的握手，这个数据应该发送一些足够随机的数。这个不需要对随机数进行加密保护，也不需要动态值。
5.2.4. C2 和 S2 的格式
C2 和 S2 数据包长度都是 1536 字节，基本就是 S1 和 C1 的副本 (分别)，包含有以下字段：
Time (四个字节)：这个字段必须包含终端在 S1 (给 C2) 或者 C1 (给 S2) 发的 timestamp。
Time2 (四个字节)：这个字段必须包含终端先前发出数据包 (s1 或者 c1) timestamp。
Random echo (1528 个字节)：这个字段必须包含终端发的 S1 (给 C2) 或者 S2 (给 C1) 的随机数。两端都可以一起使用 time 和 time2 字段再加当前 timestamp 以快速估算带宽和/或者连接延迟，但这不太可能是有多大用处。
5.2.5. 握手示意图
下面描述了握手示意图中提到的状态：
Uninitialized (未初始化)：协议的版本号在这个阶段被发送。客户端和服务器都是 uninitialized (未初始化) 状态。之后客户端在数据包 C0 中将协议版本号发出。如果服务器支持这个版本，它将在回应中发送 S0 和 S1。如果不支持呢，服务器会才去适当的行为进行响应。在 RTMP 协议中，这个行为就是终止连接。
Version Sent (版本已发送)：在未初始化状态之后，客户端和服务器都进入 Version Sent (版本已发送) 状态。客户端会等待接收数据包 S1 而服务器在等待 C1。一旦拿到期待的包，客户端会发送数据包 C2 而服务器发送数据包 S2。(客户端和服务器各自的)状态随即变为 Ack Sent (确认已发送)。
Ack Sent (确认已发送)：客户端和服务器分别等待 S2 和 C2。
Handshake Done (握手结束)：客户端和服务器可以开始交换消息了。
5.3. 分块
握手之后，连接开始对一个或多个块流进行合并。创建的每个块都有一个唯一 ID 对其进行关联，这个 ID 叫做 chunk stream ID (块流 ID)。这些块通过网络进行传输。传递时，每个块必须被完全发送才可以发送下一块。在接收端，这些块被根据块流 ID 被组装成消息。
分块允许上层协议将大的消息分解为更小的消息，例如，防止体积大的但优先级小的消息 (比如视频) 阻碍体积较小但优先级高的消息 (比如音频或者控制命令)。
分块也让我们能够使用较小开销发送小消息，因为块头包含包含在消息内部的信息压缩提示。
块的大小是可以配置的。它可以使用一个设置块大小的控制消息进行设置 (参考 5.4.1)。更大的块大小可以降低 CPU 开销，但在低带宽连接时因为它的大量的写入也会延迟其他内容的传递。更小的块不利于高比特率的流化。所以块的大小设置取决于具体情况。
5.3.1. 块格式
每个块包含一个头和数据体。块头包含三个部分：
Basic Header (基本头，1 到 3 个字节)：这个字段对块流 ID 和块类型进行编码。块类型决定了消息头的编码格式。(这一字段的) 长度完全取决于块流 ID，因为块流 ID 是一个可变长度的字段。
Message Header (消息头，0，3，7，或者 11 个字节)：这一字段对正在发送的消息 (不管是整个消息，还是只是一小部分) 的信息进行编码。这一字段的长度可以使用块头中定义的块类型进行决定。
Extended Timestamp (扩展 timestamp，0 或 4 字节)：这一字段是否出现取决于块消息头中的 timestamp 或者 timestamp delta 字段。更多信息参考 5.3.1.3 节。
Chunk Data (有效大小)：当前块的有效负载，相当于定义的最大块大小。
5.3.1.1. 块基本头
块基本头对块流 ID 和块类型 (由下图中的 fmt 字段表示) 进行编码。块基本头字段可能会有 1，2 或者 3 个字节，取决于块流 ID。
一个 (RTMP) 实现应该使用能够容纳这个 ID 的最小的容量进行表示。
RTMP 协议最多支持 65597 个流，流 ID 范围 3 - 65599。ID 0、1、2 被保留。0 值表示二字节形式，并且 ID 范围 64 - 319
最低0.47元/天 解锁文章
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
