MS-TDS 协议加速策略的研究与实现

吴超，段桂华，黄俊杰，黄家玮，马宇超，吕清娇

(1. 中南大学 信息科学与工程学院，湖南 长沙，410083；2. 中国人民解放军75660 部队，广西 桂林，541002)

随着网络技术的发展和网络应用的普及，对网络性能的需求也越来越高，主要表现在速度要求、存储开销和通信代价等方面。基于这种需求，各网络公司和研究单位纷纷投入大量人力物力以寻求提高带宽利用率以及用户体验的解决方案[1]。其中，广域网加速方案是研究热点。这是因为目前分布式企业增多，企业分支与公司总部之间的网络建设不断完善，很多企业倾向于建设集中的数据中心，使得跨网段的使用广域网作为传输网络的异地海量数据存取逐渐普遍。为了解决广域网中由于带宽限制和高时延造成的数据中心访问速度低的问题，近年来，涌现出一大批加速设备厂商如Cisco[2]，Riverbed[3]，Juniper[4]及深信服[5]和QuickBi[6]等。采用的加速策略主要有传输协议优化、数据优化和应用协议优化[7]，相应的技术主要有拥塞控制、数据缓存、数据压缩和数据预取等[8]。数据库是信息系统的基础，担负着保存单位核心数据的重要使命，国内外基于数据库的企业办公自动化系统遍布各行各业，其拥有极为广泛的用户群体。Microsoft Project 是目前国际上最为盛行与通用的项目管理软件，适用于新产品研发、IT、房地产、工程、大型活动等多种项目类型[9]。Microsoft Project 用户通过客户端直接访问服务器所连接的数据库，利用MS-SQL TDS(tabular data stream)协议进行数据库读取、存储或更新项目。MS-SQL TDS 是微软开发的一个应用层协议，用于SQL Server 数据库与客户端之间的通信。作为一种建立在TCP/IP Net-Library 之上的数据传输协议，TDS描述了客户端与服务器之间数据传输的规则、数据类型以及消息传输的秩序[10]。虽然MS-SQL TDS能保证客户端直接与数据库进行通信，但在广域网环境下，由于会受到低带宽和高延迟的局限，TDS 的传输性能急剧下降，进而会对整个协作环境造成影响，成为项目运行的瓶颈[11]。在目前已有的协议加速策略中，研究得比较多的是传输协议TCP[12-13]。在应用层协议中，有针对通用Internet 文件系统CIFS[14]和邮件应用程序接口MAPI[15]等协议的加速策略研究，但对于数据库协议，暂时还没有很好的加速方案。为此，本文作者研究针对TDS 协议的加速目标，提出有效可行的解决方案，以提高数据中心的访问速度，并为其他数据库协议的加速方法研究提供参考。

1 TDS 协议分析

表格格式数据流协议(TDS 协议)是微软公司的SQL Server 数据库服务端与客户端所遵循的通信协议，是一种请求与响应模式的应用层协议。由于TDS会话是建立在TCP 之上的[13]，这意味着当TCP 连接建立并且服务器收到客户端建立TDS 连接的请求数据包时，TDS 会话将会被建立，并一直持续到TCP连接终止。一旦TCP 长连接成功建立，TDS 消息将会在客户端与服务器之间进行传输。由于TDS 建立在TCP 之上，所以，TDS 的数据是可靠的、按序到达的。

1.1 TDS 协议头分析

通过对捕获到的数据包分析发现，TDS 存在公共包头，它是不同类型的数据包所共有的包头，也是识别TDS 数据包的唯一标准。TDS 公共包头长8 字节，其具体结构如图1 所示。

图1 中，type(1 Byte)标识TDS 消息类型，常用消息类型的含义如表1 所示；status(1 Byte)定义为TDS消息的状态；length(2 Byte)表示应用层数据长度；channel(2 Byte)传递服务器与客户端的进程ID；packnum(1 Byte)表示数据包序号；windows(1 Byte)表示在确认信息收到以前必须发送的框架数目。

表1 type 字段的值及其含义Table 1 Values and descriptions of type field

1.2 RPC 消息分析

