这里是的小编为您带来的http协议优秀4篇，希望大家可以喜欢并分享出去。
[关键词]SCORM运行时环境，流式视频，点播
[中图分类号]G40-057 [文献标识码]A [论文编号]1009－8097(2011)01－0129－03
一 引言
SCORM运行时环境(SCORM Run-Time EnvironmenttSCORM-RTE)一项重要的任务就是完成对内容对象的，暨把具体的学习内容对象涉及到的各类媒体文件传输到浏览器上，使得浏览器能够正确的展示。内容对象是SCORM运行时环境基础要求，当前流行的各种SCORM系统在这方面都进行了实现，能传输几乎所有的媒体类型，但其在对流式多媒体支持上都还存在不足，特别是对流式视频媒体来说，这些系统大都只能采用提供下载的方式来展示，不利于较大的视音频在线浏览体验。本文就将对此原因进行分析，以期找到解决方案来实现SCORM运行时环境支持流式视频点播，提升SCORM系统媒体展现能力。
二 问题分析
当前SCORM运行时环境不能很好支持流式视频的原因来自于两个方面：
1 是流式视频实现技术的原因
当前主要的流式视频技术在浏览时需要专有技术支持，这不仅包括了浏览器方面的技术要求，大多还包括了专有网络传输协议的要求，例如RealMedia流式视频技术需要RTSP协议支持，微软的流式视频技术需要MMS协议支持，完整功能的FLASH流式视频技术也推荐采用RTMP协议。而要在SCORM运行时环境中部署这些协议的支持本身就是一件十分复杂的事情，这不仅是实现这些协议需要专门的服务器端软件，而且还要使得这些服务软件和基于HTTP协议的SCORM运行时环境协调一致的来提供内容对象。这其中的难点在于协议变化时确定内容对象的URL问题，这又涉及了原因的另一个方面。
2 SCORM内容包装模型自身要求
SCORM内容包装模型要求限定了打包在内的资源实体访问路径是相对于清单文件的相对路径。当然对不打包在资源包中的引用类资源不在此限，即对链接引用方式提供的资源你可以直接提供完整的URL路径(可包括协议头)。因为打包在内的内容对象实体路径是相对于清单文件的相对路径，而且一般SCORM运行时环境都是基于HTTP协议的普通WEB服务，所以最终的内容对象实体路径普遍表现为HTTP协议URL，这使得其天生就比较排斥其他协议。
三 解决思路
解决SCORM运行时环境支持流式视频的关键就是能够正确的定位流式视频的URL，并提供传输服务，对此可以从以下方面探寻解决问题方案。
1 稳定URL链接方案
对流式视频采用链接引用的方式这样可以提供稳定的URL链接，从而解决定位流式视频的问题。但这个方案的局限性很大，因为URL是外部链接引用，使得SCORM运行环境提供的内容对象服务支持不完整，受限于其他外部服务的稳定性。试想在SCORM内容访问时，若有一个外部链接失效造成学习内容不能正确访问，学习者是否会把它归罪于当前这个SCORM运行时环境(系统)?另外对这样的SCORM内容供应商来说，其生产SCORM的成本也会增加，因为其还需要对流式视频提供长期稳定的流式点播服务。由此这个思路不可取。
2 整合流式视频支持服务方案
让SCORM运行时环境整合流式视频支持服务，这又包括了两个可选的具体方案。
(1)整合原生流式视频服务子方案
这个方案就是让SCORM运行时环境中整合进流行原生流式视频支持服务，如在SCORM-RTE中整合RTSP/MMS/RTMP协议中的一种或者多种，在请求资源时由一种算法把原来基于HTTP协议的请求转换为基于某种流协议的资源请求实现播放。当前可以通过客户端脚本动态替换来转换，例如一个SCO主展示页面中需要一段视频点播，它是基于RTSP协议的，点播的文件和主展示web页面相对路径为mediaPatl/filename.ext，主展示web自身的URL是http：//serverhost/seoPatlffweb，ext，则媒体文件真实的http协议下URL为http：//serverhost/scoPath/mediaPath/filename.ext，这时通过协议头替换，把http协议头转换为具体要求的rtsp协议头就可以了，这个计算是一个简单文本替换，完全可以在客户端中利用javascript脚本语言方便实现。但这并不是一个完美的解决方案，它有较大的局限性。这种转换的前提条件是SCORM运行时环境提供了对应的服务协议支持，而且路径关系和http协议服务路径关系一致或者按一定规则进行固化。这加大了SCORM运行时环境部署的难度和成本。因为很好实现这些协议的服务都是成本高昂的商业软件，要完全支持所有的协议必然使得SCORM运行时环境部署成本急剧增大。从SCORM生产商来说这种解决方案下产生的SCORM包是和特殊SCORM运行时环境耦合度很高的特殊SCORM包，这违背了SCORM设计就是要尽量解除SCORM包与具体SCORM运行时环境耦合的初衷。试想一个这样的SCORM产品只能适应某些昂贵的专有SCORM运行时环境，它的应用范围必将受到很大限制。
(2)整合支持HTTP协议的流式视频点播实现技术方案
这个方案的要点是找一种支持HTTP协议的流式视频点播实现技术，这样就从根本解决了SCORM运行时环境支持流式视频点播的问题。流式视频点播技术的要点就是所有内容的传输都是基于HTTP协议的，不涉及其它协议，而且它不同于普通http内容传输，允许视音频内容边下载边展示，而不需要等到所有内容下载完后再展示(极大减少了下载缓冲时间)，从而提高了用户体验。当前还没有完全的HTTP协议流式视频技术实现，但仅从支持流式点播来说还是有系列技术有这样的雏形或者说是实现。一种是基于flash Video技术的实现，它包括了flash Video媒体http协议服务器端支持和对应的客户端实现要点，这两个要点当前都已成熟的技术，大多数视频点播网站都采用了这类技术，它其支持flashVideo和H.264的mp4视频格式。另外一种是新兴的HTML5技术，但这类技术还不如flashVideo HTTP流式技术成熟，比如其支持的编码格式还没有确定，而且支持的浏览器还都处在开发阶段。由此可见采用基于flash Video技术来实现HTTP协议
流式视频点播从而解决SCORM运行时环境支持流式视频点播问题更可取。
四 基于flash Video技术SCORM运行时环境支持流式视频点播实现介绍
1 实现介绍与举例
实现SCORM运行时环境支持流式视频点播包括了两个方面，其一是SCORM运行时环境对应的http协议服务支持flashVideo技术流式播放，其二是SCORM打包中以flash Video技术流式播放支持的格式集成相应的视音频内容，并且提供客户端播放支持。对于第一点已有成熟的实现方式，例如常见的SCORM运行时环境提供软件Moodle在部署到Nginx平台时，就可以利用Nginx的ngx_http_flv_module模块实现的flashVideo技术流式点播支持，从而提供流式视频点播服务；再利用nginx_mod h264 streaming模块扩展支持mp4流式点播，类似还有基于lighttpd的部署实现。对于第二要求，则只需要在客户端实现中集成(开发)一个flash Video客户端播放应用程序，并把需要展示的内容都转换成flv格式或者mp4格式来打包即可；这都有成熟的实现，比如采用JW-player这样的开源flash Video播放应用程序来集成，对于格式转换也可以采用Mplayer开源项目中的Mencoder工具或者FFMPEG开源项目中的转码工具转化成nv格式或者mp4格式。
2 方案优势介绍
这种基于flash Video技术SCORM运行时环境实现支持流式视频点播方案有较多的优势，主要体现在以下几个方面。
(1)涉及技术成熟
无论是服务器端技术还是客户端技术，这一方案中涉及的技术都比较成熟，对于内容的产生打包来说也是这样，而且开源实现比较多，部署和维护成本都容易控制。这在前面介绍中已经举例了具体实现技术，就不再展开了。
(2)案兼容性好
它充分发挥flash Video技术自身一个特性使得方案兼容性十分好：这个特性就是当前flash Video对HTTP协议流式播放有两种程度的支持，一个是渐进式流式播放支持。更高程度的是可重定位流式播放支持。前面提到的Nginx利用ngx_http_fly_module模块和nginx_mod_h264_streaming模块支持流式点播实现到可重定位流式播放支持，而渐进式流式播放支持几乎所有HTTP协议服务器都直接支持了。这样打包的视音频点播就不存在环境兼容性问题了，都能正常观看，只是依据不同SCORM运行时环境对flash Video流式点播支持程度的不同观看效果不同，而这个不同也仅仅是是否支持随机点播定位而己，不影响完整的观看内容。从这个意义上来说这样的打包实现才是真正运行时环境无关的，是完全符合SCORM内容打包要求的。
(3)网络穿透性好
这种技术方案网络穿透性能最好，因为只涉及http协议，而只要能应用SCORM运行时环境的网络条件都提供了HTTP协议支持。
3 方案局限性
这种基于flash Video技术SCORM运行时环境实现支持流式视频点播方案的主要局限有两个方面，其一在于其流式视频点播支持性能上一般没有专门技术优良，毕竟这种方案不像那些专有流式视频支持技术在实现流式点播支持上进行了专门优化。此外就是只支持flv或者rap4格式，其他类型视频需要转换成这两种类型，这一定程度增加了SCORM生产成本：但这个转换成本相对于一般视频内容生产总成本来说所占比例较小，而且也不是一直都会有，如果采用的可直接输出为这两种格式视频生产工具就没有了再次转换成本。
五 小结
关键词：WEB服务；HTTP/HTTPS；数据传输；通道；安全性
中图分类号：TP393.08 文献标识码：A 文章编号：1007-9599 （2012） 17-0000-02
网页服务是万维网上至为重要的应用之一。在网页设计中，http协议作为网页服务数据的传递通道，也成为网上最为重要的最常见的应用协议。由于网络的广泛普及和应用，有关的安全问题也越来越突出，在网络上，WEB站点经常成为黑客攻击的主要对象，这是由于网页开放性特征和易用型特征所导致的难以避免的结果。一些攻击者千方百计地进行表单篡改、命令插入等，王冶安全漏洞很多。研究报告指出，网页应用已经成为网络技术最大的安全焦点之一。因此，WEB应用的安全问题，已经成为网络技术安全的核心问题所在。当今社会，网络技术飞速发展，同时，随着网络技术的普及，网络电子商务、网络银行等方兴未艾，这些应用大幅度地拓展了网页应用的领域，因此，WEB服务的安全问题，也就更为突出。与此相关，作为传输通道的http协议，它的安全性要求，也就更为严格。我们设想，通过系统分析网页服务的安全问题，在介绍了HTTP协议的模型的基础上，针对HTTP协议存在的缺陷提出了改进HTTP协议的基本措施，为如何提高基于WEB服务数据传输通道的安全性提供可靠的理论依据。
1 WEB服务器存在的安全问题
1.1 服务器遭受入侵。网络黑客或其他攻击者往往直接通过网页漏洞或者一些人为的疏忽，进行攻击，比如远程溢出，SQL INJECTION，以及基于社会工程学等的手段，不择手段地入侵到WEB服务器内部。入侵的结果是WEB服务器不再安全，并孪生出许多问题，这种入侵性的攻击危害性最大，突出在于入侵者取得了大量用户的保密信息。
1.2 加密不具安全性。在网络上，很多WEB应用程序爱将敏感的保密性的信息，存储到网络数据库或者文件系统中，然后借助一般的加密技术来予以保护，诸不知这样的保密，安全性并不高。网络上常见的存储操作大体有如：关键数据不加密，证书、密码等存储不安全，秘密信息放在内存中。此外，还有算法选择不好，加密过程有疏漏等。甚至一些信用卡密码等，也放在内存中。
1.3 截取传输信息。网络攻击者常常在客户终端的支路、服务器的旁路等，通过一些特殊手段，如DNS SPOOF或者ARP SPOOF等，配合SNIFF过程，在中途截取或者篡秘密改客户端和服务器端之间的通信。这种攻击危险性也很大，如果让他们截取倒管理员登陆情况，就会私自登陆，进入服务器，直接入侵服务器，其后果相当严重。
1.4 针对客户端的攻击。一些黑客直接攻击客户端，采取的做法是，借助XSS漏洞来引起。在服务器把用户输入的数据没有做出严格的html标签过滤，就把它们直接保存到数据库，然后直接回显，这最容易熬出长久的XSS攻击。其结果也很严重，有可能直接导致客户端被重定向到恶意的网站去，或者被钓鱼，或者被植入木马等。
1.5 不接受服务。在网页应用中，一般比较难于分辨哪些是攻击行为，哪些是普通的访问，这主要是IP地址是共用的，这IP地址无法成为请求来源的判断的依据，也就是说，服务器无法判断出一个http的请求是从哪里来的，是善意的还是恶意的，也就无法过滤恶意访问行为。这样，服务器也就容易受到拒绝服务的攻击。这种服务器拒绝服务型的攻击，让WEB应用无法分辨哪是攻击行为，哪是多个用户的访问。攻击者通过大量的发送文字，或者直接发送严重消耗服务端的CPU资源的请求，如服务请求等，使得服务器力不胜支，最后服务端停止响应，这就让黑客达到了攻击的目的。
2 基于HTTP协议的工作模型及其缺陷
2.1 http协议的模型。一般地，WEB的服务是基于客户机/服务器模式的。WEB文档存放在服务器上，用户通过客户终端，借助浏览器对站点网页进行浏览。服务器和客户机的连接是依靠80端口连接的，当服务器和客户端连接之后，客户器和服务器就借助http协议来进行诉求和应答。HTTP协议的工作模式见图1：
图1 WEB应用工作模型显示了WEB应用服务的工作过程
2.2 HTTP协议存在的缺陷。应用极为广泛的http协议，还存在着不少的安全漏洞。主要是缺乏安全性检测，无法对数据传送和信息完整性进行检测。在网络技术应用中，数据的明文传送和信息完整性，特别成为网络技术应用所关注，例如电子商务、网络交易、在线支付等，就极需要明文传送数据，信息要完整等等。攻击者泽试图在数据传输过程中，分析和发行敏感的数据，例如管理员的登陆、支付密码的使用等，从而偷取密码，获得网站管理权限等。即使无法得到后台登陆信息数据，黑客也能从网页数据传输过程中，得到一般用户的隐私信息，包括手机号码、信用卡资料、工作证件号码、身份证号等，这就容易导致严重的安全事故。一些攻击行为，只要使用网络的任意的抓包工具，即使是新手，也都可能窃取大型网站的秘密信息。
特别是，http协议往往对内容是否被篡改，不做出确认，它只是在报文前部给出传输数据的长度而已，中央它在传输客户端的信息、请求和服务器响应的时候，就可以让攻击者轻易地得到重要数据。例如管理员的登陆过程、客户使用密码、网页交易支付等等。攻击者可以窃取管理权限，修改客户端的数据，甚至在传输数据中插入恶意代码，或植入木马等等，客户将遭受严重损失。而这些问题，http协议却感觉不出来，这最是让人难受的了。
这些缺陷，都是http协议在设计的时候，安全性被忽略所导致，也是因为设计上的问题，就使得这些漏洞无法从根本上解决。后来，NETSCAPE提出了HTTPS协议，使得数据传输获得进一步的安全保障。
3 借助HTTPS协议改进HTTP
http协议所存在的安全漏洞，必须解决，否则客户所受的攻击，防不胜防。Https之所以具有安全保障性，主要是https在TCP层和HTTP层之间，增加了一个SSL，这就在一定程度上加强了安全性。服务器在传输数据的时候，SSL进行加密和解密的工作，这就保证了数据的安全。https的做法是：
3.1 对身份认证从客户端和服务段双向进行。就是说，客户端和服务段都进行身份认证，在数据传输之前，通过X509证书认证双方身份。具体步骤是：
从客户端发起SSL结合的信息，请求服务端给以连接——服务端给客户端发送证书——客户端检查服务段证书并确认，如果不是由自己信任的证书机构签发的，就提醒客户，由客户决定选择是否继续通信，如果检查没有问题，或用户选择继续，则服务端的身份被客户端认可——客户端应要求向服务器发送证书，并检查是否通过。如果不通过，则关闭连接，通过泽获得客户端的公钥。
在身份认证过程中，服务端和客户端都对对方进行验证，这就保证了安全。
3.2 对数据传输过程予以加密。使用加密算法，在开始传输数据的时候，客户端和服务段协商，使用哪类算法。当客户端发送协商，请求服务端时，给服务端一自己支持的非对称的密钥交换算法（RSA），还有数据签名摘要算法（SHA或MDS等），加密传输数据的对称加密算法（DES），还包括加密密钥的长度。服务端在接收到这些信息之后，则选择自己认可的安全性最高的算法，然后反送给客户端自己所选中的算法，这样就完成了初期的协商。
接下来，客户端再生成随机的字符，通过协商好的加密算法，使用服务端的公钥，对这串字符进行加密，再发送给服务器。服务器接收到加密的字符串之后，再用自己的私钥来解密这些字符串。这一双边进行加密和解密的过程，就保证了数据的安全。尔后，在传输数据时，就使用这一加密的字符串作为密钥进行对称加密。
3.3 检验数据完整性。Https操作过程中，借助SSL，使用一种信息验证码，例如MD5，或者SHA-1算法等，以之来对所传输的数据进行签名，一般地，把验证码放在数据包的后部，并且把验证码和数据一起加密，这样在数据被篡改时，会由于HASH值的改变而被发现，进而有效处理。
3.4 防止重放攻击数据包。为了防止数据包被重放攻击，SSL使用序列号来保护通信方，这个序列号也要加密，并作为数据包的负载。在使用SSL来叩应对方时，那个唯一的随机字符作出标记，这就防止了黑客对客户登陆过程的窥探，以及在得到加密数据之后，不解密而直接重传登陆数据包来进行攻击。
经过这些作为，https已经大大提高了网络数据的安全性，其创造性在于，使用了非对称的加密算法，经过协商传递，保持了非对称加密的安全性和对称加密的快速度。
4 进一步加强https的安全性
基于http协议之上的https协议，使用了非对称加密的方式，传输对称加密使用的密钥，但是，如果SSL发起攻击并取得密钥，那么，整个数据传输的加密，也就没有什么意义。因此，必须在SSL之前，通过对称加密，提高所要传输的数据的安全性。同时，不传输这次先行加密的密钥，而只是保存到两端。这样，即使SSL的对称加密密钥被窃取，攻击者也无法截获明文信息。但这又有一个新的问题，即客户端如何部署，才能方便地在客户端实施这一传输前的数据加密工作。方法是，在客户端使用JS持续。JS代码存在于服务端，如果在客户端执行这一代码，就可以保证数据在SSL传输之前，进行自定义的加密。当然，JS代码容易被攻击者直接察看，故只能哦那个在安全需求不高的场合。而对于电子商务、网上交易、网银付款等，还得另找办法。实践证明，较好的选择是使用ACTIVEX或APPLET。可通过客户端控件，在数据输入之后，马上进行加密，然后借助https协议来传输数据信息/这样，即使中间人劫持了数据，解开了SSL加密层。看到的也只是无关紧要的数据，而重要的机密的数据则另置于ACTIVEX的加密保护下，这样就达到了保护机密数据的目的。
参考文献
[1]杨波，朱秋萍。WEB安全技术综述[J].计算机应用研究，2002.10：1-4.
[2]高鹏。构建安全的WEB站点[M].清华大学出版社，1999.
关键词：桌面应用程序 自动更新 HTTP协议 数据流程 数据结构 客户端
中图分类号：TP311.1 文献标识码：A 文章编号：1007-9416（2013）06-0062-01
1 自动更新程序通信协议的选择
随着电子技术和科技的发展，计算机桌面的应用程序更新速度快，很短时间内就会推出新的版本，脑桌面应用程序新版本要求客户端运行版本与之相适应。因此，软件设计者在进行软件的后续开发时，要考虑到软件版本、软件的数据结构兼容性等问题。数据结构的兼容性是设计者要考虑的重点问题之一，兼容性方面出问题的话，软件的开发成本和后期的软件维护成本会很高，既不实用也不经济。
随着互联网的普遍应用，借助于网络来实现电脑桌面应用程序的更新升级成为了可能和常态。为适应新形势的发展，在桌面应用程序中添加软件的在线更新的功能，在用户使用程序时候出现新版本后让用户自行更新，不仅方便了用户，节约了时间，也免去了后期的维护，既方便又快捷，可谓一举多得。
自动更新程序的通信协议，可以采用比较成熟的HTTP协议，也可以编写程序实现Socket通信。综合衡量和比较两种方式的优缺点后，笔者建议选择HTTP协议来实现自动更新程序的构建。
2 HTTP协议的优点分析
HTTP协议（（Hyper Text Transfer Protocol）是超文本传输协议的缩写，这个协议是无状态的协议，具有无状态、简单快速，无连接、灵活等多种优点。HTTP传输协议的主要优点和特点有以下几个方面。
2.1 可传输任意类型的数据对象
HTTP协议的一个优点就是应用过程中传输数据灵活广泛，HTTP协议允许传输任意类型的数据对象，正在传输的数据类型由Content-Type加以标记。
2.2 操作方式简单，服务器的程序小
HTTP协议客户向服务器请求服务时，不需要传送请求其他方面的内容，只需传送请求方法和路径就能实现。应用过程操作方式、请求方法比较简单，容易实现。具体的请求方法有GET、POST、HEAD三种主要方法。由于HTTP服务器的程序比较小，占用空间不大，因而通信速度很快。
2.3 无状态协议
HTTP协议是无状态协议。所谓无状态，是指协议对于事务处理没有记忆能力，如果后续处理需要前面的信息，则它必须重重新传输。无状态协议可能导致每次连接传送的数据量增大，但是在服务器不需要先前信息时，它的应答速度却变得较快。
2.4 无连接，可节省传输时间
HTTP协议限制每次连接时，只需要处理一个请求，服务器处理完客户的请求，并收到客户的应答后，就会自动断开连接。这种传输方式传输速度快，可以有效的节省传输时间。
2.5 端口开放，一般不会被屏蔽
由于考虑网络安全、信息安全等因素，很多网络都设置了防火墙，很多端口都会被屏蔽掉。对于HTTP最常用的80端口来说，却不在屏蔽的范围之内，这样应用起来不会因为被屏蔽而造成不必要的麻烦，同时也保证了程序运行的畅通性和广泛性。
3 数据流程及数据结构
基于HTTP协议下的自动更新平台可以对数据流程扩展，例如断点续传、开始更新前检查上次留下的缓存、自动程序线程定时启动等。
基于HTTP协议下的桌面应用程序自动更新平台中，有多个软件产品存储在U_Products表中。这些软件产品有多个客户端验证时需要用到的序列号，这些序列号存储在U_Clients中。序列号是客户端的凭证，只有授权了的序列号才能访问平台。文件列表用于比较客户端文件与服务器上的各个文件的新旧。其中的时间戳是主要比较字段，文件名用于记录定位。
4 客户端工作流程
实际应用中，基于HTTP协议下的自动更新平台客户端工作流程要比上述工作流程复杂很多。等主程序启动之后，会创建自动升级程序的线程，首先读出产品的序列号，通过URL参数传值的形式传到Web端。这些信息包括客户端计算机硬件信息、当前软件版本、客户端操作系统版本等。运行在Web端的脚本响应请求，判断序列号是否正确和过期，如果序列号正确，没有过期，请求通过之后，就会输出与该序列号对应的软件的所有文件列表。
随后，自动升级程序就会通过HTTP协议下载该文件列表。列表下载完毕后，会读出上一次升级之后保存下来的文件列表，并与下载下来的列表进行对比，通过文件列表中的时间戳对比，找出新的文件。也可以采用时间戳转成浮点数后大小对比的策略。时间戳转成浮点数后大小对比的策略就可以避免高版本文件通过升级之后版本降低。
5 改进
自动更新程序的运行要靠互联网完成，当网络连接状况很差的时候，更新所需要的时间就会很长，甚至不能完成更新。为了解决这个问题，可以对文件进行逐个ZIP压缩，通过HTTP协议传输压缩流，而不是文件本身的数据流。客户端下载之后进行解压缩。需要说明的是，这里的压缩是对文件逐个压缩，而不是整体打包。如果客户端只需要更新一个文件，就只需要下载该文件的压缩包。若是整体打包的话，这种情况下，客户只能下载整个压缩包，不但对断点续传提出了更高的要求，也浪费了时间，增加了程序运行工作量和冗杂。
参考文献
[1]何航校，蒋兆远。一种改进的通用客户端自动升级模型及实现[J].兰州交通大学学报，2005.24.
[2]C.J.Date.数据库系统导论[M].北京：机械工业出版社，2000.
关键词：TTcom-3；LoongTesting；HTTP；SA；CD
The Design and Implementation of the HTTP Test Adapter Based on TTcom-3
Su Guanghao,Tan Xiaoyu,Lei Yu
(Software Institute of Hunan Vocational College of Science and Technology,Changsha410118,China)
Abstract:This paper introduces the test system framework of TTcom-3,and according to the characteristics of the HTTP protocol,design and development test adapter in LoongTesting platform.And make a simple test to a web site on this platform.
Keywords:TTcom-3;LoongTesting;HTTP;SA;CD
一、TTcom-3简介
TTcom-3（Testing and Test Control Notation version 3，测试和测试控制表示法第三版）是ETSI（European Telecommunications Standards Institute，欧洲电信标准协）推出的协议和软件测试标准，是目前主流的协议测试标准系统。图1显示了TTcom-3测试系统的整体架构，以及该系统与用户和被测系统之间的交互示意。
图1.测试系统框架
其中CD（Coding and Decoding，编码解码）是编解码模块，负责对测试数据进行编码和解码工作。SA（System Adapter，系统适配器）是系统适配器，负责针对每一种测试系统的执行平台，使TTcom-3测试系统与SUT（System Under Test，被测系统）之间可以建立基于消息或者过程的通信。SA可以实现与SUT之间基于过程的通信操作。SA和TE模块之间拥有一个接口TRI（TTcom-3 Runtime Interface，TTcom-3运行时接口），该接口用来向SA发送SUT消息，并负责在通信操作中交换SUT与TE之间相应编码之后的测试数据。
LoongTesting是由中国科学技术大学TTcom-3实验室自主开发的，也是国内唯一一个完整的TTcom-3测试平台，是一款C++语言实现的免费、开源的TTcom-3测试工具。可以动态加载CD，SA，目前该工具加载的CD和SA必须在Microsoft Visual Studio 2005环境下使用C++语言设计开发。
二、HTTP简介
HTTP（Hypertext Transfer Protocol，超文本传输协议）是应用级协议，被广泛应用于WWW全球信息服务系统。它是一种请求/响应式的协议，一个客户和服务器建立连接后，发出一个请求给服务器，服务器接到请求后给于相应的响应。HTTP协议格式比较简单：HTTP请求分为请求头和请求体，HTTP响应分为响应头和响应体。在测试时主要对这两部分的信息进行验证，测试请求信息的反馈（响应信息）与期望值是否一致。
三、基于HTTP的适配器设计
（一）主要的类及方法方法介绍。在VS2005开发平台中，CAtlHttpClientT类为HTTP客户端提供服务，需要作为一个模板参数的类，它提供基本的网络接口功能的名称，是一个轻量级的HTTP客户类，可以发出请求并获得响应。Navigate（）调用此方法来执行HTTP请求，GetRawResponseHeader（）调用此方法可以获得HTTP响应头信息，GetBody（）调用此方法可以获得HTTP响应体信息。
CAtlNavigateData类用于设置除网址外的HTTP请求信息，封装了ATL_NAVIGATE_DATA结构，增加初始化和访问和检索功能。该ATL_NAVIGATE_DATA结构是用来提供设定到CAtlHttpClientT类。除了本身的网址，几乎需要执行HTTP请求的所有设置也提供了ATL_NAVIGATE_DATA结构。SetMethod （）此方法可以设置数据传输的方法，SetPostData（）调用此方法可以设置请求传送的数据。
（二）TRI主要接口介绍。TRI定义了在TTcom-3测试系统实现内的TE（TTcom-3 executable，TTcom-3执行实体）、SA和PA之间的交互。
triMap（）接口：建立测试组件端口和测试系统端口之间的映射，同时也可以在此进行一些初始化的工作；triSend（）接口：用来实现测试系统向被测系统发送PDU，并且对PDU进行编码。
在LoongTesting测试平台中实现TTcom-3适配器，需要通过triExcuteTestCase接口创建了执行测试模块（TE）和被测系统模块（SUT）的端口，此适配器中将被测系统模块端口指向HTTP服务器。triMap接口实现了两模块通信端口的映射。trisend 接口可以实现执行测试模块（TE）发送消息，利用VC++2005开发平台CAtlHttpClientT类，此类为HTTP客户端提供服务，可以向服务器发出请求并获得相应的响应。
通过trisend接口的实现，就实现了TE与HTTP服务器之间的数据通信了。当端口映射完成数据通信后，可以利用triUnmap 接口释放映射关系。
四、测试实例
用户在登录网站时，需要和服务器端按照规定的协议进行交互．我们在此只列出了其中一个协议交互，即用户登录，被测实现为浏览器中登录页面。在此消息的交互过程中，用户输入用户名和密码后按照指定的协议格式提交到服务器端的Servlet中，如果提交的信息正确，则Servlet返回login-OK，否则login-fail。
五、结束语
将TTcom-3应用于HTTP应用协议的测试中，它不但解决了HTTP应用开发中协议测试难的问题，而且使得测试覆盖协议的各个方面，本文所实现的适配器，可以加快TTcom-3测试套的开发和实施．但在此过程中，我们也发现有些问题还有待于进一步研究，比如：响应的数据类型比较多，验证比较复杂，需要工作量。
参考文献：
[1]ETSI ES 201 873-1 V3.2.1 (2007-02) Methods for Testing and Specification (MTS);The Testing and Test Control Notation version 3; Part 1: TTcom-3 Core Language