WO2001014990A1

WO2001014990A1 - Method for content delivery over the internet

Info

Publication number: WO2001014990A1
Application number: PCT/US2000/022964
Authority: WO
Inventors: Jesse Chou; Jonathan Stockley; James Teske; Chung-Kao Hsieh; Emil Chang
Original assignee: Webever, Inc.
Priority date: 1999-08-21
Filing date: 2000-08-21
Publication date: 2001-03-01
Also published as: AU6795100A

Abstract

Methods for allowing digital content (e.g. website) to be distributed and delivered on several servers located at various geographic locations by redirecting user requests from the home server to a server that can provide the best performance to that particular user are presented. A user's request to the home server of a website is processed (100) whereby the user's IP address, along with other information, is used to determine the preferred support server (108, 110, 111, 112). User information may be inserted into one or more cookies, enabling subsequent requests for content from this location which may include information to be used by server agent(s) to minimize redirection computations, to gather necessary statistical information on end users, and to conduct load balancing (110, 111, 112).

Description

TITLE

METHOD FOR CONTENT DELIVERY OVER THE INTERNET

PRIORITY CLAIM

This application claims priority to a first U.S. provisional application filed on August 21. 1999, entitled "Method For Replication, Synchronization, and Rerouting of Data over the Internet", having Application No. 60/150,163 and a second U.S. provisional application filed on June 20, 2000, entitled "Method for Distributing Content Over the Internet", having Application No. (pending).

FIELD OF INVENTION

The present invention generally relates to content distribution and user request redirection over the internet, and, in particular, the distribution of all types of data (including dynamic and static web pages, e- commerce transactions, email messages, banner ads, etc.) over the internet and the redirection/rerouting of a web content request from one server to another server.

BACKGROUND Traditional internet web sites generally are hosted at one location (i.e. at one server or a cluster of servers at one physical location). For example, referring to Fig. 1, the server for ABC website (as illustrated) is on a server located in New York 10. User requests from various localities, e.g. Seattle 12, San Jose 14, L.A. 16, Taipei 18, Boston 20, and New York 22, are all routed to this one server located in New York 10. There are many problems with this situation. In the first case, a single location constitutes a single point of failure. For example, if a catastrophe happens at this physical location, web sites at this locality will go down. With mission critical web sites, such as e-commerce sites, this is not an acceptable situation. In the second case, with a web site hosted at a single geographical point, user requests from relatively distant places will experience very slow response due to the number of hops required from the requesting user's browser to the web site and back. For example, a request for a web page generated by a Taipei user 18 will go through a number of hops from that user's computer to the web site and back, which translates into a significant amount of time. Often, the requesting user will experience a time-out situation where the browser simply informs the user that the requested web page is not available. Both of the above examples illustrate that the traditional model of hosting a web site at one physical location actually is not a very good model. It would be desirable from a fault-tolerance point of view and from a performance point of view (among others) to have a distributed model whereby web contents are distributed around the globe and user requests are captured and routed to the server that can provide the best performance to that particular user.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide a method for a content delivery network.

It is another object of the present invention to provide a content delivery network having intelligent routing of user requests to the server that can provide the best performance to the particular requesting user.

It is still another object of the present invention to provide a method for load balancing in a content delivery network.

Briefly, the present invention provides methods for allowing a website (or any content) to be distributed and delivered on several servers located at various geographic locations and for redirecting user requests from the home server to a server that can provide the best performance to that particular requesting user (the preferred support server). The original home server and all other support servers hosting the distributed content are provided with an agent. A user's request to the home server of a website is processed whereby the user's IP address, along with other information, is used to determine the preferred support server (which also can be the home server itself). The requested web page is then compiled with the universal resource index (URI) of the preferred support server and sent back to the user. Javascripts for generating cookies may also be attached to the compiled web page such that the user's time zone and the URI (among other information) of the preferred support server can be inserted into the cookie where one or more of these cookies may be returned to the support server the next time a web page is requested from this website. In the subsequent requests for content from this website, one or more cookies will be sent along with the request and the information in the cookie can be used by the agent to minimize redirection computations, to gather necessary statistical information on end users; and to conduct load balancing. In this manner, a content distribution and redirection network is established.

