首页> 中国专利> 一种基于关键字的HTTP报文缓存机制的实现方法

一种基于关键字的HTTP报文缓存机制的实现方法

摘要

一种基于关键字的HTTP报文缓存机制的实现方法,客户的HTTP请求报文,需要先匹配对应的配置项;需要根据配置项中的关键字搜索客户请求报文,并确定是从缓存中给给用户HTTP响应,还是从服务器获取完整HTTP响应,还是从服务器获取部分HTTP响应,并根据配置修改缓存报文,合成完整的HTTP响应。本发明有效减少代理服务器与WEB服务器之间的数据流量;有效缩短客户端获取WEB页面的等待延时的时间;可以确保客户端每次请求到的WEB页面均为最新的页面;与客户端用户状态,浏览器类型有关的WEB页面,也能达到减少数据流,缩短延时的效果;同时,可以根据配置文件来优化WEB页面的缓存。

著录项

  • 公开/公告号CN102075570A

    专利类型发明专利

  • 公开/公告日2011-05-25

    原文格式PDF

  • 申请/专利权人 南京中兴特种软件有限责任公司;

    申请/专利号CN201010616315.0

  • 发明设计人 张炎;朱鹏飞;

    申请日2010-12-31

  • 分类号H04L29/08(20060101);G06F17/30(20060101);

  • 代理机构32218 南京天华专利代理有限责任公司;

  • 代理人夏平

  • 地址 210012 江苏省南京市雨花台区紫荆花路68号

  • 入库时间 2023-12-18 02:26:11

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2019-12-03

    专利权人的姓名或者名称、地址的变更 IPC(主分类):H04L29/08 变更前: 变更后: 申请日:20101231

    专利权人的姓名或者名称、地址的变更

  • 2016-03-30

    专利权人的姓名或者名称、地址的变更 IPC(主分类):H04L29/08 变更前: 变更后: 申请日:20101231

    专利权人的姓名或者名称、地址的变更

  • 2015-01-07

    专利实施许可合同备案的生效 IPC(主分类):H04L29/08 合同备案号:2014320000711 让与人:南京中新赛克科技有限责任公司 受让人:何洪宁 发明名称:一种基于关键字的HTTP报文缓存机制的实现方法 申请公布日:20110525 授权公告日:20130130 许可种类:普通许可 备案日期:20141031 申请日:20101231

    专利实施许可合同备案的生效、变更及注销

  • 2013-04-24

    专利权人的姓名或者名称、地址的变更 IPC(主分类):H04L29/08 变更前: 变更后: 申请日:20101231

    专利权人的姓名或者名称、地址的变更

  • 2013-01-30

    授权

    授权

  • 2011-07-06

    实质审查的生效 IPC(主分类):H04L29/08 申请日:20101231

    实质审查的生效

  • 2011-05-25

    公开

    公开

查看全部

说明书

技术领域

本发明属于一种HTTP网络代理缓存方法,尤其是用于反向代理,WEB服务器多网加速等场景的方法,具体地说是一种基于关键字的HTTP报文缓存机制的实现方法。

背景技术

代理服务器是介于浏览器和Web服务器之间的一台服务器,有了它之后,浏览器不是直接到Web服务器去取回网页而是向代理服务器发出请求,Request信号会先送到代理服务器,由代理服务器来取回浏览器所需要的信息并传送给你的浏览器。

HTTP代理,其功能就是代理网络用户去取得网络信息;现在也用于WEB类网站加速。常见的HTTP代理分为无缓存机制的,与有缓存机制的。

无缓存机制的HTTP代理:代理服务器不检测用户请求的内容,自己从服务器请求相关内容,返回给用户;它存在如下问题:无缓存机制的HTTP代理流量大、网络延时大;所有数据均需要从客户端,代理服务器,WEB服务器进行传输,网络流量无缩小,每一步网络传输都有网络延时,它包括:

请求:客户端浏览器->代理服务器->WEB服务器

响应:WEB服务器->代理服务器->客户端浏览器

