U.S. patent application number 16/133533 was filed with the patent office on 2019-01-17 for latency measurement in resource requests.
The applicant listed for this patent is Amazon Technologies, Inc.. Invention is credited to John David Cormie, Colm Gearoid MacCarthaigh, Benjamin W.S. Redman, David R. Richardson.
Application Number | 20190020562 16/133533 |
Document ID | / |
Family ID | 56507326 |
Filed Date | 2019-01-17 |
View All Diagrams
United States Patent
Application |
20190020562 |
Kind Code |
A1 |
Richardson; David R. ; et
al. |
January 17, 2019 |
LATENCY MEASUREMENT IN RESOURCE REQUESTS
Abstract
Systems and method for the management and processing of resource
requests by a service provider, such as a content delivery network
("CDN") service provider, on behalf of a content provider are
provided. The CDN service provider can measure the performance
associated with the delivery of resources to a requesting client
computing devices from various computing devices associated with
the CDN service provider. In one embodiment, a client computing
device can execute code, such as scripts, that cause the client
computing device to transmit requests to different computing
devices associated with the CDN service provider's domain.
Information associated with the processing of the responses can be
used to measure CDN service provider latencies.
Inventors: |
Richardson; David R.;
(Seattle, WA) ; Cormie; John David; (Seattle,
WA) ; MacCarthaigh; Colm Gearoid; (Seattle, WA)
; Redman; Benjamin W.S.; (Seattle, WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Amazon Technologies, Inc. |
Seattle |
WA |
US |
|
|
Family ID: |
56507326 |
Appl. No.: |
16/133533 |
Filed: |
September 17, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13621022 |
Sep 15, 2012 |
10079742 |
|
|
16133533 |
|
|
|
|
12892852 |
Sep 28, 2010 |
9407681 |
|
|
13621022 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 67/101 20130101;
H04L 29/06 20130101; H04L 67/10 20130101; H04L 43/0876 20130101;
H04L 67/02 20130101 |
International
Class: |
H04L 12/26 20060101
H04L012/26; H04L 29/08 20060101 H04L029/08; H04L 29/06 20060101
H04L029/06 |
Claims
1. A computer-implemented method comprising: obtaining, by a client
computing device, a set of content for display on the client
computing device, wherein the set of content includes instructions
for causing the client computing device to generate a first request
and a second request to a service provider to determine latency
information for different components of the service provider,
wherein the instructions include an IP address associated with a
point of presence (POP) of the service provider for receipt of
individual requests, wherein the first and second requests are
configured for transmission to different components of the service
provider; generating, by the client computing device, the first and
second requests based on an execution of the instructions included
in the set of content, wherein the first request is configured to
be directed to a first IP address of a first component of the
service provider and the second request is configured to be
directed to a second IP address of a second component of the
service provider, wherein the first and second components of the
service provider are different; and determining, by the client
computing device, latency for each of the first and second
requests, wherein the determining includes collecting information
associated with the respective first and second requests to
determine latency information, and wherein the latency information
corresponds to a communication latency between the client computing
device and the first and second identified components of the
service provider respectively.
2. The method as recited in claim 1 further comprising transmitting
the determined latencies from the client computing device to the
service provider.
3. The method as recited in claim 1, wherein the second request is
a request for a special resource, wherein the request for the
special resource does not result in delivery of an actual resource
to the client computing device.
4. The method as recited in claim 1, wherein the first request is
not a request for a resource to be generated by the client
computing device.
5. The method as recited in claim 1, wherein the second request
identifies the same resource as the first request.
6. The method as recited in claim 1, wherein the first request is
not a request for a resource to be transmitted by the service
provider or for a resource to be generated by the client computing
device.
7. The method as recited in claim 1, wherein the service provider
corresponds to a content delivery network service provider.
8. A computer-implemented system comprising: at least one client
computing device that is operative to: obtain a set of content for
display on the at least one client computing device, wherein the
set of content includes instructions for causing the at least one
client computing device to generate a first request and a second
request to a service provider to determine latency information for
different components of the service provider, wherein the
instructions include an IP address associated with a point of
presence (POP) of the service provider for receipt of individual
requests, wherein the first and second requests are configured for
transmission to different components of the service provider;
generate the first and second requests based on an execution of the
instructions, wherein the first request is configured to be
directed to a first IP address of a first component of the service
provider and the second request is configured to be directed to a
second IP address of a second component of the service provider,
wherein the first and second components of the service provider are
different; and determine, at the at least one client computing
device, latency for each of the first and second requests, wherein
the determining includes collecting information associated with the
respective first and second requests to determine latency
information, and wherein the latency information corresponds to a
communication latency between the client computing device and the
first and second identified components of the service provider
respectively.
9. The system as recited in claim 8, wherein the at least one
client computing device is further operative to transmit the
determined latencies from the client computing device to the
service provider.
10. The system as recited in claim 8, wherein the second request is
a request for a special resource, wherein the request for the
special resource does not result in delivery of an actual resource
to the client computing device.
11. The system as recited in claim 8, wherein the first request is
not a request for a resource to be generated by the client
computing device.
12. The system as recited in claim 8, wherein the second request
identifies the same resource as the first request.
13. The system as recited in claim 8, wherein the first request is
not a request for a resource to be transmitted by the service
provider or for a resource to be generated by the client computing
device.
14. A computer-implemented system comprising: a data store for
storing performance metric information associated with processing
content requests; and at least one client computing device in
communication with said data store that is operative to: obtain a
set of content for display on the at least one client computing
device, wherein the set of content includes instructions for
causing the at least one client computing device to generate a
first request and a second request to a service provider to
determine latency information for different components of the
service provider, wherein the instructions include an IP address
associated with a point of presence (POP) of the service provider
for receipt of individual requests, wherein the first and second
requests are configured for transmission to different components of
the service provider; generate the first and second requests based
on an execution of the instructions included in the set of content,
wherein the first request is configured to be directed to a first
IP address of a first component of the service provider and the
second request is configured to be directed to a second IP address
of a second component of the service provider, wherein the first
and second components of the service provider are different; and
measure, by the at least one client computing device, latency
information corresponding to processing the generated first and
second requests at the client computing device, wherein the
measuring includes collecting information associated with the
respective first and second requests to determine latency
information, and wherein the latency information corresponds to a
communication latency between the client computing device and the
first and second identified components of the service provider
respectively.
15. The system as recited in claim 14, wherein the at least one
client computing device is further operative to transmit, by the
client computing device, the performance metric information
corresponding to processing the generated first and second requests
to the service provider.
16. The system as recited in claim 14, wherein the second request
is a request for a special resource, wherein the request for the
special resource does not result in delivery of an actual resource
to the client computing device.
17. The system as recited in claim 14, wherein the first request is
not a request for a resource to be generated by the client
computing device.
18. The system as recited in claim 14, wherein the second request
identifies the same resource as the first request.
19. The system as recited in claim 14, wherein the first request is
not a request for a resource to be transmitted by the service
provider or for a resource to be generated by the client computing
device.
20. The system as recited in claim 14, wherein the service provider
corresponds to a content delivery network service provider.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 13/621,022, entitled "LATENCY MEASUREMENT IN
RESOURCE REQUESTS" and filed on Sep. 15, 2012, which in turn is a
divisional of U.S. patent application Ser. No. 12/892,852, now U.S.
Pat. No. 9,407,681, entitled "LATENCY MEASUREMENT IN RESOURCE
REQUESTS" and filed Sep. 28, 2010, the disclosures of which are
incorporated herein by reference.
BACKGROUND
[0002] Generally described, computing devices and communication
networks can be utilized to exchange information. In a common
application, a computing device can request content from another
computing device via a communication network. For example, a user
at a personal computing device can utilize a software browser
application to request a Web page from a server computing device
via the Internet. In such embodiments, the user computing device
can be referred to as a client computing device and the server
computing device can be referred to as a content provider.
[0003] Content providers are generally motivated to provide
requested content to client computing devices often with
consideration of efficient transmission of the requested content to
the client computing device and/or consideration of a cost
associated with the transmission of the content. For larger scale
implementations, a content provider may receive content requests
from a high volume of client computing devices, which can place a
strain on the content provider's computing resources. Additionally,
the content requested by the client computing devices may have a
number of components, which can further place additional strain on
the content provider's computing resources.
[0004] With reference to an illustrative example, a requested Web
page, or original content, may be associated with a number of
additional resources, such as images or videos, which are to be
displayed with the Web page. In one specific embodiment, the
additional resources of the Web page are identified by a number of
embedded resource identifiers, such as uniform resource locators
("URLs"). In turn, software on the client computing devices
typically processes embedded resource identifiers to generate
requests for the content. Often, the embedded resource identifiers
reference computing devices associated with the content provider
such that the client computing devices would transmit requests for
resources to the referenced content provider computing devices.
[0005] Some content providers attempt to facilitate the delivery of
requested content, such as Web pages and/or resources identified in
Web pages, through the utilization of a content delivery network
("CDN") service provider. A CDN service provider typically
maintains a number of computing devices in a communication network
that can maintain content from various content providers. In turn,
content providers can instruct, or otherwise suggest to, client
computing devices to request some, or all, of the content
provider's content from the CDN service provider's computing
devices.
[0006] CDN service providers are also generally motivated to
provide requested content to client computing devices often with
consideration of efficient transmission of the requested content to
the client computing device or consideration of a cost associated
with the transmission of the content. Typically, CDN service
providers often consider factors such as latency of delivery of
requested content in order to meet service level agreements or
generally improve the quality of delivery service. In turn, the CDN
service provider can utilize the considered factors in processing
resource requests.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The foregoing aspects and many of the attendant advantages
of this invention will become more readily appreciated as the same
become better understood by reference to the following detailed
description, when taken in conjunction with the accompanying
drawings, wherein:
[0008] FIG. 1 is a block diagram illustrative of a content delivery
environment including a number of client computing devices, a
content provider, and a content delivery network service
provider;
[0009] FIG. 2 is a block diagram of the content delivery
environment of FIG. 1 illustrating the registration of a content
provider with a CDN service provider;
[0010] FIG. 3 is a block diagram of the content delivery
environment of FIG. 1 illustrating the generation of resource
requests by a client computing device;
[0011] FIGS. 4A-4C are block diagrams of the content delivery
environment of FIG. 1 illustrating the generation of multiple
embedded resource requests by a client computing device based on
the execution of executable code;
[0012] FIG. 5 is a flow diagram illustrative of resource identifier
processing routine implemented by a client computing device;
[0013] FIG. 6 is a block diagram of the content delivery
environment of FIG. 1 illustrating the registration of a content
provider with a CDN service provider;
[0014] FIG. 7 is a block diagram of the content delivery
environment of FIG. 1 illustrating the generation of resource
requests by a client computing device;
[0015] FIG. 8 is a block diagram of the content delivery
environment of FIG. 1 illustrating the generation of resource
requests by a client computing device responsive to a redirection
command provided by a CDN service provider;
[0016] FIG. 9 is a flow diagram illustrative of a resource request
processing routine implemented by a CDN service provider;
[0017] FIG. 10 is a block diagram of the content delivery
environment of FIG. 1 illustrating the generation of resource
requests by a client computing device;
[0018] FIG. 11 is a block diagram of the content delivery
environment of FIG. 1 illustrating the protocol interaction between
a client computing device and multiple Point of Presence associated
with a CDN service provider; and
[0019] FIG. 12 is a flow diagram illustrative of a resource request
processing routine implemented by a CDN service provider.
DETAILED DESCRIPTION
[0020] Generally described, the present disclosure is directed to
managing resource requests for one or more resources associated
with a content provider. Specifically, aspects of the disclosure
will be described with regard to the management and processing
resource requests by a service provider, such as a content delivery
network ("CDN") service provider, on behalf of a content provider.
Illustratively, the CDN service provider can measure the
performance associated with the delivery of resources to a
requesting client computing devices from various computing devices
associated with the CDN service provider. In one embodiment, client
computing devices can be provided executable code, such as scripts,
that cause the client computing device to transmit requests to
different computing devices associated with the CDN service
provider's domain. Information associated with the processing of
the responses can be used to measure CDN service provider
latencies. In another embodiment, the CDN service provider can
utilize commands responsive to an initial request for a resource
that causes the requesting client computing device to transmit one
or more supplemental resource requests to computing devices
associated with the CDN service provider's domain. Information
associated with the processing of the sequence of resource requests
can be used to measure CDN service provider latencies. In a further
embodiment, the CDN service provider can utilize commands
corresponding to communication protocols that cause the requesting
client computing device to transmit or receive protocol information
from multiple computing devices associated with the CDN service
provider's domain. Information associated with the processing of
the protocol responses can be used to measure CDN service provider
latencies.
[0021] Although various aspects of the disclosure will be described
with regard to illustrative examples and embodiments, one skilled
in the art will appreciate that the disclosed embodiments and
examples should not be construed as limiting. For example, the
present disclosure may be described with regard to request routing
services provided by a service provider, such as a CDN service
provider, that may provide additional services and functionality
including network-based storage services, caching services,
application hosting, or other services. However, one skilled in the
relevant art will appreciate that a service provider need not
provide all, or any, of the additional services or functionality
that may be associated with some service providers, such as a CDN
service provider. Additionally, although various embodiments will
be described with regard to the measurement of performance or
latencies associated with the processing of resource requests, one
skilled in the relevant art will further appreciate that the
various embodiments may be practiced independently or combined in
various manners.
[0022] FIG. 1 is a block diagram illustrative of content delivery
environment 100 for the management and processing of content
requests. As illustrated in FIG. 1, the content delivery
environment 100 includes a number of client computing devices 102
(generally referred to as clients) for requesting content from a
content provider and/or a CDN service provider. In an illustrative
embodiment, the client computing devices 102 can correspond to a
wide variety of computing devices including personal computing
devices, laptop computing devices, hand-held computing devices,
terminal computing devices, mobile devices, wireless devices,
various electronic devices and appliances and the like. In an
illustrative embodiment, the client computing devices 102 include
necessary hardware and software components for establishing
communications over a communication network 108, such as a wide
area network or local area network. For example, the client
computing devices 102 may be equipped with networking equipment and
browser software applications that facilitate communications via
the Internet or an intranet.
[0023] Although not illustrated in FIG. 1, each client computing
device 102 can utilize some type of local DNS resolver component,
such as a DNS Name server, that generates the DNS queries
attributed to the client computing device 102. In one embodiment,
the local DNS resolver component may be provided by an enterprise
network to which the client computing device 102 belongs. In
another embodiment, the local DNS resolver component may be
provided by an Internet Service Provider (ISP) that provides the
communication network connection to the client computing device
102. However, for purposes of the present disclosure,
communications facilitated through a network component, such as a
DNS Resolver component, will be illustrated as transmitted directly
from the client computing devices 102.
[0024] The content delivery environment 100 can also include a
content provider 104 in communication with the one or more client
computing devices 102 via the communication network 108. The
content provider 104 illustrated in FIG. 1 corresponds to a logical
association of one or more computing devices associated with a
content provider. Specifically, the content provider 104 can
include a web server component 110 corresponding to one or more
server computing devices for obtaining and processing requests for
content (such as Web pages) from the client computing devices 102.
The content provider 104 can further include an origin server
component 112 and associated storage component 114 corresponding to
one or more computing devices for obtaining and processing requests
for network resources from the CDN service provider. One skilled in
the relevant art will appreciate that the content provider 104 can
be associated with various additional computing resources, such as
additional computing devices for administration of content and
resources, DNS name servers, and the like. For example, although
not illustrated in FIG. 1, the content provider 104 can be
associated with one or more DNS name server components that would
be authoritative to resolve client computing device DNS queries
corresponding to a domain of the content provider.
[0025] With continued reference to FIG. 1, the content delivery
environment 100 can further include a CDN service provider 106 in
communication with the one or more client computing devices 102 and
the content provider 104 via the communication network 108. The CDN
service provider 106 illustrated in FIG. 1 corresponds to a logical
association of one or more computing devices associated with a CDN
service provider. Specifically, the CDN service provider 106 can
include a number of Point of Presence (herein "POP") locations 116,
122, 128 that correspond to nodes on the communication network 108.
Each POP 116, 122, 128 includes a DNS component 118, 124, 130 made
up of a number of DNS server computing devices for resolving DNS
queries from the client computing devices 102. Each POP 116, 122,
128 also includes a resource cache component 120, 126, 132 made up
of a number of cache server computing devices for storing resources
from content providers and transmitting various requested resources
to various client computers. The DNS components 118, 124 and 130
and the resource cache components 120, 126 132 may further include
additional software and/or hardware components that facilitate
communications including, but not limited, load balancing or load
sharing software/hardware components.
[0026] In an illustrative embodiment, the DNS component 118, 124,
130 and resource cache component 120, 126, 132 are considered to be
logically grouped, regardless of whether the components, or
portions of the components, are physically separate. Additionally,
although the POPs 116, 122, 128 are illustrated in FIG. 1 as
logically associated with the CDN service provider 106, the POPs
will be geographically distributed throughout the communication
network 108 in a manner to best serve various demographics of
client computing devices 102. Additionally, one skilled in the
relevant art will appreciate that the CDN service provider 106 can
be associated with various additional computing resources, such as
additional computing devices for administration of content and
resources, and the like.
[0027] With reference now to FIGS. 2-4, one embodiment related to
the interaction between various components of the content delivery
environment 100 of FIG. 1 will be illustrated. For purposes of the
example, however, the illustration has been simplified such that
many of the components utilized to facilitate communications are
not shown. One skilled in the relevant art will appreciate that
such components can be utilized and that additional interactions
would accordingly occur without departing from the spirit and scope
of the present disclosure.
[0028] With reference to FIG. 2, an illustrative interaction for
the optional registration of a content provider 104 with the CDN
service provider 106 for hosting content on behalf of the content
provider 104 will be described. As illustrated in FIG. 2, the CDN
service provider content registration process begins with
registration of the content provider 104 with the CDN service
provider 106. In an illustrative embodiment, the content provider
104 utilizes a registration application program interface ("API")
to register with the CDN service provider 106 such that the CDN
service provider 106 can provide content on behalf of the content
provider 104, or at least perform the processes described herein.
Illustratively, the registration API can include the identification
of the origin server 114 of the content provider 104 that may
provide requested resources to the CDN service provider 106. In
addition or alternatively, the registration API can include the
content to be stored by the CDN service provider 106 on behalf of
the content provider 104. Additionally, the content provider 104
can specify one or more network storage providers (not illustrated)
that may act as an origin server for the content provider 104.
[0029] With continued reference to FIG. 2, upon receiving the
registration API, the CDN service provider 106 obtains the
registration information and generates, or otherwise obtains,
embedded resource identifiers that will be utilized in the mapping
of client identifiers. In an illustrative embodiment, and as will
be explained in greater detail below, the embedded resource
identifiers correspond to data or instructions that are processed
by the client computing devices 102 to cause the client computing
devices 102 to request specific resources from the CDN service
provider 106. The resources may correspond to content, such as
multi-media content, that is being hosted on behalf of the content
provider 104. Additionally, in this illustrative embodiment, the
CDN service provider 106 generates, or otherwise obtains,
executable code that causes the client computing device to transmit
resource requests to one or more computing devices associated with
the CDN service provider 106. Unlike requests related to the
embedded resource identifiers, the transmission of requests to the
CDN service provider 106 based on the execution of the executable
code may not result in the transmittal of actual content by the CDN
service provider 106.
[0030] The CDN service provider 106 returns the resource
identifiers and executable code to the content provider 104 along
with any additional information. In turn, the content provider 104
can then store for the embedded resource identifiers for embedding
in requested content or otherwise embed (or associate) the embedded
resource identifiers and executable code with requested content
(such as Web page markup language). In an illustrative embodiment,
the embedded resource identifiers can be applicable to multiple
content providers 104. Alternatively, the embedded resource
identifiers can be unique to each particular content provider 104.
Still further, the CDN service provider 106 may provide additional
logic to the content providers 104 that controls the circumstances
or methodologies for processing the embedded resource identifiers
and executable code provided in the requested content, such as
executing the executable code. For example, the embedded resource
identifiers can include instructions (or executable code) that
defines that the type of content (e.g., specific Web pages) for
which the embedded resource identifiers will apply.
[0031] With reference now to FIG. 3, after completion of the
registration and embedding processes illustrated in FIG. 2, a
client computing device 102 generates a content request that is
received and processed by the content provider 104, such as through
the Web server 110. In accordance with an illustrative embodiment,
the request for content can be in accordance with common network
protocols, such as the hypertext transfer protocol ("HTTP"). Upon
receipt of the content request, the content provider identifies the
appropriate responsive content. In an illustrative embodiment, the
requested content can correspond to a Web page that is displayed on
the client computing device 102 via the processing of information,
such as hypertext markup language ("HTML"), extensible markup
language ("XML"), and the like.
[0032] As previously described, the requested content can include a
number of embedded resource identifiers that corresponds to
resource objects that should be obtained by the client computing
device 102 as part of the processing of the requested content. The
embedded resources can corresponds to multi-media content, such as
images, videos, text, etc. that will be processed by the client
computing devices 102 and rendered on output device. Additionally,
the requested content will also include the additional executable
code previously provided by the CDN service provider 106 (FIG. 2).
In an illustrative embodiment, the embedded executable code
previously provided by the CDN service provider 106 can be arranged
in a manner such that it is processed prior to processing any other
of the content in the requested content or processed in the earlier
stages of the processing of the requested content, as allowed.
Alternatively, the embedded executable code previously provided by
the CDN service provider 106 can also be arranged such that it is
processed after all any other embedded resources are process so as
to mitigate any type of interference or delay in the processing of
other embedded resources/identifiers. Examples of executable code
that can be included in the content requests include scripts
executable by a browser software application, stand-alone
executable software code, intermediate software code requiring
additional processing, and the like.
[0033] Generally, the identification of the embedded resources
provided by the content provider 104 will be in the form of
resource identifiers that can be processed by the client computing
device 102, such as through a browser software application. In an
illustrative embodiment, the resource identifiers can be in the
form of a uniform resource locator ("URL"). For purposes of an
illustrative example, the URL can identify a domain of the content
provider 104 (e.g., contentprovider.com) or CDN service provider
106 (e.g., CDNserviceprovider), a name of the resource to be
requested (e.g., "resource.xxx") and a path where the resource will
be found (e.g., "path"). By way of an illustrative example, the
URLs of the embedded resource have the form of: [0034]
http://www.contentprovider.com/path/resource.xxx [0035] or [0036]
http://www.CDNserviceprovider.com/path/resource.xxx
[0037] Additionally, in an illustrative embodiment, any additional
embedded resource identifiers previously provided by the CDN
service provider 106 during the registration process (FIG. 2) will
also be in the form of a resource identifier (e.g., URLs) that can
be processed by the client computing device 102, such as through a
browser software application. For purposes of an illustrative
example, the URL can identify a domain of the CDN service provider
106 (e.g., CDNserviceprovider.com), a name of a resource to be
requested (e.g., "resource.xxx") and a path where the resource will
be found (e.g., "path"). As will be explained in greater detail,
the additional embedded resource identifiers previously provided by
the CDN service provider 106 will identify a special resource such
that a request for the special resource may not result in the
delivery of an actual resource to the requesting client computing
device 102. Accordingly, additional embedded resource identifiers
can correspond to a different or the same domain as the other
embedded resource identifiers included in the content request. In
this illustrative example, the URLs of the additional embedded
resource identifiers can have the form of: [0038]
http://www.CDNservieprovider.com/path/resoure.xxx
[0039] With reference now to FIG. 4A, upon receipt of the requested
content, including the embedded resource identifiers and the
executable code previously provided by the CDN service provider
106, the client computing device 102 processes the received
information in a manner that causes the client computing device 102
to request embedded resource previously provided by the CDN service
provider 106 from the CDN service provider 106. In accordance with
an embodiment utilizing the hypertext transfer protocol ("HTTP"),
the request of a resource can correspond to a GET request
transmitted by the client computing device 102 to an IP address
associated with CDN service provider 106. Although not illustrated
in FIG. 4A, the client computing device 102 would first issue a DNS
query for the embedded resource previously provided by the CDN
service provider 102, which if properly resolved, would include the
identification of the above mentioned IP address associated with
the CDN service provider 106. One skilled in the relevant art will
appreciate that the resolution of the DNS query may involve
multiple DNS queries to either the content provider 104 or CDN
service provider 106.
[0040] With continued reference to FIG. 4A, the client computing
device 102 also processes the executable code, such as a script,
that causes the client computing device to generate one or more
resource requests, or other types of data exchange between the CDN
service provider 106 and the client computing device. In one
embodiment, the request of a resource can also correspond to a GET
request transmitted by the client computing device 102 to an IP
address associated with CDN service provider 106. However, the
resulting resource request generated by the client computing device
102 does not have to result in the transmission of resource from
the CDN service provider 106. Upon receipt of the resource request,
the receiving POP, POP 116 processes the request and returns a
response. Illustratively, the processing of the resource request
can include the collection or logging of information associated
with the resource request that will allow the CDN service provider
106 to determine performance metric information. The processing of
the resource request can also include the generation of identifiers
or other information that is returned to the client computing
device 102 and that can be collected by the client computing device
for purposes of determining performance metric information.
[0041] In an illustrative embodiment, based on the execution of the
executable code, the client computing device 102 may transmit
multiple resource requests for purposes of determining latency
information. For example, a client computing device 102 may
transmit two resource requests to different POPs to determine
latency information associated with each POP. In another example, a
client computing device 102 may transmit multiple resource requests
to the same POP to verify latency information, conduct a series of
latency tests for a single POP, test different software
applications on the client computing device 102 or CDN service
provider 106, test various Internet Service Provider ("ISP")
functionality, and the like. With reference now to FIG. 4B, the
client computing device 102 processes the executable code included
in the returned content, such as a script, that causes the client
computing device to generate additional resource requests, or other
types of data exchange between the CDN service provider 106 and the
client computing device. As described above, in one embodiment, the
request of a resource can also correspond to a GET request
transmitted by the client computing device 102 to an IP address
associated with CDN service provider 106. However, the resulting
resource request generated by the client computing device 102 may
not necessarily correspond to any content that is to be generated
by the client computing device and does not have to result in the
transmission of resource from the CDN service provider 106. Upon
receipt of the resource request, the receiving POP, POP 122,
processes the request and, optionally, returns a response.
Illustratively, the processing of the resource request can include
the collection or logging of information associated with the
resource request that will allow the CDN service provider 106 to
determine performance metric information. The processing of the
resource request can also include the generation of identifiers or
other information that is returned to the client computing device
102 and that can be collected by the client computing device for
purposes of determining performance metric information.
[0042] Finally, with reference now to FIG. 4C, with continued
reference to an embodiment in which the executable code results in
multiple resource requests to various POPs, the client computing
device 102 processes the executable code, such as a script, that
causes the client computing device to generate additional resource
requests, or other types of data exchange between the CDN service
provider 106 and the client computing device. As described above,
in one embodiment, the request of a resource can also correspond to
a GET request transmitted by the client computing device 102 to an
IP address associated with CDN service provider 106. Similar to the
description in FIG. 4B, the resulting resource request generated by
the client computing device 102 may not necessarily correspond to
any content that is to be generated by the client computing device
and does not have to result in the transmission of resource from
the CDN service provider 106. Upon receipt of the resource request,
the receiving POP, POP 128, processes the request and returns a
response. Illustratively, the processing of the resource request
can include the collection or logging of information associated
with the resource request that will allow the CDN service provider
106 to determine performance metric information. The processing of
the resource request can also include the generation of identifiers
or other information that is returned to the client computing
device 102 and that can be collected by the client computing device
for purposes of determining performance metric information.
[0043] Turning now to FIG. 5, a routine 500 implemented by a client
computing device 102 for the generation of resource requests based
on the execution of executable code will be described. At block
502, the client computing device 102 transmits the original request
for content. As described above, the request for content may
directed to a Web server 110 of the content provider 104. At block
504, the client computing device 102 obtains responsive content
that includes the embedded executable code provided by the CDN
service provider 106 to the content provider 104. As described
above, in an illustrative embodiment, the embedded executable code
can correspond to script-based instructions that can be processed
by a software application running on the client computing device
102. Still further, the translation request code can be organized
in the responsive content such that the translation request is the
first data processed by the client computing device 102 in
accordance with the limitations of the limitations/capabilities of
the networking protocols and markup language.
[0044] At block 506, the client computing device 102 executes the
embedded executable code and, at block 508, transmits a first
request for embedded resources to the CDN service provider 106. As
previously described, the executable code may be configured such
that the resource request transmitted by the client computing
device 102 is directed to a specific CDN service provider 106
component. At decision block 510, a test is conducted to determine
whether the execution of the executable code results in additional
resource requests. If so, the routine 500 returns to block 508 for
the generation of one or more additional resource requests. The
client computing device 102 can collect and store information
associated with the transmission of each resource request and
receipt of any response. Additionally, the client computing device
102 can process any returned information that facilitates a
determination of performance metric information. For example, the
returned information may include timing information, such as a time
stamp, that can be utilized to determine network latency between
the transmission and receipt of a response from the CDN service
provider 106. As previously described, the additional resource
requests may be configured such that they are to be received by the
POP receiving the first resource request (e.g., a repeat resource
request) or by a different POP within the CDN provider's
domain.
[0045] Returning to decision block 510, once all the resource
requests have been transmitted, at block 512, the client computing
device 102 can process all collected resource request information
to assist in the determination of latencies in the receipt of
resources from the various components of the CDN service provider
106. In other embodiments, the processing of resource request
information may correspond to the transmission of any collected
information to the CDN service provider 106. Illustratively, the
executable code provided in the returned content can include logic
and functions necessary to process the resource request information
and provide it to the CDN service provider 106. Alternatively, the
client computing device 102 can include additional executable code
or modules, software applications, etc. that facilitate the
processing and reporting of the resource request information and
provide it to the CDN service provider 106. Additionally, in
embodiments in which the CDN service provider 106 obtains all the
relevant information upon receipt of the resource request (e.g.,
embedded timing information it the request), block 512 may be
omitted. At block 514, the routine 500 terminates.
[0046] With reference now to FIGS. 6-8, another embodiment related
to the interaction between various components of the content
delivery environment 100 of FIG. 1 will be illustrated. For
purposes of this illustrative example, however, the illustration
has been simplified such that many of the components utilized to
facilitate communications are not shown. One skilled in the
relevant art will appreciate that such components can be utilized
and that additional interactions would accordingly occur without
departing from the spirit and scope of the present disclosure.
[0047] With reference now to FIG. 6, after completion of the
registration and embedding processes illustrated in FIG. 2, a
client computing device 102 generates a content request that is
received and processed by the content provider 104, such as through
the Web server 110. In accordance with an illustrative embodiment,
the request for content can be in accordance with common network
protocols, such as HTTP. Upon receipt of the content request, the
content provider identifies the appropriate responsive content. As
described above, in an illustrative embodiment, the requested
content can correspond to a Web page that is displayed on the
client computing device 102 via the processing of information, such
as HTML, XML, and the like. The requested content can include a
number of embedded resource identifiers that corresponds to
resource objects that should be obtained by the client computing
device 102 as part of the processing of the requested content. The
embedded resources can corresponds to multi-media content, such as
images, videos, text, etc. that will be processed by the client
computing devices 102 and rendered on output device.
[0048] As described above, the identification of the embedded
resources provided by the content provider 104 will be in the form
of resource identifiers that can be processed by the client
computing device 102, such as through a browser software
application. In an illustrative embodiment, the resource
identifiers can be in the form of a URL. For purposes of an
illustrative example, the URL can identify a domain of the content
provider 104 (e.g., contentprovider.com) or CDN service provider
106 (e.g., CDNserviceprovider), a name of the resource to be
requested (e.g., "resource.xxx") and a path where the resource will
be found (e.g., "path"). By way of an illustrative example, the
URLs of the embedded resource have the form of: [0049]
http://www.contentprovider.com/path/resource.xxx [0050] or [0051]
http://www.CDNserviceprovider.com/path/resource.xxx
[0052] Additionally, in an illustrative embodiment, the additional
embedded resource identifiers previously provided by the CDN
service provider 106 during the registration process (FIG. 2) will
also be in the form of a resource identifier (e.g., URLs) that can
be processed by the client computing device 102, such as through a
browser software application. For purposes of an illustrative
example, the URL can identify a domain of the CDN service provider
106 (e.g., CDNserviceprovider.com), a name of a resource to be
requested (e.g., "resource.xxx") and a path where the resource will
be found (e.g., "path"). As will be explained in greater detail,
the embedded resource previously provided by the CDN service
provider 106 will identify a special resource such that a request
for the special resource may not result in the delivery of an
actual resource to the requesting client computing device 102. As
previously discussed, the additional embedded resource identifiers
can correspond to a different or the same domain as the other
embedded resource identifiers included in the content request. In
this illustrative example, the URLs of the embedded resource have
the form of: [0053]
http://www.CDNservieprovider.com/path/resoure.xxx
[0054] With reference now to FIG. 7, upon receipt of the requested
content, including the embedded resource identifiers and the
executable code previously provided by the CDN service provider
106, the client computing device 102 processes the received
information in a manner that causes the client computing device 102
to request embedded resource previously provided by the CDN service
provider 106 from the CDN service provider 106. In accordance with
an embodiment utilizing HTTP, the request of a resource can
correspond to a GET request transmitted by the client computing
device 102 to an IP address associated with CDN service provider
106. Although not illustrated in FIG. 7, the client computing
device 102 would first issue a DNS query for the embedded resource
previously provided by the CDN service provider 102, which if
properly resolved, would include the identification of the above
mentioned IP address associated with the CDN service provider 106.
One skilled in the relevant art will appreciate that the resolution
of the DNS query may involve multiple DNS queries to either the
content provider 104 or CDN service provider 106.
[0055] As also illustrated in FIG. 7, a receiving POP, POP 116,
obtains the resource request and processes the request.
Illustratively, the processing of the resource request can include
the collection or logging of information associated with the
resource request that will allow the CDN service provider 106 to
determine performance metric information. Additionally, in this
embodiment, the processing of the resource request also includes
the generation of at least one additional resource identifier and
corresponding commands that will cause the client computing device
102 to issue one or more subsequent requests for resources. In
accordance with an embodiment utilizing HTTP, the response can
include a resource identifier in accordance with a REDIRECT command
that causes the client computing device 102 to generate a
subsequent resource request.
[0056] With reference now to FIG. 8, in an illustrative embodiment,
upon receipt of the response (e.g., the at least one additional
resource identifier and corresponding commands) from the CDN
service provider 106, the client computing device 102 issues a
subsequent resource response corresponding to the at least one
additional resource identifier. In one embodiment, the additional
resource identifier is configured such that the subsequent request
is received at a different POP, POP 122. In another embodiment, the
additional resource identifier can be configured such that the
subsequent request is received at the same POP. Based on a series
of commands, the client computing device 102 or CDN service
provider 106 can collect performance metric information that
facilitates the determination of latency information (or other
information) associated with the transmission of resource
requests.
[0057] Turning now to FIG. 9, a routine 900 implemented by a CDN
service provider 106 for the processing of resource requests will
be described. One skilled in the relevant art will appreciate that
actions/steps outlined for routine 900 may be implemented by one or
many computing devices/components that are associated with the CDN
service provider 106. Accordingly, routine 900 has been logically
associated as being generally performed by the CDN service provider
106, and thus the following illustrative embodiments should not be
construed as limiting
[0058] At block 902, the CDN service provider 106 obtains the
original request for content. As described above, the client
computing device 102 transmits the request for content based on one
or more embedded resource identifiers. At block 904, the CDN
service provider 106 processes the resource request. In an
illustrative embodiment, the CDN service provider 106 can utilize a
variety of logic in determining how to process resource requests.
For example, if the resource request corresponds to an actual
resource to be delivered by the CDN service provider 106, the CDN
service provider 106 can utilize various criteria to determine
which resource requests will result in the delivery of the resource
and which resource requests will result in the return of a REDIRECT
command. In another example, the CDN service provider 106 can
maintain some type of count or other selection mechanism to
determine how many REDIRECT commands to provide. In still another
example, the CDN service provider 106 can provide REDIRECT commands
for all requests for particular resources or all requests from
particular types of requesting client computing devices 102 (e.g.,
all client computing devices associated with a particular ISP).
Additionally, the CDN service provider 106 can collect and store
information associated with the transmission of each resource
request and receipt of any response.
[0059] Once the resource request has been processed, at decision
block 906, a test is conducted to determine whether there will be
additional resource requests that will be processed. If so, the CDN
service provider 106 transmits the alternative resource identifier
and corresponding REDIRECT command (or similar command) and the
routine 900 returns to block 902 to repeat the process for the
alternative resource identifier. Accordingly, the routine 900 can
be repeated a number of times for a set of successive resource
requests and performance metric measures.
[0060] Returning to decision block 906, once all the resource
requests have been received, at block 910, the CDN service provider
106 can process all collected resource request information to
assist in the determination of latencies in the receipt of
resources from the various components of the CDN service provider
106. In other embodiments, the processing of resource request
information may correspond to the receipt of any collected
information and processing information provided by the client
computing device 102. At block 912, the routine 900 ends.
[0061] With reference now to FIGS. 10 and 11, another embodiment
related to the interaction between various components of the
content delivery environment 100 of FIG. 1 will be illustrated. For
purposes of this illustrative example, however, the illustration
has been simplified such that many of the components utilized to
facilitate communications are not shown. One skilled in the
relevant art will appreciate that such components can be utilized
and that additional interactions would accordingly occur without
departing from the spirit and scope of the present disclosure.
[0062] With reference now to FIG. 10, after completion of the
registration and embedding processes illustrated in FIG. 2, a
client computing device 102 generates a content request that is
received and processed by the content provider 104, such as through
the Web server 110. In accordance with an illustrative embodiment,
the request for content can be in accordance with common network
protocols, such as HTTP. Upon receipt of the content request, the
content provider identifies the appropriate responsive content. As
described above, in an illustrative embodiment, the requested
content can correspond to a Web page that is displayed on the
client computing device 102 via the processing of information, such
as HTML, XML, and the like. The requested content can include a
number of embedded resource identifiers that corresponds to
resource objects that should be obtained by the client computing
device 102 as part of the processing of the requested content. The
embedded resources can corresponds to multi-media content, such as
images, videos, text, etc. that will be processed by the client
computing devices 102 and rendered on output device.
[0063] Although not previously discussed, in an illustrative
embodiment, the client computing device 102 and the receiving POP,
illustratively POP 116, may engage in a number of communication
exchanges corresponding to the communication and networking
protocols utilized to exchange information and request/receive the
received. For example, with regard to an HTTP-based request, the
client computing device 102 may first transmit a synchronization
command (e.g., a SYNC command) that elicits an acknowledgement from
the receiving POP. At that point, the client computing device 102
and POP can establish a communication channel and process the
resource request in a manner described above.
[0064] As also illustrated in FIG. 10, a receiving POP, POP 116,
obtains the resource request and processes the request.
Illustratively, the processing of the resource request can include
the collection or logging of information associated with the
resource request that will allow the CDN service provider 106 to
determine performance metric information.
[0065] With reference now to FIG. 11, upon the transmission of the
response to the CDN service provider 106, the communication channel
is typically closed or terminated by the transmission of a
termination command, such as a FIN command in HTTP. In this
embodiment, the receiving POP does not transmit the termination
command. Rather, the POP 116 transmits a request to another CDN
service provider 106 POP, such as POP 122, to transmit one or more
commands. The POP 122 obtains the request and transmits the
protocol commands to the client computing device 102. As
illustrated in FIG. 11, the client computing device 102 may
transmit additional protocol commands, such as an acknowledgement
to the original POP, POP 116, and can include performance metric
information related to the latencies associated with the
transmission of protocol commands from the other POP. In an
illustrative embodiment, client computing device 102 may not be
aware that any of the subsequent transmissions originated from
another POP. One skilled in the relevant art will appreciate that
while the this embodiment is illustrated with regard to specific
HTTP commands, the present disclosure is not limited to any
particular networking or communication protocol or specific
commands or type of commands within a networking or communication
protocol.
[0066] Turning now to FIG. 12, a routine 1200 implemented by a CDN
service provider 106 for the processing of resource requests will
be described. One skilled in the relevant art will appreciate that
actions/steps outlined for routine 1200 may be implemented by one
or many computing devices/components that are associated with the
CDN service provider 106. Accordingly, routine 1200 has been
logically associated as being generally performed by the CDN
service provider 106, and thus the following illustrative
embodiments should not be construed as limiting.
[0067] At block 1202, the CDN service provider 106 obtains the
original request for content. As described above, the client
computing device 102 transmits the request for content based on one
or more embedded resource identifiers. At block 1204, the CDN
service provider 106 initiates protocol-based interactions related
to the establishment of a communication channel and request for
resources. Examples of protocol interactions can include various
synchronization commands, acknowledgments and the identification of
the requests. Additionally, the CDN service provider 106 can
collect and store information associated with the transmission of
each resource request and receipt of any response.
[0068] Once the resource request has been processed, at decision
block 1206, a test is conducted to determine whether there will be
additional between the POP and the client computing device 102. If
so, the routine 1200 returns to block 1204 for additional protocol
interactions. Returning to decision block 1206, once no additional
interaction is required or the CDN service provider 106 determines
that it wants another component to interact with the client
computing device 102, at block 1208, the CDN service provider 106
(through the POP) transmits a request to another POP (or other
component) to transmit additional protocol communications with the
client computing device 102.
[0069] At block 1210, the CDN service provider 106 can process all
collected resource request information to assist in the
determination of latencies in the receipt of resources from the
various components of the CDN service provider 106. In other
embodiments, the processing of resource request information may
correspond to the receipt of any collected information and
processing information provided by to the client computing device
102. At block 1212, the routine 1200 ends.
[0070] While illustrative embodiments have been disclosed and
discussed, one skilled in the relevant art will appreciate that
additional or alternative embodiments may be implemented within the
spirit and scope of the present invention. Additionally, although
many embodiments have been indicated as illustrative, one skilled
in the relevant art will appreciate that the illustrative
embodiments do not need to be combined or implemented together. As
such, some illustrative embodiments do not need to be utilized or
implemented in accordance with scope of variations to the present
disclosure.
[0071] Conditional language, such as, among others, "can," "could,"
"might," or "may," unless specifically stated otherwise, or
otherwise understood within the context as used, is generally
intended to convey that certain embodiments include, while other
embodiments do not include, certain features, elements and/or
steps. Thus, such conditional language is not generally intended to
imply that features, elements and/or steps are in any way required
for one or more embodiments or that one or more embodiments
necessarily include logic for deciding, with or without user input
or prompting, whether these features, elements and/or steps are
included or are to be performed in any particular embodiment.
[0072] Any process descriptions, elements, or blocks in the flow
diagrams described herein and/or depicted in the attached figures
should be understood as potentially representing modules, segments,
or portions of code which include one or more executable
instructions for implementing specific logical functions or steps
in the process. Alternate implementations are included within the
scope of the embodiments described herein in which elements or
functions may be deleted, executed out of order from that shown or
discussed, including substantially concurrently or in reverse
order, depending on the functionality involved, as would be
understood by those skilled in the art. It will further be
appreciated that the data and/or components described above may be
stored on a computer-readable medium and loaded into memory of the
computing device using a drive mechanism associated with a computer
readable storing the computer executable components such as a
CD-ROM, DVD-ROM, or network interface further, the component and/or
data can be included in a single device or distributed in any
manner. Accordingly, general purpose computing devices may be
configured to implement the processes, algorithms and methodology
of the present disclosure with the processing and/or execution of
the various data and/or components described above.
[0073] It should be emphasized that many variations and
modifications may be made to the above-described embodiments, the
elements of which are to be understood as being among other
acceptable examples. All such modifications and variations are
intended to be included herein within the scope of this disclosure
and protected by the following claims.
* * * * *
References