http协议范例【最新4篇】

【导言】此例“http协议范例【最新4篇】”的文书资料由阿拉题库网友为您分享整理，以供您学习参考之用，希望这篇资料对您有所帮助，喜欢就复制下载支持吧！

http协议【第一篇】

关键词：TTCN-3；LoongTesting；HTTP；SA；CD

The Design and Implementation of the HTTP Test Adapter Based on TTCN-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 TTCN-3,and according to the characteristics of the HTTP protocol,design and development test adapter in LoongTesting make a simple test to a web site on this platform.

Keywords:TTCN-3;LoongTesting;HTTP;SA;CD

一、TTCN-3简介

TTCN-3（Testing and Test Control Notation version 3，测试和测试控制表示法第三版）是ETSI（European Telecommunications Standards Institute，欧洲电信标准协）推出的协议和软件测试标准，是目前主流的协议测试标准系统。图1显示了TTCN-3测试系统的整体架构，以及该系统与用户和被测系统之间的交互示意。

图1.测试系统框架

其中CD（Coding and Decoding，编码解码）是编解码模块，负责对测试数据进行编码和解码工作。SA（System Adapter，系统适配器）是系统适配器，负责针对每一种测试系统的执行平台，使TTCN-3测试系统与SUT（System Under Test，被测系统）之间可以建立基于消息或者过程的通信。SA可以实现与SUT之间基于过程的通信操作。SA和TE模块之间拥有一个接口TRI（TTCN-3 Runtime Interface，TTCN-3运行时接口），该接口用来向SA发送SUT消息，并负责在通信操作中交换SUT与TE之间相应编码之后的测试数据。

LoongTesting是由中国科学技术大学TTCN-3实验室自主开发的，也是国内唯一一个完整的TTCN-3测试平台，是一款C++语言实现的免费、开源的TTCN-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定义了在TTCN-3测试系统实现内的TE（TTCN-3 executable，TTCN-3执行实体）、SA和PA之间的交互。

triMap（）接口：建立测试组件端口和测试系统端口之间的映射，同时也可以在此进行一些初始化的工作；triSend（）接口：用来实现测试系统向被测系统发送PDU，并且对PDU进行编码。

在LoongTesting测试平台中实现TTCN-3适配器，需要通过triExcuteTestCase接口创建了执行测试模块（TE）和被测系统模块（SUT）的端口，此适配器中将被测系统模块端口指向HTTP服务器。triMap接口实现了两模块通信端口的映射。trisend 接口可以实现执行测试模块（TE）发送消息，利用VC++2005开发平台CAtlHttpClientT类，此类为HTTP客户端提供服务，可以向服务器发出请求并获得相应的响应。

通过trisend接口的实现，就实现了TE与HTTP服务器之间的数据通信了。当端口映射完成数据通信后，可以利用triUnmap 接口释放映射关系。

四、测试实例

用户在登录网站时，需要和服务器端按照规定的协议进行交互．我们在此只列出了其中一个协议交互，即用户登录，被测实现为浏览器中登录页面。在此消息的交互过程中，用户输入用户名和密码后按照指定的协议格式提交到服务器端的Servlet中，如果提交的信息正确，则Servlet返回login-OK，否则login-fail。

五、结束语

将TTCN-3应用于HTTP应用协议的测试中，它不但解决了HTTP应用开发中协议测试难的问题，而且使得测试覆盖协议的各个方面，本文所实现的适配器，可以加快TTCN-3测试套的开发和实施．但在此过程中，我们也发现有些问题还有待于进一步研究，比如：响应的数据类型比较多，验证比较复杂，需要工作量。

参考文献：

[1]ETSI ES 201 873-1 (2007-02) Methods for Testing and Specification (MTS);The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language

http协议【第二篇】

关键词：WWW； HTTP； 网络协议；http协议；请求

中图分类号：TP391 文献标识码：A

一、HTTP协议简述

HTTP是一个客户端和服务器端请求和应答的标准。所有基于Web的应用都要使用到HTTP协议。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口的HTTP请求。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定可靠的传输，任何能够提供这种保证的协议都可以被其使用。

