Patent Application
20090292824
This invention relates generally to information transfer for network-based applications on a computer network. More particularly, the invention is related to application acceleration across a network that does not require accelerators at both endpoints.
The Internet is rapidly becoming a global business network, where partners and clients can easily access mission critical applications from anywhere in the world. In some instances (e.g. outsourcing), application users are increasingly far away from the network application servers and the associated data and content on those servers. Yet application developers often write network applications under the assumption of local area network or LAN access. LAN performance is by definition low latency and easily and economically over-provisioned meaning little packet loss and low jitter. Often, when those applications operate over vast distances as is common on the Internet, network conditions such as high latency, packet loss and jitter dramatically impact the performance of those applications.
For some applications where the content is static and does not change, a Content Delivery Network or CDN can be used to address this problem. The CDN solves the problem by placing a copy of the content at a location that is close to the ultimate user or client. Companies such as Speedera and Akamai have helped certain businesses address the performance problems inherent in the Internet, in those instances where the application data is easily cached, accessed often by many users and most importantly, static.
For dynamic applications where the underlying data is different for different users (e.g. an account balance for an online banking application), the CDN cannot address the performance problems without the onerous process of replicating the entire application and all of its associated data near the users. For certain applications, such as financial applications operating on real-time market data, the replication needs to occur in real-time to accommodate the underlying dynamic data changes. The near instantaneous replication of data to all CDN sites is prohibitively expensive and impractical. Other business applications such as CRM, sales order management, database access or backup also require dynamic interaction and data transfer not suitable to the CDN. For many, the cost and overhead in replicating the application all over the world is prohibitive.
CDN solutions are also not appropriate for some emerging real-time applications, such as voice and video where real-time interaction is required between the application participants. These applications demand strict performance requirements of the network in the form of loss, latency and jitter. As such, most long haul network paths cannot match the requirements and these applications degrade or outright fail.
Recently, new approaches for accelerating applications have appeared on the market. Broadly speaking, these application accelerators overcome the limitations of the network and dramatically increase the performance of applications running over the network. They employ various techniques such as TCP acceleration, session splitting, compression, virtual window expansion, data segment caching, application layer acceleration and route control to overcome long distance, high packet loss, small constrained networks and poorly written applications. Companies such as Peribit, Riverbed, Orbital Data, Expand, Allot, Internap, and Packeteer are developing hardware that employs one or more of the above or similar techniques in the pursuit of increased application performance. While these techniques are helpful, they will not help the application scale when the user base is large or global. Additionally, many applications have a user base that is not known a priori. Consider a business-to-consumer (B2C) application or a business application that is accessed from traveling workers or telecommuters. The one-to-many and the open nature of these applications presents a significant challenge to anyone wishing to deploy stand alone solutions in support of these applications. The prospect of placing this technology at every application user or client is cost prohibitive and not practical for the applications with a large and geographically disbursed user base.
In addition to the above scalability concerns, an application manager would need to lease and operate physical space and systems in remote locations. In addition, the application manager would need to buy and maintain the software and hardware necessary to effectively utilize and load balance many such sites. Currently, application mangers would have to waste economic and other resources on functions that are not relevant to their core business.
In summary, there is need for cost effective acceleration of many applications over large geographical distances when application data is dynamic or is not cost effectively cached by solutions such as CDN. The present invention solves these and other problems associated with the prior art.
The present invention meets the needs described above by providing a system and method for intelligently routing and accelerating applications over a large network of servers in a way that dramatically improves the transport times and enhances user experience of the application. The present invention provides a set of servers operating in a distributed manner. The application traffic is routed through the server network and accelerated along a portion of the network path. In one embodiment, the major components of the network include a set of servers running DNS, a set of servers measuring network and server performance metrics, a set of servers to translate addressing, a set of servers to implement the acceleration techniques and a set of servers for reporting and customer management interfaces. The servers perform the necessary processes and methods of the invention and, as will be apparent to those skilled in the art, these software systems can be embedded on any appropriate collection of hardware or even embedded in other products. These servers are deployed throughout the globe in a series of Service Delivery Points (SDPs). The SDPs collectively make up the Application Service Network Provider (ASNP). The present invention also contemplates that the collection of the individual functions described above can be deployed throughout the network and need not be organized into the SDPs of the disclosed embodiment.
The invention provides a network architecture that allows an application provider to accelerate their applications over long distances and under less than ideal network conditions, as is commonly found in some underdeveloped portions of the world or with satellite networks. The applications are automatically routed over the accelerated network without any effort or overhead on the part of the clients or application provider.
The global framework is fault tolerant at each level of operation. Different SDPs can be engaged and used in the event of any single failure and still achieve good levels of application acceleration. Individual and system level components of the SDPs also fail over to other systems in the same SDP or in a nearby SDP.
It is an object of the present invention to provide a computer network comprising a number of widely deployed servers that form a fault tolerant infrastructure designed to accelerate applications efficiently and reliably to end users. A more general object of the present invention is to provide a fundamentally new and better way to transport Internet applications.
Another object of the present invention is to provide a fault tolerant network for accelerating the transport of Internet applications. The network architecture is used to speed up the delivery of the applications and allows application providers with a large audience to serve the application reliably and with dramatically improved application experience due to greater network throughput.
Yet another objective of the present invention is to provide a network architecture that is able to improve the application experience without the need to replicate content or data near the users. This allows applications with dynamic data or large amounts of data to be accelerated with significantly less cost in server and disk at the various network locations resulting in a more cost effective solution.
Yet another objective of the present invention is to provide a network architecture that improves the performance of applications that are used infrequently and thus, not effectively served by caching solutions. Caching solutions often resort to the origin of the content on a cache miss and this performance is at the base performance of the underlying network.
Yet another objective of the present invention is to provide a network architecture that improves the performance of applications without disrupting the relationship with the end users. The network should allow for the acceleration of applications without additional equipment or software required at the end user or client.
Another objective of the present invention is to provide a network architecture that improves the performance of applications without disrupting the application infrastructure and does not require additional equipment or software at the application server or application server networks. However, in some embodiments of the present invention technology is collocated near the application to enable further improvements in application user experience or lower the cost of the solution.
Yet another object of the present invention is to provide a distributed scalable infrastructure that shifts the burden of application performance from the application provider to a network of application accelerators deployed, for example, on a global basis.
The forgoing has outlined some of the more pertinent objects and features of the present invention. These objects should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description and by reference to the figures and claims.
The present invention provides application acceleration across a widely deployed network. Briefly described, the invention provides an application service network provider (ASNP) located between the client and the application server, which includes a number of service delivery points (SDPs). The SDPs typically provide address translation, acceleration, and performance measurements. In one embodiment two SDPs are used, a client SDP and a server SDP. Traffic is routed from the client to a client SDP, from the client SDP to a server SDP, and from the server SDP to the application server. Accelerators are provided at the client SDP and the server SDP. Each SDP is generic and can serve both client and server SDP functions for different applications. In another embodiment the client includes an accelerator and traffic is routed from the client to a server SDP and from the server SDP to the application server. In this embodiment, the server SDP includes an accelerator matched to the accelerator associated with the client. In an embodiment where the application server includes an accelerator, traffic is routed from the client to a client SDP and from the client SDP to the application server. In this embodiment, the client SDP includes an accelerator matched to the accelerator associated with the application server.
The present invention supports application acceleration in widely deployed networks. In the embodiment illustrated by
The clients 201, 202 access the application server 231 via local network connections 203, 204 to networks or network service providers (NSP) 241, 242, 244. The servers of the ASNP are organized into Service Delivery Points (SDPs) 210, 220, which collectively make up the ASNP. The SDPs are connected to the network via one or more network connections 215, 216, 225 using a layer 3 switch or router 211, 221. The SDPs can be connected to a regional or national network or NSP 241, 242, 243, which are further connected to a larger set of networks to form an Internetwork or Internet 243, although other regional, internal or external networks are also possible.
Each SDP includes a number of servers, including a measurement server 218, 220, a DNS server 222, 212 and a gateway server 223, 213, as well as at least one accelerator 224a, 224b, 214a, 214b. The measurement servers 218, 228 measure the availability and performance metrics of each server in the SDP, as well as the network performance such as loss, latency, jitter to both the application servers and the clients or client LDNS servers. The DNS servers 212, 222 respond to requests from a client LDNS and issue unique IP addresses in a given SDP that are best able to serve the client's request.
Although DNS is used in the preferred embodiment, other mechanisms can also be used so long as traffic is routed into the ASNP. In the alternative embodiments that do not use DNS, DNS servers 212, 222 would be replaced with the systems and software necessary to route traffic into the ASNP. The alternative embodiments could use a web service protocol, such as UDDI. Support for a web services registry inside the ASNP could serve to route web services traffic into the SDP for enhancement. Alternative embodiments may access the ASNP as an integrated function of the application itself. Some applications do not require human readable addresses and thus, do not require DNS to access. An example is the delivery of large media files to a set-top box. In this example, the set-top box is not using DNS to access the content. Instead, access to the content is integrated as a part of the delivery application. Accessing the ASNP for such an application would be integrated as a function of the application itself with selection criteria similar to those described for DNS.
The gateway (G/W) server 213, 223 is responsible for translating the source and destination addresses of a given data stream. This address translation corresponds to the underlying routing of the network to ensure traffic is routed through the ASNP via the configured SDP. The G/W server may be implemented in several ways. The preferred embodiment uses Network Adress Translation (NAT) or Port Address Translation (PAT) to translate addresses at the IP layer only. Alternative embodiments may terminate TCP sessions using a full TCP proxy that can be configured to translate the necessary layer three IP addressing. The address translation is critical to ensure traffic is routed through the correct accelerator. The GIW servers may also perform admission control and other functions necessary to ensure only authorized traffic utilizes the network.
The accelerators 214a, 214b, 224a, 224b perform one or more known techniques to accelerate applications. TCP acceleration is probably the most common and is used to improve the throughput of any TCP session. Since the acceleration techniques must interoperate with existing network stacks in the clients and application servers, the original TCP session must be restored at another accelerator associated with the application server. Acceleration is an end-to-end stateful function and requires that traffic is routed through a compatible pair of accelerators for the duration of the session. Other acceleration techniques that can be used with the present invention are described in the section entitled “Exemplary Acceleration Techniques.” Depending on the nature of the techniques, the accelerators may also perform an additional proxy of application protocols (and address translation) of the underlying data stream.
Additional servers not shown in
The SDPs provide a fault tolerant infrastructure. If one SDP fails, then application acceleration can be maintained by using another SDP. In addition to substituting one SDP for another, the components within an SDP or between SDPs also can be substituted upon a failure.
Alternative embodiments may rely on an “end to end” form of route control, such as that described in U.S. application Ser. No. 11/063,057 entitled “System and Method for End to End Route Control,” which is incorporated herein by reference, within and between the known SDPs to greatly improve the performance of the long haul portion of the delivery network. This may enable the delivery network for other applications, such as real-time applications (e.g. voice and video) not readily improved by the various other application acceleration techniques employed. Therefore, another embodiment of the present invention may rely on route control without specific application accelerators. Certain acceleration techniques, such as session splitting may further be enhanced when operating over multiple distinct network paths as provided by
As will be apparent to those skilled in the art, the described SDPs are not the only way to provide application acceleration according to the present invention. Application acceleration could also be delivered with many of the SDP components implemented as client software to permit the tight coupling of the delivery network with a specific application. For example, ITUNES client software could be a critical component of a delivery network for audio files. As such, the client software could implement many or all of the features associated with the client SDP (e.g. application acceleration) without the downside of client to client SDP network distance, or the difficulties associated with intelligent selection of the client SDP via DNS or other mechanisms.
The accelerators used in the present invention can implement a variety of acceleration techniques. Typically, the choice of a particular acceleration technique is based on the application to be accelerated. Not all techniques can be used, or will be needed for all applications. Each acceleration technique may be embodied in a separate accelerator or multiple techniques may be combined in a single accelerator.
Since the accelerator modifies the data stream in some way, each accelerator accepts packets at a network interface and once the packets are processed sends the packets out a network interface. The same interface may be used for both sending and receiving. Once the packets are input, they are sent to the acceleration engine where one or more acceleration techniques are applied to the application data stream. Some of these acceleration techniques represent an end-to-end process and must communicate with another matching accelerator of the same type before being engaged and altering network traffic. In such instances, accelerators typically synchronize with each other to ensure this process occurs properly. Otherwise, the accelerator passes traffic ‘in the clear’ (i.e. unmodified) and the underlying network performance is seen at the application.
One acceleration technique that can be used with the present invention is TCP acceleration. TCP acceleration is a series of techniques designed to improve the throughput of TCP traffic under network conditions of high latency or high packet loss. TCP throughput has an inverse relationship with the round trip time or network latency. Additionally, various network stacks have a preconfigured maximum window size, which also limits the amount of data that can be in transit without an acknowledgement. When network latencies are larger, these two factors limit the throughput of a TCP session dramatically. The TCP acceleration technique rewrites various fields in the data stream to change the performance characteristics of the end-to-end TCP session. Since the original session is restored at the matching TCP accelerator, the effective throughput more closely matches the throughput of the non-accelerated components of the network path at either end of the SDPs. The effects are greatest when the network performance between the SDPs is at its worst. Other components of TCP acceleration such a pre-selective ACK and forward error correction are designed to reduce the effects of packet loss on the TCP session with some nominal overhead at the data stream.
Another acceleration technique is session splitting whereby large sessions are split into number smaller sessions and transmitted concurrently end to end. This permits the delay bandwidth product to be multiplied by the number of split sessions, increasing overall throughput. In addition, the throughput of each split session can be monitored, to effectively assess the performance qualities of the underlying network path. This is particularly useful when multiple distinct network paths are available. Split sessions can be divided and sent concurrently over the various network paths to be reassembled into a single session at the matching accelerator. In this example, high quality network paths may receive more of the sessions while low quality paths, receive fewer sessions or are avoided.
Another acceleration technique is application layer acceleration. Application layer acceleration represents techniques to overcome limitations of specific application implementations. An example is Common Internet File System (CIFS) acceleration where the application requires significant network communication between client and server for simple interactions. The techniques employed by CIFS acceleration terminate and proxy the connection at each accelerator and spoof the communication of the other endpoint. Thus if a client is communicating to a server through an accelerator, the accelerator associated with the client SDP takes on the role of the server and responds to certain requests per the protocol, while sending along the initial data and awaiting the required response from the application server. Likewise, the accelerator associated with the server SDP is also spoofing certain communication that would result from the client to ensure the communication is occurring per the protocol and as fast as possible. Thus, poorly written applications deployed over the wide area network are able to enjoy significant improvements in performance.
Compression/data referencing techniques are another acceleration technique that can be used with the present invention. Compression/data referencing techniques reduce the amount of data sent across the network and are mostly used for applications running over constrained connections. These techniques can also be used to reduce the effects of TCP acceleration that, by definition, increase the utilization of the network connections in the SDP. Compression finds patterns in the underlying data that can be represented with fewer bits. Another type of compression is data referencing that performs like tasks. Neither technique will work in the presence of encryption, since the encrypted data appears random and no patterns can be found. Data referencing can be used to dramatically improve the throughput of TCP if only the payloads of each packet are compressed. This allows each payload to carry more data and reduces the overall round trips that are required. This is the function of Virtual Window Expansion. Although again, encryption disrupts this process.
The only method to preserve compression/data referencing and Virtual Window Expansion in the presence of encryption is to decrypt the data, process the data per the accelerator and then re-encrypt the resulting data stream. This requires that the SDP and the ASNP be in the trust relationship of the customer, and to share the key material necessary to encrypt and decrypt the data. Although application providers may be unable or unwilling to share this information generally, it may be possible to share it for select applications and data sharing, which would enable these techniques in the presence of encryption. This has the effect of integrating the ASNP as part of a managed Virtual Private Network (VPN) service offering. Integrating security with the acceleration of the ASNP provides tremendous benefits and addresses the challenges of large diverse enterprise environments, such as those presented by remote workers and telecommuters.
Data segment caching can also be used to accelerate application performance. Data segment caching is a form of caching where small elements of the data stream are stored on the disk or in the memory of each accelerator. This is not like full file caching where an entire copy of the file is stored, but instead only small, often repeated data segments are stored. An example might be the master slide pattern of a POWERPOINT file or data outside of the small changes made to an older version of the same file. When certain patterns are seen or requests for data are made by the application, the data can be taken from the disk instead of requested over the network, reducing the time to access the file and lowering the burden on the network.
The selection of an acceleration technique for a data stream can be automatic based on the type of application, which assumes that certain techniques work well with certain types of applications. Alternatively or in addition to a selection based on the type of application, the customer can select the technique(s) to be applied. The customer could make a selection through the management and administration portal. Each technique used could result in an additional cost for the service. The resulting system would be configured for all SDPs in all regions selected to only use the techniques selected.
The application accelerators may be deployed using commercially available systems for point-to-point acceleration, such as the hardware products currently available from Riverbed, Orbital Data, Peribit, Expand, Allot and other suppliers. Or they may be specific software implementing unique acceleration techniques deployed on servers in the SDPs.
As an alternative to using an accelerator associated with a server SDP, some web-based applications may operate with a single accelerator associated with the application server. Typical devices in this family of accelerators offload SSL, cache content files, manage connections, operate with certain browser-based features, such as compression, and apply certain application centric techniques, such as HTTP rewrite and pre-fetching of content. Some convert complicated enterprise applications (e.g. CIFS) into simple protocols, such as HTTP, accessible through a web browser. Many of these techniques are also applicable to a delivery network. In this embodiment, a matching accelerator is not required at a server SDP, although the various functions of the accelerators may be implemented across the client and server SDPs. For example, caching and compression may be implemented at the client SDP while session management and other application specific functions could reside at the server SDP or at (or near) the application server itself. Examples of accelerators suitable for this embodiment include accelerators offered by Redline, NetScaler, and FineGround.
Once the data is accelerated, the accelerated data is delivered to the server SDP using the destination address in step 605 and the accelerated data enters the server SDP in step 606. The accelerated data is sent to the matching accelerator in the server SDP where the same acceleration technique(s) are applied to the data in step 607 to restore the initial data stream. This is called restoration, meaning that the data stream is returned to its natural form. Specifically, the inverse technique(s) applied in the client SDP (acceleration, compression, etc.) are reversed and the original data stream emerges. The data is then forwarded to the GAW server in the server SDP and another address translation is performed in step 608 to identify the application server as the destination address. The data is the forwarded to the application server in step 609. Return data from the application server to the client follows a similar, but reversed method to that illustrated in
The ASNP typically provides a number of SDPs.
The measurement servers in each candidate server SDP also collect network measurements from the SDP towards the client SDP. Various network tests, such as ping, traceroute, UDP tests, TCP tests, download test, application specific tests and the like are employed by the measurement servers. In step 702, the candidate server SDPs report their network performance measurements to the client SDP.
In step 703, the best candidates server SDP in terms of network performance and available resources is selected as the server SDP. The metrics and measurements collected by the measurement servers in the candidate server SDPs and are used to select the candidate server SDP with the lowest network latency and best packet loss with sufficient available resources to handle the customer-configured traffic as the server SDP. The selection of a server SDP includes the identification of the specific addresses that are to be used by the G/W servers. The address translation rules are then configured on the G/W servers in the client SDP and the server SDP, a step not shown on this flowchart.
Typically, the DNS server returned is under the direct control of the application provider 803. In this example, HP DNS server 804 is returned at the IP address 15.227.128.50. To enable the intelligent routing of data through the network, the application provider 803 makes the ASNP authoritative for the specific application domain name. This can be done at the root level for all of the application provider's domains, but is more commonly done at the application provider's DNS with a CNAME or other similar record as shown in 804. In the example illustrated by
The Client LDNS resolves the name (hpl .internap.net) in order to determine the proper DNS server to resolve the application name. If the name is not cached, then the Client LDNS 802 will query the net root nameserver 807 in step 6. The net root nameserver returns a list of configured DNS servers 810, 811 in a set of SDPs authorized to serve this application in step 7. Alternatively, the .net root nameserver returns a single IP address that is an anycast IP address for all DNS servers in all SDPs. For the anycast embodiment, the natural routing of the network would determine which SDP DNS server in which SDP would service the request.
In the embodiment illustrated by
Once the SDP DNS has been selected, the client LDNS 802 requests the IP address from that server in step 9 and the SDP DNS provides the IP address in step 10. When the SDP DNS server receives a request from the client LDNS 802 it converts the application name into an IP address configured on a G/W server in one of the SDPs, preferably the SDP closest to the client 801 or with the best performing network path and available resources. This step is discussed in greater detail in connection with
If the client LDNS is a new entry or the record contains old, possibly outdated information, then the network provider has not measured the performance to this LDNS for some time (if ever). If there are available resources in the local SDP of the DNS server, the DNS server responds to the request with the local GIW server configured for the application provider in step 1004. If local resources are not available, the DNS responds with the closest SDP to itself where resources are available. Once the request has been handled, the network begins measuring performance to the LDNS in the background to better service future requests. The first measurements, which occur constantly, are local performance metrics for all SDP servers as shown in step 1005. These measurements ensure the network is aware of available resources in every SDP. In addition to these measurements, the measurement servers initiate reverse DNS, and other network measurements back to the client LDNS from every configured SDP. These measurements assess the network quality between any given SDP and the Client LDNS as shown in step 1006. Once all of the measurements have been collected, the best SDP for the client LDNS is selected in step 1007 and the record for that client LDNS is configured in the SDP DNS servers associated with the client LDNS for future requests to use in step 1008.
Additional alternative embodiments will be apparent to those skilled in the art to which the present invention pertains without departing from its spirit and scope. Although
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2006/002129 | 1/23/2006 | WO | 00 | 4/20/2009 |
| Number | Date | Country | |
|---|---|---|---|
| 60645906 | Jan 2005 | US |
