WO2013113150A1 - 缓存优化的方法、缓存器和缓存优化的系统 - Google Patents

缓存优化的方法、缓存器和缓存优化的系统 Download PDF

Info

Publication number
WO2013113150A1
WO2013113150A1 PCT/CN2012/070791 CN2012070791W WO2013113150A1 WO 2013113150 A1 WO2013113150 A1 WO 2013113150A1 CN 2012070791 W CN2012070791 W CN 2012070791W WO 2013113150 A1 WO2013113150 A1 WO 2013113150A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
url
cache
response message
cached
Prior art date
Application number
PCT/CN2012/070791
Other languages
English (en)
French (fr)
Inventor
欧雄兵
顾纳
Original Assignee
华为技术有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN201280000262.7A priority Critical patent/CN103416027B/zh
Priority to PCT/CN2012/070791 priority patent/WO2013113150A1/zh
Publication of WO2013113150A1 publication Critical patent/WO2013113150A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching

Definitions

  • Embodiments of the present invention relate to the field of communications and, more particularly, to a method of cache optimization, a cache, and a cache optimization system.
  • BACKGROUND OF THE INVENTION The number of users, types of Internet applications, and network bandwidth all show explosive growth. These applications give customers a rich Internet experience, but they also lead to a surge in network traffic.
  • network operators and managers mainly use methods such as expanding bandwidth, controlling traffic, introducing a web cache, and introducing content sources. Compared with the expansion bandwidth, traffic control, network cache introduction, and limited improvement brought by the introduction of content sources, telecom operators can also choose to deploy cache nodes in the network to cache hot content, thereby achieving low cost in a way that reduces bandwidth. Operation and improvement of service quality, that is, operators actively deploy OTT (over the top) cache nodes in their networks.
  • the OTT cache node is deployed next to the Internet egress of the network, and the policy route is deployed on the router, and the Hyper Text Transport Protocol (HTTP) service is routed to the cache node, if the cache node has the terminal requested by the cache.
  • HTTP Hyper Text Transport Protocol
  • the content is directly provided by the cache node. If the cache node does not cache the content requested by the terminal, the cache node proxy terminal requests the content from the content source and then delivers the content to the terminal.
  • the OTT cache node After the OTT cache node obtains the content from the content source through the HTTP protocol, if the cache control header field carried in the HTTP response message returned by the content source indicates that the content can be cached, the content is cached according to the cache control header field; if the content source is found The returned HTTP response message does not carry the cache control header field or the cache control header field that is carried does not cache. The content is not cached by default.
  • the service provider I content provider does not tend to allow the carrier's network to cache its own content for the purpose of protecting its own business and content, so in response messages Often, the cache control header field is not carried by default or the cache control header field is not indicated to be cached. Then, if the OTT cache node always determines the cache and refresh of the content according to the cache control header field, the cache effect will be poor, and a large number of service requests still need to be needed. Up to the content source, the effect of reducing bandwidth and improving the terminal service experience.
  • the operator performs offline analysis on the content of the traffic provided by the SP/CP, and then analyzes the result as a policy to the OTT cache node.
  • the refresh of the configuration policy is not flexible and timely, so the change of the service cannot be quickly tracked. Once the content source is modified, the service quality may be affected. Summary of the invention
  • the embodiment of the invention provides a method for buffer optimization, a buffer and a cache optimization system, which can avoid the problem of whether the cache quality is affected by the cache control header field in the HTTP response header.
  • a method for buffer optimization including: receiving, by a terminal, multiple service requests for a first Uniform Resource Locator (URL), and receiving multiple received from a content source based on the multiple service requests.
  • a first response message when none of the plurality of first response messages does not carry a cache control header field or the carried cache control header field indicates not to be cached, respectively determining the content of the content included in the plurality of first response messages a signature value; comparing a plurality of the first signature values, if the same, buffering content included in the first response message and the first URL, if not identical, not including the first response message Content.
  • a buffer including: a processing unit, configured to receive, by a terminal, multiple service requests for a first URL, and receive multiple first response messages from a content source, respectively, based on the multiple service requests, Determining, by the plurality of first response messages, the cache control header field or the carried cache control header field indicating that the first signature value of the content included in the plurality of first response messages is respectively not determined; For comparing the plurality of the first signature values, if the same, the buffer buffers the content included in the first response message and the first URL, and if not, the buffer does not cache the The content contained in the first response message.
  • a cache optimization system including: multiple buffers; a service management device; an extensible message processing field protocol XMPP server, configured to acquire a cache rule issued by the service management device, and each of the An analysis result of whether the URL can be cached by the buffer, so that the service management device learns, by the XMPP server, an analysis result of whether the uniform resource locator URL can be cached by each of the buffers, and each of the The cacher learns, by the XMPP server, a cache rule issued by the service management device and an analysis result published by other buffers whether the URL can be cached.
  • the cache optimization method, the buffer, and the cache optimization system of the embodiment of the present invention may determine the cache content cached in the local cache device based on the signature value of the requested service content, thereby reducing bandwidth and improving the terminal service experience.
  • FIG. 1 is a flow chart of a method of cache optimization in accordance with an embodiment of the present invention.
  • FIG. 2 is a schematic structural diagram of a buffer according to an embodiment of the present invention.
  • FIG. 3 is a schematic structural diagram of a buffer according to another embodiment of the present invention.
  • FIG. 4 is a schematic structural diagram of a buffer according to still another embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of a buffer according to still another embodiment of the present invention.
  • FIG. 6 is a schematic structural diagram of a buffer according to still another embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a system for cache optimization according to an embodiment of the present invention. detailed description
  • An embodiment of the present invention provides a method for buffer optimization, that is, a method for actively caching content, implementing a single package, and being transparent to a terminal, a content source, and an operator.
  • the method of the embodiment of the present invention can automatically perform automatic analysis on a popular Uniform Resource Locator (URL), and determine whether the content can be cached by analyzing a response message of multiple requests of the corresponding URL.
  • the cached content can be identified according to the signature value of the actual content, so that the ratio of the cached content can be increased even when the URL changes, so that the actually cacheable content with a relatively high heat is cached on the cache node, thereby To reduce bandwidth and improve the terminal business experience.
  • the solution of the invention can quickly track the change of the business, and let the popular content end in this as soon as possible. Ground.
  • the traffic of the user accessing the external network server is transferred to the cache node through the PBR, so that the HTTP traffic is drained from the router to the cache node, and then the cache node is used to proxy the user to the external network.
  • the server downloads the content and provides it to the user. That is, the user's HTTP access request is pulled to the cache node through the PBR; if the cache node does not locally cache the content requested by the user, the proxy user initiates an HTTP access request to the external network server; the external network server returns a response message according to the HTTP access request.
  • the cache node; the cache node then returns a response message to the user.
  • the cache node In the process of providing content delivery to the user by the cache node, for each HTTP request received, if the corresponding content is not cached locally, the content source server of the SP/CP needs to be requested. For the response message received from the content source server, the cache node needs to check its cache control header field. If the cache control header field carries a header field that can be cached, it can be directly cached locally on the cache node, and does not carry a cache control header for the response message. When the domain or the carried cache control header field indicates that it is not cached, the cache node analyzes the popular URL to determine whether the content contained in the response message can be cached.
  • the method of cache optimization includes the following steps:
  • the cache node receives, by the terminal, multiple service requests for the first uniform resource locator URL, and receives multiple first response messages from the content source (for example, the content source server) according to the multiple service requests, if the multiple The first response message does not carry the cache control header field or the carried cache control header field indicates that the buffer is not cached, and the first signature value of the content included in the multiple first response messages is determined respectively.
  • the content source for example, the content source server
  • the cache node receives the first response message from the content source, if the first response message does not carry the cache control header field or the carried cache control header field. If the indication is not cached, the cache node determines a first signature value of the content contained in the first response message. It will be appreciated that the first signature value may be determined for all or part of the content of the content contained in the first response message. At this time, the first URL and its corresponding content are not saved in the cache node. If the terminal further initiates a service request for the first URL to the cache node multiple times, the cache node still calculates a plurality of first signature values according to the corresponding content. At this point, the cache node still does not save the first URL and its corresponding content.
  • the URL involved is also a lot of.
  • the hotness of the first URL is first counted. If the heat of the first URL does not reach the threshold, the cache node does not need to consider saving the first URL. And corresponding business content, the operation of calculating the first signature value is performed only when the heat of the first URL exceeds a threshold, and it is determined that the first URL is not statically configured and is not in the blacklist. In this way, the cache node actively analyzes the URLs with high access popularity and compares the results of multiple requests. If they are consistent, the local cache is forced. If the URLs are inconsistent, the cache is not cached and the URL is entered into the uncached blacklist to avoid repeated analysis.
  • the cache node compares the plurality of the first signature values. If they are the same, the content included in the first response message and the first URL are cached. Otherwise, the content included in the first response message is not cached.
  • the cache optimization method of the embodiment of the present invention can determine the cached content cached in the local cache device based on the signature value of the requested service content, thereby reducing bandwidth and improving the terminal service experience.
  • the cache node if the response message returned by the content source server does not carry the cache control header field or the carried cache control header field indicates that the cache is not cached, the cache node does not cache the request.
  • the content carried by the response message obtained by the content source server, but the cache node calculates the heat of the first URL in real time based on the number of accesses. After the heat of the first URL reaches a set threshold, it is checked whether the cache policy for the first URL has a static configuration can be matched, and if so, can be processed according to the corresponding static policy.
  • the so-called static configuration means that if you know explicitly that some URLs belong to dynamic URLs and cannot be cached, you can configure static caching policies for these URLs to explicitly not cache these URLs.
  • the cache node determines that the first URL does not have a statically configured cache policy, it checks whether the first URL is in the blacklist that is not cached. If the blacklist does not perform subsequent processing, the process continues as follows:
  • the cache node After the cache node receives the service request corresponding to the first URL again, since the corresponding content is not cached locally, the cache node still needs to obtain content from the content source server.
  • the signature value is generated for the content acquired this time, and the algorithm for generating the signature value may have various options, such as the message digest algorithm fifth edition (MD5, Message Digest Algorithm). 5) Or a Secure Hash Algorithm (SHA).
  • MD5 message digest algorithm fifth edition
  • SHA Secure Hash Algorithm
  • a single signature value can be generated for the entire content returned by the content source server, or the content can be sampled to reduce the amount of calculation to generate a single or multiple signature values, for example, only the first 16 KB (Kbyte) of the returned content is used.
  • the content of the calculation calculates the signature value, or the signature value is calculated separately for the first 16 KB and the last 16 KB.
  • the calculated signature value is obtained from the content source server. After the cache node receives the service request corresponding to the first URL, the cache node still needs to obtain the content from the content source server because the corresponding content is not cached locally.
  • the above algorithm is used to calculate the signature value, and the calculated signature value is compared with the previously calculated signature value. If the comparison result of the signature values of the content downloaded from the content source server is consistent multiple times (for example, 2 times or 3 times), it is considered that the content corresponding to the first URL can be used for the service request of the first URL. Cache local content directly to provide services.
  • the result of the signature value is inconsistent, for example, the signature values of the two consecutive calculations are inconsistent, indicating that each time the content obtained from the content source server is different, the content of the first URL cannot be locally cached, and the first URL needs to enter. Go to the un-cached blacklist or lower the heat statistics of the first URL to avoid subsequent judgment processing whether it can be cached.
  • a time to live TTL (Time To Live ) may be set for the content included in the cached first response message, so that when the TTL expires, the cached first response message is forcibly deleted.
  • Content Specifically, set different TTL values for locally cached content. When the TTL times out, the content of the locally cached content is forcibly deleted, and the content is requested again from the content source server when a new service request is received. In this way, it is possible to avoid a small change in the actual content and a low probability event that the signature value of the partial content technology is still consistent, thereby ensuring that the cached content is consistent with the content on the content source server.
  • setting the TTL can be based on the following principles.
  • different domain name settings For example, for a domain name that mainly provides video content, the content has a low frequency of change, so a longer TTL can be set; for a domain name that mainly provides information, the content changes frequently, so the setting is The TTL is relatively short.
  • Set according to the extension of the requested content Different extensions actually correspond to different content types, so different TTLs can be set.
  • the domain name and the extension can be set together: that is, for different domain names, the content of the same extension can be set with different TTL values.
  • the content source server can record the user access log and help to ensure timely refresh of the content. .
  • the cache node can simulate the terminal to initiate a service request to the content source server, so that the content source server is requested according to the service request.
  • the entity value information of the variable to check if the content in the cache has changed.
  • the content source server may determine, according to the information, whether the cached content is refreshed; or the If-None-Match header field carries the entity value generated by the cached content. (Etag) signature information, the content source server can determine whether the cached content has been refreshed based on the signature information.
  • the HTTP download (HTTP Get) request message sent by the cache node carries an If-Modified-Since header field or an If-None-Match header field, and the content source server can directly carry according to the If-Modified-Since header field.
  • the time information or the Etag signature information of the requested variable carried in the If-None-Match header field checks whether the content has changed. If there is no change, you can directly reply to the "304: not modified" response message, and you do not need to carry the actual data in the response message, so you can also reduce the bandwidth.
  • the cache optimization method shown in Fig. 1 once the cache node determines that the content corresponding to the first URL can be cached, the first URL and the content corresponding to the first URL are cached locally.
  • the terminal initiates the service request for the first URL again, there is no need to wait for the content source server of the SP/CP to feed back the relevant content, and only need to obtain the required content directly from the local cache device.
  • the SP/CP protects its own services and content.
  • the SP/CP In addition to not carrying the cache control header field or carrying the cache control header field to indicate no cache in the response message, the SP/CP also transforms the same one.
  • the URL of the content that is, the SP/CP, issues different URLs to different users for the same content. From the request received by the cache node, the URL of each request is different. If only the cached content is found according to the URL, it is basically a local miss.
  • the signature value can still be used to implement active caching, thereby reducing bandwidth and improving the terminal service experience.
  • the detailed implementation process is as follows.
  • the cache node calculates the signature value of the partial content after acquiring the content from the content source server, for example, calculating the signature value of the first 16 KB content and the signature value of the last 16 KB content, and the calculated signature value and content are saved locally, and are established at the same time. Correspondence between the signature value of the first 16KB content and the content In other words, in addition to indexing to the cached content according to the URL, the cached content can also be indexed according to the signature value.
  • the cache node When the cache node receives a new access request corresponding to the second URL, it searches whether the content corresponding to the requested second URL is cached locally according to the second URL, and if so, can provide the service based on the cached content. If not, the first 16 KB of content is requested from the content source server.
  • the signature value of the post 16 KB content is recalculated in the process of requesting content from the content source server and the requested content and the corresponding signature value are cached locally.
  • the locally cached content may be the content of the current service request.
  • the signature value is also calculated for the content of the last 16 KB, and the calculated signature value and the signature value of the last 16 KB content of the locally cached content indexed by the signature value of the previous 16 KB content are used. Comparison.
  • the content in addition to marking the cached content according to the URL of the original request, the content may be marked according to the signature value of the content. According to this scheme, for the hot content, even if the requested URL is different, the locally cached content can be used to provide the service after the content is identified based on the signature value.
  • the content used to calculate the signature value can be varied in many ways, such as sharding the original file, extracting partial bytes from each slice, and then calculating the signature value.
  • the cache node in addition to buffering the content included in the first response message and the first URL, the cache node establishes and caches a correspondence between the content included in the cached first response message and the first signature value. relationship. Therefore, when the cache node receives the service request of the terminal for the second URL, if the second URL is the same as the cached first URL, sending the cached first response message corresponding to the first URL to the terminal. Included content, otherwise receiving a second response message from the content source (server) based on a service request to the second URL and a correspondence between the content included in the cached first response message and the first signature value, and A second signature value of the content included in the second response message is determined.
  • the cache node compares the second signature value with the first signature value, and if the same, sends the content included in the cached first response message to the terminal, otherwise the second response message received from the content source (server) is included The entire content of the content is sent to the terminal.
  • the buffer 20 includes a processing unit 21 and a comparison unit 22.
  • the processing unit 21 is configured to receive, by the terminal, multiple service requests for the first URL, and receive multiple first response messages from the content source respectively according to the multiple service requests, where the multiple first response messages are The first control value of the content included in the plurality of first response messages is determined by not carrying the cache control header field or carrying the cache control header field indicating that the buffer is not cached.
  • the processing unit 21 may determine the first signature value according to part of the content of the content included in the first response message; or may determine the first signature value according to the entire content of the content included in the first response message.
  • the comparing unit 22 is configured to compare the plurality of the first signature values. If the same, the buffer buffers content included in the first response message and the first URL, otherwise the buffer does not cache the The content contained in the first response message.
  • the buffer of the embodiment of the present invention can determine the cached content that is cached in the local cache device based on the signature value of the requested service content, thereby reducing bandwidth and improving the terminal service experience.
  • the buffer 30 in addition to the processing unit 21 and the comparing unit 22, the buffer 30 further includes a statistical unit 23 and a determining unit 24.
  • the statistic unit 23 is configured to count the heat of the URL.
  • the determining unit 24 is configured to determine that the URL is not statically configured and is not in the blacklist when the temperature of the URL exceeds a threshold.
  • the buffer 40 in addition to the processing unit 21, the comparison unit 22, the statistical unit 23, and the determination unit 24, the buffer 40 further includes a setting unit 25.
  • the setting unit 25 is configured to set a survival for the content included in the cached first response message. Time TTL, forcibly deleting the content contained in the cached first response message when the TTL times out.
  • the buffer 50 in addition to the processing unit 21, the comparison unit 22, the statistical unit 23, the determination unit 24, and the setting unit 25, the buffer 50 further includes an analog unit 26.
  • the simulation unit 26 is configured to simulate that the terminal initiates a service request to the content source, so that the content source checks whether the content has changed according to the entity value information of the requested variable carried in the service request.
  • the buffer 60 further includes an establishing unit 27 for establishing the cached number. a correspondence between the content contained in the response message and the first signature value. Therefore, the processing unit 21 is further configured to receive a service request of the terminal for the second URL, and if the second URL is the same as the cached first URL, send the cached corresponding to the first URL to the terminal. And responding to the content included in the message, otherwise determining a second signature value of the content included in the second response message based on the service request for the second URL and the corresponding relationship receiving the second response message from the content source.
  • the comparing unit 22 is further configured to compare the second signature value with the first signature value, if the same, the buffer sends the content included in the cached first response message to the terminal, otherwise The buffer transmits the entire content of the content included in the second response message received from the content source to the terminal.
  • the buffer of the embodiment of the present invention can track the heat change of the content in real time, and cache the content that is hot and can be cached as much as possible, thereby reducing the bandwidth and improving the terminal service experience.
  • the buffer of the embodiment of the present invention continues to send a request carrying an If-Modified-Since header field or an If-None-Match header field to the content source server when the content is served by the locally forced cache content, the content source server. You can continue to keep a record of the user access logs, but you don't need to actually return the content, so it also improves the performance of the content source server.
  • FIG. 7 illustrates a system for cache optimization in accordance with an embodiment of the present invention.
  • Real-time sharing of the analysis result of whether the URL can be cached between multiple cache nodes that is, the cache policy can be shared in the entire network, thereby avoiding repeated calculation of multiple cache nodes, allowing the cached content to be cached locally as soon as possible, thereby improving the whole The performance of the cache system.
  • a cache optimization system 70 includes a plurality of buffers 71, a service management device 72, and an extensible message processing field protocol (XMPP, The Extensible Messaging and Presence Protocol) server 73.
  • the plurality of buffers 71 may be buffers as shown in FIGS. 2 to 6.
  • the XMPP server 73 can obtain the cache rule issued by the service management device 72 and the analysis result of whether the URL can be cached by each buffer 71, so that the service management device 72 can know the URL issued by each buffer 71 through the XMPP server 73.
  • the cache optimization system of the embodiment of the present invention can determine the cached content cached in the local cache device based on the signature value of the requested service content, thereby reducing bandwidth and improving the terminal service experience.
  • overall cache performance can be optimized by sharing the analysis results of various cache nodes (e.g., buffer 71).
  • the publish/subscribe model based on the XMPP protocol implements the publishing and sharing of cached analysis results.
  • the service management device 72 can act as a publisher, and can issue known cache rules to the XMPP server 73 according to the configuration; each cache node (for example, the buffer 71) can also be released as a publisher to the XMPP server 73 in real time.
  • the hierarchical analysis and induction can be configured to form a static rule and configured on all cache nodes; each cache node (for example, the buffer 71) is also a subscriber, and subscribes to the XMPP server 73 to subscribe to the service management device 72.
  • the caching rules also subscribe to the analysis results published by other cache nodes for whether the URL can be cached.
  • a cache node for example, the buffer 71
  • the cache can be directly cached locally without the calculation check after the heat reaches the threshold. Whether it is consistent; if a cache node (for example, the buffer 71) receives a URL from another cache node and cannot cache it, the URL is directly placed in the blacklist that cannot be cached.
  • the disclosed systems, devices, and methods may be implemented in other ways.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not executed.
  • the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be electrical, mechanical or otherwise.
  • the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solution of the embodiment.
  • each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the functions, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium.
  • the technical solution of the present invention which is essential to the prior art or part of the technical solution, may be embodied in the form of a software product stored in a storage medium, including
  • the instructions are used to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and the like, which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明实施例提供了缓存优化的方法、缓存器和缓存优化的系统。其中，缓存优化的方法包括：缓存节点接收终端对第一统一资源定位符URL的多个业务请求，并基于所述多个业务请求从内容源分别接收多个第一响应消息，当所述多个第一响应消息中均不携带缓存控制头域或者携带的缓存控制头域指示不缓存，分别确定所述多个第一响应消息中包含的内容的第一签名值；缓存节点比较多个所述第一签名值，如果相同，则缓存所述第一响应消息中包含的内容以及所述第一URL，如果不相同，不缓存所述第一响应消息中包含的内容。本发明实施例的缓存优化的方法、缓存器和缓存优化的系统可以基于请求的业务内容的签名值确定缓存在本地缓存设备中的缓存内容，从而降低带宽，提升终端业务体验。

