Method and system for deferring network requests

By intercepting and embedding deferred request data into the header of non-deferred requests on both the client and server sides, the problem of low network traffic and resource utilization efficiency in HTTP requests is solved, achieving more efficient network communication.

CN116368786BActive Publication Date: 2025-10-21INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202180069483.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2020-10-28
Filing Date
2021-10-13
Publication Date
2025-10-21
Estimated Expiration
2041-10-13

Smart Images

  • Figure CN116368786B_ABST
    Figure CN116368786B_ABST
Patent Text Reader

Abstract

Embodiments of the invention provide methods, computer program products, and systems. Embodiments of the invention can identify a network request as deferrable, and embed data for the deferrable network request into a header of a suitable carrier network request for transmission to a remote server. Embodiments of the invention can receive a carrier network request having embedded data for a deferrable network request within a header of the carrier network request. Embodiments of the invention can then parse the embedded data from the header into a separate request message for action at a server.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] The present invention relates to processing network requests, and more particularly, to processing deferrable network requests.

[0002] Network requests in the form of Hypertext Transfer Protocol (HTTP) requests are used for communication between clients and servers in a network environment. The HTTP request method from the client indicates the desired action to be performed on a given resource at the server. Resources are identified by request Uniform Resource Locators (URLs), and each request method implements different semantics. For example, web applications typically run code in a browser and submit HTTP requests back to the server to send or retrieve data.

[0003] Many HTTP requests need to be processed immediately by the server, but some requests are less time-sensitive and can be deferred. An example of a deferred request is a request for tracking data used for user analytics. This data is useful for developers to understand user behavior, but is not critical to the direct functionality of the web application.

[0004] The information contained in such an HTTP request is typically very small compared to the overhead of the HTTP request (headers, cookies, etc.), and developers typically need to design strategies to handle failures of such calls.

[0005] Therefore, such extra requests often result in inefficient network traffic and resource usage. Summary of the Invention

[0006] According to a first aspect of the present invention, there is provided a computer-implemented method for processing a deferrable network request, the method being performed at a user agent of a client and comprising: intercepting a network request and identifying it as deferrable; and embedding data of the deferrable network request within a header of a suitable carrier network request for transmission to a remote server.

[0007] This has the advantage of reducing the number of network requests by waiting for a non-deferrable network request, wherein one or more deferrable network requests may be carried in the header of the non-deferrable network request.

[0008] The method may include: storing data for the deferrable network request in a local cache at the client in the form of aggregated data of a target destination and request message data of the deferrable network request; identifying a suitable bearer network request; and embedding the aggregated data for the deferrable request within a header of the bearer network request. The method may include embedding the aggregated data for each of a plurality of deferrable requests within one of a plurality of headers of the bearer network request. The suitable bearer network request is non-deferrable and may have sufficient space for the deferrable request data.

[0009] Identifying the network request as deferrable may include intercepting the network request message and determining whether the request network message is being sent to a host in a predefined list of deferrable destinations. The method may include obtaining a defined header name from the server for use when embedding the deferrable request data in the header.

[0010] The method may include sending the cached deferrable network request data in batches once the cache reaches a predefined size or when leaving the user agent, wherein the batch sending selects a cached deferrable network request as a bearer network request and adds other cached deferrable request data to one or more headers of the bearer network request.

[0011] The method may include receiving a bearer network response having embedded data within a header of the bearer network response for a response to a deferrable network request, and parsing the embedded data from the header into a separate response message for action at the client.

[0012] The method may include, for each deferrable network request added to the appropriate bearer network message, marking the deferrable network request as in progress and updating the deferrable network request upon receipt of a successful response.

[0013] According to another aspect of the present invention, there is provided a computer-implemented method for processing a deferrable network request, the method being performed at a server and comprising: receiving a carrier network request having embedded data for the deferrable network request within a header of the carrier network request; and parsing the embedded data from the header into separate request messages for action at the server.

[0014] The embedded data of the deferrable network request may be aggregated data of a target destination of the deferrable network request and request message data, and parsing the embedded data may form a separate request message to the target destination.

[0015] The method may include receiving a batch of deferrable network requests for individual processing at a server.

[0016] The method may include: intercepting and identifying a deferrable network response; and embedding data of the deferrable network response within a header of an appropriate bearer network response for transmission back to the client. The method may include: storing the data of the deferrable network response in a local cache at the server in the form of aggregated data of a target destination of the deferrable network response and response message data; identifying an appropriate bearer network response; and embedding the aggregated data of the deferrable response within a header of the bearer network response. The method may include embedding the aggregated data of each of a plurality of deferrable responses within one of a plurality of headers of a bearer network request.

[0017] The method may further comprise sending a defined header name from the server for use by the user agent when embedding the deferrable request data in a header of the bearer network request.

[0018] The method may include receiving a batch of deferrable network requests for individual processing at a server in the form of a deferrable network request as a carrier network request and other cached deferrable request data disposed in one or more headers of the carrier network request.

