HTTP协议

HTTP协议（精选9篇）

HTTP协议 篇1

21世纪是信息时代。当前的万维网是一个巨大的存储、共享文本和图像信息的分布式媒介, 计算机是展现文字或图像的一个平台。从万维网上获取文本资源的集合可以作为Web挖掘的语料库。随着信息科学技术的发展, 基于HTTP协议POST请求的文档量占的比重越来越大, 研究如何快速并准确地从万维网中抓取POST请求类型的文本数据能够丰富Web挖掘技术的语料库, 同时对其他需要大量POST文本数据的行业也有一定的意义。

本课题主要研究如何从万维网中抓取带有持续Cookie (persistent cookie) 的POST文本数据。现以Windows7的32位系统作为测试平台, 以eclipse Mars.1为开发平台, 研究一个快速抓取POST文本数据的方法。

HTTP协议概述

HTTP协议, 即超文本传输协议 (Hyper-text transfer protocol) , 是用于从万维网服务器传输超文本到本地浏览器的传送协议。HTTP是一个应用层协议, 由请求和响应这两种报文组成。请求方法有8中类型, GET、POST、HEAD、PUT、DELETE、TRACE、CONNECT和OPTIONS等。其中GET和POST是最常见的两种请求方式。GET是以实体的方式得到由请求URI所指定资源的信息, 如果请求URI只是一个数据产生过程, 那么最终要在响应实体中返回的是处理过程的结果所指向的资源, 而不是处理过程的描述。POST则用来向目的服务器发送请求, 要求它接受背负在请求后的实体, 并把它当作请求队列中请求URI所指定资源的附加新子项, POST被设计成用统一的方法实现下列功能:

对现有资源的解释;

向电子公告栏、新闻组、邮件列表或类似讨论组发信息;

提交数据块;

通过附加操作来扩展数据库等。

POST请求报头信息分析

请求报头允许客户端向服务器端传送请求的附加信息以及客户端自身的信息。例图1介绍了一个典型的POST请求报头, 它主要包含以下字段:Accept字段表示浏览器支持的MIME (Multipurpose Internet Mail Extensions) 类型;AcceptEncoding字段表示浏览器有能力解码的编码类型;AcceptLanguage字段表示浏览器所支持的语言类型;Connection字段表示客户端与服务器连接的类型;Content-Type字段表示网络文件的类型和网页的编码格式;Cache-Control字段指定了请求遵循的缓存机制;User-Agent字段表示浏览器版本信息;X-Requested-With字段的值为XMLHttp Request表示请求是Ajax异步请求, 值为nul表示请求是传统同步请求;Host字段表示请求的服务器网址;Cookie字段是一些网站为了辨别用户身份、进行session跟踪而存储在用户本地终端商的数据。

POST文本数据抓取方案设计

抓取POST文本数据的基本流程如图1。首先, 需要读取字符串url, 并根据字符串url建立URL类的实例post URL, 此后需要建立post URL连接, 这将返回一个Http URLConnection类的对象connection, 此时并没有创建实际的网络连接。其次, 要给对象connection设置连接属性, 其中, 首先要调用set Request Method方法将请求方式设置为POST;其次需分调用set Do Output和set Do Input方法将参数都设置为true, 这是因为POST请求的参数是放在http正文内;此后, 需要调用set Request Property方法, 该方法有两个参数分别是key和value, 参数key可参考表1中第一列的数据来设置, 参数value的值与表1中第二列的数据类似, 针对来自不同的源的POST网页可依照抓包代理工具中捕获的POST请求报头信息来设置key和value的值。设置好连接属性后, 就可以调用connection对象的connect方法来打开到post URL引用的资源的通信链接。应该注意的是, 设置连接属性必须在打开连接之前, 否则将会发生错误。最后, 建立字符输入流对象读取文本数据并保存到本地, 流程结束。

若要批量抓取POST文本数据, 需要对图1中描述的方案的流程进行改进。在给对象connection设置连接属性这一步骤中, 有一个字段为Cookie。Cookie分为非持续Cookie (nonpersistent cookie) 和持续Cookie (persistent cookie) 。如果没有给Cookie设置过期时间, 则Cookie会在关闭浏览窗口时消失, 这样的Cookie被称为非持续Cookie。非持续Cookie一般被保存在内存里。如果设置了Cookie的过期日期, 则它将被一直保存直到过期位置, 这样的Cookie被称为持续Cookie。火狐浏览器的持续Cookie被保存在数据库cookies.sqlite中, 过期日期由expiry字段记录。获取持续Cookie的方法有以下两种:

连接数据库cookies.sqlite, 选择表moz_cookies, 读取name、value和expiry字段的值;

建立Web Driver类的对象打开浏览器, 建立并打开url链接后获取cookie的name、value和expiry字段的值。

第一种方法在数据库cookies.sqlite中表格的数据没有加密的情况下可通过Class.for Name (org.sqlite.JDBC) 连接SQLite的JDBC来实现。第二种方法的原理是在打开浏览器并打开url链接时保存服务器向客户端发送的Cookie。显然, 第二种方法比第一种方法更加通用。因此, 本课题采用第二种方法来获取Cookie, 流程图见图2。

采用图2中描述的方法可以完整地得到Cookie的name和value, 又根据持续Cookie有过期日期的特性, 设计出了批量抓取POST文本数据的流程图, 见图3。当保存好当前抓取到的文本数据后, 并在抓取下一个页面前, 需要判断当前日期是否在Cookie的过期日期之前。若为真, 说明此前得到的Cookie仍然有效, 可继续使用;若为假, 需要刷新网页重新抓取Cookie和过期日期。由于在获取Cookie的过程中打开了firefox浏览器, 因此抓取完预计的所有页面后, 需要关闭浏览器, 到此整个流程结束。

实验结果

调试好各模块的程序后, 需配置好URL和文本的保存路径。以中国裁判文书网为例, 运行程序, 见表2所示的统计结果。

结束语

本文介绍了抓取POST文本数据的详细步骤, 在执行抓取文本程序的过程中, 曾出现过返回502 Bad Gateway的HTTP状态消息的情况。这是由于服务器从上游服务器收到一个无效的响应。此种情况可通过记录抓取进程的方式解决, 在再次执行程序时就不会出现抓取重复文本的错误。通过反复的实验, 验证了此种抓取方式的可行性, 并且操作简单。

摘要：现如今, 基于HTTP协议的POST文本量越来越多, 有选择性地抓取这种类型的文本数据可以丰富Web挖掘技术的语料库。通过研究带有persistent cookie的POST请求, 设计了一种抓取POST文本数据的方法。在设置好各项参数后, 可以抓取大量文档, 操作简单, 可行性强。在抓取类似POST请求的文本数据时, 更改几项参数即可实现批量抓取文本数据的目的。

HTTP协议 篇2

Python采用httplib库进行HTTP通讯，用法很简单：

import httplib #导入httplib库

conn = httplib.HTTPConnection(“10.197.32.136”,8080)#建立http链接，只需要IP地址和端口

conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str,{})#发送url请求

response = conn.getresponse()#获取返回信息

conn.close()#关闭链接

request函数是非阻塞函数，也就是说，它向服务器发送了url请求之后，可以正常运行之后的任务。

getresponse函数是阻塞函数，如果没有收到服务器的返回信息，程序将无法继续。

close函数在任何地方都可以调用，因此，如果无需服务器返回信息，则可以在发送请求之后就关闭链接。

Httplib无法连续发送两个request，例如：

conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str1,{})conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str2,{})

程序将会抛异常，并且关闭。因为http协议本身一次链接只支持一个request，在收到response或者关闭才能开启下一次链接。所以，正常的程序应该是：

conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str1,{})

conn.close()

或者：

conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str1,{})

response = conn.getresponse()

HTTP协议 篇3