Description

緩存优化的方法、 緩存器和緩存优化的系统 技术领域
本发明实施例涉及通信领域， 并且更具体地， 涉及緩存优化的方法、 緩 存器和緩存优化的系统。 背景技术 户数、 互联网应用种类、 网络带宽等都呈现出爆炸式的增长。 这些应用给客 户带来丰富的互联网体验， 但是也导致了网络流量激增。 网络的运营者和管 理者为了满足不断增长的用户需求， 主要采用扩容带宽、 控制流量、 引入网 络緩存（ web cache )、 引入内容源等方法。 相比于扩容带宽、 流量控制、 引 入网络緩存、 引入内容源带来的有限改善， 电信运营商还可以选择在网络中 部署緩存节点对热门的内容进行緩存，从而以降低带宽的方式实现低成本运 营并提升服务质量， 即运营商主动在其网络中部署 OTT ( over the top )緩存 节点。
通常， 将 OTT緩存节点部署在网络的互联网出口旁边， 在路由器上部 署策略路由， 将超级文本传送协议（ HTTP, Hyper Text Transport Protocol ) 业务路由到緩存节点上， 如果緩存节点上緩存有终端所请求的内容， 则由緩 存节点直接提供服务， 如果緩存节点上没有緩存终端所请求的内容， 则由緩 存节点代理终端向内容源请求内容后再交付给终端。
OTT緩存节点在通过 HTTP协议从内容源获取到内容后， 如果发现内容 源返回的 HTTP响应消息中携带的緩存控制头域表明内容可以緩存， 则根据 緩存控制头域来緩存内容； 如果发现内容源返回的 HTTP响应消息中没有携 带緩存控制头域或者携带的緩存控制头域指示不緩存， 则默认对内容不做緩 存。
一般而言， 业务提供商 I内容提供商 （ SP/CP , service provider/content provider ) 出于保护自己业务和内容的考虑， 不倾向让运营商的网络对自己 的内容进行緩存， 因此在响应消息中经常默认不携带緩存控制头域或者携带 緩存控制头域指示不緩存。 那么， OTT緩存节点如果总是按照緩存控制头域 来决定内容的緩存和刷新将会导致緩存的效果差， 大量的业务请求仍然需要 上到内容源， 起不到降低带宽以及提升终端业务体验的效果。
或者， 运营商对 SP/CP提供的流量比较大的内容离线进行是否可以緩存 的分析， 再将分析结果作为策略配置到 OTT緩存节点上。 但是， 配置策略的 刷新不够灵活及时， 因此不能快速跟踪业务的变化， 一旦内容源修改规则， 则可能影响其服务质量。 发明内容
本发明实施例提供了緩存优化的方法、 緩存器和緩存优化的系统， 能够 避免完全根据 HTTP响应头中的緩存控制头域来决定是否緩存而影响服务质 量的问题。
一方面， 提供了一种緩存优化的方法， 包括： 接收终端对第一统一资源 定位符 （URL, Uniform Resource Locator ) 的多个业务请求， 并基于所述多 个业务请求从内容源分别接收多个第一响应消息， 当所述多个第一响应消息 中均不携带緩存控制头域或者携带的緩存控制头域指示不緩存，分别确定所 述多个第一响应消息中包含的内容的第一签名值； 比较多个所述第一签名 值， 如果相同， 则緩存所述第一响应消息中包含的内容以及所述第一 URL, 如果不相同， 不緩存所述第一响应消息中包含的内容。
另一方面， 提供了一种緩存器， 包括： 处理单元， 用于接收终端对第一 URL的多个业务请求，并基于所述多个业务请求从内容源分别接收多个第一 响应消息， 当所述多个第一响应消息中均不携带緩存控制头域或者携带的緩 存控制头域指示不緩存， 分别确定所述多个第一响应消息中包含的内容的第 一签名值； 比较单元， 用于比较多个所述第一签名值， 如果相同， 则所述緩 存器緩存所述第一响应消息中包含的内容以及所述第一 URL, 如果不相同， 所述緩存器不緩存所述第一响应消息中包含的内容。
又一方面， 提供了一种緩存优化的系统， 包括： 多个緩存器； 业务管理 装置； 可扩展消息处理现场协议 XMPP服务器，用于获取所述业务管理装置 发布的緩存规则以及每个所述緩存器发布的对 URL是否可以緩存的分析结 果，以便所述业务管理装置通过所述 XMPP服务器获知每个所述緩存器发布 的对统一资源定位符 URL是否可以緩存的分析结果， 以及每个所述緩存器 通过所述 XMPP服务器获知所述业务管理装置发布的緩存规则和其他緩存 器发布的对所述 URL是否可以緩存的分析结果。 本发明实施例的緩存优化的方法、緩存器和緩存优化的系统可以基于请 求的业务内容的签名值确定緩存在本地緩存设备中的緩存内容，从而降低带 宽， 提升终端业务体验。 附图说明
为了更清楚地说明本发明实施例的技术方案， 下面将对实施例或现有技 术描述中所需要使用的附图作筒单地介绍， 显而易见地， 下面描述中的附图 仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造 性劳动的前提下， 还可以根据这些附图获得其他的附图。
图 1是根据本发明实施例的緩存优化的方法的流程图。
图 2是根据本发明实施例的緩存器的结构示意图。
图 3是根据本发明另一实施例的緩存器的结构示意图。
图 4是根据本发明又一实施例的緩存器的结构示意图。
图 5是根据本发明再一实施例的緩存器的结构示意图。
图 6是根据本发明又一实施例的緩存器的结构示意图。
图 7是根据本发明实施例的緩存优化的系统的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行 清楚、 完整地描述， 显然， 所描述的实施例是本发明一部分实施例， 而不是 全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作出创 造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
本发明实施例提供一种緩存优化的方法， 即一种对内容主动緩存的方 法， 实现筒单， 且对终端、 内容源和运营商透明。 通过本发明实施例的方法 可以自动对热门的统一资源定位符 ( URL, Uniform Resource Locator )进行 自动分析， 通过分析对应 URL的多次请求的响应消息来判断内容是否可以 緩存。 此外， 还可以根据实际内容的签名值来识别緩存的内容， 因此即使在 URL变化时也可以提升緩存内容的比率，让热度相对较高的实际可以緩存的 内容在緩存节点上緩存下来，从而起到降低带宽，提升终端业务体验的效果。 并且本发明的方案可以快速跟踪业务的变化， 让热门的内容尽快终结在本 地。
以下将结合图 1具体描述根据本发明实施例的緩存优化的方法。
通过在路由器上配置策略路由 （PBR, Policy-Based Routing )将用户访 问外网服务器的流量通过 PBR转向緩存节点， 从而将 HTTP流量从路由器引 流到緩存节点， 然后再由緩存节点代理用户去外网服务器下载内容后提供给 用户。 也就是， 用户的 HTTP访问请求通过 PBR牵引到緩存节点； 如果緩存 节点本地没有緩存用户所请求的内容， 则代理用户向外网服务器发起 HTTP 访问请求； 外网服务器依据 HTTP访问请求返回响应消息给緩存节点； 緩存 节点再将响应消息返回给用户。
在緩存节点为用户提供内容交付的过程中，对于收到的每个 HTTP请求， 如果本地没有緩存对应的内容， 则需要向 SP/CP的内容源服务器请求内容。 对于从内容源服务器收到的响应消息， 緩存节点需要检查其緩存控制头域， 如果緩存控制头域携带可以緩存的头域， 则可以直接緩存在緩存节点本地， 对于响应消息不携带緩存控制头域或者携带的緩存控制头域指示不緩存时， 则緩存节点对热门的 URL进行分析来判断响应消息包含的内容是否可以緩 存。
在图 1中， 緩存优化的方法包括以下步骤：
11 , 緩存节点接收终端对第一统一资源定位符 URL的多个业务请求， 并基于该多个业务请求从内容源（例如， 内容源服务器）分别接收多个第一 响应消息，如果该多个第一响应消息中均不携带緩存控制头域或者携带的緩 存控制头域指示不緩存，分别确定该多个第一响应消息中包含的内容的第一 签名值。
也就是说， 当终端向緩存节点发起对第一 URL的业务请求， 緩存节点 从内容源分别接收第一响应消息，如果该第一响应消息中不携带緩存控制头 域或者携带的緩存控制头域指示不緩存， 则緩存节点确定该第一响应消息中 包含的内容的第一签名值。 可以理解， 第一签名值可以针对第一响应消息中 包含的内容的全部内容或者部分内容而确定。 此时， 緩存节点中并不保存该 第一 URL及其对应的内容。 如果终端之后还多次向緩存节点发起对第一 URL的业务请求，緩存节点依然按照对应的内容计算多个第一签名值。此时， 緩存节点仍然不保存该第一 URL及其对应的内容。
通常， 由于终端向緩存节点发起的业务请求很多， 因此涉及的 URL也 很多。 优选地， 可以在緩存节点接收终端对第一 URL的多个业务请求之前， 首先统计该第一 URL的热度， 如果该第一 URL的热度没有达到阈值， 则緩 存节点无需考虑保存该第一 URL及其对应的业务内容， 只有当该第一 URL 的热度超出阈值， 并且确定该第一 URL未被静态配置以及未在黑名单中， 才进行上述计算第一签名值的操作。 这样， 緩存节点主动对访问热度高的 URL进行分析， 比较多次请求的结果， 如果一致则强制本地緩存， 如果不一 致则不緩存并且令该 URL进入不緩存黑名单， 就可以避免重复分析。
由上可知， 当緩存节点确定了多个第一签名值时， 可以针对同一个第一 URL的多个第一签名值确定是否緩存该第一 URL及其对应的内容。
12, 緩存节点比较多个所述第一签名值， 如果相同， 则緩存第一响应消 息中包含的内容以及该第一 URL,否则，不緩存第一响应消息中包含的内容。
一旦緩存节点确定对应于第一 URL 的内容可以被緩存， 则将该第一 URL 以及对应于第一 URL 的内容緩存在本地。 当终端再次发起对该第一 URL的业务请求时， 就无需等待 SP/CP的内容源服务器反馈有关内容了， 而只需直接从本地緩存设备中获取所需内容。 也就是说， 本发明实施例的緩 存优化的方法可以基于请求的业务内容的签名值确定緩存在本地緩存设备 中的緩存内容， 从而降低带宽， 提升终端业务体验。
具体而言， 对于某个 URL (例如， 第一 URL )访问请求， 如果内容源服 务器返回的响应消息中不携带緩存控制头域或者携带的緩存控制头域指示 不緩存， 则緩存节点不緩存从内容源服务器获得的响应消息携带的内容， 但 是緩存节点基于访问次数实时统计该第一 URL的热度。 当第一 URL的热度到 达设定的阈值（threshold )后， 检查针对该第一 URL是否有静态配置的緩存 策略可以匹配上， 如果有则可以按照对应的静态策略来处理。 所谓静态配置 是指， 如果明确地知道有些 URL是属于动态 URL而不能緩存， 就可以针对这 些 URL配置静态的緩存策略明确对这些 URL不緩存。 当緩存节点确定该第一 URL没有静态配置的緩存策略， 则检查该第一 URL是否在不緩存的黑名单 中， 如果在黑名单中则不进行后续处理， 否则继续进行如下处理：
当緩存节点又收到对应该第一 URL的业务请求后， 由于本地没有緩存对 应的内容， 緩存节点仍然需要从内容源服务器获取内容。 在从内容源服务器 获取内容的过程中， 针对本次获取到的内容生成签名值， 生成签名值的算法 可以有多种选择， 如消息摘要算法第五版（MD5 , Message Digest Algorithm 5 )或者是安全散列算法（SHA, Secure Hash Algorithm )。 计算签名值时可 以针对内容源服务器返回的整个内容进行计算而生成单个签名值，也可以为 了减少计算量对内容进行抽样生成单个或者多个签名值， 例如只是使用返回 内容的前 16KB ( Kbyte ) 的内容计算签名值， 或者对前 16KB和最后的 16KB 都分别计算签名值。计算得到的签名值作为从内容源服务器获取的内容属性 当緩存节点又收到对应该第一 URL的业务请求后， 由于本地没有緩存对应的 内容， 緩存节点仍然需要从内容源服务器获取内容。 在从内容源服务器获取 内容的过程中采用上述算法计算签名值， 并将本次计算的签名值和之前计算 的签名值进行比较。 如果连续多次（例如， 2次或 3次）从内容源服务器下载 的内容的签名值的比较结果都一致时， 则认为对应该第一 URL的内容可以緩 第一 URL的业务请求就可以利用緩存在本地的内容直接提供服务。如果出现 签名值结果不一致， 例如连续两次计算的签名值不一致， 说明每次从内容源 服务器获取的内容存在差异， 因此对该第一 URL的内容不能在本地緩存， 则 该第一 URL需要进入到不緩存的黑名单中或者降低该第一 URL的热度统计 值， 避免进行后续的是否可以緩存的判断处理。
为了进一步优化上述的緩存方法， 可以为所緩存的第一响应消息中包含 的内容设置生存时间 TTL ( Time To Live ), 以便当所述 TTL超时时， 强制 删除所緩存的第一响应消息中包含的内容。 具体而言， 对于本地緩存下来的 内容设置不同的 TTL值。 当 TTL超时时， 强制删除本地緩存的内容， 当收 到新的业务请求时重新从内容源服务器请求内容。这样,可以避免实际内容发 生小的变化而根据部分内容技术的签名值仍然一致的低概率事件，从而确保 緩存的内容与内容源服务器上的内容相一致。
其中， 设置 TTL可以基于如下的原则。 根据不同的域名设置： 例如对于 主要提供视频内容的域名，其内容的变化频度低， 因此可以设置较长的 TTL; 对于主要提供资讯的域名， 其内容的变化频度较高， 因此设置的 TTL相对要 短一些。 根据所请求内容的扩展名来设置： 不同的扩展名实际对应不同的内 容类型， 因此可以设置不同的 TTL。 当然可以将域名和扩展名结合起来设置： 即针对不同的域名， 相同扩展名的内容可以设置不同的 TTL值。
在用本地强制緩存的内容提供服务时， 继续向内容源服务器发送携带 "如果被修改（ If-Modified-Since )"头域或者 "如果不匹配（ If-None-Match )" 头域的请求， 让内容源服务器能记录用户访问日志， 同时有利于保证内容的 及时刷新。
因为在有些场景下， SP/CP需要看到原始用户的请求从而收集用户的访 问日志， 这时緩存节点可以模拟终端向内容源服务器发起业务请求， 以便内 容源服务器根据业务请求中携带的被请求变量的实体值信息来检查緩存中 的内容是否发生了变化。
例如，在 If-Modified-Since头域携带緩存的内容生成的时间信息， 内容源 服务器可以根据该信息判断緩存的内容是否刷新过；或者 If-None-Match头域 携带緩存的内容生成的实体值（Etag )签名信息， 内容源服务器可以根据该 签名信息判断緩存的内容是否刷新过。
具体而言， 在緩存节点发送的 HTTP下载（HTTP Get )请求消息中携带 If-Modified-Since头域或者 If-None-Match头域， 内容源服务器可以直接根据 If-Modified-Since头域携带的时间信息或者 If-None-Match头域携带的被请求 变量的 Etag签名信息来检查内容是否发生了变化。 如果没有发生变化， 可 以直接回复 "304: not modified (没有修改）" 响应消息， 在响应消息中不用 携带实际的数据， 因此同样可以降低带宽。
根据如图 1所示的緩存优化的方法，一旦緩存节点确定对应于第一 URL 的内容可以被緩存， 则将该第一 URL以及对应于第一 URL的内容緩存在本 地。 当终端再次发起对该第一 URL的业务请求时， 就无需等待 SP/CP的内 容源服务器反馈有关内容了， 而只需直接从本地緩存设备中获取所需内容。
然而， 在部署实际业务时， SP/CP出于保护自己业务和内容的考虑， 除 了在响应消息中默认不携带緩存控制头域或者携带緩存控制头域指示不緩 存外， 还会变换针对同一个内容的 URL, 即 SP/CP针对同一个内容向不同的 用户发布不同的 URL。 从緩存节点收到的请求来看， 每个请求的 URL都不一 样， 如果只是根据 URL去查找緩存的内容则基本都是本地不命中。
针对上述情况， 仍然可以利用签名值来实现主动緩存， 从而降低带宽， 提升终端业务体验， 详细实现流程如下。
首先，緩存节点从内容源服务器获取到内容后同时计算部分内容的签名 值， 例如计算前 16KB内容的签名值和后 16KB内容的签名值， 计算得到的签 名值和内容都保存在本地， 同时建立前 16KB内容的签名值与内容的对应关 系， 即除了可以根据 URL索引到緩存的内容之外， 也可以根据签名值索引到 緩存的内容。
当緩存节点收到对应第二 URL的新的访问请求时，将根据第二 URL查找 本地是否緩存有与请求的第二 URL对应的内容，如果有则可以基于緩存的内 容提供服务。如果没有则先向内容源服务器请求前 16KB的内容,请求前 16KB 的内容可以通过在 HTTP Get请求消息中携带范围 （Range ) 头域指示请求范 围来实现， 例如： Range: bytes=0- 16383。
在緩存节点收到前 16KB的内容后， 对这 16KB的内容计算签名值， 将计 算出来的签名值作为索引查找本地緩存的内容，如果没有找到匹配的结果则 说明本地没有緩存所请求的内容， 因此需要从内容源服务器继续请求剩下的 内容交付给终端， 请求剩下的内容可以通过在 HTTP Get请求消息中携带 Range头域指示请求范围来实现， 例如： Range: bytes=16384-。 在从内容源服 务器请求内容的过程中再计算后 16KB内容的签名值并将请求的内容和对应 的签名值緩存在本地。
如果找到有本地緩存的内容的签名值和本次计算出来的前 16KB的内容 的签名值一样， 则说明本地緩存的内容可能就是本次业务请求的内容。 为了 确认可以做进一步的校验和核实， 緩存节点再向内容源服务器请求最后 16KB的内容，这也可以通过在 HTTP Get请求消息中携带 Range头域指示请求 范围来实现，例如： Range: bytes=-16384。在緩存节点收到后 16KB的内容后， 对后 16KB的内容也计算签名值， 将计算出来的签名值和之前根据前 16KB内 容的签名值索引到的本地緩存内容的后 16KB内容的签名值进行比较。 如果 一致，则说明可以利用本地緩存的内容来为终端用户提供服务，如果不一致， 则说明本地没有緩存所请求的内容， 因此需要从内容源服务器继续请求剩下 的内容交付给终端， 请求剩下的内容可以通过在 HTTP Get请求消息中携带 Range头域指示请求范围来实现， 例如： Range: bytes= 16384-。
通过上面的描述可以看出， 除了可以根据原始请求的 URL来标示緩存的 内容之外， 还可以根据内容的签名值来标示内容。 按照这种方案处理时， 对 于热点内容， 即使请求的 URL不同， 在根据签名值识别出来内容之后还是可 以利用本地緩存的内容来提供服务。
在实际应用中， 如果为了提升性能， 后 16KB内容对应的签名值的生成 和校验也可以省略，即只是根据前面 16KB内容的签名值来识别内容。 当然， 实际中用来计算签名值的内容可以有多种变化方式， 例如将原始文件分片， 从每片中抽取部分字节组合到一起再计算签名值。
综上所述，可选地， 除了緩存第一响应消息中包含的内容以及第一 URL 外，緩存节点建立并緩存所緩存的第一响应消息中包含的内容与第一签名值 之间的对应关系。 因此， 当緩存节点接收到终端对第二 URL的业务请求时， 如果该第二 URL与所緩存的第一 URL相同， 则向终端发送对应于该第一 URL的所緩存的第一响应消息中包含的内容， 否则基于对第二 URL的业务 请求以及所緩存的第一响应消息中包含的内容与第一签名值之间的对应关 系从所述内容源（服务器）接收第二响应消息， 并确定该第二响应消息中包 含的内容的第二签名值。緩存节点比较第二签名值与第一签名值，如果相同， 则将所緩存的第一响应消息中包含的内容发送给终端， 否则将从内容源（服 务器）接收的第二响应消息中包含的内容的全部内容发送给终端。
图 2中示出了根据本发明实施例的緩存器。 在图 2中， 緩存器 20包括 处理单元 21和比较单元 22。 其中， 处理单元 21用于接收终端对第一 URL 的多个业务请求， 并基于所述多个业务请求从内容源分别接收多个第一响应 消息， 当所述多个第一响应消息中均不携带緩存控制头域或者携带的緩存控 制头域指示不緩存， 分别确定所述多个第一响应消息中包含的内容的第一签 名值。 例如， 处理单元 21可以依据所述第一响应消息中包含的内容的部分 内容确定第一签名值； 或者可以依据所述第一响应消息中包含的内容的全部 内容确定第一签名值。 比较单元 22用于比较多个所述第一签名值， 如果相 同， 则所述緩存器緩存所述第一响应消息中包含的内容以及所述第一 URL, 否则所述緩存器不緩存所述第一响应消息中包含的内容。
因此， 本发明实施例的緩存器可以基于请求的业务内容的签名值确定緩 存在本地緩存设备中的緩存内容， 从而降低带宽， 提升终端业务体验。
图 3中示出了根据本发明另一实施例的緩存器。 在图 3中， 除了处理单 元 21和比较单元 22, 緩存器 30还包括统计单元 23和确定单元 24。 其中， 统计单元 23用于统计所述 URL的热度。确定单元 24用于当所述 URL的热 度超出阈值时， 确定所述 URL未被静态配置以及未在黑名单中。
图 4中示出了根据本发明又一实施例的緩存器。 在图 4中， 除了处理单 元 21、 比较单元 22、 统计单元 23和确定单元 24, 緩存器 40还包括设置单 元 25。 该设置单元 25用于为所緩存的第一响应消息中包含的内容设置生存 时间 TTL, 以便当所述 TTL超时时， 强制删除所緩存的第一响应消息中包 含的内容。
图 5中示出了根据本发明再一实施例的緩存器。 在图 5中， 除了处理单 元 21、 比较单元 22、 统计单元 23、 确定单元 24和设置单元 25, 緩存器 50 还包括模拟单元 26。 该模拟单元 26用于模拟终端向所述内容源发起业务请 求， 以便所述内容源根据所述业务请求中携带的被请求变量的实体值信息来 检查内容是否发生了变化。
图 6中示出了根据本发明又一实施例的緩存器。 在图 6中， 除了处理单 元 21、 比较单元 22、 统计单元 23、 确定单元 24、 设置单元 25和模拟单元 26,緩存器 60还包括建立单元 27,该建立单元 27用于建立所緩存的第一响 应消息中包含的内容及所述第一签名值之间的对应关系。 由此，处理单元 21 进一步用于接收终端对第二 URL的业务请求，如果所述第二 URL与所緩存 的第一 URL相同， 则向终端发送对应于所述第一 URL的所緩存的第一响应 消息中包含的内容， 否则基于对第二 URL的业务请求以及所述对应关系从 所述内容源接收第二响应消息，确定所述第二响应消息中包含的内容的第二 签名值。 比较单元 22进一步用于比较所述第二签名值与所述第一签名值， 如果相同， 则所述緩存器将所緩存的第一响应消息中包含的内容发送给所述 终端， 否则所述緩存器将从所述内容源接收的第二响应消息中包含的内容的 全部内容发送给终端。
综上所述， 本发明实施例的緩存器可以实时跟踪内容的热度变化， 将热 度高并且实际可以緩存的内容尽可能本地緩存下来， 从而起到降低带宽， 提 升终端业务体验的效果。 此外， 本发明实施例的緩存器在用本地强制緩存的 内容提供服务时， 根据需要继续向内容源服务器发送携带 If-Modified-Since 头域或者 If-None-Match头域的请求， 内容源服务器可以继续保持对用户访问 日志的记录，但是不需要实际返回内容，因此也提升了内容源服务器的性能。
图 7示出了根据本发明实施例的緩存优化的系统。在多个緩存节点之间 实时共享对 URL是否可以緩存的分析结果， 即整个网络中能共享緩存策略， 从而避免多个緩存节点的重复计算， 让能緩存的内容尽快緩存到本地， 进而 提升整个緩存系统的性能。
例如， 如图 7所示， 根据本发明实施例的緩存优化的系统 70包括多个 緩存器 71、 业务管理装置 72 和可扩展消息处理现场协议 （XMPP, The Extensible Messaging and Presence Protocol )服务器 73。 其中, 多个緩存器 71可以是如图 2至图 6所示的緩存器。 XMPP服务器 73 , 可以获取业务管 理装置 72发布的緩存规则以及每个緩存器 71发布的对 URL是否可以緩存 的分析结果， 以便业务管理装置 72通过 XMPP服务器 73获知每个緩存器 71发布的对 URL是否可以緩存的分析结果，以及每个緩存器 71通过 XMPP 服务器 73 获知业务管理装置 72发布的緩存规则和其他緩存器发布的对该 URL是否可以緩存的分析结果。 因此，本发明实施例的緩存优化的系统可以 基于请求的业务内容的签名值确定緩存在本地緩存设备中的緩存内容，从而 降低带宽， 提升终端业务体验。
在实际中， 可以通过共享各个緩存节点（例如，緩存器 71 )的分析结果， 从而优化整体緩存性能。 例如， 基于 XMPP协议的发布 /订阅模型来实现緩存 分析结果的发布和共享。 具体而言， 业务管理装置 72可以作为发布者， 可以 根据配置向 XMPP服务器 73发布已知的緩存规则； 每个緩存节点（例如， 緩 存器 71 )也可以作为发布者， 向 XMPP服务器 73实时发布该緩存节点对 URL 是否可以緩存的分析结果； 业务管理装置 72同时也作为订阅者， 向 XMPP服 务器 73订阅其它緩存节点实时发布的对 URL是否可以緩存的分析结果， 这些 结果可以帮助运营商进行更深层次的分析和归纳， 最终可以形成静态规则而 配置到所有的緩存节点上； 每个緩存节点（例如， 緩存器 71 ) 同时也都是作 为订阅者， 向 XMPP服务器 73订阅业务管理装置 72下发的緩存规则， 同时也 订阅其它緩存节点发布的对 URL是否可以緩存的分析结果。 例如， 如果一个 緩存节点（例如， 緩存器 71 )从其它緩存节点收到某个 URL可以緩存而本地 目前是作为不能緩存处理的， 则在热度达到阈值后可以直接緩存在本地而不 用计算校验是否一致； 如果一个緩存节点（例如， 緩存器 71 )从其它緩存节 点收到某个 URL不可以緩存则直接将该 URL放到不能緩存的黑名单中。通过 这种多个緩存节点之间共享分析结果， 可以减少整个网络内校验比较的操 作， 从而提升了整个系统的性能。
本领域普通技术人员可以意识到， 结合本文中所公开的实施例描述的各 示例的单元及算法步骤， 能够以电子硬件、 或者计算机软件和电子硬件的结 合来实现。 这些功能究竟以硬件还是软件方式来执行， 取决于技术方案的特 定应用和设计约束条件。 专业技术人员可以对每个特定的应用来使用不同方 法来实现所描述的功能， 但是这种实现不应认为超出本发明的范围。 所属领域的技术人员可以清楚地了解到， 为描述的方便和筒洁， 上述描 述的系统、 装置和单元的具体工作过程， 可以参考前述方法实施例中的对应 过程， 在此不再赘述。
在本申请所提供的几个实施例中， 应该理解到， 所揭露的系统、 装置和 方法， 可以通过其它的方式实现。 例如， 以上所描述的装置实施例仅仅是示 意性的， 例如， 所述单元的划分， 仅仅为一种逻辑功能划分， 实际实现时可 以有另外的划分方式， 例如多个单元或组件可以结合或者可以集成到另一个 系统， 或一些特征可以忽略， 或不执行。 另一点， 所显示或讨论的相互之间 的耦合或直接耦合或通信连接可以是通过一些接口， 装置或单元的间接耦合 或通信连接， 可以是电性， 机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作 为单元显示的部件可以是或者也可以不是物理单元， 即可以位于一个地方， 或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或 者全部单元来实现本实施例方案的目的。
另外， 在本发明各个实施例中的各功能单元可以集成在一个处理单元 中， 也可以是各个单元单独物理存在， 也可以两个或两个以上单元集成在一 个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使 用时， 可以存储在一个计算机可读取存储介质中。 基于这样的理解， 本发明 的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部 分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质 中， 包括若干指令用以使得一台计算机设备（可以是个人计算机， 服务器， 或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。 而前 述的存储介质包括： U盘、移动硬盘、只读存储器（ ROM, Read-Only Memory )、 随机存取存储器（RAM, Random Access Memory ), 磁碟或者光盘等各种可 以存储程序代码的介质。
以上所述， 仅为本发明的具体实施方式， 但本发明的保护范围并不局限 于此， 任何熟悉本技术领域的技术人员在本发明揭露的技术范围内， 可轻易 想到变化或替换， 都应涵盖在本发明的保护范围之内。 因此， 本发明的保护 范围应所述以权利要求的保护范围为准。

