WO2017107568A1 - 一种基于云-端协同的移动浏览器资源加载优化方法 - Google Patents
一种基于云-端协同的移动浏览器资源加载优化方法 Download PDFInfo
- Publication number
- WO2017107568A1 WO2017107568A1 PCT/CN2016/098289 CN2016098289W WO2017107568A1 WO 2017107568 A1 WO2017107568 A1 WO 2017107568A1 CN 2016098289 W CN2016098289 W CN 2016098289W WO 2017107568 A1 WO2017107568 A1 WO 2017107568A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- resource
- url
- proxy server
- server
- cloud
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
Definitions
- the invention is a mobile browser resource loading optimization method based on cloud-end collaboration, and belongs to the technical field of software.
- the caching mechanism In order to speed up the loading of web resources, the caching mechanism is widely used. Through the caching method, the amount of resource downloads can be reduced for the user, thereby improving the performance of the web browsing.
- This caching mechanism brings greater benefits to mobile devices because on mobile devices, this mechanism not only reduces page load time, but also reduces network traffic and power consumption.
- the cache is often not well configured and implemented. Studies have shown that there is a big gap between the theoretical performance and the actual performance of the caching mechanism. Therefore, there is a need to optimize the existing caching mechanism and improve the cache without changing the existing browser and server implementation. Utilization effect. It is hoped that this can further improve the experience of mobile device users when browsing the web, and reduce the user's traffic and power consumption.
- an object of the present invention is to provide a mobile browser resource loading optimization method based on cloud-end collaboration.
- the invention minimizes the transmission traffic of the web resource and improves the loading speed without changing the existing user browsing habits and the original configuration of the web application cache.
- the core idea is: based on the original Web application architecture, build a proxy server on the mobile phone side, and prefetch the Web resources with the cloud server, and change the original two-layer architecture from browser to server to a four-tier architecture.
- the system builds an HTTP proxy server on the mobile phone side, and configures the HTTP proxy of the mobile browser to the mobile proxy server; and builds a cloud server for each mobile phone user on the personal cloud.
- the mobile proxy server receives the request from the mobile browser and returns a resource response to the mobile browser.
- the mobile terminal server does not directly request resources from the Internet, but requests resources from the cloud server built on the personal cloud, and the cloud server downloads resources from the Internet and selectively pushes to the mobile terminal.
- the URL matching algorithm, resource check code comparison, data compression and website prefetching are used to minimize the transmission traffic and increase the loading speed.
- a cloud-side collaborative mobile browser cache optimization method the specific steps are:
- the proxy server can receive the request of the browser and parse the request. For the resource cached by the proxy server, or calculate the corresponding resource through the URL matching algorithm, the proxy can directly return the resource to the browse. For the resources that are not stored locally, the resources are queried to the cloud server.
- the cloud server can prefetch the resources of the website and receive resource requests from the mobile proxy server. If the resource has been cached on the cloud server, the cloud server directly returns the resource to the mobile proxy server. If not, the request is made to the target website and the result is returned.
- the user configures the browser's proxy as the proxy server on the mobile terminal on the mobile terminal.
- each resource calculates the check value of the file on the cloud server side as the only basis for identifying the content of the resource, and the cache resource can be retrieved according to the value.
- the server sends the resource back to the mobile terminal, it will first retrieve whether the file with the check value already exists in the cache of the mobile terminal. If it already exists, only the check value of the resource is returned, and the mobile terminal proxy server will The check value extracts the resource.
- the cloud server periodically prefetches websites that the user may access, and establishes a cache of the website in advance for the user to access.
- server-to-mobile transmissions are compressed to save transmission traffic from uncompressed resources.
- resource access mainly consists of three steps:
- the cloud server periodically prefetches resources that users may access.
- the mobile terminal proxy server receives the browser request, and if the mobile phone end does not have the cache resource, requests the resource from the cloud server; if the cache exists or can find the corresponding resource according to the URL matching algorithm, Return resources directly to the browser.
- Pre-fetching target resources The server will prefetch resources that users may access in advance.
- the specific resource list will be generated according to the user's access habits.
- the server will store the prefetched resources, calculate the checksums, and organize the entries into the database.
- the proxy server receives the browser request and checks the mobile phone side cache: the present invention can be used simultaneously with the browser's original cache, and the browser sends the resource that needs to be requested to the remote server to the mobile terminal proxy server.
- the proxy server on the mobile side receives the request and parses the request according to the HTTP protocol. It is then locally detected whether the resource has been cached by the mobile proxy server. If the cache does not exist, the mobile phone will query the retrieved resource URL in the cache list through the URL matching algorithm. If the related resource is queried, the resource will be returned. Otherwise, the resource request is sent to the server through HTTP2 or SPDY protocol.
- the URL matching algorithm consists of two parts, URL pattern recognition and URL matching query, in which pattern recognition is performed on the cloud server side and matching queries are performed on the mobile phone side.
- the cloud server periodically fetches and parses the same website, thereby obtaining a corresponding list of URLs and resources.
- the purpose of the algorithm is to retrieve potential corresponding resources according to the URL, so it is necessary to establish a URL pattern corresponding to each resource.
- the algorithm first splits the URL according to the common URL separator. For the same resource, the probability that the resource remains unchanged when each part of the URL changes is calculated. This value is called the paragraph key coefficient.
- the calculation method is:
- This value is always between 0 and 1 for all resources.
- the mobile terminal agent service When the mobile terminal agent service receives a request for a URL, it first performs a matching query, and compares the URL with the similarity of all the URL records of the corresponding website (first find the corresponding website according to the URL, and then all the URLs of the website) The records are compared), the similarity is calculated as follows:
- ⁇ i indicates whether the paragraph of the URL to be requested in the search matches the paragraph of the target URL, and if it does not match, it is 1, and the match is 0.
- the similarity result is 1 when the to-be-requested URL is identical to the target URL.
- the similarity result is greater than 0.5, we consider that the resource of the target URL is the resource of the URL to be requested, and takes the result of the maximum similarity as the resource of the URL to be requested. If the similarity of all the resources is less than 0.5, the matching is considered to be a failure. The resource does not exist in the cache and needs to be sent to the server for further confirmation.
- the server After receiving the resource request from the mobile terminal, the server calculates the database entry corresponding to the URL according to the relevant algorithm, or the URL is not in the database, that is, the resource is not cached. If the resource is not cached, the server requests the resource from the original website. After the resource is obtained, the check value of the resource is calculated and the entry is stored in the database.
- the invention optimizes the web browsing through the four-layer architecture, which can reduce the transmission traffic and increase the loading speed.
- This framework can save traffic by 17% and increase loading speed by 29% when users visit the webpage for the first time. By accessing the same webpage again, it can save 66% of traffic for the second visit and increase the loading speed. %.
- FIG. 1 is a system architecture diagram of the present invention.
- This section takes a news website as an example, and gives a background operation process in which the user accesses the news website twice by using the framework provided by the present invention.
- the cloud server periodically prefetches the resource of the website.
- the browser first sends the HTML request to the mobile proxy server. Since HTML belongs to the most frequently updated resource, for HTML. Request, the mobile terminal will default to the previous cache is not available, and initiate an inquiry to the server. After the proxy service resolves the URL, it initiates an inquiry to the cloud server. Since the cloud server has previously pre-fetched the resource, the server can retrieve the resource according to the URL. After that, the server will retrieve the resource in the mobile terminal resource list. Since the website has not been visited before, the resource does not exist on the mobile terminal, so the server compresses the resource and returns it to the mobile proxy server.
- the mobile proxy server will parse the content returned by the server and organize it into an HTTP response and send it back to the browser.
- the browser will parse the contents of the HTML and send a request for the remaining resources to the proxy service. For the remaining resources, since there was no previous access Through the website, these resources do not exist in the cache, and the cached resources similar to the resource cannot be calculated by the URL matching algorithm, so the mobile terminal proxy service also requests these resources from the server.
- the browser When visiting the website for the second time, the browser will send the HTML request to the mobile agent again, and the mobile terminal will send the request for the resource to the cloud server.
- the cloud server retrieves the resource locally, it will check according to the verification. The value is retrieved in the phone cache list. If the content of the HTML itself has not changed, the check value of the resource will exist in the phone cache list, the resource itself will not be returned, otherwise the entire resource needs to be returned, and on the mobile phone side. Update the cache.
- the change of the URL may be caused by dynamic analysis of the webpage, and the resource itself is not changed, and the URL matching algorithm can detect Change to such a resource URL to return the corresponding cached resource. If the algorithm determines that the relevant resource cannot be found, the mobile terminal still needs to send the request to the server for inquiry.
- the mobile terminal After the mobile terminal sends the request for the resource to the cloud server, if the cloud server retrieves or requests the resource, and finds that the check value corresponding to the resource already exists in the resource list of the mobile terminal, the resource itself is not returned. , and only the response header and check value will be returned to the mobile terminal.
- the mobile terminal will receive the information, then extract the resource ontology from the local, recombine the two (the response header and the resource ontology) according to the corresponding structure of HTTP, and send the content to the browser.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明公开了一种基于云-端协同的移动浏览器资源加载优化方法。本方法为:1)在用户的手机端建立一代理服务器,在该用户的个人云上搭建一云服务器;2)手机端代理服务器将接收并解析浏览器的URL请求,如果手机端代理服务器已缓存该URL请求对应的资源,或者通过URL匹配算法计算出存在对应的资源,则直接将该资源返回给浏览器;否则将其发送给云服务器;3)云服务器检查是否已缓存该URL请求对应的资源,如果已缓存则将该资源返回给代理服务器;否则向该URL请求对应的目标网站进行资源请求并将结果返回给手机端代理服务器;4)该手机端代理服务器将收到的返回结果依照HTTP响应的结构发回浏览器。本发明大大提高了加载速度。
Description
本发明是一种基于云-端协同的移动浏览器资源加载优化方法,属于软件技术领域。
根据中国互联网络信息中心于2015年1月发布的《第35次中国互联网络发展状况统计报告》,截至2014年12月,我国手机网民规模达5.57亿,网民中使用手机上网的人群占比已达到85.8%。连续几年来,手机网民规模保持稳定增长,手机也早已成为第一大上网终端。
越来越多的人们正在利用手机或者平板电脑来通过Wi-Fi或3G网络上网,随之而来的,Web浏览器成为了移动设备上最常用的应用之一。据研究表明,浏览器占据了移动设备63%的显示时间。但是,现有移动浏览器的用户体验却远不尽如人意。资源加载是影响浏览器性能重要因素之一,有实验表明,网页加载65%的时间都消耗在资源加载上。由于移动设备的网络状况通常并不理想,尤其是可能出现网络拥挤或是用户正在移动的状况,这个问题就变得更为严重了。此外,下载资源的过程本身会消耗许多电量,而电量恰恰是移动设备上最为稀缺的资源。
为了加速Web资源加载,缓存机制被广泛运用。通过缓存的方法,可以为用户减少资源下载量,从而提高Web浏览性能。这种缓存机制给移动设备带来的好处更大,因为在移动设备上,该机制不仅可以减少网页加载时间,还可以减少网络流量和电量消耗。然而在实际运用中,缓存却常常并未被很好地配置与实现。有研究表明,缓存机制的理论性能与实际性能之间有很大差距因此当前有这样一个需求,在不改变现有浏览器与服务器实现的前提下,对现有的缓存机制进行优化,提高缓存的利用效果。希望可以以此进一步提高移动设备用户在浏览网页时的体验,减少用户的流量与电量消耗。
发明内容
针对现有技术中存在的问题,本发明的目的在于提供一种基于云-端协同的移动浏览器资源加载优化方法。本发明是在不改变现有用户浏览习惯与Web应用缓存原有配置的前提下,最大程度减少Web资源的传输流量并提高加载速度。其核心思想是:在原有的Web应用架构的基础上,在手机端搭建代理服务器,并借助云服务器预取Web资源,即将原有的从浏览器到服务器的两层架构改变为四层架构。
该系统在手机端搭建HTTP代理服务器,并将手机端浏览器的HTTP代理配置为该手机端代理服务器;在个人云上为每个手机用户搭建云服务器。手机端代理服务器接收手机端浏览器的请求,并向手机端浏览器返回资源响应。手机端代理服务器并不直接向互联网请求资源,而向在个人云上搭建的云服务器请求资源,由云服务器从互联网上下载资源,并有选择地向手机端进行推送。在此过程中,通过URL匹配算法、资源校验码比对、数据压缩与网站预取等手段达到最大程度减少传输流量并提高加载速度的目的。
本发明的技术方案为:
一种云-端协同的移动浏览器缓存优化方法,具体步骤为:
1)在手机端建立代理服务器,该代理服务器可以接收浏览器的请求,并解析请求,对于代理服务器已缓存的资源,或者通过URL匹配算法计算出存在对应的资源,可以直接将资源返回给浏览器;对于本地未存储的资源,向云端服务器进行资源的查询。
2)在云端为每个手机用户建立一个云服务器,该云服务器可以进行Internet连接。云服务器可以预取网站的资源,并接收手机端代理服务器的资源请求。如果资源已经被缓存在云服务器上,则云服务器直接向手机端代理服务器返回该资源,如果没有,则向目标网站进行请求并将结果返回。
3)用户在手机端将浏览器的代理配置为手机端的代理服务器。
进一步的,每一个资源都会在云服务器端计算出该文件的校验值,作为标识资源内容的唯一依据,可以依据该值对缓存资源进行检索。在服务器端将资源传回手机端时,会先检索该校验值的文件是否已存在于手机端的缓存中,如果已存在,则仅返回该资源的校验值,手机端代理服务器会根据该校验值提取资源。
进一步的,云端服务器会定时预取用户可能访问的网站,提前建立网站的缓存以供用户访问。
进一步的,所有服务器到手机端的传输均经过压缩,以节省未经压缩资源的传输流量。
使用本发明的框架,资源访问主要包含三个步骤:
1.预取目标资源:云服务器端会定期对用户可能访问的资源进行预取。
2.接收浏览器请求并检查手机端缓存:手机端代理服务器接收浏览器请求,如果手机端没有缓存资源,则向云端服务器请求资源;如果该缓存存在或可以根据URL匹配算法找到相应资源,则直接向浏览器返回资源。
3.检查云服务器端缓存:如果云服务器端没有缓存资源,则向原网站请求,然后将资源传回手机端代理服务器。手机端代理服务器再将结果依照HTTP响应的结构发回浏览器。
上述步骤的具体技术方案如下:
1.预取目标资源:服务器端会对用户可能访问的资源进行提前预取,具体的资源列表会根据用户的访问习惯产生。服务器会将预取好的资源存储,同时计算好校验值,并将条目整理到数据库中。
2.代理服务器接收浏览器请求并检查手机端缓存:本发明可以与浏览器的原有缓存同时使用,浏览器会将原本需要向远程服务器请求的资源发到手机端代理服务器上。手机端的代理服务器会接收请求并根据HTTP协议对请求进行解析。之后在本地检测资源是否已被手机端代理服务器缓存。如果缓存不存在,手机会将解析到的资源URL通过URL匹配算法在缓存列表中进行查询,如果查询到相关资源,则返回资源,否则将资源请求通过HTTP2或SPDY协议发送给服务器。
URL匹配算法包含两部分,URL模式识别与URL匹配查询,其中模式识别在云服务器端进行,匹配查询在手机端进行。
云服务器会对同一网站定时进行的抓取与解析,由此可以得到URL和资源的对应列表。同一资源对应的URL可能会有多个。本算法的目的在于根据URL检索到潜在对应的资源,因此需要建立每个资源对应的URL模式。算法首先对URL根据常见URL分隔符进行切分,对于同一资源,计算得出URL每一部分发生变化时,该资源保持不变的可能性,这个值我们称为段落关键系数,计算方法为:
对于所有资源,该值永远介于0至1之间。
当服务器将资源与其URL发回手机端时,该URL中所有段落的关键系数都将被传回。
当手机端代理服务接收到一个URL的请求时,会首先进行匹配查询,将该URL与相应网站的所有URL记录进行相似度的对比(先根据该URL找到相应网站,然后将该网站的所有URL记录进行对比),相似度的计算方法如下:
其中αi表示检索中的待请求URL的段落是否与目标URL的段落匹配,如果不匹配则为1,匹配则为0。特别地,当待请求URL与目标URL完全相同时,该相似度结果为1。当相似度结果大于0.5时,我们认为目标URL的资源就是待请求URL的资源,并取最大相似度的结果作为待请求URL的资源,如果所有资源的相似度均不足0.5,则认为匹配失败。缓存中
不存在该资源,需要发往服务器进一步确认。
3.检查服务器端缓存:服务器端接收到手机端的资源请求后,会根据相关算法计算出该URL对应的数据库条目,或者URL并不在数据库中,即资源并未缓存。如果资源没有被缓存,服务器会向原网站请求该资源,得到资源后,会将资源的校验值计算出并将条目存储到数据库中。
4.检查资源是否在手机端已存在并向浏览器发送响应:在服务器端准备好资源后,会依照资源的校验码在服务器端存储的手机资源列表中检索资源是否存在,如果资源存在,则不会返回数据体,只会返回资源对应的校验值,手机端会根据此校验值从本地列表中提取出相应资源。如果资源不存在,则服务器端会将资源压缩并通过HTTP2或SPDY协议将内容返回给手机端。手机端接收到数据后会进行解压缩,并按照HTTP响应的标准得到该资源的响应,最终将相应发回给浏览器。
与现有技术相比,本发明的积极效果为:
本发明通过四层架构进行Web浏览的优化,可以减少传输流量并提高加载速度。实验表明,使用该框架,在用户第一次访问网页时,平均可以节省流量17%,提高加载速度29%;再次访问同一网页,平均可以为第二次访问节省流量66%,提高加载速度9%。
图1为本发明的系统架构图。
本节以某新闻网站为例,给出用户利用本发明提供的框架先后两次访问该新闻网站的后台操作过程。
云服务器端会定期预取该网站的该资源,当用户第一次访问该网站时,浏览器会先把HTML的请求发送给手机端代理服务器,由于HTML属于最经常更新的资源,对于HTML的请求,手机端会默认此前的缓存不可用,而向服务器发起询问。代理服务解析出URL后,向云端的服务器发起询问,由于云端的服务器此前已经预取过该资源,服务器可以根据URL检索到该资源。此后服务器会在手机端资源列表中检索该资源,由于此前并未访问过此网站,该资源不存在手机端上,因此服务器会将资源进行压缩,并传回手机端代理服务器。手机端代理服务器会解析服务器传回的内容,并将其整理为HTTP响应,发回浏览器。浏览器将解析HTML的内容,并向代理服务发送其余资源的请求。对于剩余的资源,由于此前并未访问
过该网站,缓存中不存在这些资源,通过URL匹配算法也无法计算得出与该资源相似的已缓存资源,因此手机端代理服务也会向服务器请求这些资源。
在第二次访问该网站时,浏览器会再次把HTML的请求发送给手机端代理,手机端会将该资源的请求发给云服务器,云服务器在本地检索到该资源后,再根据校验值在手机缓存列表中检索,如果HTML本身的内容并未改变,该资源的校验值会在手机缓存列表中存在,该资源本身将不会被返回,否则需要返回整个资源,并在手机端更新该缓存。
对于HTML解析出的某些资源,虽然在手机端不存在该URL的缓存数据,但这种URL的改变可能是由于网页的动态解析造成的,资源本身并未改变,通过URL匹配算法,可以检测到这类资源URL的改变从而返回相应的已缓存资源。如果算法判定找不到相关资源,手机端仍需将该请求发送给服务器进行询问。
当手机端将该资源的请求发送给云服务器端后,若云服务器检索或请求到该资源之后,发现该资源对应的校验值在手机端的资源列表中已存在,则不会返回该资源本身,而只会向手机端返回响应头和校验值。手机端会接收到该信息,然后从本地提取出资源本体,将两者(该响应头和资源本体)按照HTTP相应的结构进行重新组合,并将此内容发给浏览器。
Claims (9)
- 一种基于云-端协同的移动浏览器资源加载优化方法,其步骤为:1)在用户的手机端建立一代理服务器,在该用户的个人云上搭建一云服务器;2)手机端代理服务器将接收并解析浏览器的URL请求,如果手机端代理服务器已缓存该URL请求对应的资源,或者通过URL匹配算法计算出存在对应的资源,则直接将该资源返回给浏览器;否则将该URL请求发送给云服务器;3)云服务器检查是否已缓存该URL请求对应的资源,如果已缓存则将该资源返回给该手机端代理服务器;否则向该URL请求对应的目标网站进行资源请求并将结果返回给该手机端代理服务器;4)该手机端代理服务器将收到的返回结果依照HTTP响应的结构发回浏览器。
- 如权利要求1所述的方法,其特征在于,所述云服务器为一虚拟机。
- 如权利要求1或2所述的方法,其特征在于,所述云服务器将资源与其URL返回手机端代理服务器时,将该URL相关的段落关键系数同时传回。
- 如权利要求3所述的方法,其特征在于,所述段落关键系数为(段落的出现次数)/(相同资源对应URL总数+1)。
- 如权利要求1或2所述的方法,其特征在于,当该代理服务接收到一个URL请求时,先进行匹配查询,将该URL与相应网站的所有URL记录进行相似度对比,将相似度最大且超过设定阈值的URL记录对应的缓存资源返回给浏览器。
- 如权利要求1所述的方法,其特征在于,所述云服务器计算获取的资源的校验值并将该资源及其校验值存储到数据库中。
- 如权利要求1所述的方法,其特征在于,所述云服务器根据用户的访问习惯生成该用户的资源列表,然后根据该资源列表进行资源预取,并将预取好的资源及其校验值存储到数据库中。
- 如权利要求7或8所述的方法,其特征在于,所述云服务器将资源返回手机端代理服务器之前,检查该资源对应的校验值在手机端的资源列表中是否已存在,如果存在则返回响应 头和该资源的校验值;该手机端代理服务器接收到该信息后从本地提取出资源本体,将该响应头和资源本体按照HTTP相应的结构进行重新组合,并将此内容发给浏览器;如果不存在,则将该资源及其校验值发送给手机端代理服务器。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/743,018 US10686726B2 (en) | 2015-12-21 | 2016-09-07 | Method for optimizing resource loading at mobile browsers based on cloud-client cooperation |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510964171.0A CN105610909B (zh) | 2015-12-21 | 2015-12-21 | 一种基于云-端协同的移动浏览器资源加载优化方法 |
| CN201510964171.0 | 2015-12-21 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2017107568A1 true WO2017107568A1 (zh) | 2017-06-29 |
Family
ID=55990443
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2016/098289 Ceased WO2017107568A1 (zh) | 2015-12-21 | 2016-09-07 | 一种基于云-端协同的移动浏览器资源加载优化方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US10686726B2 (zh) |
| CN (1) | CN105610909B (zh) |
| WO (1) | WO2017107568A1 (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110198333A (zh) * | 2018-04-18 | 2019-09-03 | 腾讯科技(深圳)有限公司 | 数据获取方法和装置、存储介质及电子装置 |
| CN112286592A (zh) * | 2020-10-29 | 2021-01-29 | 平安普惠企业管理有限公司 | 资源数据的加载方法及装置、存储介质、计算机设备 |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10320934B1 (en) * | 2015-08-25 | 2019-06-11 | Instart Logic, Inc. | One-time cache |
| CN105610909B (zh) * | 2015-12-21 | 2019-01-18 | 北京大学 | 一种基于云-端协同的移动浏览器资源加载优化方法 |
| CN106161427B (zh) * | 2016-06-08 | 2020-02-11 | 北京兰云科技有限公司 | 一种网页处理方法、网络分析器及http服务器 |
| EP3484125B1 (en) * | 2016-07-08 | 2022-09-07 | Tencent Technology (Shenzhen) Company Limited | Method and device for scheduling interface of hybrid cloud |
| KR101962426B1 (ko) * | 2016-12-27 | 2019-03-26 | 한국과학기술원 | 모바일 애플리케이션 콘텐츠 로딩 가속화 방법 및 장치 |
| CN109089175B (zh) * | 2017-06-14 | 2022-04-22 | 中兴通讯股份有限公司 | 一种视频缓存加速的方法及装置 |
| CN110020310A (zh) * | 2017-12-05 | 2019-07-16 | 广东欧珀移动通信有限公司 | 资源加载的方法、装置、终端及存储介质 |
| KR20210157389A (ko) * | 2018-11-21 | 2021-12-28 | 글랜스 네트웍스, 인크. | 공동 브라우징 세션에서 독점 자원에 액세스하기 위한 방법 및 장치 |
| CN110516189B (zh) | 2019-08-29 | 2023-04-18 | 深圳市今天国际物流技术股份有限公司 | 一种界面自我服务的方法、装置、计算机设备及存储介质 |
| CN112364274B (zh) * | 2020-10-28 | 2024-12-06 | 北京中科网威信息技术有限公司 | Web站点访问加速方法及装置 |
| CN113515458B (zh) * | 2021-07-23 | 2024-04-16 | 浩鲸云计算科技股份有限公司 | 基于Envoy插件降低测试环境资源消耗的方法及系统 |
| CN114598503B (zh) * | 2022-02-21 | 2023-12-12 | 北京北信源软件股份有限公司 | 违规外联检测方法、装置、系统及电子设备 |
| CN118353959B (zh) * | 2024-06-18 | 2024-11-12 | 北京翼辉信息技术有限公司 | 资源请求处理方法、电子设备及计算机可读存储介质 |
| CN120179940B (zh) * | 2025-03-05 | 2025-11-18 | 中科星图易码(无锡)科技有限公司 | 用于WebGIS端的空间数据的加载方法、装置及客户端 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101163156A (zh) * | 2007-09-27 | 2008-04-16 | 腾讯科技(深圳)有限公司 | 获取网络资源的方法、客户端与系统 |
| US20090177514A1 (en) * | 2008-01-08 | 2009-07-09 | Microsoft Corporation | Services using globally distributed infrastructure for secure content management |
| CN101814086A (zh) * | 2010-02-05 | 2010-08-25 | 山东师范大学 | 一种基于模糊遗传算法的中文web信息过滤方法 |
| CN103795690A (zh) * | 2012-10-31 | 2014-05-14 | 华为技术有限公司 | 一种云访问控制的方法、代理服务器和系统 |
| CN104202403A (zh) * | 2014-09-10 | 2014-12-10 | 安一恒通(北京)科技有限公司 | 网页浏览的加速方法、云服务器和浏览器 |
| CN105610909A (zh) * | 2015-12-21 | 2016-05-25 | 北京大学 | 一种基于云-端协同的移动浏览器资源加载优化方法 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5673322A (en) * | 1996-03-22 | 1997-09-30 | Bell Communications Research, Inc. | System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks |
| US6959318B1 (en) * | 1998-03-06 | 2005-10-25 | Intel Corporation | Method of proxy-assisted predictive pre-fetching with transcoding |
| US7519726B2 (en) * | 2003-12-12 | 2009-04-14 | International Business Machines Corporation | Methods, apparatus and computer programs for enhanced access to resources within a network |
| US8676978B2 (en) * | 2010-08-03 | 2014-03-18 | Facebook, Inc. | Efficient storage and retrieval of resources for rendering structured documents |
| CN103701834A (zh) * | 2012-09-27 | 2014-04-02 | 中国人民解放军国防科学技术大学 | 基于代理的移动云服务访问系统及方法 |
| US9363660B2 (en) * | 2013-04-30 | 2016-06-07 | Metaswitch Networks Ltd. | Processing data in a cluster of network nodes |
| CN103237088A (zh) * | 2013-05-16 | 2013-08-07 | 百度在线网络技术(北京)有限公司 | 基于对应关系库的浏览方法、系统及云端服务器 |
| US9037752B1 (en) * | 2013-11-14 | 2015-05-19 | Sap Se | Remote materialization of low velocity data |
-
2015
- 2015-12-21 CN CN201510964171.0A patent/CN105610909B/zh active Active
-
2016
- 2016-09-07 US US15/743,018 patent/US10686726B2/en active Active
- 2016-09-07 WO PCT/CN2016/098289 patent/WO2017107568A1/zh not_active Ceased
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101163156A (zh) * | 2007-09-27 | 2008-04-16 | 腾讯科技(深圳)有限公司 | 获取网络资源的方法、客户端与系统 |
| US20090177514A1 (en) * | 2008-01-08 | 2009-07-09 | Microsoft Corporation | Services using globally distributed infrastructure for secure content management |
| CN101814086A (zh) * | 2010-02-05 | 2010-08-25 | 山东师范大学 | 一种基于模糊遗传算法的中文web信息过滤方法 |
| CN103795690A (zh) * | 2012-10-31 | 2014-05-14 | 华为技术有限公司 | 一种云访问控制的方法、代理服务器和系统 |
| CN104202403A (zh) * | 2014-09-10 | 2014-12-10 | 安一恒通(北京)科技有限公司 | 网页浏览的加速方法、云服务器和浏览器 |
| CN105610909A (zh) * | 2015-12-21 | 2016-05-25 | 北京大学 | 一种基于云-端协同的移动浏览器资源加载优化方法 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110198333A (zh) * | 2018-04-18 | 2019-09-03 | 腾讯科技(深圳)有限公司 | 数据获取方法和装置、存储介质及电子装置 |
| CN110198333B (zh) * | 2018-04-18 | 2022-05-20 | 腾讯科技(深圳)有限公司 | 数据获取方法和装置、存储介质及电子装置 |
| CN112286592A (zh) * | 2020-10-29 | 2021-01-29 | 平安普惠企业管理有限公司 | 资源数据的加载方法及装置、存储介质、计算机设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105610909B (zh) | 2019-01-18 |
| US10686726B2 (en) | 2020-06-16 |
| US20180287960A1 (en) | 2018-10-04 |
| CN105610909A (zh) | 2016-05-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2017107568A1 (zh) | 一种基于云-端协同的移动浏览器资源加载优化方法 | |
| US10645143B1 (en) | Static tracker | |
| US20220006878A1 (en) | Method and apparatus for reducing loading time of web pages | |
| EP1908245B1 (en) | Method for training a server for content delivery based on communication of state information from a mobile device browser | |
| US8341245B1 (en) | Content-facilitated speculative preparation and rendering | |
| US8990357B2 (en) | Method and apparatus for reducing loading time of web pages | |
| US8171135B2 (en) | Accumulator for prefetch abort | |
| CN103593466B (zh) | 网页加载方法及客户端和服务器 | |
| US20100146415A1 (en) | Dns prefetch | |
| CN103383687B (zh) | 一种页面处理方法和装置 | |
| US20120136927A1 (en) | Computer networking system and method with javascript execution for pre-fetching content from dynamically-generated url and javascript injection to modify date or random number calculation | |
| WO2011109957A1 (zh) | 一种提高网页访问速度的方法及装置 | |
| CN107025234A (zh) | 一种信息推送方法及缓存服务器 | |
| US20180302489A1 (en) | Architecture for proactively providing bundled content items to client devices | |
| US20130262704A1 (en) | System and method for improving delivery of content over a network | |
| EP1907922B1 (en) | A method for detecting state changes between data stored in a first computing device and data received from a second computing device | |
| WO2019052299A1 (zh) | 一种sdn交换机和sdn交换机的应用管理方法 | |
| WO2012159360A1 (zh) | 网页预取的方法及装置 | |
| WO2011067769A1 (en) | Shared dictionary compression over http proxy | |
| EP2901658B1 (en) | Request-agnostic caching for a data resource collection | |
| WO2012119496A1 (zh) | 预读方法和装置 | |
| CN103167554B (zh) | 网关流量压缩处理方法与装置、网络服务提供系统 | |
| KR20020008579A (ko) | 압축기능을 갖는 웹 프락시 솔루션 | |
| CN118035585A (zh) | 网页资源的加载方法、装置、终端设备和存储介质 | |
| Deng et al. | A review of network latency optimization techniques |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16877379 Country of ref document: EP Kind code of ref document: A1 |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 15743018 Country of ref document: US |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 16877379 Country of ref document: EP Kind code of ref document: A1 |