二、HTTP协议的概念

超文本传输协议（HTTP）是一种通信协议，它允许将超文本标记语言（HTML）文档从Web服务器传送到客户端的浏览器。

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/的第六版。

三、HTTP协议的主要特点

1 支持“客户/服务器”模式。

2 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

3 灵活：HTTP允许传输任意类型的数据。正在传输的类型由Content-Type加以标记。

4 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

5 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。它并不知道这两个请求来自同一个客户端。 为了解决这个问题， Web程序引入了Cookie机制来维护状态。另一方面，在服务器不需要先前信息时它的应答就较快。

四、HTTP协议与URL

HTTP（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

五、HTTP消息的结构

先看Request 消息的结构， Request 消息分为3部分，第一部分叫请求行， 第二部分叫http header， 第三部分是body。 header和body之间有个空行。

第一行中的Method表示请求方法，比如“POST”，“GET”，Path-to-resoure表示请求的资源， Http/version-number 表示HTTP协议的版本号。当使用的是“GET” 方法的时候，body是为空的。

Http协议定义了很多与服务器交互的方法，最基本的有4种，分别是GET，POST，PUT，DELETE。 HTTP中的GET， POST， PUT， DELETE就对应着对这个资源的查，改，增，删4个操作。 我们最常见的就是GET和POST了。GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。

我们再看Response消息的结构， 和Request消息的结构基本一样。 同样也分为三部分，第一部分叫request line， 第二部分叫request header，第三部分是body。 header和body之间也有个空行。

HTTP/version-number表示HTTP协议的版本号，status-code 和message 为状态代码。

Response 消息中的第一行叫做状态行，由HTTP协议版本号，状态码，状态消息 三部分组成。

状态码用来告诉HTTP客户端，HTTP服务器是否产生了预期的Response。

HTTP/中定义了5类状态码，状态码由三位数字组成，第一个数字定义了响应的类别 。

200 OK-最常见的就是成功响应状态码200了， 这表明该请求被成功地完成，所请求的资源发送回客户端。

302 Found 重定向，新的URL会在response中的Location中返回，浏览器将会使用新的URL发出新的Request。

304 Not Modified 代表上次的文档已经被缓存了， 还可以继续使用。

400 Bad Request 客户端请求与语法错误，不能被服务器所理解。

403 Forbidden 服务器收到请求，但是拒绝提供服务。

404 Not Found 请求资源不存在。

500 Internal Server Error 服务器发生了不可预期的错误。

503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

结语

以上便是HTTP协议的工作原理及基本结构，在实际工作学习中我们可以使用Fiddler软件工具来帮助我们具体分析http协议的工作流程。

参考文献

[1]祝瑞，车敏。基于HTTP协议的服务器程序分析[J].现代电子技术，2012（04）.

http协议【第三篇】

程序实现过程：

1.分析链接关系（限于篇幅，这里只介绍对锚标记〈a〉的分析）。

在html中〈a〉标记的基本语法为：〈ahref=″...″name=″...″target=″...″〉。其中参数href的值就是欲获取的url值。

2.下载。

在http协议中常用的请求方法有两种：get和post。本实现使用get方法。最简化的get请求包如下：

get//

“/”表示客户端欲下载的文件路径；“http/”表示协议版本。

程序生成get请求包，在成功连接对应web服务器的80或其它端口后，使用基于tcp协议的同步模式套接字发送请求包并等待返回信息。

服务器将返回一个应答包，大致如下：

http/

...

[数据。]

第一行是应答信息。如果成功，服务器将返回“http/”。

第三行是一个空行，用以分隔http包头和包体(数据)。

第四行开始就是以字节流的方式返回的数据。

如果使用http，则与上述有两点不同。

第一，连接时应连接服务器，而不是连接web服务器。

第二，在生成请求包时，下载文件的url必须写全url。对上例而言，请求应为“getnetsport//”，而不是“get//”。

具体程序和类(程序使用编制)：

1.初始化winsock。

(sender:tobject);

