2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

????HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。HTTP基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）。所有的www文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收html頁面的方法。1960年美國(guó)人Ted Nelson構(gòu)思了一種通過計(jì)算機(jī)處理文本信息的方法，并稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協(xié)議標(biāo)準(zhǔn)架構(gòu)的發(fā)展根基。

????RTSP（Real Time Streaming Protocol）,是一種實(shí)時(shí)流傳輸協(xié)議，是TCP/IP協(xié)議體系中的一個(gè)應(yīng)用層協(xié)議。作為一個(gè)應(yīng)用層協(xié)議，RTSP提供了一個(gè)可供擴(kuò)展的框架，它的意義在于使得實(shí)時(shí)流媒體數(shù)據(jù)的受控和點(diǎn)播變得可能。總的說來，RTSP是一個(gè)流媒體表示協(xié)議，主要用來控制具有實(shí)時(shí)特性的數(shù)據(jù)發(fā)送，但它本身并不傳輸數(shù)據(jù)，而是必須依賴于下層傳輸協(xié)議所提供的某些服務(wù)。RTSP可以對(duì)流媒體提供諸如播放、暫 停、快進(jìn)等操作，它負(fù)責(zé)定義具體的控制消息、操作方法、狀態(tài)碼等，此外還描述了與RTP間的交互操作（RFC2326）。

????RTMP協(xié)議是Real Time Message Protocol(實(shí)時(shí)信息傳輸協(xié)議)的縮寫，它是由Adobe公司提出的一種應(yīng)用層的協(xié)議，用來解決多媒體數(shù)據(jù)傳輸流的多路復(fù)用（Multiplexing）和分包（packetizing）的問題。特點(diǎn)如下：

適合長(zhǎng)時(shí)間播放：因?yàn)镽TMP支持的很完善，所以能做到flash播放RTMP流長(zhǎng)時(shí)間不斷流，當(dāng)時(shí)測(cè)試是100萬秒，即10天多可以連續(xù)播放。

對(duì)于商用流媒體應(yīng)用，客戶端的穩(wěn)定性當(dāng)然也是必須的，否則最終用戶看不了還怎么玩？我就知道有個(gè)教育客戶，最初使用播放器播放http流，需要播放不同的文件，結(jié)果就總出問題，?如果換成服務(wù)器端將不同的文件轉(zhuǎn)換成RTMP流，客戶端就可以一直播放；該客戶走RTMP方案后，經(jīng)過CDN分發(fā)，沒聽說客戶端出問題了。

延遲較低：比起YY的那種UDP私有協(xié)議，RTMP算延遲大的（延遲在1-3秒），比起HTTP流的延時(shí)（一般在10秒以上）RTMP算低延時(shí)。一般的直播應(yīng)用，只要不是電話類對(duì)話的那種要求，RTMP延遲是可以接受的。在一般的視頻會(huì)議應(yīng)用中，RTMP延時(shí)也能接受，原因是別人在說話的時(shí)候我們一般在聽，實(shí)際上1秒延時(shí)沒有關(guān)系，我們也要思考（話說有些人的CPU處理速度還沒有這么快）。

有累積延遲：技術(shù)一定要知道弱點(diǎn)，RTMP有個(gè)弱點(diǎn)就是累積誤差，原因是RTMP基于TCP不會(huì)丟包。?所以當(dāng)網(wǎng)絡(luò)狀態(tài)差時(shí)，服務(wù)器會(huì)將包緩存起來，導(dǎo)致累積的延遲；待網(wǎng)絡(luò)狀況好了，就一起發(fā)給客戶端。這個(gè)的對(duì)策就是，當(dāng)客戶端的緩沖區(qū)很大，就斷開重連。

????RTP數(shù)據(jù)協(xié)議負(fù)責(zé)對(duì)流媒體數(shù)據(jù)進(jìn)行封包并實(shí)現(xiàn)媒體流的實(shí)時(shí)傳輸，每一個(gè)RTP數(shù)據(jù)報(bào)都由頭部（Header）和負(fù)載（Payload）兩個(gè)部分組成，其中頭部前12個(gè)字節(jié)的含義是固定的，而負(fù)載則可以是音頻或者視頻數(shù)據(jù)。RTP用到的地方就是 PLAY ，服務(wù)器往客戶端傳輸數(shù)據(jù)用UDP協(xié)議，RTP是在傳輸數(shù)據(jù)的前面加了個(gè)12字節(jié)的頭(描述信息)。RTP載荷封裝設(shè)計(jì)本文的網(wǎng)絡(luò)傳輸是基于IP協(xié)議，所以最大傳輸單元(MTU)最大為1500字節(jié)，在使用IP／UDP／RTP的協(xié)議層次結(jié)構(gòu)的時(shí)候，這 其中包括至少20字節(jié)的IP頭，8字節(jié)的UDP頭，以及12字節(jié)的RTP頭。這樣，頭信息至少要占用40個(gè)字節(jié)，那么RTP載荷的最大尺寸為1460字 節(jié)。以H264 為例，如果一幀數(shù)據(jù)大于1460，則需要分片打包，然后到接收端再拆包，組合成一幀數(shù)據(jù)，進(jìn)行解碼播放。