Web的应用层协议HTTP是Web的核心。HT-TP在Web的客户程序和服务器程序中得以实现。运行在不同端系统上的客户程序和服务器程序通过交换HTTP消息彼此交流。HTTP定义这些消息的结构以及客户和服务器如何交换这些消息。Web页面(Web Page)也称为文档,由多个对象构成。对象(Object)仅仅是可由单个URL寻址的文件,例如HTML文件、JPG图像、GIF图像、JAVA小应用程序、语音片段等。大多数Web页面由单个基本HIML文件和若干个所引用的对象构成。HTTP定义Web客户(即浏览器)如何从Web服务器请求Web页面,以及服务器如何把Web页面传送给客户。

1 HTTP协议

超文本传输协议(HTTP)是一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方式。绝大多数的Web开发,都是构建在HTTP协议之上的Web应用。本程序实现的是一个轻量级的Web服务器[1]。

(1)HTTP请求由3部分组成,分别是:请求行、消息报头、请求正文。

请求行以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本,格式如下:Method Request-URI HTTP-Version CRLF。其中Method表示请求方法;Request-URI是一个统一资源标识符;HT-TP-Version表示请求的HTTP协议版本;CRLF表示回车和换行(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)[2]。

(2)HTTP响应由3个部分组成,分别是:状态行、消息报头、响应正文。

状态行格式是:HTTP-Version Status-Code Reason-Phrase CRLF,其中HTTP-Version表示服务器HTTP协议的版本;Status-Code表示服务器发回的响应状态代码;Reason-Phrase表示状态代码的文本描述。状态代码由3位数字组成,第1个数字定义了响应的类别,且有五种可能取值[3]:

2 HTTPSVR程序分析

HTTPSVR是一个简单的Web服务器,具有图形界面,可以指定端口和Web主目录,且可以生成Web访问的日志,它由一个无限循环构成:接收来自客户端的请求,根据HTTP协议解析并处理请求,然后发送应答至客户端。

2.1 HTTPSVR主要工作流程图

HTTPSVR功能强大,具有丰富的图形界面,主要的工作流程如图1所示[5]。

首先通过CListenSocket::OnAccept(int nErrorCode)函数生成CRequestSocket类,监听到连接请求时,Accept函数创建新的套接字pRequest并返回句柄,AsyncSelect函数监听80端口的FD_READ和FD_CLOSE两个事件,当传入FD_READ事件时,准备接收,并且触发OnReceive()函数,如果传入FD_WRITE事件,发送数据的时候,OnSend()函数就会触发。

当有数据到达时,执行ReqSock.cpp中的void CRequestSocket::OnReceive(int nErrorCode)函数。代码int nBytes=Receive(m_buf.GetData(),m_buf.GetSize())将tcp层上传的数据包存放在请求和应答报文的缓冲区m_buf中。

接下来使用swich语句对3种请求状态(REQ_REQUEST,REQ_HEADER,REQ_BODY)进行处理,当请求状态m_reqStatus==REQ_DONE,调用StartResponse()开始构造应答报文。

当StartResponse()构造应答报文结束后,利用AsyncSelect(FD_WRITE|FD_CLOSE);调用void CRequestSocket::OnSend(int nErrorCode)函数发送缓冲区m_buf中的数据[6]。

2.2 异步非阻塞类CAsyncSocket

CAsyncSocket的Create()函数,除了创建了一个Socket以外,使用WSAAsyncSelect()将这个Socket与该窗口对象关联,以让该窗口对象处理来自Socket的事件(消息),然而CSocketWnd收到Socket事件之后,只是简单地回调CAsyncSocket::OnReceive()CAsyncSocket::OnSend(),CAsyncSocket::OnAccept(),CAsyncSocket::OnConnect()等虚函数。所以CAsyncSocket的派生类,只需要在这些虚函数里添加发送和接收的代码。使用CAsyncSocket时,如果使用Create缺省创建socket,则所有网络I/O都是异步操作,进行有关网络数据传输时需要用到以下函数:OnAccept,OnClose,OnConnect,OnOutOfBandData,OnReceive,OnSend[7]。

2.3 HTTPSVR关键类分析

void CListenSocket::OnAccept(int nErrorCode)创建新的CRequestSocket,并监听80端口,请求到达时返回套接字,并通过AsyncSelect(FD_READ|FD_CLOSE)调用void CRequestSocket::OnReceive(int nErrorCode)函数接收数据。

void CRequestSocket::OnReceive(int nError-Code)[8]实现httpsvr的所有主要功能,包括接受浏览器的请求,根据Http协议解析请求报文,构造应答报文,将处理后的数据发送回浏览器。Receive(m_buf.GetData(),m_buf.GetSize())函数接收来自浏览器的请求数据包,switch语句根据不同的状态处理。浏览器的请求状态m_reqStatus为REQ_REQUEST时,使用while循环进行处理。ProcessLine()函数对接收到报文的每一行进行解析,然后初始化m_pRequest类。Swich语句结束后调用StartResponse()根据m_pRequest中的解析结果构造应答报文,最后函数AsyncSelect(FD_WRITE|FD_CLOSE)调用OnSend函数进行发送。

void CRequestSocket::OnSend(int nErrorCode)调用int nBytes=Send(m_buf.GetData(),m_cbOut)函数发送缓存中的数据,并对可能出现的错误进行处理,或者关闭或者重新进行发送。

void CRequestSocket::ProcessLine(void)根据请求状态m_reqStatus的不同作出处理,完成对CRequest*m_pRequest的初始化。

BOOL CRequestSocket::StartResponse(void)[9],该函数用于构造应答报文(将构造好的应答报文缓存在m_buf中,用void CRequestSocket::OnSend(int nErrorCode)发送m_buf),并根据不同的Method(GET,HEAD,POST)构造应答报文。例如当Method为GET时,表示浏览器需要浏览网页,就用FindTarget(strFile);在默认目录底下进行查找,如果存在则打开报文,并使用StuffHeading()构造http协议要求的头部,然后使用StartTargetStuff();将刚才打开的网页内容填充到m_buf中,等待发送,构造完毕后再返回BOOL CRequestSocket::StartResponse(void),然后调用AsyncSelect(FD_WRITE|FD_CLOSE);该函数调度void CRequestSocket::OnSend(int nErrorCode)对缓存m_buf中的数据进行发送。

BOOL CRequestSocket::FindTarget(CString&strFile),由于浏览器发送过来的请求都是网络地址格式的,所以该函数将网络地址格式转为windows文件系统的路径格式。例如发送:GET/default.html,经过本函数转换之后变为c:WebPagesdefault.html(httpsvr默认根目录为c:WebPages)。

void CRequestSocket::StartTargetStuff(void),该函数读取客户端请求浏览的网页文件内容到m_buf中,等待进一步发送。

UINT CGIThread(LPVOID pvParam)[10],该函数以线程的方式运行,调用相应的GCI函数处理,并输出结果到一个临时文件。该线程处理完毕后,再由BOOL CRequestSocket::StartResponse(void)将临时文件发给浏览器。

3 HTTPSRV程序执行过程

3.1 运行函数

程序由MFC中的文件APPMODULE.CPP的_tWinMain函数开始执行,执行该文件的return AfxWinMain函数。

3.2 链接服务器

由WINMAIN.CPP文件中的int AFXAPI AfxWinMain函数来创建工作线程pThread对httpsvr进行初始化工作,调用HttpSvr.cpp文件中的BOOL CHttpSvrApp::InitInstance方法对HTTP服务器进行初始化,然后运行线程的主函数,最后在THRD-CORE.CPP文件中运行int CWinThread::Run函数,开始服务器的循环。

在循环中,首先调用Listen.cpp中的void CListenSocket::OnAccept方法,生成CRequestSocket,将其设置用于监听8080端口。设置端口为8080,将Web服务文件夹地址Root Dir指向root所在地址。此时显示结果如图2所示。