每一步骤流程都存在完整的数据流量产生;每一步骤流程都对应产生网络延时的生成。

有缓存机制的HTTP代理:代理服务器有一个很大的Cache,它有很大的存储空间,它不断将新取得数据储存到它本机的存储器上,如果浏览器所请求的数据在它本机的存储器上已经存在而且是最新的,那么它就不重新从Web服务器取数据,而直接将存储器上的数据传送给用户的浏览器,这样就能显著提高浏览速度和效率。但是,它存在如下问题:

1、客户端有可能获取到的不是最新的页面。

例如:代理服务器在缓存更新周期内,WEB服务器更新了WEB页面。客户端这时候请求到的页面为未更新前的老页面。

2、不能缓存相同URL,但是与用户状态有关的页面。

例如:某WEB页面需要用户登陆后,页面上固定位置显示的用户名不同,这种页面是无法进行缓存的。

3、不能缓存相同URL,与浏览器类型有关的页面。

例如:某WEB页面使用动态语句,IE和Firefox浏览器使用的脚本不同,这种页面是无法进行缓存的。

发明内容

本发明的目的是针对现有上述问题,提出的一种基于关键字的HTTP报文缓存机制的实现方法。

本发明的技术方案是:

一种基于关键字的HTTP报文缓存机制的实现方法,包括以下步骤:

(a)、用户建立配置文件,该配置文件包括多个配置项;各配置项均包括需要处理的域名、页面、Cookie和用户浏览器类型,对应于各配置项设有相应的处理方式;各配置项中的域名、页面、Cookie和用户浏览器类型均设有多个关键字;

      (b)、建立报文处理所需要的缓冲内存,启动处理线程,绑定报文处理端口;

      (c)、读取配置文件,在内存中将配置文件中的每个配置项串成配置链表;

      (d)、当客户访问代理服务器时,代理服务器与客户建立连接,获取用户的请求报文;

      (e)、根据客户的请求报文,检索配置链表中的关键字,确定所属配置项,根据配置项中的方法进行处理;

      (f)、如果步骤(e)中的处理方式,需要从服务器获取全部,或者部分报文,则与服务器建立连接,从服务器获取相应的报文;否则,直接从缓冲内存中获取相应的报文;

      (g)、将步骤(f)处理过的HTTP响应报文发送给客户端用户。

本发明中:客户的HTTP请求报文,需要先匹配对应的配置项;需要根据配置项中的关键字搜索客户请求报文,并确定是从缓存中给给用户HTTP响应,还是从服务器获取完整HTTP响应,还是从服务器获取部分HTTP响应,并根据配置修改缓存报文,合成完整的HTTP响应。

本发明的有益效果:

本发明可根据配置文件,使得与客户端一切状态无关的静态页面进行缓存处理。

本发明可根据配置文件,使得页面更新与否仅仅根据HTTP头检测,不必要下载这个页面进行比较。

本发明可根据配置文件,解决与客户端状态,浏览器类型有关页面缓存的问题。

本发明有效减少代理服务器与WEB服务器之间的数据流量;有效缩短客户端获取WEB页面的等待延时的时间;可以确保客户端每次请求到的WEB页面均为最新的页面;与客户端用户状态,浏览器类型有关的WEB页面,也能达到减少数据流,缩短延时的效果;同时,可以根据配置文件来优化WEB页面的缓存。

 

具体实施方式

下面结合实施例对本发明作进一步的说明。

一种基于关键字的HTTP报文缓存机制的实现方法,它包括以下步骤:

(a)、用户建立配置文件,该配置文件包括多个配置项;各配置项均包括需要处理的域名、页面、Cookie和用户浏览器类型,对应于各配置项设有相应的处理方式;各配置项中的域名、页面、Cookie和用户浏览器类型均设有多个关键字;

      (b)、建立报文处理所需要的缓冲内存,启动处理线程,绑定报文处理端口;

      (c)、读取配置文件,在内存中将配置文件中的每个配置项串成配置链表;

      (d)、当客户访问代理服务器时,代理服务器与客户建立连接,获取用户的请求报文;

      (e)、根据客户的请求报文,检索配置链表中的关键字,确定所属配置项,根据配置项中的方法进行处理;

      (f)、如果步骤(e)中的处理方式,需要从服务器获取全部,或者部分报文,则与服务器建立连接,从服务器获取相应的报文;否则,直接从缓冲内存中获取相应的报文;

      (g)、将步骤(f)处理过的HTTP响应报文发送给客户端用户。

