[計算機網絡]IP、UDP、TCP和HTTP報文格式總結

OSI七層參考模型：

詳細OSI七層參考模型解析博客

報文封裝過程

物理層、數據鏈路層、網絡層代表設備

物理層：網卡，網線，集線器，中繼器，調制解調器

數據鏈路層：網橋，交換機

網絡層：路由器

網關工作在第四層傳輸層及其以上

集線器是物理層設備,采用廣播的形式來傳輸信息。

交換機就是用來進行報文交換的機器。多為鏈路層設備(二層交換機)，能夠進行地址學習，采用存儲轉發的形式來交換報文.。

路由器的一個作用是連通不同的網絡，另一個作用是選擇信息傳送的線路。選擇通暢快捷的近路，能大大提高通信速度，減輕網絡系統通信負荷，節約網絡系統資源，提高網絡系統暢通率。

交換機和路由器的區別

交換機擁有一條很高帶寬的背部總線和內部交換矩陣。交換機的所有的端口都掛接在這條總線上，控制電路收到數據包以后，處理端口會查找內存中的地址對照表以確定目的MAC（網卡的硬件地址）的NIC（網卡）掛接在哪個端口上，通過內部交換矩陣迅速將數據包傳送到目的端口，目的MAC若不存在則廣播到所有的端口，接收端口回應后交換機會“學習”新的地址，並把它添加入內部MAC地址表中。
使用交換機也可以把網絡“分段”，通過對照MAC地址表，交換機只允許必要的網絡流量通過交換機。通過交換機的過濾和轉發，可以有效的隔離廣播風暴，減少誤包和錯包的出現，避免共享沖突。
交換機在同一時刻可進行多個端口對之間的數據傳輸。每一端口都可視為獨立的網段，連接在其上的網絡設備獨自享有全部的帶寬，無須同其他設備競爭使用。當節點A向節點D發送數據時，節點B可同時向節點C發送數據，而且這兩個傳輸都享有網絡的全部帶寬，都有着自己的虛擬連接。假使這里使用的是10Mbps的以太網交換機，那么該交換機這時的總流通量就等於2×10Mbps＝20Mbps，而使用10Mbps的共享式HUB時，一個HUB的總流通量也不會超出10Mbps。
總之，交換機是一種基於MAC地址識別，能完成封裝轉發數據包功能的網絡設備。交換機可以“學習”MAC地址，並把其存放在內部地址表中，通過在數據幀的始發者和目標接收者之間建立臨時的交換路徑，使數據幀直接由源地址到達目的地址。

路由器的作用與交換機和網橋非常相似。但是與工作在網絡物理層，從物理上划分網段的交換機不同，路由器使用專門的軟件協議從邏輯上對整個網絡進行划分。例如，一台支持IP協議的路由器可以把網絡划分成多個子網段，只有指向特殊IP地址的網絡流量才可以通過路由器。對於每一個接收到的數據包，路由器都會重新計算其校驗值，並寫入新的物理地址。因此，使用路由器轉發和過濾數據的速度往往要比只查看數據包物理地址的交換機慢。但是，對於那些結構復雜的網絡，使用路由器可以提高網絡的整體效率。路由器的另外一個明顯優勢就是可以自動過濾網絡廣播。

集線器與路由器在功能上有什么不同?

首先說HUB,也就是集線器。它的作用可以簡單的理解為將一些機器連接起來組成一個局域網。而交換機（又名交換式集線器）作用與集線器大體相同。但是兩者在性能上有區別：集線器采用的式共享帶寬的工作方式，而交換機是獨享帶寬。這樣在機器很多或數據量很大時，兩者將會有比較明顯的。而路由器與以上兩者有明顯區別，它的作用在於連接不同的網段並且找到網絡中數據傳輸最合適的路徑。路由器是產生於交換機之后，就像交換機產生於集線器之后，所以路由器與交換機也有一定聯系，不是完全獨立的兩種設備。路由器主要克服了交換機不能路由轉發數據包的不足。

IP

IP數據報格式

IP數據報分為兩個部分，首部和數據部分（TCP、UDP），首部分為固定部分和可變部分。

IPv4

IPv4分類地址

特殊IP地址

IPv6

IPv6數據報格式


IPv4與 IPv6區別

TCP

UDP

UDP首部格式

UDP實現可靠傳輸

三種使用UDP進行可靠數據傳輸的協議
RUDP、RTP、UDT

RUDP（Reliable User Datagram Protocol）

可靠用戶數據報協議（RUDP）是一種基於可靠數據協議（RDP： RFC908 和 1151 （第二版））的簡單分組傳輸協議。作為一個可靠傳輸協議，RUDP 用於傳輸 IP 網絡間的電話信號。它允許獨立配置每個連接屬性，這樣在不同的平台可以同時實施不同傳輸需求下的協議。