TDS 协议头之后封装了数据段，也称为消息。如表1 所示，消息有多种类型，不同的消息完成不同的功能。其中，与优化相关的是RPC(remote procedure call)消息。

RPC 消息的type 字段值为0x03，客户端通过发送一系列的RPC 请求到服务器上，并在服务器上执行，服务器将执行结果返回给客户端。其中，RPC 请求信息包含了RPC 的具体信息，包括存储过程的编号、选项标志位以及每个存储过程所需要的参数。每个RPC 请求必须包含1 个单独的SQL 语句，而不能携带其他的SQL 语句，其完整结构如图2 所示。其中：procedure name length(2 Byte)表示存储过程名称的长度；stored procedure id(2 Byte)表示存储过程对应的ID。parameters 字段为存储过程所携带的参数字段，具体参数的结构如图3 所示。

图2 RPC Request Data 结构Fig.2 Structure of RPC request data

图3 RPC 参数结构Fig.3 Structure of RPC Parameters

图3 中：name length(1 byte)表示参数名字的长度；status flags(1 byte)表示状态标志位；type info(2 Byte)表示类型信息，它的值决定了value 字段的值。

1.3 文件传输交互分析

TDS 协议交互过程包括预登录、登录、文件传输以及断开连接这4 步，这里重点介绍可优化的文件传输交互流程。

在已登录状态下，TDS 客户端等待来自上层应用的通知。若上层应用需要从服务器上传或下载文件，则客户端进入发送客户端请求状态并发送第1 个请求。在该状态下，客户端将会在正确识别服务器的响应后发送请求。若上层应用想取消刚发出去的请求，则客户端将会发送1 个注意消息请求，并进入发送注意消息状态。

在发送注意消息状态下，若客户端能够识别服务器发来的Attention 确认并且其结构合法有效，则客户端会丢弃该确认包中的所有数据，并向上层应用提交对该确认包处理的完成，说明发送Attention 数据请求的原因，然后重新进入已登录状态。文件传输的完整交互过程如图4 所示。

在客户端进入发送客户端请求状态后，若并未取消请求，则开始进入文件传输RPC 交互阶段，主要包括文件格式传输和文件内容传输。此时协议交互以RPC 类型数据包为主，并且RPC 交互呈现了一定的规律，其典型交互过程如图5 所示。

首先客户端发送携带有存储过程ID 号为5 的RPC 请求至服务器，以获取下一个存储过程ID 号为7的句柄和内容游标；然后，在收到并正确识别RPC 响应后，客户端发送携带有存储过程ID 号为7 的RPC请求至服务器，以获取内容游标所指向的内容；最后，在收到并正确识别RPC 响应后，客户端发送携带有存储过程ID 号为9 的RPC 请求至服务器，关闭该内容游标。若需要开始下一个任务，则客户端在完成ID为7 的过程交互之后，会发送携带有存储过程ID 号为14 和15 的RPC 请求，前者获取下一条任务的信息，后者通告这条任务的信息传输已经完成，可以进入下一条信息的传输过程。

2 TDS 加速策略的设计

在对TDS 协议的数据包头以及协议交互过程详细分析的基础上，提出基于数据预取的TDS 加速策略，并结合流量控制和内存池技术提升加速效果。

2.1 基于数据预取的加速策略

为了减少TDS 协议频繁的交互，采用数据预取技术的加速策略，以提升TDS 数据传输的性能。采用数据预取加速策略的文件传输交互协议，如图6 所示。在T1时刻，客户端发起请求，客户端和服务器网关转发请求。服务器在T2时刻接受到请求并将结果发送给客户端。在T3时刻，结果到达服务器网关后，网关将结果转发的同时开启预取，服务器通过服务器网关将请求数据发送给客户端网关，客户端网关将所接受到的数据进行缓存。因此，当客户端在T4时刻接收到T1时的处理结果并在T5时刻产生下一个请求时，其结果已经到达客户端，这极大地减少了客户端与服务器的交互次数。客户端的用户不必再去浪费时间等待数据到来，性能得到大幅度提升。

图4 文件传输交互图Fig.4 Interaction diagram of transfer

图5 文件传输中RPC 交互图Fig.5 RPC interaction diagram of file transfer