3.3 请求客户

在ReqSock.cpp文件中,根据响应状态m_reqStatus的不同,对接收到的数据包进行不同的响应处理。当browser发送第一个数据包时,响应状态m_reqStatus被设置为REQ_REQUEST,之后,对REQ_RE-QUEST数据包的每一行进行处理,根据http的协议使用ProcessLine方法对m_pRequest进行初始化,完成以上操作之后,调用判断StartResponse方法来构造应答报文,运行AsyncSelect函数,之后其调用void CRequestSocket::OnSend方法将缓存m_buf的应答报文发送给客户端,如图3所示。

当点击submit,返回页面如图4所示。

4 结语

通过对该HTTP服务器程序的分析,熟悉了HTTP服务工作流程,对Socket有更深的了解,可以创建异步Socket的方法。本文对所给的具有图形界面HTTP服务器程序源代码进行分析和调试,介绍程序实现的主要功能,运行过程以及程序中各类实现的功能。当然,这个程序实现的只是一个轻量级的服务器,其功能相对比较简单。熟悉了基于HTTP协议服务器创建的基本原理,以后就能在此基础上实现功能更加丰富的服务器。

摘要：绝大多数的Web开发,都是构建在HTTP协议之上的Web应用。为了分析基于HTTP协议服务器程序以及浏览器与服务器的交互过程,以一个简单的基于HTTP协议中服务器程序为实例,探讨怎样使用多线程与异步操作的理论,运用WinSock编程来逐步解析HTTP协议的服务器程序的核心部分,这样既可达到避免调用线程阻塞的目的,又可提高服务器程序的可响应性。

关键词：HTTP,HTTP协议,服务器,WinSock

参考文献

[1]叶强.超文本传输协议:HTTP/1.0[J].科技情报开发与经济,2004(8):66-68.

[2]肖戈林.HTTP协议技术探析[J].江西通信科技,2001(1):39-41.

[3]FIELDING R,GETTYS J,MOGUL J,et al.RFC 2068hypertext transfer protocol-HTTP/1.1[J].MIT/LCS,UCIrvine,1999(1):37-38.

[4]徐健,王涛.HTTP/1.1的分析[J].西南师范大学学报:自然科学版,2004(2):47-48.

[5]蒋东兴.网络程序设计大全[M].北京:清华大学出版社,1999.

[6]TANENBAUM A S.计算机网络[M].潘安民,译.北京:清华大学出版社,2004.

[7]李腊元,李春林.计算机网络技术[M].北京:国防工业出版社,2004.

[8]蔡皖东.HTTP协议的传输机制与超文本链的研究[J].微电子学与计算机,1997(4):53-55.

[9]王艳平,张越.Windows网络与通信程序设计[M].北京:人民邮电出版社,2006.

HTTP协议 篇4

关键词：TCP UDP HTTP PDA

引 言

超文本传输协议（HTTP）是目前通过Internet进行信息交换最主要的方式。HTTP协议是建立在请求/响应(request/response)模型上的。首先由客户建立一条与服务器的TCP链接，并发送一个请求到服务器，请求中包含请求方法、URI、协议版本以及相关的MIME(Multipurpose Internet Mail Extensions)样式的消息。服务器响应一个状态行，包含消息的协议版本、一个成功和失败码以及相关的MIME式样的消息(包含服务器的信息、资源实体的信息和可能的资源内容)。图1给出了HTTP协议实现的一个简单模型。HTTP/1.0[3]为每一次HTTP的请求/响应建立一条新的TCP链接，因此一个包含HTML内容和图片的页面将需要建立多次的短期的TCP链接。一次TCP链接的建立将需要3次握手。另外，为了获得适当的传输速度，则需要TCP花费额外的回路链接时间（RTT）。每一次链接的建立需要这种经常性的开销，而其并不带有实际有用的数据，只是保证链接的可靠性，因此HTTP/1.1[4]提出了可持续链接的实现方法。HTTP/1.1将只建立一次TCP的链接而重复地使用它传输一系列的请求/响应消息，因此减少了链接建立的次数和经常性的链接开销。

可持续链接减少了每次TCP链接建立的时间，但是一个空闲的TCP链接将需要一个Socket和相应的存储缓冲区。一个Socket缓冲区的最小长度必须大于一个TCP包的最大长度，即64 KB，而且很多实现方法在链接建立时将预分配一些缓冲区。可用的Socket的数量是有限的，很多基于BSD的操作系统对于能够同时打开的链接数都有一个缺省的最大值。

无线掌上设备PDA的应用（如浏览器）[5]特点表现在：① 因为页面是针对掌上设备制作的，一般在1 K~2 K字节，比较小；② 目前无线通信网络的带宽很窄，GSM的数据信道带宽只有9.6 K。当前Web页面的访问大多通过HTTP协议，并使用TCP作为下层的传输控制协议。但不幸的是，TCP并不适合短会话的应用情况，不同于现在采用的使用单一TCP传输协议进行数据传输的方式。本文提出了采用动态选择传输层协议（TCP、UDP）的方法来改善取回页面的延迟、网络拥塞以及服务器的负荷。

这种混合TCP-UDP的方法结合两个方面的优点：首先，对于需要比较少数据传输的情况，它将使用UDP作为传输层的协议，从而避免了TCP链接的多次握手开销；另外，对于需要较多数据传输的情况，它将使用可靠的带有重排序和拥塞控制的TCP协议作为传输层的协议。混合TCP-UDP的实现方法只需要对应用层的改动，而操作系统的核心代码不用任何更改。仅采用UDP协议的缺点在于，需要在应用层建立一套类似于TCP复杂的控制协议，从而进行重排序和拥塞控制来保证传输的可靠性。背 景

HTTP是一个请求/响应协议，客户端的应用程序通过提供一个URL可以从服务器上得到所需的数据。HTTP可以用来访问各种不同类型的资源，其中包括文本、图形、影音、可执行文件、数据库查询结果等等。

图2给出了在客户端发起HTTP GET请求后，在客户端和服务器之间进行数据包交换的示意。图中只有两个数据包是有用的（即携带了数据）：一个是HTTP GET请求，另一个是HTTP的响应。其它的都是TCP用来进行握手操作的数据包。为了减轻Web服务器的负荷，经常采用重定向机制。这样从服务器发来的重定向响应报文是很短的数据包。使用TCP作为传输协议需要至少7个数据包，而使用UDP则只需要2个数据包就足够了。设 计

我们使用混合传输层[6]的方法即对于少量数据传输的链接采用UDP，而对于大量数据传输的链接采用TCP作为传输层协议。这样对于短链接而言就避免了TCP经常性的握手开销，而对于长链接则仍可获得TCP的优点，如超时重传、拥塞控制、错误恢复机制等。这种方法中，客户端首先尝试使用UDP作为传输层的协议，如果对于所请求的URL UDP并不适合，则再次使用TCP链接。这种方法提供了以下保证：

◇ 如果初始的UDP数据包丢失，将采用TCP重新链接而不会受到影响。

◇ 如果所链接的服务器没有使用混合传输层的实现机制，客户端将使用TCP重新进行链接。

图3给出了混合TCP、UDP的实现算法。一个采用混合算法的HTTP客户端首先使用UDP作为传输层的协议发出HTTP GET请求，同时启动超时定时器。

当服务器处理客户端发来的请求时，它可以从以下两点做出选择：

① 如果响应的数据足够小（比如，可放到一个数据包中），服务器将使用UDP发回响应。像比较小的网页或HTTP REDIRECT响应就属于这一类。

② 如果响应的数据很大，无法放进一个UDP数据包中，服务器则要求客户端使用TCP重试。这可以通过添加一个HTTP的头部字段来解决如 TCPRETR。

在客户端，将会出现以下三种情况：

