Patent Description:
<CIT> describes methods, systems, and computer program products for reducing web latency using adaptive speculative preconnection.

The invention to which this European patent relates is defined by a method and a client-side pre-connect module as defined in the independent claims.

In some embodiments, setup of a persistent connection over a network involving a handshake comprising at least a connection request by a client device followed by a compliant response by a remote host server is accelerated.

After it is determined that a client device may in the future seek a connection with a particular host server, a pre-connect request on behalf of the client device can be generated and sent to the host server. The pre-connect request can mimic a connection request by the client device so that the host server generates a compliant connection response. The host server's connection response (often referred to herein as a "pre-connect response") can then be prepositioned on the client-side of the network along with generation information indicating how the pre-connect request was generated.

Later, when the client device determines to initiate an actual connection handshake with the host server, the client device first checks a client-side cache for generation information for generating a connection request to the host server. If the client device finds such generation information, the client device uses the generation information to generate the connection request, which should thus be materially the same as the pre-connect request previously used to elicit the pre-connect response. If the client device does not find corresponding generation information, the client device generates the connection request in accordance with applicable protocols of the handshake process. Regardless of how the connection request was generated, the client device sends the connection request to the host server. An interceptor on the client-side of the network intercepts connection requests and checks a client-side cache for a corresponding pre-connect response. If the interceptor finds such a pre-connect response, the interceptor sends the pre-connect response to the client device. Because the pre-connect response was previously generated by the host server in response to a pre-connect request that is materially the same as the intercepted connection request, the pre-connect request should be accepted by the client device as a compliant response to the connection request, causing the client device to proceed with the handshake process to establishment of a connection with the host server. If the interceptor does not find a corresponding pre-connect response, the interceptor forwards the intercepted connection request across the network to the remote 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. 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, "persistent connection" refers to a connection between devices on a network that, once established, remains until terminated by one of the devices or due to a time out after a pre-defined period of non-use. A persistent connection can thus remain in existence over multiple exchanges of data, messages, or the like between a client device and a host server. A web socket connection between two network devices is an example of a persistent connection. Known protocols for establishing a persistence connection between devices on a network include Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS). Some connection protocols (e.g., HTTPS) allow a client device to establish a secure connection with a host server. Secure connection protocols include Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. A ClientHello message is an example of a known connection request for establishing a secure connection, and a ServerHello is an example of a corresponding connection response.

In many network systems, a client device (e.g., a personal computing device running a Web browser) establishes a persistent connection with a remote host server by a handshake protocol. Typically, the client device starts the handshake by sending a connection request over the network to the host server and then waiting for a connection response from the host server. Only if the connection response is received and complies with the handshake protocol does the client device proceed with the handshake. Once the handshake process is completed and a persistent connection established, the client device can obtain network resources, services, or the like from the host server.

In modern networks, a client device executing a network transaction often requests resources, services, and/or the like from many different host servers. In order to complete a network transaction, a client device thus often must establish connections with and then request resources, services, and/or the like from many different host servers. This can result in many transmissions of messages over the network and result in not insignificant delays in completing the network transaction. Indeed, merely establishing connections with each host server can comprise a not insignificant portion of the delay.

Some embodiments of the invention attempt to reduce this delay by accelerating the process of establishing connections with host servers. When it is known beforehand that a client device will or even might attempt in the future to establish a connection with a particular host server (e.g., as part of a network transaction), some embodiments of the invention mimic a connection request (hereinafter a "pre-connect request") to the host server, which elicits a connection response (hereinafter a "pre-connect response") from the host server. The pre-connect response is then preposition on the local-device side of the network along with information indicating how the pre-connect request was generated. Then, when the client device starts the process of establishing an actual connection with the host server, the client device can first determine whether it has locally stored information indicating how a pre-connect request to the host server was generated (hereinafter this information is referred to as "generation information"). If so, the client device uses the generation information to generate a connection request that is materially the same as the pre-connect request. If no, the client device generates a connection request in accordance with the applicable handshake protocol. An interceptor on the client-side of the network intercepts connection requests and determines, for each intercepted connection request, whether a corresponding pre-connect response is locally stored on the client-side of the network. If so, the interceptor provides the locally stored pre-connect response as a response to the intercepted connection request, which can now be discarded. If no, the interceptor forwards the connection request to the host server to which the connection request is addressed.

In those instances in which a pre-connect response from the host server to which the intercepted connection request is addressed is locally stored, providing the locally stored pre-connect response to the client device can accelerate the process of establishing the connection by at least the time corresponding to a round trip across the network. That is, at least the sum of the following is saved: the time for the actual connection request by the client device to travel across the network to the host server, the time for the host server to generate a connection response, and the time for the connection response to travel back across the network to the client device. Embodiments of the invention can provide these and other advantages, which can be particularly advantageous when the network between the client device and the host server has a relatively high latency such as when the network includes one or more satellite links. The invention, however, is not limited to use over a network that includes a satellite link or any high latency link.

