rtmpt

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的會話期間，有四種可能的請求類型從客户端發送到服務器，我們將在下面進行描述。

URL的形式如下：

http://server/<comand>/[<client>/]<index>

<command> 是RTMPT請求的類型(詳細描述見下)

<client> 給出執行這個請求的客户端的ID(只是在連接建立後才發送)

<index> 是一個順序增加的數字，好像是用來進行丟包檢查的

所有的連接請求都具有以下屬性：

使用HTTP 1.1的POST;

Content type 是 application/x-fcs;

服務器和客户端的連接是長連接以減少網絡負擔；

HTTP的迴應也有一些相同的特性：

Content type 是 application/x-fcs;

所有連接會話的迴應裏的第一個字節是用來控制客户端的輪詢週期的，值越大輪詢請求越少；

服務器開始返回數據時輪詢週期一直是從0x01開始，大約在10個空的應答後增加一下這個值，最大的延遲時間值是0x21，它造成的結果是兩個請求間大約有0.5秒的間隔。

Red5 現在是以以下的步驟增加：0x01, 0x03, 0x05, 0x09, 0x11, 0x21.

這是第一個發送到服務器的命令，在服務器上註冊客户端，開始一個新的會話。服務器返回一個獨一無二的ID(一般是一個數字)，客户端在將來的請求中將使用這個ID。

注意：回覆的數據中不包含輪詢週期值，連接成功後會重設在URL中使用的索引值。

在RTMP中客户端發送到服務器的數據不用修改，在附加上HTTP頭後，就是一個HTTP的請求。

服務器迴應HTTP的數據中第一個字節是控制輪詢間隔的，如果後面還有數據，那就是RTMP的。

如果客户端沒有數據了，它就得向服務器輪詢更新，接收流數據或者像shared objects這樣的事件。

如果客户端想中斷連接，它可以發送close命令到服務器，服務器回覆一個0x00.

^[1] 

握手 - 在連接建立

通信 - 消息被傳遞到客户端

關閉連接

^[2]