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 天文观测对数据完整性的要求，允许设定可容忍的丢包率，并根据该值进行尽力传输。【本文图均略】
