[發明專利]基于UDP協議的數據傳輸方法

無效

• 申請號: 200910010076.1
• 申請日: 2009-01-13
• 公開（公告）號: CN101778093A
• 公開（公告）日: 2010-07-14
• 發明（設計）人: 蔣一;李德寶
• 申請（專利權）人: 蔣一
• 主分類號: H04L29/06
• 分類號: H04L29/06;H04L12/56
• 代理公司: 大連智慧專利事務所 21215
• 代理人: 劉琦

技術領域

本發明涉及一種互聯網中數據傳輸的方法，更具體地說，涉及一種基于UDP協議的數據傳輸方法。

背景技術

TCP(Transmission?Control?Protocol)，傳輸控制協議，主要用于在主機間建立一個虛擬連接，以實現高可靠性的數據包交換。IP協議可以進行IP數據包的分割和組裝，但是通過IP協議并不能清楚地了解到數據包是否順利地發送給目標計算機。而使用TCP協議就不同了，在該協議傳輸模式中在將數據包成功發送給目標計算機后，TCP會要求發送一個確認；如果在某個時限內沒有收到確認，那么TCP將重新發送數據包。另外，在傳輸的過程中，如果接收到無序、丟失以及被破壞的數據包，TCP還可以負責恢復。

TCP是一種面向連接的、可靠的、基于字節流的運輸層通信協議，通常由IETF的RFC?793說明。在簡化的計算機網絡OSI模型中，它完成運輸層所指定的功能。

UDP(User?Datagram?Protocol)，用戶數據報協議，是OSI參考模型中一種無連接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務。UDP協議基本上是IP協議與上層協議的接口。UDP協議適用端口分別運行在同一臺設備上的多個應用程序。

由于大多數網絡應用程序都在同一臺機器上運行，計算機上必須能夠確保目的地機器上的軟件程序能從源地址機器處獲得數據包，以及源計算機能收到正確的回復。這是通過使用UDP的“端口號”完成的。例如，如果一個工作站希望在工作站128.1.123.1上使用域名服務系統，它就會給數據包一個目的地址128.1.123.1，并在UDP頭插入目標端口號53。源端口號標識了請求域名服務的本地機的應用程序，同時需要將所有由目的站生成的響應包都指定到源主機的這個端口上。UDP端口的詳細介紹可以參照相關文章。

UDP協議使用IP層提供的服務把從應用層得到的數據從一臺主機的某個應用程序傳給網絡上另一臺主機上的某一個應用程序。其特點如下：

1、UDP傳送數據前并不與對方建立連接，即UDP是無連接的，在傳輸數據前，發送方和接收方相互交換信息使雙方同步。

2、UDP不對收到的數據進行排序，在UDP報文的首部中并沒有關于數據順序的信息(如TCP所采用的序號)，而且報文不一定按順序到達的，所以接收端無從排起。

3、UDP對接收到的數據報不發送確認信號，發送端不知道數據是否被正確接收，也不會重發數據。

4、UDP傳送數據較TCP快速，系統開銷也少。

從以上特點可知，UDP提供的是無連接的、不可靠的數據傳送方式，是一種盡力而為的數據交付服務。問題在于，TCP協議在網絡發展的前期，適用于所有的用戶。在前期使用網絡的用戶，每個人都擁有一個公共的固定的ip地址，隨著用戶的增多，ip地址資源開始變得匱乏。為了解決ip資源匱乏的問題，nat(網絡地址轉換器)設備出現了，大的網絡用戶集群使用局域網地址，訪問公共網絡時分配臨時的公網地址的方式，解決了ip匱乏問題。但是也直接導致了網絡狀態的復雜化，并直接影響了TCP協議的適用范圍。用戶與用戶之間使用TCP協議共享資源時，絕大多數情況都無法進行。UDP協議可以穿越絕大多數的nat設備共享用戶資源，但是UDP協議的無連接以及不可靠傳輸的特點，使得共享資源的過程變得異常艱難。

發明內容

本發明提供一種基于UDP協議實現互聯網中兩個客戶終端之間數據的可靠傳輸方法，旨在彌補TCP協議下對傳輸數據因IP地址數量有限而受到的限制問題。

本發明一種基于UDP協議的數據傳輸方法，包括如下步驟：

(S1)發送終端將待發送的文件分成數據包，為數據包設置序號，以便接收終端將各個數據包重新恢復為發送的文件；

(S2)發送終端設置三個隊列，包括等待發送數據隊列、等待應答數據隊列和補發數據隊列。其中，等待發送數據隊列，將數據包信息以先進先出的方式按序排列，并且基于UDP協議建立傳輸鏈路實現數據包的傳輸；

(S3)當等待發送數據隊列中的一個數據包數據全部發出后，將該數據包信息從等待發送數據隊列放入所述等待應答數據隊列，等待所述接收終端應答；當接收終端應答接收成功時，等待應答數據隊列刪除成功傳輸的數據包信息；

(S4)當接收終端對所述等待應答數據隊列中的數據包超時或未應答，則將該數據包放入補發數據隊列，用于等待重新放入等待發送數據隊列進行發送。