RUDP 提供一組數據服務質量增強機制，如擁塞控制的改進、重發機制及淡化服務器算法等，從而在包丟失和網絡擁塞的情況下， RTP 客戶機（實時位置）面前呈現的就是一個高質量的 RTP 流。在不干擾協議的實時特性的同時，可靠 UDP 的擁塞控制機制允許 TCP 方式下的流控制行為。

為了與網絡 TCP 通信量同時工作， RUDP 使用類似於 TCP 的重發機制和擁塞控制算法。在最大化利用可用帶寬上，這些算法都得到了很好的證明。
RUDP特性

客戶機確認響應服務器發送給客戶機的包；

視窗和擁塞控制，服務器不能超出當前允許帶寬；
一旦發生包丟失，服務器重發給客戶機；
比實時流更快速，稱為“緩存溢出”。
用戶數據報協議（UDP）

RTP（Real Time Protocol）

RTP，實時協議被用來為應用程序如音頻，視頻等的實時數據的傳輸提供端到端（end to end）的網絡傳輸功能。傳輸的模型可以是單點傳送或是多點傳送。數據傳輸被一個姐妹協議——實時控制協議（RTCP）來監控，后者允許在一個大的多點傳送網絡上監視數據傳送，並且提供最小限度的控制和識別功能。

RTP是被IETF在RFC1889中提出來的。順帶提及，RTP已經被接受為實時多媒體傳送的通用標准。ITU-T跟IETF都在各自的系統中將這一協議標准化。

1.1 為何需要RTP?

TCP不能支持像交互視頻，會議等的實時服務，這一原因是由於TCP只是一個“慢”協議，需要三次握手。就此在IP層上UDP是一個比TCP更好的選擇。但是UDP是本質上是一個不可靠協議，不支持在包丟情況下的重傳機制。誠然，UDP有一些特性，比如多路復用跟校驗和服務，這些都是對實時服務很有利的。為了消除UDP的缺點，RTP是作為應用層而被提出來的。

RTP提供的各種服務包括有效負載識別，序列編號，時間戳和投遞監聽。RTP能夠序列化包，當這些包在收端不是按順序到達的時。序列號也能被用來識別包丟失。時間戳被用於媒體有效的播放。到達的數據一直被RTCP監聽，以通知RTP層來校正其編碼和傳輸的參數。例如，如果RTCP層檢測到包丟失，它會通知RTP層減緩發送速率。

盡管RTP有助於實時媒體的有效的播放 ，但是要注意的是RTP自身並不提供任何機制來確保及時傳遞或提供其他服務質量（QoS）的保證，而是依靠低層服務來完成這些。同樣，RTP也不保證投遞或防止無序投遞。RTP被設計出來主要是為了滿足有多個參加者的多媒體會議的需要。RTP也同樣適合於象持續數據的儲存，分布式交互仿真，主動標記以及應用程序的控制和測量。

1.2 RTP特性一覽

RTP提供有效負荷類型識別，亂序重排和利用時間戳的媒體有效播放。

RTCP監控服務質量，也提供在一個當前進行的會話中傳送關於參加者的信息作用。

RTP對於下層協議是獨立的，它能夠工作在像TCP/IP，ATM，幀時延等類型的網絡上。

如果被下層網絡支持，RTP支持利用多路技術的對於多點的數據傳輸。

RTP序列號也能被用來確定包的合適位置。例如在視頻解碼，包無需按序解碼。

UDT（UDP-based Data Transfer Protocol）

基於UDP的數據傳輸協議（UDP-based Data Transfer Protocol，簡稱UDT）是一種互聯網數據傳輸協議。UDT的主要目的是支持高速廣域網上的海量數據傳輸，而互聯網上的標准數據傳輸協議TCP在高帶寬長距離網絡上性能很差。 顧名思義，UDT建於UDP之上，並引入新的擁塞控制和數據可靠性控制機制。UDT是面向連接的雙向的應用層協議。它同時支持可靠的數據流傳輸和部分可靠的數據報傳輸。 由於UDT完全在UDP上實現，它也可以應用在除了高速數據傳輸之外的其它應用領域，例如點到點技術（P2P），防火牆穿透，多媒體數據傳輸等等。

UDT是雙工的，每個UDT實體有兩個部分：發送和接收。發送者根據流量控制和速率控制來發送（和重傳）應用程式數據。接收者接收數據包和控制包，並根據接收到的包發送控制包。發送和接收程式共享同一個UDP端口來發送和接收。
接收者也負責觸發和處理任何的控制事件，包括擁塞控制和可靠性控制和他們的相對機制，例如RTT估計、帶寬估計、應答和重傳。
UDT總是試着將應用層數據打包成固定的大小，除非數據不夠這么大。和TCP相似的是，這個固定的包大小叫做MSS（最大包大小）。由於期望UDT用來傳輸大塊數據流，我們假定只有很小的一部分不規則的大小的包在UDT session中。MSS能夠通過應用程式來安裝，MTU是其最優值（包括任何包頭）。
UDT擁塞控制算法將速率控制和窗口（流量控制）合並起來，前者調整包的發送周期，后者限制最大的位被應答的包。在速率控制中使用的參數通過帶寬估計技術來更新，他繼承來自基於接收的包方法。同時，速率控制周期是估計RTT的常量，流控制參數依賴於對方的數據到達速度，另外接收端釋放的緩沖區的大小。