Claims

权利要求
1、 一种緩存优化的方法， 其特征在于， 包括：
接收终端对第一统一资源定位符 URL的多个业务请求， 并基于所述多 个业务请求从内容源分别接收多个第一响应消息， 当所述多个第一响应消息 中均不携带緩存控制头域或者携带的緩存控制头域指示不緩存，分别确定所 述多个第一响应消息中包含的内容的第一签名值；
比较多个所述第一签名值， 如果相同， 则緩存所述第一响应消息中包含 的内容以及所述第一 URL,如果不相同， 不緩存所述第一响应消息中包含的 内容。
2、 根据权利要求 1所述的方法， 其特征在于， 在所述接收终端对第一 统一资源定位符 URL的多个业务请求之前， 还包括：
统计所述第一 URL的热度；
如果所述第一 URL的热度超出阈值，确定所述第一 URL是否被静态配 置以及是否在黑名单中。
3、 根据权利要求 1或 2所述的方法， 其特征在于， 所述分别确定所述 多个第一响应消息中包含的内容的第一签名值包括：
确定所述第一响应消息中包含的内容的部分内容的第一签名值； 或者 确定所述第一响应消息中包含的内容的全部内容的第一签名值。
4、 根据权利要求 1至 3中任一项所述的方法， 其特征在于， 在所述緩 存所述第一响应消息中包含的内容之后， 还包括：
为所述緩存的第一响应消息中包含的内容设置生存时间 TTL, 以便当所 述 TTL超时时， 强制删除所述緩存的第一响应消息中包含的内容。
5、 根据权利要求 1至 4中任一项所述的方法， 其特征在于， 还包括： 模拟终端向所述内容源发起业务请求， 以便所述内容源根据所述业务请 求中携带的被请求变量的实体值信息检查緩存的内容是否发生了变化。
6、 根据权利要求 1至 5中任一项所述的方法， 其特征在于， 还包括： 建立所述緩存的第一响应消息中包含的内容及所述第一签名值之间的 对应关系。
7、 根据权利要求 6所述的方法， 其特征在于， 还包括：
接收终端对第二 URL的业务请求，如果所述第二 URL与緩存的所述第 一 URL相同， 则向所述终端发送对应于所述第一 URL的所述緩存的第一响 应消息中包含的内容， 否则， 基于对所述第二 URL的业务请求以及所述对 应关系从所述内容源接收第二响应消息，确定所述第二响应消息中包含的内 容的第二签名值；
比较所述第二签名值与所述第一签名值， 如果相同， 则将所述緩存的第 一响应消息中包含的内容发送给所述终端， 如果不相同， 将从所述内容源接 收的第二响应消息中包含的内容的全部内容发送给所述终端。
8、 一种緩存器， 其特征在于， 包括：
处理单元， 用于接收终端对第一统一资源定位符 URL的多个业务请求， 并基于所述多个业务请求从内容源分别接收多个第一响应消息， 当所述多个 第一响应消息中均不携带緩存控制头域或者携带的緩存控制头域指示不緩 存， 分别确定所述多个第一响应消息中包含的内容的第一签名值；
比较单元， 用于比较多个所述第一签名值， 如果相同， 则所述緩存器緩 存所述第一响应消息中包含的内容以及所述第一 URL,如果不相同，所述緩 存器不緩存所述第一响应消息中包含的内容。
9、 根据权利要求 8所述的緩存器， 其特征在于， 还包括：
统计单元， 用于统计所述第一 URL的热度；
确定单元，用于如果所述第一 URL的热度超出阈值，确定所述第一 URL 是否被静态配置以及是否在黑名单中。
10、 根据权利要求 8或 9所述的緩存器， 其特征在于， 所述处理单元具 体用于：
确定所述第一响应消息中包含的内容的部分内容的第一签名值； 或者 确定所述第一响应消息中包含的内容的全部内容的第一签名值。
11、 根据权利要求 8至 10中任一项所述的緩存器， 其特征在于， 还包 括设置单元， 用于为所述緩存的第一响应消息中包含的内容设置生存时间
TTL, 以便当所述 TTL超时时， 强制删除所述緩存的第一响应消息中包含的 内容。
12、 根据权利要求 8至 11 中任一项所述的緩存器， 其特征在于， 还包 括：
模拟单元， 用于模拟终端向所述内容源发起业务请求， 以便所述内容源 根据所述业务请求中携带的被请求变量的实体值信息检查緩存的内容是否 发生了变化。
13、 根据权利要求 8至 12中任一项所述的緩存器， 其特征在于， 还包 括：
建立单元， 用于建立所述緩存的第一响应消息中包含的内容及所述第一 签名值之间的对应关系。
14、 根据权利要求 13所述的緩存器， 其特征在于，
所述处理单元进一步用于接收终端对第二 URL的业务请求， 如果所述 第二 URL与緩存的所述第一 URL相同， 则向所述终端发送对应于所述第一 URL的所述緩存的第一响应消息中包含的内容，否则，基于对所述第二 URL 的业务请求以及所述对应关系从所述内容源接收第二响应消息，确定所述第 二响应消息中包含的内容的第二签名值；
所述比较单元进一步用于比较所述第二签名值与所述第一签名值，如果 相同， 则所述緩存器将所述緩存的第一响应消息中包含的内容发送给所述终 端， 如果不相同， 所述緩存器将从所述内容源接收的第二响应消息中包含的 内容的全部内容发送给所述终端。
15、 一种緩存优化的系统， 其特征在于， 包括：
多个如权利要求 8至 14中任一项所述的緩存器；
业务管理装置；
可扩展消息处理现场协议 XMPP服务器，用于获取所述业务管理装置发 布的緩存规则以及每个所述緩存器发布的对统一资源定位符 URL是否可以 緩存的分析结果，以便所述业务管理装置通过所述 XMPP服务器获知每个所 述緩存器发布的对统一资源定位符 URL是否可以緩存的分析结果， 以及每 个所述緩存器通过所述 XMPP服务器获知所述业务管理装置发布的緩存规 则和其他緩存器发布的对所述 URL是否可以緩存的分析结果。
PCT/CN2012/070791 2012-01-31 2012-01-31 缓存优化的方法、缓存器和缓存优化的系统 WO2013113150A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201280000262.7A CN103416027B (zh) 2012-01-31 2012-01-31 缓存优化的方法、缓存器和缓存优化的系统
PCT/CN2012/070791 WO2013113150A1 (zh) 2012-01-31 2012-01-31 缓存优化的方法、缓存器和缓存优化的系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2012/070791 WO2013113150A1 (zh) 2012-01-31 2012-01-31 缓存优化的方法、缓存器和缓存优化的系统

