MXPA01000454A - Global document hosting system utilizing embedded content distributed ghost servers - Google Patents

Abstract

A network architecture or framework that supports hosting and content distribution on a truly global scale. The framework allows a Content Provider to replicate and serve its most popular content atan unlimited number of points throughout the world. The framework comprises a set of servers operating in a distributed manner. The actual content to be served is preferably supported on a set of hosting servers (36), sometimes referred to as ghost servers. This content comprises HTML page objects that, conventionally, are served from a Content Provider site. In accordance with the invention, however, a base HTML document portion of a web page is served from the Content Provider's site (1), while one or more embedded objects for the page are served from the hosting servers (3, 4), preferably those hosting servers (5) near the client machine. By serving the base HTML document from the Content Provider's site, the Content Provider maintains control over the content.

Description

GLOBAL HOST SYSTEM OF DOCUMENTS THAT USES GHOST SERVERS DISTRIBUTED OF BUILT-IN CONTENT FIELD OF THE INVENTION This invention relates, in general, to the retrieval of information in a computer network. More particularly, the invention relates to a novel method for performing functions of hosting and distribution of content on the Internet (Interconnected Networks) that addresses the problems of Internet Service Providers (ISP) and Internet Content Providers.

BACKGROUND OF THE INVENTION The World Wide Web is the Internet's multi-media information retrieval system. In the Web environment, the clients' machines carry out transactions with the Web servers using the Hypertext Transfer Protocol (HTTP), which is a known application protocol that provides users with access to the files (for example, text, graphics, images, sound, video, etc.) using a standard page description language, known as a Hypertext Markup Language (HTML). HTML provides a basic formatting of documents and allows the designer to specify "links" with other servers and files. In the Internet paradigm, a network path to a server is identified by the so-called Uniform Resource Locator (URL) that has a special syntax to define a network connection. The use of an HTML compatible browser (for example, Netscape Navigator or Microsoft Internet Explorer) on a client's machine, involves specifying a link through the URL. In response, the client makes a request to the server identified in the link and, in return, receives a document or other object formatted according to the HTML. A collection of documents supported on a Web server is sometimes referred to as a Web site. It is well known in the prior art, for a Web site, to perform mirrored mirroring of its content, on another server. Indeed, currently, the only method for a Content Provider to place its content in a site closer to its readers is to build copies of its Web site in machines that are located in computer collaborators that perform Web host functions in different sites. , both domestically and internationally. These copies of the websites are known as mirror-like sites. Unfortunately, mirror-like sites represent unnecessary economic and operational burdens for Content Providers, and do not offer economies of scale. Economically, the total cost for a Content Provider with a primary site and another mirror-like site is more than double the cost of a single primary site. This additional cost is the result of two factors: (1) the Content Provider must contract with a separate facility that performs host functions, for each mirror-type site, and (2) the Content Provider must incur additional indirect costs , associated with the synchronized maintenance of mirror-like sites. In an effort to address the problems associated with mirrored mirroring, companies such as Cisco, Resonate, BrightTiger, F5 Labs and Alteon, are developing software and hardware that will help keep mirror sites balanced and their load balanced. Although these mechanisms are useful for the Content Provider, they fail to address the underlying problem of scaling capacity. Even if a Content Provider wishes to incur the costs associated with mirror-like duplication, the technology itself will not allow escalations beyond a few (that is, less than 10) Web sites. In addition to these economic issues and escalation capacity, mirror-like duplication also involves operational difficulties. A Content Provider that uses a mirror-like site must not only lease and manage physical space in distant sites, but also must buy and maintain the software or hardware that synchronizes and balances the load of the sites. Current solutions require that Content Providers provide personnel, technology and other necessary elements to maintain multiple Web sites. In summary, mirror-like mirroring requires that Content Providers spend economic and other resources on functions that are not relevant to their core business activity, to create the content. In addition, Content Providers also want to retain control of their content. Today, some ISPs are installing temporary memory management (cache) hardware that disrupts the link between the Content Provider and the end user. The effect of that cache can produce devastating results to the Content Provider, including (1) that of preventing the Content Provider from obtaining accurate hit counts on its Web pages (thereby reducing the advertisers' income), (2) preventing that the Content Provider adjusts the content according to their needs, and directs its advertising to specific audiences (which severely limits the effectiveness of the Content Provider's Website), and (3) provides non-updated information to its clients ( which can lead to an end user becoming frustrated and annoyed). There remains a significant need in the art to provide a decentralized host function solution, which allows users to obtain Internet content on a more efficient basis (ie, without unnecessarily burdening the Network's resources) and likewise allow the Content Provider to maintain control over its content. The present invention solves these and other problems associated with the prior art.

