WO2015100283A1

WO2015100283A1 - Systems and methods for delivering content to clients that are suboptimally mapped

Info

Publication number: WO2015100283A1
Application number: PCT/US2014/072033
Authority: WO
Inventors: Umesh SIRSIWAL; Jian Yang; Marc E. FIUCZYNSKI
Original assignee: Akamai Technologies, Inc.
Priority date: 2013-12-23
Filing date: 2014-12-23
Publication date: 2015-07-02

Abstract

In many content delivery schemes, an end-user client is mapped to a given server out of many possible servers. According to the teachings hereof, the given server may be able to determine that another In many content delivery schemes, an end-user client is mapped to a selected server out of many possible servers. According to the teachings hereof, the initially selected server may be able to determine that another server or group of servers is better able to deliver content to the client. This may occur because the other server is closer to the client, or because the initially selected server is overloaded, or for other reasons. Described herein are, among other things, systems and methods for delivering content to the end-user client in such situations.

Description

SYSTEMS AND METHODS FOR DELIVERING CONTENT TO CLIENTS THAT

ARE SUBOPTIMALLY MAPPED

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority of U.S. Provisional Application No.

61/920,445, filed December 23, 2013, and of U.S. Application No. 14/579,850, filed

December 22, 2014, the teachings of both of which are hereby incorporated by reference in their entirety.

This patent document may contain material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in Patent and Trademark Office patent files records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND

Technical Field

This application relates generally to distributed data processing systems and to the delivery of content to client devices over computer networks.

Brief Description of the Related Art A variety of approaches for delivering content are known in the art. One approach is to employ a distributed computing system known as a content delivery network or "CDN." A "distributed system" of this type typically refers to a collection of autonomous computers linked by a network or networks, together with the software, systems, protocols and techniques designed to facilitate various content delivery services. The infrastructure is generally used for the storage, caching, or transmission of content. The platform may also provide ancillary technologies used therewith including, without limitation, DNS query handling, provisioning, data monitoring and reporting, content targeting, personalization, and business intelligence.

CDNs are often operated and managed by service providers as a shared platform. The service provider typically provides content delivery services on behalf of third parties, e.g., the content providers. The CDN infrastructure is shared by multiple content providers. In a known system such as that shown in FIG. 1, a distributed computer system 100 is configured as a content delivery network (CDN) and has a set of CDN content servers 102 distributed around the Internet. Typically, most of the servers are located near the edge of the Internet, i.e., at or adjacent end user access networks. A network operations command center (NOCC) 104 may be used to administer and manage operations of the various machines in the system. Content providers, who host content on origin server 106, offload delivery of content (e.g., HTML or other markup language files, embedded page objects, streaming media, software downloads, and the like) to the distributed computer system 100 and, in particular, to the CDN servers 102 (which are sometimes referred to as content servers, or sometimes as "edge" servers in light of the possibility that they are near an "edge" of the Internet). Such servers may be grouped together into a point of presence (POP) 107 at a particular location.

The CDN servers are typically located at nodes that are publicly-routable on the Internet, within or adjacent nodes that are located in mobile networks, in or adjacent enterprise-based private networks, or in any combination thereof. Typically, content providers offload their content delivery by aliasing (e.g., by a DNS

CNAME) given content provider domains or sub-domains to domains that are managed by the service provider's authoritative domain name service. The server provider's domain name service provides IP addresses that direct end user client machines 122 that desire content to the distributed computer system (or more particularly, to a CDN server in the platform) to obtain the content more reliably and efficiently. The CDN servers typically respond to the client requests with a proxy caching function, for example by serving requested content from a local cache if available, or if not fetching from another CDN server, from the origin server 106 associated with the content provider, or other source, and sending it to the requesting client. For cacheable content, CDN servers typically employ on a caching model that relies on setting a time-to-live (TTL) for each cacheable object. After it is fetched, the object may be stored locally at a given CDN server until the TTL expires, at which time is typically revalidated or refreshed from the origin server 106. For non-cacheable objects (sometimes referred to as 'dynamic' content), the CDN server typically must return to the origin server 106 when the object is requested by a client. The CDN may operate a server cache hierarchy to provide intermediate caching of customer content in various CDN servers closer to the CDN server handling a client request than the origin server 106; one such cache hierarchy subsystem is described in U.S. Patent No. 7,376,716, the disclosure of which is incorporated herein by reference.