An advantage of the present invention is that it provides a method for a content delivery network.

Another advantage of the present invention is that it provides a content delivery network having intelligent routing of user requests to the server that can provide the best performance to the particular requesting user.

Yet another advantage of the present invention is that it provides a method for load balancing in a content delivery network. These and other features and advantages of the present invention will become well understood upon examining the figures and reading the following detailed description of the invention.

IN THE DRAWINGS

Fig. 1 illustrates the traditional method in accessing a website on the internet.

Fig. 2 illustrates a conceptual diagram of the method of the present invention.

Fig. 3 illustrates an embodiment of the present invention for a content distribution network.

Fig. 4 illustrates a system view of the components of the preferred embodiment of the present invention and the interaction among them.

Fig. 5 illustrates a detailed view of the components of the preferred embodiemtn of the present invention and the interaction among them.

Figs. 6A and 6B illustrate the process flow in processing a user request.

Fig. 7 illustrates an alternative embodiment of the present invention whereby several companies can be peered using the present invention.

DETAIL DESCRIPTION OF THE PREFERRED EMBODIMENT

In a presently preferred embodiment of the present invention, referring to Fig. 2, a first server for hosting ABC website is located at a first locality, e.g. New York 30 and a second server for hosting ABC website is located at a second locality, e.g. San Jose 32. The two websites may have the exact same content or may have specific localized content suited for each locality. Each website would have its own IP address. A content delivery agent (CDA) of the present invention is placed at each locality and next to each web server, 34 and 36. Generally speaking, the CDA will perform a number of tasks, including the identification of the geographical location of the user .requesting web content and the routing of the request to the preferred support server that will provide the highest performance to that particular requesting user. As an example considering only geographic distance between users and the servers. Seattle users 12. San Jose users 14, L.A. users 16, and Taipei users 18 will be routed to the San Jose server 36, and Boston users 20 and"New York users 22 will be routed to the New York server 34.

More specifically, referring to Fig. 3, a user at a client computer 40 uses a browser to request a web page from a specified website. The website may have its own database 46 as well (which is supported by the present invention as well in the distribution and synchronization of the database contents). The initial request 42 goes through the internet and arrives at the specified website 44, this site 44 being a site enabled by an CDA of the present invention. The agent-enabled web server makes a number of calculations and database inquiries 47 working in conjunction with a content delivery management (CDM) server 50 and a database server 56 to arrive at a determination as to the best support server to service this user's request. After the initial request, subsequent requests by this user for web content from this website will be served by the second agent-enabled web server 48, 51 and 53. If in any of the subsequent requests, the best support server needs to be determined again (e.g. for load balancing reasons, etc), this CDA 48 can communicate 55 with another CDM server 52 and database server 54 to make that determination. By this method, the user is directed to the server that can provide the highest performance to the user, based on constant re-evaluation of the parameters such as the server load and content, end user location, mobile end users (e.g. using the wireless application protocal (WAP)), load balancing, cost balancing, and specific traffic routing.

In another embodiment of the present invention, once the determination is made as to the support server, a message is sent 49 from the first server 44 to the determined support server 48. The determined support server 48 then provides 51 the requested information to the user 40 (instead of the server 44). Note that all references to the term support server may include the home server (the original web server) as well.

To accomplish these tasks, once the determination is made as to the preferred support server and redirection of the end user request has occurred, information is continually transmitted between the CDAs, CDMs, and the database servers at each location. In this manner, subsequent requests by end users are continually evaluated as to the suitability of the current preferred support server selection. The continuous evaluation of preferred support server selection requires timely communications between server locations and system components (i.e. CDAs, CDMs, database servers). By way of example, referring to Fig. 3, an end user's initial information request from a server 44 is evaluated by CDA for content type and end user information and passed 47 to the CDM/database for determining a preferred support server for redirection. The result of this determination is then communicated 47 back to the CDA for compilation into the server response to the end user. Subsequent requests by the end user are directly directed to the preferred support server. The CDA/CDM/database 44, 50, 56 maintain the ability to communicate any necessary information regarding these transactions to the CDA/CDM/database 48, 52, 54 located at the preferred server site. The information shared between server locations is the basis for supporting e-commerce and dynamic content, load balancing, cost balancing, and system health monitoring.

