本申请涉及互联网技术领域,尤其涉及一种网站访问加速方法及装置。
背景技术:
在互联网时代,如何提升网站访问速率是改进用户上网体验的首要问题。从用户发出访问请求到网站将内容资源返回给用户,这一过程受到多方面因素的影响,其中既包括用户侧和网站侧自身的因素,也包括两侧之间通信环节的因素,针对这些不同方面,也产生了各式各样的网站访问加速技术。
不同逻辑网络之间的互连瓶颈,是影响网络连接速率的重要因素,以国内网络环境为例,存在电信、联通、铁通、教育网等多个逻辑网络,受到客观条件的影响,在这些网络内部的通信都很流畅,但一旦涉及到网络之间的互连,就会出现延迟过高、丢包甚至无法连接等各种情况。针对该问题,现有的技术的解决方案是搭建具有多线带宽的代理服务器,参见图1所示,用户设备和网站服务器位于不同的逻辑网络A和B,如果用户直接访问网站,速率会受到A和B网络互连瓶颈的影响。搭建代理服务器后,用户设备与网站服务器之间的交互可以通过代理服务器进行转发,由于代理服务器同时具有网络A和网络B的双线带宽,因此能够对用户访问网站的过程起到加速效果。
上述方案问题在于通用性较差,仅针对用户设备和网站服务器存在网络互连瓶颈的场景具有加速效果,对于连接瓶颈并不在于网络互连的情况则并不能起到加速作用,甚至可能导致额外的转发延迟,代理服务器的硬件资源也没有得到充分的利用。
技术实现要素:
针对上述技术问题,本申请提供一种网站访问加速方法及装置,技术方案如下:
根据本申请的第一方面,提供一种网站访问加速方法,应用于代理服务器,所述代理服务器分别与用户设备及网站服务器通信连接,所述方法包括:
获得用户设备发出的针对目标网站资源的访问请求;
确认所述用户设备与所述代理服务器之间已建立Socket连接;
根据所述访问请求,获取所述目标网站资源;
利用所述Socket连接,将所获取的目标网站资源反馈至所述用户设备,以响应所述访问请求。
根据本申请的第二方面,提供一种网站访问加速装置,应用于代理服务器,所述代理服务器分别与用户设备及网站服务器通信连接,所述装置包括:
访问请求获得模块,用于获得用户设备发出的针对目标网站资源的访问请求;
连接确认模块,用于确认所述用户设备与所述代理服务器之间已建立Socket连接;
资源获取模块,用于根据所述访问请求,获取所述目标网站资源;
访问请求响应模块,用于利用所述Socket连接,将所获取的目标网站资源反馈至所述用户设备,以响应所述访问请求。
本申请提所提供的网站访问加速方案,通过在代理服务器和用户设备之间建立Socket连接的方式,可以实现建立一次连接后多次传输资源,避免每次传输资源都需要建立HTTP连接而导致的连接延迟。在上述方案的基础上,本申请还进一步提供在代理服务器中预存网站资源、预存网站域名解析结果、对网站资源进行压缩传输等改进方案以提升加速效果。与现有技术相比,本申请方案能够在更多的应用场景下获得更为明显的加速效果,也使得代理服务器能够被更高效地应用于网站访问加速。
应当理解的是,实施本申请方案的任一产品或方法并不一定需要同时具有以上所述的所有优点。以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1是现有技术的网站访问加速原理示意图;
图2是本申请的网站访问加速的系统架构示意图;
图3是本申请的网站访问加速方法的第一种流程示意图;
图4是本申请的网站访问加速方法的第二种流程示意图;
图5是本申请的网站访问加速方法的第三种流程示意图;
图6是本申请的网站访问加速装置的第一种结构示意图;
图7是本申请的网站访问加速装置的第二种结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于本申请保护的范围。
现有的代理服务器加速技术,是从改善网络连接带宽或连接质量的角度来实现上网加速效果,如果上网速率瓶颈并不在于网络连接,例如:用户设备和网站服务器位于相同的逻辑网络、或者处于连接比较顺畅的不同逻辑网络、或者用户设备及网站加速器自身接入网络的速率受限,在这些情况下,现有技术 均无法有效起到加速效果。
针对现有技术存在的问题,本申请从改善通信效率的角度来实现上网加速效果。通过研究发现,从用户发出访问请求到网站将内容资源返回给用户,这一过程的延时开销主要体现在以下几个方面:
1)用户设备与网站服务器需要多次建立HTTP连接,以获取不同的HTTP资源;
2)用户侧基于域名访问网站时,域名解析所带来的延迟;
3)网站资源的下行传输;
本申请则针对以上几个方面给出相应的上网加速方案,对应的系统架构如图2所示:
网站服务器30是资源的拥有方;
用户设备10是资源的需求方,利用网站域名向网站服务器30发起资源访问请求;
代理服务器20在逻辑上位于用户设备10和网站服务器30之间,代理服务器20与用户设备10、代理服务器20与网站服务器30之间可通过各种形式的网络实现通信连接,并且代理服务器20可以分别与多台不同的用户设备及多个不同的网站服务器进行通信。
根据本申请方案,代理服务器20可以截获任一用户设备10向任一网站服务器30发起的资源访问请求,并基于该请求对后续的访问过程进行加速。
当网络通信采用TCP协议时,通信双方的连接方式可分为长连接和短连接两种。所谓长连接是指在一个TCP连接上可以连续发送多个数据包,在TCP连接保持期间,如果没有数据包发送,需要双方发检测包以维持此连接。短连接则是指通信双方有数据交互时,就建立一个TCP连接,数据发送完成后,则断开此TCP连接。
HTTP协议是TCP协议的一种典型应用,也是互联网的上应用最为广泛的一种协议,很多网站在向用户提供服务时都使用HTTP连接。HTTP连接属于短连接,用户设备发送的每次请求都需要服务器回送响应,在请求结束后,会主 动释放连接。这样做的目的是为了避免大量用户访问网站而导致的大量并发连接,从而降低网站服务器资源消耗。但是从另一个方面看,由于网站页面上各种资源,例如图片、音频、视频等都是以HTTP链接的形式提供,因此用户设备每次请求获取一个资源,就需要与网站服务器建立一次HTTP连接,服务器则需要等到连接建立成功后才能将资源反馈给用户设备,这种频繁建立HTTP连接的方式必然会增加用户设备与网站服务器之间的交互延迟。
从第三方加速的角度,无法去改变网站自身的连接策略,但是在代理服务器加速机制下,用户设备实际上是与代理服务器建立连接,并且从代理服务器获取资源,因此可以通过改变用户设备与代理服务器之间的连接方式来降低连接开销。
图3所示,为本申请提供的网站访问加速方法的流程图,该方法基于代理服务器,可以包括以下步骤:
S101,获得用户设备发出的针对目标网站资源的访问请求;
S102,确认所述用户设备与所述代理服务器之间已建立Socket连接;
S103,根据所述访问请求,获取所述目标网站资源;
S104,利用Socket连接,将所获取的目标网站资源反馈至所述用户设备。
与现有的代理加速方案相比,本申请将用户设备与代理服务器之间默认的HTTP连接方式替换为Socket连接方式,与HTTP连接相比,Socket连接属于长连接,也就是说,除非双方主动要求,否则在连接建立之后不会自动断开。利用这个特性,代理服务器可以将原本需要使用多次HTTP连接进行传输的内容,通过一次Socket连接完成,从而避免频繁建立HTTP连接而导致的额外时延。
本申请方案的应用前提是:代理服务器需要能够截获用户设备向网站服务器发起的资源访问请求,在实际应用层面,很多产品都具备这样的条件,例如浏览器、搜索引擎、网站导航、公众平台、综合业务服务窗等,作为综合性的网络服务提供方,这些应用产品一方面能够为用户提供方便的网站访问入口,另一方面能够为网站带来更多的用户,在此基础上,如果能够进一步提供网站 访问加速功能,对于用户和网站双方都具有很大意义。当然,本申请并不需要对应用层面的具体实现方式进行限定。
根据S101,代理服务器可以作为应用的承载设备,直接获得用户设备向网站服务器发起的资源访问请求,也可以获得其他应用服务器转发来的用户访问请求。
根据S102,代理服务器需要确认用户设备已经与自身建立起了Socket连接,这里可能存在两种情况:
一种情况是Socket连接当前已经建立完成,例如,当代理服务器本身作为应用承载设备时,即使没有访问网站的需求,也可能为了实现其他功能而预先建立了用户设备与代理服务器之间的Socket连接,这种情况下,可以维持已建立的Socket连接并进一步利用该连接实现后续的网站访问加速功能;
另一种情况是当前尚未建立用户设备与代理服务器之间的Socket连接,这种情况下,代理服务器下需要执行Socket连接的建立操作。
建立Socket连接的具体方式可参见现有技术的说明,在本申请中不再详细介绍。
根据S103,代理服务器根据用户侧的访问请求,获取相应的目标网站资源;本申请提供两种代理服务器获取目标网站资源的方式:
1)代理服务器本地获取。
参见图4所示,代理服务器可以预先从其他网站获取资源缓存到本地,并且按照特定的方式进行标识。根据S103a,获得用户侧的资源访问请求后,根据所需访问的内容,从本地的缓存取出相应的资源反馈至用户侧。由于不需要代理服务器实时与网站侧进行交互,这种方式可以显著降低对用户侧的响应时间。
在实际应用中,对于公众平台、综合业务服务窗等提供网站入口相对固定的产品,可以直接预先对这些固定入口所对应的网站资源进行预存,而对于浏览器等产品,也可以根据用户的自定义配置或者用户的使用习惯等信息选取若干网站并对其资源进行预存。
另外,为了保证代理服务器本地预存资源的时效性,可以按照一定的策略, 对存储在代理服务器本地的网站资源进行更新。例如周期性进行更新,或者主动对网站侧进行监测、发现网站资源内容发生变化后进行更新,如果和网站方具有较为密切的合作关系,也可以根据网站侧发送的提醒来进行更新。当然,本申请并不需要对具体的更新机制进行限定。
2)实时从网站服务器获取。
参见图5的S103b所示,代理服务器在获得用户侧针对目标网站的访问请求后,实时与目标网站服务器建立连接,并从目标网站服务器获取资源;
与方式1)相比,这种资源获取方式需要更长的时间来响应用户侧的请求,但是能够更好地保证资源的时效性。而且,对于一些实时交互需求,例如验证、授权等,也必须采用实时获取资源的方式。
在本申请所提供的一种具体实施方式中,可以采用在代理服务器预存域名解析结果的方式,以进一步降低代理服务器与网站服务器实时交互所带来的时间开销。
根据一般用户的使用习惯,都是使用网站域名来对网站资源进行访问,即便是第三方应用为用户提供的网站快捷访问入口,其后台所对应的URL也多是基于网站域名所保存的信息。因此,在代理服务器根据用户的请求与目标网站服务器建立连接的过程中,将网站域名解析为IP地址的操作将会占用一定的时间。针对该问题,本申请提供的解决方案是:预先将网站的域名解析结果(即网站IP地址)存储在代理服务器本地,当代理服务器需要与网站服务器建立连接时,直接利用网站的IP地址与网站服务器建立连接,从而避免域名解析所带来的交互时延。
实际应用中,代理服务器可以从专用的域名解析服务器中获取网站的域名解析结果,也可以在代理服务器本地实现域名解析操作。在入口应用中,可以直接将为用户提供的网站快捷访问入口所对应的URL保存为IP地址的形式。
与预存网站资源类似的是,代理服务器可以根据实际应用需求选择性地保存一些网站URL对应的IP地址。同时为了保证域名解析结果的正确,也可以按照一定的策略,对存储在代理服务器本地的域名解析结果进行更新。
以上提供了两种代理服务器获取目标网站资源的方式,其中方式1)更适合于例如图片、音视频文件等相对静态资源的获取,方式2)则更适合例如验证、授权等需要动态交互的场景。在实际应用中,两种方式往往可以结合使用,即:针对一次用户的访问请求,可以按照实际需求,对一部分资源采用代理服务器本地获取的方式、对另一部分资源采用实时从网站服务器获取的方式。事实上,在数据传输过程中,图片、音视频文件等资源需要占用大部分的传输带宽,因此,这种相结合的资源获取方式,尽管无法完全避免代理服务器与网站服务器交互所带来的延时,仍然可以有效降低代理服务器与网站服务器之间的传输数据量,从而提高代理服务器对用户侧的响应速率。
在S104,代理服务器利用已建立的Socket连接,将所获取的目标网站资源反馈至用户设备,以响应用户侧的访问请求。
在本申请的一种优选实施方式中,对于从网站服务器获取到的资源,代理服务器可以对其进行压缩处理后再提供给用户侧。实际应用中,对于很多网站所提供的资源,可以在不影响用户实际使用的前提下做压缩处理以降低代理服务器与用户设备之间的数据传输量,从而进一步降低传输时延。这种方式对于接入带宽受限的用户设备(例如利用无线移动方式上网的手机)具有较大意义,而且还可以降低用户设备的数据流量。压缩处理操作可以针对代理服务器本地预存的资源预先完成,如果压缩处理操作所带来的收益大于所消耗的时间,也可以在向用户设备反馈之前完成。本申请对具体的压缩对象、压缩算法并不需要进行限定,本领域技术人员可以根据实际需求灵活选取。
可见,本申请提所提供的网站访问加速方案,通过建立Socket连接、在代理服务器中预存网站资源、预存网站域名解析结果、对网站资源进行压缩传输等多个环节来提升用户访问网站的速度。与现有的加速方案相比,本申请中的代理服务器并不只是简单起到资源转发和网络互连的作用,因此能够在更多的应用场景下获得更为明显的加速效果。当然,本申请的加速方案与现有的加速方案本身也并不存在冲突,本领域技术人员可以根据实际需求将本申请方案与现有技术方案进行结合。
相应于上述方法实施例,本申请还提供一种网站访问加速装置,参见图6所示,该装置可以包括:
访问请求获得模块110,用于获得用户设备发出的针对目标网站资源的访问请求;
连接确认模块120,用于确认用户设备与代理服务器之间已建立Socket连接;
资源获取模块130,用于根据访问请求,获取目标网站资源;
访问请求响应模块140,用于利用所述Socket连接,将所获取的目标网站资源反馈至用户设备,以响应访问请求。
参见图7所示,在本申请的一种具体实施方式中,上述网站访问加速装置还可以包括资源管理模块150,用于预先从网站服务器获取网站资源并存储在代理服务器本地;相应地,资源获取模块130具体用于根据访问请求,获取预先存储在代理服务器本地的目标网站资源。
此外,资源管理模块150还可以用于对存储在代理服务器本地的网站资源进行更新。
在本申请的一种具体实施方式中,资源获取模块130可以具体用于根据访问请求,与目标网站的服务器建立连接,从目标网站的服务器获取目标网站资源。
参见图7所示,上述网站访问加速装置还可以进一步包括域名解析管理模块160,用于预先获得网站的域名解析结果并存储在代理服务器本地;相应地资源获取模块130具体用于根据预先存储在代理服务器本地的域名解析结果,与目标网站的服务器建立连接。
此外,域名解析管理模块,还可以用于对存储在代理服务器本地的域名解析结果进行更新。
在本申请的一种具体实施方式中,访问请求响应模块140可以具体用于将经过压缩处理的目标网站资源反馈至用户设备。
可以理解的是,资源管理模块150与域名解析管理模块160作为两种功能独立的模块,既可以如图7所示同时配置在装置中,也可以分别单独配置在装置中,因此图7所示的结构不应理解为对本申请方案的限定。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本申请的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。