SUMMARY OF THE INVENTION A general object of the present invention is to provide a computer network comprising a large number of widely deployed Internet servers, which form a massively fault-tolerant organic infrastructure, designed to serve Web content efficiently, effectively, and reliably. , to the end users. Another more general object of the present invention is to provide a fundamentally new and better method for distributing web-based content. The inventive architecture provides a method to intelligently route and replicate the content through a large network of distributed servers, preferably without centralized control. Another object of the present invention is to provide a network architecture that moves the content to a site near the user. The inventive architecture allows Web sites to develop large audiences without worrying about the construction of a massive infrastructure, to handle the associated traffic. Still another object of the present invention is to provide a fault-tolerant network for distributing Web content. The network architecture is used to accelerate the supply of richer Web pages, and allows Content Providers, with large audiences, to serve them reliably and economically, preferably from servers located near the end users. An additional feature of the present invention is the ability to distribute and manage the content, through a large network, without interrupting the direct relationship of the Content Provider with the end user. Still another feature of the present invention is to provide a scalable, distributed infrastructure for the Internet, which moves the distribution load of the Web content, from the Content Provider to a network of preferably hundreds of servers performing host functions. , deployed, for example, on a global basis. In general, the present invention consists of a network architecture that supports hosts on a truly global scale. The inventive structure allows a Content Provider to reproduce its most popular content, in an unlimited number of points throughout the world. As an additional feature, the actual content that is reproduced in any geographic location is specifically made according to the needs of the observers in that location. In addition, the content is automatically sent to the location where it is requested, without any effort or indirect costs by a Content Provider. Thus, a more general object of this invention is to provide a host structure on a global scale, to allow Content Providers to retain control over their content. The host structure of the present invention comprises a set of servers that operate in a distributed manner. The actual content to be served is preferably supported on a set of servers with host functions (sometimes referred to as phantom servers). This content includes objects of pages in HTML that, conventionally, are served from the site of a Content Provider. However, in accordance with the invention, a basic portion of the HTML document of a Web page is served from the Content Provider site, while one or more embedded objects, for the page, are served from the host servers , preferably, those host servers that are closest to the client's machine. By serving the basic document in HTML, from the Content Provider site, the Content Provider maintains control over the content. The determination that the host server should be used to serve a particular embedded object is made by other resources that are in the host structure. In particular, the structure includes a second set of servers (or server resources) that are configured to provide the highest level Domain Name Service (DNS). In addition, the structure also includes a third set of servers (or server resources) that are configured to provide low-level DNS functionality. When a client's machine issues an HTTP request to the Web site for a particular Web page, the basic document in HMTL is served from the Web site as previously mentioned. The objects incorporated for the page are preferably served from the particular host servers, identified by the highest and lowest level DNS servers. To locate the servers that perform host functions, appropriate, to be used, the highest level DNS server determines the user's location in the network, in order to identify a low-level DNS server, determined, that responds to the request with respect to the incorporated object. The highest-level DNS server then redirects the request to the identified low-level DNS server, which in turn resolves the request to an IP address for the particular host server serving the object back to the client. More generally, it is possible (and in some cases desirable) to have a hierarchy of DNS servers consisting of several levels. The one that is in a lower place moves in the hierarchy and the one that is closer reaches the best region. A further aspect of the invention is a means by which the content can be distributed and reproduced through a collection of servers, such that the use of the memory is optimized in a manner subject to the restrictions that there is a sufficient number of copies of any object, to satisfy the demand, the copies of objects are disseminated in such a way that no server becomes overloaded, the copies tend to be located in the same servers as time goes by, and the copies are located in regions close to the clients that are requesting them. In this way, the servers that work within the structure do not keep copies of all the content databases. On the contrary, certain servers keep copies of a minimum amount of data, so that the entire system provides the required level of service. This aspect of the invention allows the host scheme to be much more efficient than caching schemes everywhere and everywhere, or caching objects, only in pre-specified locations. The host network on a global scale is tolerant to failures at each level of operation. In particular, the top-level DNS server returns a list of low-level DNS servers, which can be used by the client to service the request regarding the embedded object. Likewise, each host server preferably includes a colleague server that is used to assume the host responsibilities of its associated host server, in the case of a failure condition. In accordance with the present invention, load balancing is through the set of host servers, is achieved in part through a novel technique for distributing the requests of embedded objects. In particular, each URL of the built-in object is preferably modified by previously placing a virtual server host name on hold in the URL. More generally, the host name of the virtual server is inserted in the URL. Preferably, the host name of the virtual server includes a value (sometimes referred to as a serial number) generated by applying a particular random check function (hash function) to the URL or encoding the given imation, about the object, in the value. This function is used to randomly distribute the built-in objects through a set of virtual server host names. further, a certain fingerprint value is generated for the built-in object, through the application of a particular hash function, for the same built-in object. This determined value serves as a fingerprint that identifies whether the built-in object has been modified. Preferably, the functions used to generate the values (that is, for the host name and the fingerprint of the virtual server) are applied to a particular Web page in an offline process. In this way, when an HTTP request is received for the page, the basic document in HTML is served by the Web site and some portion of the embedded objects of the page are served from the host servers, nearby (although not necessarily the closest ones). ) to the client's machine that initiates the request. The foregoing has outlined some of the most pertinent objects and features of the present invention. These objects should be considered only illustrative of some of the most prominent features and applications of the invention. Many other beneficial results can be achieved by applying the described invention in a different manner, or by modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention can be had, with reference to the following detailed description of the preferred embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the present invention and advantages thereof, reference should be made to the following detailed description, taken in conjunction with the accompanying drawings in which: Figure 1 is a representative system in which the present invention is implemented; Figure 2 is a simplified representation of a document with markup language, which illustrates the basic document and a set of built-in objects; Figure 3 is a high-level diagram of a global host system, in accordance with the present invention; Fig. 4 is a simplified flow chart, illustrating a method for processing a Web page to URLs of modified embedded objects, which is used in the present invention; Figure 5 is a simplified state diagram, illustrating how the present invention responds to an HTTP request referring to a Web page.

DETAILED DESCRIPTION OF THE PREFERRED MODALITY A known system of client and Internet server is implemented as illustrated in Figure 1. The machine 10 of a client is connected to a Web server 12 through a network 14. For illustrative purposes, network 14 is the Internet , an intranet, an extranet or any other known network. The Web server 12 is one of a plurality of servers to which the clients can access, one of which is illustrated by the machine 10. A machine representative of the client includes a browser 16, which is a known software tool, used to access the servers in the network. The Web server supports files (collectively referred to as a "Web" site) in the form of documents and hypertext objects. In the Internet paradigm, a network route, to a server, is identified by the so-called Uniform Resource Locator (URL). A representative Web server 12 is a computer comprising a processor 18, an operating system 20, and a Web server program 22, such as Netscape Enterprise Server. The server 12 also includes a display screen that supports a graphical user interface (GUI) for management and administration, and an Application Programming Interface (API) that provides extensions to allow application designers to extend and / or adapt to the specific needs the central functionality of the same, through software programs that include programs of Common Gateway Interface (CGI) plug-in elements, server inputs and outputs, active server pages, functions that include the side of the server (SSI) or similar. A representative Web client is an x86 personal computer, PowerPC * or RISC, which includes an operating system such as 03/2 ™ from IBM ™ or Microsoft Windows? 95, and includes a Web browser, such as Netscape Navigator 4.0 (or higher) ), that has a Java Virtual Machine (JVM) and support for plug-in elements of the application, or auxiliary applications. A client can also be a notebook-type laptop, a hand-held computing device (for example, a PDA), an Internet device, or any other type of device that can be connected to the computer network. As seen in Figure 2, a typical Web page comprises a master or basic document 28 in markup language (e.g., HTML) and many built-in objects (e.g., images, audio, video or the like) 30. In this way , on a typical page, twenty or more images or built-in objects are quite common. Each of these images is a separate object on the Web, which is retrieved (or valid for a change) separately. The common behavior of a Web client is, therefore, to search the base HTML document, and then immediately search for the embedded objects, which are typically (but not always) located on the same server. In accordance with the present invention, preferably the basic document in markup language 28 is served from the Web server (ie, the Content Provider site) while a certain number (or perhaps all) of the embedded objects are served. from other servers. As will be seen, preferably a built-in object, determined, is served from a server (different from the Web server itself) that is close to the client's machine, that is, it is not overloaded, and most likely already has a current version of the required file.