UDP構建可靠數據傳輸
簡單來講，要使用UDP來構建可靠的面向連接的數據傳輸，就要實現類似於TCP協議的超時重傳，有序接受，應答確認，滑動窗口流量控制等機制，等於說要在傳輸層的上一層（或者直接在應用層）實現TCP協議的可靠數據傳輸機制，比如使用UDP數據包+序列號，UDP數據包+時間戳等方法，在服務器端進行應答確認機制，這樣就會保證不可靠的UDP協議進行可靠的數據傳輸。

HTTP

瀏覽器輸入一個URL后的過程

當我們在瀏覽器中輸入一個網址，比如www.google.cn，瀏覽器就會加載出百度的主頁。那么瀏覽器背后完成的具體是怎么樣的呢？
總結起來大概的流程是這樣的：
（1）瀏覽器本身是一個客戶端，當你輸入URL的時候，首先瀏覽器會去請求DNS服務器，通過DNS獲取相應的域名對應的IP
（2）然后通過IP地址找到IP對應的服務器后，要求建立TCP連接
（3）瀏覽器發送完HTTP Request（請求）包后，服務器接收到請求包之后才開始處理請求包
（4）在服務器收到請求之后，服務器調用自身服務，返回HTTP Response（響應）包
（5）客戶端收到來自服務器的響應后開始渲染這個Response包里的主體（body），等收到全部的內容隨后斷開與該服務器之間的TCP

瀏覽器輸入url訪問的過程

前言

當我們在瀏覽器中輸入一個網址，比如www.google.cn，瀏覽器就會加載出百度的主頁。那么瀏覽器背后完成的具體是怎么樣的呢？
總結起來大概的流程是這樣的：
（1）瀏覽器本身是一個客戶端，當你輸入URL的時候，首先瀏覽器會去請求DNS服務器，通過DNS獲取相應的域名對應的IP
（2）然后通過IP地址找到IP對應的服務器后，要求建立TCP連接
（3）瀏覽器發送完HTTP Request（請求）包后，服務器接收到請求包之后才開始處理請求包
（4）在服務器收到請求之后，服務器調用自身服務，返回HTTP Response（響應）包
（5）客戶端收到來自服務器的響應后開始渲染這個Response包里的主體（body），等收到全部的內容隨后斷開與該服務器之間的TCP連接。
就可以用下面的這幅圖來進行解釋

1. DNS解析

在瀏覽器中輸入的是一個網址，是不能直接用來進行連接的，因而就要使用DNS地址解析將輸入的URL網址轉換為IP地址。查找的流程圖是這樣的

具體的查找過程和策略可以分為下面這幾步：
（1）在瀏覽器中輸入www.google.cn域名，操作系統會先檢查自己本地的hosts文件是否有這個網址映射關系，如果有，就先調用這個IP地址映射，完成域名解析。
（2）如果hosts里沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關系，如果有，直接返回，完成域名解析。
（3）如果hosts與本地DNS解析器緩存都沒有相應的網址映射關系，首先會找TCP/IP參數中設置的首選DNS服務器，在此我們叫它本地DNS服務器，此服務器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具有權威性。
（4）如果要查詢的域名，不由本地DNS服務器區域解析，但該服務器已緩存了此網址映射關系，則調用這個IP地址映射，完成域名解析，此解析不具有權威性。
（5）如果本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至13台根DNS，根DNS服務器收到請求后會判斷這個域名(.com)是誰來授權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息后，將會聯系負責.com域的這台服務器。這台負責.com域的服務器收到請求后，如果自己無法解析，它就會找一個管理.com域的下一級DNS服務器地址(google.com)給本地DNS服務器。當本地DNS服務器收到這個地址后，就會找google.com域服務器，重復上面的動作，進行查詢，直至找到www.google.com主機。
（6）如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。不管是本地DNS服務器用是是轉發，還是根提示，最后都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。

2. Socket建立連接

當我們輸入這樣一個請求時，首先要建立一個socket連接，因為socket是通過ip和端口建立的，所以之前還有一個DNS解析過程，把www.google.com變成ip，如果url里不包含端口號，則會使用該協議的默認端口號。

3. 發送HTTP請求

