Patent Abstract:
An exemplary method performed by a proxy server located between a content server and a client browser for reducing effects of network latency therebetween comprises intercepting a request from the client browser for a resource at the content server, obtaining a response by the content server to the request, determining that the response would, if unmodified, require a plurality of communications between the content server and the client browser in the absence of the proxy server, modifying the response to reduce a network latency associated with the plurality of communications for accessing information located externally to the response, and transmitting the modified response to the client browser for use thereby.

Full Description:
REFERENCE TO RELATED APPLICATION 
     This application claims priority to provisional patent application filed on Dec. 17, 2003, bearing application Ser. No. 60/531,018, which is hereby incorporated by reference in its entirety for all purposes. 
    
    
     FIELD 
     This patent relates generally to accessing content over a network. More specifically, this patent relates to minimizing the impact of network latency on the response time to a client&#39;s request for a resource from a remote content server. 
     BACKGROUND 
     Browser-based applications are deployed and managed centrally, and therefore are inexpensive in comparison to client/server applications. Specifically, in contrast to client/server applications, browser-based applications can be accessed ubiquitously from any web-browser, and therefore do not require the maintenance of specialized software on each user&#39;s desktop. On the downside, browser applications suffer from performance issues in that responding to client actions may take several network roundtrips to the server. In contrast, client/server applications carry significant computing intelligence on the client, thereby providing significantly better performance. 
     Round trips (i.e., multiple communications) on the network can take anywhere from a fraction of a millisecond to more than a second, depending on the type of network and the geographic distance between the client and the server. For example, on a campus Local Area Network (LAN), the latency is typically 0.1 ms. As a second example, the latency on a high-speed land line between New York and Tokyo is ˜400 ms. As a third example, the latency between any two terrestrial points on a satellite link is about 1.5 seconds. In light of this, the performance of browser-based applications depends substantially on the number of network roundtrips required to respond to a typical client action. A response that requires 16 round trips would take well over 7 seconds when the client is in Tokyo and the server is in New York. It is therefore desirable to minimize the number of network roundtrips involved in each response of the application to client action. 
     In general, application developers tend to focus on providing the best functionality in the application, but pay little attention to performance issues. A market therefore exists for technology to optimize the performance of applications a posteriori by examining the request/response interactions between the client and the server. The situation is similar to that of application development, where application developers write software with a view to richness of functionality, leaving it to compilers and optimizing processors to deliver performance afterwards. 
     With regard to the impact of network latency on application performance, application developers often construct files (e.g., web pages) that, when displayed, involve multiple objects (e.g., frames). For example, a customer service application at an insurance company may includes files that, when accessed, display web pages having several frames such as an “account information” frame, a “contact information” frame, a “policy claims” frame etc. This organization of the frames is convenient to the application developer because the application modules for different frames can be separately developed then the modules can be reused in multiple pages in any combination. For example, the “account info” frame may occur in every page or just in some of the company&#39;s pages. This allows the application developer to rapidly develop complex applications in a modular fashion. 
     On the downside, requiring the browser to download many independent objects (e.g., frames) to complete a response to a client request can have severe negative impact on performance. In general, each object is requested by the browser independently; therefore, a web page including multiple objects will require several network roundtrips. This causes the impact of network latency to become manifold thereby leading to poor performance. 
     Other techniques used by application developers can also impact network performance. For example, application developers often implement so-called server-based redirects. A developer may construct an application to comprise several functional modules. When a client requests a URL, a content server may process the URL at a nominal control module which then redirects the client to another module for handling the request. Redirection of client requests can have severe performance impact because each client request must travel the network twice—once to the server&#39;s control module and back, and a second time to another (redirected) server module and back. 
     Network latency can have varying impact on the performance of web and other network applications involving the fetching of an object that in turn requires the fetching of other objects that are external to the originally fetched object. When the latency between the client and the server is small, network latency has limited impact on performance. When the latency is large (e.g., of the order of a second), as is the case when the client and the server are separated by a significant geographic distance, network latency can degrade application performance significantly. 
     Thus, a market exists for techniques to minimize the impact of network latency on application performance a posteriori to application development. Optimization can be carried out dynamically as a client interacts with an application so that changes to the application (e.g., on the server or client computers) are not required (but may be optional depending on design choice). 
     SUMMARY 
     An exemplary method performed by a proxy server located between a content server and a client browser for reducing effects of network latency therebetween comprises intercepting a request from the client browser for a resource at the content server, obtaining a response by the content server to the request, determining that the response would, if unmodified, require a plurality of communications between the content server and the client browser in the absence of the proxy server, modifying the response to reduce a network latency associated with the plurality of communications for accessing information located externally to the response, and transmitting the modified response to the client browser for use thereby. 
     Other embodiments and implementations are also described below. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         FIG. 1  illustrates an exemplary network environment. 
         FIG. 2  illustrates an exemplary process for reducing network latency caused by server redirects. 
         FIG. 3  illustrates an exemplary process for reducing network latency when processing requested resources containing embedded objects. 
         FIG. 4  illustrates another exemplary process for reducing network latency when processing requested resources containing embedded objects. 
     
    
    
     DETAILED DESCRIPTION 
     I. Overview 
     Exemplary techniques for reducing network latency are disclosed herein. 
     Section II describes an exemplary network environment. 
     Section III describes an exemplary process for reducing network latency caused by a server redirect. 
     Section IV describes exemplary processes for reducing network latency when a content server&#39;s response is a resource including multiple embedded objects. 
     Section V describes other aspects and considerations. 
     II. An Exemplary Network Environment 
       FIG. 1  illustrates an exemplary environment including a client browser  100  connected over a Wide Area Network (WAN)  110  to, and accessing content from, a content server  300 . In an exemplary embodiment, the proposed system is deployed as a transparent proxy server  200  located on the network immediately in front of the content server  300 , and connected on a high-speed low latency Local Area Network (LAN)  120  to the content server  300 . 
     When a user using the client browser  100  requests a URL, the proxy server  200  intercepts the request, and forwards the request to the content server  300 . The content server  300  then responds to the proxy server  200 . The proxy server  200  examines and modifies the response in accordance with various embodiments to be described herein then forwards the modified response to the client browser  100 . 
     Those skilled in the art will realize that the proxy server  200  can be implemented in any combination of software and/or hardware, depending on the technical and financial requirements of the particular implementation. For example, a software implementation could be run on a general purpose computer having a processor, one or more memories or other computer-readable media, and appropriate I/O interfaces for connections to the content server  300  and the client browser  100 , via the LAN  120  or the WAN  100 , respectively. Or, a hardware implementation could be deployed using ASICs, PALs, PLAs, or still other forms of hardware now known or hereafter developed. 
     Further, the computer-readable media can store data and logic instructions (which, when executed, implement the processes described herein) that are accessible by the computer or the processing logic within the hardware. Such media might include, without limitation, hard disks, flash memory, random access memories (RAMs), read only memories (ROMs), and the like. 
     III. An Exemplary Process for Reducing Network Latency Caused by Server Redirects 
       FIG. 2  illustrates an exemplary process for reducing network latency caused by server redirects. Server redirects are instances where a content server&#39;s response to a client request is a redirect to another Universal Resource Locator (URL) identifying a unique resource. In general, each URL uniquely identifies a resource. A resource can be any type of data, including, without limitation, a frame, a text file, an image file, a voice file, any other types of data, and/or a combination thereof. For ease of explanation, the terms resource and object may be used interchangeably throughout this patent. 
     The exemplary process begins at block  10 . 
     At block  15 , the proxy server  200  obtains a client request for URL 1 . The client request is sent by the client browser  100  via the WAN  110  and destined for the content server  300 . In an exemplary implementation, the proxy server  200  intercepts the client request. The request interception can be transparent to the client browser  100 . 
     At block  20 , the proxy server  200  forwards the request to the content server  300  via the LAN  120 . 
     At block  25 , the proxy server  200  receives the content server&#39;s  300  response to the request. In an exemplary implementation, the proxy server  200  examines the response after receiving it. 
     At block  30 , the proxy server  200  determines whether the response is a redirect to another URL (e.g., URL 2 ). 
     If so, at block  35 , the proxy server  200  requests the redirect URL (e.g., URL 2 ) from a content server. The content server may or may not be the same content server as the one for URL 1  (i.e., content server  300 ). The process returns to block  25 , where the proxy server  200  receives a response to the redirect URL from a content server. If the new response is not yet another redirect to yet another URL (e.g., URL 3 ), then the process continues to block  40  where the new response is forwarded to the client browser  100 . 
     In this exemplary embodiment, the proxy server  200  intercepts a redirect response from the content server  300  and requests the resource identified by the redirect URL via the high-speed low latency LAN  120 . Therefore, network latency between the client browser  100  and the content server  300  is reduced by eliminating one roundtrip between them over the higher latency WAN  110  to request the resource identified by the redirect URL. 
     IV. Exemplary Processes for Reducing Network Latency when a Requested Resource Includes Multiple Embedded Objects 
     Network latency can also occur when a response (e.g., a resource) from the content server  300  to a client request (e.g., made via the client browser  100 ) includes multiple embedded objects.  FIGS. 3 and 4  illustrate two exemplary processes for reducing network latency by modifying the response from the content server  300 . 
     A. Reducing Network Latency by Obtaining and Appending the Embedded Objects to the Response 
       FIG. 3  illustrates an exemplary process performed by the proxy server  200  that includes the same blocks  10 - 35  of  FIG. 2 . 
     After determining that a response from the content server  300  is not a redirect to another URL, at block  45 , the proxy server  200  determines whether the response includes any embedded objects. For ease of explanation only, this response will be referred to as the original response. 
     If so, at block  50 , the proxy server  200  requests the embedded objects from the content server  300  via the LAN  120  and appends the objects to the original response to form a modified response. In an exemplary implementation, the embedded objects are separated from the parent resource by a header. In addition, each object is also separated from another object by a header. In an exemplary implementation, a header may identify the resource location of each object appended immediately following the header. 
     The modified response can be represented in any desired format, subject to the ability of the client browser  100  to recognize such format. For example, a well-known format that could be used is the so-called Multipurpose Internet Mail Extension HTML (a.k.a. MIME HTML, MHTHL or MHT). The MIME HTML format, developed by a committee of the standards setting body known as the Internet Engineering Task Force, is well known to those skilled in the art, and need not be described in greater detail herein. For example, see the specification for this format at www.ietf.org/rfc/rfc2110.txt and www.ietf.org/rfc/rfc2557.txt. Current versions of some popular browsers, including Microsoft&#39;s Internet Explorer, are configured to recognize (and some can even write) files in this format. 
     At block  55 , the proxy server  200  forwards the modified response to the client browser  100  via the WAN  110 . The client browser  100  can render the parent resource as well as the embedded objects by opening the modified response in accordance with the requirements of the implemented format, without having to incur additional roundtrips to request and obtain the objects embedded in the parent resource. 
     Referring back to block  45 , if the original response from the content server  300  does not include any embedded objects, then at block  55 , the proxy server  200  forwards the original response to the client browser  100  via the WAN  110 . 
     In this exemplary embodiment, the proxy server  200  intercepts an original response from the content server  300  and directly requests the content server  300  for any objects embedded in the original response via the high-speed low latency LAN  120 . Therefore, network latency between the client browser  100  and the content server  300  is reduced by eliminating additional roundtrips between them over the higher latency WAN  110  for retrieving any embedded objects. 
     B. Reducing Network Latency by Creating Additional Unique Pseudonyms 
     Client browsers  100  are typically hard-coded by the manufacturers to automatically open two parallel TCP/IP connections per uniquely named content server. Without proxy server  200  intervention, a resource having multiple embedded objects will be retrieved directly by the client browser  100  via the two connections opened for the content server  300  of the resource. In this example, a first connection will be used to retrieve the parent resource, and a second connection will be used to retrieve any embedded objects one-by-one until either the first connection becomes free or when all embedded objects have been retrieved. In the first scenario, the first connection can be used in parallel with the second connection to retrieve any remaining embedded objects. If more connections could be opened, then network latency can be correspondingly reduced.  FIG. 4  illustrates an exemplary process performed by the proxy server  200  to enable the client browser  100  to open additional connections. 
       FIG. 4  includes the same blocks  10 - 35  of  FIG. 2 . 
     After the proxy server  200  determines that a response from the content server  300  is not a redirect to another URL, at block  60 , the proxy server  200  determines whether the response includes any embedded objects. For ease of explanation only, this response will be referred to as the original response. 
     If the original response includes embedded objects, at block  65 , the proxy server  200  creates additional unique pseudonyms of the content server  300  and modifies the addresses of the embedded objects in the original response to include the unique pseudonyms (to form a modified response). The impact of this process performed by the proxy server  200  can best be illustrated by example. 
     Consider a parent resource identified by the URL www.bank.com. The parent resource includes multiple embedded objects identifiable by the following URLs: 
     
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;img src = “http://www.bank.com/button1.jpg”&gt; 
               
               
                   
                 &lt;img src = “ http://www.bank.com/button2.jpg”&gt; 
               
               
                   
                 &lt;img src = “ http://www.bank.com/clock.jpg”&gt; 
               
               
                   
                 &lt;img src =” http://www.bank.com/footer.gif “ &gt; 
               
               
                   
                   
               
             
          
         
       
     
     In the absence of the proxy server  200 , when the client browser  100  receives the parent resource, it will attempt to fetch the embedded objects (e.g., image files) using the two connections opened for the content server www.bank.com. Assuming both connections are free (i.e., one of the connections has already finished retrieving the parent resource), the client browser  100  will fetch the first two objects “button1.jpg” and “button2.jpg” followed by the next two, “clock.jpg” and “footer.gif.” 
     By creating additional unique pseudonyms for the content server  300 , the proxy server  200  can enable the client browser  100  to open more connections (e.g., 4 connections) to be used to retrieve the embedded objects in parallel. For example, the proxy server  200  creates two unique pseudonyms: server1.bank.com and server2.bank.com for the content server www.bank.com, and modifies the addresses of the embedded objects in the parent resource to reference the pseudonyms. Thus, the embedded objects can now be identified by: 
     
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;img src = “http://www.server1.bank.com/button1.jpg”&gt; 
               
               
                   
                 &lt;img src = “http://www.server1.bank.com/button1.jpg”&gt; 
               
               
                   
                 &lt;img src = “http://www.server2.bank.com/clock.jpg”&gt; 
               
               
                   
                 &lt;img src = “http://www.server2.bank.com/footer.gif”&gt; 
               
               
                   
                   
               
             
          
         
       
     
     In this example, when the client browser  100  receives the modified response (see block  75 ), it will open two connections for each of the pseudonym servers, i.e., a total of four connections to the content server, and can retrieve all four embedded objects in parallel. 
     In order for pseudonyms created by the proxy server  200  for a content server to resolve to the content server, at block  70 , the proxy server  200  adds additional entries into a Domain Name Server, one for each pseudonym created by the proxy server  200  so the pseudonym(s) will resolve to the same IP address as the content server (e.g., www.bank.com). In an exemplary implementation, the proxy server  200  may add a single DNS entry having a wildcard character symbol (e.g., an asterisk) preceding (or after) the content server name instead of adding a separate entry per unique pseudonym. In the above example, an entry of the form “*.bank.com” can be added to refer to the content server name of “.bank.com” with any string of wild card characters preceding the name. Alternatively, such DNS entry (i.e., having a wildcard character symbol) can refer to the proxy server  200  which will resolve any address to an appropriate content server. 
     At block  75 , the modified response is forwarded to the client browser  100  to enable it to open additional connections (i.e., more than 2) to access the content server  300 . 
     Referring back to block  60 , if the original response does not include any embedded objects, then at block  75 , the original response is forwarded to the client browser  100  unmodified. 
     One skilled in the art will recognize that, depending on design choice, the number of unique pseudonyms to be created by the proxy server  200  may be a default number or a dynamically determined number (e.g., based on the size of the parent resource, the number of embedded objects, and/or any other factors). 
     In an exemplary implementation, when a parent resource identifies embedded objects by relative URLs (e.g., of the form “./button.jpg”), the proxy server  200  fills in the complete root path to convert the relative URL to an absolute URL, then introduces a created pseudonym to the absolute URL. To illustrate using the above example, if the parent resource makes a reference to an embedded object by a relative URL “button.jpg,” the proxy server  200  will fill in the complete root path to convert the relative URL to an absolute URL www.bank.com/button.jpg, and then introduce a pseudonym of the content server to modify the absolute URL to a modified URL www.server1.bank.com/button.jpg. 
     In other exemplary implementations, the proxy server  200  is configured to introduce the same pseudonym for each object if the object is referenced multiple times (e.g., within the same parent resource). This feature can prevent retrieval of the same object multiple times. In one implementation, the absolute URL (or the content) of an object can be hashed to the space of a pseudonym. 
     In this exemplary embodiment, the proxy server  200  intercepts an original response from the content server  300 , creates additional unique pseudonyms of the content server  300 , modifies the addresses of embedded objects in the response, and sends the modified response to the client browser  100 . The modified response enables the client browser  100  to open additional connections to the content server  300  to thereby retrieve the embedded objects faster. Therefore, network latency between the client browser  100  and the content server  300  is reduced. 
     V. Other Aspects and Considerations 
     A. Latency Testing 
     The process of intercepting a file (e.g., a request from the client browser  100  or a response from the content server  300 ) at the proxy server  200 , appending external objects or otherwise form a modified file (e.g., a modified response), and transmitting that modified file to a client will involve some overhead and therefore, will introduce some latency of its own. Additional latency might be introduced by the overhead associated with reading a modified file (e.g., a MIME HTML file) at the client browser  100  computer. In most cases, the additional latency will be more than offset by the reduction in latency associated with the savings in eliminated round trips (or by opening additional server connections). However, this is not always the case. For example, the overhead may exceed the savings when requesting content from a content server  300  that is very close to the client browser  100 , or when the network is very lightly loaded. As one optional aspect, it may therefore be useful to perform latency testing and condition the operation of the modification (of the original response) on the outcome of such testing. In other situations, the overall effect of differential network speeds between the content-server-to-proxy legs and the proxy-to-client legs might also render the modification operation moot. 
     B. Client Application Testing 
     As mentioned above, some response modifications may require the client browser  100  to be able to read a modified response. If a modified response is sent to a client browser that cannot read it, not only will no savings result, but the original response may have to be retransmitted in any case. Thus, in another exemplary embodiment, the proxy server  200  might be configured to interrogate the client browser  100  (e.g., by sending a test message or otherwise) to determine whether the client computer can read a certain file format. If not, the proxy server  200  can either skip the modification, or transmit a supplementary application (via a plug-in, patch, applet, etc.) to invest the client computer with the missing functionality. 
     C. Caching 
     Still another optional aspect utilizes caching at the proxy server  200  to further reduce latency. For example, if a commonly requested resource can be found in the proxy server&#39;s cache, then one trip back to the content server  300  can be eliminated. 
     In an optional embodiment, the proxy server  200  could even be equipped with “precomputing” technology to predict that a particular resource will be needed in the future, and to compute that resource ahead of time. This is particularly useful for dynamic content. An exemplary such precomputing technology has been developed by FineGround Networks, Inc. and is described in pending U.S. patent application Ser. No. 10/459,365 filed on Jun. 11, 2003, which application is hereby incorporated by reference in its entirety for all purposes. 
     VI. Conclusion 
     As a matter of convenience, the techniques of this patent have been disclosed in the exemplary context of a web-based system in which the user accesses content identified by URLs from a client browser. However, those skilled in the art will readily appreciate that other user access devices, and content identifiers, may also be used. Similarly, it should be appreciated that the proposed techniques will operate on any networked computer, including without limitation, wireless networks, handheld devices, and personal computers. Therefore, exemplary terms such as resource, web, browser, URL and the like should be interpreted broadly to include known substitutes and other equivalents, counterparts, and extensions thereof. Indeed, it should be understood that the technologies disclosed herein are more generally applicable to obtaining virtually any form of resource over a network. Accordingly, the specific exemplary embodiments and aspects disclosed herein are not to be construed as limiting in scope. 
     Therefore, the inventions should not be limited to the particular embodiments discussed above, but rather are defined by the claims. Furthermore, some of the claims may include alphanumeric identifiers to distinguish the elements thereof. Such identifiers are merely provided for convenience in reading, and should not necessarily be construed as requiring or implying a particular order of elements, or a particular sequential relationship among the claim elements.

Technology Classification (CPC): 7