The CDM servers provide a second level of content distribution and delivery management to monitor and interact with the agents. In the preferred embodiment, the database servers (54, 56) monitor the CDM and CDA servers and the CDM servers perform the load balancing calculations. In another embodiment, each CDM server interfaces with a geographic database server (54, 56), monitors several CDAs, and performs a number of functions depending on the specific configuration. For example, the CDM server or the database server monitors the status of a number of CDAs and reacts when a CDA no longer responses, which can be an indication that particular CDA and the associated web server is down. The CDM server also may interfaces with the geographic database (54, 56) to provide geographic information for identifying the location of the requesting user. Although, Fig. 3 only shows two CDM servers, there may be many more CDM servers for the purpose of providing a distributed network and a fault-tolerant system. The CDM servers also monitor each other. If a CDM server fails, other CDM servers may take over its tasks. The combination of CDM servers, geographic database servers, and CDA can be implemented in a number of different ways.

Referring to Fig. 4, a presently preferred embodiment of the CDM, geographic database, and CDA is presented. Here, the end user at a computer 60 makes an initial request 62 for a page of a particular website 64. The CDA residing at this website processes the request and makes an inquiry to the database 66. In processing the request, the CDA parses the request and determines the IP (internet protocol) address of the requesting user and performs a number of other tasks (which are explained in detail below) for deriving certain information. This information is then provided to the geographic database 66 and the database 66 generates the IP address for the server most optimal for serving the client 60. The CDA replaces all hyperlinks referencing within this particular website to use this IP address. This page is then returned back 68 to the client 60. All subsequent requests 70 by the client 60 for web pages within this particular website is now directed to the determined, optimal web server 72 and this server 72 serves this client 60. Note that a cache can be included with the CDA such that the most frequently lookup IP addresses will be readily available so that no database lookup is necessary.

Information with respect to the client, in particular the time zone, is collected and factored into the database. Each database is updated accordingly every time a client accesses the database. Each database also communicates and updates other databases such that there is not a single point of failure and all of the databases have the same updated information.

Referring to Fig. 5, the components of the presently preferred embodiment are illustrated. The CDM server 80 interfaces with a geographic database server 82. The geographic database server 82 interacts with a number of CDAs, 84, 86, and 88, and other geographic database servers 90. There is also a content delivery administration server (CDAS) 92 for interfacing with one or more content management consoles (CMC), 94 and 96. Note that the CDM 80, the database 82, the CDAS 92, and web server can all reside on one machine or on separate machines. The CMC 94 typically resides on a remote machine for monitoring the CDM. CDA, the database, etc. While. the CDA can also share the same machine with the CDM, it typically resides on a separate machine with the web server. The CDA is placed on the web server or may be integrated as part of the web server. Referring to Fig. 6A, it intercepts all HTTP requests to the web server and parses the header for IP address and for cookie information 100. Then, it passes the HTTP request to the web server and the web server generates a response page (which can be any types of data in any format, not limited to the traditional notion of a "page") 102. The CDA captures the response page and checks for supported content 104 (i.e. markup content with resource links such as HTML files, streaming media meta files, RTSP meta files, etc.). If there is no supported content, there is no redirection to be done and the response page is sent back to the client without modification 106. If there is supported' content, the response page is parsed 108. If a cookie is received with the request 1 10, or if a cookie is received but no support server is specified in the cookie 1 1 1 , a new support server needs to be determined. The support server simply indicates the server that will provide that best performance relative to the client. The steps for determining a new support server is explained in Fig. 6B starting from connect point A and returning to connect point B. After connect point B at 1 12, the response page is compiled using the IP address of the determined support server, meaning that all Universal Resource Indices (URI) referencing this particular website has been changed to the IP address of the support server. In other words, the response page now contains redirected URIs to the support server rather than to the original website. In the next step 1 14, a javascript is inserted into the redirect response page and the response page is returned to the client. The javascript contains code for obtaining user's time zone information (and other information) and the IP address of the determined support server is inserted into the new cookie.