[0019] According to another aspect of the present invention, a system for processing deferrable network requests is provided, comprising: a client system including a processor and a memory, the memory being configured to provide computer program instructions to the processor to perform the functions of the following components: a request interception component for intercepting network requests and a deferrable request identification component for identifying network requests as deferrable; and a header embedding component for embedding data of the deferrable network request into a header of a suitable carrier network request for sending to a remote server.

[0020] The client system may include: a deferrable request storage component for storing data of the deferrable network request in a local cache at the client in the form of aggregated data of a target destination of the deferrable network request and request message data; and a bearer request identification component for identifying a suitable bearer network request.

[0021] The client system may include: a batch sending component for sending cached deferrable network request data in batches once the cache reaches a predefined size or when leaving the user agent; and a batch receiving component for receiving batch responses to the deferrable network requests.

[0022] The client system may include: a bearer response receiving component for receiving a bearer network response having embedded data of a response to a deferrable network request within a header of the bearer network response; and a response parsing component for parsing the embedded data from the header into a separate response message for action at the client.

[0023] According to another aspect of the present invention, a system for processing a deferrable network request is provided, comprising: a server having a processor and a memory, the memory being configured to provide computer program instructions to the processor for performing the functions of the following components: a bearer request receiving component for receiving a bearer network request having embedded data of a deferrable network request within a header of the bearer network request; and a request parsing component for parsing the embedded data from the header into a separate request message for action at the server.

[0024] The server system may include: a response interception component for intercepting network responses and a deferrable response identification component for identifying deferrable network responses; and a header embedding component for embedding data of the deferrable network response within a header of a suitable carrier network response for transmission back to the client.

[0025] The server system may include: a deferrable response storage component for storing data of the deferrable network response in a local cache at the server in the form of aggregated data of a target destination of the deferrable network response and response message data; and a carrier response identification component for identifying an appropriate carrier network response.

[0026] The server system may include a batch request receiving component for receiving a batch of deferrable network requests for individual processing at the server, and a batch response sending component for sending cached deferrable network response data in batches once the cache reaches a predefined size at the server.

[0027] According to another aspect of the present invention, a computer program product for processing a deferrable network request is provided, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to: intercept a network request and identify it as deferrable; and embed data of the deferrable network request within a header of a suitable carrier network request for transmission to a remote server.

[0028] The computer-readable storage medium may be a non-transitory computer-readable storage medium, and the computer-readable program code may be executed by a processing circuit. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The subject matter of the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification.The invention, both as to its organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read in connection with the accompanying figures.

[0030] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings, in which:

[0031] Figure 1 is a schematic diagram of an exemplary embodiment of a method according to the present invention;

[0032] Figure 2 is a flow chart of an example embodiment of another aspect of a method at a client according to the present invention;

[0033] Figure 3A and 3B is a flow chart of an example embodiment of aspects of a method at a server according to the present invention;

[0034] Figure 4 is a block diagram of an exemplary embodiment of a server system according to an aspect of the present invention;

[0035] Figure 5 is a block diagram of an example embodiment of a client system according to another aspect of the present invention;

[0036] Figure 6 is a block diagram of an embodiment of a computer system or cloud server in which the present invention may be implemented;

[0037] Figure 7 is a schematic diagram of a cloud computing environment in which the present invention may be implemented; and

[0038] Figure 8 is a diagram of the abstract model layers of a cloud computing environment in which the present invention may be implemented.

[0039] It should be understood that for simplicity and clarity of illustration, the elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. In addition, where deemed appropriate, reference numerals may be repeated in the drawings to indicate corresponding or similar features. DETAILED DESCRIPTION

[0040] Methods and systems for processing deferrable network requests are described. Network requests in the form of Hypertext Transfer Protocol (HTTP) requests are used for communication between clients and servers in a network environment. The HTTP request method from the client indicates the desired action to be performed on a given resource at the server. Resources are identified by a request Uniform Resource Locator (URL), and each request method implements different semantics.

[0041] The described method embeds data for a deferrable request (e.g., a lightweight routine request) into the header of a non-deferrable request (e.g., a request for a functional purpose) from a client. The header can then be extracted on the server side, and the request data can be sent to a destination location on the server side. A corresponding method is also provided for returning a response to a deferrable request in the reply header of the non-deferrable request.

[0042] refer to Figure 1 , diagram 100 shows an example embodiment of a client 110 and a server 120, exchanging HTTP requests and responses between them. In this example, a user agent 130 (e.g., a web browser) at the client 110 sends a request to a resource 140, 142 (e.g., a web application) at the server 120.

[0043] In a typical request, client 110 submits an HTTP request message to server 120, and server 120, which provides resources 140, 142 such as HTML files and other content, or performs other functions on behalf of client 110, returns a response message to client 110. The response contains completion status information about the request and may also contain the requested content in its message body.

[0044] A web browser is an example of a user agent (UA) 130. Other types of user agents 130 include indexing software used by search providers (web crawlers), voice browsers, mobile applications, and other software that accesses, consumes, or displays web content.