Referring now to Figure 3, this operation is achieved by the host system of the present invention. As will be seen, the host system comprises a set of widely deployed servers (or server resources) that form a large, fault-tolerant infrastructure designed to serve the Web's content in an efficient, effective, and reliable manner for the end users. The servers can be deployed globally, or through any desired geographic region. As will be seen, the system with host functions provides a distributed architecture to intelligently route and reproduce that content. For this purpose, the global host system comprises three (3) basic types of servers (or server resources): host servers (sometimes called ghosts) 36, top-level DNS servers 38, and low-level DNS servers 40 Although not illustrated, there may be additional levels in the DNS hierarchy. Alternatively, there may be a single DNS level that combines the functionality of the highest level and low level servers. In this illustrative embodiment, the inventive structure 35 is displayed by an Internet Service Provider (ISP), although this is not a limitation of the present invention. The ISP or ISPs that deploy the inventive global host structure preferably has a large number of machines that execute both the ghost server component 36 and the low-level DNS component 40 in their networks. These machines are distributed throughout the network; they are preferably concentrated around the exchange points 42 of the network and the access points 44 to the network, although this is not a requirement. In addition, the ISP preferably has a small number of machines running the highest level DNS 38 which may also be distributed throughout the network. Although without intending to place limitations, preferably a particular server used in structure 35 includes a processor, an operating system (for example, Linux, UNIX, Windows? T, or similar), a Web server application, and a set of application routines used by the invention. These routines are conveniently implemented in software, as a set of instructions executed by the processor, in order to carry out several process steps or method, as will be described in more detail later. The servers are preferably located on the edges of the network (for example, points of presence, or POP). Several factors can determine if the host servers are placed in the network. Thus, for example, the server sites are preferably determined by a network map activated on demand, which allows the provider (for example, the ISP) to inspect the traffic requests. By studying the traffic patterns, the ISP can optimize the server locations for the determined traffic profiles. In accordance with the present invention, a given Web page (containing a basic document in HTML and a set of built-in objects) is served in a distributed manner. In this way, preferably, the basic HTML document is served from the Content Provider that normally performs host functions with the page. The incorporated objects, or some subset thereof, are preferably served from the host servers 36 and, specifically, certain host servers 36 that are located near the client's machine, which in the first case initiated the request of the Web page. In addition, preferably the loads that are found through the host servers, are balanced to ensure that a built-in object, determined, can be efficiently served from a particular host server that is close to the client, when that client requires that object to complete the page. To serve the content of the page in this way, the URL associated with a built-in object is modified. As is well known, each embedded object that can be served on a page has its own URL. Typically, the URL has a host name that identifies the Content Provider site, from which the object is conventionally served, ie, without reference to the present invention. In accordance with the invention, the URL of the embedded object is first modified, preferably in an offline process, to the condition of the URL to be served by the global host servers. A flow chart illustrating the preferred method for modifying the URL of objects is illustrated in Figure 4. The routine begins at step 50 by determining whether all the objects incorporated into a particular page have been processed. If so, the routine ends. However, if not, the routine obtains the next built-in object, in step 52. In step 54, a host name of the virtual server is previously placed on hold in the URL for the given built-in object. The host name of the virtual server includes a value (for example, a number) that is generated, for example, by applying a particular hash function, to the URL. As is well known, a hash function takes as input a string of bits of arbitrary length and produces, as outputs, fixed-length bit chains (hash values). These functions satisfy two conditions: (1) it is impossible to find two entries that produce the same hash value, and (2) given an entry and its hash value, it is impossible to find a different entry with the same hash value. In step 54, the URL for the embedded object is submitted to the hash function to produce a value xx, xxx which is then included in the host name of the virtual server. This stage randomly distributes the object for a host name of the given virtual server. The present invention is not limited to the generation of a host name of the virtual server, by applying a hash function as described above. As an alternative and preferred embodiment, a host name of the virtual server is generated as follows. Consider the representative hostname al234.g. akamaitech.net. The value 1234, sometimes referred to as a serial number, preferably includes information about the object such as its size (large or small), its anticipated popularity, the date on which the object was created, the identity of the site Web, the type of object (for example, movie or static image), and perhaps some random bits generated by a certain randomness function. Of course, it is not required that any given serial number encode all that information or even a significant number of those components. In effect, in the simplest case, the serial number can be a simple whole number. In any case, the information is coded in a serial number, in any convenient way. In this way, for example, a first bit is used to denote the size, a second bit is used to denote popularity, a set of additional bits is used to denote the date, and so on. As mentioned earlier in the hash function application example, the serial number is also used to balance the load and to direct certain types of traffic to certain types of servers. Typically, most URLs on the same page have the same serial number to minimize the number of DNs needed per page. This requirement is less important for larger objects. In this way, in accordance with the present invention, a virtual server host name is previously placed on hold in the URL for a particular embedded object, and this host name includes a value (or serial number) that is generated by applying a function determined to the URL or object. The function can be a hash function, a coding function, or similar. Now focusing again on the flowchart, the routine then continues in step 56 to include a determined value in the URL of the object. Preferably, the determined value is generated by applying a particular hash function to the embedded object. This stage creates a unique fingerprint of the object, which is useful for determining whether the object has been modified or not. Subsequently, the routine returns to stage 50 and cycles. With the foregoing as background, the inventive global host structure is now described in the context of a specific example. In particular, it is assumed that a user of a client machine in Boston requests a Web page from the Content Provider normally maintained by a host in Atlanta. For illustrative purposes, it is assumed that the Content Provider is using the global host architecture, on the network, which may be global, international, national, regional, local or private. Figure 5 shows the different components of the system and how the client's request is processed. This operation is not taken as a limitation, as will be explained. Stage 1: The browser sends a request to the Supplier's website (point 1). The Content Provider site in Atlanta receives the request in the same way it does as if a global host network was not implemented. The difference is that it is returned through the Provider's site. Instead of returning the usual page, in accordance with the invention, the website returns a page with URLs of built-in objects, which are modified in accordance with the method illustrated in the flow diagram of figure 4. As previously described, the URLs are preferably changed as follows: Assume that there are 100,000 virtual phantom servers, although there may only be a relatively small number (for example 100) physically present in the network. These virtual ghost servers or virtual ghosts are identified by the host name: ghostxxxxx.ghosting.com, where xxxxx is replaced by a number between 0 and 99,999. After the content provider's Web site is updated with new information, a script that runs on the Content Provider site is carried out in such a way that it rewrites the embedded URLs. Preferably, the embedded URL names are submitted to the hash function to produce numbers between 0 and 99,999, although this range is not a limitation of the present invention. A built-in URL is then changed to refer to the virtual ghost with that number. For example, the following is an embedded URL, from the Provider's site: <; IMG SRC = htt: //www.provider. com / ECH / images / space. story gif > . If the serial number for the object that is referenced by this URL is the number 1467, then preferably the URL is rewritten to be like: < IMG SRC = http: // ghostl467. ghosting akamai. com / www.provider. com / TECH / image s / space. story.gif > . The use of serial numbers in this way distributes the incorporated URLs, roughly uniformly, into the 100,000 names of virtual ghost servers. Note that the Supplier's site can still customize the page, rearranging the different objects on the screen, according to individual preferences. In addition, the provider can also insert ads dynamically and count how many people have seen each ad. In accordance with the preferred embodiment, a further modification to the incorporated URLs is made to ensure that the global host system does not serve discontinued information. As previously described, preferably a routing value of the data contained in the embedded URL is also inserted in the embedded URL, itself. That is, each embedded URL can contain a fingerprint of the data it indicates. When the underlying information changes, so does the fingerprint, and this prevents users from referring to old data. The second addressing value takes a bit stream as input and outputs what is sometimes referred to as a fingerprint of the stream. The important property of the fingerprint is that two different streams almost certainly produce two different fingerprints. Examples of these addressing values are the MD2 and MD5 hash functions, however, other, more transparent methods such as a simple checksum can be used. To be specific, assume that the output of the address value is a 128-bit signature. This signature can be interpreted as a number and can then be inserted into the embedded URL. For example, if the hash of the data in the space.story.gif image of the Provider's website is the number 28765, then the incorporated, modified URL would look really like this: < IMG SRC = http: //ghostl467.ghosting. akamai. com / 28765 / www. provider com / TECH / images / space. story.gif "> Every time a page is changed, preferably the hash for each embedded URL is recalculated and the URL is rewritten if necessary, if any of the URL data changes, for example, it Insert a new and different image with the name space.story.gif, then the hash value of the data is different and therefore the URL itself will be different.This scheme prevents the system from serving data that is not updated as a result of Updates made to the original page For example, assume that the space.story.gif image is replaced with a more up-to-date version on the Content Provider server Because the image data changes, the URL hash It changes as such, so the new built-in URL looks the same, except that a new number is inserted for the fingerprint.Any user who requests the page after the update receives a page that indicates the New image: The old image is never referenced and can not be returned wrongly instead of the most up-to-date information. In summary, there are preferably two operations of the hash function, which are performed to modify the pages of the Content Provider. First, the hash function can be a component of the process by which a serial number is selected to transform the domain name into a virtual ghost name. As will be seen, this first transformation serves to redirect clients to the global host system to retrieve the embedded URLs. Later, a hash value of the data indicated by the incorporated URLs is calculated, and inserted into the URL. This second transformation serves to prevent ghost servers from serving a discontinued and non-updated content. Preferably, these two transformations are carried out offline and therefore have no potential bottlenecks in operation. Generalizing, the preferred URL scheme is as follows. The domain ilustrativowww.domainname.com/frontpage.jpg becomes: xxxx.yy. zzzz .net / yyyy / www. domainname com / frontpage. jpg, where: xxx = serial number field yy = lower level DNS field zzzz = maximum level DNS field aaaa = other information field (for example, fingerprint). In addition to the additional levels of the hierarchy If DNS is used, there may be DNS fields with lower, additional levels, for example, xxxx. and ^. y2y2 zzz.net/aaaa / ... Stage 2: after receiving the initial page from the Content Provider site, the browser needs to load the incorporated URLs for the display of the page. The first step to do this is to make contact with the DNS server on the user's machine (or the user's ISP) to resolve the altered host name, in this case: ghostl467.ghosting.akamai.com. As will be seen, the architecture with host functions at a global scale, of the present invention, manipulates the DNS system in such a way that the name has been solved for one of the ghosts that is close to the client and that probably already has the list ready. page. To appreciate how this is done, the following describes the progress of the DNS query that was initiated by the client. Step 3: As previously described, there are preferably two types of DNS servers in the inventive system: top-level and low-level. The highest level DNS servers 38, for ghosting.com have a special function that is different from the regular D? S servers such as those in the .com domain. The highest level D? S 38 servers include appropriate control routines that are used to determine which network site a user is located in, and then to direct the user to a server akamai.com is (ie, a Low level D) by which it is closed. Like the .com domain, akamai.com preferably has a number of top-level 38 DNS servers, spread across the network for fault tolerance. In this way, a determined D &S server 38 at the highest level directs the user to a region on the Internet (which has a collection of servers 36 with host functions, which can be used to satisfy the request of a built-in object). , determined) while the low level DNS server 40 (within the identified region) identifies a particular host server within that collection from which the object is actually served. More generally, as indicated above, the DNS process may contain several levels of processing, each of which serves to better direct the client to a phantom server. The name of the ghost server may also have more fields. For example, you can use "al23.g.g. akamaitech.net" instead of "al23.ghost.akamai.com." If only one DNS level is used, a representative URL could be "al23.akamai.com." Although other techniques may be used, the user's location in the network is preferably inferred by observing the IP address of the client's machine making the request. In the present example, the DNS server is working on the user's machine, although this is not a requirement. If the user is using an ISP DNS server, for example, routines make the assumption that the user is located near (in the Internet sense) of this server. Alternatively, the user's location or IP address could be directly encoded in the request sent to the highest level DNS. To determine the physical location of an IP address in the network, preferably the top-level DNS server builds a map of the network that is then used to identify the relevant location. This way, for example, when a request reaches the highest level DNS for a resolution for al23 .g. akamaitech.net, the top-level DNS looks at the return address of the requester and then formulates the response based on that address, according to a map of the network. In this example, al234 is a serial number, g is a field that refers to the lowest level DNS, and akamaitech refers to the highest level DNS. The map of the network preferably contains a list of all the blocks of the Internet Protocol (IP), for each block of the IP, the map determines where to direct the request. The map is preferably continuously updated based on the conditions and traffic of the network. After determining in which part of the network the request originated, the highest level DNS server redirects the D? S request to a low level D? S server near the user in the network. The ability to redirect requests is a standard feature in the D? S system. In addition, this redirection can be done in such a way that if the local low level D server is inactivated, there is a backup server with which contact can be made.

Preferably, the TTL mark (life time) in these top-level DNS redirects, for the ghosting.com domain, is adjusted to be long. This allows DNS caching on DNS servers and / or ISP's DNS servers to prevent top-level DNS servers from being overloaded. If the TTL for ghosting.com on the DNS server on the user's machine or the ISP, has expired, then contact is made with a top-level server, and a new redirection towards a server D? S ghosting.akamai.com Low level, local, it is returned to a new TTL brand. It should be noted that the system does not cause a substantially higher number of D? S queries than those that were made in the common solutions of centralized host functions. This is because the TTL of the maximum level redirects is adjusted to be high and, thus, the vast majority of users are directed by their local D? S directly to the server D? S ghosting. Low level, surrounding akamai. In addition, fault tolerance for the highest level D? S servers is automatically provided by the D? S, similar to what was done for the popular. .com domain. Fault tolerance, for low level D? S servers, is preferably provided by returning a list of possible low level DNS servers, instead of just one server. If one of the low level D? S servers is deactivated, the user will still be able to make contact with one of the active and functioning list. Fault tolerance can also be manipulated through an "overflow control" mechanism where the client is redirected to a low level D? S located in a region that is known to have sufficient capacity to serve the object. This alternative approach is very useful in scenarios where there is a large amount of demand from a specific region _ or when there is a reduced capacity in a region. In general, customers are directed to regions, in a way that minimizes the total latency experienced by customers, subject to the restriction that no region is overloaded.

By minimizing the total latency subject to regional capacity, a restriction is preferably achieved using a multiple commodity flow algorithm at a minimum cost. Stage 4: At this point, the user has the address of a server D? S 38 near ghosting.com. The user's local D's server contacts the low-level DNS server 40, nearby, and requests a translation of the name ghost.1467.akamai.com. The D? S server is responsible for returning the IP address of one of the phantom servers 36 in the network, which is close to the user, which is not overloaded, and most likely has the required data ready. The basic mechanism to perform the assignment of the names of virtual ghosts, to real ghosts, is the key calculation. A preferred technique is the so-called consistent addressing calculation, such as described in US Patent Serial No. 09 / 042,228, filed March 13, 1998, and US Patent Serial No. 09 / 088,825, filed on 2 June 1998, each entitled "Method and Apparatus for Distributing Requests Among a Plurality of Resources," and which is owned by the Massachusetts Institute of Technology, which applications are incorporated herein by reference. The consistent hash functions make the system robust under failures and total machine stops. It also allows the system to grow elegantly, without changing where most of the Articles are located and without perfect information about the system. In accordance with the invention, the virtual ghost names can be submitted to the hash function to change to real ghost addresses, using a look-up table, where the table is updated continuously based on the conditions and traffic of the net, in such a way as to ensure load balancing and fault tolerance. Preferably, a resolution table is created for each serial number. For example, serial number 1 resolves to phantom 2 and 5, serial number 2 resolves to phantom 3, serial number 3 resolves ghosts 2, 3, 4, and so on. The goal is to define the resolutions in such a way that no ghost exceeds its capacity and that the total number of all ghosts in all resolutions is minimized. This is done to ensure that the system can take maximum advantage of the available memory in each region. This is a major advantage over existing load balancing schemes, which tend to cache anything and anywhere, or only cache certain objects in certain locations, no matter what the load is. In general, it is desirable to make allocations in such a way that those resolutions tend to remain consistent over time, provided that the charges do not change too much in a short period. This mechanism also preferably takes into account how close the user's ghost is, and how loaded the ghost is at that moment. Note that the same virtual ghost is preferably translated into real, different ghost addresses, according to the site where the user is located on the network. For example, assume that the ghost server 18.98.0.17 is located in the United States of America and that the ghost server 132.68.1.28 is located in Israel. A DNS request for ghost.1487.ghosting.akamai.com that originates in Boston will resolve to 18.98.0.17, while a request originating in Tel.Aviv will resolve to 132.68.1.28. Low-level DNS servers monitor the different ghost servers to take their charges into account, while translating the virtual ghost names into real addresses. This is handled by a software routine (computer programs) that work on ghosts and low-level DNS servers. In one embodiment, the load information is circulated among the servers in a region, so that they can calculate the resolutions for each serial number. An algorithm to calculate resolutions works as follows. The server first calculates the projected load (based on the number of user requests) for each serial number. The serial numbers are then processed to increase the order of the load. For each serial number, a random priority list of desired servers is assigned, a consistent key calculation method. Each serial number is subsequently resolved to the smallest initial segment of servers, from the priority list, so that no server becomes overloaded. For example, if the priority list for a serial number is 2,5,3,1,6, then an attempt is made first to try to assign the load for the serial number, to the phantom 2. If this overloads the ghost 2, then the load is assigned to both ghosts 2 and 5. If this produces too much load on any of those servers, then the load is assigned to ghosts 2,3, and 5 and so on. The projected load in a server can be calculated observing all the resolutions that contain that server and adding the amount of load that is probably going to be sent, to that server from that serial number. This method of producing resolutions is the most effective when used in an iterative form, where assignments begin in a default state, where each serial number is assigned to each fault phantom. Retreating the table of resolutions, according to the previous procedure, the load is balanced using the minimum number of reproductions (thus maximally conserving the available memory in a region). The TTL for these low level DNS translations, it is adjusted to be short and allows a quick response when a heavy load is detected in one of the ghosts. The TTL is a parameter that can be manipulated by the system to ensure a balance between the synchronized response for a high load on the ghosts and the induced load on the low level DNS servers. Note, however, that even if the TTL for low-level DNS translation is set to a value of 1 to 2 minutes, a few users will actually have to perform a low-level DNS query. Most users will see a DNS translation that is cached on their machine or on their ISP. In this way, most users go directly from their local DNS server to the nearest ghost that has the data they want. Those users who actually perform a low level DNS query, have a very small added latency, however this latency is small compared to the advantage of recovering that most of the data is closed. As mentioned above, fault tolerance, for low-level DNS servers, is provided if the top-level DNS returns a list of possible low-level DNS servers instead of a single server address. The user's DNS system caches this list (part of the standard DNS system), and makes contact with one of the other servers in the list, if the first one is deactivated for some reason. Low-level DNS servers make use of a standard DNS feature to provide an additional level of fault tolerance for ghost servers. When a name is translated, instead of returning a unique name, a list of names is returned. If for some reason the fault-tolerance method, primary, for ghosts (known as the Colleague system, described later) fails, the client's browser will make contact with one of the other ghosts in the list. Step 5: The browser then makes a request for an object named al23.ghosting.akamai.com / ... /www.provider. com / TECH / images / s pace.story.gif from the near ghost. Note that the name of the original server (www.provider.com) is preferably included as part of the URL. The software that runs on the ghost analyzes the name of the page in the original host name and the actual name of the page. If a copy of the file is already stored in the ghost, then the data is returned immediately. However, if there is no copy of the data in the ghost, a copy of the original server or another ghost server is recovered. Note that the ghost knows who the original server was, because the name was encoded in the URL that was passed to the ghost from the browser. Once a copy has been recovered, it is returned to the user, and preferably it is also stored in the ghost to answer future requests. As an additional protection, it may be preferable to verify that the user is indeed close to the server. This can be done by examining the IP address of the client, before responding to the file request. This is useful in the rare case when the client's DNS server is far away from the client. In that case, the phantom server can redirect the user to a closer server (or to the other virtual address that is likely to be resolved to a server that is closer to the client). If the redirect is to a virtual server, then it must be labeled to prevent additional redirects from occurring. In the preferred mode, redirection would be done only for large objects; In this way, a verification can be made before applying a redirection, to be sure that the object being requested exceeds a certain total size. Performance for long downloads can also be improved by dynamically changing the server a client is connected to based on changing network conditions. This is especially useful for audio and video downloads (where connections can be long and where quality is especially important). In those cases, the user can be directed to an alternative server in the middle of the stream. The control structure to redirect the client may be similar to the one described above, but may also include software that is located in the client's browser or media player. The software monitors the performance of the client connection and perhaps the state of the network as such. It is considered that the client connection can be improved by changing the server, then the system directs the client to a new server for the rest of the connection. Fault tolerance for ghosts is provided by a colleague system, where each ghost has a designated colleague ghost. If a ghost is deactivated, your colleague assumes his work (and IP address) in such a way that the service is not interrupted. Another characteristic of the system is that the collateral ghost does not have to be inactive waiting for a failure. Instead, all machines are always active, and when a failure occurs, the load is absorbed by the colleague and then balanced by the low-level DNS system to the other active ghosts. An additional feature of the colleague system is that fault tolerance is provided without having to wait for long periods of downtime. Still as another feature of the system with host functions on a global scale, a gate mechanism can be used to maintain total traffic, for certain objects within specified limits. One mode of the gate mechanisms works as follows. When the number of requests for an object exceeds a certain specified threshold, then the server may choose not to serve the object. This can be very useful if the object is very large. Instead, the customer can serve a much smaller object that asks the customer to return later. Or, the client can be redirected. Another method to implement a gate is to provide the customer with a "ticket" that allows the customer to receive the object at a prespecified future time. In this method the ghost server needs to verify the time on the ticket before serving the object. The inventive global host scheme is a way for ISPs, or global ISP, regional conglomerates, to strengthen their network infrastructure and generate revenue for host functions, and save bandwidth in the network. An ISP that offers the scheme of host functions on a global scale, inventive, can give Content Providers the ability to distribute content to their users, from the nearest point in the ISP's network, thus ensuring access fast and reliable. The guaranteed functioning of the website is critical for any web-based business, and the host function on a global scale allows the creation of a service that meets this need. The global host functions, in accordance with the present invention, also allow an ISP to control how and where the content crosses its network. Global host servers can be configured on the edge of the ISP network (for example, at many network exchange and access points). This allows the ISP to serve the content for sites for which it is hosted, directly to the exchange points and at the network access points. Expensive backbone links do not have to carry more redundant traffic from the Content Provider site to the exchange and access points to the network. Instead, content is served directly outside the ISP network, freeing up valuable network resources for other traffic. Although the global host function reduces network traffic, it is also a method by which global ISPs can capture a rapidly expanding piece of the market that offers host functions, which is currently estimated to be in excess of a billion. of dollars per year. The solution with host functions at a global level also provides numerous advantages for Content Providers, and, in particular, an efficient and cost-effective solution to improve the performance of their websites, both domestically and internationally. The software with host functions, inventive, assures the Content Providers, a fast and reliable Internet access, providing a means to distribute the content to their subscribers from the nearest point in an ISP network. In addition to other benefits described in more detail later, the solution with global host functions also provides the important benefit of reducing network traffic. Once the cheap, global host servers are installed on the periphery of an ISP network (that is, at the many exchange points and access to the network), the content is served directly to the exchange and access points to the Internet. network. As a result of this efficient content distribution, directly from an ISP network, the present invention substantially improves the performance of the Web site. In contrast to current content distribution systems, the solution with inventive global host functions does not require expensive backbone links to transport redundant traffic from the Content Provider website to the exchange and access points to network. A summary of the specific advantages provided by the inventive global host scheme is presented below: 1. Reduced Operating Expenses for Content Providers: Most competitive solutions require Content Providers to purchase servers at each site. Web that offers host functions to its content. As a result, Content Providers often have to negotiate separate contracts with different ISPs around the world. In addition, the Content Providers are generally responsible for the reproduction of the content and for maintaining the servers at these remote sites. With the present invention, ISPs are primarily responsible for most aspects of global host functions. Content Providers preferably maintain only their single source server. The content on this server is automatically played by software, to the sites to which you have access. No intervention or planning is needed from the provider (or, for that matter, the ISP). Content Providers provide instant access to all servers in the global network; there is no need to select where to play the content or buy additional servers at remote sites. 2. Data Reproduction, Intelligent and Efficient: Most competitive solutions require Content Providers to reproduce their content on servers, on a site with commercial host functions, or to duplicate their content on geographically distant servers. No approach is particularly efficient. In the previous situation, the content is still located in a single site on the Internet (and thus is far from most users). In the latter case, all the content of a Web site is copied to remote servers, even though only a small portion of the content may actually need to be remotely located. Even with a cheap memory, the excessive cost associated with that mirror-like duplication makes it not economical to mirror-mirror over more than a few sites, which means that most users will still be far from the mirror-like mirroring site. . Mirror mirroring also has the added disadvantage that Content Providers must ensure that all sites remain consistent and current, which is not a trivial task even for a few sites. With the present invention, the content is automatically reproduced in the global server network, in an intelligent and efficient way. The content is reproduced only in those places where it is needed. In addition, when the content changes, preferably new copies are reproduced automatically throughout the network. 3. Automatic Content Management: Many existing solutions require active management of content distribution, content playback and load balancing between different servers. In particular, decisions about where content will receive the host functions can be done manually, and the process of data reproduction is handled in a centralized automation form. On the contrary, the invention exhibits a passive handling. The reproduction is done in a form of automation based on demand, so that the content is preferably sent only where it is really needed. In addition, the process is preferably fully automated; The ISP does not have to worry about how and where the Content and / or the Content Provider is reproduced. 4. Unlimited Escalation Capacity, Cost Effective: Competitive solutions can not be scaled to more than a small number of sites. For example, solutions based on mirrored mirroring are typically used in relation to the most with three or four sites. Barriers to scaling include the cost of reproducing the entire site, the cost of reproducing compute resources across all nodes, and the complexity of supporting widely varying software packages that content providers use on their servers. The unique architecture of the system, of the present invention, can be scaled up to hundreds, thousands or even millions of nodes. Servers in the network with host functions may malfunction or stop altogether, and the overall function of the system is not affected. The structure with global host functions makes efficient use of resources; the servers and the client's software do not need to be reproduced in each node, because only the server with host functions is executed in each node. In addition, the server with global host functions, is designed to run on simple hardware, standard, which does not require to be very tolerant to failures. 5. Protection against Instant Agglomerations: Competitive solutions do not provide the Content Provider with protection against unexpected instantaneous agglomerations. Although mirror-type duplication and load balancing solutions, related, allow in fact that a Content Provider distributes load through a collection of servers, the aggregate capacity of the servers must be sufficient to handle the peak demands. This means that the Content Provider must purchase and maintain a level of resources in proportion to the anticipated peak load, rather than the true average load. Given the highly variable and unpredictable nature of the Internet, these solutions are expensive and waste many resources.

The architecture with host functions, inventive, allows the ISPs to use a single network with host functions, to offer Content Providers protection against instantaneous agglomerations. That is, the assurance that the network will adapt automatically and will support a greater unexpected load on the Provider's site. Because the ISP is adding many Providers in the same global network, resources are used more efficiently. 6. Substantial Bandwidth Saving: Competitive solutions do not provide substantial savings in bandwidth to ISPs or Content Providers. Through the use of mirrored mirroring, it is possible to save bandwidth through certain links (ie, between New York and Los Angeles). However, without global host functions, most requests for content will still need to transit the Internet, thus incurring bandwidth costs. The structure with host functions, inventive, saves a substantial backbone network bandwidth, for ISPs that have their own backbones. Because the content is distributed throughout the network and can be placed close to the exchange points of the network, both ISPs and Content Providers experience substantial savings, because there are no charges to the network backbone for most content requests. 7. Instant Access to the Global Network: Competitive solutions require that the Content Provider manually selects a small collection of sites in which the content will be handled with host and / or reproduced functions. Even if the ISP has numerous sites to perform host functions, in widely varying locations, only those specifically selected sites will be used (and will be paid for) to perform host functions in the content, for that Content Provider. On the contrary, the solution of performing host functions at a global level, of the present invention, allows ISPs to offer their clients instant access to the global network of servers. To provide instant access to the global network, the content moves preferably, constantly and dynamically around the network. For example, if a Content Provider adds content that will be of interest to customers located in Asia, the Content Provider will be assured that its content will automatically move to servers that are also located in Asia.

In addition, the network that acts as a global host, allows the content to move very close to the end users (including as close as the user's building can be, in the case of the business market). 8. Designed for ISP and Conglomerates Global: Most competitive solutions are designed to be purchased and managed by Content Providers, many of whom are already facing a challenge consistently and are consumed by the administrative and operational tasks of managing a single server . The scheme with host functions, inventive, can be deployed by a global ISP, and provides a new service that can be offered to Content Providers. One feature of the service is that it minimizes the operational and administrative requirements of a Content Provider, thus enabling the Content Provider to focus on its core business activity of creating unique content. 9. Effective Control of Patrimonial Databases and Confidential Information: Many competitive solutions require that Content Providers reproduce their patrimonial databases, in multiple geographically distant places. As a result, the Content Provider effectively loses control over their proprietary and usually confidential databases. To remedy these problems, the solution of host functions on a global scale, of the present invention, ensures that Content Providers retain full control over their databases. As described above, initial requests for content are directed to the Content Provider's central website, which then implements effective and controlled as to the database. Preferably, static portions with large bandwidth, for page requests, are retrieved from the network with global host functions. 10. Compatibility with the Content Provider Software: Many competing solutions require Content Providers to use a specific set of servers and databases. These particular, non-uniform requirements restrict the ability of the Content Provider to use, in the most effective way, the new technologies, and may require costly changes to an existing infrastructure of the Content Provider. By eliminating these problems, the architecture with inventive global host functions is effectively communicated between the Content Provider and the ISP, and makes no assumption about the systems or servers used by the Content Provider. In addition, the Content Provider systems can be updated, changed or completely replaced, without modifying or interrupting the inventive architecture. 11. There is no Interference with Dynamic Content, Personalized Advertising or Electronic Commerce, and there is no discontinued content: Many competitive solutions (such as naive caching of all content), can interfere with dynamic content, personalized advertising and electronic commerce, and may serve the user a discontinued content. Although other software companies have attempted to partially eliminate these situations (such as maintaining hit counts, for all cached copies), each of these solutions causes a partial or complete loss of functionality (such as the ability to customize the advertising) . On the contrary, the solution of global host functions does not interfere with the generation of dynamic content, personalized advertising or electronic commerce, because each of these tasks is preferably handled by the central server of the Content Provider. 12. Designed for the Global Network: The architecture with global host functions can be greatly scaled and deployed on a global network basis. The functionality described above, of each of the components of the architecture with global host functions, is preferably implemented in software that can be executed in a processor, especially as a set of instructions or program code in a code module resident in the random as memory of the computer. Until required by the computer, the instruction set may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM). ) or floppy disk (for eventual use on a floppy disk drive), or downloaded through the Internet or from another computer network. Furthermore, although the different described methods are conveniently implemented in a general-purpose computer, activated or selectively reconfigured by software, a person with ordinary skill in the art would also recognize that those methods can be carried out in hardware, in permanently stored software. , or in specialized devices built to carry out the required steps of the method. In addition, as used herein, a "client" of the Web shall be construed broadly as any computer or component thereof, connected, or connectable., directly or indirectly, in any way known or subsequently developed, to a computer network, such as the Internet. The term "server" Web shall also be interpreted broadly as a computer, computer platform, an attachment to a computer or platform, or any component thereof. Of course, a "client" should be broadly interpreted as one that requests or obtains the file, and "server" is the entity that downloads the file. Having thus described the invention, what is claimed as new and wishes to be protected by the Patent, is presented in the following claims.