????RTCP控制協(xié)議需要與RTP數(shù)據(jù)協(xié)議一起配合使用，當(dāng)應(yīng)用程序啟動(dòng)一個(gè)RTP會(huì)話時(shí)將同時(shí)占用兩個(gè)端口，分別供RTP和RTCP使用。RTP本身并 不能為按序傳輸數(shù)據(jù)包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負(fù)責(zé)完成。通常RTCP會(huì)采用與RTP相同的分發(fā)機(jī)制，向會(huì)話中的 所有成員周期性地發(fā)送控制信息，應(yīng)用程序通過接收這些數(shù)據(jù)，從中獲取會(huì)話參與者的相關(guān)資料，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息，從而能夠?qū)Ψ?wù)質(zhì)量進(jìn) 行控制或者對(duì)網(wǎng)絡(luò)狀況進(jìn)行診斷。

????RTCP協(xié)議的功能是通過不同的RTCP數(shù)據(jù)報(bào)來實(shí)現(xiàn)的，主要有如下幾種類型：

• SR：發(fā)送端報(bào)告，所謂發(fā)送端是指發(fā)出RTP數(shù)據(jù)報(bào)的應(yīng)用程序或者終端，發(fā)送端同時(shí)也可以是接收端。(SERVER定時(shí)間發(fā)送給CLIENT)。
• RR：接收端報(bào)告，所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報(bào)的應(yīng)用程序或者終端。(SERVER接收CLIENT端發(fā)送過來的響應(yīng))。
• SDES：源描述，主要功能是作為會(huì)話成員有關(guān)標(biāo)識(shí)信息的載體，如用戶名、郵件地址、電話號(hào)碼等，此外還具有向會(huì)話成員傳達(dá)會(huì)話控制信息的功能。
• BYE：通知離開，主要功能是指示某一個(gè)或者幾個(gè)源不再有效，即通知會(huì)話中的其他成員自己將退出會(huì)話。
• APP：由應(yīng)用程序自己定義，解決了RTCP的擴(kuò)展性問題，并且為協(xié)議的實(shí)現(xiàn)者提供了很大的靈活性。

簡(jiǎn)單來說：

HTTP: ?即超文本傳送協(xié)議(ftp即文件傳輸協(xié)議)。

RTSP: （Real Time Streaming Protocol），實(shí)時(shí)流傳輸協(xié)議。

RTMP: 全稱Routing Table Maintenance Protocol（路由選擇表維護(hù)協(xié)議）。

HTTP將所有的數(shù)據(jù)作為文件做處理。http協(xié)議不是流媒體協(xié)議。RTMP和RTSP協(xié)議是流媒體協(xié)議。

?

這里再提一下于流媒體有關(guān)的知識(shí)：

GOP-Cache

什么是GOP？就是視頻流中兩個(gè)I幀的時(shí)間距離。
GOP有什么影響？
Flash（解碼器）只有拿到GOP才能開始解碼播放。
也就是說，服務(wù)器一般先給一個(gè)I幀給Flash。
可惜問題來了，假設(shè)GOP是10秒，也就是每隔10秒才有關(guān)鍵幀，
如果用戶在第5秒時(shí)開始播放，會(huì)怎么樣？
第一種方案：等待下一個(gè)I幀，
也就是說，再等5秒才開始給客戶端數(shù)據(jù)。
這樣延遲就很低了，總是實(shí)時(shí)的流。
問題是：等待的這5秒，會(huì)黑屏，現(xiàn)象就是播放器卡在那里，什么也沒有，
有些用戶可能以為死掉了，就會(huì)刷新頁面。
總之，某些客戶會(huì)認(rèn)為等待關(guān)鍵幀是個(gè)不可饒恕的錯(cuò)誤，延時(shí)有什么關(guān)系？
我就希望能快速啟動(dòng)和播放視頻，最好打開就能放！

第二種方案：馬上開始放，
放什么呢？
你肯定知道了，放前一個(gè)I幀。
也就是說，服務(wù)器需要總是cache一個(gè)gop，
這樣客戶端上來就從前一個(gè)I幀開始播放，就可以快速啟動(dòng)了。
問題是：延遲自然就大了。

有沒有好的方案？
有！至少有兩種：
編碼器調(diào)低GOP，譬如0.5秒一個(gè)GOP，這樣延遲也很低，也不用等待。
壞處是編碼器壓縮率會(huì)降低，圖像質(zhì)量沒有那么好。

?

轉(zhuǎn)載于:https://my.oschina.net/u/3490860/blog/1616593

總結(jié)

以上是生活随笔為你收集整理的HTTP RTSP RTMP RTP 协议简说 流媒体学习（一）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。