流媒體的傳輸協議
大家在觀看網上電影或者電視時，一般都會注意到這些文件的連接都不是用http或者ftp開頭，而是一些rtsp或者mms開頭的東西，為什么是這樣呢？實際上，這些和http和ftp一樣，都是數據在網絡上傳輸的協議，只是它們是專門用來傳輸流式媒體的協議而已。下面，讓我們來看一下現在使用的主要的流媒體協議：
1. RTSP（Real Time ），實時流媒體協議，它是由和共同提出的，現在用于的Real Media產品中；
2. PNM（ Audio），這也是Real專用的實時傳輸協議，它一般采用UDP協議，并占用7070端口，但當你的服務器在防火墻內且7070端口被擋，且你的服務器把設為真時，則采用http協議，并占用默認的80端口；
3. MMS（ Media ），這是微軟的流媒體服務器協議，MMS 是連接 Media 單播服務的默認方法。
介紹了主要的三個，可能您還會問，Apple的使用哪種協議呢？在多數情況下，使用http協議流媒體視頻編碼格式，但實際上它也由標準的流媒體傳輸協議，這就是標準RTSP協議，而Real公司使用的RTSP是自己經過開發的。
在流媒體傳輸中，標準的協議就是RTP（Real time ，實時傳輸協議）、RTCP(Real-time ，實時傳輸控制協議)、RTSP（Real Time ，實時流媒體協議）和RSVP（ , 資源預訂協議），廠商們的產品都是在這些協議的基礎上進行研究與開發，限于篇幅，在這里我們就不再深入討論了。
流媒體文件和發布格式
有了實時的傳輸協議，我們應該還能夠想到，只有較小的文件才適合網絡實時傳輸，那么，流媒體文件采用了什么樣的壓縮算法呢？
而使用操作系統的朋友可以看到，我們觀看網上流節目時，它們的后綴名一般是rm、asf、wmv等，這些就是流媒體的格式。流媒體文件格式經過特殊編碼，不僅采用較高的壓縮比，還加入了許多控制信息，使其適合在網絡上邊下載邊播放，而不是等到下載完整個文件才能播放。
常見的流媒體格式大致有以下幾種：
流媒體文件格式擴展(Video/Audio) 媒體類型與名稱
asf . ().
Video/Audio 文件 ( ).
Audio 文件 ( ).
Pix 文件 ( ).
Text 文件 ( ).
swf Shock Wave Flash ().
mov （Apple公司格式）
viv Vivo Movie 文件(Vivo ).
另外還有一個wmv格式，是 Media Video的簡稱，它與asf文件有稍許區別，wmv一般采用 media video/audio 格式，asf視頻部分一般采用 MPG4 V(3/2/1?)，音頻部分是 media audio v2/1，不過現在很多制作軟件都沒有把它們分開，所以直接更改后綴名就能夠互相轉換為對方格式。
制作完成的流媒體文件需要發布到網絡上才能夠被別人使用，這就需要以特定方式安排壓縮好的流媒體文件，而安排流媒體文件的格式就被成為流媒體發布格式。常見的發布格式主要有以下幾種：
流媒體發布格式擴展 媒體類型和名稱
.
smil .
File.
RAM File.
/ASF流轉向器文件
MPEG-4與流媒體
說到流媒體就不能不提及MPEG-4。MPEG-4是當前討論的焦點之一，只因為它能夠在大的壓縮比下實現近似DVD品質的視頻和音頻效果，這也是許多朋友認為MPEG-4格式肯定比rm清晰的原因。但事實上并不是如此，MPEG-4只是一種視頻編碼技術，它的清晰度也根據壓縮時所選擇的碼率的不同有較大的改變（我們見到的MPEG-4格式文件通常為壓縮生成，質量當然高了），并且，MPEG-4還有多種壓縮標準，如的asf視頻部分就是基于MPEG-4的 (DCT)，另外還有DivX的免費MPEG-4版本（開始是破解微軟的格式而來）。至于音頻部分，更是混亂，采用 media audio v2/1，DivX采用MP3或者更高質量的AC3等。相比而言，Real或者Apple的格式使用的是自己開發的編碼，在相同碼率，特別是低碼率下，不見得就比MPEG-4差，采取高碼率的rm格式照樣清晰可人，所以大家以后說rm格式清晰度差的觀念要改變一下：），至少也要加上條件。而且，最新的Helix 中的Real Video 9采用VP5壓縮格式進行編碼，這可比DivX優秀多了！
不過，流媒體服務器開始向MPEG-4格式靠攏是不爭的事實，Real最新的Helix就開始支持mp4格式文件的服務，而 更是只需安裝一個插件便可實現MPEG-4格式的播放。
點播與廣播
在架設流媒體服務器之前，我們一定要了解一些點播與廣播的知識。
點播是客戶端與服務器之間的主動的連接，在點播連接中，用戶通過選擇內容項目來初始化客戶端連接，一個客戶端從服務器接收一個媒體流（這個連接是唯一的，其它用戶不能占用），并且能夠對媒體進行開始、停止、后退、快進或暫停等操作，客戶端擁有流的控制權，就像在看影碟一樣。這種方式由于每個客戶端各自連接服務器，服務器需要給每個用戶建立連接，對服務器資源和網絡帶寬的需求都比較大。
廣播指的是用戶被動接收流。在廣播過程中，客戶端接收流，但不能控制流，用戶不能暫停、快進或后退該流，廣播使用的數據發送手段有單播與廣播。使用單播發送時，服務器需要將數據包復制多個拷貝，以多個點對點的方式分別發送到需要它的那些用戶，而使用廣播方式發送，數據包的單獨一個拷貝將發送給網絡上的所有用戶，而不管用戶是否需要，上述兩種傳輸方式會非常浪費網絡帶寬和服務器資源，因此產生了組播（多播）技術。
組播（多播）吸收了上述兩種發送方式的長處，克服了上述兩種發送方式的弱點，將數據包的單獨一個拷貝發送給需要的那些客戶，組播不會復制數據包的多個拷貝傳輸到網絡上，也不會將數據包發送給不需要它的那些客戶，保證了網絡上多媒體應用占用網絡的最小帶寬。但組播不僅需要服務器端支持，更需要有多播路由器乃至整個網絡結構的支持。
單播與組播（多播）
在上面我們已經了解了一些單播和組播的概念，這也是現在流媒體方面討論的焦點之一。以我的認識流媒體視頻編碼格式，點播與廣播是一組概念，它們和客戶端媒體交互的手段；單播和組播又是另外一組概念，它們是流媒體數據在服務器端和網絡上的傳輸方式。
單播發送時，需要在客戶端與媒體服務器之間需要建立一個單獨的數據通道，從一臺服務器送出的每個數據包只能傳送給一個客戶機，每個用戶必須分別對媒體服務器發送單獨的查詢，而服務器必須向每個用戶發送所申請的數據包拷貝。這種巨大冗余會造成服務器沉重和網絡帶寬的沉重負擔，響應需要很長時間，甚至出現不能服務的情況。單播可以用在點播和廣播上。
組播發送時，服務器將一組客戶請求的流媒體數據發送到支持組播技術的路由器上，然后由路由器一次將數據包根據路由表復制到多個通道上，再向用戶發送。這時候，媒體服務器只需要發送一個信息包，所有發出請求的客戶端都共享同一信息包，并且信息可以發送到任意地址的客戶機，沒有請求的客戶機不會收到信息包，網絡上傳輸的信息包的總量沒有廣播那么多，大大提高了服務器和網絡線路的利用率。不過組播也有自己的特點，首先是必須要開始支持組播技術的路由器，另外就是一般只能用作廣播，因為用作點播會存在用戶控制問題。
好了，說了這么多，您可能都嫌我煩了，那么，就讓我們開始架設流媒體服務器之旅吧。