[0045] The deferrable request processing systems 150, 155 are provided in the form of a server deferrable request processing component 150 and a client deferrable request processing component 155. The client component 155 may be code provided by the server component 150 that is downloadable or executable at the client 110 to provide functionality that supplements the server component 150. The client component 155 includes or has access to a deferrable request data cache 156 local to the client 110, in which deferrable requests are cached, as further described below. The server component 150 includes or has access to a deferrable response data cache 152 local to the server 120, in which deferrable request responses are cached, as further described below.

[0046] The client deferrable request processing system 155 intercepts the request at the client 110 and determines whether the request is deferrable or whether it is non-deferrable and should be sent directly. If the request is deferrable, it can be cached in the deferrable request data cache 156 until it is combined into a header 170 of a bearer request message 160 and sent in the form of a subsequent non-deferrable request. Several deferrable request messages can be sent in multiple headers 170 of the bearer request message 160.

[0047] A non-deferrable request message serving as a bearer request message 160 may be sent with its own request data 161 and with deferrable request data 171 embedded in a header 170 of the bearer request message 160. When such a message is received at the server 120, the server deferrable request processing system 150 processes the bearer message request data 161 and separates out the deferrable request data 171 and processes it separately.

[0048] Once the deferrable request data 171 has been acted upon and the deferrable response data 191 is available, the deferrable response data 191 may be cached in the deferrable response data cache 152 local to the server 120 to await delivery by the carrier response message 180 to the client deferrable request processing system 155 at the user agent 130 of the client 110.

[0049] A non-deferrable response message may be sent as a carrier response message 180, along with its own response data 181 and with deferrable response data 191 embedded in a header 190 of the carrier response message 180. When such a message is received at the client 110, the client-deferrable request processing system 155 processes the carrier message response data 181 and separates out the deferrable response data 191 and processes it separately.

[0050] Further details of example embodiments of the methods at the server and client are given below.

[0051] A request message consists of: a request line, which specifies the request method and requests the specified resource from the server; request header fields; a blank line; and an optional message body.

[0052] HTTP defines a request method, which may be the subject of a request message to indicate a desired action to be performed by the server 120 on the identified resource 140, 142. Examples of request methods include, but are not limited to, a method for identifying and / or resolving errors (e.g., a TRACE HTTP request), a method for receiving status notifications (e.g., a STATUS HTTP request), a method for retrieving information (e.g., a GET HTTP request), a method for sending data (e.g., a POST HTTP request), a method for removing predefined information (e.g., a DELETE HTTP request), a method for establishing a communication flow (e.g., a CONNECT HTTP request), a method for describing communication options (e.g., an OPTIONS HTTP request), a method for creating a new resource or replacing a resource (e.g., a PUT HTTP request), a method for making partial changes to a resource (e.g., a PATCH HTTP request), and a method for requesting headers for a resource (e.g., a HEAD HTTP request).

[0053] Some request messages can be considered deferrable if they are not time-sensitive and do not need to be processed immediately by the server. An example is tracking data used for user analytics. Such tracking data is useful for developers to understand user behavior, but is not critical to the direct functionality of the web application. On the other hand, request messages that are relevant to the functionality of the web application are not deferrable.

[0054] HTTP headers allow clients and servers to pass additional information with HTTP requests or responses. Custom, proprietary headers may have an "X-" prefix. This additional information is used in the described method to include data related to the deferrable request message in the form of a message destination and data. The server then extracts the header information and processes the request data by sending it to the message destination.

[0055] The non-deferrable request message forms a bearer request message, whose header contains the destination and data of the deferrable request message. The bearer request message and the deferrable request message may involve different request methods.

[0056] refer to Figure 2 , flowchart 200 illustrates an example embodiment of the method performed by the client deferrable request processing system 155 at the client 110 .

[0057] The client-side deferrable request processing system 155 may receive 201 code for a client-side user agent (e.g., a web browser, a client application, etc.) that sends an HTTP request message to a server having the server-side deferrable request processing system 150. The client-side deferrable request processing system 155 may be provided as a browser extension, for example, to intercept deferrable HTTP requests and cache deferrable request data. The client-side deferrable request processing system 155 may intercept HTTP requests at the native browser network level, or it may make a patch call to a "fetch" or XMLHttpRequest function used by the client application.

[0058] The client-side deferrable request processing system 155 may obtain 202 the defined header name for use when sending a deferrable request message embedded in the header of another request message. For example, the defined header name may be obtained by the client-side deferrable request processing system 155 by making a REST call to the server. In the case of a custom header, the client-side may call a known server route, such as / api / getDeferrableHeader, which responds with the name of the header to be used for the session (e.g., which may be generated using a universally unique identifier). Alternatively, a fixed defined header name may be used for all such messages.

