Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20080046596 A1
Publication typeApplication
Application numberUS 11/929,406
Publication dateFeb 21, 2008
Filing dateOct 30, 2007
Priority dateJul 11, 2002
Also published asCA2491740A1, CA2491740C, EP1535177A1, EP1535177A4, US7395355, US8903937, US20040010621, US20130103782, US20150058439, US20150058455, WO2004008334A1
Publication number11929406, 929406, US 2008/0046596 A1, US 2008/046596 A1, US 20080046596 A1, US 20080046596A1, US 2008046596 A1, US 2008046596A1, US-A1-20080046596, US-A1-2008046596, US2008/0046596A1, US2008/046596A1, US20080046596 A1, US20080046596A1, US2008046596 A1, US2008046596A1
InventorsMichael Afergan, Charisma Schlossberg, Duke Hong, Satish Rao
Original AssigneeAfergan Michael M, Charisma Schlossberg, Hong Duke P, Rao Satish B
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Method for caching and delivery of compressed content in a content delivery network
US 20080046596 A1
Abstract
A content delivery network (CDN) edge server is provisioned to provide last mile acceleration of content to requesting end users. The CDN edge server fetches, compresses and caches content obtained from a content provider origin server, and serves that content in compressed form in response to receipt of an end user request for that content. It also provides “on-the-fly” compression of otherwise uncompressed content as such content is retrieved from cache and is delivered in response to receipt of an end user request for such content. A preferred compression routine is gzip, as most end user browsers support the capability to decompress files that are received in this format. The compression functionality preferably is enabled on the edge server using customer-specific metadata tags.
Images(4)
Previous page
Next page
Claims(4)
1-20. (canceled)
21. A content delivery method operative at an edge server to which an client machine has been directed by a CDN request routing mechanism, the edge server having a cache, wherein the edge server is managed by a service provider and shared by a set of participating content provider customers, wherein participating content provider customers identify content to be delivered over the content delivery network and such content has associated therewith at least one content handling requirement that is enforceable at the edge server, comprising:
storing a configuration file associated with each participating content provider customer, the configuration file comprising given metadata, wherein at least one attribute of the given metadata tag is settable on a per participating content provider customer basis, and wherein the given metadata tag has an associated match condition;
upon receipt of a request for given content from the client machine, fetching an uncompressed form of the given content from the cache;
selectively compressing the given content as the given content is delivered to the client machine in response to the request if there is a match on the associated match condition in the given metadata; and
billing the participating content provider customer associated with the given content for delivery of the given content delivered to the client machine, wherein an amount billed to the participating content provider customer is a function of a size of the given content in the uncompressed form irrespective of a number of bytes delivered to the client machine.
22. The content delivery method as described in claim 21 wherein the given content is stored in uncompressed form in the cache as a function of other given metadata.
23-26. (canceled)
Description
  • [0001]
    This application is a division of Ser. No. 10/194,043, filed Jul. 11, 2002.
  • [0002]
    This application contains subject matter protected by copyright.
  • BACKGROUND OF THE INVENTION
  • [0003]
    1. Technical Field
  • [0004]
    The present invention relates generally to techniques for selectively storing content in a compressed form in a content delivery network edge server cache and for serving the content to an end user browser.
  • [0005]
    2. Description of the Related Art
  • [0006]
    A content delivery network (“CDN”) is a collection of content servers and associated control mechanisms that offload work from Web site origin servers by delivering content on their behalf to end users. A well-managed CDN achieves this goal by serving some or all of the contents of a site's Web pages, thereby reducing the customer's costs while enhancing an end user's browsing experience from the site. In operation, the CDN uses a request routing mechanism to locate a CDN content server close to the client to serve each request directed to the CDN, where the notion of “close” is based, in part, on evaluating results of network traffic tests.
  • [0007]
    Data compression techniques are well-known in the art. In HTTP 1.1, a Web server may compress an object, e.g., the HTML comprising a base page, to reduce the download time of the page from the server to a requesting end user browser. Most browsers in use today are capable of receiving compressed content and decompressing such content for display. A recent study showed that over 95% of users have browsers capable of decoding compressed HTMLs. A browser indicates to a Web server that it can receive compressed content in the HTTP request header. The Web server may send compressed content, indicating in the HTTP response header that the object was compressed and should be uncompressed before rendering. Servers should not send compressed HTMLs to browsers that do not include decompression capability in the request header. The benefits of compressing data in a typical HTTP 1.1 client-server session is described in a W3C Note titled Network Performance Effects of HTTP/1.1, CSS1, and PNG, by Neilsen et al., June 1997.
  • [0008]
    While browsers have had the capability to decompress content for years, most servers do not for various reasons, primarily due to issues involving compatibility, processor workload and complexity of content management.
  • [0009]
    While content delivery network service providers (CDNSPs) have developed and implemented techniques for accelerating delivery of content between origin server sites and the CDN edge servers, delivery over the so-called “last mile” (from the ISP at which the edge server is located to the end user) has not been adequately addressed.
  • [0010]
    It would be highly desirable to accelerate the delivery of content between a CDN edge server and the requesting end user browser through selective delivery of compressed content.
  • BRIEF SUMMARY OF THE INVENTION
  • [0011]
    A technical advantage is provided by selectively compressing given content provider content as it is received (from an origin server) for caching at a CDN edge server, and/or selectively delivering given content in a compressed format from the edge server to a requesting end user browser. These techniques provide for effective last mile acceleration of content delivery in a CDN. Preferably, the edge server utilizes a publicly available compression utility such as gzip (GNU zip), although any convenient utility may be used. In one embodiment, the edge server has a first routine running on its forward side, i.e., the side that connects the edge server to one or more content provider origin servers. The first routine receives uncompressed content from a content provider origin server and selectively compresses that content to make more efficient use of the edge server's cache space. A second routine runs on the server's client side, i.e., the side that connects the edge server to requesting end user browsers. The second routine compresses content that has been cached in an uncompressed form so that such content can be delivered by the edge server (in such format) to the requesting end user browser. According to a technical advantage of the invention, preferably the routines are selectively controlled by customer-specific metadata supplied to the edge server.
  • [0012]
    In a preferred embodiment, compression metadata is defined for given compressible file types. A first metadata tag controls the edge server to take uncompressed content from an origin server and to apply the first routine to compress the content, thereby allowing the edge server to make more efficient use of its cache space. When a request for such content is received at the edge server, it is typically served as-is, namely, in the same compressed form in which it was cached. A second metadata tag controls the edge server to simply cache content in its uncompressed form (if cacheable) and, using the second routine, to compress the content when a request for compressed content is received at the edge server. Preferably the first and second routines are gzip. Because the majority of browsers in use today support gzipped content, content associated with the first or second metadata tags is delivered to the end user in a compressed form to provide last mile accelerated delivery.
  • [0013]
    Preferably, compression metadata is applied to compressible file types, e.g., those with a MIME type such as HTML, cascading style sheets, and the like. The benefits of compression for such content are significant. Typically, page sizes are reduced to roughly -th of their original sizes, significantly reducing the transfer time to the end user.
  • [0014]
    The present invention provides an improved CDN edge server that fetches, compresses and caches content obtained from a content provider origin server, and/or compresses content on-the-fly as it is being delivered. These features preferably are enabled using simple metadata as applied to specified files, directories, host names or any other constraints.
  • [0015]
    The foregoing has outlined some of the more pertinent features of the present invention. These features should be construed to be merely illustrative. 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.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0016]
    FIG. 1 is a block diagram of a known content delivery network in which the present invention may be implemented;
  • [0017]
    FIG. 2 illustrates a typical machine configuration for a CDN edge server;
  • [0018]
    FIG. 3 illustrates a CDN edge server that has been modified according to the present invention to include a first compression utility on its forward side, and a second compression utility on its client side, with these utilities being selectively controlled by customer-specific metadata;
  • [0019]
    FIG. 4 is a chart illustrating expected TCP transfer times for various file sizes using normal delivery and compressed delivery assuming a 4:1 compression ratio; and
  • [0020]
    FIG. 5 is a chart illustrating compression gains versus file size for broadband and dial-up users.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
  • [0021]
    By way of background, it is known in the prior art to deliver digital content (e.g., HTTP content, streaming media and applications) using an Internet content delivery network (CDN). A CDN is a network of geographically-distributed content delivery nodes that are arranged for efficient delivery of content on behalf of third party content providers. Typically, a CDN is implemented as a combination of a content delivery infrastructure, a request-routing mechanism, and a distribution infrastructure. The content delivery infrastructure usually comprises a set of “surrogate” origin servers that are located at strategic locations (e.g., Internet network access points, Internet Points of Presence, and the like) for delivering content to requesting end users. The request-routing mechanism allocates servers in the content delivery infrastructure to requesting clients in a way that, for web content delivery, minimizes a given client's response time and, for streaming media delivery, provides for the highest quality. The distribution infrastructure consists of on-demand or push-based mechanisms that move content from the origin server to the surrogates. An effective CDN serves frequently-accessed content from a surrogate that is optimal for a given requesting client. In a typical CDN, a single service provider operates the request-routers, the surrogates, and the content distributors. In addition, that service provider establishes business relationships with content publishers and acts on behalf of their origin server sites to provide a distributed delivery system.
  • [0022]
    As seen in FIG. 1, an Internet content delivery infrastructure usually comprises a set of “surrogate” origin servers 102 that are located at strategic locations (e.g., Internet network access points, and the like) for delivering copies of content to requesting end users 119. A surrogate origin server is defined, for example, in IETF Internet Draft titled “Requirements for Surrogates in the HTTP” dated Aug. 9, 2000, which is incorporated herein by reference. The request-routing mechanism 104 allocates servers 102 in the content delivery infrastructure to requesting clients. The distribution infrastructure consists of on-demand or push-based mechanisms that move content from the origin server to the surrogates. A CDN service provider (CDNSP) may organize sets of surrogate origin servers as a group or so-called “region.” In this type of arrangement, a CDN region 106 typically comprises a set of one or more content servers that share a common back-end network, e.g., a LAN, and that are located at or near an Internet access point. Thus, for example, a typical CDN region may be co-located within an Internet Service Provider (ISP) Point of Presence (PoP) 108. A representative CDN content server is a Pentium-based caching appliance running an operating system (e.g., Linux, Windows NT, Windows 2000) and having suitable RAM and disk storage for CDN applications and content delivery network content (e.g., HTTP content, streaming media and applications). Such content servers are sometimes referred to as “edge” servers as they are located at or near the so-called outer reach or “edge” of the Internet. The CDN typically also includes network agents 109 that monitor the network as well as the server loads. These network agents are typically co-located at third party data centers or other locations. Mapmaker software 107 receives data generated from the network agents and periodically creates maps that dynamically associate IP addresses (e.g., the IP addresses of client-side local name servers) with the CDN regions.
  • [0023]
    Content may be identified for delivery from the CDN using a content migrator or rewrite tool 106 operated, for example, at a participating content provider server. Tool 106 rewrites embedded object URLs to point to the CDNSP domain. A request for such content is resolved through a CDNSP-managed DNS to identify a “best” region, and then to identify an edge server within the region that is not overloaded and that is likely to host the requested content. Instead of using content provider-side migration (e.g., using the tool 106), a participating content provider may simply direct the CDNSP to serve an entire domain (or subdomain) by a DNS directive (e.g., a CNAME). In either case, the CDNSP may provide object-specific metadata to the CDN content servers to determine how the CDN content servers will handle a request for an object being served by the CDN. Metadata, as used herein, refers to a set of control options and parameters for the object (e.g., coherence information, origin server identity information, load balancing information, customer code, other control codes, etc.), and such information may be provided to the CDN content servers via a configuration file, in HTTP headers, or in other ways. The Uniform Resource Locator (URL) of an object that is served from the CDN in this manner does not need to be modified by the content provider. When a request for the object is made, for example, by having an end user navigate to a site and select the URL, a customer's DNS system directs the name query (for whatever domain is in the URL) to the CDNSP DNS request routing mechanism. Once an edge server is identified, the browser passes the object request to the server, which applies the metadata supplied from a configuration file or HTTP response headers to determine how the object will be handled.
  • [0024]
    As also seen in FIG. 1, the CDNSP may operate a metadata transmission system 116 comprising a set of one or more servers to enable metadata to be provided to the CDNSP content servers. The system 116 may comprise at least one control server 118, and one or more staging servers 120 a-n, each of which is typically an HTTP server (e.g., Apache). Metadata is provided to the control server 118 by the CDNSP or the content provider (e.g., using a secure extranet application) and periodically delivered to the staging servers 120 a-n. The staging servers deliver the metadata to the CDN content servers as necessary.
  • [0025]
    FIG. 2 illustrates a typical machine configuration for a CDN content edge server. Typically, the content server 200 is a caching appliance running an operating system kernel 202, a file system cache 204, CDN software 206, TCP connection manager 208, and disk storage 210. CDN software 206 creates and manages a “hot” object cache 212 for popular objects being served by the CDN. It may also provide other CDN-related functions, such as request routing, in-region load balancing, and the like. In operation as an HTTP cache for example, the content server 200 receives end user requests for content, determines whether the requested object is present in the hot object cache or the disk storage, serves the requested object via HTTP (if it is present) or establishes a connection to another content server or an origin server to attempt to retrieve the requested object upon a cache miss. Typically, the edge server operates in a “pull” manner, wherein an object is pulled into the cache initially upon the first request to the cache—which will generate a cache miss since the object is not present.
  • [0026]
    The edge server includes a forward or “server” side, for handling communications between the edge server and the content provider origin servers, and a client side, for handling communications between the end user browsers and the edge server. An illustrative architecture of this type is shown in the paper titled “Intelligent Caching For World-Wide Web Objects,” Wessels, Proceedings of the INET '95 Conference 1995.
  • [0027]
    FIG. 3 illustrates a CDN edge server 300 according to the present invention. This server has been modified to include a first compression utility 302 on its forward side 304, and a second compression utility 306 on its client side 308. Each compression utility is preferably gzip, which is an open source compression routine that provides high performance and that is compatible with most existing end user browsers. Edge server 300 also includes a metadata handling routine 310 for applying customer-specific metadata 312 to control application of the first and second compression routines 302 and 306. According to an illustrative embodiment, a first metadata tag, e.g., gzip-incoming, is applied, selectively, to (uncompressed) content fetched by the edge server from an origin server, and a second metadata tag, e.g., gzip-ghost-to-browser, is applied, selectively, to (uncompressed) content fetched by the edge server from its own in-memory cache 314 or disk cache 316. Generally, the first metadata tag is associated with content that, upon receipt from the origin server, is desired to be stored in a compressed form. Such content, typically, will be delivered to a requesting end user as-is, in the sense that the cached content is merely retrieved and sent to the end user in its already-compressed state. In contrast, the second metadata tag normally is associated with content that, upon receipt from the origin server, has not been stored in a compressed form but where it is desired to take advantage of last mile acceleration between the edge server and the requesting end user. Preferably, when the second tag is set, the content associated therewith is compressed as it being served in response to an end user request, i.e., “on-the-fly.”
  • [0028]
    Both the first and second metadata tags cause the edge server to take uncompressed content and serve it to browsers, either compressed or uncompressed, depending on whether they advertise support for compressed content.
  • [0029]
    Typically, the first metadata tag is used for objects that have cache time-to-live (TTL) greater than zero and that are not associated with edge side include (ESI) processing. ESI is a simple markup language to describe cacheable and non-cacheable Web page components that can be aggregated, assembled and delivered at the network edge. Using ESI tags, developers can identify content fragments for dynamic assembly at the edge server. ESI also specifies a content invalidation protocol for transparent content management across ESI-compliant solutions, such as application servers and content delivery networks. The ability to assemble dynamic pages from individual page fragments means that only non-cacheable or expired fragments need to be fetched from the origin Web site, thereby lowering the need to retrieve complete pages and decreasing the load on the Web site's content generation infrastructure. Further details about ESI can be found at “. . . //www.esi.org.” By applying the gzip-incoming tag to such content, the object is compressed, thereby allowing the edge server to make more efficient use of its cache space. Because the majority of browsers in use today support gzipped content, in most cases the gizpped file is served out to the client as is, without any need for unzipping it first. Preferably, the gzip-incoming tag is not set for content nominated for or otherwise associated with ESI processing. In such case, it is typically more efficient just to cache the content unzipped, use it as required by ESI, and then compress the result before serving.
  • [0030]
    If the content received from the origin server has a given time-to-live (TTL) associated therewith that is small enough as compared to the processing overhead (in terms of CPU cycles) involved in making the compression and storing the compressed object, it may be desirable to avoid storing the object compressed as this will consume resources in the server. This is especially true for the case where the end user is connecting to the edge server over a broadband connection. Thus, according to a feature of the invention, it may be desirable to determine whether given content fetched from the origin server should be stored in the cache in an uncompressed or compressed form by evaluating a function trading off anticipated storage time in the cache versus processing overhead required to perform the compression. This determination may be done selectively, e.g., when the object is fetched upon a cache miss and the requesting end user connects to the edge server over a high speed connection. This determination of whether to compress the object may be done as follows, although any convenient technique may be used: when the object is returned from the origin server, the software receives a response header indicating the object's size and TTL (or other cache control data). Based on the size information, the software determines the amount of processing that will be required to compress and store the object in cache given the CPU processing speed, and by examining file properties, notably file size. A decision may then be made to override a metadata tag (that would otherwise dictate storage of the object in compressed form) if storing the object in compressed form is impractical or otherwise determined to be unnecessary. This operation can be used whether or not metadata tags are used to control the compression routine. In a preferred embodiment, the metadata handling routine is configured to override the gzip-incoming metadata tag in such circumstances.
  • [0031]
    Typically, the second metadata tag is used for objects that are nominated for or are associated with ESI processing or that have no-store response headers. As noted above, the gzip-ghost-to-browser tag causes the edge server to cache content in its uncompressed form (if cacheable) and to compress (via gzip for example) the content every time a request for compressed content is received at the edge server. For cacheable content not being ESI-processed, it is preferably to use gzip-incoming for the reasons set forth above, but for no-store content, gzip-ghost-to-browser must be used to take advantage of compression.
  • [0032]
    Preferably, gzip metadata is applied only to compressible file types, i.e., those with a MIME type of text/html. Other types of content (e.g., images) are often already highly compressed and the benefit gained by gzip typically is not worth the processing cycles to do so. The gzip metadata can be applied to these files in any convenient manner, e.g., using a response-header match, or a match on file extensions known to be of text/html type, e.g., html, htm, asp, cfm, jsp, jhtml, and the like.
  • [0033]
    The application of compression must be based on information about the browser. HTTP 1.1 compliant browsers advertise support for gzipped content by including an “accept encoding: gzip” header in the requests they send. Therefore, if a browser does not advertise this support (either because it does not have it and/or does not wish to advertise it), the system must dynamically detect this (e.g., by looking at the HTTP headers) and serve an uncompressed copy of the content. Similarly, there are some browsers that do not handle gzipped content correctly even though they advertise support for with this header. If the CDN customer desires to exclude certain user-agents from being gzipped to the client, it may be desirable to nest the appropriate gzip metadata tag within a response header match and/or to have a dynamically updated set of rules regarding the support provided by various browsers. These rules may be expressed in metadata or by some other means, such as a browser lookup table, and these rules may be consulted when making decisions regarding storage and/or serving. In addition, although not required, compressed and uncompressed objects may be cached separately in the edge server cache if it is desired to apply last mile acceleration based on user-agent. This can be accomplished by generating a different cache key (which is used to control storage) for the different types of content. In an illustrative example, it is assumed that the origin server is part of the cache key. A compressed object can be stored separately by generating a cache key using an origin-server tag to override a default origin server. The value used can be a bogus host header, in which case the edge server can use a forward DNS name with a value of the real origin server set to ensure that the edge server can get the object on a cache miss.
  • [0034]
    The present invention provides many advantages. With last mile compression between the edge server and the end user, the content provider does not have compress the content before making it available to the CDN. The CDN edge servers fetch original content from the content provider's origin site the same way as in the prior art, compress the content, cache the compressed version, and serve the compressed objects, and these actions are taken in accordance with the metadata for a particular customer. Preferably, the compression metadata is enabled for compressible content such as HTMLs, javascript (.js), and stylesheets (.css), and it is disabled for images, sound and video clips, and the like, where compression does not provide performance enhancements. Compression, using the gzip algorithm for example, can reduce the size of an HTML page by a factor of anywhere from 3 to 6. A reduction by a factor of 4 means that the base page-download time can be reduced by up to 75% or more depending on the size of the object and the various TCP parameters employed. Compression may additionally be applied to javascript and style sheets components of a page. Actual reduction in download time may be slightly less than 75% due to TCP's slow start algorithm. Decompression, which is a much faster process then compression, should not take a significant amount of time.
  • [0035]
    FIG. 4 below shows expected TCP transfer times for various file sizes using normal delivery and compressed delivery assuming a 4:1 compression ratio. TCP transfer time includes connection set-up and request, but does not include request processing time. For broadband (BB) users, the figure shows time reductions over 1 second for 100 kB files. For dial-up users, the time reduction for 100 kB files is over 12 seconds. Clearly, any additional compression and decompression processing times of a few milliseconds is a small price to pay for a 12 second reduction in page download time. For very small files, less than 3 or 4 kB, the savings in download times are not as significant and may not warrant compressed delivery. The bulk of the transfer time for small files is due to connection set-up and TCP slow start.
  • [0036]
    The following describes when a content provider may consider using compressed delivery and when it may not want to do so. Once it is determined when and for what content compression will be used, the content provider and/or the CDNSP provisions the edge servers using metadata.
  • [0037]
    Content with long TTLs can be cached compressed. Typically, CDN edge server turnaround latency with compression is about equal to the latency for normal delivery while drastically reducing the object download time. The larger the object, the greater the impact the object has on total page time. Because of fixed connection set-up and request times, TCP packetization and TCP slow start, gains from compressed delivery are seen if the page sizes (uncompressed) are at least 3 kB for dial-up users and 5 kB for broadband users as shown in FIG. 5. Additionally, larger HTML objects make up a larger portion of the total page time when including embedded objects (images, graphics, and the like). The greater the portion of the total page time that compression can affect, the greater the gain. Compression only impacts the object download time but not the first byte time. The lower the user bandwidth, the longer the object download time is while the first byte time stays relatively unchanged. Situations where the page download time is significantly larger than the first byte time will yield the most improvements with compressed delivery. When pages are assembled using ESI, delivery of the first byte has to wait until all the ESI components are fetched from origin, regardless of whether compression is enabled or not. As there is now no first byte “penalty” for enabling compression, compression will largely only help to reduce total page time.
  • [0038]
    In the following situations, compression can still be enabled, but the gains may not be as great as they might be otherwise. Objects that are no-store always have to be fetched from the origin site. This has two impacts. First, the object must be compressed by the CDNSP every time, rather than cached compressed. Second, the object cannot be delivered until it has been received in its entirety from the origin site. The latter point is significant because chunked transfer encoding normally enables the CDN edge server to begin delivery after a small amount of data is received from origin. Without the ability to do chunked delivery, the first byte time will be longer with compression enabled. If the page has some of the other features conducive to compressed delivery (large HTML, mainly dial-up users, fast origin fetch), however, compression may still be advantageous. While, in most cases, compressed delivery of small files will still be faster than normal delivery, compressed delivery will not appear to be much faster unless the object is at least 4 kB. While, in most cases, compressed delivery to high BW users will still be faster than normal delivery, if the page is no-store (and non-ESI), a lower first byte time with normal delivery and chunking may make the overall page time nearly as fast or faster than with compressed delivery.
  • [0039]
    The following metadata example demonstrates the application of last mile acceleration according to the present invention to requests for the following file types: html, htm, and asp from Microsoft Internet Explorer 5 and 6 browsers on a Microsoft Windows platform. In this example, which is merely illustrative, the metadata is in the form of last mile acceleration (LMA) tags: gzip-incoming and gzip-ghost-to-browser. This metadata is supplied to the edge server via the metadata transport mechanism described above, or by any other convenient method or means. In this example, gzip is applied only to compressible content, including implicit index pages of directories and excluding javascript files. The gzip-incoming routine is used on cached content, and the gzip-ghost-to-browser is used on no-stored content. The gzip-incoming and enable-accept-chunking are not applied to the same content. In addition, gzip is applied only to requests from MSIE 5 and 6 on a Windows platform:
    <?xml version=“1.0”?>
     <configs>
     <akamai-config version=“4.3”>
      <originMap tree=“1”>
      <originServer value=“www.origin.foo.com”>
       <hostHeader>www.foo.com</hostHeader>
      </originServer>
      </originMap>
     <tree name=“1”>
      <md name=“serial”>123</md>
      <md name=“cpcode”>1</md>
      <md name=“max-age”>2h</md>
      <match type=“default-file” recursive=“on”>
      <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“Windows”>
       <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“MSIE 5”>
       <md name=“forward-dns-name”>www.origin.customer.com</md>
       <md name=“origin-server”>gzip.origin.customer.com</md>
       <md name=“gzip-incoming”>on</md>
       </match>
       <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“MSIE 6”>
       <md name=“forward-dns-name”>www.origin.customer.com</md>
       <md name=“origin-server”>gzip.origin.customer.com</md>
       <md name=“gzip-incoming”>on</md>
       </match>
      </match>
      </match>
      <match type=“ext” value=“html htm asp”>
      <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“Windows”>
       <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“MSIE 5”>
       <md name=“origin-server”>gzip.origin.foo.com</md>
       <md name=“forward-dns-name”>www.origin.foo.com</md>
       <md name=“gzip-incoming”>on</md>
       </match>
       <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“MSIE 6”>
       <md name=“origin-server”>gzip.origin.foo.com</md>
       <md name=“forward-dns-name”>www.origin.foo.com</md>
       <md name=“gzip-incoming”>on</md>
       </match>
      </match>
      </match>
      <match type=“filename” value=“LogIn.asp”>
      <md name=“no-store”>on</md>
      <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“Windows”>
       <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“MSIE 5”>
       <md name=“gzip-ghost-to-browser”>on</md>
       </match>
       <match type=“request-header” operation=“name-value-strcasestr” argument1=“user-agent”
    argument2=“MSIE 6”>
       <md name=“gzip-ghost-to-browser”>on</md>
       </match>
      </match>
      </match>
     </tree>
     </akamai-config>
    </configs>
  • [0040]
    While the present invention has been described using the gzip compression utility, this is not a limitation. Any convenient compression utility can be used, provided that the end user browser includes a compatible decompression routine.
  • [0041]
    Moreover, while the gzip-incoming and gzip-ghost-to-browser routines have been described as separate, this is not a limitation. The routines can be integrated into a single routine that is selectively called from either the client or forward side of the server as needed.
  • [0042]
    Although not required, preferably the CDN customer is billed for the last mile acceleration service based on the size of the uncompressed content. Thus, if the CDNSP obtains the content in an uncompressed form from the origin, a managed storage system, or the like) and compresses this content before servicing it to a requesting end user, the CDN edge server logs (and the customer is billed for) the size of the object as if it had been served without compression.
  • [0000]
    Variants
  • [0043]
    While the use of metadata tags to control the compression routine is a preferred embodiment, variations of this approach may be implemented. If there are no metadata tags, by default all content that meets a certain file type (e.g., html, htm, or the like) could be run through the compression engine. More generally, the software may be configured to automatically determine what content should be compressed by looking at file types and/or by some preprocessing to determine the compressability of the content. An example of this would be a case in which the system automatically determines that HTML pages should be compressed by either preprocessing the document and/or using a lookup table of file type extensions but not compress a given JPEG file based on the same steps. In like fashion, selective EXE files may be compressed, as another example. If desired, the software may be configured to automatically modify the operative steps (e.g., by not compressing certain files and/or file types) based on inherent information (e.g., as defined by a lookup table) that is correlated with browser information. An example of this would be a case where the system selectively does not compress certain file types for specific browsers because it knows that those browsers have bugs handling those file types.
  • [0044]
    A given compression routine may be selectively run based on a determination of the bandwidth of the end user's connection and then modifying one of the steps accordingly. Thus, for example, if the connection is high speed, it may be undesirable to compress no-store content due to the processing overhead involved in making compression. Likewise, the system may decide to uncompress an object stored compressed in cache before serving.
  • [0045]
    The decision to store an object in compressed form, or to serve an object in compressed form, as the case may be, can vary on a user request-by-user request basis.
  • [0046]
    The techniques of the present invention may be implemented in other than a content delivery network. An alternative implementation, for example, is to place the above-described functionality in a server located at or adjacent a content provider's site. The server provides caching as does a conventional Web site forward proxy. The CDN service provider or some other entity then runs the machine as a compression service on the content provider's behalf. More generally, the present invention thus includes the provision of a managed compression service wherein the service provider (such as the CDNSP) provides the mechanism (e.g., a standalone box, software, and the like) to a provisioned Web site to enable content to be stored at and/or delivered from the proxy in a compressed format.
  • [0047]
    An alternative implementation is to create a single machine CDN, e.g., by locating the server at a given datacenter at which a Web site of a content provider is hosted. Domains that will be managed by the server are CNAMEd to a CDN-specific domain so that end users get mapped to the server. The compression functionality is then implemented as has been described above.
  • [0048]
    One of ordinary skill in the art will also recognize that the present invention may also be used to facilitate delivery of compressed content between servers across a CDN. As is known, large CDNs typically include intermediate tiers between a given origin server and the edge servers. In such case, it may be desirable to implement the compression functionality in the intermediate tier or elsewhere, in which case the “client” is just one of the edge servers (as opposed to the end user's machine). More generally, the client is any other server in the CDN where the intent is to speed the transfer time of the content across the CDN for better performance or reliability for content that is not located in an edge cache.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5852717 *Nov 20, 1996Dec 22, 1998Shiva CorporationPerformance optimizations for computer networks utilizing HTTP
US5949551 *Apr 25, 1997Sep 7, 1999Eastman Kodak CompanyImage handling method using different image resolutions
US5978841 *Mar 7, 1997Nov 2, 1999Berger; LouisLook ahead caching process for improved information retrieval response time by caching bodies of information before they are requested by the user
US5991809 *Jul 25, 1997Nov 23, 1999Clearway Technologies, LlcWeb serving system that coordinates multiple servers to optimize file transfers
US6003030 *Oct 18, 1996Dec 14, 1999Intervu, Inc.System and method for optimized storage and retrieval of data on a distributed computer network
US6003082 *Apr 22, 1998Dec 14, 1999International Business Machines CorporationSelective internet request caching and execution system
US6029175 *Jun 7, 1996Feb 22, 2000Teknowledge CorporationAutomatic retrieval of changed files by a network software agent
US6108703 *May 19, 1999Aug 22, 2000Massachusetts Institute Of TechnologyGlobal hosting system
US6119143 *May 22, 1997Sep 12, 2000International Business Machines CorporationComputer system and method for load balancing with selective control
US6185598 *Feb 10, 1998Feb 6, 2001Digital Island, Inc.Optimized network resource location
US6397259 *May 29, 1998May 28, 2002Palm, Inc.Method, system and apparatus for packet minimized communications
US6405252 *Aug 23, 2000Jun 11, 2002Speedera Networks, Inc.Integrated point of presence server network
US6460076 *Dec 21, 1998Oct 1, 2002Qwest Communications International, Inc.Pay per record system and method
US6484143 *Aug 18, 2000Nov 19, 2002Speedera Networks, Inc.User device and system for traffic management and content distribution over a world wide area network
US6502125 *Aug 9, 2000Dec 31, 2002Akamai Technologies, Inc.System and method for optimized storage and retrieval of data on a distributed computer network
US6542508 *Dec 16, 1999Apr 1, 2003Watchguard Technologies, Inc.Policy engine using stream classifier and policy binding database to associate data packet with appropriate action processor for processing without involvement of a host processor
US6553413 *Jun 28, 2000Apr 22, 2003Massachusetts Institute Of TechnologyContent delivery network using edge-of-network servers for providing content delivery to a set of participating content providers
US6665706 *Dec 30, 2002Dec 16, 2003Akamai Technologies, Inc.System and method for optimized storage and retrieval of data on a distributed computer network
US6751673 *Jan 3, 2001Jun 15, 2004Akamai Technologies, Inc.Streaming media subscription mechanism for a content delivery network
US6754699 *Jul 19, 2001Jun 22, 2004Speedera Networks, Inc.Content delivery and global traffic management network system
US6820133 *Mar 24, 2000Nov 16, 2004Netli, Inc.System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
US7010578 *Sep 21, 2000Mar 7, 2006Akamai Technologies, Inc.Internet content delivery service with third party cache interface support
US7133905 *Apr 9, 2002Nov 7, 2006Akamai Technologies, Inc.Method and system for tiered distribution in a content delivery network
US7200681 *Jul 30, 2002Apr 3, 2007Akamai Technologies, Inc.Edge side components and application programming environment for building and delivering highly distributed heterogenous component-based web applications
US7240100 *Apr 16, 2001Jul 3, 2007Akamai Technologies, Inc.Content delivery network (CDN) content server request handling mechanism with metadata framework support
US7263528 *Jun 13, 2002Aug 28, 2007Hyperspace Communications, Inc.File transfer system
US20010029544 *Mar 28, 2001Oct 11, 2001Cousins Robert E.System for increasing data packet transfer rate between a plurality of modems and the internet
US20020005946 *Apr 18, 2001Jan 17, 2002Takeo OomoriDefect testing apparatus and defect testing method
US20020009180 *Mar 15, 2001Jan 24, 2002Andreas WeirichFail to pots architecture
US20020013843 *Aug 21, 2001Jan 31, 2002Limor SchweitzerSystem, method and computer program product for constructing a network-based filtering and aggregating platform
US20020015231 *Mar 6, 2001Feb 7, 2002Hideki OgawaOptical system having a diffractive optical element, and optical apparatus
US20020056010 *Mar 19, 2001May 9, 2002Sri InternationalMethod and apparatus for transmitting compressed data transparently over a client-server network
US20020059463 *Jul 10, 2001May 16, 2002Leonid GoldsteinMethod and system for accelerating internet access through data compression
US20020091801 *Jan 7, 2002Jul 11, 2002Lewin Daniel M.Extending an internet content delivery network into an enterprise
US20020107701 *Jun 8, 2001Aug 8, 2002Batty Robert L.Systems and methods for metering content on the internet
US20020138437 *Jan 7, 2002Sep 26, 2002Lewin Daniel M.Extending an internet content delivery network into an enterprise environment by locating ICDN content servers topologically near an enterprise firewall
US20020152305 *Jan 30, 2002Oct 17, 2002Jackson Gregory J.Systems and methods for resource utilization analysis in information management environments
US20020152318 *Mar 4, 2002Oct 17, 2002Menon Satish N.Metadata enabled push-pull model for efficient low-latency video-content distribution over a network
US20030006581 *May 31, 2002Jan 9, 2003Moss Newell RyanStowable-lock, convertible-pintle hitch
US20030065810 *Oct 3, 2001Apr 3, 2003International Business Machines CorporationSelective edge processing of dynamically generated content
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7822869 *Oct 15, 2009Oct 26, 2010Patentvc Ltd.Adaptation of data centers' bandwidth contribution to distributed streaming operations
US7925782Apr 12, 2011Amazon Technologies, Inc.Request routing using network computing components
US7962597Jun 14, 2011Amazon Technologies, Inc.Request routing based on class
US7970820Jun 28, 2011Amazon Technologies, Inc.Locality based content distribution
US7991910 *Nov 17, 2008Aug 2, 2011Amazon Technologies, Inc.Updating routing information based on client location
US8028090 *Nov 17, 2008Sep 27, 2011Amazon Technologies, Inc.Request routing utilizing client location information
US8060561Nov 15, 2011Amazon Technologies, Inc.Locality based content distribution
US8060616Nov 17, 2008Nov 15, 2011Amazon Technologies, Inc.Managing CDN registration by a storage provider
US8065417Nov 17, 2008Nov 22, 2011Amazon Technologies, Inc.Service provider registration by a content broker
US8073940Dec 6, 2011Amazon Technologies, Inc.Managing content delivery network service providers
US8122098Nov 17, 2008Feb 21, 2012Amazon Technologies, Inc.Managing content delivery network service providers by a content broker
US8135820Apr 29, 2011Mar 13, 2012Amazon Technologies, Inc.Request routing based on class
US8156243Mar 31, 2008Apr 10, 2012Amazon Technologies, Inc.Request routing
US8185612 *May 22, 2012Peerapp Ltd.Methods and systems for caching data communications over computer networks
US8234403Jun 21, 2011Jul 31, 2012Amazon Technologies, Inc.Updating routing information based on client location
US8239514Aug 7, 2012Amazon Technologies, Inc.Managing content delivery network service providers
US8239571Mar 7, 2011Aug 7, 2012Amazon Technologies, Inc.Request routing using network computing components
US8266310Sep 11, 2012Microsoft CorporationEnabling peer-to-peer content retrieval in HTTP
US8275874Sep 25, 2012Amazon Technologies, Inc.Locality based content distribution
US8301748Nov 14, 2011Oct 30, 2012Amazon Technologies, Inc.Managing CDN registration by a storage provider
US8301778Oct 30, 2012Amazon Technologies, Inc.Service provider registration by a content broker
US8321568Nov 27, 2012Amazon Technologies, Inc.Content management
US8321588Nov 27, 2012Amazon Technologies, Inc.Request routing utilizing client location information
US8346937Nov 30, 2010Jan 1, 2013Amazon Technologies, Inc.Content management
US8352613Jan 8, 2013Amazon Technologies, Inc.Content management
US8352614Nov 30, 2010Jan 8, 2013Amazon Technologies, Inc.Content management
US8352615Nov 30, 2010Jan 8, 2013Amazon Technologies, Inc.Content management
US8386596Mar 12, 2012Feb 26, 2013Amazon Technologies, Inc.Request routing based on class
US8397073Mar 12, 2013Amazon Technologies, Inc.Managing secure content in a content delivery network
US8402137Mar 19, 2013Amazon Technologies, Inc.Content management
US8412823Mar 27, 2009Apr 2, 2013Amazon Technologies, Inc.Managing tracking information entries in resource cache components
US8423667Jun 21, 2012Apr 16, 2013Amazon Technologies, Inc.Updating routing information based on client location
US8438263May 7, 2013Amazon Technologies, Inc.Locality based content distribution
US8447831May 21, 2013Amazon Technologies, Inc.Incentive driven content delivery
US8452874Nov 22, 2010May 28, 2013Amazon Technologies, Inc.Request routing processing
US8458250Aug 6, 2012Jun 4, 2013Amazon Technologies, Inc.Request routing using network computing components
US8458360Jun 4, 2013Amazon Technologies, Inc.Request routing utilizing client location information
US8463846 *Jun 11, 2013Cdnetworks Co., Ltd.File bundling for cache servers of content delivery networks
US8463877Sep 15, 2012Jun 11, 2013Amazon Technologies, Inc.Dynamically translating resource identifiers for request routing using popularitiy information
US8468247Jun 18, 2013Amazon Technologies, Inc.Point of presence management in request routing
US8495220Sep 15, 2012Jul 23, 2013Amazon Technologies, Inc.Managing CDN registration by a storage provider
US8510448Sep 13, 2012Aug 13, 2013Amazon Technologies, Inc.Service provider registration by a content broker
US8521851Mar 27, 2009Aug 27, 2013Amazon Technologies, Inc.DNS query processing using resource identifiers specifying an application broker
US8521880Nov 17, 2008Aug 27, 2013Amazon Technologies, Inc.Managing content delivery network service providers
US8521885Sep 15, 2012Aug 27, 2013Amazon Technologies, Inc.Dynamically translating resource identifiers for request routing using popularity information
US8533293 *Mar 31, 2008Sep 10, 2013Amazon Technologies, Inc.Client side cache management
US8543702Sep 15, 2012Sep 24, 2013Amazon Technologies, Inc.Managing resources using resource expiration data
US8570962 *Jun 22, 2010Oct 29, 2013Blackberry LimitedInformation selection in a wireless communication system
US8577992Sep 28, 2010Nov 5, 2013Amazon Technologies, Inc.Request routing management based on network components
US8583776Aug 6, 2012Nov 12, 2013Amazon Technologies, Inc.Managing content delivery network service providers
US8583813Aug 15, 2012Nov 12, 2013Microsoft CorporationEnabling peer-to-peer content retrieval in HTTP
US8601090 *Mar 31, 2008Dec 3, 2013Amazon Technologies, Inc.Network resource identification
US8606996Mar 31, 2008Dec 10, 2013Amazon Technologies, Inc.Cache optimization
US8626950Dec 3, 2010Jan 7, 2014Amazon Technologies, Inc.Request routing processing
US8639817Dec 19, 2012Jan 28, 2014Amazon Technologies, Inc.Content management
US8676918Sep 15, 2012Mar 18, 2014Amazon Technologies, Inc.Point of presence management in request routing
US8688837Mar 27, 2009Apr 1, 2014Amazon Technologies, Inc.Dynamically translating resource identifiers for request routing using popularity information
US8713156Feb 13, 2013Apr 29, 2014Amazon Technologies, Inc.Request routing based on class
US8732309Nov 17, 2008May 20, 2014Amazon Technologies, Inc.Request routing utilizing cost information
US8756325Mar 11, 2013Jun 17, 2014Amazon Technologies, Inc.Content management
US8756341Mar 27, 2009Jun 17, 2014Amazon Technologies, Inc.Request routing utilizing popularity information
US8782236Jun 16, 2009Jul 15, 2014Amazon Technologies, Inc.Managing resources using resource expiration data
US8788671Jan 25, 2012Jul 22, 2014Amazon Technologies, Inc.Managing content delivery network service providers by a content broker
US8819259 *Oct 14, 2009Aug 26, 2014Aster Risk Management LlcFast retrieval and progressive retransmission of content
US8819260 *Oct 15, 2009Aug 26, 2014Aster Risk Management LlcRandom server selection for retrieving fragments under changing network conditions
US8819261 *Oct 15, 2009Aug 26, 2014Aster Risk Management LlcLoad-balancing an asymmetrical distributed erasure-coded system
US8819283Sep 28, 2010Aug 26, 2014Amazon Technologies, Inc.Request routing in a networked environment
US8825894 *Oct 14, 2009Sep 2, 2014Aster Risk Management LlcReceiving streaming content from servers located around the globe
US8832292 *Oct 15, 2009Sep 9, 2014Aster Risk Management LlcSource-selection based internet backbone traffic shaping
US8832295 *Nov 10, 2010Sep 9, 2014Aster Risk Management LlcPeer-assisted fractional-storage streaming servers
US8874774Oct 15, 2009Oct 28, 2014Aster Risk Management LlcFault tolerance in a distributed streaming system
US8874775Oct 15, 2009Oct 28, 2014Aster Risk Management LlcBalancing a distributed system by replacing overloaded servers
US8903937Dec 5, 2012Dec 2, 2014Akamai Technologies, Inc.Apparatus and method for caching of compressed content in a content delivery network
US8914502Aug 31, 2012Dec 16, 2014Oracle International CorporationSystem and method for dynamic discovery of origin servers in a traffic director environment
US8914521Aug 31, 2012Dec 16, 2014Oracle International CorporationSystem and method for providing active-passive routing in a traffic director environment
US8924528Sep 28, 2010Dec 30, 2014Amazon Technologies, Inc.Latency measurement in resource requests
US8930513Sep 28, 2010Jan 6, 2015Amazon Technologies, Inc.Latency measurement in resource requests
US8930544Oct 29, 2013Jan 6, 2015Amazon Technologies, Inc.Network resource identification
US8938526Sep 28, 2010Jan 20, 2015Amazon Technologies, Inc.Request routing management based on network components
US8938549 *Oct 15, 2009Jan 20, 2015Aster Risk Management LlcReduction of peak-to-average traffic ratio in distributed streaming systems
US8949449 *Oct 15, 2009Feb 3, 2015Aster Risk Management LlcMethods and systems for controlling fragment load on shared links
US8990354May 21, 2012Mar 24, 2015Peerapp Ltd.Methods and systems for caching data communications over computer networks
US8996664Aug 26, 2013Mar 31, 2015Amazon Technologies, Inc.Translation of resource identifiers using popularity information upon client request
US9003035Sep 28, 2010Apr 7, 2015Amazon Technologies, Inc.Point of presence management in request routing
US9003040Apr 29, 2013Apr 7, 2015Amazon Technologies, Inc.Request routing processing
US9009286May 6, 2013Apr 14, 2015Amazon Technologies, Inc.Locality based content distribution
US9021127Mar 14, 2013Apr 28, 2015Amazon Technologies, Inc.Updating routing information based on client location
US9021128May 17, 2013Apr 28, 2015Amazon Technologies, Inc.Request routing using network computing components
US9021129Jun 3, 2013Apr 28, 2015Amazon Technologies, Inc.Request routing utilizing client location information
US9026616May 17, 2013May 5, 2015Amazon Technologies, Inc.Content delivery reconciliation
US9069617Aug 31, 2012Jun 30, 2015Oracle International CorporationSystem and method for intelligent GUI navigation and property sheets in a traffic director environment
US9077666 *Oct 29, 2013Jul 7, 2015International Business Machines CorporationService segregation according to subscriber service association
US9083675Jun 4, 2013Jul 14, 2015Amazon Technologies, Inc.Translation of resource identifiers using popularity information upon client request
US9083743Jun 20, 2012Jul 14, 2015Amazon Technologies, Inc.Managing request routing information utilizing performance information
US9106701Nov 4, 2013Aug 11, 2015Amazon Technologies, Inc.Request routing management based on network components
US9128764Aug 31, 2012Sep 8, 2015Oracle International CorporationSystem and method for providing flexibility in configuring HTTP load balancing in a traffic director environment
US9130756 *Mar 11, 2013Sep 8, 2015Amazon Technologies, Inc.Managing secure content in a content delivery network
US9135048Sep 20, 2012Sep 15, 2015Amazon Technologies, Inc.Automated profiling of resource usage
US9154551Jun 11, 2012Oct 6, 2015Amazon Technologies, Inc.Processing DNS queries to identify pre-processing information
US9155001Aug 30, 2013Oct 6, 2015Blackberry LimitedInformation selection in a wireless communication system
US9160703Dec 10, 2014Oct 13, 2015Amazon Technologies, Inc.Request routing management based on network components
US9172674Jun 20, 2012Oct 27, 2015Amazon Technologies, Inc.Managing request routing information utilizing performance information
US9176894Jul 14, 2014Nov 3, 2015Amazon Technologies, Inc.Managing resources using resource expiration data
US9185012Nov 21, 2014Nov 10, 2015Amazon Technologies, Inc.Latency measurement in resource requests
US9191338Aug 25, 2014Nov 17, 2015Amazon Technologies, Inc.Request routing in a networked environment
US9191458Jun 5, 2014Nov 17, 2015Amazon Technologies, Inc.Request routing using a popularity identifier at a DNS nameserver
US9208097Nov 12, 2013Dec 8, 2015Amazon Technologies, Inc.Cache optimization
US9210235 *Aug 28, 2013Dec 8, 2015Amazon Technologies, Inc.Client side cache management
US9237114Mar 14, 2013Jan 12, 2016Amazon Technologies, Inc.Managing resources in resource cache components
US9246776Mar 10, 2015Jan 26, 2016Amazon Technologies, Inc.Forward-based resource delivery network management techniques
US9251112Aug 26, 2013Feb 2, 2016Amazon Technologies, Inc.Managing content delivery network service providers
US9253065Nov 21, 2014Feb 2, 2016Amazon Technologies, Inc.Latency measurement in resource requests
US9288153Jun 13, 2014Mar 15, 2016Amazon Technologies, Inc.Processing encoded content
US9294391Jun 4, 2013Mar 22, 2016Amazon Technologies, Inc.Managing network computing components utilizing request routing
US9311155Sep 26, 2012Apr 12, 2016Oracle International CorporationSystem and method for auto-tab completion of context sensitive remote managed objects in a traffic director environment
US9323577Sep 20, 2012Apr 26, 2016Amazon Technologies, Inc.Automated profiling of resource usage
US20090248858 *Aug 8, 2008Oct 1, 2009Swaminathan SivasubramanianContent management
US20090248893 *Mar 31, 2008Oct 1, 2009Richardson David RRequest routing
US20090327517 *Dec 31, 2009Swaminathan SivasubramanianRequest routing using network computing components
US20100094950 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Methods and systems for controlling fragment load on shared links
US20100094962 *Oct 14, 2009Apr 15, 2010Patentvc Ltd.Internet backbone servers with edge compensation
US20100094966 *Oct 14, 2009Apr 15, 2010Patentvc Ltd.Receiving Streaming Content from Servers Located Around the Globe
US20100094969 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Reduction of Peak-to-Average Traffic Ratio in Distributed Streaming Systems
US20100094970 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Latency based selection of fractional-storage servers
US20100094971 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Termination of fragment delivery services from data centers participating in distributed streaming operations
US20100094972 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Hybrid distributed streaming system comprising high-bandwidth servers and peer-to-peer devices
US20100094973 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Random server selection for retrieving fragments under changing network conditions
US20100094974 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Load-balancing an asymmetrical distributed erasure-coded system
US20100094975 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Adaptation of data centers' bandwidth contribution to distributed streaming operations
US20100094986 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Source-selection based Internet backbone traffic shaping
US20100095004 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Balancing a distributed system by replacing overloaded servers
US20100095012 *Oct 14, 2009Apr 15, 2010Patentvc Ltd.Fast retrieval and progressive retransmission of content
US20100095013 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Fault Tolerance in a Distributed Streaming System
US20100095015 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Methods and systems for bandwidth amplification using replicated fragments
US20100095016 *Oct 15, 2009Apr 15, 2010Patentvc Ltd.Methods and systems capable of switching from pull mode to push mode
US20100125673 *Nov 17, 2008May 20, 2010Richardson David RRequest routing utilizing client location information
US20100125675 *Nov 17, 2008May 20, 2010Richardson David RUpdating routing information based on client location
US20110055420 *Nov 10, 2010Mar 3, 2011Patentvc Ltd.Peer-assisted fractional-storage streaming servers
US20110072110 *Mar 24, 2011Swaminathan SivasubramanianContent management
US20110072134 *Mar 24, 2011Swaminathan SivasubramanianContent management
US20110072140 *Mar 24, 2011Swaminathan SivasubramanianContent management
US20110078240 *Nov 30, 2010Mar 31, 2011Swaminathan SivasubramanianContent management
US20110276623 *Nov 10, 2011Cdnetworks Co., Ltd.File bundling for cache servers of content delivery networks
US20110310812 *Jun 22, 2010Dec 22, 2011William Anthony GageInformation selection in a wireless communication system
US20120117201 *May 10, 2012Peerapp Ltd.Methods and systems for caching data communications over computer networks
US20130080566 *Mar 28, 2013Oracle International CorporationSystem and method for dynamic cache data decompression in a traffic director environment
US20130191645 *Mar 11, 2013Jul 25, 2013Amazon Technologies, Inc.Managing secure content in a content delivery network
US20130346539 *Aug 28, 2013Dec 26, 2013Amazon Technologies, Inc.Client side cache management
US20140059223 *Oct 29, 2013Feb 27, 2014International Business Machines CorporationService segregation according to subscriber service association
US20150081842 *Nov 19, 2014Mar 19, 2015Amazon Technologies, Inc.Network resource identification
EP2583189A2 *Jun 20, 2011Apr 24, 2013Akamai Technologies, Inc.Extending a content delivery network (cdn) into a mobile or wireline network
WO2009124011A2Mar 31, 2009Oct 8, 2009Amazon Technologies, Inc.Content management
WO2009124011A3 *Mar 31, 2009Dec 30, 2009Amazon Technologies, Inc.Content management
Classifications
U.S. Classification709/247, 707/E17.001, 707/E17.12
International ClassificationG06F17/30, H04L12/66, G06F15/16, H04L29/06, H04L29/08
Cooperative ClassificationH04L67/02, H04L67/2842, G06F15/167, H04L45/20, H04L12/66, H04L69/04, G06F17/30902
European ClassificationG06F17/30W9C, H04L12/66, H04L29/06C5, H04L29/08N27S