專利名稱：基于nat的udp流媒體服務器的網(wǎng)關穿透方法
技術領域：
本發(fā)明屬于網(wǎng)絡多媒體技術領域，涉及一種基于NAT的UDP流媒體服務器的網(wǎng)關穿透方法。具體地說，主要涉及在網(wǎng)絡多媒體中，使流媒體服務器ClearServer可以識別內(nèi)網(wǎng)客戶端的IP(網(wǎng)絡協(xié)議)地址和端口號，將服務器端的多媒體數(shù)據(jù)能夠順利發(fā)送到客戶端的方法，從而實時有效的在因特網(wǎng)中傳送多媒體信息。
背景技術：
流媒體(Media Streaming)技術是指支持多媒體數(shù)據(jù)流通過網(wǎng)絡從服務器向客戶端傳送，接收方邊接收邊播放的技術。流媒體應用通常要求視頻和音頻連續(xù)、清晰和實時地播放，這就對網(wǎng)絡服務提出了要求1)必須實時傳輸數(shù)據(jù)，僅能夠容忍少量的延遲(數(shù)百毫秒)；2)傳送數(shù)據(jù)相對可靠，容忍一定數(shù)量的數(shù)據(jù)丟失；3)確保一定的帶寬，以保證傳輸?shù)臄?shù)據(jù)量能夠實時地播放。
Internet(因特網(wǎng))給網(wǎng)絡應用程序提供兩種服務TCP(傳輸控制協(xié)議)和UDP(用戶數(shù)據(jù)報協(xié)議)。TCP通過確認和重傳機制保證數(shù)據(jù)無錯順序地傳送，同時采用擁塞控制策略和發(fā)送速率控制解決傳輸中的擁塞問題以及發(fā)送速率與接受速率不匹配問題。但是TCP采用上述控制策略的時候卻犧牲了數(shù)據(jù)的傳輸速度，所以對于傳輸數(shù)據(jù)量較大的流媒體應用來說，采用TCP傳輸難以保證數(shù)據(jù)傳輸?shù)膶崟r性。而UDP傳輸方式?jīng)]有TCP的擁塞控制和發(fā)送速率控制，也沒有提供數(shù)據(jù)傳輸?shù)目煽啃员ＷC，但是卻保證了傳輸?shù)乃俣龋瑵M足了流媒體應用中的關鍵因素——實時性，所以越來越被流媒體應用系統(tǒng)所采納。
ClearServer是一種新興的UDP流媒體服務器，實現(xiàn)了視頻質量和發(fā)送速率的控制以及符合工業(yè)標準的擁塞控制以此大幅度的提高流媒體服務質量，并有自適應網(wǎng)絡帶寬的傳輸功能，可按網(wǎng)絡實際狀況調(diào)節(jié)媒體傳輸碼率，解決了流媒體傳輸中的時延問題，即采用UDP傳輸協(xié)議能夠獲得較高的傳輸率。ClearServer服務器端接收到包含客戶端請求信息的RTSP(Real Time Streaming Protocol實時流協(xié)議)數(shù)據(jù)包請求之后，解析數(shù)據(jù)包取得客戶端的IP地址和端口號，根據(jù)取得的客戶端IP地址和端口號，將客戶請求的多媒體數(shù)據(jù)發(fā)送到客戶端。但是，這種接收和發(fā)送機制存在這樣的一個問題如果一臺intranet(內(nèi)網(wǎng))機器在點播ClearServer的時候，由于內(nèi)網(wǎng)機器IP地址對于普通的Internet上的機器而言是不可知的，即對于流媒體服務器ClearServer來說，包含客戶端請求信息的RTSP數(shù)據(jù)包中的IP地址和端口號是不可識別的，根據(jù)這個數(shù)據(jù)包中的IP地址和端口號，ClearServer無法將客戶端請求的流媒體數(shù)據(jù)發(fā)到客戶端。
由于UDP傳輸協(xié)議是一個面向無連接的服務，即沒有在兩個進程之間建立連接的初始“握手”階段，所以在一個進程想要往另一個進程發(fā)送一批字節(jié)的時候，發(fā)送方進程必須將目的進程的地址加入到發(fā)送的字節(jié)中。當點播ClearServer的時候，客戶端發(fā)送的RTSP請求字節(jié)中包含客戶端的IP地址和端口號信息。當RTSP請求到達ClearServer后，ClearServer將它解析，得到客戶端的IP地址和端口號信息，然后服務器回應客戶端的RTSP請求。在向客戶端發(fā)送UDP流媒體數(shù)據(jù)之前，先對要發(fā)送的流媒體數(shù)據(jù)進行“包裝”，以解析RTSP請求所得的客戶端IP地址和端口為發(fā)送目的地，然后將UDP數(shù)據(jù)包發(fā)出。
在內(nèi)網(wǎng)中，任何一臺計算機的IP地址僅僅是一個臨時的IP地址，即內(nèi)網(wǎng)外部的機器無法識別這個IP地址。所以內(nèi)網(wǎng)的某臺計算機點播ClearServer服務器的時候，客戶端發(fā)送到服務器端的分組中包含的IP地址實際上“虛擬”的，以這個IP地址為發(fā)送目的地的UDP數(shù)據(jù)包無法到達客戶端。所以，必須找出一種方法，找到內(nèi)網(wǎng)客戶端的“地址”，使得服務器端能夠根據(jù)這個“地址”能找到客戶端，從而將流媒體數(shù)據(jù)發(fā)送到客戶端。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種使流媒體服務器Clear Media Server可以識別內(nèi)網(wǎng)客戶端的IP地址和端口號，將服務器端的多媒體數(shù)據(jù)順利發(fā)送到客戶端的方法，我們稱其為ClearNat方法。目前網(wǎng)絡上運行的網(wǎng)關普遍都提供NAT服務，即網(wǎng)絡地址轉換。本發(fā)明適用于穿透提供NAT服務的網(wǎng)關，以下稱之為NAT服務器。本方法需要為內(nèi)網(wǎng)的機器的客戶端建立內(nèi)網(wǎng)IP地址、端口與NAT服務器IP地址、端口的映射，以使流媒體服務器ClearServer能將媒體數(shù)據(jù)穿透NAT服務器發(fā)送到內(nèi)網(wǎng)機器的播放器上。該方法的計算復雜度較低，效果好，對主控服務器的其他應用進程沒有影響，且在流媒體服務器ClearServer中能支持大的內(nèi)網(wǎng)并發(fā)用戶的使用。
對于流媒體服務器來說處于內(nèi)網(wǎng)的客戶端所在計算機的IP地址、端口是不可見的，也就是說，通過RTSP交互，服務器ClearServer得到的內(nèi)網(wǎng)IP地址、端口其實是不可用的，即無法將點播節(jié)目的UDP數(shù)據(jù)包發(fā)送到處于內(nèi)網(wǎng)的客戶端。而網(wǎng)關提供的NAT服務使得服務器有途經(jīng)正確得發(fā)送UDP數(shù)據(jù)包。當內(nèi)網(wǎng)的計算機向外網(wǎng)發(fā)送UDP數(shù)據(jù)包時，NAT服務器會記錄內(nèi)網(wǎng)計算機的IP地址、端口(記為A、B)，并在NAT服務器上隨即選擇一個端口C，轉發(fā)從內(nèi)網(wǎng)發(fā)送過來的UDP數(shù)據(jù)包，并將NAT服務器上的端口C與內(nèi)網(wǎng)IP地址A、端口B組成一個映射，此后，從外網(wǎng)發(fā)回給NAT服務器端口C的UDP數(shù)據(jù)包都會被轉發(fā)到內(nèi)網(wǎng)IP地址A的端口B。因此，只要UDP流媒體服務器將數(shù)據(jù)包發(fā)向NAT服務器上正確的端口，那么UDP數(shù)據(jù)包就能夠被轉發(fā)到處于內(nèi)網(wǎng)的客戶端。關鍵在于，要讓UDP流媒體服務器ClearServer建立內(nèi)網(wǎng)IP地址、端口與NAT服務器IP地址、端口的映射。通過運行在客戶端與服務器端兩方的程序的配合，能夠做到這一點，這也就是ClearNat方法的基本原理。據(jù)此，稱本發(fā)明為基于NAT的UDP流媒體服務器的網(wǎng)關穿透方法。
本發(fā)明的具體工作步驟如下首先，需要一個OCX(ActiveX控件)運行在客戶端瀏覽的點播網(wǎng)頁上。當用戶點擊網(wǎng)頁上的點播鏈接后，由網(wǎng)頁告知OCX，用戶名信息、用戶點播影片名信息和流媒體服務器ClearServer的IP地址。OCX根據(jù)這些信息構建UDP數(shù)據(jù)包，其中數(shù)據(jù)段的內(nèi)容包括用戶的內(nèi)網(wǎng)IP地址、內(nèi)網(wǎng)UDP接收端口和點播的節(jié)目名。內(nèi)網(wǎng)UDP接收端口其實就是用戶的視頻播放器等待接收UDP數(shù)據(jù)包的端口，OCX可以根據(jù)不同播放器的不同配置來動態(tài)決定端口號(在RTSP協(xié)議下，通常為4個連續(xù)的端口)。UDP數(shù)據(jù)包構建完成后，發(fā)送到流媒體服務器ClearServer的IP地址(實際實現(xiàn)中約定端口8888，非強制)。每個UDP數(shù)據(jù)包對應一個端口映射，四個連續(xù)的端口映射形成一組。
然后，ClearServer服務器端有一個clearnat進程，負責接收和處理OCX發(fā)送過來UDP數(shù)據(jù)包。在收到一個UDP數(shù)據(jù)包后，先解析UDP協(xié)議頭部，獲得UDP數(shù)據(jù)包來源的IP地址和端口，也就是NAT服務器的IP地址和端口。接著解析UDP數(shù)據(jù)段，獲得用戶的內(nèi)網(wǎng)IP地址和端口(用戶名和節(jié)目名是用于判斷這個UDP數(shù)據(jù)包是否反映了最新的信息，以防止產(chǎn)生重復和錯誤的映射關系)。再將NAT服務器的IP地址和端口與內(nèi)網(wǎng)IP地址和端口組成一對端口映射關系，并記錄下來，然后接著接收下一個UDP數(shù)據(jù)包。當集齊4個連續(xù)的端口映射后，就把它們作為一組完整的端口映射關系，并將完整的每一組映射關系，通過IPC(進程間通信)方式傳遞給ClearServer的主控服務器。主控服務器接收映射關系組，并保存在關系組記錄表中。
最后，當ClearServer主控服務器需要向客戶端發(fā)送UDP數(shù)據(jù)包的時候，先去查看映射關系組記錄表。對于來自于內(nèi)網(wǎng)的客戶端點播，服務器就用映射關系中的NAT地址、端口替換掉客戶端所在計算機的內(nèi)網(wǎng)IP地址、端口。即，以NAT IP地址、端口作為UDP數(shù)據(jù)包的發(fā)送目的地。
這樣，ClearServer實際上就會向NAT服務器發(fā)送UDP數(shù)據(jù)包，而當數(shù)據(jù)包到達NAT服務器后，就會被正確得轉發(fā)到處于內(nèi)網(wǎng)的客戶端。讓內(nèi)網(wǎng)用戶也能享受視頻點播的服務。