Publications (1)

Publication Number Publication Date
WO2013113150A1 true WO2013113150A1 (zh) 2013-08-08

Family

ID=48904361

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/070791 WO2013113150A1 (zh) 2012-01-31 2012-01-31 缓存优化的方法、缓存器和缓存优化的系统

Country Status (2)

Country Link
CN (1) CN103416027B (zh)
WO (1) WO2013113150A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106789857A (zh) * 2015-11-25 2017-05-31 中国移动通信集团公司 一种信息交互方法、设备及缓存系统
CN108471355A (zh) * 2018-02-28 2018-08-31 哈尔滨工程大学 一种基于海云计算架构的物联网信息互操作方法
CN110555184A (zh) * 2019-09-06 2019-12-10 深圳市珍爱捷云信息技术有限公司 资源缓存方法、装置、计算机设备和存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105959361A (zh) * 2016-04-25 2016-09-21 乐视控股（北京）有限公司 一种任务分发方法、装置和系统
CN109788047B (zh) * 2018-12-29 2021-07-06 山东省计算中心（国家超级计算济南中心） 一种缓存优化方法及一种存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1286443A (zh) * 1999-08-28 2001-03-07 Lg情报通信株式会社 网关系统中的无线互联网业务方法
US20040010543A1 (en) * 2002-07-15 2004-01-15 Steven Grobman Cached resource validation without source server contact during validation
CN101473590A (zh) * 2006-05-05 2009-07-01 奥多比公司 用于缓存web文件的系统和方法
CN101706827A (zh) * 2009-08-28 2010-05-12 四川虹微技术有限公司 一种嵌入式浏览器文件缓存方法
CN101888349A (zh) * 2009-05-13 2010-11-17 上海即略网络信息科技有限公司 一种msn与xmpp互通网关
CN102096712A (zh) * 2011-01-28 2011-06-15 深圳市五巨科技有限公司 一种移动终端缓存控制的方法和装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1286443A (zh) * 1999-08-28 2001-03-07 Lg情报通信株式会社 网关系统中的无线互联网业务方法
US20040010543A1 (en) * 2002-07-15 2004-01-15 Steven Grobman Cached resource validation without source server contact during validation
CN101473590A (zh) * 2006-05-05 2009-07-01 奥多比公司 用于缓存web文件的系统和方法
CN101888349A (zh) * 2009-05-13 2010-11-17 上海即略网络信息科技有限公司 一种msn与xmpp互通网关
CN101706827A (zh) * 2009-08-28 2010-05-12 四川虹微技术有限公司 一种嵌入式浏览器文件缓存方法
CN102096712A (zh) * 2011-01-28 2011-06-15 深圳市五巨科技有限公司 一种移动终端缓存控制的方法和装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106789857A (zh) * 2015-11-25 2017-05-31 中国移动通信集团公司 一种信息交互方法、设备及缓存系统
CN108471355A (zh) * 2018-02-28 2018-08-31 哈尔滨工程大学 一种基于海云计算架构的物联网信息互操作方法
CN110555184A (zh) * 2019-09-06 2019-12-10 深圳市珍爱捷云信息技术有限公司 资源缓存方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CN103416027A (zh) 2013-11-27
CN103416027B (zh) 2017-06-20

