WO2022226510A1 - Modes de transfert d'entité de serveur mandataire - Google Patents

Modes de transfert d'entité de serveur mandataire Download PDF

Info

Publication number
WO2022226510A1
WO2022226510A1 PCT/US2022/071819 US2022071819W WO2022226510A1 WO 2022226510 A1 WO2022226510 A1 WO 2022226510A1 US 2022071819 W US2022071819 W US 2022071819W WO 2022226510 A1 WO2022226510 A1 WO 2022226510A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
server
request
proxy server
client
Prior art date
Application number
PCT/US2022/071819
Other languages
English (en)
Inventor
Matthew J. Stevens
Michael G. MERIDETH
Nil Alexandrov
Andrew F. Champagne
Brendan Coyle
Timothy Glynn
Mark A. Roman
Philip A. Lisiecki
Xin Xu
Original Assignee
Akamai Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/325,450 external-priority patent/US11343344B1/en
Application filed by Akamai Technologies, Inc. filed Critical Akamai Technologies, Inc.
Priority to EP22722104.1A priority Critical patent/EP4327543A1/fr
Publication of WO2022226510A1 publication Critical patent/WO2022226510A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5683—Storage of data provided by user terminals, i.e. reverse caching

Definitions

  • this application generally relates to the design and operation of distributed computing systems, proxy server networks, and proxy servers themselves.
  • CDNs are essentially distributed computing systems, typically composed of large sets of proxy servers that form an overlay network and provide HTTP and related services.
  • the proxy servers typically provide a caching function from a local data store. That is, a proxy server stores content that was fetched from an origin server for the content. The content might be fetched directly by the proxy server or indirectly through a parent server or other topological architectures.
  • TTL time to live
  • CDN architectures can be thought of as facilitating the transfer of content in a vertical manner.
  • end user clients request content from a proxy server (preferably located at a network edge).
  • the proxy server can issue a request “upstream” to a parent server which may in turn query an origin server at the top of the hierarchy.
  • the proxy server can also query the origin directly, and/or query peer servers before going “forward”, that is, “upstream”.
  • the requested content is returned down to the proxy and ultimately served to the end user client.
  • Consumable content is generated not only up at origin but throughout a network.
  • Client devices for example, may be producing message flows, publishing messages on a given topic, issuing status reports, reaching out to other client devices, or updating a distributed database (such as no-SQL, eventually consistent databases).
  • Other nearby clients may be interested in such information before it travels upstream, and ideally they should receive it sooner since they are in fact closer to the source of the content geographically and/or in network distance terms.
  • This patent application presents, among other things, systems and methods in which proxy servers facilitate the transfer of content in new ways.
  • the teachings hereof enable new modes of operation for a proxy server. These new modes are referred to as entity transfer modes. While the teaching hereof are not necessarily limited to HTTP, the term entity is a term used in relation to HTTP to describe the body of the content (sometimes referred to as an object) for which the proxy intermediates transfer from a producing device to a consuming device, and to describe any associated headers or meta-information about that content (such as a TTL).
  • a device that produces an entity for consumption by other devices is a producing device; it may be a client or a server. Consuming devices likewise may be clients or servers.
  • teachings hereof provide new capabilities and represent a technical improvement to proxy servers, and to distributed computing systems (e.g., CDNs).
  • a proxy server is augmented with the capability of taking transient possession of a received entity for purposes of serving consuming devices, without or in addition to destination forwarding and/or origin server transactions.
  • This ability enables several entity transfer modes, including a rendezvous service, in which the proxy server can (if invoked by a client) fulfill a client’s request with an entity the proxy server receives from a producing device contemporaneous with (or shortly after) the client’s request for that entity arrives. It also enables a server-to-server transfer mode with synchronous or asynchronous destination forwarding behavior.
  • proxy server It also enables a mode in which clients can request different representations of entities from the proxy server, e.g., from either a ‘near-channel’ (e.g., the version stored in cache at the proxy server) or a ‘far-channel’ (e.g., from the origin server).
  • client-channel e.g., the version stored in cache at the proxy server
  • far-channel e.g., from the origin server.
  • the teachings hereof are compatible with, though not limited to, conventional HTTP messaging protocols, including GET, POST and PUT methods.
  • FIG 1 A is a diagram illustrating an example of a proxy server transfer mode that involves transferring an entity from a producing client to consuming clients and a consuming server;
  • FIG IB is a diagram illustrating an example of a proxy server transfer mode that involves transferring an entity from a producing client to consuming clients;
  • FIG 2 is a timing diagram showing an order of events at the proxy server in the system depicted in FIGS. 1 A and IB;
  • FIG. 3 is a block diagram illustrating an example of message flow and operation at the proxy server from FIGS. 1 A, IB in greater detail;
  • FIG 4A is a diagram illustrating an example of a proxy server transfer mode that involves transferring an entity from a producing server to consuming clients and a consuming server;
  • FIG 4B is a diagram illustrating an example of a proxy server transfer mode that involves transferring an entity from a producing server to a consuming server;
  • FIG 5 is a timing diagram showing an order of events at the proxy server as in the system depicted in FIGS. 4A and 4B;
  • FIG. 6 is a block diagram illustrating an example of a message flow and operation at the proxy server from FIGS. 4A, 4B in greater detail;
  • FIG. 7 is a block diagram illustrating hardware in a computer system that may be used to implement the teachings hereof.
  • HTTP/S transport layer security
  • TLS transport layer security
  • HTTP protocol will be used to illustrate various processes. While the teachings hereof are especially useful in the context of HTTP, it should be understood that these are non-limiting embodiments and the teachings hereof may be applied to other protocols.
  • entity is used herein to refer to the concept of an “entity” as used in HTTP standards (e.g., IETF RFC 2616), and equivalents.
  • HTTP standards e.g., IETF RFC 2616
  • the teachings hereof are highly applicable to HTTP messaging; however the term “entity” is not meant to indicate that compliance with HTTP standards (e.g., in message structure, formatting, or otherwise) is necessary to practice the invention.
  • An entity typically has entity header fields and an entity body. Entity header fields often contain meta-information about the body, or the sender, or other subject. A given request and response message may contain, in some cases, only entity-headers.
  • the entity body is sometimes referred to as an “object” or an item of “content”.
  • an exemplary entity body is data forming an image, script, HTML document, JSON document, or the like, but there is no limitation as to what the entity represents.
  • the entity could also carry messages being published (by the producing device) on a particular topic or channel to one or many subscribers (consuming devices).
  • HTTP/2 protocols e.g., IETF RFC
  • entity headers can be carried in HEADER frame(s), and the entity body can be carried in DATA frame(s).
  • a service sometimes referred to as a “rendezvous” service.
  • the rendezvous service is provided by the proxy server, or by the proxy server network.
  • An actor e.g., a consuming device
  • the rendezvous service is scoped to a given request which is associated with a given entity.
  • a consuming device can issue an HTTP GET request for an entity and, for example, indicate that it desires rendezvous service for such request by using a URL parameter or request header (or using other alternatives, which will be described below).
  • a request is referred to herein as a “rendezvous” request.
  • the use of the rendezvous service is referred to herein, for convenience, as the consuming device being able to “rendezvous” with an entity, or to “rendezvous” with the producing device.
  • a producing device in certain instances, might also request the proxy server provide a rendezvous service with respect to a given entity that the producing device is sending to the proxy server.
  • a producing device might coordinate the rendezvous with consuming devices via an out-of-band channel.
  • the producing device could signal that a given entity transfer (e.g., an HTTP POST/PUT request it sends) is eligible for or should use the rendezvous service, e.g., using an HTTP request header, URL parameter, or other signal.
  • Entity Transfer Mode Producing Device Is A Client
  • FIG. 1 A illustrates at a high level the case where a producing client sends an
  • HTTP entity to the proxy server using an HTTP POST or PUT method.
  • the proxy server responds, e.g., with a conventional HTTP 201 ‘Created’ message.
  • the proxy server looks up a policy applicable to the received entity (or to a domain associated therewith).
  • This policy may be defined by a content provider and/or CDN operator, e.g., as described in US Patent No. 7,240,100 and/or 9,942,363, the teachings of which are hereby incorporated by reference, or in any other way.
  • the policy directs the proxy server to handle the entity in a special way.
  • the proxy server begins to upload the entity to the intended destination, e.g., the origin server. It can do that by creating a temporary copy of the entity in a transfer buffer in memory, opening a transport layer connection to the origin server if not already available, using an HTTP message and thereby beginning to transfer the bytes of the entity to the origin server.
  • the producing client typically will have been directed to the proxy server in the first place as a result of a domain name lookup, and the origin server is associated with that domain name.
  • the origin server could be another consuming server.
  • Examples include a parent in the proxy server’s overlay network, such as a cache parent server or a gateway server. Such servers may themselves relay the entity to the origin. The consuming server could even be a peer, e.g., another server co-located with the proxy server.
  • the proxy server Concurrent with the upload to the origin or other consuming server, stores the entity in its cache, that is, into a store entry in a local data store. Consuming clients are able to request and be served with the entity from that store entry by making a request to a URL associated with the store entry. Such a request can be made shortly before or at the time that the entity arrives at the proxy server. In this way the entity is transferred directly from the producing client to the requesting consuming clients in FIG. 1 A.
  • the ability of consuming clients to request and receive the entity as it arrives from the producing client (and as it is sent to the consuming server) is referred to as the “rendezvous” service provided by the proxy server.
  • Consuming clients are able to ask for rendezvous with the received entity by requesting the entity from the URL during a limited time period before the producing client sends it to the proxy server, and/or contemporaneously with the producing client sending it to the proxy server.
  • FIG. IB is similar to FIG. 1 A; however, FIG. IB omits the POST or PUT request that would send the entity up to the consuming server. (That omitted POST or PUT request is often referred to as a ‘forward request’ in a CDN.)
  • FIG. IB shows the producing client sending an entity to the proxy server and the proxy server delivering that entity directly to the consuming clients, without going forward. This is an alternative example of how the system can operate.
  • FIG. 2 is a timing diagram related to FIGS. 1 A and IB. It shows events that occur from the perspective of the proxy server. Note that the diagrams are meant to show the general timeline of events so they should not be taken as exact representations of timing at the level of specific events occurring in executing computer processes.
  • FIG. 2 illustrates when a consuming client may rendezvous with the uploaded entity from the producing client.
  • consuming clients are generally issuing HTTP GET requests for an example entity ‘y’ to the proxy server at a URL of http://domain ⁇ dot>com/path-foo/y.
  • Consuming clients may indicate that they wish to have the proxy server attempt to rendezvous their entity request with a subsequent or contemporaneously uploaded entity from a producing client by using a predetermined transform of the entity URL (in this case, /y becomes /y;rendezvous).
  • Time TB represents the time at which a producing client sends a POST/PUT request to the proxy server.
  • the proxy server will hold consuming clients’ GET requests that want to rendezvous for some configurable or event-driven time period, TB minus TA, in an effort to fulfill them with the entity arriving at time TB. Consuming client requests arriving contemporaneously with TB are also able to rendezvous. In both cases, the consuming clients are served from a copy of the entity in a store entry referred to herein as a rendezvous store entry.
  • the proxy server ceases to offer rendezvous service for the entity that arrived at TB. This means that a consuming client’s request for /y;rendezvous will be either rejected, or be held for the next upload of the entity from a producing client. If a consuming client’s rendezvous request “misses” the uploaded entity, preferably it does not trigger a forward request by the proxy server to the origin to fetch the entity, although of course different implementations could handle this situation differently.
  • Tc is when the proxy server finishes writing the entity into the rendezvous store entry in cache (i.e., when that store entry is finalized).
  • the time Tc may occur at approximately the same time as the proxy server finishes forwarding the entity to the consuming server (if forwarding is performed).
  • the period TB to Tc could be configured explicitly, or event-driven.
  • the period TB to Tc can be configured to end automatically once, or shortly after, the proxy server finishes pumping the bytes of the entity upstream to the origin.
  • consuming clients are able to request the version of the entity stored locally in the cache of the proxy server by issuing an HTTP GET to /y;near. As noted, this is referred to as the near-channel, and the consuming client is served from the near-channel store entry.
  • the proxy server handles such near-channel requests by suppressing a forward request operation that would otherwise go to a parent or origin, and instead serving directly from cache.
  • consuming clients can ask the proxy server for the ‘authoritative’ version of the entity, which needs to come from or be validated with the copy at origin.
  • the proxy server would check if its cached version of the entity is current, e.g., via an if-modified-since (IMS) in a forward request, and if not, the current version of the entity would be transferred from the origin to the proxy server and served to the consuming client.
  • IMS if-modified-since
  • the proxy server may no longer offer the near-channel service, at least in some implementations.
  • TD may be triggered by an event or determined by a configured time period following Tc or TB.
  • the proxy server either might be implemented to reject a near channel request, for example, or override it and validate the cached entity against the origin copy, fetching it if needed, before serving the entity.
  • rendezvous store entry and the near-channel store entry can be implemented as the same store entry.
  • the proxy server might convert a consuming client’s rendezvous request for the entity to a near-channel request, based on some native logic, policy, or upon signalling from the consuming client that this is desired rather than a ‘too-late’ rendezvous request being held for the next possible rendezvous.
  • FIG. 3 illustrates the operation of the proxy server in greater detail.
  • the arrows represent the messages.
  • the circular labels on the arrows have letters that correspond to the time at which (or time periods during which) the messages are sent, with respect to the timeline shown in FIG. 2.
  • labels BC1 to BC4 occur substantially during the time period TB to Tc, as shown in FIG. 2.
  • BC1 would occur at time TB, when the producing client sends the entity, thus beginning the TB to Tctime period.
  • Messages AC1 and AC2 occur during the time period TA to Tc.
  • Labels CD1 and CD2 occur substantially during the time period Tc to TD.
  • the proxy server places the entity in a transfer buffer, and the proxy server opens or reuses an open connection to the appropriate consuming server (e.g., the origin for the domain in the POST/PUT request).
  • the proxy server begins to send the entity upstream at BC3. The path from
  • BC1 to BC3 is referred to as the pump-path because the proxy server is pumping the bytes that make up the entity to the consuming server.
  • the proxy server also responds to the producing client with an appropriate acknowledgment, e.g., transport layer acknowledgements as bytes are received, and at the end of the transfer (BC5), an application layer message: HTTP 201 created.
  • the proxy server request handling logic looks up the policy for entity /y and determines that the entity is eligible for rendezvous service. Hence, the proxy server writes the entity to a store entry in the data store, and in particular, to the rendezvous store entry. That operation is shown at BC4.
  • Store entries in the data store are addressable with a store key, often referred to in the art as a cache key.
  • the proxy server generates the store key to use for the entity by calculating it. The calculation can be based on a variety of parameters associated with the POST/PUT request from BC1, e.g., including the URL (or a hash thereof), the HTTP method, other HTTP headers, and so on. (Typically the cache key calculation involves a MD5 hash function applied over such information, but the particular cache key calculation is not crucial to the teachings hereof as long as it provides the functionality described herein.)
  • the proxy server continues to copy the entity into the rendezvous store entry of the local data store as it arrives (e.g., on a byte-by-byte as it is being pumped upstream).
  • the consuming client may signal this desire using a parameter in the URL (/y;rendezvous), a value in an HTTP header field, or in any other suitable way.
  • the proxy server can calculate the store key as was done for the POST/PUT of the entity by the producing client. However, it switches the HTTP method from the GET in the consuming client’s rendezvous request to a POST or PUT, as appropriate. It may also need to adjust the URL, e.g., by changing /y;rendezvous to /y. In this way, the proxy server calculates the store key and looks to see if the store entry for the producing POST or PUT is actually available with the entity /y. If the consuming client arrived before TB, then it will not be, and the proxy server holds or queues the consuming client’s request. The proxy server can periodically ping the rendezvous store entry to see if the entity has arrived, or set a call back so that when it arrives the pending requests can be satisfied.
  • the proxy server can serve the entity in response to the request.
  • the proxy server may in fact be transmitting the bytes of the entity to the consuming clients at the same as the proxy server is transmitting bytes of the entity to the consuming server (although this is not a requirement).
  • the proxy server calls back to the request handling procedure that has queued the previously-received rendezvous requests, and responds to them by serving the entity from the rendezvous store entry. Also, any consuming client requests arriving to the URL at this time (TB) can be fulfilled from the rendezvous store enty.
  • the proxy server determines first that the request is for near-channel service.
  • the consuming client may signal this desire using a parameter in the URL (/y;near), a value in an HTTP header field, or in any other suitable way.
  • the proxy server can calculate the proper store entry for near-channel service in the same way as it did for the rendezvous service.
  • the near-channel service could be provided by the conventional store entry for entity /y, for which the store key is calculated from the GET request; in this case, the lookup is the same as it would be for conventional GET requests, except that the proxy server does not go forward to the origin to fetch the entity if it is not present, expired, or otherwise not valid to serve.
  • the proxy server may maintain for a given entity /y three distinct store entries in the cache: (1) a rendezvous store entry that can correspond to the uploaded entity from a POST or PUT; (2) a near-channel store entry, which may be the same as the rendezvous store entry, or may be the same as the store entry for the entity retrieved from the origin in a conventional proxy server forward GET request operation, or may be a dedicated near-channel store entry and (3) the conventional store entry for /y retrieved from the origin in a conventional proxy server forward GET request operation. [0059] After time TD, the near-channel is no longer available.
  • a consuming client s GET request to the URL for entity /y can be handled using conventional logic for “cache miss handling”, that is, the proxy server validates the freshness of the entity stored in the store entry against an upstream parent cache or the origin, e.g., using an if-modified since request.
  • a fresh copy can be served to the consuming client and cached for the associated time to live period.
  • a stale copy is overwritten with a fresh copy fetched from origin.
  • the logic handling the pump-path can write the entity into a store entry by transforming the URL and other parameters of the POST into a GET and other parameters of the rendezvous request. This puts the conversion burden on the logic writing into the store entry, rather than on the logic reading out of the store entry in response to the rendezvous requests.
  • Entity Transfer Mode Producing Device Is A Server
  • FIG. 4A is similar to FIG. 1 A except that the device that produces the entity is a server rather than a client.
  • the proxy server first requests the entity from the producing server, e.g., using a HTTP GET. That request may be a long poll, for example.
  • the proxy server’s GET request may be synchronous to some other event or edge logic operating at the proxy server, and/or triggered by a request or other message received at the proxy server.
  • the producing server responds to the proxy server’s GET request by serving the entity to the proxy server.
  • FIG. 4B shows that in some embodiments, the proxy server does not provide rendezvous service for consuming clients.
  • the proxy server pumps the entity to a consuming server via a forward HTTP POST or PUT request.
  • the proxy server may make that POST/PUT request synchronously or asynchronously to the GET response that the proxy server received from the producing server.
  • FIGS. 4C and 4D are similar to FIGS. 4A and 4B, respectively. However
  • FIGS. 4C and 4D illustrate the use of HTTP/2 message exchanges, and server push in particular between the proxy server and producing server.
  • the producing server initiates the entity transfer process rather than the proxy server (acting as a client) doing so for the entity. More specifically, given an existing, open HTTP/2 stream between the proxy server and producing server, the producing server can issue a PUSH PROMISE frame on that open stream for the entity /y.
  • the producing server can push the entity /y on a new server-initiated stream, using an HTTP/2 response per RFC 7540, and finishing with an END STREAM frame.
  • FIG. 5 is a timing diagram related to FIGS. 4A and 4B.
  • FIG. 5 shows events occurring from the perspective of the proxy server.
  • the timeline illustrates when a consuming client may rendezvous with an entity from a producing server, as well as how the proxy server may issue an asynchronous POST/PUT to send that entity upstream to a consuming server.
  • FIG. 5 is similar to FIG. 2 in many respects; however, at time TB, instead of a producing client sending the entity /y , the proxy server requests the entity from the producing server and the producing server responds with the entity /y. (Of course the request and reply message exchange would not occur exactly simultaneously but for purposes of the diagram they are illustrated both at TB).
  • consuming clients may request the entity during a defined rendezvous time period beforehand, which is TB minus TA.
  • the time period TB to Tc a brief time after TB during which the entity is available and served to consuming clients that happen to arrive while the entity is received from the consuming server and being handled at the proxy server, e.g., contemporaneously with the entity being pumped upstream.
  • the near-channel service is available to consuming clients at the designated near-channel URL.
  • Tc to TD the near-channel service is no longer offered, finally stopping at TD.
  • time periods could be configured or event driven.
  • the proxy server synchronously transmits the entity upstream to a consuming server upon receipt from the producing server, using e.g., a forward HTTP POST/PUT request.
  • the proxy server can hold the entity for some period of time, and then asynchronously transfer the entity to the consuming server.
  • the holding period can be configurable or triggered by an event, such as the transfer channel to the consuming server becoming available/established/uncongested, which can ease any potential mismatch between the communication transfer characteristics of the client side and server side channels of the proxy server.
  • the asynchronous operation occurs at TE.
  • FIG. 6 illustrates, in greater detail, the operation of the proxy server shown in
  • FIGS. 4A, 4B and 5. The same circular labeling format is used as was already described with respect to FIG. 3.
  • FIG. 6 parallels FIG. 3 in many respects and the detailed description of proxy server operations provided in connection with FIG. 3 applies likewise.
  • the proxy server requests the entity (e.g., using an HTTP GET) at BC1, and the producing server responds at BC2.
  • the proxy server can copy the entity bytes into the rendezvous and near-channel store entry (BC4), concurrent with synchronously pumping the bytes to the consuming server (BC3).
  • Consuming clients can make requests at various times and upon request are served from the rendezvous and/or near-channel store entry (which once again are depicted here as a single entry in the data store). See AC1, AC2, CD1, and CD2, which represent the HTTP message exchanges during times TA to Tc and Tc to TD, respectively.
  • FIG. 6 illustrates an optional asynchronous operation in which the proxy server uploads the entity /y to the consuming server at some time TE.
  • the transfer buffer may no longer exist and if so the entity can be sourced from the store entry in the data store. See flow E in FIG. 6.
  • BC3 represents the synchronous upload
  • E represents the asynchronous upload
  • BC5 is meant to generically represent the acknowledgement to either one.
  • the URLS in the set above are predefined string transforms of one another, and this is preferable (but not necessary). It is preferable because given any one of the URLs, the proxy server, clients, or other devices, can can calculate the other URLs so as to be able to request those alternative services.
  • the service being requested can be signaled in ways other than in the URL.
  • it could be signaled using a specific HTTP header field value (including a cookie or token with a specific value).
  • any attribute of the request can be used.
  • the signaling could also be accomplished at other network layers, for example by configuring the proxy server to treat a particular client identifier (e.g. source or destination IP address) as a request for rendezvous, near-channel or other related service.
  • an HTTP request to a URL made to a first IP address of the proxy server may be treated as a request for conventional HTTP services, while an HTTP request to the same URL but to a second IP address of the proxy server may be treated as a rendezvous request.
  • a consuming device could also use an out of band channel to request rendezvous service for requests, including for groups or certain classes of requests that it expects to send.
  • the service being requested can also be something that the proxy server determines contextually, e.g., based on the time when the request is made. For example, a client request received during the rendezvous period or near-channel can be treated as a request for rendezvous or near-channel services, respectively. This may be thought of as the proxy server using “best efforts” to service a request locally, for entities that are configured as eligible for the services.
  • a producing server could utilize HTTP/2 server push to push an entity /y to the proxy server. It should be clear that likewise server push can be used (if desired) to push an entity from the proxy server to a consuming client during the time period TB to Tc.
  • a consuming client can open a HTTP/2 stream to the proxy server by sending a HTTP/2 GET request for /y;rendezvous, which the proxy server interprets as a request for entity /y with rendezvous service.
  • the proxy server could respond on that open stream with /y;rendezvous, which might be HTTP headers indicating that the connection is ok, and perhaps some meta-information about the arrival or status of entity /y in the data store or in the proxy server network.
  • /y;rendezvous which might be HTTP headers indicating that the connection is ok, and perhaps some meta-information about the arrival or status of entity /y in the data store or in the proxy server network.
  • the proxy server can issue a PUSH PROMISE frame for the entity /y on the existing HTTP/2 stream (assuming still open).
  • a PUSH PROMISE frame includes request headers and is effectively a server-initiated GET request for the promised entity.
  • the proxy server can push the entity /y over a new, server-initiated stream, using an HTTP/2 response with data frame(s) per RFC 7540, and finishing with an END STREAM frame.
  • FIGS. 3 and 6 would change as follows: message AC1 would represent the consuming client’s HTTP/2 GET request for /y;rendezvfous. Message AC2 would represent the proxy server’s server push of entity /y using the appropriate frames as described above. The HTTP/2 stream (and overall connection) would close at some later time, but that is not depicted.
  • Server push can also be used for near-channel requests.
  • teachings hereof may be implemented using conventional computer systems, but modified by the teachings hereof, with the components and/or functional characteristics described above realized in special-purpose hardware, general-purpose hardware configured by software stored therein for special purposes, or a combination thereof, as modified by the teachings hereof.
  • Software may include one or several discrete programs. Any given function may comprise part of any given module, process, execution thread, or other such programming construct. Generalizing, each function described above may be implemented as computer code, namely, as a set of computer instructions, executable in one or more microprocessors to provide a special purpose machine. The code may be executed using an apparatus - such as a microprocessor in a computer, digital data processing device, or other computing apparatus - as modified by the teachings hereof. In one embodiment, such software may be implemented in a programming language that runs in conjunction with a proxy on a standard Intel hardware platform running an operating system such as Linux. The functionality may be built into the proxy code, or it may be executed as an adjunct to that code.
  • FIG. 7 is a block diagram that illustrates hardware in a computer system 700 upon which such software may run in order to implement embodiments of the invention.
  • the computer system 700 may be embodied in a client device, server, personal computer, workstation, tablet computer, mobile or wireless device such as a smartphone, network device, router, hub, gateway, or other device.
  • Representative machines on which the subject matter herein is provided may be a computer running a Linux or Linux -variant operating system and one or more applications to carry out the described functionality.
  • Computer system 700 includes a microprocessor 704 coupled to bus 701. In some systems, multiple processor and/or processor cores may be employed. Computer system 700 further includes a main memory 710, such as a random access memory (RAM) or other storage device, coupled to the bus 701 for storing information and instructions to be executed by processor 704. A read only memory (ROM) 708 is coupled to the bus 701 for storing information and instructions for processor 704. A non-volatile storage device 706, such as a magnetic disk, solid state memory (e.g., flash memory), or optical disk, is provided and coupled to bus 701 for storing information and instructions. Other application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or circuitry may be included in the computer system 700 to perform functions described herein.
  • ASICs application-specific integrated circuits
  • FPGAs field programmable gate arrays
  • a peripheral interface 712 may be provided to communicatively couple computer system 700 to a user display 714 that displays the output of software executing on the computer system, and an input device 715 (e.g., a keyboard, mouse, trackpad, touchscreen) that communicates user input and instructions to the computer system 700.
  • a computer system 700 may not have a user interface beyond a network port, e.g., in the case of a server in a rack.
  • the peripheral interface 712 may include interface circuitry, control and/or level-shifting logic for local buses such as RS- 485, Universal Serial Bus (USB), IEEE 1394, or other communication links.
  • Computer system 700 is coupled to a communication interface 716 that provides a link (e.g., at a physical layer, data link layer,) between the system bus 701 and an external communication link.
  • the communication interface 716 provides a network link 718.
  • the communication interface 716 may represent an Ethernet or other network interface card (NIC), a wireless interface, modem, an optical interface, or other kind of input/output interface.
  • Network link 718 provides data communication through one or more networks to other devices. Such devices include other computer systems that are part of a local area network (LAN) 726.
  • the network link 718 provides a link, via an internet service provider (ISP) 720, to the Internet 722.
  • ISP internet service provider
  • the Internet 722 may provide a link to other computing systems such as a remote server 730 and/or a remote client 731.
  • Network link 718 and such networks may transmit data using packet-switched, circuit-switched, or other data-transmission approaches.
  • the computer system 700 may implement the functionality described herein as a result of the processor executing code.
  • code may be read from or stored on a non-transitory computer-readable medium, such as memory 710, ROM 708, or storage device 706.
  • a non-transitory computer-readable medium such as memory 710, ROM 708, or storage device 706.
  • Other forms of non-transitory computer-readable media include disks, tapes, magnetic media, SSD, CD-ROMs, optical media, RAM, PROM, EPROM, and EEPROM, flash memory. Any other non-transitory computer-readable medium may be employed.
  • Executing code may also be read from network link 718 (e.g., following storage in an interface buffer, local memory, or other circuitry).

