Patent Publication Number: US-2023134974-A1

Title: Intelligently routing internet traffic

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 15/930,999, filed May 13, 2020, which claims the benefit of U.S. Provisional Application No. 62/847,307, filed May 13, 2019, both of which are hereby incorporated by reference. 
    
    
     FIELD 
     Embodiments of the invention relate to the field of computing; and more specifically, to intelligently routing internet traffic. 
     BACKGROUND 
     Global internet routing is configured by advertising network prefixes. These prefixes define a group of IP addresses that a network device is willing to route. Many data centers are serviced by multiple network providers. Conventionally a data center or network advertises all its prefixes on all its links, indicating that any connecting network can send data addressed to those IP addresses to that location. Conventional internet routing typically picks one path for traffic between data centers, largely based off common providers. This pathing, while simple and predictable, is not always optimal. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings: 
         FIG.  1    illustrates an exemplary system for intelligently routing internet traffic according to an embodiment. 
         FIG.  2    illustrates exemplary data centers and their transit connections according to an embodiment. 
         FIG.  3    illustrates an exemplary architecture of a compute node according to an embodiment. 
         FIG.  4    illustrates an example architecture for determining and using optimized routes according to an embodiment. 
         FIG.  5    is a flow diagram that illustrates exemplary operations for intelligently routing internet traffic according to an embodiment. 
         FIG.  6    is a block diagram illustrating a data processing system that can be used in an embodiment. 
     
    
    
     DESCRIPTION OF EMBODIMENTS 
     A method and apparatus for intelligently routing internet traffic is described. The internet traffic is routed through multiple compute nodes of a distributed network. The compute nodes are geographically distributed (e.g., in different locations throughout the world). There may be hundreds to thousands of compute nodes of the distributed network. The intelligent routing of traffic includes calculating one or more optimized routes based on a set of factors such as latency, speed, reliability, and/or cost; for each combination of network providers (e.g., Internet Service Providers). The optimized routes may or may not be the same as the route taken by conventional routing protocols such as standard BGP. In an embodiment, the intelligent routing is based on network probe data to calculate the routes to take to the destination. 
     There may be multiple network connections from multiple transit providers that connect a first compute node and a second compute node. The intelligent routing includes selecting a transit provider from multiple transit providers to carry the traffic between one compute node to another compute node. Four variables exist for a single connection between a first compute node and a second compute node: egress from the first compute node, ingress to the second compute node, egress from the second compute node, and ingress to the first compute node. In an embodiment, each of these four variables is tested for each combination of transit providers on both sides of the connection. The resulting data is then used to calculate forwarding tables that provide optimized routes. 
     The optimized routes use encoded IP addresses that encode the transit provider information used by the network connections. These encoded IP addresses are sometimes referred herein as transit selection IP addresses. The transit selection IP addresses define the endpoints (e.g., source and destination compute nodes) and also the transit providers that are to be used to move traffic. The choice of source and destination transit selection IP addresses may be made by programs or applications running on the compute nodes. This allows the programs or applications to select individual routing policies and route decisions on a case-by-case, packet-by-packet, and/or connection-by-connection basis. A particular compute node may be assigned a unique IP address for each of the multiple network connections. Each particular IP address encodes an identifier of the link and an identifier of the machine. 
     The compute node can instruct an edge device (e.g., router, switch) regarding how the traffic is to be handled, e.g., through the transit selection IP addresses. The edge devices are configured to recognize the transit selection IP addresses and perform specific traffic routing behavior depending on the encoding of the transit selection IP addresses. 
       FIG.  1    illustrates an exemplary system for intelligently routing internet traffic according to an embodiment. The system  100  includes the client device  110 , the data centers  120 A-N, and the origin server  130 . The client device  110  is a computing device (e.g., laptop, workstation, smartphone, palm top, mobile phone, tablets, gaming system, set-top box, etc.) that is capable of accessing network resources through a client network application (e.g., a browser, a mobile application, or other network application). 
     Each data center  120  includes one or more compute nodes of a distributed cloud computing network  105 . Each compute node is a computing device that may provide multiple services for customers (e.g., domain owners). The data centers  120 A-N are geographically distributed (e.g., in different locations throughout the world). There may be hundreds to thousands of data centers. The data centers  120 A-N process web traffic (e.g., HTTP/S requests/responses, SPDY requests/responses, or other web traffic), and may provide services including protecting against Internet-based threats (e.g., proactively stopping botnets, cleaning viruses, trojans, and worms, etc.), providing performance services for customers (e.g., acting as a node in a content delivery network (CDN) and dynamically caching customer&#39;s files closer to visitors, page acceleration, content optimization services, etc.), TCP stack optimizations, and/or other services. Each data center may include one or more physical servers (e.g., one or more compute servers, one or more control servers, one or more DNS servers (e.g., one or more authoritative name servers, one or more proxy DNS servers), and one or more other pieces of network equipment such as router(s), switch(es), and/or hubs. 
     Each data center  120  may operate as a reverse proxy and receive requests for network resources (e.g., HTTP/S requests) of a domain of the origin server  130 . The particular data center  120  that receives a request from a client device may be determined by the network infrastructure according to an Anycast implementation or by a geographical load balancer. For instance, compute nodes within the data centers  120 A-N may have a same anycast IP address that points to a domain of the origin server  130 . If the origin server  130  handles the domain “example.com”, a DNS request for “example.com” returns an address record having the anycast IP address of the compute nodes within the data centers  120 A-N. Which of the data centers  120 A-N receives a request from a client device depends on which data center  120  is closest to the client device in terms of routing protocol configuration (e.g., Border Gateway Protocol (BGP) configuration) according to an anycast implementation as determined by the network infrastructure (e.g., router(s), switch(es), and/or other network equipment between the requesting client and the data centers  120 A-N). As illustrated in  FIG.  1   , the client device  110  is closest to the data center  120 A. Accordingly, requests from the client device  110  are received at the data center  120 A. In some embodiments, instead of using an anycast mechanism, a geographical load balancer is used to route traffic to the nearest data center. The number of client devices and compute servers illustrated in  FIG.  1    is exemplary. The distributed cloud computing network may include hundreds to thousands (or more) data centers and each data center may receive requests from thousands or more client devices. 
     Traffic may traverse the internet between data centers  120 A-N. There may be multiple network providers that provide transit connections between the data centers  120 A-N. The different transit connections may have different properties (e.g., different performance characteristics such as latency, speed, and/or reliability; and cost). An optimized route between the entry data center and the exit data center may be determined and used. The entry data center is the data center that initially receives the traffic and the exit data center is the data center that is connected to the origin server. For instance, with respect to  FIG.  1   , the data center  120 A is the entry data center and the data center  120 D is the exit data center. The optimized route may be based on a set of factors such as latency, speed, reliability, and/or cost, for each of the transit connections. The optimized route may not be the same as the route taken by conventional routing protocols such as standard BGP. For instance,  FIG.  1    illustrates the optimized route  155  that goes from the data center  120 A to the data center  120 B to the data center  120 C to the data center  120 D to the origin server  130 . The data centers  120 E- 120 N are not part of the optimized route  155 .  FIG.  1    also illustrates a nonoptimized route  160  going through the hops (internet nodes)  112  to  114  to  116  of a public network  170  (e.g., the general internet) to the origin server  130 . This nonoptimized route does not take network conditions into account but rather is based on a conventional routing protocol such as BGP. The optimized route  155 , when compared to the nonoptimized route  160 , may have lower latency, higher speed, more reliability, and/or lower cost. 
     There may be multiple transit connections between the data centers.  FIG.  2    illustrates an exemplary data center  120 A and data center  120 B and their transit connections according to an embodiment. The data center  120 A includes the compute nodes  220 A-N and the data center  120 B includes the compute nodes  222 A-N. The compute nodes  220 A-N are coupled to the router  225 A and the compute nodes  222 A-N are coupled to the router  225 B. Each of the compute nodes  220 A and  222 A may be physical servers. A first transit connection  260 A and a different second transit connection  260 B connect the data centers  120 A and  120 B. The transit connections  260 A and  260 B may be provided by different network providers and may have different properties (e.g., different performance characteristics such as latency, speed, and/or reliability; and cost). 
     When determining the optimal route, the characteristics of the transit connections may be considered. In an embodiment, each combination of transit connections between the data centers is tested for performance. For each transit connection between a first data center and a second data center, four variables may be tested including: ingress to the first data center, ingress to the second data center, egress from the first data center, and egress from the second data center. The performance of the entry and exist transit connections may not be the same. For instance, as illustrated in  FIG.  2   , the following may be tested and measured for the transit connection  260 A: the ingress  230  into the data center  120 A, the ingress  232  into the data center  120 B, the egress  234  from the data center  120 A, and the egress  236  from the data center  120 B. Likewise, the following may be tested and measured for the transit connection  260 B: the ingress  240  into the data center  120 A, the ingress  242  into the data center  120 B, the egress  244  from the data center  120 A, and the egress  246  from the data center  120 B. 
     The transit connections may be tested using network probes. The network probe data may include probe data for data center-to-data center links and/or probe data for data center-to-origin links. The probe data for data center-to-data center links and the probe data for data center-to-origin links may determine (at a particular time) for each link, the network average round trip time (RTT), the network minimum RTT, the network maximum RTT, the network median RTT, the network standard deviation, jitter metrics on network RTT, packet loss rate, throughput, IP path MTU, AS path (including number of ASes in the path and which specific ASes are in the path), packet reordering, and/or packet duplication for each of the transit connections. The network probe data is used to calculate forwarding tables that provide the optimized routes. 
     A unique IP routing prefix may be assigned to each network link and each prefix may be advertised to only one network link. Each compute node is assigned multiple IP addresses, at least one from each prefix. In an embodiment, the optimized routes use encoded IP address(es) to direct traffic between the compute nodes. These transit selection IP addresses define the endpoints (e.g., source and destination compute nodes) and the transit providers that are to be used to move traffic. Each compute node is configured with at least a first set of transit selection IP addresses for each transit provider. By way of example, a transit selection IP address is an IPv6 address and may take the form of 2001:dB80:DDDI:EMMM::1, where DDD is a value that identifies the data center (a data center identifier), I is a value that identifies the ingress transit provider (0 is reserved for default behavior), E is a value that identifies the egress transit provider (0 is reserved for default behavior), and MMM is a value that identifies that compute node (0 is reserved for equal-cost multi-path (ECMP) groups). The order of the values that encode the information may be different in different embodiments. By way of example, in the example shown in  FIG.  2   , there are two transit providers. Assuming that the data center  120 A is identified by the value  230  (0xa00+0xe6=0xae6), the compute node  220 A is identified by the value  125  (0x7d), and if the default value is included, there will be three ingress indexes and three egress indexes. Accordingly, 9 transit selection IP addresses are assigned for the compute node  220 A as follows: 
     (1) 2001:dB80:ae60:007d::1 (data center  230 , compute node  125 , 0 ingress, 0 egress); 
     (2) 2001:dB80:ae60:107d::1 (data center  230 , compute node  125 , 0 ingress, 1 egress); 
     (3) 2001:dB80:ae60:207d::1 (data center  230 , compute node  125 , 0 ingress, 2 egress); 
     (4) 2001:dB80:ae61:007d::1 (data center  230 , compute node  125 , 1 ingress, 0 egress); 
     (5) 2001:dB80:ae61:107d::1 (data center  230 , compute node  125 , 1 ingress, 1 egress); 
     (6) 2001:dB80:ae61:207d::1 (data center  230 , compute node  125 , 1 ingress, 2 egress); 
     (7) 2001:dB80:ae62:007d::1 (data center  230 , compute node  125 , 2 ingress, 0 egress); 
     (8) 2001:dB80:ae62:107d::1 (data center  230 , compute node  125 , 2 ingress, 1 egress); and 
     (9) 2001:dB80:ae62:207d::1 (data center  230 , compute node  125 , 2 ingress, 2 egress). 
     A second set of transit selection IP addresses may be assigned to each compute node where the identifier for the compute node is set to 0 to form ECMP groups. Thus, these transit selection IP addresses may take the form of 2001:dB80:DDDI:EMMM::1 where MMM is 0. The second set of transit selection IP addresses are not used as source addresses (e.g., due to the difficulty of ensuring return packets are directed to the correct compute node of the ECMP group). However, the second set of transit selection IP addresses may be used as destination addresses. By using two sets of addresses, the only compute node identifier required to setup the connection is the compute node identifier of the compute node that is opening the connection (which is used to bind to a specific local source address). 
     The set(s) of transit selection IP addresses for a compute node are configured on the local loop-back interface of the compute node. The set(s) of transit selection IP addresses for a compute node are advertised to the edge router of the data center. For instance, the compute nodes  220 A-N each advertise their assigned set(s) of transit selection IP addresses to the router  225 A, and the compute nodes  222 A-N each advertise their assigned set(s) of transit selection IP addresses to the router  225 B. 
     The routers of the data centers are configured to accept the advertisements. For instance, the router  225 A is configured to accept the advertisements of the set(s) of transit selection IP addresses of the compute nodes  220 A-N, and the router  225 B is configured to accept the advertisements of the set(s) of transit selection IP addresses of the compute nodes  222 A-N. Each router  225  is also configured to advertise specific ingress BGP prefixes to specific transit providers (and only those transit providers) to force traffic to be received through those specific providers. For instance, the router  225 A is configured to advertise the transit selection IP address prefix for the transit provider identified by the ingress index 1 only to the transit provider identified by the ingress index 1. To advertise specific transit selection IP address prefixes only to specific transit providers, each router  225  is configured to match the transit selection IP address prefix (e.g., the value that identifies the ingress transit provider) to the corresponding transit providers and their physical interfaces on the router  225  and advertise accordingly. For instance, the router  225 A is configured to match the transit selection IP address prefix for the transit provider identified by the ingress index 1 to the physical interface on the router  225 A for that transit provider identified by the ingress index. With respect to  FIG.  2   , if the first transit connection  260 A is provided by a transit provider identified by the ingress index 1, the router  225 A is configured to match the transit selection IP address prefix that encodes the ingress index 1 to the physical interface on the router  225 A for the first transit connection  260 A and advertise the transit selection IP address prefixes that include the ingress index 1 only to the transit provider identified by the ingress index 1. 
     To support egress to a specific transit provider, each router  225  is configured with one or more route filters to direct traffic out of specific physical interfaces. For instance, each router  225  is configured to match the transit selection IP address prefix (e.g., the value that identifies the egress transit provider) to the corresponding transit providers and their physical interfaces on the router  225 . For instance, each router  225  may be configured to recognize that the source IP address of a packet is a transit selection IP address that encodes an egress transit provider, match that encoding to the physical interface configured for that transit provider, and direct the packet out that physical interface. 
     As an example, for a packet from a service running in the compute node  220 A going to a service running in a compute node of the data center  120 B, the source transit selection IP address controls egress transit out of the data center  120 A and the destination transit selection IP address controls ingress transit into the data center  120 B. 
     Because the transit selection IP addresses are specially encoded to instruct the routers how traffic should be handled (and the routers exhibit specific traffic routing behavior depending on the encoding), the transit selection IP addresses do not act like traditional IP addresses. Connections that utilize transit selection IP addresses are subject to pre-determined behaviors by the existing networking infrastructure (e.g., the routers). This effectively overrides the routes of a conventional routing table (e.g., generated by BGP). 
     Although embodiments have described using an IP address to encode how traffic is to be routed, other embodiments encode the routing policy differently. In another embodiment, the Differentiated Services Code Point (DSCP) bits in the header of the IP packet may be used to encode an egress transit connection. In another embodiment, at layer 3, different VLANs between the host (e.g., compute node) and router are used to signal which traffic goes to which egress transit connection. In another embodiment, an identification of the egress transit connection is encoded using a layer 2 source or destination MAC address. Regardless of the embodiment, the sending host (e.g., the compute node) is capable of tagging or otherwise marking the outbound traffic in a way that causes the router to force that traffic to egress on a specific transit connection. 
       FIG.  3    illustrates an exemplary architecture of a compute node according to an embodiment. The compute node  220 A includes a web proxy  315 A, an optimized routing module  320 A, and a cache  325 A. The web proxy  315 A receives requests (e.g., HTTP/S requests), such as from the client device  110 . The web proxy  315 A may determine whether the request can be fulfilled using resources in its cache  325 A instead of, for example, querying the origin server or another compute node for the requested resource. Before determining to transmit the request to another server of the distributed cloud computing network  105  or to the origin server, the compute node  220 A can determine whether the requested resource is available in cache, and if so, return the requested resource without querying the origin server or another server. 
     The optimized routing module  320 A is configured to intelligently route at least certain requests towards their destination. The compute node  220 A stores optimized routes that it can use to intelligently route requests towards their destination. Each optimized route may include one or more hops, one or more next-hops (e.g., which may be tried randomly for load balancing purposes), and/or one or more alternate paths to be tried if the first path fails. Each hop may be an IP address. If the request cannot be answered using its cache, the optimized routing module  320 A accesses the stored optimized routes to determine if an optimized route exists (e.g., based on the destination of the request). The optimized routing module  320 A attempts to connect to the best route as defined by the optimized route and if it cannot connect it tries an alternative route (if one exists). 
     As illustrated in  FIG.  3   , the optimized routing module  320 A of the compute node  220 A communicates with the optimized routing module  320 B of the compute node  220 B. The optimized routing modules may communicate using a layer-4 (e.g., TCP or UDP), mutually-authenticated TLS, point-to-point link. This allows any layer-4 traffic to be communicated between the compute nodes  220 A and  220 B. The compute node  220 A may transmit a request to the compute node  220 B (e.g., a similar request as received by the compute node  220 A). The compute node  220 B may determine whether the request can be fulfilled using resources in its cache  325 B in a similar way as the compute node  220 A. The web proxy  315 B of the compute node  220 B may be configured to connect to the origin if the origin is coupled to the compute node  220 B. 
     In some instances, the compute node  220 A may not intelligently route requests towards their destinations. For instance, the compute node  220 A may determine that there is not sufficient information to intelligently route requests towards a particular destination (e.g., an optimized route does not exist). In such a case, the compute node  220 A may proxy the request directly towards the destination origin (e.g., the origin server  130 ) over a non-optimized route (the default route according to BGP, for instance) through a public network such as the Internet. 
       FIG.  4    illustrates an example architecture for determining and using optimized routes according to an embodiment. The optimized routing is logically split into a control plane  410  and a data plane  415 . The control plane  410  computes a routing table and stores the computed routes. The routing table is modified/re-computed periodically based on new probe data and/or feedback of real-time traffic performance. The data plane  415  executes the computed, optimized routes. Each optimized route may include one or more hops, one or more next-hops (e.g., which may be tried randomly for load balancing purposes), and/or one or more alternative paths to be tried if the first path fails. 
     The control plane  410  may be executed on a server separate from the data centers  120 A-N (e.g., as part of a control server) or be part of each data center  120 . The control plane  410  includes the probe manager  420 . The probe manager  420  manages one or more probes such as a data center-to-data center probe and/or a data center-to-origin probe. The data center-to-data center probe determines, at a particular time, for each data center-to-data center link, the network average RTT, the network minimum RTT, the network maximum RTT, the network median RTT, the network standard deviation, jitter metrics on network RTT, packet loss rate, throughput, IP path MTU, AS path (including number of ASes in the path and which specific ASes are in the path), packet reordering, and/or packet duplication. The data center-to-origin probe determines, at a particular time, for each link, the networkRTT to the origin server, the network minimum RTT to the origin server, the network maximum RTT to the origin server, the network median RTT to the origin server, the network standard deviation to the origin server, jitter metrics on the network to the origin server, packet loss rate to the origin server, throughput to the origin server, IP path MTU to the origin server, AS path to the origin server, packet reordering to the origin server, and/or packet duplication to the origin server. In cases where the control plane  410  is implemented on a control server separate from the servers of the data centers  120 A-N, the control server may transmit a probe request to each data center  120  to probe traffic to another data center or an origin. Each server of a data center  120  may perform a TCP traceroute according to the probe request and transmit the result back to the control server. 
     The route engine  430  uses the results of the probe(s) to compute optimized routes that are stored in the optimized routes  435 . Each optimized route may include one or more hops, one or more next-hops (e.g., which may be tried randomly for load balancing purposes), and/or one or more alternative paths to be tried if the first path fails. In an embodiment, the optimized route may include an optimal primary transit selection path, an optimal non-transit selection path as a first failover path, and a second failover path of direct-to-origin. 
     At least a portion of the optimized routes are communicated to the data plane  415  as optimized routes  440 . The optimized routes  440  are used by the optimized routing module  328 A (for example) when intelligently routing requests toward their origin. The optimized routing module  328 A also includes the L4 point-to-point module  445  that is operative to establish a mutually-authenticated TLS point-to-point link with another edge server in which the request is transited. In an embodiment, HTTP Connect is used in connection between the edge servers. For instance, the L4 point-to-point module may act as an HTTP Connect proxy and execute the HTTP Connect protocol as defined in RFC 2616. 
       FIG.  5    is a flow diagram that illustrates exemplary operations for intelligently routing internet traffic according to an embodiment. The operations of  FIG.  5    are described with reference to the exemplary embodiment of  FIG.  2   . However, the operations of  FIG.  5    can be performed by embodiments other than those discussed with reference to  FIG.  2   , and the embodiments discussed with reference to  FIG.  2    can perform operations different than those discussed with reference to  FIG.  5   . 
     At operation  510 , a compute node  220 A receives data from the client device  110 . The data may be a request such as an HTTP/S request or other Internet request or other Internet data. The following description of  FIG.  5    will be with the example that the data is a request. The compute node  220 A may receive the request because it is in the closest data center to the client device (out of the data centers  120 A-N) in terms of routing protocol configuration (e.g., BGP configuration) according to an anycast implementation. 
     Next, at operation  515 , the compute node  220 A determines the destination of the request. The destination may be specified in the request. The routing of the request may be different depending on the destination of the request. 
     Next, at operation  520 , the compute node  220 A determines that an optimized route for transmitting the request towards an origin server corresponding with the destination of the request is available. Determining that an optimized route is available may include accessing a storage of optimized routes that are computed by a control plane like the control plane  410 . The optimized routes may be based in part on probe data between the data centers  120 A-N for each of multiple transit connections and/or probe data between the data centers  120 A-N and the destination. The optimized routes may be stored according to a pair defined by the receiving data center (e.g., the data center  120 A in this case) and the subnet of the origin server (the subnet of the destination). 
     The optimized route uses one or more encoded IP addresses that specify the transit provider(s) that are to be used to deliver the traffic. For instance, the optimized route has a source IP address that encodes an identification of which of the transit connections are to deliver the request. For instance, the source IP address may encode an identification of the egress transit connection on which the request is to egress the data center  120 A. The source IP address may further encode: an identifier of the source data center (e.g., the data center  120 A), and/or an identification of the ingress transit connection on which a response is to be received at the data center  120 A. The source IP address may also identify the source compute node. The optimized route may have a destination IP address that encodes: an identification of the destination data center (e.g., the data center  120 B), an identification of the ingress transit connection into the destination data center, an identification of the egress transit connection out of the destination data center, and/or an identification of the destination compute node. 
     In an embodiment, prior to performing operation  520 , the compute node  220 A may determine whether the request can be fulfilled with its cache (e.g., whether the requested resource is available in its cache). If it can, then operation  520  may not be performed and the compute node  220 A may respond to the request locally. If it cannot, then operation  520  is performed in an embodiment. 
     Next, at operation  525 , the compute node  220 A transmits the request to a next hop over the identified transit connection as defined by the optimized route. If the next hop is another data center  120 , the compute node  220 A may transmit the request to another compute node in a different data center using a layer-4 point-to-point link that is a mutually authenticated TLS connection. Prior to transmitting the request, the compute node  220 A may add metadata to the request that specifies the destination and the optimized route(s). For instance, a header may be added that specifies the IP address and port of the destination, a header may be added that specifies the request URI, a header may be added that specifies how the request is routed, and optionally a header may be added that specifies that the request is delivered to the origin via a specific compute node. In an embodiment, the optimized route(s) are defined by a one or more path components where each path component has one or more next hop bags, where each next hop bag has one or more next hops, and each next hop is an IP address and port or a literal string of the origin. 
     In an embodiment, the compute nodes do not directly connect to the transit connections. Instead, a router (or other piece of networking equipment) couple the compute nodes with the transit connections. In such an embodiment, the router of the source data center (e.g., the router  225 A) receives the request from the compute node  220 A, and is configured to recognize the transit selection IP addresses and perform specific traffic routing behavior depending on the encoding of the transit selection IP addresses. For instance, if the source IP address is encoded with an identifier of the egress transit connection, the router  225 A is configured to recognize and match that encoding to the corresponding transit connection and its physical interface to direct the traffic onto the identified transit connection. 
     The request may transit through one or more other data centers  120  of the distributed cloud computing network  105  until either the request can be locally fulfilled (e.g., using a locally available cache) or until the request is transmitted to the origin server. After exiting the data center  120 A, the request may travel through one or more other network equipment before being received by the next hop (e.g., the data center  120 B). The next hop, assuming that it is not the origin, receives the request based on the transit connection according to the transit selection IP address. A response to the request may be transmitted along the same path as the request. 
     Next, at operation  530 , the compute node  220 A receives a response to the request. The response is received on the transit connection according to the transit selection IP address. At operation  535  the compute node  220 A processes the response. Processing the response may include adding the response to its cache as appropriate. Next, at operation  540 , the response is transmitted to the client device  110 . 
       FIG.  6    illustrates a block diagram for an exemplary data processing system  600  that may be used in some embodiments. One or more such data processing systems  600  may be used to implement the embodiments and operations described with respect to the compute nodes or other electronic devices. The data processing system  600  is an electronic device that stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media  610  (e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals—such as carrier waves, infrared signals), which is coupled to the processing system  620  (e.g., one or more processors and connected system components such as multiple connected chips). For example, the depicted machine-readable storage media  610  may store program code  630  that, when executed by the processor(s)  620 , causes the data processing system  600  to execute the web proxy  315 A, the optimized routing module  320 A, the cache module  325 A, and/or any of the operations described herein. 
     The data processing system  600  also includes one or more network interfaces  660  (e.g., a wired and/or wireless interfaces) that allows the data processing system  600  to transmit data and receive data from other computing devices, typically across one or more networks (e.g., Local Area Networks (LANs), the Internet, etc.). The data processing system  600  may also include one or more input or output (“I/O”) components  650  such as a mouse, keypad, keyboard, a touch panel or a multi-touch input panel, camera, frame grabber, optical scanner, an audio input/output subsystem (which may include a microphone and/or a speaker), other known I/O devices or a combination of such I/O devices. Additional components, not shown, may also be part of the system  600 , and, in certain embodiments, fewer components than that shown in One or more buses may be used to interconnect the various components shown in  FIG.  6   . 
     The techniques shown in the figures can be implemented using code and data stored and executed on one or more computing devices (e.g., client devices, servers, etc.). Such computing devices store and communicate (internally and/or with other computing devices over a network) code and data using machine-readable media, such as non-transitory machine-readable storage media (e.g., magnetic disks; optical disks; random access memory; read only memory; flash memory devices; phase-change memory) and machine-readable communication media (e.g., electrical, optical, acoustical or other form of propagated signals—such as carrier waves, infrared signals, digital signals, etc.). In addition, such computing devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices, user input/output devices (e.g., a keyboard, a touchscreen, and/or a display), and network connections. The coupling of the set of processors and other components is typically through one or more busses and bridges (also termed as bus controllers). The storage device and signals carrying the network traffic respectively represent one or more machine-readable storage media and machine-readable communication media. Thus, the storage device of a given computing device typically stores code and/or data for execution on the set of one or more processors of that computing device. Of course, one or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware. 
     In the preceding description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation. 
     References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. 
     While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.). 
     While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.