圖1是本發(fā)明的方法結構圖。
圖2是OCX的工作流程圖。
圖3是clearnat進程的工作流程圖。
圖4是主控服務器中處理映射關系并進行地址端口替換的功能模塊的工作流程圖。
具體實施例方式
為了解決現(xiàn)有技術中的問題，本發(fā)明提供了一種新穎的使UDP數(shù)據(jù)包順利穿透網(wǎng)關(NAT服務器)的方法，即ClearNat方法，參見圖1。圖1描述的是ClearNat方法的結構。圖中圓圈的標號反映的是數(shù)據(jù)流程的順序。IP地址和端口僅僅是示例性的。
下面詳細說明ClearNat方法的工作流程。
第一，本發(fā)明需要在內(nèi)網(wǎng)客戶端的點播網(wǎng)頁上運行一個OCX。OCX的工作流程參見圖2。當用戶進行VOD(Video On Demand)點播時，首先會點擊視頻點播網(wǎng)頁上某一個節(jié)目的鏈接。這樣，網(wǎng)頁就會把一些必要的信息傳遞給在網(wǎng)頁上運行的OCX，對應圖中步驟202。信息包括用戶名、點播的節(jié)目名和點播服務器ClearServer的IP地址。OCX接收到這些信息后，就到了步驟204。OCX需要確定本機播放器監(jiān)聽接收UDP視頻數(shù)據(jù)的端口。一般而言，對于Apple公司的QuickTime Player，會以6970為起始，每4個連續(xù)的端口為一個播放器工作。例如，一臺計算機上，第一個QuickTime Player使用端口6970-6973，第二個QuickTime Player使用端口6974-6977，以此類推。對于MicroSoft公司的WindowsMedia Player，可以為它指定接收UDP視頻數(shù)據(jù)的端口，OCX每次動態(tài)地選擇一組空閑的端口供Windows Media Player使用。這樣，OCX就根據(jù)用戶使用的播放器確定本機UDP數(shù)據(jù)接收端口，并綁定。接著進入步驟206，OCX將確定的本機端口號，連同本機IP地址、用戶名、點播節(jié)目名寫入UDP數(shù)據(jù)包的數(shù)據(jù)段中。每個端口對應一個UDP數(shù)據(jù)包，4個合為一組。最后，步驟208中，根據(jù)網(wǎng)頁處得來的ClearServer服務器的IP地址，將步驟206中構建的UDP數(shù)據(jù)包發(fā)向ClearServer的8888端口(實際實現(xiàn)中的約定)?？紤]到內(nèi)網(wǎng)到外網(wǎng)的鏈路一般環(huán)境不會很好，UDP可能會出現(xiàn)丟包，則在步驟208中，可以采取冗余發(fā)送的策略，將每個UDP數(shù)據(jù)包發(fā)送多遍，可以有效降低丟包率。實際上，由復旦大學(內(nèi)網(wǎng)環(huán)境)發(fā)向清華大學(外網(wǎng)環(huán)境)，每個UDP數(shù)據(jù)包發(fā)送3遍就幾乎可以確保沒有丟包。
第二，在UDP流媒體視頻點播服務器ClearServer端，運行一個名為clearnat的進程。它的功能是接收、處理OCX發(fā)過來的UDP數(shù)據(jù)包，并將完整的、最新的端口映射關系組發(fā)送給主控進程。clearnat的工作流程參見圖3。步驟302中clearnat啟動并在約定的8888端口監(jiān)聽，當接收到一個UDP數(shù)據(jù)包后，就開始處理。步驟304，解析UDP協(xié)議頭，獲得NAT服務器的IP地址和端口；解析UDP數(shù)據(jù)段，獲得用戶名、點播節(jié)目名、內(nèi)網(wǎng)IP地址和端口。如果UDP協(xié)議頭中的IP地址與UDP數(shù)據(jù)段中的內(nèi)網(wǎng)IP地址相同，則說明該用戶是在外網(wǎng)上進行點播，不需要用到本發(fā)明的方法，程序繼續(xù)等待下一個UDP數(shù)據(jù)包。如果是內(nèi)網(wǎng)點播，則將NAT服務器的IP地址和端口與內(nèi)網(wǎng)的IP地址和端口組成一個映射關系。然后查詢自己維護的映射關系記錄表(步驟306)，如果有重復的記錄，說明這是個冗余的UDP數(shù)據(jù)包，則簡單地丟棄它；否則再根據(jù)用戶名、點播節(jié)目名來判斷這個映射關系的時效性(步驟308)，即是否反映了最新的用戶點播請求，是，則將這個映射關系記錄(步驟310)；否，則簡單丟棄。進入步驟312，每次記錄下一個映射關系，就去檢查整個映射關系記錄表，看看是否集齊完整的一組映射關系，即，同一個內(nèi)網(wǎng)IP地址上的4個連續(xù)端口的映射關系。如果沒有，就繼續(xù)等待下一個UDP數(shù)據(jù)包的到來；如果得到完整的一組映射關系，就將這一映射關系組，通過IPC(Inter-Process Communication進程間通信)方式傳遞給主控服務器(步驟314)，然后繼續(xù)等待UDP數(shù)據(jù)包。
第三，在主控服務器上，有一個功能模塊，負責處理從clearnat進程發(fā)送過來的信息，并在服務器發(fā)送UDP數(shù)據(jù)前進行必要的IP地址和端口的替換。圖4描述了這個功能模塊的流程。它在主控服務器的消息循環(huán)中等待來自clearnat的信息(步驟402)，接收到clearnat發(fā)送過來的映射關系組信息后(步驟404)，首先到自己的映射關系組記錄表中查詢是否有相同的記錄(步驟406)，如果有相同的記錄則丟棄此映射關系組，繼續(xù)等待映射關系組信息，如果沒有則把此記錄添加到記錄表中(步驟408)。每當有客戶端的點播請求到達主控服務器時(步驟410)，就去映射關系組記錄表中查詢，看看是否有對應該用戶的映射關系記錄(步驟412)，如果沒有，則表明該用戶是普通的外網(wǎng)點播客戶端，無需使用本發(fā)明的方法，(步驟414)；如果有，則表明該用戶是通過內(nèi)網(wǎng)點播的客戶端，那么在向這個客戶端發(fā)送UDP數(shù)據(jù)的時候，就用映射關系組中的NAT服務器IP地址和端口，替換內(nèi)網(wǎng)IP地址和端口。
本發(fā)明的性能如下復雜度N個客戶端，處理NAT信息所需要多做的計算包括加減計算和查表計算計算復雜度為O(N2)。
處理時間ClearNat信息處理中主要是對信息表的查詢和處理操作。表1是信息表查詢操作所需的CPU時間進行測試。測試環(huán)境處理器迅馳1.5G，內(nèi)存512M，操作系統(tǒng)WindowsXP。

