OSI七層模型
OSI 中的層 功能 TCP/IP協議族
應 用層 文件傳輸，電子郵件，文件服務，虛擬終 端 TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet
表示層 數據格式化，代碼轉換，數據加密 沒有協議
會話 層 解除或建立與別的接點的聯系 沒有協議
傳輸層 提供端對端的接口 TCP，UDP （RTP）
網 絡層 為數據包選擇路由 IP，ICMP，RIP，OSPF，BGP，IGMP
數據鏈路層 傳輸有地址的幀以及錯誤檢測功能 SLIP，CSLIP，PPP，ARP，RARP，MTU
物 理層 以二進制數據形式在物理媒體上傳輸數據 ISO2110，IEEE802，IEEE802.2
************************************************************************************************************************************
TCP/IP五層模型的協議
應用層
傳輸層：四層交換機、也有工作在四層的路由器
網絡層：路由器、三層交換機
數據鏈路層：網橋（現已很少使用）、以太網交換機（二層交換機）、網卡（其實網卡是一半工作在物理層、一半工作在數據鏈路層）
物理層：中繼器、集線器、還有我們通常說的雙絞線也工作在物理層
**************************************************************************************************************************************
一、RTP協議分析
1、 RTP概述
1.1. RTP是什麼
RTP全名是Real-time Transport Protocol（實時傳輸協議）。它是IETF提出的一個標准，對應的RFC文檔為RFC3550（RFC1889為其過期版本）。RFC3550不僅定義了RTP，而且定義了配套的相關協議RTCP（Real-time Transport Control Protocol，即實時傳輸控制協議）。RTP用來為IP網上的語音、圖像、傳真等多種需要實時傳輸的多媒體數據提供端到端的實時傳輸服務。RTP為Internet上端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量，服務質量由RTCP來提供。
1.2. RTP的應用環境
RTP用於在單播或多播網絡中傳送實時數據。它們典型的應用場合有如下幾個。
（1）簡單的多播音頻會議。語音通信通過一個多播地址和一對端口來實現。一個用於音頻數據（RTP），另一個用於控制包（RTCP）。
（2）音頻和視頻會議。如果在一次會議中同時使用了音頻和視頻會議，這兩種媒體將分別在不同的RTP會話中傳送，每一個會話使用不同的傳輸地址（IP地址＋端口）。如果一個用戶同時使用了兩個會話，則每個會話對應的RTCP包都使用規范化名字CNAME（Canonical Name）。與會者可以根據RTCP包中的CNAME來獲取相關聯的音頻和視頻，然後根據RTCP包中的計時信息(Network time protocol)來實現音頻和視頻的同步。
（3）翻譯器和混合器。翻譯器和混合器都是RTP級的中繼系統。翻譯器用在通過IP多播不能直接到達的用戶區，例如發送者和接收者之間存在防火牆。當與會者能接收的音頻編碼格式不一樣，比如有一個與會者通過一條低速鏈路接入到高速會議，這時就要使用混合器。在進入音頻數據格式需要變化的網絡前，混合器將來自一個源或多個源的音頻包進行重構，並把重構後的多個音頻合並，采用另一種音頻編碼進行編碼後，再轉發這個新的RTP包。從一個混合器出來的所有數據包要用混合器作為它們的同步源（SSRC，見RTP的封裝）來識別，可以通過貢獻源列表（CSRC表，見RTP的封裝）可以確認談話者。
1.3. 流媒體
流媒體是指Internet上使用流式傳輸技術的連續時基媒體。當前在Internet上傳輸音頻和視頻等信息主要有兩種方式：下載和流式傳輸兩種方式。
下載情況下，用戶需要先下載整個媒體文件到本地，然後才能播放媒體文件。在視頻直播等應用場合，由於生成整個媒體文件要等直播結束，也就是用戶至少要在直播結束後才能看到直播節目，所以用下載方式不能實現直播。
流式傳輸是實現流媒體的關鍵技術。使用流式傳輸可以邊下載邊觀看流媒體節目。由於Internet是基於分組傳輸的，所以接收端收到的數據包往往有延遲和亂序（流式傳輸構建在UDP上）。要實現流式傳輸，就是要從降低延遲和恢復數據包時序入手。在發送端，為降低延遲，往往對傳輸數據進行預處理（降低質量和高效壓縮）。在接收端為了恢復時序，采用了接收緩沖；而為了實現媒體的流暢播放，則采用了播放緩沖。
使用接收緩沖，可以將接收到的數據包緩存起來，然後根據數據包的封裝信息（如包序號和時戳等），將亂序的包重新排序，最後將重新排序了的數據包放入播放緩沖播放。
為什麼需要播放緩沖呢？容易想到，由於網絡不可能很理想，並且對數據包排序需要處理時耗，我們得到排序好的數據包的時間間隔是不等的。如果不用播放緩沖，那麼播放節目會很卡，這叫時延抖動。相反，使用播放緩沖，在開始播放時，花費幾十秒鐘先將播放緩沖填滿（例如PPLIVE），可以有效地消除時延抖動，從而在不太損失實時性的前提下實現流媒體的順暢播放。
到目前為止,Internet 上使用較多的流式視頻格式主要有以下三種:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。
上面在談接收緩沖時，說到了流媒體數據包的封裝信息（包序號和時戳等），這在後面的RTP封裝中會有體現。另外，RealMedia這些流式媒體格式只是編解碼有不同，但對於RTP來說，它們都是待封裝傳輸的流媒體數據而沒有什麼不同。
2、 RTP詳解
2.1. RTP的協議層次
2.1.1. 傳輸層的子層
RTP（實時傳輸協議），顧名思義它是用來提供實時傳輸的，因而可以看成是傳輸層的一個子層。圖 1給出了流媒體應用中的一個典型的協議體系結構。圖2給出了RTP協議與其他協議之間的關系。
圖1 流媒體體系結構
圖2 RTP協議與其他協議的關系
RTP、TCP、UDP都屬於傳輸層協議; RTP也可以認為是介於應用層與傳輸層之間
從圖中可以看出，RTP被劃分在傳輸層，它建立在UDP上。同UDP協議一樣，為了實現其實時傳輸功能，RTP也有固定的封裝形式。RTP用來為端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量。服務質量由RTCP來提供。
2.1.2. 應用層的一部分
不少人也把RTP歸為應用層的一部分，這是從應用開發者的角度來說的。操作系統中的TCP/IP等協議棧所提供的是我們最常用的服務，而RTP的實現還是要靠開發者自己。因此從開發的角度來說，RTP的實現和應用層協議的實現沒不同，所以可將RTP看成應用層協議。
RTP實現者在發送RTP數據時，需先將數據封裝成RTP包，而在接收到RTP數據包，需要將數據從RTP包中提取出來。
2.2. RTP的封裝
一個協議的封裝是為了滿足協議的功能需求的。從前面提出的功能需求，可以推測出RTP封裝中應該有同步源和時戳等字段，但更為完整的封裝是什麼樣子呢？請看圖3。
圖 3 RTP的頭部格式
版本號（V）：2比特，用來標志使用的RTP版本。
填充位（P）：1比特，如果該位置位，則該RTP包的尾部就包含附加的填充字節。
擴展位（X）：1比特，如果該位置位的話，RTP固定頭部後面就跟有一個擴展頭部。
CSRC計數器（CC）：4比特，含有固定頭部後面跟著的CSRC的數目。
標記位（M）：1比特,該位的解釋由配置文檔（Profile）來承擔.
載荷類型（PT）：7比特，標識了RTP載荷的類型。
序列號（SN）：16比特，發送方在每發送完一個RTP包後就將該域的值增加1，接收方可以由該域檢測包的丟失及恢復包序列。序列號的初始值是隨機的。
時間戳：32比特，記錄了該包中數據的第一個字節的采樣時刻。在一次會話開始時，時間戳初始化成一個初始值。即使在沒有信號發送時，時間戳的數值也要隨時間而不斷地增加（時間在流逝嘛）。時間戳是去除抖動和實現同步不可缺少的。
同步源標識符(SSRC)：32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。該標識符是隨機選取的 RFC1889推薦了MD5隨機算法。
貢獻源列表（CSRC List）：0～15項，每項32比特，用來標志對一個RTP混合器產生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的SSRC標識符插入表中。SSRC標識符都被列出來，以便接收端能正確指出交談雙方的身份。
2.3. RTCP的封裝
RTP需要RTCP為其服務質量提供保證，因此下面介紹一下RTCP的相關知識。
RTCP的主要功能是：服務質量的監視與反饋、媒體間的同步，以及多播組中成員的標識。在RTP會話期 間，各參與者周期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，各參與者可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。
從圖 1可以看到，RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組
表 1 RTCP的5種分組類型
上述五種分組的封裝大同小異，下面只講述SR類型，而其它類型請參考RFC3550。
發送端報告分組SR（Sender Report）用來使發送端以多播方式向所有接收端報告發送情況。SR分組的主要內容有：相應的RTP流的SSRC，RTP流中最新產生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的字節數。SR包的封裝如圖3所示。
圖 3 RTCP頭部的格式
版本（V）：同RTP包頭域。
填充（P）：同RTP包頭域。
接收報告計數器（RC）：5比特，該SR包中的接收報告塊的數目，可以為零。
包類型（PT）：8比特，SR包是200。
長度域（Length）：16比特，其中存放的是該SR包以32比特為單位的總長度減一。
同步源（SSRC）：SR包發送者的同步源標識符。與對應RTP包中的SSRC一樣。
NTP Timestamp（Network time protocol）SR包發送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。
RTP Timestamp：與NTP時間戳對應，與RTP數據包中的RTP時間戳具有相同的單位和隨機初始值。
Sender’s packet count：從開始發送包到產生這個SR包這段時間裡，發送者發送的RTP數據包的總數. SSRC改變時，這個域清零。
Sender`s octet count：從開始發送包到產生這個SR包這段時間裡，發送者發送的淨荷數據的總字節數（不包括頭部和填充）。發送者改變其SSRC時，這個域要清零。
同步源n的SSRC標識符：該報告塊中包含的是從該源接收到的包的統計信息。
丟失率（Fraction Lost）：表明從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP數據包的丟失率。
累計的包丟失數目：從開始接收到SSRC_n的包到發送SR,從SSRC_n傳過來的RTP數據包的丟失總數。
收到的擴展最大序列號：從SSRC_n收到的RTP數據包中最大的序列號，
接收抖動（Interarrival jitter）：RTP數據包接受時間的統計方差估計
上次SR時間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。
上次SR以來的延時（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到發送本報告的延時。
2.4. RTP的會話過程
當應用程序建立一個RTP會話時，應用程序將確定一對目的傳輸地址。目的傳輸地址由一個網絡地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數據能夠正確發送。RTP數據發向偶數的UDP端口，而對應的控制信號RTCP數據發向相鄰的奇數UDP端口（偶數的UDP端口＋1），這樣就構成一個UDP端口對。 RTP的發送過程如下，接收過程則相反。
1)RTP協議從上層接收流媒體信息碼流（如H.263），封裝成RTP數據包；RTCP從上層接收控制信息，封裝成RTCP控制包。
2)RTP將RTP 數據包發往UDP端口對中偶數端口；RTCP將RTCP控制包發往UDP端口對中的接收端口。
二、 TCP協議分析
1、 TCP協議簡介
TCP，全稱Transfer Control Protocol，中文名為傳輸控制協議，它工作在OSI的傳輸層，提供面向連接的可靠傳輸服務。
TCP的工作主要是建立連接，然後從應用層程序中接收數據並進行傳輸。TCP采用虛電路連接方式進行工作，在發送數據前它需要在發送方和接收方建立一個連接，數據在發送出去後，發送方會等待接收方給出一個確認性的應答，否則發送方將認為此數據丟失，並重新發送此數據。
2、TCP報頭
TCP報頭總長最小為20個字節，其報頭結構如下圖（圖1）所示；
比特0 比特15 比特16 比特31
源端口（16）
目的端口（16）
序列號（32）
確認號（32）
TCP偏移量（4）
保留（6）
標志（6）
窗口（16）
校驗和（16）
緊急（16）
選項（0或32）
數據（可變）
（圖1 TCP報頭結構）
源端口：指定了發送端的端口
目的端口：指定了接受端的端口號
序號：指明了段在即將傳輸的段序列中的位置
確認號：規定成功收到段的序列號，確認序號包含發送確認的一端所期望收到的下一個序號
TCP偏移量：指定了段頭的長度。段頭的長度取決與段頭選項字段中設置的選項
保留：指定了一個保留字段，以備將來使用
標志：SYN、ACK、PSH、RST、URG、FIN
SYN： 表示同步
ACK： 表示確認
PSH： 表示盡快的將數據送往接收進程
RST： 表示復位連接
URG： 表示緊急指針
FIN： 表示發送方完成數據發送
窗口：指定關於發送端能傳輸的下一段的大小的指令
校驗和：校驗和包含TCP段頭和數據部分，用來校驗段頭和數據部分的可靠性
緊急：指明段中包含緊急信息，只有當U R G標志置1時緊急指針才有效
選項：指定了公認的段大小，時間戳，選項字段的末端，以及指定了選項字段的邊界選項
3、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協議分析
1、UDP簡介
UDP協議是英文UserDatagramProtocol的縮寫，即用戶數據報協議，主要用來支持那些需要在計算機之間傳輸數據的網絡應用。包括網絡視頻會議系統在內的眾多的客戶/服務器模式的網絡應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協議所掩蓋，但是即使是在今天，UDP仍然不失為一項非常實用和可行的網絡傳輸層協議。
與我們所熟知的TCP（傳輸控制協議）協議一樣，UDP協議直接位於IP（網際協議）協議的頂層。根據OSI（開放系統互連）參考模型，UDP和TCP都屬於傳輸層協議。
UDP協議的主要作用是將網絡數據流量壓縮成數據報的形式。一個典型的數據報就是一個二進制數據的傳輸單位。每一個數據報的前8個字節用來包含報頭信息，剩余字節則用來包含具體的傳輸數據。
2、UDP協議結構
UDP報頭由4個域組成，其中每個域各占用2個字節，具體如下：
源端口號 、目標端口號 、數據報長度 和校驗值 。
UDP協議使用端口號為不同的應用保留其各自的數據傳輸通道。UDP和TCP協議正是采用這一機制實現對同一時刻內多項應用同時發送和接收數據的支持。數據發送一方（可以是客戶端或服務器端）將UDP數據報通過源端口發送出去，而數據接收一方則通過目標端口接收數據。有的網絡應用只能使用預先為其預留或注冊的靜態端口；而另外一些網絡應用則可以使用未被注冊的動態端口。因為UDP報頭使用兩個字節存放端口號，所以端口號的有效范圍是從0到65535。一般來說，大於49151的端口號都代表動態端口。
數據報的長度是指包括報頭和數據部分在內的總的字節數。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數據部分（又稱為數據負載）。數據報的最大長度根據操作環境的不同而各異。從理論上說，包含報頭在內的數據報的最大長度為65535字節。不過，一些實際應用往往會限制數據報的大小，有時會降低到8192字節。
UDP協議使用報頭中的校驗值來保證數據的安全。校驗值首先在數據發送方通過特殊的算法計算得出，在傳遞到接收方之後，還需要再重新計算。如果某個數據報在傳輸過程中被第三方篡改或者由於線路噪音等原因受到損壞，發送和接收方的校驗計算值將不會相符，由此UDP協議可以檢測是否出錯。這與TCP協議是不同的，後者要求必須具有校驗值。
四、三種協議對比