Although not shown in detail in FIG. 1, the distributed computer system may also include other infrastructure, such as a distributed data collection system 108 that collects usage and other data from the CDN servers, aggregates that data across a region or set of regions, and passes that data to other back-end systems 110, 112, 114 and 116 to facilitate monitoring, logging, alerts, billing, management and other operational and administrative functions. Distributed network agents 118 monitor the network as well as the server loads and provide network, traffic and load data to a DNS query handling mechanism 115. A distributed data transport mechanism 120 may be used to distribute control information (e.g., "metadata" to manage content, to facilitate load balancing, and the like) to the CDN servers. The CDN may include a network storage subsystem (sometimes referred to herein as "NetStorage") which may be located in a network datacenter accessible to the CDN servers and which may act as a source of content, such as described in U.S. Patent No. 7,472,178, the disclosure of which is incorporated herein by reference.

As illustrated in FIG. 2, a given machine 200 in the CDN typically has commodity hardware (e.g., a microprocessor) 202 running an operating system kernel (such as Linux® or variant) 204 that supports one or more applications 206. To facilitate content delivery services, for example, given machines typically run a set of applications, such as an HTTP proxy 207, a name service 208, a local monitoring process 210, a distributed data collection process 212, and the like. The HTTP proxy 207 typically includes a manager process for managing a cache and delivery of content from the machine. For streaming media, the machine may include one or more media servers, such as a Windows® Media Server (WMS) or Flash server, as required by the supported media formats. The CDN platform may be thought of as an overlay across the Internet providing improved or best-practice communication techniques over standard Internet communications. Such communication on the overlay can help when a CDN server needs to obtain content from an origin server 106, or otherwise when accelerating non-cacheable content for a content provider customer. Communications between CDN servers and/or across the overlay may be improved using route selection, protocol optimizations including TCP enhancements, persistent connection reuse and pooling, content & header compression and de-duplication, and other techniques such as those described in U.S. Patent Nos. 6,820,133, 7,274,658,

7,607,062, and 7,660,296, among others, the disclosures of which are incorporated herein by reference.

For streaming delivery, the CDN may include a streaming delivery subsystem, such as described in U.S. Patent No. 7,296,082, and U.S. Publication Nos. 2011/0173345 and 2012/0265853, the disclosures of which are incorporated herein by reference.

In addition to being deployed by dedicated CDN service providers, content delivery networks may also be deployed by content providers themselves (e.g., to efficiently serve their own content), and/or by network operators, internet service providers (ISPs) and the like, in their own networks (operator CDN). Such CDNs may have any or all of features described above. In some cases, CDN service providers may provide appropriate hardware, software, management and/or expertise to such entities to enable them to establish and operate their own CDNs, whether for their own use or on behalf of the entity's own customers.

In CDN operations, request mapping is the process of mapping an end-user client machine request for a URL to a CDN server that is 'best' able to serve the named object. Here the notion of best CDN server can have many qualitative meanings such as: the CDN server closest to the location of the end-user in topological terms, the CDN server with the least network latency (closest network distance) to the end-user (often the CDN server that is topologically closest, but not necessarily), least loaded server hosting the cache, least loaded and highest bandwidth links, or some combination thereof - to name a few. Good request mapping is an important aspect of a CDN platform.

As mentioned previously, DNS based request routing is often used in CDNs to direct end user client machines to content servers in the CDN. For DNS based request routing, in response a client machine's name resolution request, the CDN's DNS server returns an IP address for a selected CDN server (or set of CDN servers), so that the client machine requests content from the selected server.

DNS-based request mapping works well under the premise that an end-user's DNS server is close to the end user. When this is not the case then there may be a suboptimal mapping of the end-user to a CDN server. More specifically, problems can arise because end-user client machines generally do not interact directly with the CDN's DNS system. Rather, they ask a recursive DNS server, typically provided by their ISP and often referred to as their "local" DNS server, to resolve a name The recursive DNS asks the CDN's DNS system. As a result, the mapping decision is made based on the IP address of the recursive DNS server (e.g., of the ISP) rather than that of the end-user client machine. In many cases, this is a good approximation for the location of the client machine. But that is not always the case;

