| OSI中的層 | 功能 | TCP/IP協議族 |
| 應用層 | 文件傳輸，電子郵件，文件服務，虛擬終端 | TFTP,FTP,HTTP,SNMP,SMTP,DNS,RIP,Telnet |
| 表示層 | 數據格式化，代碼轉換，數據加密 | 無 |
| 會話層 | 解除或創建與別的結點的聯繫 | 無 |
| 傳輸層 | 提供端對端的接口 | TCP,UDP |
| 網絡層 | 爲數據包選擇路由 | IP,ICMP,OSPF,BGP,IGMP,ARP,RARP |
| 數據鏈路層 | 傳輸有地址的幀以及錯誤檢測功能 | SLIP,CSIP,PPP,MTU,ARP,RARP |
| 物理層 | 以二進制的數據形式在物理媒體上傳輸數據 | ISO2110,IEEE802,IEEE802.2 |
本文摘抄自：html
https://www.cnblogs.com/imystr/p/4026639.html安全
http://blog.csdn.net/fireroll/article/details/50725183服務器
1、RTP/RTCP協議網絡
RTP協議 框架
RTP全名是Real-time Transport Protocol（實時傳輸協議）。ide
它是IETF（國際互聯網工程任務組：The Internet Engineering Task Force）提出的一個標準，對應的RFC文檔爲RFC3550（RFC1889爲其過時版本）。RFC3550不只定義了RTP，並且定義了配套的相關協議RTCP（Real-time Transport Control Protocol，即實時傳輸控制協議）。RTP用來爲IP網上的語音、圖像、傳真等多種須要實時傳輸的多媒體數據提供端到端的實時傳輸服務。RTP爲Internet上端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量，服務質量由RTCP來提供。性能
RTP的應用環境編碼
（1）簡單的多播音頻會議。語音通訊經過一個多播地址和一對端口來實現。一個用於音頻數據（RTP），另外一個用於控制包（RTCP）。加密
（2）音頻和視頻會議。若是在一次會議中同時使用了音頻和視頻會議，這兩種媒體將分別在不一樣的RTP會話中傳送，每個會話使用不一樣的傳輸地址（IP地址＋端口）。若是一個用戶同時使用了兩個會話，則每一個會話對應的RTCP包都使用規範化名字CNAME（Canonical Name）。與會者能夠根據RTCP包中的CNAME來獲取相關聯的音頻和視頻，而後根據RTCP包中的計時信息(Network time protocol)來實現音頻和視頻的同步。spa
（3）翻譯器和混合器。翻譯器和混合器都是RTP級的中繼系統。翻譯器用在經過IP多播不能直接到達的用戶區，例如發送者和接收者之間存在防火牆。當與會者能接收的音頻編碼格式不同，好比有一個與會者經過一條低速鏈路接入到高速會議，這時就要使用混合器。在進入音頻數據格式須要變化的網絡前，混合器未來自一個源或多個源的音頻包進行重構，並把重構後的多個音頻合併，採用另外一種音頻編碼進行編碼後，再轉發這個新的RTP包。從一個混合器出來的全部數據包要用混合器做爲它們的同步源（SSRC，見RTP的封裝）來識別，能夠經過貢獻源列表（CSRC表，見RTP的封裝）能夠確認談話者。
RTCP協議
實時傳輸控制協議(Real-time ControlProtocol，RTCP)與RTP共同定義在1996年提出的RFC 1889中，是和RTP一塊兒工做的控制協議。RTCP單獨運行在低層協議上，由低層協議提供數據與控制包的複用。在RTP會話期間，每一個會話參與者週期性地向全部其餘參與者發送RTCP控制信息包。對於RTP會話或者廣播，一般使用單個多目標廣播地址，屬於這個會話的全部RTP和RTCP信息包都使用這個多目標廣播地址，經過使用不一樣的端口號可把RTP信息包和RTCP信息包區分開來。
是實時傳輸協議（RTP）的一個姐妹協議。RTCP爲RTP媒體流提供信道外（out-of-band）控制。RTCP自己並不傳輸數據，但和RTP一塊兒協做將多媒體數據打包和發送。RTCP按期在流多媒體會話參加者之間傳輸控制數據。RTCP的主要功能是爲RTP所提供的服務質量（Quality of Service）提供反饋。
RTCP執行下列四大功能：
(1) 主要是提供數據發佈的質量反饋。RTCP是做爲RTP傳輸協議的一部分，與其餘傳輸協議的流和阻塞控制有關。反饋對自適應編碼控制直接起做用，但IP多播經驗代表，從發送者收到反饋對診斷髮送錯誤是相當重要的。給全部參加者發送接收反饋報告容許問題觀察者估計那些問題是局部的，仍是全局的。諸如IP多播等發佈機制使網絡服務提供商之類的團體可能接收反饋信息，充當第三方監控者來診斷網絡問題。反饋功能由RTCP發送者和接收者報告執行。
(2)RTCP帶有稱做規範名字(CNAME)的RTP源持久傳輸層標識。如發現衝突，或程序從新啓動，既然SSRC標識可改變，接收者須要CNAME跟蹤參加者。接收者也須要CNAME與相關RTP鏈接中給定的幾個數據流聯繫。
(3)前兩種功能要求全部參加者發送RTCP包，所以，爲了RTP擴展到大規模數量，速率必須受到控制。讓每一個參加者給其餘參加者發送控制包，就加大獨立觀察參加者數量。該數量用於計算包發送的速率。
(4)可選功能是傳送最小鏈接控制信息，如辨識參加者。最可能用在「鬆散控制」鏈接，那裏參加者自由進入或離開，沒有成員控制或參數協調，RTCP充當通往全部參加者的方便通道，但沒必要支持應用的全部控制通信要求。
在IP多播場合應用RTP時，前三個功能是必須的，推薦用於全部情形。RTP應用設計人員必須避免使用僅在單播模式下工做的機制，那將致使沒法擴展規模。
2、RTP/RTCP與其餘協議之間的關係
流媒體體系結構圖
RTP協議與其餘協議的關係
RTP、TCP、UDP都屬於傳輸層協議；RTP也能夠認爲是介於應用層與傳輸層之間
從圖中能夠看出，RTP被劃分在傳輸層，它創建在UDP上。同UDP協議同樣，爲了實現其實時傳輸功能，RTP也有固定的封裝形式。RTP用來爲端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量。服務質量由RTCP來提供。
3、RTMP協議
RTMP(Real Time Messaging Protocol)實時消息傳送協議，是Adobe Systems公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議。
它有三種變種：
1)工做在TCP之上的明文協議，使用端口1935；
2)RTMPT封裝在HTTP請求之中，可穿越防火牆；
3)RTMPS相似RTMPT，但使用的是HTTPS鏈接；
RTMP協議是被Flash用於對象,視頻,音頻的傳輸.這個協議創建在TCP協議或者輪詢HTTP協議之上；
RTMP協議就像一個用來裝數據包的容器,這些數據既能夠是AMF格式的數據,也能夠是FLV中的視/音頻數據；
一個單一的鏈接能夠經過不一樣的通道傳輸多路網絡流.這些通道中的包都是按照固定大小的包傳輸的；
4、SRTP與SRTCP 協議
參考文檔 RFC3711
安全實時傳輸協議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協議（Real-time Transport Protocol或RTP）基礎上所定義的一個協議，旨在爲單播和多播應用程序中的實時傳輸協議的數據提供加密、消息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發的，並最先由IETF於2004年3月做爲RFC3711發佈。因爲實時傳輸協議和能夠被用來控制實時傳輸協議的會話的實時傳輸控制協議（RTP Control Protocol或RTCP）有着緊密的聯繫，安全實時傳輸協議一樣也有一個伴生協議，它被稱爲安全實時傳輸控制協議（Secure RTCP或SRTCP）；安全實時傳輸控制協議爲實時傳輸控制協議提供相似的與安全有關的特性，就像安全實時傳輸協議爲實時傳輸協議提供的那些同樣。
在使用實時傳輸協議或實時傳輸控制協議時，使不使用安全實時傳輸協議或安全實時傳輸控制協議是可選的；但即便使用了安全實時傳輸協議或安全實時傳輸控制協議，全部它們提供的特性（如加密和認證）也都是可選的，這些特性能夠被獨立地使用或禁用。惟一的例外是在使用安全實時傳輸控制協議時，必需要用到其消息認證特性。
5、RTSP協議
參考文檔 RFC2326
實時流傳輸協議（Real Time Streaming Protocol）是用來控制聲音或影像的多媒體串流協議，並容許同時多個串流需求控制，傳輸時所用的網絡通信協定並不在其定義的範圍內，服務器端能夠自行選擇使用TCP或UDP來傳送串流內容，它的語法和運做跟HTTP 1.1相似，但並不特別強調時間同步，因此比較能容忍網絡延遲。而前面提到的容許同時多個串流需求控制（Multicast），除了能夠下降服務器端的網絡用量，更進而支持多方視訊會議（Video Conference）。由於與HTTP1.1的運做方式類似，因此代理服務器《Proxy》的快取功能《Cache》也一樣適用於RTSP，並因RTSP具備從新導向功能，可視實際負載狀況來轉換提供服務的服務器，以免過大的負載集中於同一服務器而形成延遲。
是由Real Networks和Netscape共同提出的。該協議定義了一對多應用程序如何有效地經過IP網絡傳送多媒體數據。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控、點播成爲可能。數據源包括現場數據與存儲在剪輯中的數據。
該協議目的在於控制多個數據發送鏈接，爲選擇發送通道，如UDP、多播UDP與TCP提供途徑，併爲選擇基於RTP上發送機制提供方法。
RTSP和RTP的關係
RTP不象http和ftp可完整的下載整個影視文件，它是以固定的數據率在網絡上發送數據，客戶端也是按照這種速度觀看影視文件，當影視畫面播放事後，就不能夠再重複播放，除非從新向服務器端要求數據。
RTSP與RTP最大的區別在於：RTSP是一種雙向實時數據傳輸協議，它容許客戶端向服務器端發送請求，如回放、快進、倒退等操做。
固然，RTSP可基於RTP來傳送數據，還能夠選擇TCP、UDP、組播UDP等通道來發送數據，具備很好的擴展性。
它時一種相似與http協議的網絡應用層協議。
RTP：實時傳輸協議（Real-time Transport Protocol）
RTP/RTCP是實際傳輸數據的協議；
RTP傳輸音頻/視頻數據，若是是PLAY，Server發送到Client端，若是是RECORD，能夠由Client發送到Server整個RTP協議由兩個密切相關的部分組成：RTP數據協議和RTP控制協議（即RTCP）；
RTCP：RTCP包括Sender Report和Receiver Report，用來進行音頻/視頻的同步以及其餘用途，是一種控制協議；
RTSP：實時流協議（Real Time Streaming Protocol，RTSP）
RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義能夠知道起對話和控制做用；
RTSP的對話過程當中SETUP能夠肯定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN能夠開始或者中止RTP的發送，等等；
6、TCP與UDP協議
TCP協議
TCP，全稱Transfer Control Protocol，中文名爲傳輸控制協議，它工做在OSI的傳輸層，提供面向鏈接的可靠傳輸服務。
TCP的工做主要是創建鏈接，而後從應用層程序中接收數據並進行傳輸。TCP採用虛電路鏈接方式進行工做，在發送數據前它須要在發送方和接收方創建一個鏈接，數據在發送出去後，發送方會等待接收方給出一個確認性的應答，不然發送方將認爲此數據丟失，並從新發送此數據。
TCP報頭
TCP報頭總長最小爲20個字節，其報頭結構以下圖所示；
比特0 比特15 比特16 比特31
| 源端口（16） |
目的端口（16） |
||
| 序列號（32） |
|||
| 確認號（32） |
|||
| TCP偏移量（4） |
保留（6） |
標誌（6） |
窗口（16） |
| 校驗和（16） |
緊急（16） |
||
| 選項（0或32） |
|||
| 數據（可變） |
|||
源端口：指定了發送端的端口
目的端口：指定了接受端的端口號
序號：指明瞭段在即將傳輸的段序列中的位置
確認號：規定成功收到段的序列號，確認序號包含發送確認的一端所指望收到的下一個序號
TCP偏移量：指定了段頭的長度。段頭的長度取決與段頭選項字段中設置的選項
保留：指定了一個保留字段，以備未來使用
標誌：SYN、ACK、PSH、RST、URG、FIN
SYN： 表示同步
ACK： 表示確認
PSH： 表示儘快的將數據送往接收進程
RST： 表示復位鏈接
URG： 表示緊急指針
FIN： 表示發送方完成數據發送
窗口：指定關於發送端能傳輸的下一段的大小的指令
校驗和：校驗和包含TCP段頭和數據部分，用來校驗段頭和數據部分的可靠性
緊急：指明段中包含緊急信息，只有當U R G標誌置1時緊急指針纔有效
選項：指定了公認的段大小，時間戳，選項字段的末端，以及指定了選項字段的邊界選項
TCP工做原理
TCP鏈接創建：TCP的鏈接創建過程又稱爲TCP三次握手。首先發送方主機向接收方主機發起一個創建鏈接的同步（SYN）請求；接收方主機在收到這個請求後向送方主機回覆一個同步/確認（SYN/ACK）應答；發送方主機收到此包後再向接收方主機發送一個確認（ACK），此時TCP鏈接成功創建；
TCP鏈接關閉：發送方主機和目的主機創建TCP鏈接並完成數據傳輸後，會發送一個將結束標記置1的數據包，以關閉這個TCP鏈接，並同時釋放該鏈接佔用的緩衝區空間； TCP重置：TCP容許在傳輸的過程當中忽然中斷鏈接，這稱爲TCP重置；
TCP數據排序和確認：TCP是一種可靠傳輸的協議，它在傳輸的過程當中使用序列號和確認號來跟蹤數據的接收狀況；
TCP重傳：在TCP的傳輸過程當中，若是在重傳超時時間內沒有收到接收方主機對某數據包的確認回覆，發送方主機就認爲此數據包丟失，並再次發送這個數據包給接收方，這稱爲TCP重傳；
TCP延遲確認：TCP並不老是在接收到數據後當即對其進行確認，它容許主機在接收數據的同時發送本身的確認信息給對方。
TCP數據保護（校驗和）：TCP是可靠傳輸的協議，它提供校驗和計算來實現數據在傳輸過程當中的完整性。
UDP協議
UDP協議是英文UserDatagramProtocol的縮寫，即用戶數據報協議，主要用來支持那些須要在計算機之間傳輸數據的網絡應用。包括網絡視頻會議系統在內的衆多的客戶/服務器模式的網絡應用都須要使用UDP協議。UDP協議從問世至今已經被使用了不少年，雖然其最初的光彩已經被一些相似協議所掩蓋，可是即便是在今天，UDP仍然不失爲一項很是實用和可行的網絡傳輸層協議。
與咱們所熟知的TCP（傳輸控制協議）協議同樣，UDP協議直接位於IP（網際協議）協議的頂層。根據OSI（開放系統互連）參考模型，UDP和TCP都屬於傳輸層協議。
UDP協議的主要做用是將網絡數據流量壓縮成數據報的形式。一個典型的數據報就是一個二進制數據的傳輸單位。每個數據報的前8個字節用來包含報頭信息，剩餘字節則用來包含具體的傳輸數據。
7、RTP/RTCP、RTMP、TCP、UDP協議對比
TCP爲點對點的協議，這意味着各個客戶須要分開客戶機/服務器連接，於是沒法在網絡級實現對多個客戶機的數據廣播。若是有一個數據流必須同時被傳送到多個客戶機，服務器必須傳送數據流的副本到各個客戶機，TCP可以根據網絡帶寬和擁擠程度動態地調節傳送速度並從新發送丟失的數據包，這樣雖然保證了數據傳輸的可靠性，可是對服務器資源耗費較大，在數據流大的場合難以保證數據流傳輸的實時性。
UDP爲不可靠傳輸協議，在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度，計算機的能力和傳輸帶寬的限制；在接收端，UDP把每一個消息段放在隊列中，應用程序每次從隊列中讀一個消息段；UDP協議不須要維護鏈接狀態，也不認爲每一個數據包都必須到達接受端，所以網絡負荷比TCP小，傳輸速度也要比TCP快；但在網絡越擁擠時，越有更多的數據包丟失。
UDP和TCP協議的主要區別是二者在如何實現信息的可靠傳遞方面不一樣。TCP協議中包含了專門的傳遞保證機制，當數據接收方收到發送方傳來的信息時，會自動向發送方發出確認消息；發送方只有在接收到該確認消息以後才繼續傳送其它信息，不然將一直等待直到收到確認信息爲止。
因此TCP比UDP多了創建鏈接的時間。相對UDP而言，TCP具備更高的安全性和可靠性。TCP協議傳輸的大小不限制，一旦鏈接被創建，雙方能夠按照必定的格式傳輸大量的數據，而UDP是一個不可靠的協議，大小有限制，每次不能超過64K。
相對於TCP協議，UDP協議的另一個不一樣之處在於如何接收突法性的多個數據報。不一樣於TCP，UDP並不能確保數據的發送和接收順序。
RTP位於UDP之上，UDP雖然沒有TCP那麼可靠，而且沒法保證明時業務的服務質量，須要RTCP實時監控數據傳輸和服務質量，可是，因爲UDP的傳輸時延低於TCP，能與視頻和音頻很好匹配。所以，在實際應用中，RTP/RTCP/UDP用於音頻/視頻媒體，而TCP用於數據和控制信令的傳輸。
三者的性能對比見表。
|
協議名稱 |
複雜性 |
鏈接建 立時間 |
可靠性 |
是否確保數據報發送和接受順序 |
實時性 |
適用範圍 |
是否支持組播
|
| RTP/RTCP |
低 |
少 |
低 |
否 |
是 |
實時音視 頻媒體傳輸 |
支持 |
| TCP |
高 |
多 |
高 |
是 |
否 |
數據和控制信令傳輸 |
不支持 |
| UDP |
低 |
少 |
低 |
否 |
否 |
音視頻媒體傳輸 |
支持
|
RTMP協議是一個專門爲高效傳輸視頻，音頻和數據而設計的協議。它經過創建一個二進制TCP鏈接或者鏈接HTTP隧道實現實時的視頻和聲音傳輸。
RTMP比傳統媒介服務器流出的媒介協議支持更多。它支持可能包含聲音，影像和腳本數據從服務器到客戶和從客戶到服務器多條線路的動態傳輸。RTMP對聲音、影像和腳本數據分別處理。
聲音和視頻數據被分開地緩衝在服務器中。若是聲音數據在聲音緩衝器中達到某一極限，全部在緩衝器中的數據將被丟掉，而且最近到達的數據被容許開始收集在緩衝中並被送到各個客戶。視頻數據被以類似的方式處理，不一樣是當新的關鍵幀到達時，緩衝器中數據才被清除。在丟掉舊的幀數據時，若是發現客戶端的數據有誤，則將新舊兩個不一樣的幀進行擬合。
RTMP對數據給予不一樣的優先級別。在實時交談中，聲音是最重要的，影像給予低優先級，而腳本數據被給予的優先權介於聲音和影像中間。
RTMP協議能夠建立多個數據流，可是每一個數據流只能有一個方向。使用RTMP能夠構建這樣的一個系統，客戶端能夠同時與RTMP服務器和應用服務器進行交互，使得服務端的負荷得以分散，雖然在這種改進的系統結構中，RTMP服務器的性能要求比較高。
8、其餘協議
HTTP協議，全稱HyperText Transfer Protocol，中文名爲超文本傳輸協議；
MMS協議，全稱Microsoft Media Server Protocol，中文名爲微軟媒體服務器協議；
HLS協議，全稱HTTP Live Streaming， 是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議；