Claims (34)

NOVEDJAD OF THE INVENTION Having described the above invention, it is considered as a novelty, and therefore, the content of the following is claimed as property: CLAIMS

1. A structure or host architecture, distributed, operating in a computer network in which users of the client's machines are connected to a server of the Content Provider, the structure is characterized in that it comprises: a routine to modify at least one URL of the built-in object, of a Web page, to include a intended host name for a domain name and path; a set of content servers, other than the Content Provider server, to perform host functions on at least some of the embedded objects of the Web pages that are normally hosted by the Content Provider server; at least one first-level name server, which provides the resolution of a first-level domain name service (DNS); and at least one second-level name server that provides the resolution of the second-level domain name service (DNS); where in response to requests from the Web page, generated by the client machines, where the Web page includes the URL of the incorporated, modified object, it is served from the Content Provider server and the embedded object identified by the URL of the Embedded object, modified, is served from one of the content servers, identified by the servers with first level and second level names.

2. The structure with host functions, according to the description of claim 1, characterized in that it also includes a first-level, redundant name server.

3. The structure according to the description of claim 1, characterized in that it includes a redundant second level name server.

4. The structure with host functions, in accordance with the description of claim 1, characterized in that a determined set, of the set of servers, includes a colleague server to assume the responsibilities of host functions, of the set determined between the set of servers, when a certain failure condition occurs.