連接成功建立后，開始向web服務器發送請求，當瀏覽器向Web服務器發出請求時，它向服務器傳遞了一個數據塊，也就是請求信息，HTTP請求信息由3部分組成：
（1）請求方法URI協議/版本
（2）請求頭(Request Header)
（3）請求正文
下面是一個HTTP請求的例子：

1. GET /sample.jsp HTTP/1.1
2. Accept:image/gif.image/jpeg,*/*
3. Accept-Language:zh-cn
4. Connection:Keep-Alive
5. Host:localhost
6. User-Agent:Mozila/ 4.0(compatible;MSIE5.01;Window NT5.0)
7. Accept-Encoding:gzip,deflate
8. username=jinqiao&password= 1234

3.1 請求方法URI協議/版本

請求的第一行是“方法URL議/版本”：GET/sample.jsp HTTP/1.1``
以上代碼中“GET”代表請求方法，/sample.jsp表示URI，HTTP/1.1“`代表協議和協議的版本。
根據HTTP標准，HTTP請求可以使用多種請求方法。例如：HTTP1.1支持7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet應用中，最常用的方法是GET和POST。
URL完整地指定了要訪問的網絡資源，通常只要給出相對於服務器的根目錄的相對目錄即可，因此總是以“/”開頭，最后，協議版本聲明了通信過程中使用HTTP的版本。

3.2 請求頭(Request Header)

請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如，請求頭可以聲明瀏覽器所用的語言，請求正文的長度等。

1. Accept:image/gif.image/jpeg.*/*
2. Accept-Language:zh-cn
3. Connection:Keep-Alive
4. Host:localhost
5. User-Agent:Mozila/ 4.0(compatible:MSIE5.01:Windows NT5.0)
6. Accept-Encoding:gzip,deflate.

3.3 請求正文

請求頭和請求正文之間是一個空行，這個行非常重要，它表示請求頭已經結束，接下來的是請求正文。請求正文中可以包含客戶提交的查詢字符串信息：

username=jinqiao&password=1234

•  

在以上的例子的HTTP請求中，請求的正文只有一行內容。當然，在實際應用中，HTTP請求正文可以包含更多的內容。

3.4 HTTP請求方法：GET方法與POST方法

3.4.1 GET方法

GET方法是默認的HTTP請求方法，我們日常用GET方法來提交表單數據，然而用GET方法提交的表單數據只經過了簡單的編碼，同時它將作為URL的一部分向Web服務器發送，因此，如果使用GET方法來提交表單數據就存在着安全隱患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
從上面的URL請求中，很容易就可以辯認出表單提交的內容。（？之后的內容）另外由於GET方法提交的數據是作為URL請求的一部分所以提交的數據量不能太大

3.4.2 POST方法

POST方法是GET方法的一個替代方法，它主要是向Web服務器提交表單數據，尤其是大批量的數據。POST方法克服了GET方法的一些缺點。通過POST方法提交表單數據時，數據不是作為URL請求的一部分而是作為標准數據傳送給Web服務器，這就克服了GET方法中的信息無法保密和數據量太小的缺點。因此，出於安全的考慮以及對用戶隱私的尊重，通常表單提交時采用POST方法。

3.5 各種HTTP請求的含義

GET
通過請求URI得到資源
POST
用於添加新的內容
PUT
用於修改某個內容
DELETE
刪除某個內容
CONNECT
用於代理進行傳輸，如使用SSL
OPTIONS
詢問可以執行哪些方法
PATCH
部分文檔更改
PROPFIND
查看屬性
PROPPATCH
設置屬性
MKCOL
創建集合（文件夾）
COPY
拷貝
MOVE
移動
LOCK
加鎖
UNLOCK
解鎖
TRACE
用於遠程診斷服務器
HEAD
類似於GET, 但是不返回body信息，用於檢查對象是否存在，以及得到對象的元數據

4. 服務器響應

應答 web服務器收到這個請求，進行處理。從它的文檔空間中搜索子目錄mydir的文件index.html。如果找到該文件，Web服務器把該文件內容傳送給相應的Web瀏覽器。為了告知瀏覽器，Web服務器首先傳送一些HTTP頭信息，然后傳送具體內容（即HTTP體信息），HTTP頭信息和HTTP體信息之間用一個空行分開。

4.1 HTTP響應報文頭

HTTP應答與HTTP請求相似，HTTP響應也由3個部分構成，分別是：
（1）協議狀態版本代碼描述
（2）響應頭(Response Header)
（3）響應正文
下面是一個HTTP響應的例子：

1. HTTP/1.1 200 OK
2. Server:Apache Tomcat/5.0.12
3. Date:Mon,6Oct2003 13:23:42 GMT
4. Content-Length:112
5.  
6. <html>
7. <head>
8. <title>HTTP響應示例<title>
9. </head>
10. <body>
11. Hello HTTP!
12. </body>
13. </html>