If there is already a support server specified in the cookie 1 1 1 , there is no need to determine a new support server and the response page is compiled using the IP address of the destination server as specified in the cookie 1 12. In the next step 1 14, as explained above, a javascript for obtaining interested information is generated and attached to the response page and the response page is returned to the client.

In determining a new preferred support server (which can be calculated by the database server), referring to Fig. 6B, at connect point A, if-a cookie has been received and the cookie does not already contain a support server but does contains time zone information of the client 120, this time zone information is converted to a longitude coordinate 121. The latitude information .is determined by the general location of the country. With the longitude and latitude information for the client determined, a correlation to one or more support servers can be determined 122 based on distance. Also, geographic information within the geographic database is compared to the cookie time zone information and updated if necessary to provide current, up-to-date geographic database data. If the cookie does not contain time zone information, then information already present in the geographic database is used. In calculating the distance between the support servers to the user's geographic location, because the longitude and latitude information for the support servers and for the requesting user are known, these distances (from the user to each support server) can be calculated using the Great Circle formula (for calculating the distance between any two points on earth). By selecting the top five (arbitrarily speaking) support server candidates and ranking them by distance, a preliminary list of support server candidates is formed.

Additionally, the geographic database is updated with the new longitude and latitude information associated with that particular user IP address if necessary 124. Note that the geographic database contain a complete set of IP addresses including gateways. Associated with each IP address is a set of longitude and latitude information, meaning that for each IP address in existence, the method of the present invention can determine the longitude and latitude information for it and can therefore determine the best server for serving each particular IP address.

Next 128, each of the support servers on the preferred support server list is factored with load balancing information such as peak time information,- special event information, network utilization (e.g. traffic and CPU usage), business logic specified needs, and the status and load of the CDAs and CDMs. Generally speaking, the formula for calculating the ultimate support server is the summation of all factors listed above (and described below), each indicated by a raw number and multiplied by a weight.

In considering peak time information, internet traffic tends to be the greatest during certain hours. It would be beneficial to shift traffic from servers in one time zone to servers in another time zone. For example, traffic may be the greatest during 6 P.M. and 9 P.M. By shifting traffic to another time zone where traffic is light, end user may experience better performance. In the presently preferred embodiment, a timestamp for the cookie is used to allow load balancing between peak and off-peak hours. By properly setting the timestamp for the cookie, traffic can be directed away from certain support servers during peak- hour periods. This type of load balancing is oracular in nature; hence it is predictive load balancing. For example, if a user requests certain information at 5 P.M., a cookie can be set to expire at 6 P.M. so that the server that can provide the best performance will have to be calculated again. Over time, once a pattern is developed, all the support servers for different time periods can be placed in the cookie without further calculation.

For special events, instead of having all user hitting one server at the same time, by monitoring the performance of all the support servers, users can be redirected to support servers with light usage, thereby avoiding overloading any one particular support server or the home server. Time-stamping the cookies can also be used here.

The status of the CDAs and CDMs are provided to the database server through a heartbeat, which is a small packet of information periodically sent by each CDA and CDM server. The packet indicates the load and queue size of the server and any other interested system information. If the heartbeat is not received λvithin a certain interval (e.g. two times the reporting period), there is a high likelihood that the particular CDA or CDM is down and the proper steps_, will be taken (such as informing the operator).

The availability of the content on each of the servers is also considered since it is not necessary to have a complete set of content at each server 130. Content can be distributed, localized and stored customized for each server accordingly. After the calculations, the preferred server at the top of the list becomes the destination server for this particular client at this particular time 132.

In the steps described above and in the preferred embodiment, the CDM server provides the heartbeat to the database server as described above. The CDM server also logs various statistics including bandwidth usage, number of pages served, time served, etc.