◇ 客户端从服务器接收到响应。如果响应中包含了所需的HTTP响应，客户端将对数据进行处理。如果服务器要求客户端重试，客户端将使用TCP作为传输层重试。

◇ 如果服务器没有处理通过UDP传输的HTTP包，客户端就会收到ICMP错误消息（目的地址无法到达/协议无法到达）。此时客户端将会使用TCP重试。

◇ 如果定时器超时，客户端应使用TCP重试。

图4给出了在定时器超时情况下，客户端和服务器之间数据包的交换。这种超时机制提供了可靠性，以及与未使用混合TCP-UDP方法的服务器的兼容性。

图5示意了服务器要求客户端使用TCP重发请求时，客户端和服务器之间的数据包交换。结 语

混合TCP-UDP方法改善了参与HTTP传输的三个方面：客户端、服务器和网络。

◇ 对于客户端而言，可以避免由于TCP而引入的三向握手的时间，从而减少了浏览的延迟时间。

◇ 对于服务器而言，由于所需的TCP的链接数量减少，从而降低了由于建立、维护、撤销TCP链接所带来的服务器的负荷。

HTTP协议 篇5

关键词：ZONE-BASE,防火墙,HTTP协议过滤

引言

当前, 一些别有用心的国家持续对我国发起大规模、系统性的网络攻击, 导致重要资源的泄露和恶意篡改, 如何有效防止黑客的恶意攻击已经成为我国当前发展的一个重要课题。防火墙技术, 最初是针对Internet网络不安全因素所采取的一种保护措施。顾名思义, 防火墙就是用来阻挡外部不安全因素影响的内部网络屏障, 其目的就是防止外部网络用户未经授权的访问[1]。它是一种计算机硬件和软件的结合, 使Internet与Internet之间建立起一个安全网关, 从而保护内部网免受非法用户的侵入, 防火墙就是一个位于计算机和它所连接的网络之间的软件或硬件, 该计算机流入流出的所有网络通信均要经过此防火墙[2]。

1. 防火墙分类

防火墙是保护局域网免受外部网络攻击的最有效措施, 从发展过程来看, 主要分成两大类, 一是经典防火墙, 二是ZONE-BASE防火墙。经典防火墙是一种比较老一点的技术, 能有效的实现内部, 外部以及DMZ区域之间流量的过滤, 不足之处在于不能实现单机的有效控制, 比如要限制单独访问或不能访问某一台服务器, 用经典防火墙技术根本实现不了。正是在这种情况下, ZONE-BASE防火墙出现了, 它是一种新的防火墙技术, 完美的实现对单独服务器的访问权限的设置。

2. ZONE-BASE防火墙简介

ZONE就是区域, 所以ZONE-BASE防火墙就是基于区域划分的一种新技术。因为区域化分防火墙是基于区域的, 策略也只能在区域间传递数据时才生效, 在区域内是不生效的, 所以我们就可以将需要使用策略的接口划入不同的区域, 这样就可以应用我们想要的策略[3]。但是, 有时某些接口之间可能不需要彼此使用策略, 那么这样的接口只要划入同一个区域, 它们之间就可以任意互访了。ZONE是应用防火墙策略的最小单位, 一个ZONE中可以包含一个接口, 也可以包含很多接口。

3. ZONE BASE防火墙的HTTP协议配置和实现

本文研究的是ZONE-BASE防火墙对应用层HTTP协议的过滤。应用层协议是用于解决某一类网络应用问题的、位于不同主机中的多个应用进程之间的通信规则和约定。应用层的具体内容就是规定应用进程在通信时所遵循的协议。当前常见的应用层协议包括:FTP、Telnet、SMTP、HTTP、RIP、NFS、DNS等, 本文以HTTP为例, 通过在ZONE-BASE防火墙上进行正确的配置来对HTTP的URI进行过滤, 有效防止恶意内容传送到终端, 以及防止恶意级协议流量传送到终端, 从而达到限制某些指定的不可信的网址无法打开, 保证网络的安全。

3.1 URI与网络安全协议配置

URI有绝对和相对之分, 绝对的URI指以冒号开头的URI。比如, http://www.gdufs.edu.cn/computer/re.php, 冒号后面就是绝对的URI的一个例子, 其它的例子还有mailto:xxx@xxx.xx。你可以把绝对的URI看作是以某种方式引用某种资源, 而这种方式对标识符出现的环境没有依赖。如果使用文件系统作类比, 绝对的URI类似于从根目录开始的某个文件的路径。

相对的URI不是以冒号开始的URI, 相对的URI类似于从当前目录开始的文件路径。在上面的网址中, 其中computer/re.php就是一个相对的URI。本文讨论的是相对的URI.

3.2 实验拓扑

为了实现对应用层HTTP协议的URI过滤, 我们采用了如下拓扑结构:

如图所示:在外网有一台网站服务器, 网址为http://www.gdufs.edu.cn。在ZONE-BASE防火墙进行配置前, 在内部可以通过XP操作系统对该网站主网址及子网址进行访问, 配置后, 对于其网址内包含有字符”abc”的网址都不可以访问。比如在浏览器无法打开http://www.gdufs.edu.cn/abc/index.php。

3.3 配置步骤

步骤一:在防火墙上创建两个ZONE, 分别是内部ZONE (IN) 和外部ZONE (OUT) 。例如:创建内部ZONE方法:FW (config) #zone security IN;

步骤二:将防火墙左右两个接口分别加入到对应ZONE, 左边接口加入外部ZONE, 右边接口加入内部ZONE。做完这一步, 防火墙开始起作用, 将内部区域和外部区域完全隔开, 内外完全不通。接下来的步骤三到步骤五是对HTTP流量放行, 实现内部区域可以访问外面网站服务器。将接口加入内部ZONE的方法:

步骤三:创建class-map指定需要放行的协议, 我们在这放行HTTP协议, 因为需要深度监控HTTP的URI, 在这里需要在class-map中使用一个访问控制列表来达到目标;具体实现方法如下:

步骤四:创建policy-map调用步骤三创建的class-map并对步骤三定义的协议采取放行动作。具体实现如下:

步骤五:创建zone-pair对, 调用步骤四定义的policy-map, 从而实现了内部任何设备可以访问外部的网站服务器的所有网址。到这一步为止, 在ZONE BASE防火墙上实现了从内部到外部网站的HTTP流量放行, 但是还没有做任何过滤, 接下来步骤六到步骤八实现了HTTP的过滤功能。具体实现如下:

步骤六:创建参数MAP, 匹配正则表达式:

步骤七:创建一个应用层的class-map对指定的URI过滤, 在这里, 我们采用正则表达式匹配URI, 然后在class-map里调用该正则表达式。具体实现如下:

步骤八:创建一个应用层的policy-map, 调用第七步创建的class-map, 然后对需要过滤的URI采取相应的动作, 具体实现如下:

步骤九:在步骤四调用的class-map里面调用步骤八创建的policy-map.

3.4 实验

在XP上打开浏览器, 输入网址www.gdufs.edu.cn, 可以正常访问, 但包含关键字abc的网址已经被过滤, 无法打开;同时可以在防火墙上看到相应的日志信息。在Inside设备上已经无法执行telnet 20.1.1.1 80, 同时也可以看到日志信息。

4. 结束语

互联网技术的发展使得计算机应用越来越普及, 但是, 也随之带来了更多的网络安全问题, 在这一背景下如何更好的利用防火墙技术显得由其重要。本文研究的是在防火墙上采用划分区域的方法来对HTTP协议流量进行过滤, 从而实现了对一些非法网站的有效屏蔽。相信随着防火墙技术的发展, 互联网上的安全问题会进一步得到有效控制和解决。

参考文献

[1]吴秀梅.防火墙技术及教程[M].清华大学出版社, 2010.

[2]于婷婷.浅谈Internet防火墙技术[J].计算机光盘软件与应用2012.4