图6 采用预取技术的文件传输交互图Fig.6 Interaction diagram of prefetch

2.2 流量控制技术

虽然采用数据预取可以实现对TDS 协议的加速，而客户端必须对预取的数据进行缓存，但由于缓存有限，不可能无止境地对数据进行缓存，必须对数据量进行合理控制。

假设双边网关上的缓存为B(双边网关上缓存大小设置相同)，广域网延时设置为K，实际吞吐量为M，客户端或者服务器的一次性发送的数据块字节为P，客户端服务器一次性发送数据包个数为N，则有

在客户端与服务器交互的过程中，客户端发送请求后，必须等待服务器返回的响应，在正确接收到响应以后才能继续发送请求。频繁的交互会受到广域网高延迟的严重影响导致性能降低，故采用加速代理后，可在代理客户端上进行数据预取，将数据提前取回。式(1)中N 则实际表示可预取的最大的数据包个数，吞吐量M 可以通过网关测量获取，N 作为阈值在代理客户端和服务器上设置计数器即可实现流量控制。

2.3 内存池技术

内存池技术是应用程序通过调用系统内存管理分配函数为程序申请一块足够大的内存，此后应用程序需要开辟内存时，均从这块大内存中获取，从而避免了频繁地申请系统内存，提升程序的性能。本系统中需要频繁地申请内存来构建数据包，因此，使用内存池技术提升效率，从而提升加速效果。

根据内存池中对申请内存变化进行划分，可分为固定内存池和动态内存池。固定内存池分配的内存均是固定的，而动态内存池分配的内存是动态变化的。在本系统中，因为需要频繁构造数据包，故需要频繁申请内存，而数据包的大小并不一致，所以，综合使用这2 种内存池。系统通过对申请内存的判断来决定是固定内存还是动态内存来进行分配，这样只需在系统启动时申请1 次内存就能满足程序的需要，使得加速效果达到最佳。其分配方式如图7 所示。

图7 内存池结构Fig.7 Structure of memory pool

3 AcTDS 的设计与实现

基于提出的TDS 加速策略，设计和实现1 个TDS加速系统AcTDS，并对系统的网络拓扑、总体结构的设计以及功能实现进行阐述。

3.1 系统部署图

系统详细的网络结构如图8 所示。其中，加速系统AcTDS 的代理客户端部署在企业局域网出口的网关(图8 中Gateway(C))上，公司内所有主机必须通过此网关才能够连接Internet；而AcTDS 代理服务器则部署在企业数据中心的出口网关(图8 中Gateway(S))上，这样无论任何1 个分公司的局域网内的任何1 台主机通过Project 客户端在跨广域网访问企业总部中的数据中心时，都能够得到加速。

图8 系统网络拓扑Fig.8 Network topology of system

3.2 系统功能结构

AcTDS 包括代理客户端与代理服务器。客户端与服务器的功能模块主要有数据包识别模块、数据包解析模块、数据预取模块、数据包重组模块、数据包缓存模块共5 个模块。

3.2.1 数据包识别模块

数据包识别模块的功能是在所有经过网关的数据包中准确识别出TDS 数据包，并递交给数据包解析模块进行处理。而正确识别数据是协议加速的基础。

本文采用端口识别与行为分析2 种方式来保障协议数据包识别的准确性。SQL Server 在进行通信时，所占用的端口是1433，因此，在网关的配置文件中对监听端口进行配置，使加速网关只捕获通过1433 端口的数据流，从而过滤掉其他数据包。其次，对数据包初步过滤之后，再通过传输数据包中的应用层字段规律或者独有的特征进行再次分析确认。

3.2.2 数据包解析与重组模块

在加速过程中，通过数据包识别模块识别出所有TDS 的数据包。然而，TDS 存在多种消息结构，必须解析出每一个数据包所属类型才能进行下一步操作。在数据查询加速中，代理客户端发起数据预取，在获取服务器返回的响应后，通过对响应进行解析，从特定的响应中获取伪造下一个请求命令所需要句柄、游标ID 等信息。