協議狀態代碼描述HTTP響應的第一行類似於HTTP請求的第一行，它表示通信所用的協議是HTTP1.1服務器已經成功的處理了客戶端發出的請求（200表示成功）:
HTTP/1.1 200 OK
響應頭(Response Header)響應頭也和請求頭一樣包含許多有用的信息，例如服務器類型、日期時間、內容類型和長度等：

1. Server:Apache Tomcat/5.0.12
2. Date:Mon,6Oct2003 13:13:33 GMT
3. Content-Type: text/html
4. Last-Moified:Mon, 6 Oct 2003 13:23:42 GMT
5. Content-Length: 112

響應正文響應正文就是服務器返回的HTML頁面：

1. <html>
2. <head>
3. <title>HTTP響應示例<title>
4. </head>
5. <body>
6. Hello HTTP!
7. </body>
8. </html>

響應頭和正文之間也必須用空行分隔。

4.2 HTTP應答碼

HTTP應答碼也稱為狀態碼，它反映了Web服務器處理HTTP請求狀態。HTTP應答碼由3位數字構成，其中首位數字定義了應答碼的類型：
1XX－信息類(Information),表示收到Web瀏覽器請求，正在進一步的處理中
2XX－成功類（Successful）,表示用戶請求被正確接收，理解和處理例如：200 OK
3XX - 重定向類(Redirection),表示請求沒有成功，客戶必須采取進一步的動作。
4XX - 客戶端錯誤(Client Error)，表示客戶端提交的請求有錯誤 例如：404 NOT Found，意味着請求中所引用的文檔不存在。
5XX - 服務器錯誤(Server Error)表示服務器不能完成對請求的處理：如 500
對於我們Web開發人員來說掌握HTTP應答碼有助於提高Web應用程序調試的效率和准確性。

5. 關閉連接

當應答結束后，Web瀏覽器與Web服務器必須斷開，以保證其它Web瀏覽器能夠與Web服務器建立連接。

 

[計算機網絡]TCP三次握手、四次揮手

TCP三次握手可以形象的用下圖中的例子來說明

三次握手：

四次揮手：

SDP: Session Description Protocol(會話描述協議)

  SDP: Session Description Protocol(會話描述協議)

(RFC2327)

1.       概述

SDP也是MMUSIC工作組的一個產品,在MBONE內容中用得很多。其目的就是在媒體會話中，傳遞媒體流信息，允許會話描述的接收者去參與會話。SDP基本上在internet上工作。他定義了繪畫描述的統一格式,但並不定義多播地址的分配和SDP消息的傳輸,也不支持媒體編碼方案的協商,這些功能均由下層傳送協議完成.典型的會話傳送協議包括:SAP(Session Announcement Protocol 會話公告協議),SIP,RTSP,HTTP,和使用MIME的E-Mail.(注意:對SAP只能包含一個會話描述,其它會話傳誦協議的SDP可包含多個繪畫描述)

SDP包括以下一些方面：

1）會話的名稱和目的

2）會話存活時間

3）包含在會話中的媒體信息，包括：

媒體類型(video, audio, etc)

傳輸協議(RTP/UDP/IP, H.320, etc)

媒體格式(H.261 video, MPEG video, etc)

多播或遠端（單播）地址和端口

4）為接收媒體而需的信息(addresses, ports, formats and so on)

5）使用的帶寬信息

6）可信賴的接洽信息（Contact information）

 

2.       協議

Session description                                                   //格式及舉例

v= (protocol version)                               //v=0

        o= (owner/creator and session identifier).   //o=<用戶名><會話id><版本><網絡類

//型><地址類型><地址>

//o=sname 1234567890 0987654321 IN

//IP4 126.15.64.3

        s= (session name)                                          //會話名

        i=* (session information)                                   //會話信息

        u=* (URI of description)                                   //u=http://www.zte.com.cn/staff/sdp.ps

        e=* (email address)                                          //e=[e-mail](general text如：王生)

                                                                             //或e=Mr. Wang<[e-mail]>

        p=* (phone number)                                  //p=[phone]-7110(wang)

                                                                             //or p=[phone]

        c=* (connection information -如已經包含在所有媒體中則該行不需要)

                                                                             //c=<網絡類型><地址信息><連接地址>

                                                                             //多點會議包括TTL

                                                                             //連接地址: <base multicast

//address>/<ttl>/<number of addresses>

                                                                             //c=IN IP4 224.2.13.23/127

                                                                             //c=IN IP4 224.2.1.1/127/3

        b=* (bandwidth information)                      //b=<修改量（CT Conference Total

//IAS Application-specific Max)>:<帶寬

//值（kb/s）>

//b=CT:120

One or more time descriptions (see below)

        z=* (time zone adjustments)                       //時區調整

        k=* (encryption key)                                 //k=<方法>:<密鑰>或k=<方法>

        a=* (zero or more session attribute lines)     //a=<屬性> 或a=<屬性>:<值>