<FIG> shows a high level, block diagram depiction of an example of a system <NUM> according to some embodiments of the invention. As shown, the system <NUM> can comprise a network <NUM> to which one or more client devices <NUM> (two are shown but there can be fewer or more) and one or more remote host servers <NUM> (three are shown but there can be more or fewer) are connected. The network <NUM> can have one or more communication links <NUM> between client devices <NUM> and host servers <NUM>. In some embodiments, the client devices <NUM> are on one side (sometimes referred to herein as the "client side") of such a communications link <NUM> or network <NUM>, and the host servers <NUM> are on an opposite side (sometimes referred to herein as the "server side") of the communications link <NUM> or network <NUM>. In some embodiments, the communications link <NUM> is a relatively high latency link such as a satellite link. The communications link <NUM>, however, need not be high latency, and the invention is not limited to operating over a satellite link.

A client device <NUM> 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 <NUM> can comprise any of the hardware and software modules typical of such devices. In <FIG>, client device 102a is depicted as comprising a plurality of applications <NUM>, a generation information cache <NUM>, a client-side pre-connect module <NUM>, an interceptor <NUM>, and a pre-responses cache <NUM>.

Each application <NUM> 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 <NUM> on a device <NUM> can include the ability to establish a persistent connection with a remote host server <NUM> by a prearranged handshake process that includes at least a connection request by the client device <NUM> and a connection response by the host server <NUM> in which the connection request and the connection response comply with the prearranged handshake protocol. Thus, upon receiving a connection request from a client device <NUM>, a host server <NUM> determines whether the connection request complies with the handshake protocol. If so, the host server <NUM> generates and sends back to the client device <NUM> a connection response. Only if the client device <NUM> determines that the connection response complies with the protocol and is otherwise acceptable does the client device <NUM> continue with any remaining steps in the handshake. Only after all steps in the handshake protocol are completed is a persistent connection established between the device <NUM> and the remote host server <NUM>.

Examples of applications <NUM> that typically include a capability of establishing persistent connections with remote host servers <NUM> include applications that execute a network transaction that involves the client device fetching resources or services from multiple different host servers. For example, the application <NUM> may establish a persistent connection with one or more (e.g., all) of the host servers <NUM> from which it fetches an initial parent resource and subsequent additional resources as part of executing the network transaction. A web browser is an example of such an application <NUM>, and requesting and rendering a web page (which is an example of a parent resource) is an example of such a network transaction. A media player is another example of such an application <NUM>, 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 pre-responses cache <NUM>, client-side pre-connect module <NUM>, interceptor <NUM>, and generation information cache <NUM> can work with a server-side pre-connect module <NUM> and, in some embodiments, a hinting service <NUM>, to elicit pre-connect responses from one or more host servers <NUM> and pre-position the pre-connect responses on the client-side of the network <NUM> so that, when a client device <NUM> later generates an actual connection request directed to the same host server <NUM>, a valid connection response in the form of a pre-connect response previously generated by the host server <NUM> is already cached on the client-side of the network <NUM>.

In <FIG>, the pre-responses cache <NUM>, client-side pre-connect module <NUM>, interceptor <NUM>, and generation information cache <NUM> are illustrated as modules of client device 102a. In other embodiments, one or more of those modules can alternatively be in a separate computing device such as a client proxy device <NUM> to which the client device 102a is connected. For example, in some embodiments, the pre-connect module <NUM>, interceptor <NUM>, and/or pre-responses cache <NUM> can be in a client proxy device <NUM> that is separate from the client device 102a but nevertheless on the client-side of the network <NUM>. Although not shown, client device 102b can be configured like client device 102a.

The network <NUM> can comprise a single network of interconnected computing devices, a plurality of interconnected single networks, or the like. For example, the network <NUM> can comprise one or more local area networks (LANs), wide area networks (WANs), or the like. Individual networks that comprise the network <NUM> can be public and/or private. All or part of the network <NUM> can be part of the world-wide web (a. the public Internet). In some embodiments, the network <NUM> can be the public Internet.

The network <NUM> can be a packet switched network comprising a plurality of interconnected devices such as routers, switches, bridges, or the like. As such, the network <NUM> can interconnect one device (e.g., client device 102a) to another device (e.g., host server 150a) by routing data packets from one of the devices through the network <NUM> to the other device. Moreover, persistent connections between network devices (e.g., client device 102a and 150a) can be created using known network protocols. For example, a connection can be established over the network <NUM> between a socket of one device (e.g., client devices 102a or 102b, host servers 150a-c, and/or a device or devices hosting server-side pre-connect module <NUM> and the hinting service <NUM>) and a socket of another device of those devices. Regardless, the connection can be set up in accordance with a networking protocol including the requirements of a corresponding handshake process for setting up and establishing the persistent connection. Examples of such protocols include the Hypertext Transfer Protocol (HTTP) or the Hypertext Transfer Protocol Secure (HTTPS). In some embodiments, the connection can be set up in accordance with a secure connection protocol such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). In some embodiments, the secure connection can be a data transport tunnel.