sometimes the "local" DNS that the client uses is actually located relatively far from the client machine, resulting in a mapping to a less suboptimal CDN server. Moreover, recently, public or Open' DNS servers have increased in popularity. These DNS servers may be used by members of the public to resolve domain names, just an ISP subscriber uses the DNS server provided by the ISP. Such public DNS servers may be located far from client machines.

While one can correct a mapping to a suboptimal CDN server using HTTP redirection, this is not panacea due to issues ranging from introducing latency to end users that cannot properly follow a redirect directive. For this reason an alternative solution is needed. Hence, there is a need for improved systems and methods for being able to deliver content to end-user client machines based on their location and IP address. The teachings herein address these needs and also provide other benefits and improvements that will become apparent in view of this disclosure.

SUMMARY

In many content delivery schemes, an end-user client is mapped to a selected server out of many possible servers. According to the teachings hereof, the initially selected server may be able to determine that another server or group of servers is better able to deliver content to the client. This may occur because the other server is closer to the client, or because the initially selected server is overloaded, or for other reasons. Described herein are, among other things, systems and methods for delivering content to the end-user client in such situations. BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic diagram illustrating one embodiment of a known distributed computer system configured as a content delivery network;

FIG. 2 is a schematic diagram illustrating one embodiment of a machine on which a CDN server in the system of FIG. 1 can be implemented;

FIG. 3 is a schematic diagram illustrating a mapping of an end-user client EUA to a CDN server at a PoP (Site A); FIG. 4 is a schematic diagram illustrating a suboptimal mapping of an end-user client EU_B to a CDN server at Site A, with flow routing to a CDN server in a better location (Site B); and,

FIG. 5 is a block diagram illustrating hardware in a computer system that may be used to implement the teachings hereof.

DETAILED DESCRIPTION

The following description sets forth embodiments of the invention to provide an overall understanding of the principles of the structure, function, manufacture, and use of the methods and apparatus disclosed herein. The systems, methods and apparatus described herein and illustrated in the accompanying drawings are non-limiting examples; the claims alone define the scope of protection that is sought. The features described or illustrated in connection with one exemplary embodiment may be combined with the features of other embodiments. Such modifications and variations are intended to be included within the scope of the present invention. All patents, publications and references cited herein are expressly incorporated herein by reference in their entirety. Throughout this disclosure, the term "e.g." is used as an abbreviation for the non-limiting phrase "for example."

In one embodiment, a system in accord with the teachings of this document routes upstream packets from a suboptimal CDN server location to a "better" CDN server location, for a given end-user client. While the downside is that the end user's upstream traffic needs to go via the suboptimal location, the upside is that the higher bandwidth downstream traffic is served directly from the CDN server at the better location to the end user machine.

The conclusion of what other CDN server location is "better" may be based on a variety of factors, such as latency (network distance) to the client, network topology, network conditions (e.g., congestion or outages), available services at the CDN servers, and the like. Thus, the "better" mapping is not limited to mean close in network distance terms, though that is often an important factor. Generalizing, the "better" mapping may be a conclusion based on any number of considerations, assessments, and characteristics. The teachings hereof apply regardless of the underlying reason(s) for wanting to re -map a given end-user client. In some cases, another server may be able to better serve the client because of load conditions, health status, or otherwise particular to the server condition itself rather than the location. The "better" server or PoP may be one that provides a function/service or characteristics that the initial server/PoP does not. For example, the "better" server may be designated for particular traffic which the client is requesting, which is something the initial server may discover once it is able to receive and examine the client's content request at the application layer.

In accordance with the foregoing, an example workflow may be as follows:

A. A client machine makes a DNS request to a recursive DNS (also referred to as a local DNS server) server to resolve a given hostname. The recursive DNS contacts the CDN's DNS server (e.g., as a result of recursive DNS server configuration, or after looking a content provider's domain name and receiving an alias/CNAME to a CDN domain name, or otherwise). The CDN DNS server returns an IP address pointing a given CDN server (a "first" CDN server). The recursive DNS server returns this answer to the client machine.