5. The structure with host functions, according to the description of claim 1, characterized in that the second level name server includes a load balancing mechanism, which balances the loads through a subset of the server set .

6. The structure with host functions, in accordance with the description of claim 5, characterized in that the mechanism for load balancing minimizes the amount of reproduction required for the incorporated objects, while not exceeding a capacity of any of the set of servers.

7. The structure with host functions, according to the description of claim 1, characterized in that it also includes a mechanism for overflow control, to minimize a total amount of latency experienced by the customers' machines, while at the same time Do not exceed the capacity of any given subset among the server pool.

8. The structure with host functions, according to the description of claim 7, characterized in that the mechanism for the overflow control includes a multiple goods flow algorithm at minimum cost.

9. The structure with host functions, according to the description of claim 1, characterized in that the first-level name server includes a map of the network to be used in the address or sending of a request of the incorporated object, generated by a client.

10. The structure with host functions, according to the definition of claim 1, characterized in that a server in the server set includes a gate mechanism to maintain the total traffic, for a given embedded object within specified limits.

The structure for performing host functions, in accordance with the description of claim 10, characterized in that the gate mechanism comprises: means for determining whether a given number of requests for incorporated objects exceeds a given threshold; and, means responsive to the means of determination, to restrict the service of the given embodied object.

12. The structure performing host functions, according to the description of claim 11, characterized in that the restriction means comprises means for serving an object that is smaller than the given embodied object.