Host servers <NUM> can store and provide network resources, services, or the like to other entities (e.g., client devices <NUM>) over the network <NUM>. Examples of host servers <NUM> include web page servers, media servers, email servers, file transfer protocol (FTP) servers, or the like. Examples of resources or services a host server <NUM> might provide include web pages, images, audio files, video files, text files, streaming content, or the like.

The hinting service <NUM> 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 <NUM> completes a network transaction, the hinting service <NUM> 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 server-side pre-connect module <NUM> can be configured to receive hints from the hinting service <NUM> for a particular network transaction and pre-connect host servers <NUM> identified in the hints. Thus, such hints can, among other items, include identifications of host servers <NUM> to which the client device <NUM> may or will need to connect while executing the network transaction.

Although not shown in <FIG>, the server-side pre-connect module <NUM> and the hinting service <NUM> can reside on one computing device or multiple computing devices. For example, the server-side pre-connect module <NUM> can reside on a proxy server (not shown in <FIG>), and the hinting service <NUM> can reside on a hinting server (not shown in <FIG>). An example of the foregoing is illustrated in <FIG> and <FIG>. In other examples, the server-side pre-connect module <NUM> and the hinting service <NUM> can reside on the same computing device (not shown in <FIG>). An example is illustrated in <FIG>. Regardless, the server-side pre-connect module <NUM> and hinting service <NUM> can be on the server-side of the communications link <NUM>.

When an application <NUM> of a client device 102a has or is expected to begin executing a network transaction in which it will connect to one or more host servers <NUM>, the server-side pre-connect module <NUM> can receive hints from the hinting service <NUM> that identify those host servers. When the serve-side pre-connect module <NUM> encounters an identification of such a host server (e.g., 150c) in the hints, or otherwise detects an event indicating a likelihood that the client device 102a will attempt to connect to the host server 150c, the server-side pre-connect module <NUM> can elicit a pre-connect response from the host server 150c that is sufficient to be a complete and valid response to a future connection request from the client device 102a. The server-side pre-connect module <NUM> can do so by generating a pre-connect request that complies with a handshake protocol for establishing a persistent connection. That is, the server-side pre-connect module <NUM> can generate a connection request that mimics, in relevant characteristics, a connection request that would be generated by the client device 102a. Then, when the host server 150c responds with a connection response, the server-side pre-connect module <NUM> can send the connection response (sometimes referred to herein as an "elicited pre-connect response" or simply a "pre-connect response") to client device 102a (e.g., the pre-connect module <NUM>), which can locally store the elicited pre-connect response, for example, in the pre-responses cache <NUM>.

The server-side pre-connect module <NUM> can generate a compliant pre-connect request by, for example, knowing one or more handshake protocols used by the client devices <NUM> and host servers <NUM>. As another example, information for generating a pre-connect request can be in the hints.

The pre-connect request can comprise an identifier identifying the client device 102a as the requesting device, and the pre-connect request can be addressed to the host server 150c. In some embodiments, the pre-connect request also includes a randomly generated value. For example, to comply with some handshake protocols for establishing a secure connection, the pre-connect request may include a randomly generated number. Examples of protocols for establishing a secure connection that may include a field in the connection request for a random number include protocols that comply with SSL or TLS. A ClientHello message is an example of a connection request that can include a randomly generated number.

At least when the pre-connect request includes a randomly generated value, the server-side pre-connect module <NUM> sends to the client-side pre-connect module <NUM> not only the pre-connect response elicited from the host server 150c but generation information containing enough information for the client device 102a to later generate a connection request that is materially the same as the pre-connect request used to elicit the pre-connect response. Such information can include at least the random value included in the pre-connect request. Having now received both the pre-connect response elicited from the host server 150c and generation information indicating how the pre-connect request was generated, the client-side pre-connect module <NUM> locally stores that information, respectively, in the pre-responses cache <NUM> and the generation information cache <NUM>.

Later, when an application <NUM> encounters a need to establish a connection with a host server <NUM> (e.g., while executing a network transaction), the application <NUM> initiates the handshake process by generating and sending to the host server (e.g., 150c) a connection request. In some embodiments, the application <NUM> may first determine whether generation information previously stored in the generation information cache <NUM> corresponds to the host server 150c. If the connection handshake protocol calls for a random value in the connection request and information regarding generation of a pre-connect request is locally stored in the generation information cache <NUM>, the application <NUM> can generate the connection request with the same random value as was used in the pre-connect request. If no generation information corresponding to the host server 150c is in the generation information cache <NUM>, the application <NUM> generates the connection request as it normally would. Regardless of which way the connection request is generated, the application <NUM> sends the connection request to the corresponding host server 150c.

The interceptor <NUM> intercepts connection requests from the application <NUM> and determines whether each connection request corresponds to a pre-connect response in the pre-responses cache <NUM>. If yes, the interceptor <NUM> responds to the intercepted connection request with the cached pre-connect response. Because the cached pre-connect response is a valid response previously elicited from the host server 150c, as long as other requirements are met, the application <NUM> will accept the cached pre-connect response as a valid response from the host server 150c and will continue with the handshake process, for example, by sending an additional response back to the host server 150c. Because the cached pre-connect response is thus a valid response to the application's <NUM> connection request, the interceptor <NUM> can discard the intercepted connection request. If, on the other hand, the interceptor <NUM> does not find in the pre-responses cache <NUM> a pre-connect response that corresponds to the intercepted connection request, the interceptor <NUM> forwards the intercepted connection request to the corresponding host server 150c, which can then respond with a connection response in accordance with the handshake protocol.