[0059] A method at the client can detect a new HTTP request message 203 to be sent to the server and determine whether the 204 request message is deferrable. Whether the request is deferrable can depend on the destination host name and / or path of the request. The 204 request message can be determined to be deferrable by checking whether the request message is being sent to a host in a preconfigured list. This list can be maintained by the server and exposed to the client via a REST interface.

[0060] A request message may also be deferrable only if it is smaller than a given size.The size of the request header fields is typically between 200 bytes and 2 kilobytes, and deferrable request data must fit within the request header.

[0061] If the request message is deemed deferrable, the method may determine 205 whether the cache of deferrable request messages is above a given limit. If the cache is not above the given limit, a new deferrable request message is aggregated 206 into a form including the requested destination and data and stored 207 in the cache. The method may then end 213 for the request message and may loop to detect 203 new request messages.

[0062] If it is determined 205 that the cache is above a given limit, the cached deferrable request data can be sent 208 as a bulk request message to purge or make room in the cache. A special request can be made to send a 208 bulk request message that is treated as a non-deferrable request, with the cached request appended to it. One of the deferrable requests can be selected as a carrier request for the other deferrable requests in the cache. For each deferrable request, the header of the carrier message is added to mark the deferrable request as "in progress / sent." A special request can be made to a custom route provided by the server that returns an empty response. Once room has been made in the cache, additional deferrable request data can be stored.

[0063] If it is determined 204 that the request message is not deferrable, a determination can be made 209 as to whether the request message is suitable as a carrier message for a deferrable request message. For example, whether there is space in the request message to carry one or more deferrable request messages in one or more headers. If there is insufficient space or there is another reason why the request message does not carry a deferrable request message, the method can send 212 the request message without any deferrable request messages. The method can then terminate 213 for this request message and loop to detect 203 new request messages.

[0064] If the request message is suitable as a carrier message, the method may check 210 whether the request message data is present in a cache. If no cached request message data is present, the method may send 212 the request message. If cached request message data is present, an aggregated form of the cached request data and the destination is added 211 to the header fields of the carrier request message. Multiple deferrable requests may be attached to one carrier message, and they may be attached via separate headers, e.g., "X-Deferrable-Data," then "X-Deferrable-Data-2," "X-Deferrable-Data-3," and so on. For each deferrable request added to the header of the carrier message, the deferrable request is marked as "in progress / sent."

[0065] Once the deferrable request message data has been added to one or more header fields of the message request, the request message may be sent 212. The method may then end 213 for this request message, and the method may loop to detect 203 a new request message.

[0066] When the user leaves the user agent 130, such as a wen application or web browser, all cached data in the deferrable request data that has not yet been sent is sent as a separate special batch request. This method can issue a special batch request in a manner similar to the "cache full" scenario described above. As described above, multiple deferrable requests can be attached to the special batch request.

[0067] The following is an example of a request message:

[0068] Deferable Requests:

[0069] POST https: / / datacollectionresource / tracking {...tracking data...}

[0070] Normal request:

[0071] POST https: / / domain.com / api / flows / flow1 / start {...request data...}

[0072] Single combined request:

[0073] POST https: / / domain.com / api / flows / flow1 / start {...request data...}

[0074] With additional headers:

[0075] X-Deferrable-Data:{destination:https: / / datacollectionresource / tracking data:{...tracking data...},method:'POST'}

[0076] The deferrable data provided in the header will require all the parameters required by the original request. In the simplest case this can be just the method or the method plus the body, but can include all the properties defined by the Request retrieval interface.

[0077] When a new HTTP response message is received at the client 110, it is determined whether the response message contains a deferrable response in its header. If so, the successful deferrable response is extracted and sent to each requester, and the deferrable request is removed from the deferrable request data cache 156.

[0078] refer to Figure 3A , flowchart 300 illustrates an example embodiment of the method performed by the server deferrable request processing system 150 at the server 120 .

[0079] The server-deferrable request processing system 150 may provide a 301 code to a client-side user agent (eg, a web browser, a client application, etc.) that sends an HTTP request message to the server 120 .

[0080] The server deferrable request processing system 150 can provide a 302 defined header name to use when sending a deferrable request message embedded in the header of another request message. In the case of a custom header, the client can call a known server route, such as / api / getDeferrableHeader, which responds with the name of the header to be used for the session (e.g., which can be generated using a universally unique identifier). Alternatively, a fixed, defined header name can be used for all such messages, such as "X-Deferrable-Data".

[0081] The server deferrable request processing system 150 may receive 303 a request including one or more headers having a defined header name and having aggregated deferrable request data embedded in the or each header. The aggregated deferrable request data may combine a target destination of the deferrable request with the deferrable request data. The method may parse 304 the embedded aggregated deferrable request data from the header and may send 305 the extracted data to the target destination provided in the aggregated deferrable request data.

[0082] Responses to deferrable requests can be cached 306 at server 120, and when a non-deferrable request returns a response, any deferrable request responses in the cache can be added 307 to the reply header. The client can then extract and process the deferrable request responses appropriately.

[0083] refer to Figure 3B , flowchart 320 shows further details of an example embodiment of the method performed by the server deferrable request processing system 150 at the server 120 .

