HTTP協議 RTSP協議 RTMP協議的區別

rtsp、 rtmp、http的共同點、區別

共同點：

1：rtsp rtmp http都是在應用應用層。

區別：1：http：即超文字傳送協議(ftp即檔案傳輸協議)。

rtsp：（real time streaming protocol），實時流傳輸協議。

rtmp：routing table maintenance protocol（路由選擇表維護協議）。

2：http將所有的資料作為檔案做處理。http協議不是流**協議。

rtmp和rtsp協議是流**協議。

3：rtmp協議是adobe的私有協議,未完全公開，rtsp協議和http協議是共有協議，並有專門機構做維護。

4：rtmp協議一般傳輸的是flv，f4v格式流，rtsp協議一般傳輸的是ts,mp4格式的流。http沒有特定的流。

5：rtsp傳輸一般需要2-3個通道，命令和資料通道分離，http和rtmp一般在tcp乙個通道上傳輸命令和資料。

rtsp、rtcp、rtp區別

1：rtsp實時流協議

2：rtcp控制協議

rtcp控制協議需要與rtp資料協議一起配合使用，當應用程式啟動乙個rtp會話時將同時占用兩個埠，分別供rtp和rtcp使用。rtp本身並不能為按序傳輸資料報提供可靠的保證，也不提供流量控制和擁塞控制，這些都由rtcp來負責完成。通常rtcp會採用與rtp相同的分發機制，向會話中的所有成員周期性地傳送控制資訊，應用程式通過接收這些資料，從中獲取會話參與者的相關資料，以及網路狀況、分組丟失概率等反饋資訊，從而能夠對服務質量進行控制或者對網路狀況進行診斷。

rtcp協議的功能是通過不同的rtcp資料報來實現的，主要有如下幾種型別：

sr：傳送端報告，所謂傳送端是指發出rtp資料報的應用程式或者終端，傳送端同時也可以是接收端。(server定時間傳送給client)。

rr：接收端報告，所謂接收端是指僅接收但不傳送rtp資料報的應用程式或者終端。(server接收client端傳送過來的響應)。

bye：通知離開，主要功能是指示某乙個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。

3：rtp資料協議

rtp用到的地方就是 play ，伺服器往客戶端傳輸資料用udp協議，rtp是在傳輸資料的前面加了個12位元組的頭(描述資訊)。

直播應用中，rtmp和hls基本上可以覆蓋所有客戶端**，

hls主要是延時比較大，rtmp主要優勢在於延時低。

主要有人老是問這個問題，如何降低hls延遲。

hls解決延時，就像是爬到楓樹上去捉魚，奇怪的是還有人喊，看那，有魚。

你說是怎麼回事?

我只能說你在參與謙哥的魔術表演，錯覺罷了。

如果你真的確信有，請用實際測量的來展示出來，參考下面延遲的測量。

如何測量延時，是個很難的問題，

不過有個行之有效的方法，就是用手機的秒錶，可以比較精確的對比延時。

經過測量發現，在網路狀況良好時：

. rtmp延時可以做到0.8秒左右。

. 多級邊緣節點不會影響延遲（和srs同源的某cdn的邊緣伺服器可以做到）

. nginx-rtmp延遲有點大，估計是快取的處理，多程序通訊導致？

. gop是個硬指標，不過srs可以關閉gop的cache來避免這個影響.

. 伺服器效能太低，也會導致延遲變大，伺服器來不及傳送資料。

. 客戶端的緩衝區長度也影響延遲。

譬如flash客戶端的netstream.buffertime設定為10秒，那麼延遲至少10秒以上。

除了gop-cache，還有乙個有關係，就是累積延遲。

伺服器可以配置直播佇列的長度，伺服器會將資料放在直播佇列中，

如果超過這個長度就清空到最後乙個i幀：

當然這個不能配置太小，

譬如gop是1秒，queue_length是1秒，這樣會導致有1秒資料就清空，會導致跳躍。

有更好的方法？有的。

延遲基本上就等於客戶端的緩衝區長度，因為延遲大多由於網路頻寬低，

伺服器快取後一起發給客戶端，現象就是客戶端的緩衝區變大了，

譬如netstream.bufferlength=5秒，那麼說明緩衝區中至少有5秒資料。

處理累積延遲的最好方法，是客戶端檢測到緩衝區有很多資料了，如果可以的話，就重連伺服器。

當然如果網路一直不好，那就沒有辦法了。

HTTP協議 RTSP協議 RTMP協議的區別

RTSP協議 RTMP協議 HTTP協議的區別

HTTP協議 RTSP協議 RTMP協議的區別

HTTP協議 RTSP協議 RTMP協議的區別

相關推薦