Landscapes

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

Abstract

Un serveur mandataire est augmenté avec la capacité de prendre possession transitoire d'une entité reçue à des fins d'utilisation de dispositifs consommateurs. Cette capacité complète des transactions de transfert de destination et/ou de serveur d'origine effectuées par le serveur mandataire. Cette capacité active plusieurs modes de transfert d'entité, y compris un service de rendez-vous, dans lesquels le serveur mandataire peut (s'il est appelé par un client) satisfaire une demande de client auprès d'une entité que le serveur mandataire reçoit d'un dispositif de production en même temps que (ou peu après) la demande pour cette entité. Il active également des transferts de serveur à serveur avec un comportement de transfert de destination synchrone ou asynchrone. Il active également un mode dans lequel les clients peuvent demander différentes représentations d'entités, par exemple, à partir du canal proche (par exemple, la version stockée au niveau du serveur mandataire) ou d'un canal lointain (par exemple, au niveau d'un serveur d'origine). Les enseignements de la présente invention sont compatibles, bien qu'ils ne s'y limitent pas, avec des protocoles de messagerie HTTP classiques, y compris des procédés GET, POST et PUT.
PCT/US2022/071819 2021-04-23 2022-04-20 Modes de transfert d'entité de serveur mandataire WO2022226510A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22722104.1A EP4327543A1 (fr) 2021-04-23 2022-04-20 Modes de transfert d'entité de serveur mandataire

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202163201337P 2021-04-23 2021-04-23
US63/201,337 2021-04-23
US17/325,450 US11343344B1 (en) 2021-04-23 2021-05-20 Proxy server entity transfer modes
US17/325,450 2021-05-20

Publications (1)

Publication Number Publication Date
WO2022226510A1 true WO2022226510A1 (fr) 2022-10-27

Family

ID=81585871

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/071819 WO2022226510A1 (fr) 2021-04-23 2022-04-20 Modes de transfert d'entité de serveur mandataire

Country Status (2)

Country Link
EP (1) EP4327543A1 (fr)
WO (1) WO2022226510A1 (fr)

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6108703A (en) 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
US6658463B1 (en) * 1999-06-10 2003-12-02 Hughes Electronics Corporation Satellite multicast performance enhancing multicast HTTP proxy system and method
US7058706B1 (en) 2000-03-31 2006-06-06 Akamai Technologies, Inc. Method and apparatus for determining latency between multiple servers and a client
US7096263B2 (en) 2000-05-26 2006-08-22 Akamai Technologies, Inc. Method for predicting file download time from mirrored data centers in a global computer network
US7096266B2 (en) 2001-01-08 2006-08-22 Akamai Technologies, Inc. Extending an Internet content delivery network into an enterprise
US7240100B1 (en) 2000-04-14 2007-07-03 Akamai Technologies, Inc. Content delivery network (CDN) content server request handling mechanism with metadata framework support
US7251688B2 (en) 2000-05-26 2007-07-31 Akamai Technologies, Inc. Method for generating a network map
US7274658B2 (en) 2001-03-01 2007-09-25 Akamai Technologies, Inc. Optimal route selection in a content delivery network
US7293093B2 (en) 2000-04-17 2007-11-06 Akamai Technologies, Inc. HTML delivery from edge-of-network servers in a content delivery network (CDN)
US7484002B2 (en) 2000-08-18 2009-01-27 Akamai Technologies, Inc. Content delivery and global traffic management network system
US7523181B2 (en) 1999-11-22 2009-04-21 Akamai Technologies, Inc. Method for determining metrics of a content delivery and global traffic management network
US7574499B1 (en) 2000-07-19 2009-08-11 Akamai Technologies, Inc. Global traffic management system using IP anycast routing and dynamic load-balancing
US7603439B2 (en) 2002-04-09 2009-10-13 Akamai Technologies, Inc. System for tiered distribution in a content delivery network
US7716367B1 (en) 2000-07-20 2010-05-11 Akamai Technologies, Inc. Network performance monitoring in a content delivery service
US7725602B2 (en) 2000-07-19 2010-05-25 Akamai Technologies, Inc. Domain name resolution using a distributed DNS network
US20100268789A1 (en) * 2009-04-17 2010-10-21 Microsoft Corporation Network caching for multiple contemporaneous requests
US7912978B2 (en) 2000-07-19 2011-03-22 Akamai Technologies, Inc. Method for determining metrics of a content delivery and global traffic management network
US7925713B1 (en) 1999-11-22 2011-04-12 Akamai Technologies, Inc. Method for operating an integrated point of presence server network
US7996531B2 (en) 2001-06-06 2011-08-09 Akamai Technologies, Inc. Content delivery network map generation using passive measurement data

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6108703A (en) 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
US6658463B1 (en) * 1999-06-10 2003-12-02 Hughes Electronics Corporation Satellite multicast performance enhancing multicast HTTP proxy system and method
US7925713B1 (en) 1999-11-22 2011-04-12 Akamai Technologies, Inc. Method for operating an integrated point of presence server network
US7523181B2 (en) 1999-11-22 2009-04-21 Akamai Technologies, Inc. Method for determining metrics of a content delivery and global traffic management network
US7058706B1 (en) 2000-03-31 2006-06-06 Akamai Technologies, Inc. Method and apparatus for determining latency between multiple servers and a client
US7240100B1 (en) 2000-04-14 2007-07-03 Akamai Technologies, Inc. Content delivery network (CDN) content server request handling mechanism with metadata framework support
US7293093B2 (en) 2000-04-17 2007-11-06 Akamai Technologies, Inc. HTML delivery from edge-of-network servers in a content delivery network (CDN)
US7251688B2 (en) 2000-05-26 2007-07-31 Akamai Technologies, Inc. Method for generating a network map
US7096263B2 (en) 2000-05-26 2006-08-22 Akamai Technologies, Inc. Method for predicting file download time from mirrored data centers in a global computer network
US7574499B1 (en) 2000-07-19 2009-08-11 Akamai Technologies, Inc. Global traffic management system using IP anycast routing and dynamic load-balancing
US7725602B2 (en) 2000-07-19 2010-05-25 Akamai Technologies, Inc. Domain name resolution using a distributed DNS network
US8195831B2 (en) 2000-07-19 2012-06-05 Akamai Technologies Inc. Method and apparatus for determining and using server performance metrics with domain name services
US7912978B2 (en) 2000-07-19 2011-03-22 Akamai Technologies, Inc. Method for determining metrics of a content delivery and global traffic management network
US7716367B1 (en) 2000-07-20 2010-05-11 Akamai Technologies, Inc. Network performance monitoring in a content delivery service
US7484002B2 (en) 2000-08-18 2009-01-27 Akamai Technologies, Inc. Content delivery and global traffic management network system
US7096266B2 (en) 2001-01-08 2006-08-22 Akamai Technologies, Inc. Extending an Internet content delivery network into an enterprise
US7274658B2 (en) 2001-03-01 2007-09-25 Akamai Technologies, Inc. Optimal route selection in a content delivery network
US7996531B2 (en) 2001-06-06 2011-08-09 Akamai Technologies, Inc. Content delivery network map generation using passive measurement data
US7603439B2 (en) 2002-04-09 2009-10-13 Akamai Technologies, Inc. System for tiered distribution in a content delivery network
US20100268789A1 (en) * 2009-04-17 2010-10-21 Microsoft Corporation Network caching for multiple contemporaneous requests

Also Published As

Publication number Publication date
EP4327543A1 (fr) 2024-02-28

Similar Documents

Publication Publication Date Title
US7698386B2 (en) Serving content from an off-line peer server in a photosharing peer-to-peer network in response to a guest request
US9906447B2 (en) Caching data in an information centric networking architecture
US10225362B2 (en) Processing DNS queries to identify pre-processing information
US7979563B2 (en) Method and system for dynamic client/server network management using proxy servers
US8234414B2 (en) Proxy caching in a photosharing peer-to-peer network to improve guest image viewing performance
US20180041599A1 (en) Systems and methods for controlling cacheability and privacy of objects
US10275412B2 (en) Method and device for database and storage aware routers
WO2015096801A1 (fr) Procédé et appareil d'accélération de la transmission de données dans un système de communications en réseau
US20090165115A1 (en) Service providing system, gateway, and server
US20050117558A1 (en) Method for reducing data transport volume in data networks
US10536561B2 (en) Data stream pipelining and replication at a delivery node of a content delivery network
JP2012501493A (ja) 画像処理方法、画像処理装置および画像処理システム
US20110280247A1 (en) System and method for reducing latency via multiple network connections
US9848067B2 (en) Managing sequence values with added headers in computing devices
US20180091631A1 (en) Systems and methods for writing prioritized http/2 data to a socket buffer
EP4324183A1 (fr) Acheminement de messages et service de mise à jour en temps réel dans un réseau de serveurs mandataires
EP3389240B1 (fr) Procédé et système de traitement d'un service de grappe de cache
US10742751B2 (en) User based mDNS service discovery
US10122630B1 (en) Methods for network traffic presteering and devices thereof
US11343344B1 (en) Proxy server entity transfer modes
CN110719307A (zh) 数据传输方法、客户端、服务端及计算机可读存储介质
WO2022226510A1 (fr) Modes de transfert d'entité de serveur mandataire
EP3128711A1 (fr) Procédé, serveur et équipement utilisateur d'acquisition d'objet d'information
EP4231607A1 (fr) Procédé de transmission de données et appareil de communication
Herrero et al. Application layer

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22722104

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022722104

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022722104

Country of ref document: EP

Effective date: 20231123