HTTP协议 篇6

一、HTTP Basic Authentication定义

HTTP Basic认证是通过HTTP协议中的Authorization头来传递认证相关信息的, 而其中的Basic认证就是其中一种认证, basic认证要求认证的用户名和口令对, 也就是例如这样的形式:myuser:mypassword这样的信息对 (myuser为用户名, mypassword为密码) , 而且用户名和口令对要放在HTTP的头域中传输。

二、HTTP Basic优点

1、HTTP是无状态的, 即使来自同一个客户端, 对同一个realm内资源的每一个访问还是会被要求进行认证。

2、客户端会缓存用户名和密码, 并和认证域 (authentication realm) 一起保存。所以, 如果对同一个域 (realm) 的其它资源进行访问, 不需要你重新输入用户名和密码。

3、登录信息会和认证域以及服务器名一起存储, 所以可以很好地和其他登录信息区分开来。

4、所有流行的网页浏览器都支持基本认证。

三、HTTP Basic编码实例

HTTPbasic执行过程:

1、我们先将用户名和密码拼接成一个字符串, 两者之间使用":"分隔。

2、然后使用commons-codec的Base64将这个字符串加密。在进行basic认证的时候Spring Security会使用commons-codec把这段字符串反转成用户名和密码, 再进行认证操作。

3、下一步为加密后得到的字符串添加一个前缀"Basic", 这样Spring Security就可以通过这个判断客户端是否使用了basic认证。

四、HTTPbasic应用

HTTP基本认证是最简单也是曾经使用过很长时间的一种认证方式。基本认证要求为每一个保护域 (realm) 提供一个用户名和密码进行认证。

1、客户端浏览器访问一个受HTTP基本认证保护的资源。

2、服务器返回401 (authentication required) 状态, 要求客户端提供用户名和密码进行认证。Response Header里面有一个属性WWW-Authenticate, 它的值比如:Basic realm="Restlet tutorial"。

3、客户端弹出一个窗口, 用于输入用户名和密码 (基本上所有的浏览器都提供对基本认证的支持, 它们都内建了一个用户名密码输入窗口) 。

4、输入用户名密码并确认之后, 客户端把%username%:%password%用Base64进行编码后通过Request Header:Authorization传送给服务器, 所以可以看到HTTP基本认证是明文传输, 安全风险很大。比如Authorization:Basic xxxxxxxxxx.

5、如果认证成功, 则返回相应的资源。如果认证失败, 则重新进行认证。

参考文献

[1]肖德琴.电子商务安全.高等教育出版社, 2009

一种抵御HTTP洪水攻击的方法 篇7

HTTP泛洪是分布式拒绝服务攻击(DDoS)的一种常见攻击形式,其攻击对象主要是Web服务器。当前的HTTP泛洪攻击的趋势是模仿正常访问行为,傀儡主机在脚本的控制下向服务器大量发送貌似合法的请求,从而消耗服务器的CPU、内存、数据库等资源,同时带来信息安全问题[1]。

当前区分傀儡主机与人的方法可归类为四种:图形迷题法[2]、超链接诱饵法[3]、语义模型法和请求时间特征法[4]。图形迷题法成本较低,但会对正常的用户访问造成困扰;超链接诱饵法和语义模型法可以检测遍历式攻击,但难以检测经过刻意训练的机器请求;请求时间特征法有比较高的成功率,但目前文献没有提供具体的实施方案。

本文采用请求时间特征法,结合ASP.NET的技术特点,提出一种基于Web日志监视的主动防御方法,它包括三个主要环节:一是定制Web日志字段;二是设计一个Web日志监视器,定时分析日志,筛选出可疑用户(傀儡主机);三是设计一个HTTP模块,该模块对用户请求进行预处理,采用URL重写技术将CookieId和SessionID写入Web日志,并拦截来自傀儡主机的请求。

1 定制Web日志格式

Web日志记载了用户的请求记录,为分析用户行为提供了基础。在默认情况下,Web日志中的字段内容很少,本方法需要对Web日志定制字段,使其包含(但不限于)如下字段:

#Fields: time cs-uri-query sc-status cs(User-Agent)

以上字段在本方法中的作用:(1) time字段用于分析用户请求的时间特征;(2) cs-uri-query字段包含cookie或者sessionId,用于用户识别;(3) sc-status字段用于数据清理,本方法只处理状态码为200(即请求被正常响应)的记录;(4) cs(User-Agent)字段用于识别网络蜘蛛。

2 Web日志监视器的设计

Web日志监视器的作用是通过Web日志的定时分析,发现用户请求时间特征,从而识别傀儡主机。

2.1 监视器的工作原理

(1) CookieId或SessionId作为身份标示。

Cookie和SessionID都是由服务器端分发给客户端的,客户端无法修改,适合用于身份标示[5]。CookieId相同的请求,认为来自同一用户,SessionID相同的请求,认为来自同一用户的一个连续时间段。

(2) 根据请求时间特征识别傀儡主机。

由机器发起的请求,其特征是网页停留时间短,刷新频率快,显然不同于人。从日志中可以提取具有这些特征的用户标示(CookieId和SessionId),凡持有这些标示的请求将被拦截。当然,傀儡主机经过训练也可以降低其请求频率,但对网站的威胁也就随之下降了,这种情况可以不去处理。

(3) 根据Agent识别网络蜘蛛。

傀儡主机中可能包含著名搜索引擎的网络蜘蛛,网络蜘蛛都会在Agent字段中标明蜘蛛身份,通过Agent字段检查,避免对网络蜘蛛的错误过滤。

2.2 监视器的工作流程

日志监视器在服务器的后台运行,使用一个Access数据库来存放分析结果,数据库包含三个表:TLog(请求记录表)、TSpan(每次请求与上次请求间隔时间表)、TDefent(傀儡主机身份标示表)。监视器的工作流程如下:

(1) 设定分析时间间隔参数T、傀儡主机特征参数(分析周期内的请求次数上限MaxCount、平均间隔时间下限MinSpan);

(2) 读取日志文件格式;

(3) 依次读日志中的每条记录,将状态码为200且与当前时间间隔小于T的记录写入到TLog数据表中;

(4) 取TLog中数据,按Cookie和SessionId排序,经处理得到用户时间T内的每次请求与上次请求的间隔时间,写入TSpan数据表中;

(5) 读TSpan表,统计访问次数与平均间隔时间,将符合傀儡主机特征的CookieId和SessionID写入TDefent数据表中;

(6) 线程停止时间T,清空TLog和TSpan,转到(3)。

3 HTTP模块的设计与引用

在ASP.NET框架中,HttpModule是HTTP请求的“必经之路”, HttpModule负责监听请求,在请求被处理之前附加一些信息或者终止请求。ASP.NET有内置的HTTPModule,可以通过自定义一个实现接口IHttpModule的类,来取代该HttpModule。

3.1 HttpModule的设计

本方法中,自定义的HTTPModule实现两项功能,第一是进行URL重写,在URL后添加查询参数,使之包含CookieId和SessionId信息;第二是检查请求中的CookieId和SessionId与TDefent表进行匹配,如果匹配成功,则拦截该请求。

自定义的HttpModule代码结构如下:

3.2 HTTPModule的引用

在网站应用程序中,添加上述模块的引用,然后在Web.Config中添加以下配置项:

经过以上配置,所有去往该网站的HTTP请求,都要经过HTTPModule的处理,傀儡主机的请求被拦截在网站的处理核心之外,网站服务器的CPU、内存和数据库资源得到保护。

4 实验与应用

4.1 实 验

选择一个ASP.NET网站作为测试对象。先定制IIS日志格式,然后在网站服务器上部署监视器和自定义的HTTPModule,配置网站的web.Config,使HTTPModule在网站上运行。日志监视器的间隔分析时间T设置为5分钟,根据日常的客户访问频率,将间隔时间内用户的请求包数上限MaxCount设置为500,两次请求间的最小平均间隔时间MinSpan设置为5秒。