Zero or more media descriptions (see below)      

 

各行嚴格按順序,其中:

時間描述：

        t= (time the session is active)                   //<開始時間><結束時間>，單位秒，十

//進制NTP

//t=2873397468 2873404969

        r=* (zero or more repeat times)                  //<重復時間><活動持續時間

//以開始時刻為參考的偏移列表>單位秒

//r=604800 3666 90000     或寫成

//r=7d 1h 0 25h

媒體描述：

        m= (media name and transport address)    //m=<媒體><端口><傳送><格式列表>

                                                                             //m=audio 49170 RTP/AVP 0 3

                                                                             //協議為RTP，剖面為AVP

                                                                             //參考rtp-parameters.txt

        i=* (media title媒體稱呼)                           //

        c=* (connection information – 如已經包含在會話級描述則為可選)

        b=* (bandwidth information)                      //同c

        k=* (encryption key)                                 //會話級為摸認值,同c

        a=* (zero or more media attribute lines)              //兩種形式：(也同c)（見后說明）

                                                                             //a=<attribute>如：

                                                                             //     a=recvonly

                                                                             //a=<attribute>:<value>

 

注： v,o,s,t,m 為必須的 , 其他項為可選。

         如果 SDP 語法分析器不能識別某一類型 (Type), 則整個描述丟失 ;

         如果 ”a=” 的某屬性值不理解 , 則予以丟失

         整個協議區分大小寫

         “=” 兩側不允許有空格

         會話級的描述就是媒體級描述的缺省值

         所有均格式為 <type>=<value>

 

 

 

3.       SDP 在 IP 電話中的使用

SDP用於構建INVITE和200 OK響應消息的消息體,供主/被叫用戶交換媒體信息.

1.       媒體流的配置

1)      主被叫的媒體描述必須完全對應:主被叫的第n個媒體流(“m=”)對應,都包含”a=rtpmap”.這樣的目的是易於適應靜態凈荷類型到動態凈荷類型的轉換.

2)      如被叫不想接收主叫提出的某個媒體流則在響應中設置該媒體流的端口號為0.並且,必須返回對應的媒體流行.

2.       單播SDP值的設定

1)      對於只發媒體流,端口號無意義,應設為0.

2)      每個媒體流的凈載荷類型例表應傳送兩個信息:能接受/發送的編譯碼,和用以標識這些編譯碼的RTP凈載荷類型號.

3)      如對於某一媒體流,主/被叫沒有公共的媒體格式,被叫仍然要求返回媒體流的”m=”行,端口好為0,同時,不列凈載荷類型.

4)      如果所有媒體流均無公共的媒體格式,則被叫回送400響應(壞請求),並加入304警告頭字段(無媒體類型)

3.       多播操作

1)      接受和發送的多播地址是相同的

2)      被叫不允許改變媒體流的只發,只收,或收/發特性

3)      如果被叫不支持多播,則回送400響應和330警告(多播不可用)

4.       延時媒體流

由於主叫可能實際上是一個和其他協議(如H.323)互同的協議的網關,與S其互同的協議要求呼叫建立后進行媒體協商.這樣,主叫可以先發不帶SDP的INVITE,呼叫建立后可以通過ACK或重新發一個INVITE請求修改被叫的會話描述(SDP).

5.       媒體流保持

如果要求對方進入HOLD,即暫時停止發送一個或多個媒體流,這可以用Re-INVITE,其會話描述和原來的請求或響應中的描述相同,只是,”c=”行中的保持媒體流的地址置為”0.0.0.0”,還有就是Re_INVITE中的Cseq得遞增.

6.       對應於SIP中有3個實體字段:

1)      Content-Type: 指明消息體類型,有兩種:

                         i.              Application/sdp:表示是SDP會話描述

                       ii.              Text/html:表示是普通文本或HTML格式的描述

2)      Content-Encoding:補充說明消息體類型,使用戶可以采用壓縮編碼編輯消息體

3)      Content-Length:給出消息體的字節數

7.       SDP 各 type 的詳細解釋 :

協議版本 o= SDP版本目前為0,沒有子版本

會話源    v= <用戶名>用戶在發起主機上登錄名,如果主機不支持用戶標識的概念,則為”-”

<會話id>一般為數字串,其分配由創建工具決定,建議用網絡時間協議(NTP)時

戳,以確保唯一性.

<版本>該會話公告的版本,供公告代理服務器檢測同一會話的若干個公告哪個

是最新公告.基本要求是會話數據修改后該版本值遞增,建議用NTP時戳

<網絡類型>為文本串”IN”

<地址類型>”IP4”(可為域名或點分十進制)/”IP6”(域名或壓縮文本地址形式)

<地址>

會話名    s=       ISO 10646字符表示的會話名