var

wversionrequired:word;

wsdata:twsadata;

begin

ismultithread:=true;

//置″支持多线程″为″真″

wversionrequired:=makeword(2,0);

casewsastartup(wversionrequired,wsdata)of//初始化winsock

wsasysnotready:

(′网络系统未准备′,′信息′,mb_ok);

wsavernotsupported:

(′未提供网络接口′,′信息′,mb_ok);

wsaeinval:

(′网络版本不被支持′,′信息′,mb_ok);

end;

end;

2.文件下载线程。

tdownfilethread=class(tthread)

private

fileurl:string;

//记录文件的url

protected

procedureexecute;override;

publicconstructorcreate(url:string);

end;

c(url:string);

begin

fileurl:=url;

freeonterminate:=true;

inheritedcreate(false);

end;

;

var

mysocket:tsocket;myclient:tsockaddr;

recvbuf:array[0..332]ofchar;mycmdstr:string;

ptemp:pchar;

myhandle,index_ch,reccount,i:integer;

begin//创建本地socket

mysocket:=socket(af_inet,sock_stream,0);

if(mysocket=socket_error)thenbegin

(′初始化失败！′,′信息′,mb_ok);

exit;

end;//生成连接主机的结构

_family:=af_inet;

_port:=htons(connectedport);

//connectedport：全局变量，记录连接端口号

strpcopy(recvbuf,getserverip(fileurl));

//getserverip(fileurl)：返回服务器的ip

__addr:=inet_addr(recvbuf);//连接服务器

if(connect(mysocket,myclient,sizeof(myclient))〈〉0)thenbegin

closesocket(mysocket);

exit;

end;//发请求

if(q_useproxy=0)then

mycmdstr:=′get′＋extracturlpath(fileurl)＋′http/′

//extracturlpath(fileurl)返回相对url

elsemycmdstr:=′get′＋fileurl＋′http/′;//使用写全url

strpcopy(recvbuf,mycmdstr);

i:=length(mycmdstr);

recvbuf[i]:=＃13;inc(i);recvbuf[i]:=＃10;inc(i);

recvbuf[i]:=＃13;inc(i);recvbuf[i]:=＃10;inc(i);

recvbuf[i]:=＃0;

send(mysocket,recvbuf,i,0);

//发送请求读返回数据

reccount:=recv(mysocket,recvbuf,sizeof(recvbuf)－1,0);//判断是否成功

i:=0;

whilei〈10dobegin

i:=i＋1;

//′http/′是成功标志

if((recvbuf[i]=′′)and(recvbuf[i＋1]=′2′)and(recvbuf[i＋2]=′0′)

and(recvbuf[i＋3]=′0′)and(recvbuf[i＋4]=′′))theni:=200;

end;

ifi〈〉200thenbeginclosesocket(mysocket);exit;end;

//得到数据起始位置

ptemp:=strpos(recvbuf,＃13＋＃10＋＃13＋＃10)＋4;

index_ch:=ptemp－recvbuf;

//建立下载目录

tryforcedirectories(extractfilepath(getfillocalpath(fileurl)));

except

end;//创建文件

deletefile(getfillocalpath(fileurl));

myhandle:=filecreate(getfillocalpath(fileurl));//如果未接收完则继续

while(reccount〈〉0)do

begin

filewrite(myhandle,recvbuf[index_ch],reccount－(index_ch));

index_ch:=0;

reccount:=recv(mysocket,recvbuf,sizeof(recvbuf)－1,0);

end;//关闭文件句柄和套接字

fileclose(myhandle);

closesocket(mysocket);

http协议【第四篇】

[关键词]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/，主展示web自身的URL是http：//serverhost/seoPatlffweb，ext，则媒体文件真实的http协议下URL为http：//serverhost/scoPath/mediaPath/，这时通过协议头替换，把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和的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生产成本：但这个转换成本相对于一般视频内容生产总成本来说所占比例较小，而且也不是一直都会有，如果采用的可直接输出为这两种格式视频生产工具就没有了再次转换成本。

五　小结