表1 查詢表操作所需CPU時間主控進程對NAT端口映射表的查詢和處理等操作所需時間非常少，即使NAT端口映射表中的節(jié)點數(shù)目達到100000，做一次查詢和處理所需的時間也基本上會小于1ms。
對并發(fā)數(shù)的影響由于查表操作所需時間比較少，只有客戶端達到100000以上時每次查表操作所需時間才超過10ms。當N＝1000000時，這對于主控進程(Main Process)的調(diào)度也許就會帶來一些困難。但是這個并發(fā)數(shù)是在假定每個客戶都是內(nèi)網(wǎng)用戶，并通過NAT服務器進行視頻點播。在實際應用中，服務器的客戶肯定有很大一部分是通過公網(wǎng)直接連接到流媒體服務器上進行視頻點播的。
總之，采用本發(fā)明所述的ClearNat方法，可以讓流媒體服務器ClearServer發(fā)送的UDP數(shù)據(jù)包順利穿透網(wǎng)關(NAT服務器)，為處于內(nèi)網(wǎng)的客戶端提供優(yōu)質的視頻點播服務。
本公開的方式描述了本公開和本發(fā)明的最佳模式，應該理解并且認識到，有許多等效于在此公開的示例性實施例的方式，并且在不脫離本發(fā)明的范圍和精神的情況下可以進行修改和變形，本發(fā)明不受示例性實施例的限制而只受附加的權利要求的限制。
權利要求
1.一種使流媒體服務器ClearServer可以識別內(nèi)網(wǎng)客戶端的IP地址和端口號，將服務器端的多媒體數(shù)據(jù)順利發(fā)送到客戶端的方法，其特征在于具體步驟如下a.將一個OCX運行在客戶端瀏覽的點播網(wǎng)頁上；當用戶點擊網(wǎng)頁上的點播鏈接后，由網(wǎng)頁告知OCX，用戶名信息、用戶點播節(jié)目的信息和流媒體服務器ClearServer的IP地址；OCX根據(jù)這些信息構建UDP數(shù)據(jù)包，其中數(shù)據(jù)段的內(nèi)容包括用戶的內(nèi)網(wǎng)IP地址、內(nèi)網(wǎng)UDP接收端口和點播的節(jié)目名稱；UDP數(shù)據(jù)包構建完成后，就會發(fā)送到流媒體服務器ClearServer的IP地址(實際實現(xiàn)中約定端口8888，非強制)。每個UDP數(shù)據(jù)包對應一個端口映射，四個連續(xù)的端口映射形成一組；b.ClearServer服務器端有一個clearnat進程，負責接收和處理OCX發(fā)送過來UDP數(shù)據(jù)包；在收到一個UDP數(shù)據(jù)包后，解析UDP協(xié)議頭部，獲得UDP數(shù)據(jù)包來源的IP地址和端口；解析UDP數(shù)據(jù)段，獲得內(nèi)網(wǎng)的IP地址和端口；clearnat將完整的一組映射關系通過IPC(進程間通信)方式發(fā)送給主控服務器；c.主控服務器接收映射關系組，并保存在映射關系組記錄表中；當主控服務器需要向客戶端發(fā)送UDP數(shù)據(jù)包的時候，先去查看映射關系組記錄表，對于來自于內(nèi)網(wǎng)的客戶端點播，服務器就用映射關系中的NAT地址、端口替換掉客戶端所在計算機的內(nèi)網(wǎng)IP地址、端口。
2.如權利要求1所述的方法，其特征在于，在步驟b中，包括將NAT服務器的IP地址和端口和內(nèi)網(wǎng)IP地址和端口組成一對端口映射關系，并記錄下來，然后接著接收下一個UDP數(shù)據(jù)包；當集齊4個連續(xù)的端口映射后，就把它們作為一組完整的端口映射關系，并將完整的每一組映射關系，通過IPC(進程間通信)方式傳遞給ClearServer的主控服務器進程。
全文摘要
本發(fā)明屬于網(wǎng)絡多媒體技術領域，具體是使流媒體服務器發(fā)送的UDP(用戶數(shù)據(jù)報協(xié)議)數(shù)據(jù)包穿透網(wǎng)關的一種方法，即ClearNat方法，。根據(jù)該方法流媒體服務器ClearServer可以識別內(nèi)網(wǎng)客戶端的IP地址和端口，將NAT服務器的IP地址和端口與內(nèi)網(wǎng)客戶端的IP地址和端口做一個映射，通過替換IP地址和端口，將服務器端的UDP數(shù)據(jù)發(fā)送到NAT服務器，再由NAT服務器把數(shù)據(jù)轉發(fā)到處于內(nèi)網(wǎng)的客戶端，實現(xiàn)穿透網(wǎng)關，從而有效的在因特網(wǎng)中實時傳送多媒體信息。該方法的計算復雜度較低，效果很好，對主控服務器的其他應用進程沒有影響，且在流媒體服務器ClearServer中能支持大的內(nèi)網(wǎng)并發(fā)用戶的使用。
文檔編號H04L12/56GK1694430SQ200510026160
公開日2005年11月9日 申請日期2005年5月25日 優(yōu)先權日2005年5月25日
發(fā)明者葉德建, 孫澔峻, 張佐 申請人:復旦大學