Once resolved, a random-value universal resource locator (RV-URL) identifies a resource on a host server and constitutes an instruction to a local device executing a network transaction to fetch the resource. Embodiments of the invention resolve and pre-fetch an RV-URL from a remote host server and then pre-position, on a client-side of a communications link to the remote server, both resolution information indicating how the RV-URL was resolved and the pre-fetched resource. Later, when the client device is executing a network transaction and encounters an RV-URL, the client device determines whether resolution information for the RV-URL is locally stored. If so, the client device uses the resolution information to resolve the RV-URL to the same value that was used during pre-fetch. The client device then sends a request for the resolved RV-URL. The request is intercepted on the client-side of the communications link, where it is determined whether a locally cached pre-fetched resource corresponds to the intercepted request. If so, the locally cached pre-fetched resource is provided to the local device as a complete response to the request, which can then be discarded.
|
1. A method of accelerating execution of a network transaction, the method comprising:
identifying, by a pre-fetch module one or more pre-fetch modules, a random-value universal resource locator (RV-URL) expected to be fetched by a client device as part of the network transaction, the identified RV-URL comprising a variable field and a random-value function;
resolving, by the pre-fetch module one or more pre-fetch modules, the identified RV-URL to produce a resolved pre-fetch RV-URL, wherein the variable field of the resolved pre-fetch RV-URL contains a random value generated by the random-value function;
pre-fetching, by the pre-fetch module one or more pre-fetch modules, a resource identified by the resolved pre-fetch RV-URL from a host server identified by the resolved pre-fetch RV-URL;
providing, to the client device, resolution information comprising the generated random value; and
providing, to the client device, the pre-fetched resource.
16. An apparatus, disposed on a server-side of a communications network, for accelerating execution of a network transaction by a client device disposed on a client-side of the communications network, the apparatus comprising:
at least one processor circuitry; and
at least one digital storage having stored therein non-transient instructions that cause the at least one processor circuitry to:
identify a random-value universal resource locator (RV-URL) expected to be fetched by the client device as part of the network transaction, the identified RV-URL comprising a variable field and a random-value function;
resolve the identified RV-URL to produce a resolved pre-fetch RV-URL, wherein the variable field of the resolved pre-fetch RV-URL contains a random value generated by the random-value function;
pre-fetch a resource identified by the resolved pre-fetch RV-URL from a host server identified by the resolved pre-fetch RV-URL;
provide, to the client device, resolution information comprising the generated random value; and
provide, to the client device, the pre-fetched resource.
2. The method of
executing the random-value function to generate the random value, and
inserting the generated random value into the variable field of the identified RV-URL.
3. The method of
the random-value function comprises a random-number function, and
the random value is a random number generated by the random-number function.
4. The method of
generating a pre-fetch request for the resource identified by the resolved pre-fetch RV-URL, and
sending the pre-fetch request to the host server.
5. The method of
6. The method of
7. The method of
8. The method of
receiving, at the pre-fetch module one or more pre-fetch modules, hints for executing the network transaction,
wherein identifying an RV-URL comprises encountering the RV-URL in the received hints.
9. The method of
the received hints comprise information from a prior execution of the network transaction, and
the identified RV-URL was used in the prior execution of the network transaction to fetch a resource.
11. The method of
12. The method of
13. The method of
14. The method of
caching the provided resolution information on a client-side of a communications link; and
caching the pre-fetched resource on the client-side of the communications link.
15. The method
the caching the provided resolution information on the client-side of the communications link comprises caching the provided resolution information at the client device; and
the caching the pre-fetched resource on a client-side of the communications link comprises caching the pre-fetched resource at a client proxy associated with the client device.
17. The apparatus of
execute the random-value function to generate the random value, and
insert the generated random value into the variable field of the identified RV-URL.
18. The apparatus of
the random-value function comprises a random-number function, and
the generated random value is a random number generated by the random-number function.
19. The apparatus of
generate a pre-fetch request for the resource identified by the resolved pre-fetch RV-URL, and
send the pre-fetch request to the host server.
20. The apparatus of
21. The apparatus of
22. The apparatus of
23. The apparatus of
receive hints for executing the network transaction,
identify the RV-URL in the received hints, and wherein
identification of the RV-URL is based on identification of the RV-URL in the received hints.
24. The apparatus of
the received hints comprise information from a prior execution of the network transaction, and
the identified RV-URL was used in the prior execution of the network transaction to fetch a resource.
25. The apparatus of
26. The apparatus of
27. The apparatus of
28. The apparatus of
0. 29. The apparatus of
the at least one processor circuitry is a processor circuitry, and
the at least one digital storage is a digital storage.
0. 30. The apparatus of
execute the random-value function to generate the random value, and
insert the generated random value into the variable field of the identified RV-URL.
0. 31. The apparatus of
the random-value function comprises a random-number function, and
the generated random value is a random number generated by the random-number function.
0. 32. The apparatus of
generate a pre-fetch request for the resource identified by the resolved pre-fetch RV-URL, and
send the pre-fetch request to the host server.
0. 33. The apparatus of
0. 34. The apparatus of
0. 35. The apparatus of
0. 36. The apparatus of
receive hints for executing the network transaction, identify the RV-URL in the received hints, and
wherein identification of the RV-URL is based on identification of the RV-URL in the received hints.
0. 37. The apparatus of
the received hints comprise information from a prior execution of the network transaction, and
the identified RV-URL was used in the prior execution of the network transaction to fetch a resource.
0. 38. The apparatus of
0. 39. The apparatus of
0. 40. The apparatus of
0. 41. The apparatus of
0. 42. The method of
0. 43. The method of
executing the random-value function to generate the random value, and
inserting the generated random value into the variable field of the identified RV-URL.
0. 44. The method of
the random-value function comprises a random-number function, and
the random value is a random number generated by the random-number function.
0. 45. The method of
generating a pre-fetch request for the resource identified by the resolved pre-fetch RV-URL, and
sending the pre-fetch request to the host server.
0. 46. The method of
0. 47. The method of
0. 48. The method of
0. 49. The method of
receiving, at the one or more pre-fetch modules, hints for executing the network transaction,
wherein the identifying the RV-URL comprises encountering the RV-URL in the received hints.
0. 50. The method of
the received hints comprise information from a prior execution of the network transaction, and
the identified RV-URL was used in the prior execution of the network transaction to fetch a resource.
0. 51. The method of
0. 52. The method of
0. 53. The method of
0. 54. The method of
0. 55. The method of
caching the provided resolution information on a client-side of a communications link; and
caching the pre-fetched resource on the client-side of the communications link.
0. 56. The method of
the caching the provided resolution information on the client-side of the communications link comprises caching the provided resolution information at the client device; and
the caching the pre-fetched resource on the client-side of the communications link comprises caching the pre-fetched resource at a client proxy associated with the client device.
|
More than one reissue application has been filed for the reissue of U.S. patent application Ser. No. 15/819,679, filed on Nov. 21, 2017, issued on Dec. 29, 2020 as U.S. Pat. No. 10,880,396, and entitled “PRE-FETCHING RANDOM-VALUE RESOURCE LOCATORS” (VS1880-US-2). The reissue applications are the present application and U.S. patent application Ser. No. 18/757,237, filed on Jun. 27, 2024, and entitled “PRE-FETCHING RANDOM-VALUE RESOURCE LOCATORS” (VS1880-US-5-REIS).
This application claims priority to and is a Reissue of U.S. patent application Ser. No. 15/819,679, filed on Nov. 21, 2017, issued on Dec. 29, 2020 as U.S. Pat. No. 10,880,396, and entitled “PRE-FETCHING RANDOM-VALUE RESOURCE LOCATORS” (VS1880-US-2).
U.S. patent application Ser. No. 15/819,679 claims the benefit of priority to U.S. provisional Patent Application Ser. No. 62/429,578, filed on Dec. 2, 2016, and entitled “PRE-FETCHING RANDOM-VALUE RESOURCE LOCATORS” (VS-0880-US).
In modern network systems, a local device (e.g., a Web browser on a personal computer) initiates a network transaction that comprises an initial request to a remote server for a parent resource (e.g., a web page). The parent resource typically includes multiple resources as well as instructions (e.g., universal resource locators (ULRs)) for requesting additional (i.e., child) resources from other remote devices. The local device executes the network transaction by executing the instructions in the parent resource. Because this can involve fetching numerous child resources from many different remote devices, it can be advantageous to pre-fetch some of the child resources so that those resources are locally stored at or near the local device by the time the local device encounters the instructions to fetch the resources while executing the parent resource.
When a child resource is identified in the parent resource by a static URL, the URL is the same each time the network transaction is executed. The child resource identified by a static URL can be pre-fetched because the URL will be the same at the time of pre-fetch as when it is later encountered in the parent resource. Similarly, dynamic URLs that resolve in predictable ways can be pre-fetched by first learning how the URL is resolved (e.g., during a prior execution of the network transaction). Then, during a subsequent execution of the network transaction, the now known manner of resolving the URL can be used to pre-fetch the resource. Although the URL is dynamic, it resolves to the same value each time it is resolved. The child resource identified by such a dynamic URL can be pre-fetched because the URL will resolve to the same value at the time of pre-fetch as when later encountered in the parent resource.
There are, however, dynamic URLs whose instructions include a function that generates a random value. Each time such a dynamic URL is resolved, it typically resolves to a different value. It has long been thought that such a dynamic URL cannot be pre-fetched because the resource it would point to during pre-fetch and then later when encountered in the parent resource are unlikely to be the same. Some embodiments of the present invention solve the foregoing problem and thus can pre-fetch even random-value URLs and/or provide other benefits.
A random-value universal resource locator (RV-URL) can comprise a variable field and a random-value function for generating a random value for the variable field. Because the variable field will likely contain a different value each time the RV-URL is resolved, it has been thought that RV-URLs cannot be pre-fetched. In some embodiments of the invention, an RV-URL is pre-fetched in anticipation of a client device later requesting the RV-URL while executing a network transaction.
An RV-URL encountered during pre-fetch can be resolved and a request (often referred to herein as a “pre-fetch request”) for a resource identified by the resolved RV-URL can be sent to the appropriate host server. The host server can then respond with the resource (often referred to herein as a “pre-fetched resource”), which can be prepositioned on the client-side of the network along with generation information indicating how the pre-fetch request was generated. The generation information can include, for example, the random value of the variable field in the resolved RV-URL.
Later, as the client device encounters RV-URLs while executing the network transaction, the client device first checks a client-side cache for generation information corresponding to the encountered RV-URL. If the client device finds such generation information, the client device uses the generation information to resolve the encountered RV-URL, which should be materially the same as the pre-fetch request previously used to obtain the pre-fetched resource from the host server. If the client device does not find corresponding generation information, the client device resolves the encountered RV-URL by calling the random-value function. Regardless of how the encountered RV-URL is resolved, the client device generates a request for the resolved RV-URL and sends the request to the appropriate host server. An interceptor on the client-side of the network intercepts resource requests and checks a client-side cache for a pre-fetched resource that corresponds to the intercepted request. If the interceptor finds such a pre-fetched resource, the interceptor sends the pre-fetched resource to the client device. If the interceptor does not find a corresponding pre-fetched resource, the interceptor forwards the intercepted resource request across the network to the host server.
This specification describes exemplary embodiments and applications of various embodiments of the invention. The invention, however, is not limited to the exemplary embodiments and applications or to the manner in which the exemplary embodiments and applications operate or are described herein. Moreover, the Figures may show simplified or partial views, and the dimensions of elements in the Figures may be exaggerated or otherwise not in proportion for clarity. In addition, as the terms “on,” “attached to,” or “coupled to” are used herein, one object (e.g., a material, a layer, a substrate, etc.) can be “on,” “attached to,” or “coupled to” another object regardless of whether the one object is directly on, attached, or coupled to the other object or there are one or more intervening objects between the one object and the other object. Also, directions (e.g., above, below, top, bottom, side, up, down, under, over, upper, lower, horizontal, vertical, “x,” “y,” “z,” etc.), if provided, are relative and provided solely by way of example and for ease of illustration and discussion and not by way of limitation. In addition, where reference is made to a list of elements (e.g., elements a, b, c), such reference is intended to include any one of the listed elements by itself, any combination of less than all of the listed elements, and/or a combination of all of the listed elements.
As used herein, “substantially” means sufficient to work for the intended purpose. If used with respect to a numerical value or range, substantially means within ten percent. The term “ones” means more than one.
As used herein, a “network resource” includes a visual (e.g., text, image, video, or the like) object, an audio object, a collection of one or more instructions (e.g., a page encoded in hypertext, a style sheet such as a cascading style sheet (CSS) for displaying and/or playing a network resource, a script file such as a JavaScript file, or the like), or a network service made available and/or provided by one device on a network to other devices upon request by one of the other devices. A “network resource” is sometimes referred to simply as a “resource.”
As used herein, a “parent” resource includes, among other elements, one or more instructions to fetch a “child” resource from a specified device. Examples of a parent resource include a web page (e.g., written in a markup language such as hypertext markup language (HTML), extensible markup language (XML), or the like), a media manifest file or other file that references other media objects (e.g., a movie, a prerecorded television show), a service providing access to a streaming media object (e.g., a podcast, a live television broadcast, streaming music, or the like) that references other media objects, a service for transferring a specified data file that references other data objects, or the like. Any of the foregoing can also be a child resource. Additional examples of child resources include images, audio files, video files, style files such as cascaded style sheets (CSS), executable scripts such as JavaScripts, and the like.
A “random-value function” is a function that produces a random or pseudorandom value. Examples of random value functions include a random number generation function, a pseudorandom number generation function, or the like.
As used herein, a “universal resource locator” specifies the location of a network resource and is sometimes abbreviated URL. In some examples, a universal resource locator comprises a “host identifier” and a “resource identifier.” The “host identifier” identifies a host server from which a network resource is to be fetched, and the “resource identifier” identifies the network resource. In some examples, the resource identifier is a path to the resource on the host server. As defined and used herein, universal resource locator includes within its meaning but is not limited to what is commonly referred to in Internet or world-wide-web applications as a universal resource locator or URL.
A “dynamic universal resource locator” is a resource locator that includes one or more variable fields and one or more instructions (e.g., function(s)) for generating values for the variable fields. “Resolving” a dynamic universal resource locator means executing the instruction(s) and inserting the resulting value(s) into the variable field(s). The term dynamic universal resource locator is sometimes abbreviated D-URL herein.
A “random-value universal resource locator” is a dynamic universal resource locator in which at least one instruction for generating a value for at least one variable field is a random-value or pseudorandom value function. A random-value universal resource locator is sometimes abbreviated RV-URL herein.
As used with reference to a URL (whether a static URL, a resolved dynamic URL, or a resolved random-value URL) “pre-fetching” or “fetching” means obtaining the resource from the host server identified by the static or resolved URL.
Some embodiments of the present invention facilitate pre-fetching even random-value resource locators (RV-URLs). As noted above, an RV-URL comprises a variable field and a random-value function and is resolved by executing the random-value function and inserting the resulting random value into the variable field. In some embodiments, when an RV-URL is encountered while attempting to pre-fetch resources likely to be needed during execution of a network transaction, the RV-URL is resolved and utilized to send a pre-fetch request to the identified host server. Resolution information indicating the manner in which the RV-URL was resolved during pre-fetch is provided to the client device. When the host server responds with the requested resource (referred to herein as the “pre-fetched resource”), the pre-fetched resource is sent to the client device, which locally caches it. Later, when the client device encounters an RV-URL as part of executing the network transaction, the client device determines whether it has received resolution information indicating how the RV-URL was resolved during pre-fetch. If so, the client device uses the resolution information to resolve the RV-URL to the same value as during pre-fetch. The client device then sends a request for the resolved RV-URL to the relevant host server. An interceptor associated with the client device intercepts the request and determines whether the requested resource has been pre-fetched and locally stored. If yes, the interceptor responds to the request with the locally stored pre-fetched resource and discards the intercepted request. If no, the interceptor forwards the intercepted request to the host server, which responds by sending the requested resource back to the client device.
A client device 102 can be a computing device such as a desktop or laptop personal computer, a smart cellular telephone, a tablet device, or the like. As such, a client device 102 can comprise any of the hardware and software modules typical of such devices. In
Each application 120 can be, for example, a software module such as one would expect to be on any of the above-mentioned computing devices. One or more of the applications 120 can be configured to execute a network transaction by initially requesting a parent resource from a host server (e.g., 150a) and then fetching additional resources identified in the parent resource from other host servers (e.g., 150b and/or 150c). A web browser is an example of such an application 120, and requesting and rendering a web page (an example of a parent resource) is an example of a network transaction. A media player is another example of an application 120, and requesting and consuming a media manifest (which is another example of a parent resource) is another example of a network transaction.
As will be seen, the resolution information cache 122, server-side pre-fetch module 124, interceptor 126, and pre-fetched cache 128 can work with the hinting service 154 and server-side pre-fetch module 152 to identify and pre-fetch one or more of the additional resources that the client device 102a may need before the client device 102a encounters instructions to fetch those resources in the parent resource. And those additional resources can be pre-fetched even if the resources are identified in the parent resource by RV-URLs.
In
The network 140 can comprise a single network of interconnected computing devices, a plurality of interconnected single networks, or the like. For example, the network 140 can comprise one or more local area networks (LANs), wide area networks (WANs), or the like. Individual networks that comprise the network 110 can be public and/or private. All or part of the network 140 can be part of the world-wide web (a.k.a. the public Internet). In some embodiments, the network 140 can be the public Internet.
Host servers 150 can store and provide network resources to other entities (e.g., a client device 102) over the network 140. Examples of host servers 150 include web page servers, media servers, email servers, file transfer protocol (FTP) servers, or the like. Examples of resources a host server 150 might provide include web pages, images, audio files, video files, text files, streaming content, or the like.
The hinting service 154 can be configured to provide services that may be used to accelerate execution of a network transaction. In some embodiments, each time a device (e.g., client device 102b) that is subscribed to the hinting service 116 completes a network transaction, the hinting service 154 collects information regarding the network transaction and generates hints that can thereafter be used by another subscribing device (e.g., client device 102a) to execute the same network transaction more efficiently and thus typically in a shorter amount of time. The pre-fetch module 152 can be configured to receive hints from the hinting service 154 for a particular network transaction and pre-fetch resources identified in the hints.
Although not shown in
When an application 120 of a client device 102a has or is expected to begin executing a network transaction in which it will fetch resources, the server-side pre-fetch module 152 can receive hints from the hinting service 154 that identify one or more of those resources. Some such resources are identified in the hints by RV-URLs. When the server-side pre-fetch module 152 encounters such RV-URLs in the hints, the server-side pre-fetch module 152 can resolve and pre-fetch the RV-URLs. For each such resolved and pre-fetched RV-URL, the server-side pre-fetch module 152 sends to the client-side pre-fetch module 124 both the pre-fetched child resource and resolution information indicating how the server-side pre-fetch module 152 resolved the RV-URL. The client-side pre-fetch module 124 can then store the resolution information in the resolution information cache 122 and the pre-fetched child resource in the pre-fetched cache 128.
Later, as the application 120 encounters RV-URLs while executing the network transaction, the application 120 resolves each RV-URL and generates a request to the appropriate host server 150. The application 120 resolves each RV-URL by determining whether resolution information previously stored in the resolution information cache 122 corresponds to the RV-URL. If yes, the application 120 uses the resolution information to resolve the RV-URL to have the same random value as the pre-fetched module 154 previously used to pre-fetch a corresponding child resource. If no, the application 120 resolves the RV-URL by executing the corresponding random-value function and inserting the resulting random value into the variable field of the RV-URL. Regardless of which way the RV-URL was resolved, the application 120 sends a request for the child resource to the host server 150 identified by the resolved RV-URL.
The interceptor 126 intercepts requests generated by the application 120 and determines whether each intercepted request corresponds to a pre-fetched child resource stored in the pre-fetched cache 128. If yes, the interceptor 126 responds to the intercepted request with the pre-fetched child resource from the pre-fetched cache 128 and discards the intercepted request. If no. the interceptor 126 forwards the intercepted request to the corresponding host server 150.
As shown, the computing device 200 can include a processor 210, a memory 220, a network interface 230, a display 240, and one or more user input device 250. Each of these components can be in communication with the other components via one or more communications buses 260. The computing device 200 illustrated in
Suitable network interfaces 230 may employ wireless Ethernet, including 802.11 a, g, b, or n standards. In one example, the network interface 230 can communicate using Radio Frequency (RF), Bluetooth, CDMA, TDMA, FDMA, GSM, Wi-Fi, satellite, or other cellular or wireless technology. In other examples, the network interface 230 may communicate through a wired connection and may be in communication with one or more networks, such as Ethernet, token ring, USB, FireWire 1394, fiber optic, etc.
Any configuration of the memory 220 and processor 210 can be such that computer readable instructions (e.g., software, microcode, firmware, or the like) are stored in memory 220 as non-transient signals. The memory 220 can be a non-transient digital memory device. Such instructions can cause the processor 210 to perform one or more functions, methods, or the like. For example, such instructions can cause the processor 210 to perform all or part of any of method 300 of
As noted, each client device 102, the client proxy 130 (if present), and the one or more computing devices on which the server-side pre-fetch module 152 and hinting service 154 operate can comprise one or more computing devices like device 200. Each application 120, the client-side pre-fetch module 124, the interceptor 126, the server-side pre-fetch module 152, and/or the hinting service 154 can thus comprise hardwired logic (not shown) and/or non-transient computer readable instructions stored in memory 220 that can be executed by the processor 210 in one or more computing devices like 200. Similarly, the pre-fetched cache 128 and the resolution information cache 122 can be part of the memory 220 or a similar memory (not shown) of one or more computing devices like 200.
The first of the examples is depicted in
The second of the examples is shown in
At block 302, an event is detected in system 100 that triggers a request to the hinting service 154 for hints for a particular network transaction. The event can be any event that indicates a client device 102a has, might, or probably will initiate the network transaction.
The following are examples of events that can trigger a client device 102a to expressly request from the hinting service 154 hints for a particular network transaction. One such example occurs when a user of an application 120 (e.g., a web browser) of device 102a selects a URL of a particular web page or resource. As another example, the trigger can be an action that indicates a probability that the user will select a URL of a particular web page or resource. An example of such an action indicating a probability the user will select a particular URL is a cursor of a user input device hovering over a selectable display of the URL on the client device 102a. Another example is an action that, due to the user's browsing history, indicates a probability that the URL will be selected by the user. For example, the browsing history may indicate that the user typically selects the URL upon or shortly after powering on the client device 102a, starting one of the applications 120, or the like.
Examples of events that can trigger another system 100 device to request hints from the hinting service 154 include the following. On such example is a request by a client device 102a to a domain name system (DNS) server. For example, a DNS request can be detected by proxy server 402, which then sends a hints request to the hinting service 154 for a network transaction associated with the DSN request. As another example, even if a client device 102a itself is not configured to request hints from the hinting service 154, a proxy server 402 can detect a request by the client device 102a to a host server 150a for a particular URL or resource, and the proxy server 402 can then request from the hinting service 154 hints associated with the network transaction that corresponds to the requested URL or resource.
As noted above, the method 300 of
In example 1 (illustrated in
In example 2 (illustrated in
At block 304, in response to the trigger detected at block 302, a request for hints associated with the particular network transaction is sent to the hinting service 154. The request for hints can originate from any of a number of possible sources including the client device 102a, a client proxy 130, the proxy server 402, or the like.
In example 1, the proxy server 402 detects the mouse hover at block 302 and sends, at block 304, a request 412 to the hinting service 154 for hints associated with rendering the web page www.example1.com. (See
Assuming the hinting service 154 has hints for the particular network transaction, the hinting service 154 responds by sending the hints, which are received at block 306. The hinting service 154 can send the hints to, which can thus be received by, any of a number of possible entities including the client device 102a, the client proxy 130, the server-side pre-fetch module 152, the proxy server 402, or the like. Alternatively, the hints can be sent to one entity on the network (e.g., the client device 102a) and also intercepted by another entity (e.g., the server-side pre-fetch module 152).
In example 1, the hinting service 154 sends hints 414 for rendering the web page www.example1.com to the proxy server 402. (See
At block 308, RV-URLs are encountered in the hints. The presence of each RV-URL in the hints indicates a possibility, a probability, or a certainty that the client device 102a will eventually resolve and request the RV-URL as part of executing the particular network transaction. Block 308 can be performed by a number of possible entities including the server-side pre-fetch module 152. Alternatively, all or part of block 308 can be performed by the client proxy 130 or the client device 102a (e.g., the server-side pre-fetch module 152, one of the applications 120, or the like). In both examples 1 and example 2, the server-side pre-fetch module 152 performs some processing of the hints (e.g., to identify and pre-fetch resources) received from the hinting service 154 and, in doing so, encounters RV-URLs in the hints. As shown in
Blocks 310 through 318 are now executed for each RV-URL identified at block 308.
At block 310, one of the RV-URLs encountered at block 308 is resolved. As discussed above, an RV-URL can comprise a host identifier and a resource identifier, which includes at least one variable field and identifies a random-value function for producing a random or pseudorandom value for the variable field. (Hereinafter, for simplicity, only the term random is used, but it is to be understood that “random” includes “pseudorandom.”) Resolving the RV-URL comprises executing the random-value function to produce a random value and then inserting the random value into the variable field.
In both examples 1 and example 2, it is assumed that the following RV-URL was encountered at block 308 in the hints for www.example1.com and the hints for www.example2.com: “hostserver150c/FILE-{variable field},” and a random number generator is identified as the function for generating a value for the variable field. In this example, “hostserver150c” is the host identifier portion of the RV-URL, “FILE-{variable field}” is the resource identifier portion, and a random number generator is the identified function.
In example 1, the server-side pre-fetch module 152 of
At block 312, a pre-fetch request for the RV-URL resolved at block 310 is generated. As noted, a resolved RV-URL points to a particular resource on a particular host. The pre-fetch request generated at block 312 can thus be a request to that particular host for the identified resource. Examples of such requests include an HTTP or HTTPS Get command.
In example 1, the pre-fetch module 152 of
At block 314, information regarding resolution of the RV-URL at block 310 is provided to the client-side pre-fetch module 124, which can store the “resolution information” in the resolution information cache 122. As will be seen, the client device 102a (e.g., the application 120 executing the network transaction) will use this resolution information to resolve the RV-URL to the same value when the RV-URL is later encountered by the client device 102a while executing the network transaction.
The resolution information may take any of a number of forms. For example, the resolution information can be the random value generated by the random-value function, the resolved RV-URL generated at block 310, the pre-fetch request generated at block 312, or the like. Moreover, the resolution information may be sent to the client device 102a in any number of possible ways. For example, the resolution information may be added to the hints received from the hinting service 154 (see block 306), which can occur prior to performing block 320. The resolution information can thus be in the hints (e.g., stored in association with the RV-URL) when the hints are sent to the client device 102a (or proxy client 130) at block 320. As another example, the resolution information may be sent directly to the client device 102a (or proxy client 130) in which case block 320 can be performed prior to block 314. Regardless, the resolution information can be cached in the resolution information cache 122.
In example 1, the server-side pre-fetch module 152 of
At block 316, the RV-URL resolved at block 310 is pre-fetched. This can be accomplished by sending the pre-fetch request generated at block 312 to the designated host server 150c. In example 1, the pre-fetch module 152 of
At block 318, a pre-fetched resource is received from the host server 150c and sent to the client-side pre-fetch module 124, where it can be cached in the pre-fetched cache 128 in anticipation of the client device 102a later requesting the pre-fetched resource while executing the network transaction. Block 318 can be accomplished by receiving the pre-fetched resource from the host server 150c to which the pre-fetch request was sent as part of block 316, and sending the received pre-fetched resource to the client-side pre-fetch module 124, which can store the pre-fetched resource in the pre-fetched resource cache 122.
In example 1, the pre-fetch module 152 of
Method 300 has now resolved an RV-URL encountered in the hints for a particular network transaction with a generated random number and pre-fetched the resolved RV-URL. Moreover, the pre-fetched resource and sufficient resolution information to resolve the RV-URL to the same value has been cached at the client device 102a and/or a client proxy 130 associated with the client device 102a.
Operation of method 300 with respect to example 1 is summarized in
Each of blocks 302-318 of method 300 can be performed by the server-side pre-fetch module 152. Alternatively, one or more of blocks 302-318 can be performed by another network entity such as client proxy 130 or one or more modules in a client device 102a.
At block 802, an application 120 of client device 102a can initiate a network transaction. As noted above, executing a network transaction can result in the application 120 receiving a parent resource from a host server (e.g., 150a) that includes instructions (e.g., URLs) to fetch additional resources from other host servers (e.g., 150b, 150c). Examples of network transactions include rendering a web page, playing a media object comprising a manifest that references other media objects, and the like. The application 120 can initiate a network transaction at block 802 by, for example, requesting a web page, a media object, or the like.
As discussed above with respect to
As also discussed above, an event in example 2 that triggers a request for hints at block 302 in
At block 804, the application 120 receives the parent resource requested at block 802. As shown in
At block 806, the application 120 identifies in the parent resource, among other elements, RV-URLs. In example 1, as the application 120 parses the parent resource 434 www.example1.com, the application 120 eventually finds the same RV-URL that was found as part of executing method 300, namely, host-server-150c/FILE-{variable field} and a random number generator for the variable field. In example 2, the application 120 eventually finds the same RV-URL in parent resource 634 www.example2.com.
Method 800 can perform blocks 808-818 for each RV-URL found at block 806.
At block 808, application 120 determines whether the RV-URL corresponds to resolution information locally stored in resolution information cache 122. Any such resolution information would have been sent from the server-side pre-fetch module 152 to the client-side pre-fetch module 124 at block 314 of
In example 1, the application 120 finds in resolution information cache 122 resolution information 422 for RV-URL host-server-150c/FILE-{variable field} indicating that it was resolved at block 310 of method 300 to host-server-150c/FILE-1593. (See
If the determination at block 808 is yes, the application 120 branches at block 810 to block 812, where the application 120 resolves the RV-URL using the cached resolution information. This can be accomplished, for example, by inserting the random number from the resolution information into the variable field of the RV-URL. The RV-URL, as resolved at block 812, should therefore be materially the same (e.g., have the same random value) as the RV-URL previously resolved at block 310 of
In example 1, the application 120 of client device 102a thus inserts the random number 1593 from resolution information cache 122 into the RV-URL found at block 806, which resolves to host-server-150c/FILE-1593. In example 2, the application 120 of the client device 102a inserts the random number 3117 from resolution information cache 122 into the RV-URL found at block 806, which resolves to host-server-150c/FILE-3117.
If the determination at block 808 is no, the application 120 branches at block 810 to block 814, where the application 120 resolves the RV-URL found at block 806 by executing the random-value function and inserting the resulting random value into the variable field of the RV-URL. This is a resolved RV-URL that has not been pre-fetched.
From block 812 or block 814, the application 120 proceeds to block 816, where the application 120 generates a request for the resolved RV-URL found at block 806. This can be accomplished generally as discussed above with respect to block 312, except that the request is not a pre-fetch but is an actual request from the application 120. At block 818, the application 120 can send the request for the resolved RV-URL to the corresponding host server 150.
In example 1, the application 120 sends the request 442 (which was generated at block 812) to host server 150c for a resource at FILE-1593. (See
Turning now to method 1100 of
The interceptor 126 can match the intercepted request to a pre-fetched response in the pre-fetched cache 128 in any of a number of ways. For example, the interceptor 126 can compare all or a portion (e.g., the random value) of the resolved RV-URL of the intercepted request to a corresponding portion of the resolved RV-URLs of the pre-fetched requests in the pre-fetched cache 128.
The interceptor 126 can then determine that a matching pre-fetched resource corresponds to the intercepted request and branch at block 1106 to block 1108, where the interceptor 126 can fulfill the intercepted request with the corresponding pre-fetched resource from the pre-fetched cache 128. Because the pre-fetched resource is thus a complete response to the intercepted request, the intercepted request can be discarded at block 1112.
In example 1, the interceptor 126 intercepts, at block 1102, the request 442 to host server 150c for the resource at FILE-1593 and finds, at block 1104, a corresponding pre-fetched resource 430 in pre-fetched cache 128 (which, as discussed above, was sent to the client device 102a as part of block 318 of
In example 2, the interceptor 126 intercepts, at block 1102, the request 642 to host server 150c for the resource at FILE-3117 and finds, at block 1104, a corresponding pre-fetched resource 630 in pre-fetched cache 128 (which, as discussed above, was sent to the client device 102a as part of block 318 of
In contrast, if the interceptor 126 determines at block 1104 that no matching pre-fetched resource is locally cached, the interceptor branches to block 1110, where the interceptor 126 forwards the intercepted request to the host server 150c to which the request is addressed. Although not shown, the host server 150c will receive the request and respond with the requested resource, which will then be received from the host server 150c by the client device 102a.
In the foregoing examples and discussions, the RV-URLs are described as identifying content resources. The RV-URLs, however, can represent any network resource or service. Pre-fetched resources can thus be any type of network resource or service.
Although specific embodiments and applications have been described in this specification, these embodiments and applications are exemplary only, and many variations are possible. In addition to any previously indicated modification, numerous other variations and alternative arrangements may be devised by those skilled in the art without departing from the spirit and scope of this description, and appended claims are intended to cover such modifications and arrangements. Thus, while the information has been described above with particularity and detail in connection with what is presently deemed to be the most practical and preferred aspects, it will be apparent to those of ordinary skill in the art that numerous modifications, including, but not limited to, form, function, manner of operation and use may be made without departing from the principles and concepts set forth herein. Also, as used herein, examples are meant to be illustrative only and should not be construed to be limiting in any manner.
Lepeska, Peter J, Tsillas, Demetrios J
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
10372780, | Feb 11 2011 | Viasat, Inc | Browser based feedback for optimized web browsing |
10484473, | Jun 28 2016 | SOLANO LABS, INC | Systems and methods for efficient distribution of stored data objects |
11176219, | Feb 11 2011 | ViaSat, Inc. | Browser based feedback for optimized web browsing |
11176223, | Oct 21 2014 | Amazon Technologies, Inc | Page rendering by an intermediary system that uses a truncated library |
5485609, | May 20 1994 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Online background predictors and prefetchers for locality management |
6055569, | Jan 27 1998 | GO AHEAD SOFTWARE INC | Accelerating web access by predicting user action |
6085193, | Sep 29 1997 | GOOGLE LLC | Method and system for dynamically prefetching information via a server hierarchy |
6301617, | Aug 25 1997 | Intel Corporation | Selection of resources utilizing virtual uniform resource locators |
6622168, | Apr 10 2000 | Rovi Technologies Corporation | Dynamic page generation acceleration using component-level caching |
6721780, | Nov 09 1999 | DIGITAL RIVER, INC | Predictive pre-download of network objects |
7113935, | Dec 06 2000 | Parallel Networks, LLC | Method and system for adaptive prefetching |
7716332, | Jun 20 2001 | Bellsouth Intellectual Property Corporation | System and method for server-based predictive caching of back-end system data |
8136089, | Jul 02 2003 | Amazon Technologies, Inc | Predictive prefetching to improve parallelization of document generation subtasks |
8224964, | Jun 30 2004 | GOOGLE LLC | System and method of accessing a document efficiently through multi-tier web caching |
8335838, | Aug 26 2009 | Microsoft Technology Licensing, LLC | Web page load time prediction and simulation |
8341245, | Sep 26 2011 | GOOGLE LLC | Content-facilitated speculative preparation and rendering |
8478843, | Mar 01 2011 | IMDB. COM, INC. | Templates with static parameter caching |
8566788, | Jul 02 2003 | Amazon Technologies, Inc | Predictive prefetching to improve parallelization of data retrieval subtasks |
9037638, | Apr 11 2011 | ViaSat, Inc.; Viasat, Inc | Assisted browsing using hinting functionality |
9083583, | Jul 01 2011 | GOOGLE LLC | Latency reduction via adaptive speculative preconnection |
9106607, | Feb 11 2011 | ViaSat, Inc.; Viasat, Inc | Browser based feedback for optimized web browsing |
9135364, | Nov 10 2011 | GOOGLE LLC | Delivery of web pages with markup for speed |
9456050, | Feb 11 2011 | ViaSat, Inc.; Viasat, Inc | Browser optimization through user history analysis |
9460229, | Oct 15 2007 | ViaSat, Inc.; Viasat, Inc | Methods and systems for implementing a cache model in a prefetching system |
9747386, | Aug 10 2012 | Amazon Technologies, Inc | User-perceived performance through browser hints |
20010047517, | |||
20020010761, | |||
20040064577, | |||
20050193096, | |||
20060075068, | |||
20070180019, | |||
20080091711, | |||
20080114773, | |||
20090019153, | |||
20090112975, | |||
20090228782, | |||
20090276488, | |||
20100125590, | |||
20100146415, | |||
20110258532, | |||
20110295979, | |||
20120066586, | |||
20120239598, | |||
20130031459, | |||
20130166634, | |||
20130226992, | |||
20130297561, | |||
20150156194, | |||
20150189038, | |||
EP1041497, | |||
WO2010081160, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Dec 12 2017 | TSILLAS, DEMETRIOS J | Viasat, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 064362 | /0896 | |
Dec 13 2017 | LEPESKA, PETER J | Viasat, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 064362 | /0896 | |
Dec 22 2022 | ViaSat, Inc. | (assignment on the face of the patent) | / | |||
Jun 28 2023 | Viasat, Inc | BANK OF AMERICA, N A | SUPPLEMENTAL PATENT SECURITY AGREEMENT | 064164 | /0152 | |
Jun 28 2023 | Viasat, Inc | Wilmington Trust, National Association, as Collateral Trustee | SUPPLEMENTAL PATENT SECURITY AGREEMENT | 064176 | /0566 | |
Sep 01 2023 | Viasat, Inc | MUFG BANK, LTD , AS AGENT | SUPPLEMENTAL PATENT SECURITY AGREEMENT | 064948 | /0379 |
Date | Maintenance Fee Events |
Dec 22 2022 | BIG: Entity status set to Undiscounted (note the period is included in the code). |
Date | Maintenance Schedule |
Aug 27 2027 | 4 years fee payment window open |
Feb 27 2028 | 6 months grace period start (w surcharge) |
Aug 27 2028 | patent expiry (for year 4) |
Aug 27 2030 | 2 years to revive unintentionally abandoned end. (for year 4) |
Aug 27 2031 | 8 years fee payment window open |
Feb 27 2032 | 6 months grace period start (w surcharge) |
Aug 27 2032 | patent expiry (for year 8) |
Aug 27 2034 | 2 years to revive unintentionally abandoned end. (for year 8) |
Aug 27 2035 | 12 years fee payment window open |
Feb 27 2036 | 6 months grace period start (w surcharge) |
Aug 27 2036 | patent expiry (for year 12) |
Aug 27 2038 | 2 years to revive unintentionally abandoned end. (for year 12) |