为了模仿机器行为,先通过人工操作对网站进行一个序列访问,考虑到一个网页中可能存在多个信息点(比如HTML、图片、CSS、Flash等),每一个信息点都会导致一个请求—应答对,因此,一次用户访问可能产生多个请求报文。记录下人工操作所涉及的信息点数,在人工操作的请求序列中,包含了5个网页共32个信息点。

用测试工具记录下人工操作阶段产生的HTTP脚本,然后用程序来模仿用户请求,程序每隔一秒钟启动脚本发送请求。攻击程序部署在两台PC上,攻击启动5分钟后,两台攻击主机都得到了请求被终止的反馈。此时查看监视器中的TSPAN表(摘录如表1)和TDefent表(如表2)。

分析表1,两台主机在5分钟内请求的数量远大于MaxCount,平均间隔时间远小于MinSpan,因此被记载为傀儡主机是符合预期的。按照攻击程序的逻辑来计算,攻击主机在5分钟内发出的请求数为5×60×32=9600,实际记载的请求数要稍小,对其原因进行分析,一方面,测试在局域网内部进行,丢包率较低,另一方面,5分钟时间截止前,有少部分请求数据可能还没有到达。实际应用中,由于正常行为与攻击行为在时间特征上的差异极大,因此这些小幅误差不会影响到实际抵御效果。

4.2 应 用

本方案在一个教育培训机构网站上实施,该网站用ASP.NET开发,服务器托管在ISP机房,网站的主要价值在于提供了一个大论坛,借助Web 2.0技术使大量的信息由访问者贡献,并从中衍生出大量实际客户,网站上的部分收费信息也为公司贡献了收益。该网站曾因遭到HTTP泛洪攻击而多次停机。

按照本文方案,结合网站的具体技术环境,在该网站上进行实施。对照方案实施前10天和后1个月的服务器性能数据(如表3),发现方案实施后,服务器的负载更为平稳,各种资源占用峰值以及峰值持续时间都有大幅降低。

5 结 语

本文结合ASP.NET的技术特点,设计了一种主动防御HTTP泛洪攻击的方法。该方法的主要特点是用URL重写的方法,使Web日志记载客户端的CookieId和SessionId,通过定时分析Web日志,根据请求时间特征识别傀儡主机,用自定义HTTP模块对HTTP请求进行预处理,屏蔽傀儡主机的请求。该方法成本低、便于实施,在中小型企业网站上进行了应用检验,实践证明了其有效性。

参考文献

[1]孙长华,刘斌.分布式拒绝服务攻击研究新进展综述[J].电子学报,2009,37(7):1562-1569.

[2]Kandula S,Katabi D,Jacob M,et al.Surviving Organized DDos Attacks That Mimic Flash Crowds[C]//USENIX Symposium on Network Sys-tems Design and Implementation,May,2005.

[3]Gavrilis D,Chatzis I,Dermatas E.Flash crowd detection using decoy hyperlinks[C]//Sensing and Control,2007IEEE International Confer-ence on Networking,April2007:466-470.

[4]Oikonomou G,Mirkovic J.Modeling Human Behavior for Defense A-gainst Flash-Crowd Attacks[C]//Proceedings of IEEE International Conference on Communications,June2009:14-18.

HTTP协议 篇8

关键词：安卓,手机移动客户端,套路,HTTP通信,HttpClient文档

1 应用概述

随着移动网络基础设施的建设, 手机不可否认地逐渐成为重要的信息载体。不仅如此, 随着智能手机在性能和系统功能方面的不断提升和完善, 其在信息平台中的地位逐步赶超桌面系统。对于手机平台, 信息采集能力和互联网连接能力正是其优势及发展趋势之所在, 对于当前主流的手机平台:安卓和IOS, 一方面, 其采集信息的手段方便快捷; 另一方面, 手机的网络连接能力也随着基础设施的建设和升级变得越来越强大。

而实际上, 手机移动客户端的业务框架是在已有业务框架 (B/S) 上的扩展, 其主要扩展了移动设备通过无线网络接入互联网的环节。其常见应用的业务如图1所示。

图1中, 手机移动客户端通过无线网络接入互联网, 进而实现与服务端的通信。文中的手机移动客户端APP以安卓实机 (安卓2.3.6) 为验证环境; 服务端以Tomcat 6为应用程序服务器, 采用J2EE+Spring MVC 3.0框架。其界面如图2所示。

2 关键技术及技巧

作为B/S架构应用的扩展, 手机移动客户端也通过HTTP与服务端进行通信, 按照数据流向可分为: 推送 (POST) 和获取 (GET)。也就是说, 对于手机移动客户端, 需要自行实现桌面浏览器的信息推送和获取功能。

移动客户端所推送或获取的内容主要分为两种: 文本和文件。但无论是文本还是文件, 都必须按照HTTP的规范进行编码, 即HTTP实体。在HTTP客户端通信方面, 安卓平台引入了Apache HttpClient包, 并在其基础上进行了扩展。表1是几种常见的HTTP实体类型, 完整说明请查阅安卓开发平台关于HttpClient的文档。

手机移动客户端通信要做的内容可以归纳为三步: 第一步, 将推送内容或请求参数按照适用的HTTP实体进行编码;第二步, 执行HTTP Client的方法将HTTP实体内容传送给服务端; 第三步, 从服务端返回的实体中获取执行结果。

而服务端要做的内容也可以归纳为三步: 第一步, 从请求实体中获取参数; 第二步, 执行相关操作; 第三步, 将执行结果按HTTP实体编码并回应给客户端。

2.1 信息推送

在HTTP客户端, 对于文本内容, 以URL编码形式实体进行编码; 对于文件内容, 则需以多部分实体进行编码。两者都可采用HttpClient的推送 (POST) 方法。

在服务端, 以Controller的形式提供接口, 用于分解客户端传入的实体内容, 并拼凑成SQL语句, 通过JDBC将数据内容插入 (创建记录主体时是插入) 或更新 (上传文件是更新列) 到后台数据库, 最后根据执行结果 (成功与否) 以字符串实体 (内容采用JSON编码) 的形式回应给客户端。图3是移动客户端向服务端进行信息推送的交互示意图。

2.2 信息获取

在HTTP客户端, 内容请求参数的推送都以URL编码形式实体进行编码; 对于获取内容, 文本内容将按照字符串实体解码, 文件内容将按照多部分实体解码。发送内容请求也采用推送方法。

在服务端, 以Controller的形式提供接口, 用于分解出客户端的实体内容, 调用预编译SQL语句 (语句块标识及参数通过客户端传入) 或拼凑成SQL语句 (对于文件下载), 通过JDBC将数据内容从后台数据库中取出来, 并将结果以字符串实体 (对于结果集) 或多部分实体 (BLOB字段) 的形式回应给客户端。图4是移动客户端从服务端进行信息获取的交互示意图。

2.3 通信设置

通信设置主要包括服务器IP和服务端口, 为了做到方便灵活, 可以考虑使用首选项Activity (PreferenceActivity) 来实现对通信选项的设置。其界面如图5所示。

3 服务端接口设计

3.1 信息推送接口

按照推送内容可分为两种: 文本信息 (“键-值对”) 和文件的上传。

3.1.1 文本推送接口 (model/ins.do)

文本推送接口包含3个参数, 如表2所示。

通过表2可以看出, 通过上述3个参数, 即可拼凑出SQL的插入语句 (INSERT), 以实现往数据表中插入记录。

3.1.2 文件推送 (上传) 接口 (util/upload.do)

文件推送 (上传) 接口包含5个参数, 如表3所示。

通过表3可以看出, 通过上述5个参数, 即可拼凑出SQL的更新语 句 (UPDATE), 以实现往数据 表BLOB列中插入文件内容块。