Note that the mapping process may actually involve multiple stages - for example, the top- level CDN DNS may hand out a CNAME to another CDN hostname pointing to a DNS server for a particular CDN PoP, and this second-level DNS server may then select and hand out the ultimate IP address for the CDN server, e.g., based on load conditions of servers at the PoP. B. The client machine sends a content request to the first CDN server. The first CDN server, receiving the content request with the client machine's actual IP address (source IP), determines that there a better mapping available, e.g., with another CDN server located closer in network distance terms (lower latency) to the client machine. The "better" server is referred to here as the "second" CDN server. The first CDN server forwards upstream packets from the client machine to the second CDN server, using e.g., a tunnel protocol. Suitable tunneling protocols include IP-in-IP tunneling or Generic Routing Encapsulation (GRE), both of which operate at the network layer.

C. The second CDN server receives the content request and processes it in a caching proxy operation. For example, it can retrieve the content from local cache, if available and valid to serve (e.g., not expired). If not in cache or expired (cache-miss), the second CDN server can retrieve the object from an origin server, and send it the client, caching for use in responding to subsequent requests. The second CDN server addresses its response(s) to the client machine (that is, using a destination IP address of the client machine) and uses the first CDN server's address for the source IP field. In this way, the client machine still obtains the benefit of being delivered content from the second CDN server, which is better located than the first CDN server. To the client machine, the data appears to have come from the first CDN server. To the client, the operation is transparent.

More details are now set forth to illustrate a variety of non-limiting embodiments. System Components & Architecture

This section provides a high-level description of a system embodiment. The high level description for each component shown is as follows below.

End User Client Machine (EUx): An end user client machine X using HTTP to fetch a named object. Site X: A 'Site' is a deployment of CDN servers and Site X is a deployment to which EUx should be mapped. (A 'Site' is sometimes referred to herein as a point of presence or POP and no distinction between the two is intended.) CDN server: responsible for delivering the URL named object to the EU; preferably it runs an HTTP proxy cache process; see FIG. 2.

Flow Router (FR): software component that can forward traffic to a remote CDN server at Site X based upon the EUx's IP address. The FR accepts upstream packets and routes them to appropriate site using a tunneling protocol, e.g., GRE, IP-in-IP tunnels, etc. This way FR does not have to terminate TCP connections and responses can go directly from the remote CDN server to the end user. This design improves efficacy for bulk HTTP traffic, as it is sent directly from the better cache locations to the end user. FR can be run as a process on a given CDN server. FR can be implemented as a virtual service with components running in the root context, and bound to and available to a number of CDN server nodes.

RR: The CDN's request router used by the EUx, preferably a DNS server loaded with maps for the CDN deployment and ingesting information about CDN server status (e.g., load, health, etc.) as well as network information (e.g., network latencies).

FIG. 3 shows the traffic flow where the request router is able to properly map EUA to Site A. Lines la and lb correspond to a DNS query from EUA and then made on behalf of EUA by the EUA'S recursive DNS server to the CDN DNS (the details of the recursive lookup process are not shown, for convenience of illustration); lines 2b and a represents the DNS response from the RR and then from the recursive DNS back to EUA- Line 3 is the EUA HTTP request path over TCP, line 4 is the forwarding from the FR to the local cache server process, and line 5 is the HTTP response path back to EUA- Note that in this case the FR preferably directs the traffic to the local proxy cache server process.

FIG. 4 shows EU_B sub-optimally mapped to Site A, which means EU_B was given an IP address of a CDN server in Site A. EU_B should have been mapped to Site B. The FR at site A can realize this, based on the EU_B'S actual IP address that it gets when it receives the packets making up EU_B'S content request. As such the FR in Site A forwards the HTTP request traffic from EU_B to the Site B CDN server. The Site B CDN server then responds directly to EU_B using a direct server response technique, using the IP address of the originally addressed cache in Site A as the source IP when it sends the response to the client. The forwarding from the FR in Site A to the CDN server in Site B is done using a tunneling protocol. Note that the forwarding is preferably done directly from FR to a specific CDN server. This reduces request packet latency and improves overall performance. Alternatively the forwarding could be done from the FR to the Site (e.g., using a VIP) if needed for design purposes, with local distribution. The CDN server component that terminates the tunnels is called flow router endpoint.