13. The structure that performs host functions, according to the description of claim 11, characterized in that the object is a ticket that allows a client to receive the incorporated object given at a later time.

14. A method to serve a page supported on a server of a Content Provider, the page comprises a basic document in the markup language, which has a set of built-in objects associated with it, each incorporated object is identified by a URL, the method it comprises the steps of: rewriting the URL of a built-in object, to generate a modified URL, the modified URL includes a new host name placed on hold in an original host name, where the original host name is kept as part of the Modified URL for use in the recovery of the embedded object, whenever a cached copy of the built-in object is not available; in response to a request to serve the page received on the Content Provider site, serve the page with the modified URL; attempting to serve the embedded object, from a different content server to the Content Provider server as identified by the new hostname; and, if the cached copy, the built-in object, is not available in the content server, serve the embedded object from the Content Provider server.

15. A method for serving a page and associated page object, where the page is stored on a Content Provider server and copies of the page object are stored on a set of content servers, other than the Provider server of Content, the method is characterized in that it comprises the steps of: (a) modifying a URL for the object of the page, to include a host name placed on hold in a domain name and path supplied by the Content Provider; (b) serve the page from the Content Provider server, with the modified URL; and (c) in response to a browser query, to resolve the host name, identify a given set among the set of content servers, from which the object can be retrieved, and, (d) return an address to the browser IP of the content server, identified, to allow the browser to attempt to retrieve the object from the content server.