3.2 信息获取接口

按照获取内容可分为两种: 文本信息 (JSON数组或JSON对象) 和文件的下载。

3.2.1 文本获取接口 (engine/dataset.do)

文本获取接口包含6个参数, 如表4所示。

表4中参数“ds_id”为数据集标识, 其内容是一段带有参数的SQL选择语句 (SELECT), 通过传入的参数来生成完整的SQL语句, 服务端通过执行该SQL语句来获取结果集并以JSON格式返回。

3.2.2 文件获取 (下载) 接口 (util/download.do)

文件获取 (下载) 接口包含4个参数, 如表5所示。

通过表5可以看出, 通过上述4个参数, 即可拼凑出SQL的选择语句 (SELECT), 以从BLOB列中读取文件二进制流内容。

4 功能实现

4.1 文本内容的推送

4.1.1手机移动客户端

手机移动客户端通过HttpClient的推送方法 (Post) 即可实现文本内容的推送, 如代码1所示。

代码1中, 先将参数按URL编码形式实体 (UrlEncodedFormEntity) 进行编码 , 再通过POST方法发送HTTP请求 ,进而读取服务端回应实体内容 (其以JSON格式编码)。

需要注意的是, 移动客户端采用的字符编码为utf-8, 服务端要与其一致 (下同)。

4.1.2 服务端

服务端通过request对象获取客户端传入的参数 (实体内容分解的工作已经由J2EE框架完成), 然后拼凑成插入的SQL语句, 通过JDBC执行该SQL语句, 并以JSON格式回应执行结果 (JSON字符串进行实体的编码也由J2EE框架完成)。代码2是服务端进行文本内容推送的接口定义。

需要注意的是, Tomcat应用程序服务器默认的字符编码不是utf-8, 为了使其与客户端一致, 则需要在对配置文件server.xml中的“Connector”标签添 加属性“URIEncoding” ,并其值为utf-8。

代码2中, 如果推送成功, 服务端返回的内容是 {result:"success"}; 如果推送失败, 返回的内容则是 {result:" <错误消息>"}。

4.2 文件上传

4.2.1 手机移动客户端

相比文件内容的上传, 文件上传的主要差异在于对推送内容的编码: 移动客户端需要使用多部分实体 (MultipartEntity) 将文本内容和文件流进行混合编码。代码3是移动客户端上传文件的关键代码。

代码3中, 先将参数按照多部分实体 (MultipartEntity)进行编码, 再通过POST方法发送HTTP请求, 进而读取服务端回应 (以JSON格式编码)。

4.2.2 服务端

服务端通过request对象获取客户端传入的内容, 根据边界字符串分解出各部分的内容, 并自行建立一个“变量名-变量值”的哈希表; 再根据参数值拼凑成更新BLOB列的SQL语句, 将文件内容块写入到该列中, 即实现文件内容的上传。代码4是服务端上传文件的接口定义。

相比代码2, 代码4中不能直接根据参数名来获取参数值, 而是先需要将参数名和参数值 (包括文件名和文件内容块) 从整个内容块中解析出来, 并建立“键-值”的哈希表,才能通过参数名来获取参数值。文件的上传实际上就是更新BLOB列, 所以其需要提供宿主记录的主键ID名和ID值 (即先插入记录中的文本部分, 再进行BLOB字段的更新)。

值得注意的是, 该文件上传接口中定义了上传内容的大小阈值 (16MB), 如果上传内容超过了该值, 则会造成缓冲溢出, 解析错乱。所以需要客户端也要进行同步的限制。

4.3 文本内容的获取

4.3.1 手机移动客户端

手机移动 客户端也 可以通过HttpClient的推送方 法(“POST”, 也可以使用 “GET”) 来发送数据 请求 , 代码5是手机移动客户端获取文本内容 (记录集) 的关键代码。

不难看出, 代码1与代码5基本相同, 差异之处仅仅在于返回值类型: 前者为JSON对象 (操作结果), 后者为JSON数组 (结果集)。

4.3.2 服务端

服务端通过request对象获取客户端传入的参数, 然后根据预编译的SQL语句块标识来获取SQL语句块, 并使用参数来替换占位符, 最后通过JDBC执行该SQL语句, 并以JSON格式回应结果集。代码6是服务端文本内容 (结果集) 获取接口的定义代码。

从代码6可知, 返回结果集包含多条记录, 每条记录的形式为:{列名1:" <列值1>,列名2:" <列值2>" ,列名3:" <列值3>,……}。在客户端可通过列名来获取记录中该列的值。

4.4 下载文件

4.4.1 手机移动客户端

获取文本与下载文件的差异仅仅在于对服务端回应内容的读取方式: 前者读取内容为文本, 可以逐行读取; 后者读取内容为文件流, 需要逐字节进行读取。代码7是移动客户端下载文件的关键代码。

通过代码5和代码7对比可知, 获取文本与下载文件的请求方式相同, 仅是读取服务端返回内容的方式不同而已,前者是按行读取文本, 后者是逐字节进行读取, 且存储为本地文件。

4.4.2 服务端

服务端通过request对象获取客户端传入的参数, 然后拼凑成读取BLOB列的SQL语句, 将文件内容块从该列的I/O流中读取, 即实现文件内容的下载。代码8是服务端文件下载接口定义代码。

代码8中, 文件的下载就是从BLOB字段中读取文件块内容, 所以其需要提供宿主记录的主键ID名和ID值 (即先读取记录中的文本部分, 再进行BLOB字段的读取)。

另外, 读取的内容将保存为本地文件, 所以需要为该移动客户端APP预选设置好临时文件夹, 而且设计好临时文件的命名规则。

4.5 工程设置

由于在该应用中需使用多部分实体 (MultipartEntity) 的规范 (该定义没有纳入安卓平台), 且涉及网络访问等需求,所以在工程中必须有相应的设置, 具体如下:

(1) 需引入httpmime包 (安卓平台已经包含HttpClient的包)。

(2) 须在工程清单文件中声明互联网访问等使用权限。

5 结语

从手机移动客户端应用的场景和技巧出发, 结合安卓平台的技术特性, 对手机移动客户端在HTTP通信方面的功能实现和相关技巧进行了详细的阐述, 并结合实际案例对关键功能的实现代码进行了分析。

HTTP协议 篇9

会话初始协议 (SIP) 是一个应用层的控制协议, 它可以建立、修改和结束多媒体会话。SIP消息采用文本方式, 具有简单、易扩展的特点。SIP是在IP应用的基础上提出来的, 它起源于超文本传送协议 (HTTP) , 采用请求/响应模型对实体的行为进行规范描述。同时在命名方式上采用统一资源定位符 (Uniform Resource Locators, URL) 方式, 因此可以最大程度地继承现有的HTTP寻址方法[1]。随着应用的多样化, 在不违背RFC3261的前提下, 因特网工程任务组 (IETF) 提出了很多新的消息或消息头字段, 以满足不同需求[2]。

RFC3261提出了分别适用于网络层、传输层和应用层的SIP安全解决方案, 例如IPsec、TLS、S/MIME和SIPS。与此同时, 针对SIP消息安全, 国内外学者做了很多研究。文献[3]提出了基于ECC的SIP认证方案, 在理论上解决了数据安全传输的问题, 但是现有的SIP安全设备并没有涵盖ECC加密算法, 实际实施起来困难重重。文献[4]设计了一种改进的HTTP摘要认证方案, 实现了双向身份认证和密钥协商的功能, 但其在加密算法的安全性上存在较大的问题。首先是摘要算法SHA-1 (安全散列算法) 已有被破译的可能, 其次是加密密钥的长度不够。文献[5]提出了检测任何违反SIP规范的SIP异常或非法消息的框架, 在某种程度上减少了SIP系统所面临的入侵威胁。由于SIP的结构性规则很多, 提取足够充足的检测条件是必然的选择。