此外，在数据查询加速和数据更新加速中都会存在大数据传输。在大数据传输过程中，对捕获到的数据块进行分析，由于黏包(由1 个完整数据包和下1 个数据包中的部分内容组成)和断包(只含有1 个完整数据包的部分内容)的现象存在，必须对接收到的数据进行拆分和重组，重新整合成单个完整的数据包。通过解析模块对数据进行特征识别，获取每个完整数据包的真实长度，根据长度进行重新组包。

3.2.3 数据包预取模块

数据包预取模块根据解析模块识别出的特征，伪造命令，从客户端或者服务器提前取回数据。在数据查询加速中，预取模块伪造客户端的请求命令，发送伪造的TDS 请求数据包至数据库服务器，提前获取服务器的响应数据，并将响应数据包发送至客户端网关；而在数据更新加速中，伪造服务器响应，发送伪造的TDS 响应数据包至客户端，提前获取客户端的数据，并将数据发送至服务器网关。

3.2.4 数据包缓存模块

由于数据包预取是一种预先处理的操作，而客户端请求按顺序发出的，因此，存在请求没有发出而数据已到达的现象。针对这种现象，采用通过构建动态缓存队列，对预取数据进行缓存的方法进行处理，只有在网关获得请求之后才会发出对应数据包。

3.3 系统模块实现

AcTDS 包括代理客户端与代理服务器，分别从数据更新和数据查询2 方面进行加速。AcTDS 在交互过程中智能判断交互过程是数据查询还是数据更新。根据请求特征，代理客户端和服务器会针对不同操作开启相应的模式。客户端和服务器网关的流程图如图9所示。

图9 客户端和服务器网关流程图Fig.9 Flow charts of client and server gateway

3.3.1 客户端加速

代理客户端在数据查询加速下，将开启请求缓存模式。监听后续到达网卡的数据包，见图9(a)。若是客户端发来请求，则拦截请求，通过特征判断，将缓存队列中的数据准确地发送给客户端；若是服务器网关发来数据，则先进行数据包拆分重组，将完整单一的数据包缓存在队列中，等到客户端的请求到达之后，将数据发送给客户端的同时拦截回复。而在数据更新加速下，将开启响应预取模式，代理客户端将客户端数据发给服务器端的同时，伪造回复发送给客户端，以使客户端将后续数据继续发送给服务器而不必等待真实的服务器回复。

3.3.2 服务端加速

代理服务器端在数据查询状态下将开启预取请求模式，如图9(b)所示。在收到代理客户端发送的第1条数据查询请求之后就开始持续伪造请求，并将从服务器获取的数据发送给代理客户端，直到最后1 条预取命令。而在数据更新状态下，代理服务器开启回复拦截模式，拦截服务器在收到数据包后确认信息。

4 系统测试

为了对AcTDS 系统的性能进行分析，在客户端和服务器分别安装Microsoft Project Server 2003 及SQL Server 2005，以测试AcTDS 在各种网络环境下文件传输的性能。

为保证网络测试环境的可控性与可再现性，选择在实验室搭建的网络实验测试床与实际测试相结合的方式进行。测试床实验的网络拓扑图如图10 所示。客户端与服务器部署在不同的子网之间，中间通过专用的广域网模拟器WANem 连接。广域网模拟器对网络参数如带宽、网络速度、丢包率等进行设置来模拟真实的广域网环境。

图10 测试环境网络拓扑图Fig.10 Network topology of simulation environment

在实验中，将初始带宽设置为4 Mb/s，RTT 设置为30 ms，以模拟现实中的广域网网络环境。在测试过程中，对带宽、丢包率等参数进行梯度设置，直至网速限制在10 Mb/s 左右，时延在500 ms 左右。测试过程中，服务器端数据大小为2 MB，测试结果如表2所示。

从表2 可以看出：延时对数据传输的时间影响很大，数据传输时间会随延时的增大而显著增大，这说明广域网的高延时会使得远程访问数据库的效率非常低。虽然加速后的传输时间也会有随时延的增加有一定提高，但加速比也会随时延增加而增大，可达到7.08。其原因在于TDS 加速插件通过削减协议交互次数有效削弱了高延时对协议交互的影响。