[0084] A method at the server can detect 321 a new HTTP response message to be sent to the client and determine 322 whether the response message is a response to a deferrable request and is therefore also deferrable. It can be determined 322 that the response message is deferrable by checking whether the response is to a request message sent to a host in a preconfigured list maintained by the server.

[0085] If the response message is deemed deferrable, the method can determine 323 whether the cache of deferrable response messages is above a given limit. If the cache is not above the given limit, the new deferrable response message is aggregated 324 into a form including response destination and response data and stored 325 in the cache. The method can then end 326 for this response message and can loop to detect 321 a new response message.

[0086] If it is determined 323 that the cache is above a given limit, the cached deferrable response data may be sent 327 as a bulk response message to purge or free up space in the cache. A special response may be made to send this bulk response message 327 as a non-deferrable response so that the cached response is appended to it. Once space has been freed in the cache, further deferrable response data may be stored.

[0087] If it is determined 322 that the response message is not deferrable, a determination can be made 328 as to whether the response message is suitable as a carrier response message for a deferrable response message. For example, whether there is space in the response message to carry one or more deferrable response messages in one or more headers. If there is insufficient space or there is another reason why the response message does not carry a deferrable response message, the method can send 331 the response message without any deferrable response messages. The method can then end 326 for this request message and can loop to detect 321 a new request message.

[0088] If the response message is suitable as a carrier response message, the method may check 329 whether the response message data exists in the cache. If no cached response message data exists, the method may send 331 the request message. If cached response message data exists, an aggregated form of the cached response data and the destination is added 330 to the header fields of the carrier response message. Multiple deferrable responses may be attached to one carrier message, and they may be attached via separate headers, e.g., "X-Deferrable-Data," then "X-Deferrable-Data-2," "X-Deferrable-Data-3," and so on.

[0089] Once the deferrable request message data has been added to one or more message response header fields, a response message may be sent 331. The method may then end 326 for this response message, and the method may loop to detect 321 a new request message.

[0090] refer to Figure 4 , the block diagram illustrates a client computer system 400 at which the client-side deferrable request processing system 155 may be provided for use by a user agent 130 at the client computer system 400 .

[0091] The server includes at least one processor 401, a hardware module, or circuitry for performing the functions of the described component, which may be a software unit executed on at least one processor. Multiple processors may be provided to run parallel processing threads to enable parallel processing of some or all of the functions of the component. Memory 402 may be configured to provide computer instructions 403 to at least one processor 401 to perform the functions of the component. A client deferrable request processing system 155 may be provided by the server for execution at the client computer system 400 in conjunction with the server deferrable request processing system 150.

[0092] The client-side deferrable request processing system 155 may include a request interception component 411 for intercepting network requests at the user agent 130, such as at a local browser network level or as a function of a client application. The client-side deferrable request processing system 155 may include a deferrable request identification component 412 for identifying a network request as deferrable. The deferrable request identification component 412 may include a list lookup component 413 for looking up a destination host name to which a request can be deferred in a preconfigured list provided by the server.

[0093] The client deferrable request processing system 155 may include a deferrable request storage component 414 for storing data of a deferrable network request in a local deferrable request data cache 156 at the client computer system 400; and an aggregation component 418 for aggregating the data of the deferrable network request into a combination of target destination and request message data.

[0094] The client-side deferrable request processing system 155 may include a bearer request identification component 415 for identifying an appropriate bearer network request, and a header embedding component 416 for embedding aggregated data for each of the plurality of deferrable requests from the cache 156 into a plurality of headers of the bearer network request. The header embedding component 416 may obtain a defined header name from the server to use when embedding the deferrable request data in the header.

[0095] The client-side deferrable request processing system 155 may include a batch request sending component 417 for sending cached deferrable network request data in batches once the cache reaches a predetermined size or when leaving the user agent.

[0096] The client deferrable request processing system 155 may also include components for processing responses received in response bearer messages, including a bearer response receiving component 421 for receiving a bearer network response having embedded data of a response to the deferrable network request within a header of the bearer network response, and a response parsing component 422 for parsing the embedded data from the header into separate response messages for action at the client by a response processing component 423. A batch response receiving component 424 may also be provided for receiving and processing batch responses to the deferrable network request.

[0097] refer to Figure 5 , a block diagram illustrates a server computer system 500 at which the server deferrable request processing system 150 is provided.

[0098] The server includes at least one processor 501, a hardware module, or circuitry for performing the functions of the described components, which may be software units executed on at least one processor. Multiple processors running parallel processing threads may be provided to enable parallel processing of some or all of the functions of the components. Memory 502 may be configured to provide computer instructions 503 to at least one processor 501 to perform the functions of the components.

[0099] The server deferrable request processing system 150 may include a carrier request receiving component 521 for receiving a carrier network request having embedded data of a deferrable network request within a header of the carrier network request, and a request parsing component 522 for parsing the embedded data from the header into separate request messages for action by a request processing component 523 at the server computer system 500. The server deferrable request processing system 150 may include a batch request receiving component 524 for receiving a batch of deferrable network requests for individual processing at the server computer system 500.