本文对现有的SIP安全方案进行了分析与讨论, 针对应用层上SIP消息传送时面临网络侦听的安全问题, 检测SIP非法消息, 结合密文隐写系统和HTTP摘要认证机制, 扩展SIP消息的认证头域, 在文献[5,6,8,9]的基础上, 经过改进得到一种适用于现有设备的基于HTTP的检测-认证方案。

2 方案设计

2.1 SIP检测模块

在认证之前, SIP消息首先通过检测程序, 辨别其是否是“恶意的”。请求和应答都可能含有消息体, 但是SIP代理服务器不检查消息体, 因此消息体中的内容只对用户代理有意义。SIP消息在网络中路由时, 代理服务器需要的所有信息都包含在起始行Start-Line (请求行、状态行) 和SIP标题头中。本模块主要检测SIP消息的起始行和SIP头字段。

基本思想是构建一个通用的检测非法SIP消息的模块, 即该模块能容易地应用于任意SIP消息中。这个通用检测模块的检测规则[1,5,7]如下:

Start-Line中除了SP和结束使用的CRLF外, 不允许使用回车或换行字符;

SIP_METHOD! = NULL;

SIP_VERSION == SIP/2.0;RFC3261规定SIP的版本必须为SIP/2.0。

MESSAGE_HEADER! = NULL且任何SIP消息头符合通用范式;

MESSAGE_HEADER=field-name:field_value* (;parameter-name=parameter-value)

本方案设计一个多线程的消息检测模型来提高效率, 采用Tomita算法[9]在检测过程中的具体操作如图1所示。从输入消息的左端将一个未处理过的终结符移入栈顶, 并等待更多的信息到来之后再做决定;根据上下文无关语法的ABNF (Augmented Backus-Naur Form, 扩展的巴科斯-诺尔范式) 规则, 并使用LR分析法 (最左归约-最右推导) 将该规则左边的符号取代与规则右边相匹配的栈顶符号;对栈中符号和输入符号串进行处理, 若输入串处理完毕, 且栈中只剩下一个符号S, 则分析成功, 结束;若栈中并非只有一个符号S, 或输入串中的符号未处理完毕, 也无法进行任何归约操作, 则分析失败, 结束。

2.2 改进的HTTP摘要认证模块

检测模块初步过滤掉非法SIP消息后, 就进入了认证模块。认证模块包括两个子模块:加密子模块和密文隐写子模块, 如图2所示。

目前SIP终端和软交换设备都不支持PGP和S/MIME加密, 且SHA-1算法和MD5算法都有被破解的报道。本模块考虑到大部分网络部署都支持三重DES算法 (Triple Data Encryption Standard, 3DES) 和RSA (一种以发明者的名字命名的算法, 其发明者是Ron Rivest, Adi Shamir 和Leonard Adleman) 算法, 且至今未见3DES和RSA算法被破译的报道[8], 因此我们建议采用3DES算法作为摘要算法, RSA算法用于保护共享密钥的安全传输。在公钥系统中, 发送方用私钥加密共享密钥, 接收方用发送方的公钥解密。

SIP消息头字段与HTTP摘要认证 (HTTP Digest authentication) [8]中的认证头字段相似, 用户与服务器之间采用改进的HTTP摘要认证方案进行双向认证。改进的HTTP摘要认证方案在以下方面进行了相关扩展:

(1) 对auth-param参数的扩展

auth-param参数用来封装文本编码的stega_message数据包, 其通用格式以BNF语法描述如下:

stega-param=“stega_packet”“=“<”>stega-packet<”>

stega-packet=

此外, 在承载stega_message消息后, 消息类型要将认证类型设置为“stega”。下面是一个封装了stega_message数据包的Proxy-Authenticata头域:

Proxy-Authenticate:stega-realm=“practicerealm.com”,

Stega_packet=“Join few standards let to host on all weapons inside the hardship the sign at Isaiah...to own the same hands...right the planned meet free. ”

(2) 对摘要算法的扩展

对于“algorithm”域来说, 如果该域没有指定摘要算法, 则默认为3DES算法。

algorithm=“algorithm”“=” (“3DES”|“3DES-sess”|token)

则, E (data) =3DES (data)

KD (secret, data) =E (concat (secret, “:”, data) )

即摘要就是对secret与data通过冒号连接在一起的结果进行3DES运算, 而“3DES-sess”则允许其它第三方服务器参与鉴别。E (data) 表示对数据“data”调用3DES算法获取字符串。S-E (secret, data) 表示对数据“data”和“secret”调用stega_algorithm算法和3DES加密算法获取字符串。即

S-E (secret, data)

=stega_algorithm (KD (secret, data) )

=stega_algorithm (E (concat (secret, “:”, data) ) )

3 实验结果

本文作者利用VB.NET对应用的加密算法进行了实现。主要采用以传输控制协议/网际协议 (TCP/IP) 为基础的Socket技术来处理跨网络的数据传输与网络联机, 局域网络上传输的数据都经过3DES加密算法加密之后成为密文。客户端和服务器端加密子模块的测试结果分别如图3、4所示。

测试环境配置了Windows2003系统的服务器、Windows XP系统的PC机。主要测试数据:双向身份认证时, 客户端会在新的请求Proxy-Authorization中向服务器提供认证其身份的response值, 以及服务器确认了对客户端的认证后, 响应Proxy-Authenticate中所包含的用于证明服务器身份的response值。

客户端将response值发送给服务器, 服务器能够顺利解密, 与SIP消息中的Digest algorithm、realm、username和 password进行比对, 确认后认证成功。测试结果证明了客户端与服务器之间实现双向身份认证的能力。下一步要做的是继续完成密文隐写系统的测试。

4 结束语

本文改进了应用于SIP的HTTP摘要认证的应用层安全机制:对接收到的SIP消息进行解析的同时进行一定程度的检测, 筛选掉可能存在的非法SIP消息;对SIP认证头域进行相应扩展, 实现服务器端与客户端的双向身份认证和摘要消息的3DES加密。这一方案具有较高的加密比特强度, 保证了应用层的安全性能;将消息摘要的密文转换为具有自然语言统计特性的文本, 降低了被破译的可能。

摘要：由于现有的认证机制不能有效解决会话初始协议 (SIP) 消息传送时网络侦听的问题, 因此SIP网络传输时存在易遭受异常消息攻击、数据包被侦听、密文被分析等诸多安全威胁。文章经比较分析、研究改进, 应用一个并行多进程的SIP非法消息检测流程, 扩展了SIP认证头域, 引进了密文隐写系统, 能有效保证应用层的安全。实验结果验证了该方案的有效性。

关键词：会话初始协议安全,检测,认证,密文隐写

参考文献

[1]IETF RFC3261-2002, SIP:Session Initiation Protocol[S].

[2]陆立, 张鹏生, 张华, 等.NGN协议原理与应用[M].北京:机械工业出版社, 2004.1-186.

[3]李士达, 胡?, 王兴秋, 等.一种基于ECC的SIP认证方案的提出与实现[J].计算机应用, 2007, 27 (2) :311-313.

[4]王宇飞.一种基于HTTP摘要认证的SIP安全通信系统的实现[D].成都:电子科技大学, 2005.10-60.

[5]Dimitris Geneiatakis, Georgios Kambourakis, TasosDagiuklas, et al.A Framework for Detecting Mal-formed Messages in SIP Networks[J].IEEE, LAN-MAN, 2005, (9) :1-5.

[6]张岩.SIP协议及其安全机制的研究与实现[D].南京:东南大学, 2006.78-79.

[7]夏智娟.SIP协议的研究与实现[D].南京:南京理工大学, 2005.18-27.

[8]代秀娇.数据密码编码技术在网络通信中的研究及其应用[D].广州:中山大学, 2005.32-51.