Similar Documents

Publication Publication Date Title
US10873451B2 (en) Content delivery network processing method, content delivery network, device, and storage medium
US11194719B2 (en) Cache optimization
US10491657B2 (en) Network acceleration method, apparatus and device based on router device
CN107025234B (zh) 一种信息推送方法及缓存服务器
US10567332B2 (en) Content delivery network optimization system
US9418353B2 (en) Methods and systems for delivering content to differentiated client devices
US8806008B2 (en) HTML delivery from edge-of-network servers in a content delivery network (CDN)
US9838333B2 (en) Software-defined information centric network (ICN)
US20140222967A1 (en) Transparent media delivery and proxy
US20150215400A1 (en) File Upload Method And System
US20120096116A1 (en) Content distribution network using a web browser and locally stored content to directly exchange content between users
WO2017025052A1 (zh) 资源缓存方法及装置
JP2017509053A (ja) エッジプロキシを持つコンテンツデリバリネットワークアーキテクチャ
WO2017080459A1 (zh) 服务内容的缓存及提供方法、装置、系统和存储介质
CN103716391A (zh) 一种内容缓存的实现方法及路由器
KR20140044982A (ko) 홉 카운트 기반 콘텐츠 캐싱 방법 및 그 네트워크 엔티티
US8909808B2 (en) Redundancy elimination for web caching
CN105450780A (zh) 一种cdn系统及其回源方法
WO2021253889A1 (zh) 负载均衡方法、装置、代理设备、缓存设备及服务节点
WO2013155979A1 (zh) 一种处理内容路由方法及装置
CN102025595A (zh) 流量优化方法及系统
WO2013113150A1 (zh) 缓存优化的方法、缓存器和缓存优化的系统
US20190166223A1 (en) Content delivery network (cdn) for uploading, caching and delivering user content
JP6205765B2 (ja) 映像配信装置、映像配信プログラム、映像配信方法及び映像配信システム
US20160380900A1 (en) Method and apparatus for managing traffic received from a client device in a communication network

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: 12867083

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12867083

Country of ref document: EP

Kind code of ref document: A1