16. The method according to the description of claim 15, characterized in that copies of the object of the page are stored in a subset of the set of content servers.

17. A method for the provision of content, characterized in that it comprises: labeling an object incorporated in a page, for resolving for a domain different from a domain of the Content Provider, placing in waiting the data given in a URL provided by the Provider of Content, to generate an alternative resource locator (ARL); serve the Content Provider server page, with the ARL; and, resolve the ARL to identify a content server in the domain; and, serve the incorporated object, from the content server, identified.

18. The method according to the description of claim 17, characterized in that the step of solving the ARL comprises: using a location of the user making the request and the data that then identify the common conditions of Internet traffic, to identify the content server.

19. A content delivery service, characterized in that it comprises: reproducing a set of page objects through a large area network, content servers, managed by a different domain than the domain of the Content Provider; for a given page normally served from the Content Provider's domain, tag the embedded objects of the page in such a way that the requests for the objects of the page, resolve the domain instead of the domain of the Content Provider; In response to a request for the given page received in the Content Provider's domain, serve the determined page from the Content Provider domain; and, serve, at least one embedded object of the given page, from a given content server, in the domain, rather than from the Content Provider domain.

20. The method for providing content, according to the description of claim 19, characterized in that the stage in which the content is served comprises: for each embedded object to identify one or more content servers from which it can be recovered the built-in obj ect.

