rtmpt

>comman >clien >in

概述

rtmp的變種，相當於RTMP用http包裝後的協定，可穿越防火牆。
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/<COMAND>/[<client>/]<index>
<command> 是RTMPT請求的類型(詳細描述見下)
<client> 給出執行這個請求的客戶端的ID(只是在連線建立後才傳送)
<index> 是一個順序增加的數字，好像是用來進行丟包檢查的

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.

建立新的RTMPT連線

握手 - 在連線建立
通信 - 訊息被傳遞到客戶端
關閉連線

配置RTMP訊息通道的RTMPT協定