http协议范例【推荐4篇】

【导读指引】阿拉题库漂亮网友为您分享整理的“http协议范例【推荐4篇】”法律文书资料，供您参考学习，希望这篇文档资料对您有所帮助，喜欢就下载分享给朋友吧！

http协议【第一篇】

关键词：万维网；WWW；HTTP；FTP；Web服务器

WWW（World Wide Web，3W，Web）中文译名为万维网，环球信息网等。是欧洲核物理研究中心（CERN）为全球范围的科学家利用Internet建立在客户机/服务器模型之上，为了方便地进行通信、交流和查询所建立的。Internet采用超文本和超媒体的信息组织方式，将信息的链接扩展到整个Internet上。万维网是一个分布式的超媒体（Hypermedia）系统，它是超文本（Hypertext）系统的扩充，所谓超文本是包含指向其他文档的链接文本，超文本是万维网的基础，在万维网中，主要使用了两个协议，分别是HTTP协议和FTP协议。

1 HTTP协议

超文本传输协议（Hypertext Transfer Protocol，HTTP）提供了访问超文本信息的功能，是万维网与Web服务器之间的通信协议，属于应用层。HTTP协议是用于分布式协作超文本信息系统的、通用的、面向对象的协议。可以用于传输各种超文本页面和数据。

HTTP协议包括以下4个步骤：

第一，建立连接。客户端向服务器发出建立连接HTTP报文的请求，服务端将响应发送回客户端，连接建立。

第二，发送请求。客户端按照HTTP协议通过连接线路向服务端发送请求。

第三，给出应答。服务器按照客户端的要求给出应答，将结果HTML文件返回给客户端。

第四，关闭连接。客户端接到HTTP报文请求后关闭连接。

HTTP协议是基于TCP/IP之上的协议，它不仅保证是否能够正确传输超文本文档，而且还要确定传输文档中的哪一部分，以及哪部分内容首先显示等。通常HTTP报文消息包括客户向服务器的请求报文和服务器向客户的响应报文。这两种类型的报文消息由一个起始行，一个或者多个头域，一个指示结束的空行和消息体组成。HTTP的报文结构包括通用首部、请求首部、响应首部、实体首部和实体主体五个部分。每个头域由，和三部分组成。（注意：域名与大小写无关，可以在域值前添加任何数量的空格符，可将万维网的头域扩展为多行。）

通用域名首部包含请求和响应报文，其中的头域还包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via等。对通用头域的扩展要求通讯双方都支持，如果存在不支持的通用头域，一般将会作为实体处理。

一次HTTP操作其工作过程可分为以下几步：

第一，浏览器分析链接指向页面的URL。

第二，浏览器向DNS请求解析IP地址。

第三，域名系统DNS解析出微软服务器的IP地址。

第四，浏览器与该服务器建立TCP链接。

第五，浏览器发出HTTP请求GET。

第六，服务器通过HTTP响应把文件发送给浏览器。

第七，TCP连接释放。

第八，浏览器将文件进行解释，并将Web页显示给用户。

如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，由显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。HTTP采用TCP作为运输层协议，保证了数据的可靠传输，HTTP不需要考虑数据在传输过程中丢失后是怎样重传的，但是HTTP协议本身是无连接的，即通信双方在交换HTTP报文之前不需要先建立HTTP链接。

2 FTP协议

文件传输协议（File Transfer Protocol，FTP）是因特网上使用最广泛的文件传输协议，FTP运行在TCP上采用客户/服务器模型，包括两个组成部分，分别为FTP服务器、FTP客户端。其中FTP服务器用来存储文件，用户可以使用FTP客户端通过FTP协议访问位于服务器上的资源。FTP使用20和21这两个端口，如果采用主动模式，那么数据传输端口就是20；如果采用被动模式，数据传输端口就是21。

FTP提供以下功能：

第一，提供不同种类的主机系统之间的传输。

第二，使用户对远程服务器上的文件进行管理。

第三，提供文件共享能力。

另FTP还有两种模式，主动方式Standard（PORT方式），被动方式Passive（PASV方式）。Standard模式下FTP客户端发送PORT命令到服务器。Passive模式下FTP的客户端发送PASV命令到FTP Server。

Port：FTP客户端与服务器的21端口建立控制连接，用来传输控制信息，客户端发送请求，通过控制连接发送给服务器端的控制进程。服务器通过自己的数据连接端口连接至客户端的指定端口并发送数据。

FTP服务器在很多情况下是不支持PASV模式的，因为很多防火墙在设置时，是不允许接受外部发起连接的，因而位于防火墙后或内网的客户端无法穿过防火墙打开FTP服务器的高端端口，故许多内网的客户端不能用PORT模式登陆FTP服务器，造成无法连接。

文件交换协议（File Exchange Protoco，FXP）相当于是FTP的控制器，也可以认为FXP本身其实就是FTP的一个子集，使一个FTP客户端控制两个FTP服务器，在两个服务器之间传送文件。FTP协议的任务是使计算机将文件传送至另一台计算机，它与这两台计算机所处的位置、联接的方式、是否使用相同的计算机操作系统均没有关系。例如，两台计算机通过FTP协议连接，并且能够成功地访问Internet，用户就可以使用FTP命令来传输文件。

其传输方式可分为两大类：ASCII传输和二进制数据传输。

ASCII传输模式：若客户端当时正在拷贝的文件中包含的简单ASCII码，在机器上运行的是不同的操作系统，当文件传输时，FTP协议通常会自动地调整文件的内容以便于将文件“翻译”成另一台计算机存储的文本文件格式，就是我们通常所说的翻译。但是时常会有这样的情况发生，用户正在传输的文件包含的不是文本文件，它们可能是程序、数据库、字处理文件或者压缩文件等信息。那么这时，ASCII传输模式则会消耗大量的时间、资源进行翻译，与我们所希望的相去甚远，于是，出现了第二种传输方式，二进制传输。

参考文献：

[1] 沈红，李爱华。计算机网络（第二版）[M].清华大学出版社，2010.

[2] 谢希仁。计算机网络（第5版）[M].电子工业出版社，2011.

作者简介：周开强（1993―），男，黑龙江庆安人。

张广旭（1994―），男，辽宁建昌人。

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生产成本：但这个转换成本相对于一般视频内容生产总成本来说所占比例较小，而且也不是一直都会有，如果采用的可直接输出为这两种格式视频生产工具就没有了再次转换成本。

五　小结

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）.