[0100] The server deferrable request processing system 150 may include a response interception component 511 for intercepting network responses, and a deferrable response identification component 512 for identifying deferrable network responses, for example by using a list lookup component 513 to look up a destination host name from which the response can be deferrable in a preconfigured list provided by the server.

[0101] The server deferrable request processing system 150 may include a deferrable response storage component 514 for storing data of a deferrable network response in a local deferrable response data cache 152 at the server computer system 500. An aggregation component 518 may aggregate the deferrable response data of a target destination of the deferrable network response with the response message data for storage in the cache 152.

[0102] The server deferrable request processing system 150 may include a bearer response identification component 515 for identifying an appropriate bearer network response, and a header embedding component 516 for embedding data of the deferrable network response into a header of the appropriate bearer network response to send back to the client.

[0103] The server deferrable request processing system 150 may include a batch response sending component 517 for sending cached deferrable network response data in batches once the cache reaches a predefined size at the server.

[0104] Figure 6 A block diagram of components of a computing system for a server computer system 400 or a client computer system 500 according to an embodiment of the present invention is depicted. It should be understood that Figure 6 This merely provides an illustration of one implementation and does not imply any limitation with respect to the environments in which different embodiments may be implemented.Many modifications to the described environments are possible.

[0105] The computing system may include one or more processors 602, one or more computer-readable RAMs 604, one or more computer-readable ROMs 606, one or more computer-readable storage media 608, device drivers 612, read / write drivers or interfaces 614, and network adapters or interfaces 616, all interconnected by a communications fabric 618. Communications fabric 618 may be implemented using any architecture designed to pass data and / or control information between processors (e.g., microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within the system.

[0106] One or more operating systems 610 and application programs 611, such as the server deferrable request processing system 150 and the client deferrable request processing system 155, are stored on one or more computer-readable storage media 608 for execution by one or more processors 602 via one or more corresponding RAMs 604 (which typically include cache memory). In the illustrated embodiment, each computer-readable storage medium 608 may be a disk storage device such as an internal hard drive, a CD-ROM, a DVD, a memory stick, a tape, a magnetic disk, an optical disk, a semiconductor storage device such as RAM, ROM, EPROM, flash memory, or any other computer-readable storage medium that can store computer programs and digital information, in accordance with embodiments of the present invention.

[0107] The computing system may also include a read / write drive or interface 614 to read from and write to one or more portable computer-readable storage media 626. Application programs 611 on the computing system may be stored on one or more portable computer-readable storage media 626, read via a corresponding read / write drive or interface 614, and loaded into a corresponding computer-readable storage medium 608.

[0108] The computing system may also include a network adapter or interface 616, such as a TCP / IP adapter card or a wireless communication adapter. Application programs 611 on the computing system can be downloaded from an external computer or external storage device to the computing device via a network (e.g., the Internet, a local area network or other wide area network or wireless network) and the network adapter or interface 616. Programs can be loaded from the network adapter or interface 616 into the computer-readable storage medium 608. The network may include copper wires, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0109] The computing system may also include a display screen 620, a keyboard or keypad 622, and a computer mouse or touchpad 624. The device driver 612 interfaces with the display screen 620 for imaging, the keyboard or keypad 622, the computer mouse or touchpad 624, and / or the display screen 620 for pressure sensing of alphanumeric characters and user selections. The device driver 612, the R / W driver or interface 614, and the network adapter or interface 616 may include hardware and software stored in the computer-readable storage medium 608 and / or the ROM 606.

[0110] The present invention may be a system, method and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon, the computer-readable program instructions being used to cause a processor to perform various aspects of the present invention.

[0111] A computer-readable storage medium can be a tangible device that can retain and store instructions used by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or a raised structure in a groove on which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by an optical fiber cable), or an electrical signal transmitted by a wire.

[0112] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0113] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages, such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as "C" programming language or similar programming languages). The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In some embodiments, in order to perform various aspects of the present invention, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer-readable program instructions to personalize the electronic circuit by utilizing the state information of the computer-readable program instructions.

[0114] Various aspects of the present invention are described herein with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems) and computer program products according to embodiments of the present invention. It will be understood that each block of the flowcharts and / or block diagrams and the combination of blocks in the flowcharts and / or block diagrams can be implemented by computer-readable program instructions.

[0115] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct the computer, programmable data processing device and / or other equipment to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0116] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0117] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each frame in the flow chart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing the specified logical function. In some alternative embodiments, the functions noted in the frame may not occur in the order noted in the figure. For example, the two frames shown in succession can actually be implemented as a step, simultaneously, substantially simultaneously, in a manner that overlaps part or all of the time, or these frames can sometimes be performed in reverse order, depending on the functions involved. It will also be noted that each frame of the block diagram and / or flow chart illustration and the combination of the frames in the block diagram and / or flow chart illustration can be implemented by a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0118] cloud computing