<FIG> illustrates an example computing device <NUM> suitable for use in system <NUM> of <FIG>. Any one or more of the client devices <NUM> and/or host servers <NUM> can comprise a computing device that is the same as or similar to computing device <NUM> of <FIG>. Likewise, if a client proxy <NUM> is included in system <NUM>, the client proxy <NUM> can operate on a computing device like device <NUM>. Likewise, the hinting service <NUM> and server-side pre-connect module <NUM> can operate on one or multiple distinct computing devices like <NUM>.

As shown, the computing device <NUM> includes a processor <NUM>, a memory <NUM>, a network interface <NUM>, a display <NUM>, and one or more user input device <NUM>. Each of these components is in communication with the other components via one or more communications buses <NUM>. The computing device <NUM> illustrated in <FIG> is but an example, and many variations are possible. For example, while the example shown in <FIG> includes a user input device <NUM> and a display <NUM>, such components are optional and may not be present in some examples, such as in some examples used as servers such as host servers <NUM> or one or more servers on which the hinting service <NUM> and/or the server-side pre-connect module <NUM> is located.

Suitable network interfaces <NUM> may employ wireless Ethernet, including <NUM> a, g, b, or n standards. In one example, the network interface <NUM> 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 <NUM> may communicate through a wired connection and may be in communication with one or more networks, such as Ethernet, token ring, USB, FireWire <NUM>, fiber optic, etc..

Any configuration of the memory <NUM> and processor <NUM> can be such that computer readable instructions (e.g., software, microcode, firmware, or the like) are stored in memory <NUM> as non-transient signals. Such instructions can cause the processor <NUM> to perform one or more functions, methods, or the like. For example, such instructions can cause the processor <NUM> to perform all or part of any of method <NUM> of <FIG>, method <NUM> of <FIG>, and/or method <NUM> of <FIG>. Alternatively, any configuration or instance of the computing device <NUM> can comprise hardwired logic (not shown) that causes the computing device <NUM> to perform all or any part of the foregoing methods. As yet another alternative, any configuration or instance of the computing device <NUM> can comprise a combination of computer readable instructions stored in the memory <NUM> that can be executed by the processor <NUM> and hardwired logic (not shown) that causes the computing device <NUM> to perform all or any part of the foregoing methods.

As noted, each client device <NUM>, the client proxy <NUM> (if present), and the one or more computing devices on which the server-side pre-connect module <NUM> and hinting service <NUM> operate can comprise one or more computing devices like device <NUM>. Each application <NUM>, the client-side pre-connect module <NUM>, the interceptor <NUM>, the server-side pre-connect module <NUM>, and/or the hinting service <NUM> can thus comprise hardwired logic (not shown) and/or non-transient computer readable instructions stored in memory <NUM> that can be executed by the processor <NUM> in one or more computing devices like <NUM>. Similarly, the pre-responses cache <NUM> and the generation information cache <NUM> can be part of the memory <NUM> or a similar memory (not shown) of one or more computing devices like <NUM>.

<FIG> illustrates an example of a method <NUM> for pre-connecting a client device (e.g., 102a) to a host server (e.g., 150c) by eliciting a pre-connect response from the host server 150c and pre-positioning the pre-connect response on the client-side of network <NUM>. As will be seen with respect to method <NUM> of <FIG> and method <NUM> of <FIG>, the pre-positioned pre-connect response can be a complete and valid response to a later actual connection request by the client device 102a to the host server 150c.

For ease of illustration and discussion, method <NUM> is described as being performed on system <NUM> of <FIG> in which client device 102a is expected to initiate a future connection handshake with host server 150c. Two examples illustrated in <FIG> and <FIG>, respectively, of operation of method <NUM> are provided and discussed. Method <NUM> is not, however, limited to being performed on system <NUM>, nor is method <NUM> limited to client device 102a being expected to initiate a connection with host server 150c. Nor is method <NUM> limited to the examples illustrated in <FIG>.

At block <NUM>, one or more indicators are encountered that indicate a possibility, a probability, or a certainty that a client device 102a will, at some point in the future, initiate a connection handshake with host server 150c. Such an indicator can take any of many possible forms and can arise in any of several possible scenarios.

For example, as illustrated by blocks <NUM> to <NUM>, the indicators can be found in hints for a network transaction the client device <NUM> will or is expected to execute.