表2 模拟广域网环境实验床测试结果Table 2 Simulation results based on WANem

此外，带宽的增长对于数据传输的时间并没有太大影响，因为传输速率没有达到带宽上限。以时延为30 ms、带宽为4 Mb/s 的测试结果为例，加速后传输速率为2.57 Mb/s，未达到带宽上限，继续增加带宽无法提升加速性能。因此，按照目前4 Mb/s 带宽的常用网络带宽，主要影响还是在于延时。加速系统减少了交互次数，从而使得传输性能得到大大地提升，提高了带宽的利用率。

5 结论

1) 在对MS-TDS 协议深入分析的基础上，提出了一种有效的TDS 协议加速策略，并在Linux 网关平台下实现了一个功能完备、性能良好、可扩展的TDS 加速系统AcTDS。

2)AcTDS 在各种网络环境下都能够对TDS 进行有效加速。

3)AcTDS 具有良好的可扩展性。本文的研究成果可应用到Oracle，MySQL 和DB2 等数据库的协议加速方法研究中。虽然这些数据库在数据通信过程中所采用的协议各不相同，但其通信过程基本上是一致的，因此，可以采用类似的加速方法提升其他数据库协议的性能。

[1] Liu K, Lee J Y B. Mobile accelerator: A new approach to improve TCP performance in mobile data networks[C]//WCMC2011.Istanbul,Turkey,2011:2174-2180.

[2] Cisco Systems Inc. Application networking services, wide area application services(WAAS)[EB/OL]. [2013-05-20]. http://www.cisco.com/en/us/products/application-networking-services/index.html.

[3] WANSolutionWorks.Com. Riverbed optimization system(RiOS)[EB/OL]. [2013-05-20]. http://www.wansolutionworks.com/RiOS.asp

[4] Juniper networks.Technical documentation[EB/OL].[2013-05-20].https://www.juniper.net/techpubsl/.

[5] Shenzhen Sinfors Technology Co Ltd.WAN optimization[EB/OL].[2013-05-20].http://www.sangfor.com.

[6] QuickBi. WAN acceleration and WAN optimization[EB/OL].[2013-05-20].http://www.quickbi.com.cn/.

[7] Oguchi N, Abe S. Dynamic communication protocol for quick response in interactive communication[C]// IEEE/IPSJ 12th International Symposium on Applications and the Internet(SAINT).Izmir,Turkey,2012:226-231.

[8] 王建新, 王捷, 徐涛, 等. 广域网加速网关设计与实现[J]. 中南大学学报(自然科学版),2012,43(10):3879-3885.WANG Jianxin, WANG Jie, XU Tao, et al. Design and implementation of WAN acceleration gateway[J]. Journal of Central South University (Science and Technology), 2012,43(10):3379-3885.

[9] Baidu Encyclopedia. Microsoft project[EB/OL]. [2013-04-20].http://baike.baidu.com/view/1155692.htm.

[10] WANG Jianxin, LI Jing, RONG liang. ARROW-WTCP: A fast transport protocol based on explicit congestion notification over wired/wireless networks[J]. Journal of Central South University of Technology,2011,18(3):800-808.

[11] Guo L, Wu H. Design and implementation of TDS protocol analyzer[C]// IEEE International Conference on Computer Science and Information Technology (ICCSIT 2009). Beijing,China,2009:633-636.

[12] 王圣, 苏金树.TCP 加速技术研究综述[J]. 软件学报, 2004,15(11):1689-1699.WANG Sheng, SU Jinshu. A survey of technology for TCP acceleration[J].Journal of Software,2004,15(11):1689-1699.

[13] Huh E N, Choo H. Performance enhancement of TCP in high-speed networks[J]. Information Sciences, 2008, 178(2):352-362.

[14] Zhuang Z, Chang T Y, Sivakumar R, et al. A3: Applicationaware acceleration for wireless data networks[C]// Proceedings of the 12th annual international conference on Mobile computing and networking (MobiCom'06). California, USA, 2006:194-205.

[15] Ubik S, Friedl A, Hotmar S. Quantification of traffic burstiness with MAPI middleware[C]// CESNET Conference 2008.Prague,Czech Republic,2008:13-22.