The method according to claim 20, characterized in that the identification step comprises: resolving a request to the domain, as a function of a location of the user making the request.

The method according to the description of claim 21, characterized in that the identification step comprises: resolving a request to the domain, as a function of the location of the user making the request, and then the current conditions of Internet traffic .

23. A method for the provision of content in Inter characterized in that it comprises: on the server of the content provider, modify at least one URL of the embedded object, of a page, to include a host name previously located in the domain name and a route normally used to retrieve the embedded object; in response to a request for the page, issued from a client's machine, serve the page with the URL of the modified embedded object to the client's machine from the Content Provider server; in response to a request for the embedded object, resolving the hostname to an IP address of a content server, other than the Content Provider server, which is likely to perform host functions on the embedded object; e, try to serve the built-in object, to the client, from the content server.

24. The method according to the description of claim 23, characterized in that the host name includes a value generated by the application of a given function to the embedded object.

25. The method according to the description of claim 24, characterized in that the value is generated by encoding the given information, the given information is selected from a group of information, consisting essentially of: size data, data of popularity, creation data, and data of the type of object.

The method according to the description of claim 4, characterized in that the given function randomly associates the embedded object with a virtual content storage sector.

27. The method according to the description of claim 26, characterized in that the given function is a coding function.

28. The method according to the description of claim 26, characterized in that the given function is a random check function (hash function).

The method according to the description of claim 23, characterized in that the modified URL also includes a fingerprint value generated by applying a function given to the embedded object.

30. The method according to the description of claim 29, characterized in that the value is a number generated by the key calculation of the embedded object.

31. The method according to the description of claim 23, characterized in that the page is formatted in accordance with a dialing language.

32. The method according to the description of claim 23, characterized in that it also includes the step of rewriting the URL of the embedded object, when the Content Provider modifies the page.

The method according to the description of claim 23, characterized in that the step of resolving the host name includes: identifying a subset of content servers that may be available to serve the embedded object, based on a location of the client's machine, and the ongoing conditions of Intertraffic; e, identify the content server among the subset of content servers.

34. A method for content delivery, characterized in that it comprises: distributing a set of page objects through a ork of content servers, managed by a domain different from the content provider domain, where the content server ork it is organized in a set of regions; for a given page normally served from the Domain of the Content Provider, tag at least some of the embedded objects, of the page, such that the request of those objects resolves in the domain, instead of the domain of the Content Provider; in response to a request from the client, from a built-in object, of the page: to resolve the client's request as a function of a location of the client's machine making the request and the current conditions of Intertraffic, to identify a region Dadaist; and, returning to the client an IP address of a given server among the content servers within the given region that is likely to perform host functions on the embedded object and that is not overloaded.