1 研究背景及現狀
甚長基線干涉測量\\(VeryLongBaselineInterferometry,VLBI\\) 是目前空間分辨率最高的天文觀測技術，在天文觀測領域得到了廣泛的應用。運用 VLBI 技術和分布在全球不同地域上的射電望遠鏡對同一目標進行觀測，其效果相當于一個直徑為各射電望遠鏡最大基線距離的虛擬望遠鏡。因此，各望遠鏡之間基線越長，所獲取的空間分辨率越高；射電望遠鏡采集數據的頻率越高，所獲得的測量精度也越準確。
近年來，隨著網絡通訊和計算機技術的進步，e-VLBI 在傳統 VLBI 的基礎上迅速發展。傳統 VLBI觀測是將射電望遠鏡觀測到的無線電信號經過變頻、采樣和格式轉換后生成的海量觀測數據先記錄在特殊的大容量磁帶上，之后通過其他途徑傳遞到 VLBI處理機上進行處理。因此實時性差，處理周期長。
e-VLBI 通過高速互聯網將分布于全球各地的觀測站聯系起來，同步觀測，利用高速通訊網絡代替磁盤，將來自各觀測站的數據直接傳到數據中心進行處理，大大縮小了觀測周期。由于 e-VLBI 相對于傳統VLBI，具有反應快、精度高等顯著優勢，目前得到了迅速發展，在日本和歐美的許多發達國家已進入實用階段。美國 NASA \\(National Aeronautics and SpaceAdministration\\) 已將 e-VLBI 用于常規深空探測導航，歐洲和澳大利亞也利用下一代科研互聯網 Geant2 和AARnet 從事天體物理實時 e-VLBI 觀測。在日本，利用自建的 10G 帶寬的下一代高速互聯網，已開展地球自轉參數快速測量和測地觀測的 e-VLBI 常規模式。國際上，每年都會召開一次 e-VLBI 研討會，討論 e-VLBI 技術進展，并進行聯合觀測演示。
我國目前已建成了包括“4 站 1 中心”的中國VLBI 觀測網 \\(China VLBI Network, CVN\\)。如圖 1 所示，4 個天文觀測站分別位于北京、烏魯木齊、昆明和上海，而數據中心則位于上海。其中最長基線\\(烏魯木齊-上海\\) 為 3 249km。觀測站和數據中心之間由專網連接，目前采用 TCP 協議來進行數據傳輸。CVN 網為嫦娥一號衛星 \\(CE-1\\) 順利奔月發揮了重要作用。
e-VLBI 數據傳輸作為高速長距離網絡傳輸的一種特殊應用，有其自身的特點，主要包括以下三個方面：
\\(1\\) 數據傳輸速率高，傳輸距離遠e-VLBI 數據傳輸的速率要求與觀測精度有關，觀測精度越高，速率要求也越高。例如毫米波 VLBI觀測網采樣速率 2G sample/s ~ 8G sample/s，采樣字長為 2bit ，需要的數據速率為 4Gbps ~ 16Gbps。目前在進行 e-VLBI 觀測時典型的速率是 128Mbps ~ 2Gbps/站。隨著 e-VLBI 技術的不斷發展，觀測精度越來越高，產生的數據量越來越大，傳輸速率也在不斷增長。2011 年國外已經成功進行了 16Gbps/ 站的觀測試驗，并計劃發展 128Gbps/ 站的速率。在傳輸距離方面，數據傳輸的時延 RTT 根據觀測站到處理中心的距離而不同。國內 e-VLBI 觀測最長距離為烏魯木齊到上海的 3 249km，而上海佘山 VLBI 觀測基地距離歐洲天文聯合研究中心 JIVE \\(Joint Institute For VLBIIn Europe\\) 為 9 000km，RTT 更高達 355ms。中國目前已經加入 JIVE，國際間的 e-VLBI 觀測合作將更加頻繁。據統計，TCP 協議在帶寬 622Mbps、RTT 300ms 的鏈路上進行數據傳輸時，一旦丟包事件發生，其窗口恢復時間高達 41 分鐘。因此如何在長距離網絡上有效利用帶寬依然是當今網絡研究的一大難題。
\\(2\\) 數據傳輸要求穩定性在 e-VLBI 天文觀測過程中，數據采集的頻率和采樣字長是恒定的。因此，數據采集時將會產生海量、高速但速率恒定的數據流，并通過高速網絡以穩定的速率將這些數據傳輸到處理中心。VLBI 數據在進行回放時，希望能與采集時保持一致的恒定速率，這對數據傳輸的穩定性提出了很高的要求。由于 e-VLBI 數據采集的特點，其傳輸速率一般都是 2的 n 次方。目前各個國家的 e-VLBI 傳輸大都由本國的科研網絡為其提供網絡支持，例如新西蘭 e-VLBI傳輸由 KAREN 提供網絡服務，而在中國，CVN 的e-VLBI 數據傳輸由中國科技網 \\(CSTNET\\) 為其提供支撐。
\\(3\\) e-VLBI 傳輸要有可靠性保障e-VLBI 的傳輸允許 bit 位出錯，但不允許 bit 位的增加或丟失。由計算性質所決定，e-VLBI 數據傳輸允許有少量的丟包，在此種情況下，處理中心在處理時會進行填 0 占位處理，相當于添加了噪聲。e-VLBI 能夠容忍的丟包率要求不大于 0.01%，因此要求網絡傳輸提供很高的可靠性保證。如果能夠在速率恒定的情況下不發生數據包的丟失，其觀測效果會更好。
不同的 VLBI 數據采集系統采用不同的數據格式。當前，一種新的統一的 VLBI 數據交換格式標準已制定出來，命名為 VDIF \\(VLBI Data InterchangeFormat\\)。VDIF 用于實時 e-VLBI 和傳統 VLBI 數據間的格式轉換?；?VDIF 數據格式設計的傳輸協議，稱之為 VTP \\(VDIF Transport Protocol\\) 協議。美國 MIT 大學和 JIVE 等單位研究人員正在研究 VTP協議。
2 相關工作
理想的 e-VLBI 數據傳輸協議首先要支持 VLBI標準數據格式 VDIF，其次應具有高速、穩定、可靠的傳輸性能保證。由于 e-VLBI 觀測所產生的數據量大，各觀測站間的距離遠，e-VLBI 的數據傳輸對傳統網絡提出了很高的挑戰。傳統的 TCP 協議在高速長距離傳輸網絡中的性能差，這一方面是因為 TCP 的擁塞控制算法 AIMD \\(Additive-Increase/Multiplicative-Decrease\\) 過于保守，另一方面是 TCP對丟包事件的誤解造成的。因此，也有一大批的學者針對這些問題對 TCP 協議進行改進，產生了一系列的 TCP 改進協議，如：ACP、HSTCP、FAST、BIC 等。這些協議在一定程度上提高了傳輸效率，但由于是針對普通應用在共享網絡上的傳輸，強調絕對公平性及嚴格的網絡擁塞控制，在應用于 e-VLBI這種特殊的海量數據傳輸應用時，其傳輸性能受鏈路質量影響特別大，仍然不夠理想。目前國際上在進行e-VLBI 數據傳輸時所采用的傳輸協議并沒有一定的標準。CVN 采用 TCP 協議進行數據傳輸，其傳輸效率有待提高。新西蘭采用的是 UDT 協議，UDT協議使用帶寬估計算法，擁塞窗口無限接近帶寬值。
也有一些機構采用 Tsunami 協議進行 e-VLBI 數據傳輸。由于 VTP 被提出的時間比較晚，目前國際上正在研究按照 VTP 標準設計 VLBI 數據傳輸協議。日本信息通訊研究院 NICT 設計了一種 VTP 協議，名為SUDP \\(simple-UDP\\) 協議。SUDP 主要機制是在 UDP協議的基礎上，增加了序列號等信息，以保證數據包的按序交付。SUDP 協議支持 K5/VSSP32、Mark5B和 VDIF 等多種 VLBI 數據格式，并提供了內存、文件和硬件接口間的相互傳輸模式。同時，SUDP 還提供了 VDIF 和其他 VLBI 數據格式之間的轉換，是一種典型的 VTP 協議。
SUDP 在發送端和接收端共建立了兩條連接，一條用 UDP 協議進行 VLBI 數據的傳輸，而另一條TCP 連接用于在初始階段進行參數的協商和傳輸控制。在 SUDP 協議內部，除了數據傳輸主線程外，還有數據模型線程和測量線程同時進行工作。數據模型線程負責數據接口 \\(內存、文件或硬件接口\\) 同協議之間的數據交換，而測量進程則負責發送/接收速率的測量和丟包率的顯示。
從圖 2 可以看出 SUDP 發送過程由 Sender、Receiver 和 Control 等模塊組成。Sender 除了能夠支持多種外設接口外，還能夠以 VDIF 的格式傳輸VLBI 數據。目前 SUDP 的 Control 模塊功能比較簡單，主要負責傳輸之前的參數協商，如 VLBI 的傳輸模式、發送端/接收端的地址和端口等。接收端在收到數據包后，會按照當前時間戳和數據包內的 VLBI數據幀編號進行地址定位，并將接收到的數據復制到該內存位置。SUDP 具有速率控制機制，能夠按照指定的速率傳輸數據。經過 SUDP 作者 Mamoru Sekido的實際傳輸實驗驗證，SUDP 能夠以固定的速率傳輸VLBI 數據，并能進行數據格式間的有效轉換。
SUDP 僅僅保證按序交付，沒有反饋機制和重傳機制，數據傳輸沒有可靠性保證，這對于 SUDP 的實用性提出了很大的挑戰。我們在前文已經提到，e-VLBI 數據傳輸必須以恒定的速率進行傳輸，當網絡性能很差，丟包率嚴重的情況下，e-VLBI 數據傳輸就應當降低速率檔次 \\(降低精度\\) 進行傳輸。因此，在進行 e-VLBI 數據傳輸時，首先必須保證具有高于傳輸速率要求的網絡物理帶寬。在網絡物理帶寬允許的條件下，為提高傳輸的可靠性，e-VLBI 的數據傳輸協議也應當能夠自動重傳一些意外丟失的包。本文在 SUDP 的基礎上進行改進，為其添加傳輸控制模塊，命名為 RSUDP。RSUDP 能夠有效使用帶寬資源，并盡最大努力進行數據的重傳，以提高其可靠性保證。
3 RSUDP 協議設計和實現
3.1 設計目標
為滿足 e-VLBI 的數據傳輸要求，RSUDP 根據以下目標設計：
\\(1\\) 高速。RSUDP 的發送速率在傳輸前雙方已經進行了協商。發送速率的大小不僅與 VLBI 數據采集器的采集頻率和采集字長相關，而且與發送方和接收方的硬件資源也有很大的關系。在帶寬和硬件資源支持的情況下，RSUDP 應當能夠保持高速的發送和接收速率。
\\(2\\) 穩定。RSUDP 應當能夠以接近恒定的速率進行數據的傳輸，發送端和接收端的數據傳輸率應當保持平衡。即便有丟包現象產生，發送速率和接收速率也不應該出現劇烈的波動。
\\(3\\) 可靠。RSUDP 應當具有重傳機制，對丟失的數據包盡最大努力進行重傳。由于發送端以高速恒定的速率發送數據，因此在網絡環境差的情況下，重傳失敗是可能發生的。在這種情況下，RSUDP 應當對丟包率進行實時監測，以方便操作人員進行調整。
3.2 設計思想
e-VLBI 數據傳輸要求高速、穩定和可靠。要實現這一目標，主要有兩種思路：一種思路是通過更改TCP 的擁塞窗口機制來對 TCP 協議進行改進，另一種思路則是在 UDP 基礎上為其添加可靠傳輸機制。
TCP 是可靠傳輸協議，無法對丟包的差錯率進行控制，也不能以恒定的速率進行數據的發送，靈活性不高。UDP 沒有速率控制和重傳機制，無法直接滿足傳輸需求。SUDP 在 UDP 基礎上已經添加了序列號，能夠以恒定速率發送數據，而且實現了 VLBI 傳輸的多種數據格式和接口。因此 RSUDP 將在 SUDP基礎上進行改進，為其添加重傳機制，以提高數據傳輸的可靠性保證。
RSUDP 在發送端和接收端之間建立了兩條連接。一條 UDP 連接用于以恒定速率發送 VLBI 數據，這與 SUDP 的機制是相同的。另一條 TCP 連接則用于向發送端反饋重傳信息。RSUDP 改進如圖 3 深灰色部分所示。在發送端，守護線程等待對丟失數據包的監聽，并通過發送端的重傳機制對這些丟失數據包進行重傳。而在接收端，重傳模塊對接收到的數據包進行注冊，通過一定的機制檢測丟包，向發送端發送反饋信息要求重傳。為了盡量減少對 SUDP 原協議的修改，我們以插件的方式為 SUDP 添加了 Controller模塊，即重傳機制。
RSUDP 協議以 DataPages 作為協議和數據模型之間的內存管理方式。數據輸入線程向 DataPages 中寫入數據，主發送線程則從 DataPages 中讀出數據，之后以恒定速率進行發送。接收端接收數據后，通過丟包檢測模塊和反饋線程向發送端反饋重傳信息。當發送端接收到重傳數據包請求時，重傳線程會首先檢查該數據包是否在 DataPages 中存在，如果存在，則發送端會優先重傳這部分數據。一個 DataPage 的大小目前設定為一秒鐘的數據傳輸量，協議內共設置了6 個 DataPage，按照 RTT=200ms 來計算，一個丟失包的重傳必須在 25 個 RTT 內完成。在如此長的時間內，重傳一般是能夠成功的，因此，為了不影響主線程以恒定速率發送 VLBI 數據，Controller 只按照最大努力進行數據重傳，對于無法重傳的數據包直接放棄，以避免數據發送線程進入等待狀態而造成發送速率的劇烈波動。
3.3 RSUDP 協議實現
3.3.1 發送端協議實現
發送端和接收端的 TCP 連接在數據傳輸前已經建立，之后發送端重傳線程便進入等待狀態。RSUDP的包頭沿用 SUDP 格式 \\(圖 4\\)，是由 SUDP 包頭、VLBI Frame 包頭和 VLBI 數據組成。同一 DataPage內的數據組裝成 SUDP 報文后，只有 SUDP 序列號、VLBI Frame 序列號和數據部分不同。因此，當我們對發送過的 DataPage 記錄一些必要信息后，便可以根據重傳包的序列號組裝成新的數據包發送出去，從而達到發送線程和重傳線程間的內存共享。Controller 用于記錄重傳信息的結構體為MemState，一個 DataPage 對應于一個 MemState，按照前文的敘述，Controller 中共有六個 MemState 對象。MemState結構如圖 5 所示。
在發送端，DataSend 主線程在發送 DataPage 內的數據之前，Controller 模塊會將相應的信息記錄在 MemState 中。重傳守護線程在接收到重傳包序號后，根據 MemState 中的序號區間去查找其對應的MemState。如果查找到，則說明該序號的數據包尚未被主發送線程覆蓋，Controller 則根據該重傳包的序號、重傳包在 DataPage 中的相對位置、Datapage 數據指針等信息，重裝該數據包并發送。如果重傳包序號不在任何 MemState 對象記錄的序號區間內，則說明該序號的數據包已經被主發送線程覆蓋，Controller將放棄此次重傳，并在日志中記錄此次丟包事件。
3.3.2 接收端協議實現
在接收端，Controller 使用 ACKQueue 機制來檢測數據包的丟失和亂序。ACKQueue List 里存放了一系列的 ACKQueue 結構體，該結構體包含了一些控制變量和 bit 數組。其結構如圖 6 所示。主接收線程在接收到新的數據包后，調用Controller 的接口對該數據包序號進行注冊即可。
Controller 會根據 ACKQueue List 中各結構的 ackBase和 queueLen，將該數據包序號對應的bit位設置為真。由于大部分的數據包是按序到達的，因此Controller 模塊會記錄當前的 ACKQueue，從而避免對整個隊列進行檢查。當接收到的數據包序號超過當前 ACKQueue 范圍時，Controller 會生成新的ACKQueue 對象，并將其放入隊列之中。按照這種機制，隊列是有序的，因此當重傳包到達時 Controller從尾部開始檢查 ACKQueue List，并設置其對應的 bit位。接收線程根據時間戳定位 DataPage，之后根據SUDP 包內的 Frame ID 定位數據接收位置，從而使得接收線程能夠對 DataPage 進行直接定位并接收數據，而 Controller 便可以只負責丟包的檢測和重傳。
每當有新的 ACKQueue 對象產生時，Controller便會對整個隊列進行檢查。對于沒有數據包丟失的ACKQueue，Controller 直接將其刪除，以節省內存空間。前文我們已經提到，數據包的重傳次數是有限制的 \\(目前設定最大重傳次數為 20\\)，因此 Controller 會將重傳次數過多的 ACKQueue 也刪除掉，以避免隊列過長，影響重傳模塊的效率。通過這種機制，接收端 ACKQueue 所占的內存空間便大大減少了。初步估計，在發送速率 512Mbps、MTU 為 1500Byte 時，ACKQueue 隊列的大小最多不會超過 5M。RSUDP 的內存消耗依然主要集中在數據緩沖區中，重傳機制所消耗的內存是微不足道的。
根據 TCP 的超時重傳機制，發送端在大約 3 個RTT 的時間仍未收到確認就會自動對該數據包進行重傳。RSUDP 借鑒這種思想，每隔 3 個 RTT 的時間便向發送端要求重傳丟失包。為了節約 Controller的開銷，我們將 ACKQueue 的 queueLen 設置為約一個 RTT 時間內所接收到的數據包數量。Controller在對隊列進行檢查時，將所有 ACKQueue 的重傳次數都加 1，而事實上 Controller 只對重傳次數是3的倍數的 ACKQueue 進行重傳。因此，在理想情況下Controller 不用計時器便可每隔 3 個 RTT 的時間對丟失包進行重傳，符合實際需求。用這種方法代替計時器并不準確，可能會造成數據包的多次重傳。但是VLBI 傳輸大多是在專網傳輸，數據傳輸率高，丟包率比較小，這種方法大大減少了接收端 Controller 的開銷，部分數據包的多次重傳是可以接受的。
4 實驗分析與結論
我們在實驗環境下對 RSUDP 進行了測試。如圖 7 所示，實驗床由兩臺主機和一臺 Linux 服務器構成，Linux 服務器作為交換機，并用 netem 和 TC\\(Traffic Control\\) 來仿真網絡環境。Netem 是 Linux2.6及以上內核版本提供的一個網絡模擬功能模塊，能夠在性能良好的局域網中仿真出復雜的互聯網傳輸性能，如帶寬、延遲、丟包等情況。
參照 e-VLBI 數據傳輸的實際網絡狀況，我們將實驗環境參數設置為：帶寬 622Mbps \\(長途鏈路帶寬\\)，時延 200ms \\(國際聯測時的時延\\)，丟包率 1% \\(為檢驗在網絡環境不理想的情況下RSUDP的重傳能力\\)。
之后以 512Mbps 的恒定速率發送 VLBI 數據，發送速率和接收速率如圖 8 所示。圖中之所以發送速率和接收速率都高于 512Mbps，是因為 VLBI 的發送速率指的是 VLBI 數據率，而網絡在傳送數據時會加上 UDP 包頭、SUDP 包頭等額外開銷，這部分開銷在 MTU 為 1 500Bytes 時占 5.2% 左右。在這種情況下，256Mbps 的傳輸率至少要 269.2Mbps 的鏈路，512Mbps 的傳輸率至少需要 538.5 Mbps 的鏈路。
SUDP 包頭所占的開銷根據鏈路 MTU 的不同而不同，因此實際速率要略高于發送速率。圖 8 顯示了發送端和接收端的速率，紅色部分代表發送端速率，綠色部分顯示的是接收端速率。從圖中可以看出接收端以接近于發送端的速率接收數據，速率波動很小。發送端所產生的小的波動是由丟失包重傳造成的，速率控制機制控制的是主線程的發送速率，重傳線程的發送速率不受限制，因此總體上出現了小的波動。圖 9 對比了 RSUDP 和 SUDP 的丟包率情況。
紅色部分代表的是 SUDP 的丟包率，從圖中可以看出，SUDP 沒有重傳機制，實際丟包情況比較嚴重，平均在 1.35% 左右。RSUDP 的初次丟包率要高于SUDP，但由于 RSUDP 對大部分的丟失數據包進行了重傳，其實際丟包率在 0.01% 左右。圖中 RSUDP在第 22 秒和 75 秒處出現了較大的丟包，這是因為我們向網絡中注入了 80Mbps 的 UDP 流，以模擬網絡擁塞情況。網絡擁塞導致 RSUDP 無法利用空余帶寬對丟失包進行重傳，從而造成丟包率的上升。由于RSUDP 需要以恒定速率發送數據，這與擁塞控制是相矛盾的，因此 RSUDP 自身不具有擁塞控制機制，只能適應短時間小范圍網絡擁塞。
圖 10 顯示了 RSUDP 和 SUDP 在北京到上海的網絡中進行傳輸的丟包情況。經過 Iperf 測試，網絡可用帶寬為 750Mbps，RTT 在 20ms 左右。RSUDP和 SUDP 以 512Mbps 的恒定速率進行傳輸。從圖中可以看到，由于主干網絡中丟包發生的概率很小，而且 RSUDP 的傳輸速率低于網絡可用帶寬，在開始和結尾部分 RSUDP 和 SUDP 的丟包都趨于零。由于在真實環境中，大部分時間網絡丟包率非常小，為實驗協議在網絡發生擁塞時的性能，從第 20 秒開始，我們向網絡中隨機注入了 200Mbps ~ 500Mbps 的數據流，以生成網絡擁堵。此時 RSUDP 和 SUDP 都產生了丟包，但 RSUDP 的重傳機制使得 RSUDP 的丟包率遠遠低于 SUDP。圖中綠線部分丟包率在零值以下表示此時的重傳數據包數量高于丟失數據包數量，這說明 RSUDP 正在對上一時刻的丟包進行重傳。實驗證明，當網絡擁塞發生時，RSUDP 能夠對丟失數據包進行有效重傳。
5 小結
本文面向 e-VLBI 天文數據傳輸這種特殊的網絡應用，基于 SUDP 協議，設計了一種改進的傳輸協議 RSUDP 協議，通過設計丟包重傳機制，在保證高傳輸速率的同時，RSUDP 協議提高了 SUDP 協議的傳輸可靠性。為了減輕 RSUDP 接收端的資源開銷，我們所添加的網絡重傳機制是輕量級的，這一方面符合 e-VLBI 數據傳輸時以恒定速率發送數據的需求，另一方面也以最大努力對丟失數據包進行重傳。下一步，我們將進一步根據不同 e-VLBI 天文觀測對數據完整性的要求，允許設定可容忍的丟包率，并根據該值進行盡力傳輸?！颈疚膱D均略】