In FIG. 4, lines la-b and 2a-b represent the DNS request and the response, respectively, that yield the suboptimal IP address. Line 3 is the HTTP request to CDN server in site A. Line 4 is the forwarding from the FR to the CDN server in Site B. Line 5 is the HTTP reply back to EU_B.

Flow Router Mapping

In an embodiment, the mapping approach can be arranged as follows. Preferably, FRs and RRs have interfaces allowing them to exchange information about mapping. The RR can make available to the FRs the following information, via an application programming interface (API):

Flow Router Map Association: This is static list of binding between a flow router map identifier and the sites that should use the map. Flow Routed Sites: This is a list of Sites (PoPs) that are configured in a map associated with a given FR. The FR can use this information to create IP tunnels and initial flow routing maps.

Preferably, RRs are responsible for periodically making/updating maps, and publishing to FRs. FRs inform the RR whether they are available/healthy as flow-routable Sites (able to divert traffic and to receive such diverted traffic), and also about the load on their associated CDN servers. The RR monitors health and load of the CDN servers. Based on this information (and network topology information) the RR computes the Dynamic Site Map for the FR service. The RR periodically advertises the mapping of client IP, preferably by subnet, to a prioritized list of best suited Sites. This advertisement can use pub/sub infrastructure, with FRs being the consumer of the publications, as noted above. The design allows different sites to be associated with the different Site maps. The RR will make an independent publication for each such map. The publish key can be used by FRs to selectively listen to the map it is interested in. FRs know how to select the appropriate map based on the information obtain via the aforementioned API.

By way of example, the map advertisement can have the following format:

{

"version": 1,

"map": {

"flow router": {

"flow router sites" : [<site-list>],

<subnet> : [<site-list>],

<subnet> : [<site-list>]

}

Where:

' flow router sites' is list of sites that should consume this map. 'subnet' is the end user client IP subnet, and the site-list is prioritized list of sites to handle the request. If the site-list is empty, the traffic is routed to local host on the CDN server machine.

By consulting the prioritized list of Sites in the map advertisement, a given FR can determine whether it is the "best" Site to handle the request from the client. In this embodiment, the maps and the FRs work at the IP level. In some cases, a CDN may want to implement maps in which traffic from a given IP may be directed to different Sites depending on the particular hostname in the request. This kind of name -based-mapping functionality can be fulfilled with the RR, using DNS, since it knows the requested hostname. But if the FR is based on IP-level mapping, then the FR can break these mappings.

Preferably the system in configured so that the two maps are compatible, e.g., a single map from end-user client IP to a desired IP address of a CDN server or site. Alternatively, the FR can be implemented to examine the requested host header in the HTTP 'Get', and use this information in making a mapping decision, preserving the name-based-mapping feature.

High Availability Features In addition to addressing poor end-user client machine mapping, the FR service can be used to perform an offload function. To this end, the FR monitors load/performance of its associated site and/or CDN server. If such load exceeds configurable thresholds, the FR can forward traffic away from its associated Site and/or CDN server, using e.g., the

aforementioned maps to divert this traffic. The load-based forwarding may be independent and irrespective of whether the client machine should be mapped to another Site and/or CDN server. The load metric may be based on CPU utilization, memory utilization, number of open connections, response latency, etc.

Computer Based Implementation

The subject matter described herein may be implemented with computer systems, as modified by the teachings hereof, with the processes and functional characteristics described herein realized in special-purpose hardware, general-purpose hardware configured by software stored therein for special purposes, or a combination thereof.

Software may include one or several discrete programs. A 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 conventional 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.

While in some cases above a particular order of operations performed by certain

embodiments is set forth, it should be understood that such order is exemplary and that they may be performed in a different order, combined, or the like. Moreover, some of the functions may be combined or shared in given instructions, program sequences, code portions, and the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. FIG. 5 is a block diagram that illustrates hardware in a computer system 500 on which embodiments of the invention may be implemented. The computer system 500 may be embodied in a client device, server, personal computer, workstation, tablet computer, wireless device, mobile device, network device, router, hub, gateway, or other device.

Computer system 500 includes a microprocessor 504 coupled to bus 501. In some systems, multiple microprocessor and/or microprocessor cores may be employed. Computer system 500 further includes a main memory 510, such as a random access memory (RAM) or other storage device, coupled to the bus 501 for storing information and instructions to be executed by microprocessor 504. A read only memory (ROM) 508 is coupled to the bus 501 for storing information and instructions for microprocessor 504. As another form of memory, a non-volatile storage device 506, such as a magnetic disk, solid state memory (e.g., flash memory), or optical disk, is provided and coupled to bus 501 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 500 to perform functions described herein. Although the computer system 500 is often managed remotely via a communication interface 516, for local administration purposes the system 500 may have a peripheral interface 512 communicatively couples computer system 500 to a user display 514 that displays the output of software executing on the computer system, and an input device 515 (e.g., a keyboard, mouse, trackpad, touchscreen) that communicates user input and instructions to the computer system 500. The peripheral interface 512 may include interface circuitry and logic for local buses such as Universal Serial Bus (USB) or other communication links.

Computer system 500 is coupled to a communication interface 516 that provides a link between the system bus 501 and an external communication link. The communication interface 516 provides a network link 518. The communication interface 516 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 518 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) 526. Furthermore, the network link 518 provides a link, via an internet service provider (ISP) 520, to the Internet 522. In turn, the Internet 522 may provide a link to other computing systems such as a remote server 530 and/or a remote client 531. Network link 518 and such networks may transmit data using packet-switched, circuit-switched, or other data- transmission approaches.

In operation, the computer system 500 may implement the functionality described herein as a result of the microprocessor executing program code. Such code may be read from or stored on a non-transitory computer-readable medium, such as memory 510, ROM 508, or storage device 506. Other forms of non-transitory computer-readable media include disks, tapes, magnetic media, CD-ROMs, optical media, RAM, PROM, EPROM, and EEPROM. Any other non-transitory computer-readable medium may be employed. Executing code may also be read from network link 518 (e.g., following storage in an interface buffer, local memory, or other circuitry).

A client device may be a conventional desktop, laptop or other Internet-accessible machine running a web browser or other rendering engine, but as mentioned above a client may also be a mobile device. Any wireless client device may be utilized, e.g., a cellphone, pager, a personal digital assistant (PDA, e.g., with GPRS NIC), a mobile computer with a smartphone client, tablet or the like. Other mobile devices in which the technique may be practiced include any access protocol- enabled device (e.g., iOS™-based device, an Android™-based device, other mobile-OS based device, or the like) that is capable of sending and receiving data in a wireless manner using a wireless protocol. Typical wireless protocols include: WiFi, GSM/GPRS, CDMA or WiMax. These protocols implement the ISO/OSI Physical and Data Link layers (Layers 1 & 2) upon which a traditional networking stack is built, complete with IP, TCP, SSL/TLS and HTTP. The WAP (wireless access protocol) also provides a set of network communication layers (e.g., WDP, WTLS, WTP) and corresponding functionality used with GSM and CDMA wireless networks, among others.

In a representative embodiment, a mobile device is a cellular telephone that operates over GPRS (General Packet Radio Service), which is a data technology for GSM networks.

Generalizing, a mobile device as used herein is a 3G- (or next generation) compliant device that includes a subscriber identity module (SIM), which is a smart card that carries subscriber-specific information, mobile equipment (e.g., radio and associated signal processing devices), a man-machine interface (MMI), and one or more interfaces to external devices (e.g., computers, PDAs, and the like). The techniques disclosed herein are not limited for use with a mobile device that uses a particular access protocol. The mobile device typically also has support for wireless local area network (WLAN) technologies, such as Wi- Fi. WLAN is based on IEEE 802.11 standards. The teachings disclosed herein are not limited to any particular mode or application layer for mobile device communications.

It should be understood that the foregoing has presented certain embodiments of the invention that should not be construed as limiting. For example, certain language, syntax, and instructions have been presented above for illustrative purposes, and they should not be construed as limiting. It is contemplated that those skilled in the art will recognize other possible implementations in view of this disclosure and in accordance with its scope and spirit. The appended claims define the subject matter for which protection is sought.

It is noted that trademarks appearing herein are the property of their respective owners and used for identification and descriptive purposes only, given the nature of the subject matter at issue, and not to imply endorsement or affiliation in any way.

Claims

1. A system, comprising: a first server running a proxy process, the first server receiving one or more packets that include a content request from a client machine for particular content, the one or more packets having a source IP address for the client machine and a destination IP address at which the first server receives packets; the first server determining whether to forward the one or more packets, based on at least a portion of the IP address of the client machine and a map stored at the first server; upon a determination by the first server not to forward the one or more packets, the first server performing at least one action selected from the group of actions that is: (i) serve the particular content from a local cache of the first server and (ii) retrieve the particular content from an origin server and send the particular content to the client machine; upon a determination by the first server to forward the one or more packets, the first server selecting an address based on the map and forwarding the one or more packets to the address, wherein the address points to a second server, and the second server runs a proxy process; the second server receiving the forwarded one or more packets and sending the particular content to the client, the second server obtaining the particular content by performing an action selected from the group of actions that is (i) retrieve the particular content from a local cache of the second server, and (ii) retrieve the particular content from an origin server; wherein the second server sends the particular content to the client machine in one or more packets that have a source IP address of the first server; wherein each of the first and second server comprise one or more microprocessors and memory storing instructions for execution by the one or more microprocessors.

2. The system of claim 1, wherein the second server is closer in network distance to the client machine than the first server.

3. The system of claim 1, wherein the first server is in a first point of presence and the second server is in a second point of presence, the first and second points of presence being remote from one another.

4. The system of claim 1, wherein the second server does not receive packets at the destination IP address.

5. The system of claim 1, wherein the first server sends the one or more packets to the second server in a tunnel.

6. The system of claim 1, wherein the first server determines to forward the one or more packets based at least in part on any of: a service that the client is requesting; the particular content that the client is requesting.

7. The system of claim 1, wherein the map associates any of (i) client machine IP addresses and (ii) client machine IP address subnets, with IP addresses for any of: (i) servers and (ii) points of presence.

8. The system of claim 1, wherein the first and second servers are servers in a content delivery network operated by any of: (i) a service provider, (ii) a network operator and (iii) an internet service provider.

9. The system of claim 1, further comprising a DNS server that receives a domain name resolution request made on behalf of the client machine and returns the destination IP address for the first server.

10. A method operative in a distributed computing platform having a plurality of servers that have one or more microprocessors and a storage device holding computer program instructions to be executed by the one or more microprocessors to operate the respective server, the method comprising: receiving a domain name resolution request; responding to the domain name resolution request with an IP address at which a first server receives packets; receiving a content request from a client at the first server, the content request being for particular content and being received in one or more packets bearing a source IP address of the client and a destination IP address corresponding to the IP address given in response to the domain name resolution request; determining, at the first server, whether to forward the one or more packets, based on at least a portion of the source IP address of the client and a map; upon a determination by the first server not to forward the one or more packets, the first server performing at least one action selected from the group of actions that is: (i) serve the particular content from a local cache of the first server and (ii) retrieve the particular content from an origin server and send the particular content to the client; upon a determination by the first server to forward the one or more packets, the first server selecting an address based on the map and forwarding the one or more packets to the address, the address pointing to a second server; at the second server, receiving the forwarded one or more packets and sending the particular content to the client, the second server obtaining the particular content by performing at least one action selected from the group of actions that is: (i) retrieve the particular content from a local cache for the second server, and (ii) retrieve the particular content from an origin server; wherein the second server sends the particular content to the client in one or more packets that have a source IP address of the first server.

11. The method of claim 10, wherein the second server is closer in network distance to the client than the first server.

12. The method of claim 10, wherein the first server is in a first point of presence and the second server is in a second point of presence, the first and second points of presence being remote from one another.

13. The method of claim 10, wherein the second server does not receive packets at the IP address given in response to the domain name resolution request.

14. The method of claim 10, wherein the first server sends the one or more packets to the second server in a tunnel.

15. The method of claim 10, wherein the first server determines to forward the one or more packets based at least in part on any of: a service that the client is requesting; the particular content that the client is requesting.

16. The method of claim 10, wherein the map associates any of (i) client IP addresses and (ii) client IP address subnets, with IP addresses for any of: (i) servers and (ii) points of presence.

17. The method of claim 10, wherein the first and second servers are servers in a content delivery network run by any of: (i) a service provider, (ii) a network operator, and (iii) an internet service provider.

18. The method of claim 10, further comprising distributing the map to a plurality of servers, including the first server.