The database server performs a number of tasks in addition to responding database inquiries. As stated above, it determines the support server for a given IP address. In the database itself, a set of longitude and latitude coordinates is associated with each IP address and the longitude and latitude coordinates of all support servers. Additionally, it receives a heartbeat from CDMs and CDAs. The heartbeat information is logged in a local table. If a heartbeat is missing from a CDM or CDA, it is also logged in a global table such that other database servers know the status of all the CDMs and CDAs.

Since the IP database is updated continuously, at pre-defined intervals, all of the databases are replicated and synchronized so that all of the databases may contain the same updated information.

In the preferred embodiment, the content delivery administration server (CDAS) and the CDM server can sit on the same machines. CDAS provides the interface to the CMC (content management console) for allowing reporting and configuration of the CDAs and CDMs.

Browser Redirection

The above described methods compiles the response page before the response page is sent back to the client. Another compiling method is to have the user's browser perform the compilation for redirection. Here, the response page is wrapped with javascript code (or equivalent language) to rewrite the links, and the javascript is executed in the browser. In the manner, load is taken off the CDA server and transferred to the user's machine. Another way of implementing this method is install it as a plug-in that intercepts the response page and redirect the links. Here, javascript refers to browser based scripting language such as ECMA Script, etc.

First Alternative Embodiment of the Present Inventiion

Here, an alternative embodiment of the present invention can be in the form of a Geographic Domain Name Service (GeoDNS). A DNS resolves a given domain name (e.g. www.yahoo.com) to an IP address (e.g. 123.123.123.123). Currently, DNS simply resolves names to IP addresses. By coupling with the geographic database of the present invention and the methods described above (including load balancing), redirection can be done at the DNS level rather than at the server level. For example, a user request for a web page is always routed to the DNS first for domain name resolution. When the DNS receives this information, since the user's IP address is known from the request, it can be used to calculate (as described above) the best support server for the particular user IP address. Then, the user request is directly routed to that support server without having to go to any one particular server. Here, only the DNS needs to be modified to carry out such tasks.

Second Alternative Embodiment of the Present Inventiion

The embodiments of the present invention can be applied in a number of ways. In one application, it can be deployed across a network of support servers controlled by one company. In another application, it can be deployed across two or more different networks each owned by a different company - a content peering network. The different networks, technically, will work in the same manner as a single network. However, given the fact that each network may only be at a certain geographical region of world, by using the present invention, each company can now leverage on the support servers of others uniting to become a global network. For example, referring to Fig. 7, the geographical locations of the data centers of companies A, B, and C are shown. Note that companies A and C only have data centers on the east coast of the United States and company B only has data centers on the west coast of the United States. Companies A and B, by adopting the technologies of the present invention, their networks can be extended to encompass the entire United States (illustrated with triangles). This implementation can be extended to across and around the world.

In establishing a content peering network, it is necessary to account for all of the traffic and transactions from users of one company extending to support servers of another company. This may be necessary for billing purposes. Furthermore, it can also be used to decide the least cost path for moving data from one point to another point. For example, by collecting all of the cost information for moving data from one point to another point, the least cost path may be calculated. Granted that it may not be the shortest path or the fastest path, due to cost considerations, the least cost path may be of interest. For example, if data is to be moved from Australia to Japan and the direct path costs $1 per gigabit per second. If data moving from Australia to San Jose, CA costs $0.50 per gigabit per second and data moving from San Jose, CA to Japan costs $0.25 per gigabit per second, it would be more economical to go from Australia to San Jose, CA then to Japan rather than going straight from Australia to Japan. Third Alternative Embodiment of the Present Invention

Logical extension of the geographic database data will including groupings of IP addresses according to common gateway access to the internet. In this manner, the geographic database remains valid for Dynamic Host Configuration Protocol (DHCP). In addition, granularity of the IP address location data in the geographic database is refined based on algorithms comparing data directly obtained from router tables and trace route information.

Fourth Alternative Embodiment of the Present Invention