會話信息 v=        ISO 10646字符表示的會話信息

URI       u= 能提供會議進一步信息的URI地址

E妹地址 e=給出會議負責人的聯系信息,他不一定是創建會議公告的人

電話號碼 p=        給出會議負責人的聯系信息,他不一定是創建會議公告的人(國際通用形式)

連接數據 c=媒體連接數據，會話級為媒體級的摸認值

帶寬       b=       給出會話或媒體所用帶寬，單位為kbit/s.修飾語：CT(會議總帶寬，表示所有

地點所有媒體的總帶寬)，AS(應用特定最大帶寬，表示一個地點單一媒體帶寬)

時間描述 t=見上

               r=       見上

時區調整 z=        見上

加密密鑰         k=已定義的方法有

                   k=clear:<加密密鑰>密鑰沒有變換

                     k=base64:<編碼密鑰>已編碼，因為它含有SDP禁用的字符

                     k=uri:<獲得密鑰的URI>

                     k=prompt。SDP沒有提供密鑰但該會話或媒體流是要求加密的。

屬性                a=一個m=行可有多個a=行，SDP建議擴展如下：(具體見[1].Page419)

                     會話級：        a=cat:<類別>//給出點分層次式會話分類號,供接收方篩選會話

                                   a=keywds:<關鍵詞>//供接收方篩選會話

                                   a=tool:<工具名和版本號>//創建會話描述的工具名和版本號

a=recvonly/sendrecv/sendonly//收發模式

a=type:<會議類型>//有:廣播,聚會,主席主持,測試,H.323

a=charset:<字符集>//顯示會話名和信息數據的字符集

a=sdplang:<語言標記>//描述所有語言

a=lang:<語言標記>//會話描述的缺省語言或媒體描述的語言

a=framerate:<幀速率>//單位:幀/秒

a=quality:<質量>//視頻的建議質量(10/5/0)

a=fmtp:<格式>< 格式特定參數>//定義指定格式的附加參數

                     媒體級：a=ptime:<分組時間>//媒體分組的時長(單位:秒)

a=recvonly/sendrecv/sendonly//收發模式

a=orient:<白板方向>//指明白板在屏莫上的方向

a=sdplang:<語言標記>//描述所有語言

a=lang:<語言標記>//會話描述的缺省語言或媒體描述的語言

媒體描述        m= <媒體>有5種類型：音頻/視頻/應用(如白板信息)/數據(不向用戶顯示的)/控制

<端口>媒體流發往傳輸層的端口。取決於c=行規定的網絡類型和接下來的傳

送層協議：對UDP為1024-65535；對分層編碼應用（c=行沒有多播地址），

要給出多播端口數，如：m=video 49170/2 RTP/AVP 31（表示：端口49170

和49171為第一對RTP/RTCP端口，49172和49173為第二對的端口）。

<傳送層協議>與c=行的地址類型有關。對大多的媒體在RTP/UDP上傳送，定

義2種：RTP/AVP：IETF RTP協議，音/視頻應用文檔。在UDP上傳誦。

              Udp：UDP協議。

<格式列表>對音/視頻，就是音/視頻應用文檔中規定媒體凈荷類型。列表中都

有可能用，但第一個為缺省值，分為靜態綁定和動態綁定：靜態綁定即使媒體編碼方式有凈荷類型號完全確定，動態綁定則媒體編碼方式（如時鍾頻率，音頻信道數等）沒有完全確定，需要進一步的屬性說明。分別舉例如下：

Alaw的PCM編碼單信道Audio，其凈荷類型號為8，把它發往UDP端口49232，則：m=audio 49232 RTP/AVP 8

16bit線性編碼，雙聲道立體聲，抽樣速率16kHz，其動態凈荷類型號98，則：m=audio 49232 RTP/AVP 98

       a=rtpmap:98 L16/16000/2

說明：1）a=rtpmap:<凈荷類型號><編碼名>/<時鍾速率>[/<編碼參數>]

               對音頻，編碼參數為音頻信道數；對視頻沒有定義

2）SDP允許rtpmap規定實驗性編碼格式，但編碼名必須以X-起，

表示此格式還沒正式登記。

 