[0119] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings set forth herein is not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0120] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0121] Features are as follows:

[0122] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed without manual interaction with the service provider.

[0123] Wide Area Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0124] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. This is location-independent in the sense that consumers typically do not control or know the exact location of the provided resources, but are able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0125] Rapid elasticity: In some cases, the ability to scale out quickly and in quickly can be provided quickly and elastically. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any quantity at any time.

[0126] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the provider and consumer of the utilized service.

[0127] The service model is as follows:

[0128] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on cloud infrastructure. Applications are accessed from a variety of client devices through a thin client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0129] Platform as a Service (PaaS): The capability provided to consumers is to deploy consumer-created or acquired applications onto cloud infrastructure. These applications are built using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but do have control over the deployed applications and possibly the configuration of the application hosting environment.

[0130] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but do have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0131] The deployment model is as follows:

[0132] Private cloud: The cloud infrastructure is operated solely for the organization. It can be managed by the organization or a third party and can exist inside or outside the building.

[0133] Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0134] Public cloud: Cloud infrastructure is available to the general public or large industrial groups and is owned by the organization that sells cloud services.

[0135] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a unique entity but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0136] The cloud computing environment is service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is the infrastructure consisting of a network of interconnected nodes.

[0137] Now refer to Figure 7 , depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. It should be understood that Figure 7 The types of computing devices 54A-N shown in are intended for illustration only, and computing node 10 and cloud computing environment 50 may communicate with any type of computing device over any type of network and / or network-addressable connection (eg, using a web browser).

[0138] Now refer to Figure 8 , showing the cloud computing environment 50 ( Figure 7 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 8 The components, layers, and functions shown in are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0139] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: host 61; server 62 based on RISC (Reduced Instruction Set Computer) architecture; server 63; blade server 64; storage device 65; and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0140] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71 ; virtual storage 72 ; virtual networks 73 , including virtual private networks; virtual applications and operating systems 74 ; and virtual clients 75 .

[0141] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides for dynamic procurement of computing and other resources for performing tasks within a cloud computing environment. Metering and pricing 82 provides for cost tracking when utilizing resources in a cloud computing environment, as well as billing or invoicing for the consumption of those resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. A user portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides for allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides for pre-scheduling and procurement of cloud computing resources, where future demand is anticipated based on the SLA.

[0142] The workload layer 90 provides examples of functionality that can take advantage of a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and request deferral processing 96.

[0143] The computer program product of the present invention includes one or more computer-readable hardware storage devices having computer-readable program codes stored therein. The program codes can be executed by one or more processors to implement the method of the present invention.

[0144] The computer system of the present invention includes one or more processors, one or more memories, and one or more computer-readable hardware storage devices, wherein the one or more hardware storage devices contain program codes that can be executed by the one or more processors via the one or more memories to implement the method of the present invention.

[0145] The description of various embodiments of the present invention has been provided for the purpose of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, practical applications, or improvements over existing technologies in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

[0146] Improvements and modifications may be made to the foregoing without departing from the scope of the present invention.

Claims

1. A computer-implemented method for processing a deferrable network request, comprising: Intercept network requests through the client's user agent before sending them to the remote server; identifying the intercepted network request as a deferrable network request based on a destination and a time sensitivity associated with the network request; embedding data of the deferrable network request in a header of a bearer network request to be sent to a remote server, wherein the bearer network request is a non-deferrable subsequent network request; as well as In response to detecting the departure from the user agent, data of the deferrable network request that has not yet been sent is sent to a remote server as a separate network request.

2. The computer-implemented method of claim 1 , further comprising: storing the data of the deferrable network request in a local cache at the client in the form of aggregated data of a target destination of the deferrable network request and request message data; Identify carrier network requests; as well as The aggregated data of the deferrable network request is embedded within a header of the bearer network request.

3. The computer-implemented method of claim 2 , further comprising: Aggregate data for each of a plurality of deferrable network requests is embedded within one of a plurality of headers of the bearer network request.

4. The computer-implemented method of claim 1, wherein the carrier network request is non-deferrable and has sufficient space for data of a deferrable network request.

5. The computer-implemented method of claim 1 , wherein identifying the network request as deferrable comprises intercepting a network request message and determining whether the network request message is being sent to a host in a predefined list of deferrable destinations.

6. The computer-implemented method of claim 1 , further comprising: Obtains a defined header name from the server to use when embedding data that may defer network requests in the header.

7. The computer-implemented method of claim 2, further comprising: Once the cache reaches a predefined size or when leaving the user agent, data of the cached deferrable network requests are sent in batches, wherein the batch sending selects one of the cached deferrable network requests as a bearer network request and adds data of other cached deferrable network requests to one or more headers of the bearer network request.

8. The computer-implemented method of claim 1 , further comprising: receiving a bearer network response having embedded data of a response to a deferrable network request within a header of the bearer network response; as well as The embedded data from the header is parsed into separate response messages for action at the client.