The geographic database of the present invention, containing ail IP addresses and corresponding longitude and latitude information, can be used in a number of applications. For example, localization of ads for products and/or services can be targeted based on user geographic information. Here, once the user's IP address is obtained, the corresponding longitude and latitude information can be obtained from the database of the present invention and ads can be specifically served according to the user's geographic area. Other applications include the verification of an user identity.

Fifth Alternative Embodiment of the Present Invention

In distributing web content over the internet, the same content may be distributed to one or more servers. By distributing the same content to many servers placed across a wide geographical locations, faster access can be provided to requesting users located in those wide geographical locations. Thus, this is a method to provide faster access without having to increase the size or the number of connections among the servers of the internet.

In providing the same web content across many servers, there are several considerations, including synchronization of the web content among the servers and re-directing a user request to the nearest server. For example, web content for a site may be updated periodically and the updates should be distributed to the other servers hosting the same web content. Additionally, when a user requests data from the web site, this user's request, once received by the web, should be rerouted and served by server that is located nearest to the requesting user in order to provide the fastest response to the requesting user. Furthermore, if the nearest server is experiencing heavy usage, the user request should be re-routed to the next nearest server. This is the idea of load balancing.

The present invention provides the core technology for enabling all of the above-described ideas. In a first step of one embodiment of the present invention, in replicating the web content of a web site to another server, all or partial of the web pages of the web site are copied into a database. In one simple method, the databases at two servers can be easily synchronized using existing technology. Or, a database can be easily replicated to another server using existing methods.

In copying a web page into the database, the content of the web page is parsed. For each intrinsic hyperlink (a link that is directed to a web page within the web site) in the web page, a calculation is made and the intrinsic hyperlink is replaced with a reference to a location within the database which refers to the address of the new location of the web page. For example, if the web page www .■abc.com/index. html contains an intrinsic hyperlink to www.abc.coin/companvinfo.html, in storing www.abc.com/index.html into the database, this intrinsic hyperlink www.abc.com/conipanyinfo.html is replaced with the address of the page www.abc.com/companyinfo.html within the database. Thus, all of the selected web pages of the web site is referenced and contained within the database. By changing all of the intrinsic links to within the database, it provides a major advantage that is explained below. It is important to note a level of intelligence can be added by selecting only certain web pages to store in the database, thereby rerouting only certain pages. In this manner, we can replicate either the entire web site or only part of the web site. For extrinsic hyperlinks, no changes are made to them.

Note that the reference to databases in this write-up shall not be construed as a limiting factor. Lists or other technologies can be used instead of databases.

The above method can handle web pages with static information without any problem. For web pages with dynamic information, an enhanced method is required. For example, a user requests certain information from the web site by entering certain parameters on a requesting page (which is a static page); the entered information is then submitted to the Common Gateway Interface ("CGI") program interfacing between the requesting page and perhaps a database at the backend supplying the requested information. The CGI program will take the entered information and dynamically generate a web page for the requesting user. This page will be intercepted by the agent software and parsed according to the method described above (since there might be intrinsic hyperlinks to other pages within the web site) before it is supplied to the user. In this manner, dynamic information can be retrieved directly from the web site without problem.

While the present invention has been described with reference to certain preferred embodiments, it is to be understood that the present invention is not to be limited to such specific embodiments. Rather, it is the inventor's intention that the invention be understood and construed in its broadest meaning as reflected by the following claims. Thus, these claims are to be understood as incorporating and not only the preferred embodiment described hereip but all those other and further alterations and modifications as would be apparent to those of ordinary skill in the art.

What we claim:

Claims

What we claim:

1. A method for internet content delivery network having two or more support servers at different geographic locations and each associated with longitude and latitude coordinates, comprising the steps of: generating a first user request for web content from a specified website, said user request containing an IP address; receiving said first user request at.said website; parsing said first user request for an IP address; associating said IP address with longitude and latitude coordinates; comparing the longitude and latitude coordinates of said IP address with the longitude and latitude coordinates of said support servers; determining the support server having the shortest geographic location with said IP address: and having said determined support server returning said requested web content.