4.       SDP Grammar

   announcement =       proto-version

                         origin-field

                         session-name-field

                         information-field

                         uri-field

                         email-fields

                         phone-fields

                         connection-field

                         bandwidth-fields

                         time-fields

                         key-field

                         attribute-fields

                         media-descriptions

 

   proto-version =       "v=" 1*DIGIT CRLF

                         ;this memo describes version 0

   origin-field =        "o=" username space

                         sess-id space sess-version space

                         nettype space addrtype space

                         addr CRLF

   session-name-field = "s=" text CRLF

   information-field =   ["i=" text CRLF]

   uri-field =           ["u=" uri CRLF]

   email-fields =        *("e=" email-address CRLF)

   phone-fields =        *("p=" phone-number CRLF)

   connection-field =    ["c=" nettype space addrtype space

                         connection-address CRLF]

                         ;a connection field must be present

                         ;in every media description or at the

                         ;session-level

   bandwidth-fields =    *("b=" bwtype ":" bandwidth CRLF)

   time-fields =         1*( "t=" start-time space stop-time

                         *(CRLF repeat-fields) CRLF)

                         [zone-adjustments CRLF]

   repeat-fields =       "r=" repeat-interval space typed-time

                         1*(space typed-time)

   zone-adjustments =    time space ["-"] typed-time

                         *(space time space ["-"] typed-time)

   key-field =           ["k=" key-type CRLF]

   key-type =            "prompt" |

                         "clear:" key-data |

                         "base64:" key-data |

                         "uri:" uri

   key-data =            email-safe | "~" | "

   attribute-fields =    *("a=" attribute CRLF)

   media-descriptions = *( media-field

                         information-field

                         *(connection-field)

                         bandwidth-fields

                         key-field

                         attribute-fields )

   media-field =         "m=" media space port ["/" integer]

                         space proto 1*(space fmt) CRLF

   media =               1*(alpha-numeric)

                         ;typically "audio", "video", "application"

                         ;or "data"

   fmt =                 1*(alpha-numeric)

                         ;typically an RTP payload type for audio

                         ;and video media

   proto =               1*(alpha-numeric)

                         ;typically "RTP/AVP" or "udp" for IP4

   port =                1*(DIGIT)

                         ;should in the range "1024" to "65535" inclusive

                         ;for UDP based media

   attribute =           (att-field ":" att-value) | att-field

   att-field =           1*(alpha-numeric)

   att-value =           byte-string

   sess-id =             1*(DIGIT)

                         ;should be unique for this originating username/host

   sess-version =        1*(DIGIT)

                         ;0 is a new session

   connection-address = multicast-address

                         | addr

   multicast-address =   3*(decimal-uchar ".") decimal-uchar "/" ttl

                         [ "/" integer ]

                         ;multicast addresses may be in the range

                         ;224.0.0.0 to 239.255.255.255

   ttl =                 decimal-uchar

   start-time =          time | "0"

   stop-time =           time | "0"

   time =                POS-DIGIT 9*(DIGIT)

                         ;sufficient for 2 more centuries

   repeat-interval =     typed-time

   typed-time =          1*(DIGIT) [fixed-len-time-unit]

   fixed-len-time-unit = "d" | "h" | "m" | "s"

   bwtype =              1*(alpha-numeric)

   bandwidth =           1*(DIGIT)

   username =            safe

                         ;pretty wide definition, but doesn't include space

   email-address =       email | email "(" email-safe ")" |

                         email-safe "<" email ">"

   email =               ;defined in RFC822

   uri=                  ;defined in RFC1630

   phone-number =        phone | phone "(" email-safe ")" |

                         email-safe "<" phone ">"

   phone =               "+" POS-DIGIT 1*(space | "-" | DIGIT)

                         ;there must be a space or hyphen between the

                         ;international code and the rest of the number.

   nettype =             "IN"

                         ;list to be extended

   addrtype =            "IP4" | "IP6"

                         ;list to be extended

   addr =                FQDN | unicast-address

   FQDN =                4*(alpha-numeric|"-"|".")

                         ;fully qualified domain name as specified in RFC1035

   unicast-address =     IP4-address | IP6-address

   IP4-address =         b1 "." decimal-uchar "." decimal-uchar "." b4

   b1 =                  decimal-uchar

                         ;less than "224"; not "0" or "127"

   b4 =                  decimal-uchar

                         ;not "0"

   IP6-address =         ;to be defined

   text =                byte-string

                         ;default is to interpret this as IS0-10646 UTF8

                         ;ISO 8859-1 requires a "a=charset:ISO-8859-1"

                         ;session-level attribute to be used

   byte-string =         1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)

                         ;any byte except NUL, CR or LF

   decimal-uchar =       DIGIT

                         | POS-DIGIT DIGIT

                         | ("1" 2*(DIGIT))

                         | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)

                         | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))

   integer =             POS-DIGIT *(DIGIT)

   alpha-numeric =       ALPHA | DIGIT

   DIGIT =               "0" | POS-DIGIT

   POS-DIGIT =           "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"

   ALPHA =               "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|

                         "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"|

                         "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"|

                         "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"|

                         "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"

   email-safe =          safe | space | tab

   safe =                alpha-numeric |

                         "'" | "'" | "-" | "." | "/" | ":" | "?" | """ |

                         "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |

                         "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |

                         "~" | "

   space =               %d32

   tab =                 %d9

   CRLF =                %d13.10

 

[References]

1.《IP網絡電話技術》人民郵電出版社，糜正琨編著