9. The computer-implemented method of claim 1 , further comprising: For each deferrable network request added to the bearer network message, the deferrable network request is marked as in progress and updated when a successful response is received.

10. The computer-implemented method of claim 1 , further comprising: receiving, at a server, a bearer network request having embedded data within a header that defers the network request; as well as The embedded data from the header is parsed into separate request messages for action at the server.

11. The computer-implemented method of claim 10, wherein the embedded data of the deferrable network request is aggregated data of a target destination and request message data of the deferrable network request, and the embedded data is parsed to form a separate request message to the target destination.

12. The computer-implemented method of claim 10 , further comprising: Interception and identification can delay network responses; as well as The data of the deferrable network response is embedded in a header of the bearer network response to be sent back to the client.

13. The computer-implemented method of claim 12, further comprising: storing data of the deferrable network response in a local cache at the server in the form of aggregated data of a target destination of the deferrable network response and response message data; Identify carrier network responses; as well as The aggregated data of the deferrable network response is embedded within the header of the bearer network response.

14. The computer-implemented method of claim 13, further comprising: Aggregate data for each of a plurality of deferrable network responses is embedded within one of a plurality of headers of the bearer network request.

15. The computer-implemented method of claim 10, further comprising: A defined header name is sent from the server for use by a user agent when embedding data that can deferrable network requests into a header of a bearer network request.

16. The computer-implemented method of claim 10, further comprising: A batch of deferrable network requests for individual processing at the server is received in the form of one deferrable network request as a carrier network request and data of other cached deferrable network requests provided in one or more headers of the carrier network request.

17. A computer program product comprising: One or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media, the program instructions comprising: Program instructions for intercepting network requests through a client's user agent before sending them to a remote server; program instructions for identifying the intercepted network request as a deferrable network request based on a destination and a time sensitivity associated with the network request; Program instructions for embedding data of the deferrable network request into a header of a bearer network request to be sent to a remote server, wherein the bearer network request is a non-deferrable subsequent network request; and Program instructions for sending data of the deferrable network request that has not yet been sent as a separate network request to a remote server in response to detecting departure from the user agent.

18. The computer program product of claim 17, wherein the computer program product is a client system further comprising program instructions stored on the one or more computer-readable storage media, wherein the program instructions further comprise Program instructions for storing data of the deferrable network request in a local cache at the client in the form of aggregated data of a target destination of the deferrable network request and request message data; and Program instructions for identifying a component of a carrier network request.

19. The computer program product of claim 18, wherein the program instructions stored on the one or more computer-readable storage media further comprise: program instructions for sending cached data that can defer network requests once the cache reaches a predefined size or when leaving said user agent; as well as Program instructions for receiving batched responses to deferrable network requests.

20. The computer program product of claim 17, wherein the program instructions stored on the one or more computer-readable storage media further comprise: program instructions for receiving a bearer network response having embedded data within a header of the bearer network response that is a response to the deferrable network request; as well as Program instructions for parsing the embedded data from the header into separate response messages for action at the client.

21. A computer system for processing deferrable network requests, comprising: A client system includes a processor and a memory, wherein the memory is configured to provide computer program instructions to the processor to perform the functions of the following components: A request interception component for intercepting network requests before sending them to a remote server via a client's user agent; a deferrable request identifying component for identifying the intercepted network request as a deferrable network request based on a destination and a time sensitivity associated with the network request; a header embedding component for embedding data of the deferrable network request in a header of a bearer network request for transmission to a remote server, wherein the bearer network request is a subsequent network request that is not deferrable; as well as The batch request sending component is used for sending the data of the deferrable network request that has not been sent to the remote server as a separate network request in response to detecting that the user agent leaves the user agent.

22. The computer system of claim 21, further comprising: A server system having a processor and a memory, the memory being configured to provide computer program instructions to the processor to perform the functions of: A bearer request receiving component configured to receive a bearer network request having embedded data in a header thereof for deferring the network request; as well as A request parsing component is configured to parse the embedded data from the header into separate request messages for action at the server.

23. The computer system of claim 22, wherein the server system comprises: a response interception component for intercepting network responses and a deferrable response identification component for identifying deferrable network responses; as well as The header embedding component is used for embedding the data of the deferrable network response into the header of the bearer network response so as to send the data back to the client.

24. The computer system of claim 23, wherein the server system comprises: a deferrable response storage component for storing data of the deferrable network response in a local cache at the server in the form of aggregated data of a target destination of the deferrable network response and response message data; The carrier response identification component is used to identify the carrier network response.

25. The computer system of claim 22, wherein the server system comprises: a batch request receiving component for receiving a batch of deferrable network requests for individual processing at the server; as well as A batch response sending component is used to send cached deferrable network response data in batches once the cache reaches a predefined size at the server.

Citation Information

Patent Citations

  • Method and apparatus for ensuring transport of user agent information

    US20130124680A1

  • Method and system to decrease page load time by leveraging network latency

    WO2017122981A1