At block <NUM>, an event occurs in system <NUM> that triggers a request to the hinting service <NUM> for hints for a particular network transaction. The event can be any event that indicates 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 <NUM> hints for a particular network transaction. Using one of applications <NUM> (e.g., a web browser), a user of device 102a selects a universal resource locator (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 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 <NUM>, or the like. In the foregoing examples, rendering or otherwise executing the resource or resources identified by the URL is an example of a network transaction the client device 102a is expected to execute.

Examples of events that can trigger another system <NUM> device to request hints from the hinting service <NUM> include the following. A request by a client device 102a to a domain name system (DNS) server. A DNS request can be detected by proxy server <NUM>, which then sends a hints request to the hinting service <NUM> 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 <NUM>, a proxy server <NUM> can detect a request by the client device 102a to a host server 150a for a particular URL or resource, and the proxy server <NUM> can then request from the hinting service <NUM> hints associated with the network transaction that corresponds to the requested URL or resource.

At block <NUM>, in response to the trigger detected at block <NUM>, a request for hints associated with the particular network transaction is sent to the hinting service <NUM>. The request for hints can originate from any of a number of possible sources including the client device 102a, a client proxy <NUM>, the pre-connect module <NUM>, or the like.

At block <NUM>, assuming the hinting service <NUM> has hints for the network transaction, the hinting service <NUM> sends the hints. The hinting service <NUM> can send the hints to any of a number of possible entities including the client device 102a, the client proxy <NUM>, the server-side pre-connect module <NUM>, or the like. As will be seen, the hints can be forwarded to the client device 102a at block <NUM>, which as shown, can be performed any time during process <NUM> after the hints are received from the hinting service <NUM>.

The hints can, among other things, identify host servers to which the client device 102a is expected to connect as part of executing the network transaction. Processing a hints file and encountering such identifications of host servers is thus one example of encountering connection indicators at block <NUM>. As yet example, block <NUM> can comprise the client device 102a itself indicating that it may or will establish a future connection with host server 150c. For example, client device 102a can send a pre-connect message to the server-side pre-connect module <NUM>, which can thus be another example by which a connection indicator can be encountered at block <NUM>.

Returning to block <NUM>, it is noted that block <NUM> can be performed by a number of possible entities including the server-side pre-connect module <NUM>. Alternatively, all or part of block <NUM> can be performed by the client proxy <NUM> or the client device 102a (e.g., the client-side pre-connect module <NUM>, one of the applications <NUM>, or the like).

Blocks <NUM> through <NUM> are now executed for each connection indicator encountered at block <NUM>. Those blocks are now discussed for an example of an indicator that client device 102a will seek to establish a future connection with host server 150c.

At block <NUM>, a pre-connect request is generated that is compliant with a handshake protocol for initiating a connection with a host server <NUM>. For example, the pre-connect request is generated on behalf of the client device 102a and is addressed to the host server 150c. The pre-connect request can be said to mimic an actual connection request as such a request would be generated by client device 102a.

Block <NUM> can be performed by generating a pre-connect request that complies with the requirements of an initial connection request in accordance with a pre-agreed handshake protocol between the client devices <NUM> and the host servers <NUM>. As noted, some protocols require that a random value (e.g., a randomly generated number) be included in an initial connection request. A ClientHello is an example of an initial connection request that is compliant with SSL or TLS protocols, and a ClientHello typically includes a field for a randomly generated number. Block <NUM> can thus comprise generating a random number and including the random number in the pre-connect request.

At block <NUM>, information regarding generation of the pre-connect request is provided to the client-side pre-connect module <NUM> of client device 102a, which can store the generation information in cache <NUM>. Alternatively, the generation information can be provided to an application <NUM>, which stores the generation information in the generation information cache <NUM>. Regardless, as will be seen, the client device 102a can use this information to generate a later actual connection request that is the same as the pre-connect request in material characteristics.

The generation information may take any of a number of forms. For example, if the pre-connect request includes one or more random value fields, the generation information can be the random value generated and included in the pre-connect request generated at block <NUM>. Thus, if the pre-connect request generated at block <NUM> was a ClientHello message, the generation information can include the random number included in the ClientHello message. In some embodiments, the generation information can be part or all of the pre-connect request itself.

The generation information may be sent to the client device 102a at block <NUM> in any number of possible ways. For example, if the connection indicator encountered at block <NUM> was found in hints requested as part of blocks <NUM> to <NUM>, the generation information may be added to the hints received from the hinting service <NUM> (see block <NUM>). In such an embodiment, block <NUM> can thus be accomplished as part of sending, at block <NUM>, the hints to the client device 102a. As another example, the generation information may be sent directly to the client device 102a (or proxy client <NUM>) rather than in the hints as part of block <NUM>. Regardless, the generation information can be cached in the generation information cache <NUM> at client device 102a.

At block <NUM>, the pre-connect request generated at block <NUM> is sent to the corresponding host server 150c. As noted, the pre-connect request is, in material characteristics, the same as a connection request that would be generated by the client device 102a. The pre-connect request thus mimics an actual connection request from client device 102a. When the host server 150c receives the pre-connect request, it responds with a pre-connect response that is, in material characteristics, the same as a connection response it would generate in response to an actual connection request from client device 102a. If, for example, the pre-connect request generated at block <NUM> was a ClientHello message compliant with an SSL/TLS protocol, the pre-connect response generated by host server 150c as part of block <NUM> is a ServerHello message that is compliant with the same protocol.

At block <NUM>, the pre-connect response is received from the host server 150c, and at block <NUM>, the pre-connect response of block <NUM> can be pre-positioned on the client side of network <NUM>. Block <NUM> can be performed, for example, by sending the pre-connect response received at block <NUM> to the client-side pre-connect module <NUM>, which can locally store the pre-connect response in the pre-responses cache <NUM> of client device 102a.

In some embodiments, blocks <NUM> through <NUM> can be performed by the server-side pre-connect module <NUM>. In other embodiments, one or more of blocks <NUM> through <NUM> can be performed in part or whole by another entity of system <NUM> such as the client-side pre-connect module <NUM> of the client device 102a, one or more of the applications <NUM> in the client device 102a, or the like.

At this point, method <NUM> has generated on behalf of client device 102a a pre-connect request that is compliant with a handshake protocol for establishing a connection with host server 150c. Host server 150c has treated the pre-connect request as a connection request from client device 102a and responded with a pre-connect response that is also compliant with the handshake protocol. The pre-connect response from the host server 150c and information sufficient for the client device 102a to generate later an actual connection request that is the same, in material characteristics, as the pre-connect request has been stored on the client-side of the network <NUM>. As noted, blocks <NUM>-<NUM> can be repeated for each connection indicator encountered as part of block <NUM>, which can elicit and pre-position at the client device 102a pre-connect responses from multiple servers <NUM>.

As will be seen in discussing the methods <NUM> and <NUM> of <FIG> and <FIG>, when the client device 102a later seeks to initiate an actual connection with host server 150c, the client device 102a can use the locally stored pre-connect request generation information to generate an actual connection request that is materially the same as the pre-connect request. The locally stored pre-connect response can then be a complete response to the actual connection request, obviating the need-and thus saving the time-for the actual request to travel across the network (including link <NUM>) to the host server 150c, the host server 150c to generate a connect response, and the connection response to travel back across the network to the client device 102a.

Before turning to the methods <NUM> and <NUM> of <FIG> and <FIG>, two examples illustrated, respectively, in <FIG> and <FIG> of operation of method <NUM> of Figure <NUM> are discussed.

<FIG> illustrate a first example of operation of method <NUM> in which system <NUM> is configured with the pre-connect module <NUM> on a proxy server <NUM> and the hinting service <NUM> on a distinct hinting server <NUM>. In the first example, the proxy server <NUM> can "snoop" communications to and from the hinting server <NUM> and/or other devices on the network <NUM> such as one or more of the host servers <NUM>.

As illustrated in <FIG> and <FIG>, in the first example, the pre-connect module <NUM> in the proxy server <NUM> encounters a connection indicator <NUM> (block <NUM> of <FIG>) indicating that client device 102a is expected to initiate a future connection handshake with host server 150c. The connection indicator <NUM> can be any of the examples discussed above with respect to block <NUM>. As also illustrated in <FIG> and <FIG>, the server-side pre-connect module <NUM> responds by generating and sending to host server 150c a pre-connect request <NUM> (an example of blocks <NUM> and <NUM> of <FIG>). As also shown, the server-side pre-connect module <NUM> provides generation information <NUM> indicative of how the pre-connect request <NUM> was generated to client device 102a (an example of block <NUM>), which can be locally stored in the generation information cache <NUM> of client device 102a.

As shown in <FIG> and <FIG>, the host server 150c responds with a pre-connect response <NUM>, which is received by the server-side pre-connect module <NUM> (an example of block <NUM>) and sent to the pre-connect module <NUM> of client device 102a, where the pre-connect response <NUM> can be stored in the pre-responses cache <NUM> (an example of block <NUM>).

As best seen in <FIG>, a pre-connect response <NUM> has been elicited from host server 150c with a pre-connect request <NUM>. The pre-connect response <NUM> has been stored in a pre-responses cache <NUM> local to the client device 102a, and information <NUM> indicating how to generate a connection request that is the same as the pre-connect request <NUM> has been stored in a generation information cache <NUM> local to the client device 102a.

<FIG> illustrate a second example of operation of method <NUM> in which system <NUM> is configured with the pre-connect module <NUM> and the hinting service <NUM> on the same server device <NUM>. In the foregoing configuration, communications between a client device <NUM> and the hinting server <NUM> can be encrypted.

As shown in <FIG> and <FIG>, in the second example, the client device 102a initiates a network transaction by requesting <NUM> a parent resource (e.g., a web page) from a host server (e.g., 150a). At about the same time, the client device 102a can send a request <NUM> for hints for the network transaction to the hinting service <NUM>. The hinting service <NUM> responds by providing the requested hints <NUM> to the pre-connect module <NUM>. (The foregoing is an example of operation of method <NUM> at blocks <NUM>-<NUM>.

As noted, the hints <NUM> can include, among other elements, an identification of host servers to which the client device 102a is expected to establish a connection as part of the network transaction. In the second example, the pre-connect module <NUM> finds in the hints <NUM> an indication that client device 102a is expected to attempt to establish a future connection with host server 150c. (This is an example of block <NUM> of <FIG>. ) As shown in <FIG> and <FIG>, the pre-connect module <NUM> consequently generates a pre-connect request <NUM> to host server 150c on behalf of client device 102a. The pre-connect module <NUM> also inserts into the hints <NUM> generation information <NUM> indicating how the pre-connect request <NUM> was generated, and the pre-connect module <NUM> sends the hints <NUM> with the inserted generation information <NUM> to the client device 102a. (This is an example of blocks <NUM>, <NUM>, and <NUM> in <FIG>. ) As also shown in <FIG> and <FIG>, the pre-connect module <NUM> sends the pre-connect request <NUM> to host server 150c (an example of block <NUM> of <FIG>). As shown in <FIG> and <FIG>, the host server 150c responds with a pre-connect response <NUM>, which is forwarded to client device 102a, where it can be stored in the pre-responses cache <NUM> (examples of blocks <NUM> and <NUM> of <FIG>). In the meantime, host server 150a responds to the request <NUM> (see <FIG>) for the parent resource by sending the parent resource <NUM> to client device 102a.

As best seen in <FIG>, a pre-connect response <NUM> has been elicited from host server 150c with a pre-connect request <NUM>. The pre-connect response <NUM> has been stored in a pre-responses cache <NUM> on the client-side of the network <NUM>, and information <NUM> indicating how to generate a connection request that is the same as the pre-connect request <NUM> has been stored in a generation information cache <NUM> on the client-side of the network <NUM>.

As noted above, <FIG> and <FIG> illustrate examples of methods <NUM> and <NUM> by which a client device 102a (and/or a client proxy <NUM> if included in system <NUM>) utilizes pre-positioned pre-connect responses from host servers <NUM> to accelerate establishing a connection with the host servers. For ease of illustration and discussion, methods <NUM> and <NUM> are described as being performed on the system <NUM> of <FIG> in which client device 102a utilizes a pre-connect request pre-positioned by method <NUM> to accelerate establishing a connection with host server 150c. The two examples illustrated in <FIG> and 6A-<NUM> are continued in <FIG>, which illustrates operation of methods <NUM> and <NUM> on example <NUM> of <FIG> and example <NUM> of <FIG>. Neither method <NUM> nor method <NUM>, however, is limited to being performed on system <NUM>. Likewise, neither method <NUM> nor <NUM> is limited to client device 102a establishing a connection with host server 150c. Nor are methods <NUM> and <NUM> limited to the example illustrated in <FIG>.

As illustrated by block <NUM>, an event triggers a client device 102a to initiate a handshake process for establishing an actual connection with host server 150c. The triggering event in block <NUM> can be anything that causes the client device 102a to seek a persistent connection with host server 150c. For example, as part of executing the network transaction (e.g., rendering a web page, playing pieces of a media object identified in a manifest, or the like) noted in block <NUM> of <FIG>, the client device 102a may encounter an instruction that directly or indirectly causes client device 102a to initiate a connection with host server 150c. An example is an instruction to fetch a resource from host server 150c. Such an instruction can be in the form of a URL.

At block <NUM>, method <NUM> determines whether generation information for a connection request to the host server 150c is locally stored at the client device 102a. For example, the method <NUM> can determine whether generation information for a pre-connect request to the host server 150c is stored in the generation information cache <NUM> of client device 102a. Any such generation information would have been provided to client device 102a as part of block <NUM> of <FIG>.

If the determination at block <NUM> is yes, the method <NUM> branches at block <NUM> to block <NUM>, where the method <NUM> generates a connection request to the host server 150c utilizing the generation information. As discussed above, the generation information is sufficient to generate the connection request to be the same as the pre-connect request that was previously generated at block <NUM> of <FIG> and used to elicit a pre-connect response from the host server 150c. As also noted, if the handshake protocol includes a random value field in the connection request, the generation information contains the previously used randomly generated value, which is used at block <NUM> to generate a connection request having the same randomly generated value.

If the determination at block <NUM> is no, the method <NUM> branches at block <NUM> to block <NUM>, where method <NUM> generates a connection request to host server 150c in accordance with the handshake requirements of the relevant connection protocol.

From block <NUM> or block <NUM>, the method <NUM> proceeds to block <NUM>, where method <NUM> sends the connection request generated at block <NUM> or <NUM> to the host server 150c. Block <NUM> of method <NUM> intercepts the connection request and, at block <NUM>, determines whether there is a locally stored pre-connect response that corresponds to the intercepted connection request. For example, the method <NUM> can determine whether a pre-connect response stored in the pre-responses cache <NUM> corresponds to the intercepted connection request.

The method <NUM> can match the intercepted connection request to pre-connect responses stored in the pre-responses cache <NUM> in any of a number of ways. For example, the method <NUM> can compare all or a portion (e.g., the random value) of the connection request intercepted at block <NUM> to a corresponding portion of the pre-fetched responses stored in the pre-responses cache <NUM>. The method <NUM> can, for example, compare one or more values in fields in the intercepted connection request to values in corresponding or complimentary fields in the pre-connect responses in the pre-responses cache <NUM>. For example, method <NUM> can determine at block <NUM> that an intercepted connection request corresponds to a cached pre-connect response if one or more of the following is true: the destination network (e.g., internet protocol (IP)) address of the intercepted connection request matches the source network (e.g., IP) address of a pre-connect response in the pre-responses cache <NUM>, the destination socket number of the intercepted connection request matches the source socket number of a pre-connect response in the pre-responses cache <NUM>, or the like.

If the method <NUM> finds, at block <NUM>, a cached pre-connect response that corresponds to the intercepted connection request, the method <NUM> branches at block <NUM> to block <NUM>, where method <NUM> provides to client device 102a the corresponding pre-connect response as a complete and fully compliant connection response to the intercepted connection request. Consequently, at block <NUM>, the method <NUM> can discard the intercepted connection request.

If, however, the method <NUM> does not find at block <NUM> a corresponding cached pre-connect response, the method <NUM> branches at block <NUM> to block <NUM>, where the method <NUM> forwards the intercepted connection response to the host server 150c. Although not shown in the figures the host server 150c will receive the connection request and respond with a connection response.

Returning to method <NUM> of <FIG>, at block <NUM>, method <NUM> receives a response to the connection request that was sent to host server 150c at block <NUM>. The response received at block <NUM> is thus either the cached pre-connect response provided by method <NUM> at block <NUM> or the connection response generated by the host server 150c in response to the intercepted connection request forwarded to the host server 150c at block <NUM> of <FIG>.

At block <NUM>, method <NUM> determines whether the received connection response is valid and compliant with the relevant handshake protocol. If the determination at block <NUM> is yes, the method <NUM> continues with the connection handshake process at block <NUM> and, assuming any additional steps in the handshake process are successful, completes the handshake and thus establishes a persistent connection with the host server 150c. If the determination at block <NUM> is no, the method <NUM> discontinues the handshake process at block <NUM>. Consequently, a connection is not established with host server 150c.

<FIG> illustrates operation of methods <NUM> and <NUM> with respect to the first and second examples illustrated in <FIG> and discussed above. As discussed above and illustrated in <FIG> and <FIG>, operation of method <NUM> in both the first example and the second example pre-positioned a pre-connect response (<NUM> in example <NUM> and <NUM> in example <NUM>) from host server 150c in the pre-responses cache <NUM> at client device 102a or client proxy <NUM> and generation information (<NUM> in example <NUM> and <NUM> in example <NUM>) indicating how the pre-connect request that elicited the pre-connect response was generated was stored in the generation information cache <NUM> of client device 102a.

In <FIG>, an event <NUM> is illustrated that triggers the client device 102a to initiate a connection handshake with host server 150c. In example <NUM>, the event <NUM> is not specified but can be any event that would cause the client device 102a to seek to establish a connection with host server 150c. In example <NUM>, the event <NUM> is the client device 102a encountering in the parent resource <NUM> (see <FIG> and <FIG>) an instruction (e.g., a URL) to fetch a resource from host server 150c. Regardless, event <NUM> in <FIG> is an example of block <NUM> of <FIG>.

At block <NUM> of <FIG>, in example <NUM>, the method <NUM> finds in the generation information cache <NUM> generation information regarding the pre-fetch request <NUM> to host 150c. In example <NUM>, the method <NUM> finds generation information for pre-fetch request <NUM> to host 150c. In both examples <NUM> and <NUM>, the method <NUM> therefore branches to block <NUM>, where method <NUM> uses generation information <NUM> or <NUM> to generate a connection request <NUM> that is the same as pre-connect request <NUM> (example <NUM>) or pre-connect request <NUM> (example <NUM>). At block <NUM>, the method <NUM> sends the connection request <NUM> to host server 150c. Method <NUM> of <FIG> then intercepts the connection request at block <NUM>. At block <NUM>, method <NUM> finds in the pre-connect responses cache <NUM> a corresponding pre-connect response <NUM> in example <NUM> or <NUM> in example <NUM> and branches to block <NUM>, where method <NUM> provides the pre-connect response <NUM>/<NUM> to client device 102a as a complete response to the intercepted connection request <NUM>, which is discarded at block <NUM>.

Claim 1:
A method of accelerating setup of a persistent connection over a network (<NUM>) between a client device (<NUM>, 102a, 102b) and a remote host server (<NUM>, 150a, 150b, 150c), where establishing the connection requires a connection request by the client device and a corresponding connection response by the remote host server, the method comprising:
generating, by a pre-connect module (<NUM>) on a client side of the network, a pre-connect request on behalf of the client device, the pre-connect request being a connection request that mimics a connection request that would be generated by the client device as part of a network transaction the client device is expected to execute;
sending, by the pre-connect module, the pre-connect request to the remote host server;
receiving, at the pre-connect module, a pre-connect response from the remote host server in response to the pre-connect request;
prepositioning, by the pre-connect module, the pre-connect response on a client-side of the network, comprising storing the pre-connect response in a pre-responses cache (<NUM>); and characterised in that the method further comprises
prepositioning on the client side of the network, by the pre-connect module, generation information indicating how the pre-connect request was generated.