本发明中:客户的HTTP请求报文,需要先匹配对应的配置项;需要根据配置项中的关键字搜索客户请求报文,并确定是从缓存中给给用户HTTP响应,还是从服务器获取完整HTTP响应,还是从服务器获取部分HTTP响应,并根据配置修改缓存报文,合成完整的HTTP响应。

具体实施时:

一种基于关键字的HTTP报文缓存机制的实现方法,一、需要从配置文件读取配置形成搜索索引链表;二、需要和客户端建立连接,并从客户端获取HTTP请求报文;三、需要根据关键字来判断每个HTTP请求使用哪种处理方式是最优秀的方式;四、根据上一步选择的处理方式形成完整的响应报文;五、将响应报文送给客户端。

1、所有WEB页面分等级处理:

a、静态页面不经常改变的WEB页面。

b、静态页面区分客户端类型的WEB页面。

c、具有缓存价值的动态WEB页面。

d、无缓存价值的动态WEB页面。

说明:上述a的意思是,WEB页面的报文内容仅仅与URL有关,与其他一切状态无关。

上述b的意思是,WEB页面的报文内容不仅仅与URL有关,还与请求内的HTTP头其他字段有关系。

上述c的意思是,某些动态页面,值得缓存并处理,比如不同用户登陆后的google主页,仅仅有右上角的用户名不同,其余报文均一样。

上述d的意思是,某些动态页面,差异非常大,不值得进行缓存,比如不同用户的WEB邮箱,整个页面除了框架外均不相同,缓存代价大,效果不好。

2、配置文件项,如下:

<[206]>

DomainID=21

http_hdr_up={[GET /loginfaild.srf]}&{[Host: login.live.com]}|{[HOST: login.live.com]}

http_hdr_dwn=

CheckAck=0

ChangeUp=0

ChangeDown=1

pktclient=cms_pkt//202.up.cmspkt

pktserver=cms_pkt//206.cmspkt

SSL=1

srch_dwn_val={[Set-Cookie: MSPOK=]}#{[;]}*{[64]}@{[246]}

srch_dwn_val={[https://login.live.com/ppsecure/post.srf?bk=]}#{["]}*{[10]}@{[4102]}

srch_dwn_val={[input type="hidden" name="PPFT"]}&{[value="]}#{[/>]}*{[256]}@{[8595]}

srch_dwn_val={[base href="]}&{[login.live.com/pp]}#{["]}*{[6]}@{[765]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[1561]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[1899]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[3129]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[3816]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[4947]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[5499]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[6310]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[8023]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[9094]}

srch_dwn_val={[.css?x=]}#{["]}*{[12]}@{[9358]}

pktwarn=cms_pkt//202_warn.cmspkt

说明:

a.<[206]> 表示的是配置序列号,每个配置项均有一个编号,不重复。

b.DomainID表示改配置项表示的是何域名下的。

c.http_hdr_up表示检测用户请求报文中项目,用户检索URL,用户浏览器类型,Cookie,等字段

d.http_hdr_down表示检测WEB服务器下行报文是否含有某些特定字段。

e.CheckAck 表示是否需要检测服务器响应报文是否满足条件,满足则从缓存中修改给予用户,节省网络资源与时间,不满足则从WEB服务器获取报文传送给用户,保证报文正确性。

f.ChangeUp 表示是否需要对用户请求进行修改,比如报文正文一样,仅仅不同用户的Cookie不同,那么修改用户的GET请求为HEAD请求,只需要从服务器获取报文头就可以,不需要再获取报文体内容。

g.ChangeDown 表示修改服务器响应,如f里面的例子,缓存里面已经有下行报文体了,将WEB服务器的报文HTTP头修改进报文体前,再返回给客户端,就是完整的一个下行报文了。

h.pktclient 表示上行修改报文,代理服务器缓存客户端上行报文文件路径。

i.pktserver 表示下行修改报文,代理服务器缓存WEB服务器下行报文文件路径。

j.SSL 表示满足改项http_hdr_up与http_hdr_dwon配置项的报文是否为HTTPS加密报文内容。

k.srch_dwn_val 表示对下行报文进行修改的具体操作方式,内容检索标识:{[修改字符串前字符]}#{[修改字符串后字符]}*{[最大长度]}@{[指针偏移量]},可

l.srch_up_val 表示对上行报文进行修改的具体方式,内容检索标识:{[修改字符串前字符]}#{[修改字符串后字符]}*{[最大长度]}@{[指针偏移量]}

j.pktwarn 表示如果匹配到http_hdr_up与http_hdr_down的情况下,srch_dwn_val 或者srch_up_val 发生错误,产生告警行为。

3.配置文件

配置文件是由多个配置项组成的配置文本文件

4.处理流程

4.1主线程。

a)       初始化系统,包括内存初始化,全局变量初始化,Socket通信初始化。

b)      Bind通信端口。

c)       读取配置文件,初始化配置链表。

d)      启动客户端Accept线程。

