RTMPT 协议

一、 概述
   RTMPT 协议是HTTP协议的扩展，Adobe的Flash Player和media server支持。RTMPT的命令基本都是用来控制网络连接的持久性的。在HTTP1.0的年代里，所有的HTTP请求都是建立一个网络连接，发出请求，得到回应，然后网络连接断开。在后来web世界变得越来越拥挤的时候，这个情况逐渐明显地成为一个性能话题，因此随着HTTP1.1标准的制订，HTTP的请求的网络连接就变成了默认情况下是持久性的长连接。
RTMPT用命令：OPEN, SEND, IDLE, CLOSE 来控制网络连接，在HTTP 1.1里这个功能是通过新增加两个额外的头项: Keep-Alive 和 Connection而实现的，它们都能以同样的方式像RTMPT一样保持网络连接的持久性。在处理RTMPT的请求时，所有的RTMPT的命令使用POST方法来处理请求和回应，此外的其他命令则可以使用GET方法。当我们回到HTTP 1.0的年代里，就会发现Adobe 的media server通过RTMPT来解决了那个时代web遇到的性能问题。这些命令只有Adobe的media server支持，其他的任何服务器都不支持这些命令。

二、 协议介绍

RTMPT协议基本上就是一个包装了RTMP的HTTP协议，它从客户端发送POST请求到服务器。由于HTTP 连接的非持久性本质，为了及时更新状态和数据，RTMPT需要客户端周期性向服务器轮询，取得服务器或者是其他客户端产生的通知事件。
在一个RTMPT的会话期间，有四种可能的请求类型从客户端发送到服务器，我们将在下面进行描述。
1. URL
URL的形式如下：
http://server//[/]

   是RTMPT请求的类型(详细描述见下)

   给出执行这个请求的客户端的ID(只是在连接建立后才发送)

   是一个顺序增加的数字，好像是用来进行丢包检查的
2. 请求和回应
所有的连接请求都具有以下属性：
使用HTTP 1.1的POST;
Content type 是 application/x-fcs;
服务器和客户端的连接是长连接以减少网络负担；
HTTP的回应也有一些相同的特性：
Content type 是 application/x-fcs;
所有连接会话的回应里的第一个字节是用来控制客户端的轮询周期的，值越大轮询请求越少；
3. 轮询间隔
服务器开始返回数据时轮询周期一直是从0x01开始，大约在10个空的应答后增加一下这个值，最大的延迟时间值是0x21，它造成的结果是两个请求间大约有0.5秒的间隔。
Red5 现在是以以下的步骤增加：0x01, 0x03, 0x05, 0x09, 0x11, 0x21.
4. 初始化连接(OPEN 命令)
这是第一个发送到服务器的命令，在服务器上注册客户端，开始一个新的会话。服务器返回一个独一无二的ID(一般是一个数字)，客户端在将来的请求中将使用这个ID。
注意：回复的数据中不包含轮询周期值，连接成功后会重设在URL中使用的索引值。
5. 客户端更新(SEND 命令)
在RTMP中客户端发送到服务器的数据不用修改，在附加上HTTP头后，就是一个HTTP的请求。
服务器回应HTTP的数据中第一个字节是控制轮询间隔的，如果后面还有数据，那就是RTMP的。

6. 轮询请求(IDLE 命令)
如果客户端没有数据了，它就得向服务器轮询更新，接收流数据或者像shared objects这样的事件。

7. 会话断开(CLOSE 命令)
如果客户端想中断连接，它可以发送close命令到服务器，服务器回复一个0x00.


原文url：http://www.joachim-bauch.de/tutorials/red5/SPEC-RTMPT.html/view