e)       启动Connect和Send线程。

f)        启动select处理线程。

g)       启动报文处理线程。

h)       进入命令行等待状态。

4.2Accept线程

      a.线程初始化。

      b.非阻塞调用Accept函数

      c.调用成功后将Socket句柄放入等待Select数组中

      d.循环调用b。

4.3Connect和Send线程

      a.线程初始化。

      b.从待发送,连接队列获取数据。

      c.如果待连接,设置connect超时,连接WEB服务器,Socket句柄送入等待Select数组中。

      d.如果待发送,调用send发送给WEB服务器。

      e.循环调用b

4.4Select处理线程。

      a.线程初始化。

      b.清空FD

      c.遍历待Select数组,FD SET。

      d.调用Select出待处理的Socket。

      e.放入待处理Socket队列。

      f.循环b。

4.5报文处理线程。

      a.线程初始化。

      b.从待处理Socket队列读取出待处理的Socket。

      c.Read待处理Socket

      d.如果关闭则关闭Socket。

e.在d满足的情况下,查找改Sokcet对应的WEB服务器,或者客户端的Socket,并关闭。

      f.将读取出的报文进行配置文件检测。

      g.将检测结果放入Send队列。

      h.循环b

4.6报文配置检测处理模块

      a.检测报文头中HOST字段

      b.找到对应Domainid的配置链表。

      c.如果客户端数据根据http_hdr_up 检测报文URL,Host,Cookie,User-Agent,Content-type等字段。

      d.如果WEB服务器数据且CheckAck=1需要检测报文。

      e.满足条件d的情况下,根据http_hdr_down检测报文响应值,Location,Set-Cookie等字段。

      f.如果客户端数据且ChangeUp=1的情况下需要对报文进行修改。

      g.如果WEB服务器数据且ChangeDown =1的情况下需要对报文进行修改。

      h.如果客户端数据pktclient不为空,则从内存中找到对应的缓存报文。不需要修改报文的情况下直接返回。

      i.如果WEB服务器数据pktserver 不为空,则从内存中找到对应的缓存报文。不需要修改报文的情况下直接返回。

      j.如果客户端数据srch_up_val 不为空,则根据配置中规定的方式修改内存中缓存的报文,所有srch_up_val修改完成后返回。

      k.如果WEB服务器数据srch_dwn_val不为空,则根据配置中规定的方式修改内存中缓存的报文,所有srch_dwn_val修改完成后返回。

l.在上述j,k过程中如果遇到修改报文不符合,或者错误的情况发生时候,根据pktwarn 产生告警。

本发明未涉及部分均与现有技术相同或可采用现有技术加以实现。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号