CA2288488A1 - Method and apparatus for transparently directing requests for web objects to proxy caches - Google Patents
Method and apparatus for transparently directing requests for web objects to proxy caches Download PDFInfo
- Publication number
- CA2288488A1 CA2288488A1 CA002288488A CA2288488A CA2288488A1 CA 2288488 A1 CA2288488 A1 CA 2288488A1 CA 002288488 A CA002288488 A CA 002288488A CA 2288488 A CA2288488 A CA 2288488A CA 2288488 A1 CA2288488 A1 CA 2288488A1
- Authority
- CA
- Canada
- Prior art keywords
- request message
- proxy
- address
- packet
- origin server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1017—Server selection for load balancing based on a round robin mechanism
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1019—Random or heuristic server selection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1027—Persistence of sessions during load balancing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/166—IP fragmentation; TCP segmentation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Abstract
In order to transparently redirect an HTTP connection request that is directed to an origin server (107) to a proxy cache (110-1), a proxy redirector (104) translates the destination address of packets directed to the origin server to the address of the proxy. During a handshaking procedure, a TCP connection is transparently established between the client (110-1) and the proxy cache. When the client transmits a GET request to what it thinks is the origin server, which request specifies the complete address of an object at that origin server that it wants a copy of, the proxy redirector modifies the complete address specified in that GET request before it is sent to the proxy cache. Specifically, the IP address of the origin server found in the destination field in the IP header of the one or more packets from the client containing the GET request is added by the proxy redirector as a prefix to the complete URL in the GET request to form an absolute URL. The proxy cache determines from that absolute URL whether it has the requested object stored in its cache. If it does, it sends the object back to the proxy redirector, which masquerades those packets as coming from the origin server by translating their destination address to the address of the client and their source address to that of the origin server. If the proxy does not have the requested object, a separate TCP connection is established between the proxy and the origin server from where the object is retrieved and then forwarded over the TCP connection between the client and the proxy. In order to account for the additional number of bytes in the GET request, an acknowledgement sequence number in packets returned from the proxy that logically follow receipt of the GET request are decremented by that number by the proxy redirector before being forwarded to the client. Similarly, a sequence number in packets transmitted by the client subsequent to the GET request are incremented by that number before being forwarded by the proxy redirector to the proxy cache.
Description
Cohen-Rangarajan-Singh 2-5-2 METHOD AND APPARATUS FOR TRANSPARENTLY DIRECTING
REQUESTS FOR WEB OBJECTS TO PROXY CACHES
Field of the Invention s This invention relates to packet-switched computer networks, and more particularly, to a method and apparatus in such a network for transparently intercepting client web requests and redirecting them to proxy caches.
io Background of the Invention Proxy caching is currently used to decrease both the latency of object retrieval and traffic on the Internet backbone. As is well known, if a proxy cache has stored a copy of an object from an origin server that has been requested by a client, the requested object is supplied to the client from the is proxy cache rather than from the origin server. This, therefore, obviates the need to send the request over a wide area network, such as the Internet, to the origin server where the original object is stored and the responsive transmission of a copy of the requested object back over the network to the requesting client.
2o Direction of a request from a client to a proxy cache to determine whether a requested copy of an object is stored in the cache can be accomplished either transparently or non-transparently to the client. Non-transparent redirection is accomplished through the client's browser program which is configured to send all object requests to a designated 2s proxy cache at a specified address. Generally, a browser can be configured to send all of its client requests to a designated proxy cache if the client is Cohen-Rangarajan-Singh 2-5-2 connected on a Local Area Network (LAN), or on an Intranet behind a firewall, where a proxy cache associated with that LAN or Intranet is located. When clients are served by a large Internet Service Provider (ISP), however, it is not advantageous from the ISP's standpoint to allow its s subscribers to set their browsers to a specific proxy cache associated with the ISP. A large ISP likely will have many proxy caches in several locations and will thus want to maintain control over which of its several particular proxy caches a client request is directed. Further, if a proxy cache whose address is statically set in a client's browser becomes inoperative, all client io requests will fail.
It is therefore more desirable from an ISP's standpoint with respect to latency and minimizing traffic onto and off of the network to transparently intercept a client's web request and send it to one of its operative proxy caches to determine whether a copy of the requested object is stored there.
is If a copy of the requested object is then found to be stored in that proxy cache, a copy of the object is sent to the client, which is unaware that it has been served an object from the proxy cache rather than from the origin server to which it made the request. If the proxy cache does not hold a copy of the requested object, then a separate connection is established 2o between the proxy cache and the origin server to obtain a copy of the object, which when returned to the proxy is sent to the client over the connection established between the client and the proxy.
When a client specifies a URL of the object it is requesting a copy of, a Domain Name Server (DNS) look-up is performed to determine from the 2s URL an IP address of an origin server which has that requested object. As a result of that look-up, an IP address is returned to the client of one of what may be several substantially equivalent servers that contain that object.
Cohen-Rangarajan-Singh 2-5-2 The client then establishes a TCP connection to that server using a three-way handshake mechanism. Such a connection is determined at each end by a port number and an IP address. First, a SYN packet is sent from the client to that origin server, wherein the destination IP address specified in s the packet is the DNS-determined IP address of the origin server and the destination port number for an HTTP request is conventionally port 80. The source IP address and port number of the packet are the IP address and port number associated with the client. The client IP address is generally assigned to the client by an ISP and the client port number is dynamically io assigned by the protocol stack in the client. The origin server then responds back to the client with an ACK SYN packet in which the destination IP
address and destination port are the client's IP address and port number and the packet's source IP address and port number are the server's IP
address and the server's port number, the latter generally being port 80.
is After receipt of the ACK SYN packet, the client sends one or more packets to the origin server, which packets include a GET request. The GET
request includes a complete URL, which identifies to that server the specific object within the origin server site that the client wants a copy of. Unlike an absolute URL, which includes both site information (e.g., www.yahoo.com), 2o and object information (e.g., index.html), a complete URL only identifies the particular object (e.g., index.html) that is requested since the packets) containing the GET request is sent to the proper origin server site by means of the destination address of the packet(s).
When a browser is configured to non-transparently send all requests as to a proxy, a GET request is formulated by the browser that includes the absolute URL of the requested object. That absolute URL is then used by the proxy to establish a separate TCP connection to the origin server if the Cohen-Rangarajan-Singh 2-5-2 4 proxy does not have a copy of the requested object in its cache. The proxy requires the absolute URL since the destination address of the packets to the proxy is set by the browser to the IP address of the proxy rather than the IP address of the origin server. Thus, in order to determine whether it has s the object in its cache and if not establish a connection to the origin server, the proxy requires the absolute URL of the origin server in the GET request.
When requests are transparently directed to a proxy cache, however, the client browser is unaware that the request is being directed to the proxy and is possibly being fulfilled from the cache. Rather, the client's browser to needs to "think" that it is connected to the origin server to which its SYN
and the packets) containing the GET request are addressed. Such origin server IP address is determined by the browser through a DNS look-up.
Further, the source address of the ACK SYN packet and the packets containing the requested object must be that same origin server IP address is or they will not be recognized by the browser as being the responsive packets to the SYN packet and the request for the object. Thus, in order to transparently send object requests to a proxy cache, a mechanism must be in place along the packet transmission path to intercept an initial SYN
packet sent by a browser and to redirect it to the proxy cache to establish a 2o TCP connection. The proxy cache must then masquerade as the origin server when sending the ACK SYN packet back to the client by using the origin server's IP address and port number as the source address of that packet. Further, the subsequent packets) containing a GET request must be redirected to the proxy cache and the request fulfilled either from the Zs cache or via a separate TCP connection from the proxy to the origin server.
In either case, the source address of packets sent back to the client must be Cohen-Rangarajan-Singh 2-5-2 s the origin server's IP address and port number to which the packets sent by the client are addressed.
In order for packets associated with a request for an object to be redirected to a proxy cache connected somewhere in the network, a Layer 4 s (L4) switch on the packet path "looks" at the port number of a destination address of a SYN request packet. Since HTTP connection requests are generally directed to port 80 of an origin server, the L4 switch transparently redirects all packets having a port number of 80 in the destination address.
The SYN packet is thus sent to a selected proxy cache. In order for the to proxy cache to properly respond to the client, as noted, it must know the absolute URL of the requested object and packets returned to the client must masquerade as coming from the origin server. Unlike the non-transparent caching method previously described in which the browser formulates a GET request with the absolute URL, for transparent caching Is the absolute URL must be provided in some manner to the proxy cache in order for the proxy to determine whether it in fact has the requested object in its cache, or whether it must establish a separate TCP connection to the origin server to request the object. In the prior art, when one or more caches are directly connected to the L4 switch, the switch chooses one of 2o the caches and transparently forwards the packets to that proxy without modifying the source or destination address of the packets. The proxy, working in a promiscuous TCP mode accepts all incoming packets regardless of their destination address. The proxy, then receiving the SYN
packet with the origin server's destination address and the client's source 2s address, can respond to SYN packet with an ACK SYN packet. This ACK
SYN packet has the client's address as a destination address and a source address masquerading as the origin server address. This packet is Cohen-Rangarajan-Singh 2-5-2 6 transported through the L4 switch onto the network over the TCP
connection back to the client. The subsequent packets) with the GET
request from the client is redirected by the L4 switch to the directly connected proxy. Since the GET packets) only contains the complete URL, s the proxy must formulate the absolute URL to determine whether its has the requested object in its cache or whether is must establish a separate TCP
connection to the origin server. The proxy forms the absolute URL by prefixing the complete URL in the GET request with the IP address of the origin server in the destination address of the packet. The proxy can then io determine whether it has the object and, if not, establish a TCP connection to that absolute address. If that particular origin server at that IP address should be inoperative, the proxy can alternatively prefix the complete URL in the GET request with the logical name of the site indicated in the HOST field in the packets) containing the GET request.
is In the prior art, if the proxy cache is not directly connected to the L4 switch, then the L4 switch must perform a network address translation (NAT) and port address translation (PAT) on those packets directed to port 80 of an origin server. Specifically, when the L4 switch receives a SYN
packet to initiate a TCP connection from a client to an origin server, it 2o translates the destination address of the packet from the IP address and port number of the origin server to the IP address and port number of a selected proxy cache. Further, the switch translates the source address of the packet from the clients IP address and port number to its own IP
address and a port number. When the proxy responds with an ACK SYN
as packet, it therefore responds to the L4 switch where a NAT translates the destination IP address from the IP address of the L4 switch to the IP
address of the client, and translates the source IP address from the IP
Cohen-Rangarajan-Singh 2-5-2 address of the proxy to IP address of the origin server. A PAT also translates the port number in the destination address from that of the L4 switch to that of the client, and translates the port number in the source address from that of the proxy to that of the origin server (usually 80).
s When the client sends an ACK packet and then the packets) containing the GET request to the origin server, the L4 switch again performs a NAT, translating the destination IP address to the IP address of the proxy. Thus, when the packets) containing the GET request is received by the proxy, it does not know the IP address of the origin server as in the directly io connected proxy arrangement described above. The proxy must therefore look at the logical name in the HOST field and perform a DNS look-up to determine that site's IP address. The proxy then uses that IP address in combination with the complete URL in the GET request to form an absolute URL from which it determines whether it has the requested object in its is cache. If it doesn't, a separate TCP connection is established from the proxy to that absolute URL to retrieve that object, which is returned to the proxy. Whether the object is found in the proxy cache or is retrieved over the separate connection from the origin server, it is forwarded back to the L4 switch where a NAT and PAT are performed to translate the destination 2o address to that of the client and to translate the source address to the particular origin server to which the client's request was directed. It should be noted that the source address of the origin server obtained when the client's browser initiates a DNS look-up using the origin server's absolute URL may not be the same IP address obtained when the proxy performs a 2s DNS look-up using the combination of the site URL in the HOST field and the complete URL in the GET request.
Cohen-Rangarajan-Singh 2-5-2 The above described techniques for performing transparent proxy caching have several disadvantages. Firstly, use of a HOST field to specify a logical name of an origin server is not currently incorporated within the presently employed HTTP1.0 standards. Thus, a HOST field may not be s present in the packets) containing a GET request. Where, as described above, the information in the HOST field is necessary to form an absolute URL to determine whether the proxy cache has the requested object and, if not, to establish a connection to an origin server from the proxy, the absence of the HOST field results in an unfilled request. Secondly, the prior io art techniques require the proxy cache to perform the function of forming an absolute URL from the information in the HOST field and in the packets) containing the GET request. Thus, standard proxy caches which expect the client's browser to produce the absolute URL cannot be used. A
methodology for transparent proxy caching that is transparent to both the Is client and the proxy is desirable to avoid modification to the program that controls proxy cache operations. Standard proxy caches could thus be employed anywhere in the network without the need for a special implementation.
The above described prior art techniques have even further 2o disadvantages with respect to persistent connections defined by the HTTP1.1 standards. As defined by these standards, a persistent connection enables a client to send plural GET requests over the same TCP
connection once that connection has been established between two endpoints. When a prior art transparent proxy cache is interposed on the 2s connection, a client may "think" it has established a persistent connection to the specific origin server determined through the DNS look-up. The connection in reality, however, is transparently diverted by the L4 switch to a Cohen-Rangarajan-Singh 2-5-2 9 proxy cache. The proxy cache, in response to a DNS look-up using the logical name in the HOST field, may be directed to an equivalent origin server at a different IP address. Further, as each subsequent GET request is received by the proxy from the client within the client's perceived s persistent connection, each responsive DNS look-up to the logical name may direct a connection to an even different IP address of an equivalent origin server. As a result, the advantages of a transaction-oriented persistent connection in which a server is capable of maintaining state information throughout the connection, are lost. A methodology is desirable io that maintains persistence to the same origin server to which the clients browser is directed, or to a same equivalent origin server throughout the duration of the persistent connection.
Summary of the Invention Is The problems associated with the prior art techniques for transparent proxy caching are eliminated by the present invention. In accordance with the present invention, a switching entity, such as the L4 switch (referred to hereinafter as a proxy redirector), through which the packets flow, is provided with the functionalities at the IP level necessary to transform the 2o complete URL in each GET request transmitted by a client to an appropriate absolute URL. Specifically, the IP address found in the destination field in the IP header of the packets) from the client containing the GET request are added as a prefix by the proxy redirector to the complete URL in the GET request. As a result, the complete URL in the GET request is modified 2s to form an absolute URL which, when received by the proxy cache, is directly used to determine if the requested object is stored in the cache and, if not, to establish a separate TCP connection to the origin server. The GET
Cohen-Rangarajan-Singh 2-5-2 to request received by the proxy is thus equivalent to what it would expect to receive if it were operating in the non-transparent mode. Advantageously, if a persistent connection is established, each subsequent GET request has the same IP address prefix determined by the initial DNS look-up by the s client.
By modifying the GET request at the proxy redirector to include the destination address of the origin server, the number of bytes at the IP level in the packet containing the resultant absolute address are increased by the number of bytes in the prefix. Included in the header within each packet is a to sequence number (seq) that provides an indication of the position of the first byte number in the payload. Thus, when the IP address is added to a packet, the sequence number of each of the subsequent packets needs to be incremented by the count of the added bytes. Further, an acknowledgement sequence number (ack seq) in the header on the is packets returned from the proxy or the origin server that logically follow receipt of the GET packets) at the origin server needs to be decremented by the proxy redirector before being forwarded to the client to avoid confusing the client with respect to what the sequence number of the next byte it sends should be. Further, if the GET request sent by the client Zo encompasses more than one TCP segment, then the extra bytes in the first of the segments caused by the additional bytes added to the URL are shifted into the second segment, and the resultant now extra bytes in the second segment are shifted into the third segment, etc., until the last of the segments. In order to preclude the necessity of requiring an extra segment 2s to be added to the GET request to accommodate the extra bytes, the client sending the GET request is deceived into sending segments whose maximum size is less than what can actually be received by the proxy as Cohen-Rangarajan-Singh 2-5-2 i i indicated by a maximum segment size (MSS) field in packets from the proxy. The proxy redirector, upon receipt of the ACK SYN packet from the proxy, reduces the MSS parameter received from the proxy by the amount of the number of bytes that will be added to the GET request before that s parameter is forwarded to the client. Thus, when the client next sends a GET request, each segment is limited to the reduced MSS, thereby insuring that the segment size of a last segment in a GET request after the IP
address is prefixed by the proxy redirector to form the absolute URL
(whether the GET request is one or more segments long) is less than or to equal to the actual MSS that the proxy can receive.
Brief Description of the Drawing FIG. 1 is a block diagram of a network that includes a proxy redirector that transparently sends requests from a client to a proxy cache by Is changing the destination address of packets in a client request from that of the origin server to that of a proxy and the source address from that of the client to that of the switching entity and, in accordance with the present invention, modifies a GET request to include the destination address of the origin server;
2o FIG. 2 is a block diagram showing the proxy redirector implemented on a programmable network element that manipulates packets in accordance with instructions provided by a loaded program; and FIG. 3, 4, 5 and 6 are flow charts detailing the operation of the proxy red i recto r.
Detailed Description Cohen-Rangarajan-Singh 2-5-2 With reference to FIG. 1, a plurality of clients 101-1 - 101-N are connected to a local area network (LAN) 102, such as an Ethernet. LAN
102, which, in turn, is connected through a router 103 to a Level 4 (L4) switch 104 (proxy redirector) which interfaces the LAN with a wide area s network (WAN) 105, such as the Internet. Although shown as two separate elements, the functionalities of router 103 and proxy redirector 104 can in actual practice be combined in a single unit. All requests from any of the clients connected to LAN 102 for objects stored in servers connected to the Internet 105 traverse proxy redirector 104 onto the Internet. The packets to comprising such requests, which include the standardized packets that establish a TCP connection, are directed to an IP destination address and port number indicated in the IP header of each packet originating from a client source address that includes a client IP address and port number.
Similarly, responses to such requests from an origin server connected to is Internet 105 are directed via an IP destination address that is equal to the client's IP address and port number from which the request originated, and have as a source address the server's IP address and port number. All such packets directed to any of the clients 101-1 - 101-N from any server connected to Internet 105 pass through proxy redirector 104.
2o When any of the clients connected to LAN 102, such as client 101-1, makes a request through a browser for an object by specifying a logical URL, a domain name server (DNS) 106 connected locally or on Internet 105, as shown, is accessed to perform a database look-up based on that logical name. An associated IP address is then returned to the browser.
as The IP address returned to the browser is the IP address of a particular origin server which contains the object requested through the logical URL.
Since a logical name may in fact be associated with a plurality of essentially Cohen-Rangarajan-Singh 2-5-2 13 equivalent origin servers, such as servers 107 and 109, the particular IP
address returned to the client browser chosen by DNS 106 may be determined in a round-robin manner. When DNS 106 selects an origin server corresponding to the logical URL, the IP address of the selected s origin server, such as, for example, the IP address of origin server 107, is returned to the browser in the requesting client 101-1. That IP address then serves as the IP address to which packets directed to the origin server from the client are directed. Conventionally, http requests are usually directed to port 80 of an origin server.
io With the IP address of the origin server determined and returned to the client, the browser establishes a TCP connection between the client and the origin server through a three-way handshaking process. Specifically, a SYN packet, addressed to the IP address of the selected origin server, is sent by the client. Handshaking is completed when the client receives an is acknowledgement of receipt of that SYN packet through an ACK SYN
packet sent by that origin server, and responds with a ACK packet to the origin server. The browser then sends a GET request that specifies the particular requested object.
In accordance with the present invention, once the IP address of the 20 origin server corresponding to the logical URL name is determined through the DNS look-up, proxy redirector 104, rather than establishing a TCP
connection to the origin server at the determined IP address, transparently establishes a TCP connection between the client and a proxy. If the requested object is stored in the cache, a copy of that object is transparently zs returned to the requesting client. A TCP connection, therefore, is not established over the Internet 105, to the actual origin server 107 to provide the requested object to the requesting client. The coss of transmitting the Cohen-Rangarajan-Singh 2-5-2 14 request to the origin server over the Internet and transmitting the copy of the requested object back over the Internet are thereby saved in addition to the time required for transmitting such a request over the Internet and waiting for a response from the origin server. If the proxy cache to which the s request is directed does not contain the requested object, a separate TCP
connection is established between the proxy cache and the origin server to obtain a copy of the requested object. When the proxy cache then receives the copy of the requested object from an origin server over that separate TCP connection, the copy is forwarded to the client over the original TCP
io connection that was established between the client and the proxy cache.
In the embodiment shown in FIG. 1, a proxy cache 110-1 is illustratively shown connected to a LAN 111, which is connected to LAN 102 through a router 112. Another proxy cache 115 is shown connected on a different LAN 116 through router 103. Other proxy caches can be located is anywhere on LANs 102, 111, or 116, on another LAN connected to the Internet 105 such as proxy cache 117. Proxy redirector 104 selects one of the available proxy caches to which to forward client requests based on a metric such as least-loaded or round-robin, based on IP header information such as the origin server IP address. With respect to the latter, all objects 2o from a specific origin server will be served by a specific proxy.
In the preferred embodiment described herein, proxy redirector 104 includes a programmable network element of the type described in co-pending U.S. patent application Serial Number 09/190,355, filed November 12, 1998, which application is incorporated herein by reference. As Zs described in that application, that programmable network element in the preferred embodiment runs on a Linux machine. As shown in FIG. 2, the programmable network element 200 includes a dispatcher process 202 with Cohen-Rangarajan-Singh 2-5-2 i5 which plural different gateway programs (204, 205 and 206) register and request access to IP packets that fit specific descriptions. Such programs are loaded through an admission daemon 210 via a local program injector 211 or a remote program injector 212. A gateway program, for example, s can request access to incoming packets to network interface 208 that match certain source and destination IP address ranges and port numbers. The dispatcher process 202 uses a packet filter 203 in the Linux kernel 201 to obtain packets requested by the gateway programs and uses a raw IP
socket 215 to send packets that have been manipulated in accordance with to the gateway program back to the kernel for output back to the network through filter 203 through network interfaces 208. Library functions are provided in the programmable network element that enable a gateway program to communicate with the dispatcher process 202 to register rules that specify the type of IP packets that a gateway program wants diverted to is it. A gateway program can request either a complete IP packet or only the IP and TCP header of a packet and can change both the header and payload of a packet.
In the present invention, that programmable network element is operative in combination with a gateway program that manipulates the 2o destination and source addresses of packets flowing there through in a manner to be described, as well as modifying, as will be described, information in the packets) containing the GET request that specifies the URL of the requested object. Specifically, the programmable network element in combination with the gateway program operates on packets 2s associated with HTTP requests, which are determined from the destination port number. As previously noted, HTTP requests are conventionally addressed to port 80 of an origin server. Thus, the programmable network Cohen-Rangarajan-Singh 2-5-2 16 element/gateway program which together comprise proxy redirector 104 in this embodiment, captures through the dispatcher process of the programmable network element, packets directed to port 80 and then performs address translations on those captured packets to readdress these s packets to a selected proxy. With respect to address translations, the gateway program translates the destination IP address of packets addressed to the origin server to the IP address of a selected proxy cache and translates the source IP address of such packets from that of the client to the IP address of proxy redirector 104. Further, in order for proxy io redirector 104 to identify requests from plural client terminals that are directed to the same proxy, the source port number is translated to a bogus ghost port number at the proxy redirector. Thus, when proxy cache responds, the packets transmitted by the cache have a destination IP
address of proxy redirector 104 at that bogus port number, which is is distinctly associated with the client. The gateway program within proxy redirector 104 then translates the IP destination address of these responsive packets from the proxy to the IP address of the client and translates the bogus destination port number to the port number from which the client originated its request. Further, the gateway program translates Zo the source IP address of such responsive packets from that of the proxy to the IP address of the origin server and the port number to the port (80) to which the client's requests were originally directed. Thus, the packets which are returned to the client from the proxy masquerade as if they had originated from the origin server to which the client "believed" its request 2s had been sent.
By performing the above-described network address translations (NATs) and port address translations (PATs), packets from a client 101-1 Cohen-Rangarajan-Singh 2-5-2 are transparently directed by proxy redirector 104 to a proxy cache.
Responsive packets from the proxy cache are sent to proxy redirector 104 where they are redirected to client 101-1.
In establishing a TCP connection that is directed to an origin server, s client 101-1 first transmits a SYN packet, which is intercepted by proxy redirector 104. Proxy redirector 104 selects a proxy cache, such as proxy 110-1, to redirect this request and creates a connection control block (CCB) to maintain information about the connection. Selection of the particular proxy is determined, as described above, by one of several possible to algorithms. The CCB is used to store the client IP address and TCP port number and the origin server IP address and TCP port number, both of which are contained in the IP header of the SYN packet, and the chosen proxy's IP address. The destination address is then changed to that of the chosen proxy and the packet is sent back to the network for redirection to its is new destination address of the proxy 110-1. All subsequent packets that originate from the same client with the same TCP port number are then forwarded to the same proxy. Proxy 110-1 responds with an ACK SYN
packet which is directed via its destination address to proxy redirector 110-1. Proxy redirector 104 then translates the source IP address and port 2o number to those of the origin server and the destination IP address and port number to those of the client. When the packet arrives at the client the client believes that it is connected to the origin server. The client then responds with an ACK packet to the origin server, which is redirected by proxy redirector 104 to proxy cache 110-1, to complete the handshaking 2s process.
After the TCP connection is established between client 101-1 and proxy cache 110-1, client 101-1 sends one or more packets containing a Cohen-Rangarajan-Singh 2-5-2 1g GET request addressed to the origin server. Such packets are thus "captured" by proxy redirector 104 and redirected to proxy cache 110-1. As previously discussed, the GET request sent by the client contains only the complete URL sent by the client browser which in itself provides insufficient s information for the proxy cache to determine whether it has the requested object and, if not, to forward it to the origin server which does. In accordance with the present invention, the gateway program that is operative with the programmable network element of the proxy redirector 104, captures this packet or packets and, in addition to previously described to address translations, transforms the complete URL to an absolute URL by prefixing it with the IP address of the origin server obtained from the destination IP address of the packets) containing the GET request. Thus, Level 7 (application) information is modified to assist in level 4 routing.
In order to make the URL transformation transparent to both the is client and proxy cache endpoints, changes in IP and TCP headers are also required. Since the GET request modification increases the length of the IP
packet that carries the GET request, the total length field on the IP header of this packet is increased by an offset. The offset amount is recorded in the CCB. In addition, the TCP header contains sequence numbers (seq) 2o and acknowledgement sequence numbers (ack seq) that need to be translated. The seq in the TCP header indicates the byte number of the first byte on this packet going from the sender to the receiver over the TCP
session and the ack_seq indicates the byte number of the next byte that the sender expects to receive from the receiver. For all packets after the GET
2s packets) that go from the client to the proxy cache, the seq is increased by an offset equal to the lengthof(absolute URL) - lengfhof(complete URL) so that the seq matches the byte number of the byte that the proxy cache Cohen-Rangarajan-Singh 2-5-2 19 expects to receive from the client. Similarly, on all packets starting with the acknowledgement to the GET packet that go from the proxy cache to the client through the proxy redirector, the ack_seq is decreased by the same offset so that the ack_seq matches the byte number of the byte that the s proxy cache would expect the client to send in the next packet following the GET packet. By performing these changes in the header, the client and proxy cache endpoints remain unaware of the modification in the GET
packets from the complete URL to the absolute URL.
Table 1 illustrates the URL and other header transformations to performed Table 1 Arriving packet:
Is ---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=346 id=60276 frag off=4000H TTL=64 protocol=6 cksum=1792H
saddr=135.104.25.243 daddy=204.71.200.244 20 ---> TCP header: sport=1273 dport=80 seq=2189084427 ack_seq=3266449517 tcp_hdr_len=5 flags=ACK PSH
rest=OH rest=OH window=31856 cksum=162H urgent=0 ---> beginning of packet data dump <---2s GET /a/ya/yahoomail/promo1.gif HTTP/1.0 Referer: http://www.yahoo.com/
Connection: Keep-Alive User-Agent: Mozilla/4.05 [en] (X11; U; Linux 2.1.103 i686) Host: us.yimg.com 3o Accept: image/gif, image/x-xbitmap, image/jpeg, imagelpjpeg image/png Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 Modified to:
35 _______________ Cohen-Rangarajan-Singh 2-5-2 20 ---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=367 id=60276 frag off=4000H TTL=64 protocol=6 cksum=1792H
saddr=135.104.25.245 daddy=135.104.25.31 s ---> TCP header: sport=5000 dport=7000 seq=2189084427 ack_seq=3266449517 tcp_hdr_len=5 flags=ACK PSH
rest=OH rest=OH window=31856 cksum=162H urgent=0 ---> beginning of packet data dump <---io GET http://204.71.200.244/a/ya/yahoomail/promo1.gif HTTP/1.0 Referer: http://www.yahoo.com/
Connection: Keep-Alive User-Agent: Mozilla/4.05 [en] (X11; U; Linux 2.1.103 i686) Host: us.yimg.com is Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg image/png Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 on a GET packet that arrives at proxy redirector 104 from a client 101-1.
Zo The packet is destined to an origin server at a destination IP address (daddy) 204.71.200.244 (www.yahoo.com) at a destination port (dport) 80, requesting object lalyalyahoomaillpromo1.gif. As can be noted in the modified packet, the packet is redirected to a proxy cache 110-1 at IP
address 135.104.25.31 port 7000 by changing the daddy and dport header 2s information. Also, the complete URL of the object in the GET request is modified in the translated packet by prefixing it with http:ll204.71.200.244 to form the absolute URL, where that prefix is obtained from the daddy header in the arriving packet. This transformation increases the length of the packet by 21 bytes so that the pkt len field in the header is modified from 30 346 to 367 bytes. Further, the source port is modified to a bogus port number by changing sport to 5000.
Table 2 shows the translations performed by the proxy redirector 104 to an acknowledgment from proxy cache 110-1 to the GET request. The arriving Cohen-Rangarajan-Singh 2-5-2 21 Table 2 Arriving packet:
---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=40 id=14559 frag off=4000H TTL=255 protocol=6 cksum=10eH
to saddr=135.104.25.31 daddy=135.104.25.245 ---> TCP header: sport=7000 dport=5000 seq=3266449517 ack_seq=2189084754 tcp_hdr_len=5 flags=ACK
rest=OH rest=OH window=8433 cksum=32H urgent=0 Modified to:
---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=40 id=14559 frag off=4000H TTL=255 protocol=6 cksum=10eH
saddr=204.71.200.244 daddy=135.104.25.243 ---> TCP header: sport=80 dport=1273 seq=3266449517 ack_seq=2189084733 2s tcp_hdr_len=5 flags=ACK
rest=OH rest=OH window=8433 cksum=32H urgent=0 packet is addressed (daddy) to the IP address of the proxy redirector at the bogus port (dport) 5000 used by the proxy redirector for this TCP
3o connection. The source IP address (saddr) and the source port (sport) are those of the proxy cache to where the GET request was directed. The ack seq field indicates the byte number of the first byte that is expected to be sent in the packet following the GET packet. In this example, ack seq is equal to the sequence number (seq) 218908427 of the GET packet plus the 3s length of the GET packet, which in this case per Table 1 is 367. Thus ack_seq of the arriving packet is 218908754. Since client 101-1 is unaware Cohen-Rangarajan-Singh 2-5-2 22 that a proxy redirector has increased the length of the GET packet by 21 bytes, proxy redirector 104 decreases the ack_seq field by the number of bytes added, 21. Further, proxy redirector 104 translates the destination IP
address and port number to those of the client 101-1, and the source IP
s address and port number to that of the origin server. The modified packet, when received by the client, thus appears to the client to have originated from the origin server and the ack_seq field indicates a byte number that the client would next expect to send having previously sent a packet of length 367 bytes. All packets that are subsequently sent through the proxy to redirector 104 to client 101-1 from proxy cache 110-1 are similarly modified to decrement the ack_seq field by the number of bytes, 21, added to the GET packet.
Table 3 illustrates a next packet sent by client 101-1 to the origin server after the GET packet. In this packet the sequence number (seq) is is equal to the modified ack seq sent to the client, as per Table 2. The destination IP address and port number are those of the origin server and the source IP address and port number are those of the client. When received by proxy redirector 104, the packet is modified to change the source IP address and port number to the IP address and bogus port 2o number of the proxy redirector. The destination address IP and port number are translated to that of proxy cache 110-1. The sequence number (seq) is increased by that same value of 21 to match the byte number that the proxy cache expects to receive based on the sequence number previously received in the GET packet and the length, 2s 367, of the GET packet Table 3 Cohen-Rangarajan-Singh 2-5-2 23 Arriving packet:
s ---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=40 id=60281 frag off=4000H TTL=64 protocol=6 cksum=18bfH
saddr=135.104.25.243 daddy=204.71.200.244 ---> TCP header: sport=1273 dport=80 seq=2189084733 to ack_seq=3266450977 tcp_hdr_len=5 flags=ACK
rest=OH rest=OH window=31856 cksum=d3f7H urgent=0 Modified to:
is ---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=40 id=60281 frag off=4000H TTL=64 protocol=6 cksum=18bfH
2o saddr=135.104.25.245 daddy=135.104.25.31 ---> TCP header: sport=5000 dport=7000 seq=2189084754 ack_seq=3266450977 tcp_hdr_len=5 flags=ACK
rest=OH rest=OH window=31856 cksum=d3f7H urgent=0 2s received. All subsequent packets directed to the origin server from client 101-1 are similarly modified before being directed to proxy cache 110-1.
In the above-description, it has been assumed that the length of the GET request both before modification, and after the URL extension is less 3o than the maximum TCP segment size. In fact, the length of the GET
request may be longer than one TCP segment. If the length of the GET
request carrying the complete URL occupies x number of TCP segment and, after it is modified to carry the absolute URL, it still also fits into that same x number of TCP segments, then the segment carrying the URL is 3s modified and overflowing characters are pipelined from one segment to the next. Thus, the overflowing characters from a previous packet are prefixed Cohen-Rangarajan-Singh 2-5-2 24 to the start of the next packet, etc., until the last packet, which length is increased by the increased number of bytes due to the URL modification.
Therefore, the packet length of only the last segment is modified to include the characters that have been shifted into that segment. The ack seq s parameter in packets from the proxy cache to the client is modified starting from the acknowledgment to the last GET packet.
If the modification of the URL to the absolute URL could cause the last TCP segment of the GET request to overflow to another segment, a new TCP segment would need to be constructed and injected by the proxy io redirector. The proxy redirector would then need to have the capability to retransmit this segment if it was lost. Thus, the proxy redirector would need to have some TCP layer functionalities. In order to avoid adding higher level functionality to the proxy redirector, segment sizes are limited to less than what the proxy cache is actually capable of receiving. When the is complete URL is transformed to an extended URL, the maximum increase in size is 22 bytes, equal to the maximum length of an IP address of 15 bytes plus 7 bytes from the prefix: http://. The client is deceived to send segments whose maximum size is 22 bytes less than what the protocol allows it to send. The TCP segment size sent by the client is determined by what the 2o proxy cache, in its handshake with the client, indicates as the maximum segment size it can receive. This is indicates by the proxy cache through the maximum segment size (MSS) field in the ACK SYN packet.
Accordingly, the proxy redirector 104 intercepts the ACK SYN packets and decreases the specified MSS amount by 22. For example, if the MSS
2s specified by the proxy cache is 1460, it is modified to 1438 by the proxy redirector before being sent to the client. When the client next sends a GET
request, the TCP segments are limited to 1438 bytes. In the worst case, Cohen-Rangarajan-Singh 2-5-2 25 when the client sends a GET request, 22 bytes will be added to the xth TCP
segment that carries this request. The length of this xth TCP segment will still then be within the maximum length specified by the proxy cache. If the event that the proxy cache does not stipulate a maximum MSS in the ACK
SYN packet, the default used by the client is 536 bytes. An MSS option is then added by the proxy redirector to inform the client that the maximum MSS expected by the other end of the TCP connection is 514 bytes.
As previously described, a NAT and PAT are performed by proxy redirector 104 on all packets addressed by client 101-1 to an origin server, io and all packets addressed by proxy cache 110-1 to proxy redirector 104 for return to the client. Proxy redirector 104 thus performs a NAT and a PAT on these packets flowing in both direction. If proxy redirector 104 selects a proxy cache that is located in such a point on the network that packets from the proxy cache addressed directly to client 101-1 must pass through proxy is redirector 104 due to the network configuration, then proxy redirector need only perform a half NAT on the packets flowing through it. Specifically, if proxy redirector 104 selects a proxy cache such as proxy cache 117, all packets addressed to client 101-1 must pass through proxy redirector 104.
Proxy redirector 104 thus only needs to transform the destination IP address 2o and port number of packets from client 101-1 to the IP address and port number of proxy cache 117, while maintaining the source IP address and port number as those of client 101-1. The packets returned from proxy cache 117 will thus be addressed to the client's IP address and port number. When they pass through proxy redirector 104, they are captured 2s and the transformation of the source IP address and port to those of the origin server are the only address changes that need to be effected.
Cohen-Rangarajan-Singh 2-5-2 26 The problems of the prior art with respect to persistent connections is obviated in accordance with the present invention. As previously noted, during a persistent connection plural GET requests can be made by a client.
In the prior art, as described, each GET request can result in a connection s from a proxy cache to a different origin server if the proxy cache does not have the requested objects. The ability of a server to maintain the state of a client's connection throughout the duration of the connection is compromised if each GET request results in connections to multiple servers.
In accordance with the present invention, once the IP address of the origin to server is determined at the initial DNS lookup, that same IP address is used by the proxy redirector as a prefix to each complete URL in every GET
request issued by the client throughout the duration of the persistent connection. Thus, assuming the proxy cache does not contain any of the requested objects, the proxy cache will establish a TCP connection to the is same origin server in response to each GET request generated by the client. It should be noted that if plural client GET requests are forwarded by the proxy redirector to a proxy cache within a persistent TCP connection, ack_seq parameter in packets that flow through the proxy redirector from the proxy following each GET request must reflect the cumulative changes 2o effected by translating the complete URL to the absolute URL in each of the preceding GET requests within the same TCP connection. Similarly, in all packets received by the proxy redirector from the client directed to the origin server within a persistent TCP connection, the seq parameter must reflect cumulative changes.
2s FIGS. 3, and 4, together are flow charts detailing the functions of proxy redirector 104 in establishing a TCP connection to a proxy cache and modifying the GET request so that such requests can be transparently Cohen-Rangarajan-Singh 2-5-2 27 forwarded to the proxy. At step 301, a SYN packet arrives from the client at the proxy redirector At step 302, proxy redirector selects a proxy cache based on a load balancing algorithm or on an arbitrary or random selection.
At step 303, proxy redirector performs a full NAT, changing the daddy from s that of the origin server to that of the selected proxy and saddr from that of the client to that of the proxy redirector. At step 304 a PAT is performed, changing sport to that of a bogus ghost port number and dport to the proxy's port number. At step 305, the SYN packet is sent to the proxy. In response to that SYN packet, the proxy responds, at step 306, with a SYN ACK
to packet containing an MSS parameter in the TCP header. At step 307, a reverse translation is performed on both the IP addresses and port numbers, changing saddr and sport to those of the origin server and daddy and dport to those of the client. At step 308, the MSS field is changed by reducing the value of the MSS received from the proxy by 22. At step 309, Is the ACK SYN packet is sent to the client. At step 310, proxy redirector receives a responsive ACK packet from the client. At step 311, a full NAT
and PAT are performed on that packet and, at step 312, the modified packet is sent to the proxy, thereby completing the handshake sequence.
At step 313, a packet containing a GET request is received from the 2o client. A full NAT is performed at step 314 and a PAT is performed at step 315. A determination is made at decision step 316 whether this is a first packet in the GET request. If yes, at step 317, the IP address of the origin server obtained from daddy of the arriving packet is prefixed to the complete URL in the GET request. If, at step 316, the packet is not a first packet in a 2s GET request, then, at step 318, the overflow bytes from the previous GET
packet are prefixed to those bytes in the current packet and if the total number of bytes in the resultant packet is than the actual MSS sent by the Cohen-Rangarajan-Singh 2-5-2 2g proxy, the overflow bytes greater are buffered for prefixing to the next packet. After alternative steps 316 or 318, at step 319, a determination is made whether the current packet is the last packet of a GET request. If not, at step 320, the current packet is sent to the proxy and the flow returns to s step 313 to receive the next packet in the GET request from the client. If at step 319, the current packet is the last packet in a GET message, then, at step 321, the pkt len parameter of that packet is changed to reflect the change in length of the packet. At step 322, the modified packet is sent to the proxy.
io FIG. 5 illustrates the steps performed by the proxy redirector for each packet received from the proxy starting from the ACK to the GET request through the end of the connection. At step 501, the proxy redirector receives the ACK to the GET request, or any other packet that logically follows the ACK to the GET request. At step 502, reverse NAT and PATs is are performed, translating daddy and dport to those of the client and saddr and sport to those of the origin server. At step 503, ack seq is decreased by the amount added in the preceding GET request. At step 504, the modified packet is sent to the client.
FIG. 6 illustrates the step performed by the proxy redirector for each 2o packet destined for the origin server from the client that follows the GET
request. At step 601, a packet subsequent to the GET request is received from the client. At step 602, a full NAT and PAT are performed. At step 603, seq_no is increased by the amount of bytes added by modifying the previous GET request. At step 604, the packet is sent to the proxy.
2s In the discussion above of FIGS. 3, 4, 5 and 6, it has been assumed that the proxy cache is located in a position such that packets directed to the client will not automatically flow through the proxy redirector. Thus, all Cohen-Rangarajan-Singh 2-5-2 29 packets from the proxy are addressed to the proxy redirector. Therefore, for packets flowing from the client, and packets flowing from the proxy, the proxy redirector performs a full NAT and PAT. If however, as previously described, the proxy cache selected by the proxy redirector is located on the s network so that all packets from proxy to the client automatically flow through the proxy redirector, then, in the steps shown in FIGS. 3, 4, 5 and 6, only a half NAT needs to be performed.
Although described in conjunction the programmable network element shown in FIG. 2, the proxy redirector of the present invention could Io be implemented through other means, using hardware, software, or a combination of both. As an example, a level 4 switch having a fixed program to perform the required packet manipulations required by the present invention could be used.
As described, the proxy cache returns requested objects to the is address from which a request originated as indicated by the saddr and sport parameters in the IP header information, which is the address of the proxy redirector 104 when the proxy cache is not connected on the network so that all responses do not automatically pass through the proxy redirector.
The interactions between the requesting client and the proxy cache are Zo transparent to both the client and the proxy cache, since the client does not "know" that its request is being redirected to the proxy by the proxy redirector, and the proxy cache, when receiving a GET request with an absolute URL does not know that that absolute URL is not being formulated by the client's browser operating in a non-transparent mode.
2s Advantageously, the proxy cache requires no software modifications and standard proxy caches, connected anywhere on the network can be used in conjunction with the proxy redirector. If, however, the proxy is modified, Cohen-Rangarajan-Singh 2-5-2 30 using a programmable network element as previously described, for example, the requested object retrieved by the proxy from its own cache or received from an origin server, can be sent directly back to the client, thereby obviating the need to send such packets back to the proxy s redirector for address translations and redirection to the client. By performing only a half NAT at the proxy redirector and leaving the client's saddr and sport as the source IP address and port number in the header of the SYN packet, GET request packet(s), and other packets forwarded by proxy redirector 104 from the client, the proxy cache can return packets io responsive to the request directly to the client by substituting the origin server's IP address and port number as the source address for its own address. If the proxy redirector performs a full NAT and PAT, then another mechanism must be incorporated to provide the client address to the proxy cache, such as incorporating the client address information as part of an is appendix to the absolute address in the modified GET request and stripping the appended client address information at the proxy before determining whether the requested object is stored in the cache or whether a connection to the origin server need be made. Advantageously, by sending the packets from the proxy cache directly back to the client, the delay encountered by 2o transmitting such packets back to the proxy redirector for address translation and redirection is eliminated. Disadvantageously, the proxy cache must be modified to perform these functions, precluding use of standard available proxy caches.
Although described hereinabove in connection with GET requests, Zs the present invention can equally be applied to redirection of any type of request message in which the token is, for example, GET, POST or HEAD, or any other type of token yet to be implemented and/or standardized.
Cohen-Rangarajan-Singh 2-5-2 31 The foregoing therefore merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the invention and are included s within its spirit and scope. Furthermore, all examples and conditional language recited hereinabove are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventors to furthering the art, and are to be construed as being without limitation to such specifically io recited examples and conditions. Moreover, all statements hereinabove reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents Is developed in the future, i.e., any elements developed that perform the same function, regardless of structure.
Thus, for example, it will be appreciated by those skilled in the art that the block diagrams and flowcharts described hereinabove represent conceptual views of illustrative circuitry and processes embodying the 2o principles of the invention. Similarly, it will be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such a computer or processor is explicitly shown.
2s The functions of the various elements shown in the FIGS., including functional blocks labeled as "processors" may be provided through the use of dedicated hardware as well as hardware capable of executing software in Cohen-Rangarajan-Singh 2-5-2 32 association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller"
s should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any to switches shown in the FIGS. are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementor as more specifically understood from the context.
Is In the claims hereof any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements which performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate 2o circuitry for executing that software to perform the function. The invention as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. Applicant thus regards any means which can provide those functionalities as equivalent to those shown hereinabove.
REQUESTS FOR WEB OBJECTS TO PROXY CACHES
Field of the Invention s This invention relates to packet-switched computer networks, and more particularly, to a method and apparatus in such a network for transparently intercepting client web requests and redirecting them to proxy caches.
io Background of the Invention Proxy caching is currently used to decrease both the latency of object retrieval and traffic on the Internet backbone. As is well known, if a proxy cache has stored a copy of an object from an origin server that has been requested by a client, the requested object is supplied to the client from the is proxy cache rather than from the origin server. This, therefore, obviates the need to send the request over a wide area network, such as the Internet, to the origin server where the original object is stored and the responsive transmission of a copy of the requested object back over the network to the requesting client.
2o Direction of a request from a client to a proxy cache to determine whether a requested copy of an object is stored in the cache can be accomplished either transparently or non-transparently to the client. Non-transparent redirection is accomplished through the client's browser program which is configured to send all object requests to a designated 2s proxy cache at a specified address. Generally, a browser can be configured to send all of its client requests to a designated proxy cache if the client is Cohen-Rangarajan-Singh 2-5-2 connected on a Local Area Network (LAN), or on an Intranet behind a firewall, where a proxy cache associated with that LAN or Intranet is located. When clients are served by a large Internet Service Provider (ISP), however, it is not advantageous from the ISP's standpoint to allow its s subscribers to set their browsers to a specific proxy cache associated with the ISP. A large ISP likely will have many proxy caches in several locations and will thus want to maintain control over which of its several particular proxy caches a client request is directed. Further, if a proxy cache whose address is statically set in a client's browser becomes inoperative, all client io requests will fail.
It is therefore more desirable from an ISP's standpoint with respect to latency and minimizing traffic onto and off of the network to transparently intercept a client's web request and send it to one of its operative proxy caches to determine whether a copy of the requested object is stored there.
is If a copy of the requested object is then found to be stored in that proxy cache, a copy of the object is sent to the client, which is unaware that it has been served an object from the proxy cache rather than from the origin server to which it made the request. If the proxy cache does not hold a copy of the requested object, then a separate connection is established 2o between the proxy cache and the origin server to obtain a copy of the object, which when returned to the proxy is sent to the client over the connection established between the client and the proxy.
When a client specifies a URL of the object it is requesting a copy of, a Domain Name Server (DNS) look-up is performed to determine from the 2s URL an IP address of an origin server which has that requested object. As a result of that look-up, an IP address is returned to the client of one of what may be several substantially equivalent servers that contain that object.
Cohen-Rangarajan-Singh 2-5-2 The client then establishes a TCP connection to that server using a three-way handshake mechanism. Such a connection is determined at each end by a port number and an IP address. First, a SYN packet is sent from the client to that origin server, wherein the destination IP address specified in s the packet is the DNS-determined IP address of the origin server and the destination port number for an HTTP request is conventionally port 80. The source IP address and port number of the packet are the IP address and port number associated with the client. The client IP address is generally assigned to the client by an ISP and the client port number is dynamically io assigned by the protocol stack in the client. The origin server then responds back to the client with an ACK SYN packet in which the destination IP
address and destination port are the client's IP address and port number and the packet's source IP address and port number are the server's IP
address and the server's port number, the latter generally being port 80.
is After receipt of the ACK SYN packet, the client sends one or more packets to the origin server, which packets include a GET request. The GET
request includes a complete URL, which identifies to that server the specific object within the origin server site that the client wants a copy of. Unlike an absolute URL, which includes both site information (e.g., www.yahoo.com), 2o and object information (e.g., index.html), a complete URL only identifies the particular object (e.g., index.html) that is requested since the packets) containing the GET request is sent to the proper origin server site by means of the destination address of the packet(s).
When a browser is configured to non-transparently send all requests as to a proxy, a GET request is formulated by the browser that includes the absolute URL of the requested object. That absolute URL is then used by the proxy to establish a separate TCP connection to the origin server if the Cohen-Rangarajan-Singh 2-5-2 4 proxy does not have a copy of the requested object in its cache. The proxy requires the absolute URL since the destination address of the packets to the proxy is set by the browser to the IP address of the proxy rather than the IP address of the origin server. Thus, in order to determine whether it has s the object in its cache and if not establish a connection to the origin server, the proxy requires the absolute URL of the origin server in the GET request.
When requests are transparently directed to a proxy cache, however, the client browser is unaware that the request is being directed to the proxy and is possibly being fulfilled from the cache. Rather, the client's browser to needs to "think" that it is connected to the origin server to which its SYN
and the packets) containing the GET request are addressed. Such origin server IP address is determined by the browser through a DNS look-up.
Further, the source address of the ACK SYN packet and the packets containing the requested object must be that same origin server IP address is or they will not be recognized by the browser as being the responsive packets to the SYN packet and the request for the object. Thus, in order to transparently send object requests to a proxy cache, a mechanism must be in place along the packet transmission path to intercept an initial SYN
packet sent by a browser and to redirect it to the proxy cache to establish a 2o TCP connection. The proxy cache must then masquerade as the origin server when sending the ACK SYN packet back to the client by using the origin server's IP address and port number as the source address of that packet. Further, the subsequent packets) containing a GET request must be redirected to the proxy cache and the request fulfilled either from the Zs cache or via a separate TCP connection from the proxy to the origin server.
In either case, the source address of packets sent back to the client must be Cohen-Rangarajan-Singh 2-5-2 s the origin server's IP address and port number to which the packets sent by the client are addressed.
In order for packets associated with a request for an object to be redirected to a proxy cache connected somewhere in the network, a Layer 4 s (L4) switch on the packet path "looks" at the port number of a destination address of a SYN request packet. Since HTTP connection requests are generally directed to port 80 of an origin server, the L4 switch transparently redirects all packets having a port number of 80 in the destination address.
The SYN packet is thus sent to a selected proxy cache. In order for the to proxy cache to properly respond to the client, as noted, it must know the absolute URL of the requested object and packets returned to the client must masquerade as coming from the origin server. Unlike the non-transparent caching method previously described in which the browser formulates a GET request with the absolute URL, for transparent caching Is the absolute URL must be provided in some manner to the proxy cache in order for the proxy to determine whether it in fact has the requested object in its cache, or whether it must establish a separate TCP connection to the origin server to request the object. In the prior art, when one or more caches are directly connected to the L4 switch, the switch chooses one of 2o the caches and transparently forwards the packets to that proxy without modifying the source or destination address of the packets. The proxy, working in a promiscuous TCP mode accepts all incoming packets regardless of their destination address. The proxy, then receiving the SYN
packet with the origin server's destination address and the client's source 2s address, can respond to SYN packet with an ACK SYN packet. This ACK
SYN packet has the client's address as a destination address and a source address masquerading as the origin server address. This packet is Cohen-Rangarajan-Singh 2-5-2 6 transported through the L4 switch onto the network over the TCP
connection back to the client. The subsequent packets) with the GET
request from the client is redirected by the L4 switch to the directly connected proxy. Since the GET packets) only contains the complete URL, s the proxy must formulate the absolute URL to determine whether its has the requested object in its cache or whether is must establish a separate TCP
connection to the origin server. The proxy forms the absolute URL by prefixing the complete URL in the GET request with the IP address of the origin server in the destination address of the packet. The proxy can then io determine whether it has the object and, if not, establish a TCP connection to that absolute address. If that particular origin server at that IP address should be inoperative, the proxy can alternatively prefix the complete URL in the GET request with the logical name of the site indicated in the HOST field in the packets) containing the GET request.
is In the prior art, if the proxy cache is not directly connected to the L4 switch, then the L4 switch must perform a network address translation (NAT) and port address translation (PAT) on those packets directed to port 80 of an origin server. Specifically, when the L4 switch receives a SYN
packet to initiate a TCP connection from a client to an origin server, it 2o translates the destination address of the packet from the IP address and port number of the origin server to the IP address and port number of a selected proxy cache. Further, the switch translates the source address of the packet from the clients IP address and port number to its own IP
address and a port number. When the proxy responds with an ACK SYN
as packet, it therefore responds to the L4 switch where a NAT translates the destination IP address from the IP address of the L4 switch to the IP
address of the client, and translates the source IP address from the IP
Cohen-Rangarajan-Singh 2-5-2 address of the proxy to IP address of the origin server. A PAT also translates the port number in the destination address from that of the L4 switch to that of the client, and translates the port number in the source address from that of the proxy to that of the origin server (usually 80).
s When the client sends an ACK packet and then the packets) containing the GET request to the origin server, the L4 switch again performs a NAT, translating the destination IP address to the IP address of the proxy. Thus, when the packets) containing the GET request is received by the proxy, it does not know the IP address of the origin server as in the directly io connected proxy arrangement described above. The proxy must therefore look at the logical name in the HOST field and perform a DNS look-up to determine that site's IP address. The proxy then uses that IP address in combination with the complete URL in the GET request to form an absolute URL from which it determines whether it has the requested object in its is cache. If it doesn't, a separate TCP connection is established from the proxy to that absolute URL to retrieve that object, which is returned to the proxy. Whether the object is found in the proxy cache or is retrieved over the separate connection from the origin server, it is forwarded back to the L4 switch where a NAT and PAT are performed to translate the destination 2o address to that of the client and to translate the source address to the particular origin server to which the client's request was directed. It should be noted that the source address of the origin server obtained when the client's browser initiates a DNS look-up using the origin server's absolute URL may not be the same IP address obtained when the proxy performs a 2s DNS look-up using the combination of the site URL in the HOST field and the complete URL in the GET request.
Cohen-Rangarajan-Singh 2-5-2 The above described techniques for performing transparent proxy caching have several disadvantages. Firstly, use of a HOST field to specify a logical name of an origin server is not currently incorporated within the presently employed HTTP1.0 standards. Thus, a HOST field may not be s present in the packets) containing a GET request. Where, as described above, the information in the HOST field is necessary to form an absolute URL to determine whether the proxy cache has the requested object and, if not, to establish a connection to an origin server from the proxy, the absence of the HOST field results in an unfilled request. Secondly, the prior io art techniques require the proxy cache to perform the function of forming an absolute URL from the information in the HOST field and in the packets) containing the GET request. Thus, standard proxy caches which expect the client's browser to produce the absolute URL cannot be used. A
methodology for transparent proxy caching that is transparent to both the Is client and the proxy is desirable to avoid modification to the program that controls proxy cache operations. Standard proxy caches could thus be employed anywhere in the network without the need for a special implementation.
The above described prior art techniques have even further 2o disadvantages with respect to persistent connections defined by the HTTP1.1 standards. As defined by these standards, a persistent connection enables a client to send plural GET requests over the same TCP
connection once that connection has been established between two endpoints. When a prior art transparent proxy cache is interposed on the 2s connection, a client may "think" it has established a persistent connection to the specific origin server determined through the DNS look-up. The connection in reality, however, is transparently diverted by the L4 switch to a Cohen-Rangarajan-Singh 2-5-2 9 proxy cache. The proxy cache, in response to a DNS look-up using the logical name in the HOST field, may be directed to an equivalent origin server at a different IP address. Further, as each subsequent GET request is received by the proxy from the client within the client's perceived s persistent connection, each responsive DNS look-up to the logical name may direct a connection to an even different IP address of an equivalent origin server. As a result, the advantages of a transaction-oriented persistent connection in which a server is capable of maintaining state information throughout the connection, are lost. A methodology is desirable io that maintains persistence to the same origin server to which the clients browser is directed, or to a same equivalent origin server throughout the duration of the persistent connection.
Summary of the Invention Is The problems associated with the prior art techniques for transparent proxy caching are eliminated by the present invention. In accordance with the present invention, a switching entity, such as the L4 switch (referred to hereinafter as a proxy redirector), through which the packets flow, is provided with the functionalities at the IP level necessary to transform the 2o complete URL in each GET request transmitted by a client to an appropriate absolute URL. Specifically, the IP address found in the destination field in the IP header of the packets) from the client containing the GET request are added as a prefix by the proxy redirector to the complete URL in the GET request. As a result, the complete URL in the GET request is modified 2s to form an absolute URL which, when received by the proxy cache, is directly used to determine if the requested object is stored in the cache and, if not, to establish a separate TCP connection to the origin server. The GET
Cohen-Rangarajan-Singh 2-5-2 to request received by the proxy is thus equivalent to what it would expect to receive if it were operating in the non-transparent mode. Advantageously, if a persistent connection is established, each subsequent GET request has the same IP address prefix determined by the initial DNS look-up by the s client.
By modifying the GET request at the proxy redirector to include the destination address of the origin server, the number of bytes at the IP level in the packet containing the resultant absolute address are increased by the number of bytes in the prefix. Included in the header within each packet is a to sequence number (seq) that provides an indication of the position of the first byte number in the payload. Thus, when the IP address is added to a packet, the sequence number of each of the subsequent packets needs to be incremented by the count of the added bytes. Further, an acknowledgement sequence number (ack seq) in the header on the is packets returned from the proxy or the origin server that logically follow receipt of the GET packets) at the origin server needs to be decremented by the proxy redirector before being forwarded to the client to avoid confusing the client with respect to what the sequence number of the next byte it sends should be. Further, if the GET request sent by the client Zo encompasses more than one TCP segment, then the extra bytes in the first of the segments caused by the additional bytes added to the URL are shifted into the second segment, and the resultant now extra bytes in the second segment are shifted into the third segment, etc., until the last of the segments. In order to preclude the necessity of requiring an extra segment 2s to be added to the GET request to accommodate the extra bytes, the client sending the GET request is deceived into sending segments whose maximum size is less than what can actually be received by the proxy as Cohen-Rangarajan-Singh 2-5-2 i i indicated by a maximum segment size (MSS) field in packets from the proxy. The proxy redirector, upon receipt of the ACK SYN packet from the proxy, reduces the MSS parameter received from the proxy by the amount of the number of bytes that will be added to the GET request before that s parameter is forwarded to the client. Thus, when the client next sends a GET request, each segment is limited to the reduced MSS, thereby insuring that the segment size of a last segment in a GET request after the IP
address is prefixed by the proxy redirector to form the absolute URL
(whether the GET request is one or more segments long) is less than or to equal to the actual MSS that the proxy can receive.
Brief Description of the Drawing FIG. 1 is a block diagram of a network that includes a proxy redirector that transparently sends requests from a client to a proxy cache by Is changing the destination address of packets in a client request from that of the origin server to that of a proxy and the source address from that of the client to that of the switching entity and, in accordance with the present invention, modifies a GET request to include the destination address of the origin server;
2o FIG. 2 is a block diagram showing the proxy redirector implemented on a programmable network element that manipulates packets in accordance with instructions provided by a loaded program; and FIG. 3, 4, 5 and 6 are flow charts detailing the operation of the proxy red i recto r.
Detailed Description Cohen-Rangarajan-Singh 2-5-2 With reference to FIG. 1, a plurality of clients 101-1 - 101-N are connected to a local area network (LAN) 102, such as an Ethernet. LAN
102, which, in turn, is connected through a router 103 to a Level 4 (L4) switch 104 (proxy redirector) which interfaces the LAN with a wide area s network (WAN) 105, such as the Internet. Although shown as two separate elements, the functionalities of router 103 and proxy redirector 104 can in actual practice be combined in a single unit. All requests from any of the clients connected to LAN 102 for objects stored in servers connected to the Internet 105 traverse proxy redirector 104 onto the Internet. The packets to comprising such requests, which include the standardized packets that establish a TCP connection, are directed to an IP destination address and port number indicated in the IP header of each packet originating from a client source address that includes a client IP address and port number.
Similarly, responses to such requests from an origin server connected to is Internet 105 are directed via an IP destination address that is equal to the client's IP address and port number from which the request originated, and have as a source address the server's IP address and port number. All such packets directed to any of the clients 101-1 - 101-N from any server connected to Internet 105 pass through proxy redirector 104.
2o When any of the clients connected to LAN 102, such as client 101-1, makes a request through a browser for an object by specifying a logical URL, a domain name server (DNS) 106 connected locally or on Internet 105, as shown, is accessed to perform a database look-up based on that logical name. An associated IP address is then returned to the browser.
as The IP address returned to the browser is the IP address of a particular origin server which contains the object requested through the logical URL.
Since a logical name may in fact be associated with a plurality of essentially Cohen-Rangarajan-Singh 2-5-2 13 equivalent origin servers, such as servers 107 and 109, the particular IP
address returned to the client browser chosen by DNS 106 may be determined in a round-robin manner. When DNS 106 selects an origin server corresponding to the logical URL, the IP address of the selected s origin server, such as, for example, the IP address of origin server 107, is returned to the browser in the requesting client 101-1. That IP address then serves as the IP address to which packets directed to the origin server from the client are directed. Conventionally, http requests are usually directed to port 80 of an origin server.
io With the IP address of the origin server determined and returned to the client, the browser establishes a TCP connection between the client and the origin server through a three-way handshaking process. Specifically, a SYN packet, addressed to the IP address of the selected origin server, is sent by the client. Handshaking is completed when the client receives an is acknowledgement of receipt of that SYN packet through an ACK SYN
packet sent by that origin server, and responds with a ACK packet to the origin server. The browser then sends a GET request that specifies the particular requested object.
In accordance with the present invention, once the IP address of the 20 origin server corresponding to the logical URL name is determined through the DNS look-up, proxy redirector 104, rather than establishing a TCP
connection to the origin server at the determined IP address, transparently establishes a TCP connection between the client and a proxy. If the requested object is stored in the cache, a copy of that object is transparently zs returned to the requesting client. A TCP connection, therefore, is not established over the Internet 105, to the actual origin server 107 to provide the requested object to the requesting client. The coss of transmitting the Cohen-Rangarajan-Singh 2-5-2 14 request to the origin server over the Internet and transmitting the copy of the requested object back over the Internet are thereby saved in addition to the time required for transmitting such a request over the Internet and waiting for a response from the origin server. If the proxy cache to which the s request is directed does not contain the requested object, a separate TCP
connection is established between the proxy cache and the origin server to obtain a copy of the requested object. When the proxy cache then receives the copy of the requested object from an origin server over that separate TCP connection, the copy is forwarded to the client over the original TCP
io connection that was established between the client and the proxy cache.
In the embodiment shown in FIG. 1, a proxy cache 110-1 is illustratively shown connected to a LAN 111, which is connected to LAN 102 through a router 112. Another proxy cache 115 is shown connected on a different LAN 116 through router 103. Other proxy caches can be located is anywhere on LANs 102, 111, or 116, on another LAN connected to the Internet 105 such as proxy cache 117. Proxy redirector 104 selects one of the available proxy caches to which to forward client requests based on a metric such as least-loaded or round-robin, based on IP header information such as the origin server IP address. With respect to the latter, all objects 2o from a specific origin server will be served by a specific proxy.
In the preferred embodiment described herein, proxy redirector 104 includes a programmable network element of the type described in co-pending U.S. patent application Serial Number 09/190,355, filed November 12, 1998, which application is incorporated herein by reference. As Zs described in that application, that programmable network element in the preferred embodiment runs on a Linux machine. As shown in FIG. 2, the programmable network element 200 includes a dispatcher process 202 with Cohen-Rangarajan-Singh 2-5-2 i5 which plural different gateway programs (204, 205 and 206) register and request access to IP packets that fit specific descriptions. Such programs are loaded through an admission daemon 210 via a local program injector 211 or a remote program injector 212. A gateway program, for example, s can request access to incoming packets to network interface 208 that match certain source and destination IP address ranges and port numbers. The dispatcher process 202 uses a packet filter 203 in the Linux kernel 201 to obtain packets requested by the gateway programs and uses a raw IP
socket 215 to send packets that have been manipulated in accordance with to the gateway program back to the kernel for output back to the network through filter 203 through network interfaces 208. Library functions are provided in the programmable network element that enable a gateway program to communicate with the dispatcher process 202 to register rules that specify the type of IP packets that a gateway program wants diverted to is it. A gateway program can request either a complete IP packet or only the IP and TCP header of a packet and can change both the header and payload of a packet.
In the present invention, that programmable network element is operative in combination with a gateway program that manipulates the 2o destination and source addresses of packets flowing there through in a manner to be described, as well as modifying, as will be described, information in the packets) containing the GET request that specifies the URL of the requested object. Specifically, the programmable network element in combination with the gateway program operates on packets 2s associated with HTTP requests, which are determined from the destination port number. As previously noted, HTTP requests are conventionally addressed to port 80 of an origin server. Thus, the programmable network Cohen-Rangarajan-Singh 2-5-2 16 element/gateway program which together comprise proxy redirector 104 in this embodiment, captures through the dispatcher process of the programmable network element, packets directed to port 80 and then performs address translations on those captured packets to readdress these s packets to a selected proxy. With respect to address translations, the gateway program translates the destination IP address of packets addressed to the origin server to the IP address of a selected proxy cache and translates the source IP address of such packets from that of the client to the IP address of proxy redirector 104. Further, in order for proxy io redirector 104 to identify requests from plural client terminals that are directed to the same proxy, the source port number is translated to a bogus ghost port number at the proxy redirector. Thus, when proxy cache responds, the packets transmitted by the cache have a destination IP
address of proxy redirector 104 at that bogus port number, which is is distinctly associated with the client. The gateway program within proxy redirector 104 then translates the IP destination address of these responsive packets from the proxy to the IP address of the client and translates the bogus destination port number to the port number from which the client originated its request. Further, the gateway program translates Zo the source IP address of such responsive packets from that of the proxy to the IP address of the origin server and the port number to the port (80) to which the client's requests were originally directed. Thus, the packets which are returned to the client from the proxy masquerade as if they had originated from the origin server to which the client "believed" its request 2s had been sent.
By performing the above-described network address translations (NATs) and port address translations (PATs), packets from a client 101-1 Cohen-Rangarajan-Singh 2-5-2 are transparently directed by proxy redirector 104 to a proxy cache.
Responsive packets from the proxy cache are sent to proxy redirector 104 where they are redirected to client 101-1.
In establishing a TCP connection that is directed to an origin server, s client 101-1 first transmits a SYN packet, which is intercepted by proxy redirector 104. Proxy redirector 104 selects a proxy cache, such as proxy 110-1, to redirect this request and creates a connection control block (CCB) to maintain information about the connection. Selection of the particular proxy is determined, as described above, by one of several possible to algorithms. The CCB is used to store the client IP address and TCP port number and the origin server IP address and TCP port number, both of which are contained in the IP header of the SYN packet, and the chosen proxy's IP address. The destination address is then changed to that of the chosen proxy and the packet is sent back to the network for redirection to its is new destination address of the proxy 110-1. All subsequent packets that originate from the same client with the same TCP port number are then forwarded to the same proxy. Proxy 110-1 responds with an ACK SYN
packet which is directed via its destination address to proxy redirector 110-1. Proxy redirector 104 then translates the source IP address and port 2o number to those of the origin server and the destination IP address and port number to those of the client. When the packet arrives at the client the client believes that it is connected to the origin server. The client then responds with an ACK packet to the origin server, which is redirected by proxy redirector 104 to proxy cache 110-1, to complete the handshaking 2s process.
After the TCP connection is established between client 101-1 and proxy cache 110-1, client 101-1 sends one or more packets containing a Cohen-Rangarajan-Singh 2-5-2 1g GET request addressed to the origin server. Such packets are thus "captured" by proxy redirector 104 and redirected to proxy cache 110-1. As previously discussed, the GET request sent by the client contains only the complete URL sent by the client browser which in itself provides insufficient s information for the proxy cache to determine whether it has the requested object and, if not, to forward it to the origin server which does. In accordance with the present invention, the gateway program that is operative with the programmable network element of the proxy redirector 104, captures this packet or packets and, in addition to previously described to address translations, transforms the complete URL to an absolute URL by prefixing it with the IP address of the origin server obtained from the destination IP address of the packets) containing the GET request. Thus, Level 7 (application) information is modified to assist in level 4 routing.
In order to make the URL transformation transparent to both the is client and proxy cache endpoints, changes in IP and TCP headers are also required. Since the GET request modification increases the length of the IP
packet that carries the GET request, the total length field on the IP header of this packet is increased by an offset. The offset amount is recorded in the CCB. In addition, the TCP header contains sequence numbers (seq) 2o and acknowledgement sequence numbers (ack seq) that need to be translated. The seq in the TCP header indicates the byte number of the first byte on this packet going from the sender to the receiver over the TCP
session and the ack_seq indicates the byte number of the next byte that the sender expects to receive from the receiver. For all packets after the GET
2s packets) that go from the client to the proxy cache, the seq is increased by an offset equal to the lengthof(absolute URL) - lengfhof(complete URL) so that the seq matches the byte number of the byte that the proxy cache Cohen-Rangarajan-Singh 2-5-2 19 expects to receive from the client. Similarly, on all packets starting with the acknowledgement to the GET packet that go from the proxy cache to the client through the proxy redirector, the ack_seq is decreased by the same offset so that the ack_seq matches the byte number of the byte that the s proxy cache would expect the client to send in the next packet following the GET packet. By performing these changes in the header, the client and proxy cache endpoints remain unaware of the modification in the GET
packets from the complete URL to the absolute URL.
Table 1 illustrates the URL and other header transformations to performed Table 1 Arriving packet:
Is ---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=346 id=60276 frag off=4000H TTL=64 protocol=6 cksum=1792H
saddr=135.104.25.243 daddy=204.71.200.244 20 ---> TCP header: sport=1273 dport=80 seq=2189084427 ack_seq=3266449517 tcp_hdr_len=5 flags=ACK PSH
rest=OH rest=OH window=31856 cksum=162H urgent=0 ---> beginning of packet data dump <---2s GET /a/ya/yahoomail/promo1.gif HTTP/1.0 Referer: http://www.yahoo.com/
Connection: Keep-Alive User-Agent: Mozilla/4.05 [en] (X11; U; Linux 2.1.103 i686) Host: us.yimg.com 3o Accept: image/gif, image/x-xbitmap, image/jpeg, imagelpjpeg image/png Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 Modified to:
35 _______________ Cohen-Rangarajan-Singh 2-5-2 20 ---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=367 id=60276 frag off=4000H TTL=64 protocol=6 cksum=1792H
saddr=135.104.25.245 daddy=135.104.25.31 s ---> TCP header: sport=5000 dport=7000 seq=2189084427 ack_seq=3266449517 tcp_hdr_len=5 flags=ACK PSH
rest=OH rest=OH window=31856 cksum=162H urgent=0 ---> beginning of packet data dump <---io GET http://204.71.200.244/a/ya/yahoomail/promo1.gif HTTP/1.0 Referer: http://www.yahoo.com/
Connection: Keep-Alive User-Agent: Mozilla/4.05 [en] (X11; U; Linux 2.1.103 i686) Host: us.yimg.com is Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg image/png Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 on a GET packet that arrives at proxy redirector 104 from a client 101-1.
Zo The packet is destined to an origin server at a destination IP address (daddy) 204.71.200.244 (www.yahoo.com) at a destination port (dport) 80, requesting object lalyalyahoomaillpromo1.gif. As can be noted in the modified packet, the packet is redirected to a proxy cache 110-1 at IP
address 135.104.25.31 port 7000 by changing the daddy and dport header 2s information. Also, the complete URL of the object in the GET request is modified in the translated packet by prefixing it with http:ll204.71.200.244 to form the absolute URL, where that prefix is obtained from the daddy header in the arriving packet. This transformation increases the length of the packet by 21 bytes so that the pkt len field in the header is modified from 30 346 to 367 bytes. Further, the source port is modified to a bogus port number by changing sport to 5000.
Table 2 shows the translations performed by the proxy redirector 104 to an acknowledgment from proxy cache 110-1 to the GET request. The arriving Cohen-Rangarajan-Singh 2-5-2 21 Table 2 Arriving packet:
---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=40 id=14559 frag off=4000H TTL=255 protocol=6 cksum=10eH
to saddr=135.104.25.31 daddy=135.104.25.245 ---> TCP header: sport=7000 dport=5000 seq=3266449517 ack_seq=2189084754 tcp_hdr_len=5 flags=ACK
rest=OH rest=OH window=8433 cksum=32H urgent=0 Modified to:
---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=40 id=14559 frag off=4000H TTL=255 protocol=6 cksum=10eH
saddr=204.71.200.244 daddy=135.104.25.243 ---> TCP header: sport=80 dport=1273 seq=3266449517 ack_seq=2189084733 2s tcp_hdr_len=5 flags=ACK
rest=OH rest=OH window=8433 cksum=32H urgent=0 packet is addressed (daddy) to the IP address of the proxy redirector at the bogus port (dport) 5000 used by the proxy redirector for this TCP
3o connection. The source IP address (saddr) and the source port (sport) are those of the proxy cache to where the GET request was directed. The ack seq field indicates the byte number of the first byte that is expected to be sent in the packet following the GET packet. In this example, ack seq is equal to the sequence number (seq) 218908427 of the GET packet plus the 3s length of the GET packet, which in this case per Table 1 is 367. Thus ack_seq of the arriving packet is 218908754. Since client 101-1 is unaware Cohen-Rangarajan-Singh 2-5-2 22 that a proxy redirector has increased the length of the GET packet by 21 bytes, proxy redirector 104 decreases the ack_seq field by the number of bytes added, 21. Further, proxy redirector 104 translates the destination IP
address and port number to those of the client 101-1, and the source IP
s address and port number to that of the origin server. The modified packet, when received by the client, thus appears to the client to have originated from the origin server and the ack_seq field indicates a byte number that the client would next expect to send having previously sent a packet of length 367 bytes. All packets that are subsequently sent through the proxy to redirector 104 to client 101-1 from proxy cache 110-1 are similarly modified to decrement the ack_seq field by the number of bytes, 21, added to the GET packet.
Table 3 illustrates a next packet sent by client 101-1 to the origin server after the GET packet. In this packet the sequence number (seq) is is equal to the modified ack seq sent to the client, as per Table 2. The destination IP address and port number are those of the origin server and the source IP address and port number are those of the client. When received by proxy redirector 104, the packet is modified to change the source IP address and port number to the IP address and bogus port 2o number of the proxy redirector. The destination address IP and port number are translated to that of proxy cache 110-1. The sequence number (seq) is increased by that same value of 21 to match the byte number that the proxy cache expects to receive based on the sequence number previously received in the GET packet and the length, 2s 367, of the GET packet Table 3 Cohen-Rangarajan-Singh 2-5-2 23 Arriving packet:
s ---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=40 id=60281 frag off=4000H TTL=64 protocol=6 cksum=18bfH
saddr=135.104.25.243 daddy=204.71.200.244 ---> TCP header: sport=1273 dport=80 seq=2189084733 to ack_seq=3266450977 tcp_hdr_len=5 flags=ACK
rest=OH rest=OH window=31856 cksum=d3f7H urgent=0 Modified to:
is ---> beginning of packet header dump <------> IP header: version=4 hdr_len=5 TOS=0 pkt len=40 id=60281 frag off=4000H TTL=64 protocol=6 cksum=18bfH
2o saddr=135.104.25.245 daddy=135.104.25.31 ---> TCP header: sport=5000 dport=7000 seq=2189084754 ack_seq=3266450977 tcp_hdr_len=5 flags=ACK
rest=OH rest=OH window=31856 cksum=d3f7H urgent=0 2s received. All subsequent packets directed to the origin server from client 101-1 are similarly modified before being directed to proxy cache 110-1.
In the above-description, it has been assumed that the length of the GET request both before modification, and after the URL extension is less 3o than the maximum TCP segment size. In fact, the length of the GET
request may be longer than one TCP segment. If the length of the GET
request carrying the complete URL occupies x number of TCP segment and, after it is modified to carry the absolute URL, it still also fits into that same x number of TCP segments, then the segment carrying the URL is 3s modified and overflowing characters are pipelined from one segment to the next. Thus, the overflowing characters from a previous packet are prefixed Cohen-Rangarajan-Singh 2-5-2 24 to the start of the next packet, etc., until the last packet, which length is increased by the increased number of bytes due to the URL modification.
Therefore, the packet length of only the last segment is modified to include the characters that have been shifted into that segment. The ack seq s parameter in packets from the proxy cache to the client is modified starting from the acknowledgment to the last GET packet.
If the modification of the URL to the absolute URL could cause the last TCP segment of the GET request to overflow to another segment, a new TCP segment would need to be constructed and injected by the proxy io redirector. The proxy redirector would then need to have the capability to retransmit this segment if it was lost. Thus, the proxy redirector would need to have some TCP layer functionalities. In order to avoid adding higher level functionality to the proxy redirector, segment sizes are limited to less than what the proxy cache is actually capable of receiving. When the is complete URL is transformed to an extended URL, the maximum increase in size is 22 bytes, equal to the maximum length of an IP address of 15 bytes plus 7 bytes from the prefix: http://. The client is deceived to send segments whose maximum size is 22 bytes less than what the protocol allows it to send. The TCP segment size sent by the client is determined by what the 2o proxy cache, in its handshake with the client, indicates as the maximum segment size it can receive. This is indicates by the proxy cache through the maximum segment size (MSS) field in the ACK SYN packet.
Accordingly, the proxy redirector 104 intercepts the ACK SYN packets and decreases the specified MSS amount by 22. For example, if the MSS
2s specified by the proxy cache is 1460, it is modified to 1438 by the proxy redirector before being sent to the client. When the client next sends a GET
request, the TCP segments are limited to 1438 bytes. In the worst case, Cohen-Rangarajan-Singh 2-5-2 25 when the client sends a GET request, 22 bytes will be added to the xth TCP
segment that carries this request. The length of this xth TCP segment will still then be within the maximum length specified by the proxy cache. If the event that the proxy cache does not stipulate a maximum MSS in the ACK
SYN packet, the default used by the client is 536 bytes. An MSS option is then added by the proxy redirector to inform the client that the maximum MSS expected by the other end of the TCP connection is 514 bytes.
As previously described, a NAT and PAT are performed by proxy redirector 104 on all packets addressed by client 101-1 to an origin server, io and all packets addressed by proxy cache 110-1 to proxy redirector 104 for return to the client. Proxy redirector 104 thus performs a NAT and a PAT on these packets flowing in both direction. If proxy redirector 104 selects a proxy cache that is located in such a point on the network that packets from the proxy cache addressed directly to client 101-1 must pass through proxy is redirector 104 due to the network configuration, then proxy redirector need only perform a half NAT on the packets flowing through it. Specifically, if proxy redirector 104 selects a proxy cache such as proxy cache 117, all packets addressed to client 101-1 must pass through proxy redirector 104.
Proxy redirector 104 thus only needs to transform the destination IP address 2o and port number of packets from client 101-1 to the IP address and port number of proxy cache 117, while maintaining the source IP address and port number as those of client 101-1. The packets returned from proxy cache 117 will thus be addressed to the client's IP address and port number. When they pass through proxy redirector 104, they are captured 2s and the transformation of the source IP address and port to those of the origin server are the only address changes that need to be effected.
Cohen-Rangarajan-Singh 2-5-2 26 The problems of the prior art with respect to persistent connections is obviated in accordance with the present invention. As previously noted, during a persistent connection plural GET requests can be made by a client.
In the prior art, as described, each GET request can result in a connection s from a proxy cache to a different origin server if the proxy cache does not have the requested objects. The ability of a server to maintain the state of a client's connection throughout the duration of the connection is compromised if each GET request results in connections to multiple servers.
In accordance with the present invention, once the IP address of the origin to server is determined at the initial DNS lookup, that same IP address is used by the proxy redirector as a prefix to each complete URL in every GET
request issued by the client throughout the duration of the persistent connection. Thus, assuming the proxy cache does not contain any of the requested objects, the proxy cache will establish a TCP connection to the is same origin server in response to each GET request generated by the client. It should be noted that if plural client GET requests are forwarded by the proxy redirector to a proxy cache within a persistent TCP connection, ack_seq parameter in packets that flow through the proxy redirector from the proxy following each GET request must reflect the cumulative changes 2o effected by translating the complete URL to the absolute URL in each of the preceding GET requests within the same TCP connection. Similarly, in all packets received by the proxy redirector from the client directed to the origin server within a persistent TCP connection, the seq parameter must reflect cumulative changes.
2s FIGS. 3, and 4, together are flow charts detailing the functions of proxy redirector 104 in establishing a TCP connection to a proxy cache and modifying the GET request so that such requests can be transparently Cohen-Rangarajan-Singh 2-5-2 27 forwarded to the proxy. At step 301, a SYN packet arrives from the client at the proxy redirector At step 302, proxy redirector selects a proxy cache based on a load balancing algorithm or on an arbitrary or random selection.
At step 303, proxy redirector performs a full NAT, changing the daddy from s that of the origin server to that of the selected proxy and saddr from that of the client to that of the proxy redirector. At step 304 a PAT is performed, changing sport to that of a bogus ghost port number and dport to the proxy's port number. At step 305, the SYN packet is sent to the proxy. In response to that SYN packet, the proxy responds, at step 306, with a SYN ACK
to packet containing an MSS parameter in the TCP header. At step 307, a reverse translation is performed on both the IP addresses and port numbers, changing saddr and sport to those of the origin server and daddy and dport to those of the client. At step 308, the MSS field is changed by reducing the value of the MSS received from the proxy by 22. At step 309, Is the ACK SYN packet is sent to the client. At step 310, proxy redirector receives a responsive ACK packet from the client. At step 311, a full NAT
and PAT are performed on that packet and, at step 312, the modified packet is sent to the proxy, thereby completing the handshake sequence.
At step 313, a packet containing a GET request is received from the 2o client. A full NAT is performed at step 314 and a PAT is performed at step 315. A determination is made at decision step 316 whether this is a first packet in the GET request. If yes, at step 317, the IP address of the origin server obtained from daddy of the arriving packet is prefixed to the complete URL in the GET request. If, at step 316, the packet is not a first packet in a 2s GET request, then, at step 318, the overflow bytes from the previous GET
packet are prefixed to those bytes in the current packet and if the total number of bytes in the resultant packet is than the actual MSS sent by the Cohen-Rangarajan-Singh 2-5-2 2g proxy, the overflow bytes greater are buffered for prefixing to the next packet. After alternative steps 316 or 318, at step 319, a determination is made whether the current packet is the last packet of a GET request. If not, at step 320, the current packet is sent to the proxy and the flow returns to s step 313 to receive the next packet in the GET request from the client. If at step 319, the current packet is the last packet in a GET message, then, at step 321, the pkt len parameter of that packet is changed to reflect the change in length of the packet. At step 322, the modified packet is sent to the proxy.
io FIG. 5 illustrates the steps performed by the proxy redirector for each packet received from the proxy starting from the ACK to the GET request through the end of the connection. At step 501, the proxy redirector receives the ACK to the GET request, or any other packet that logically follows the ACK to the GET request. At step 502, reverse NAT and PATs is are performed, translating daddy and dport to those of the client and saddr and sport to those of the origin server. At step 503, ack seq is decreased by the amount added in the preceding GET request. At step 504, the modified packet is sent to the client.
FIG. 6 illustrates the step performed by the proxy redirector for each 2o packet destined for the origin server from the client that follows the GET
request. At step 601, a packet subsequent to the GET request is received from the client. At step 602, a full NAT and PAT are performed. At step 603, seq_no is increased by the amount of bytes added by modifying the previous GET request. At step 604, the packet is sent to the proxy.
2s In the discussion above of FIGS. 3, 4, 5 and 6, it has been assumed that the proxy cache is located in a position such that packets directed to the client will not automatically flow through the proxy redirector. Thus, all Cohen-Rangarajan-Singh 2-5-2 29 packets from the proxy are addressed to the proxy redirector. Therefore, for packets flowing from the client, and packets flowing from the proxy, the proxy redirector performs a full NAT and PAT. If however, as previously described, the proxy cache selected by the proxy redirector is located on the s network so that all packets from proxy to the client automatically flow through the proxy redirector, then, in the steps shown in FIGS. 3, 4, 5 and 6, only a half NAT needs to be performed.
Although described in conjunction the programmable network element shown in FIG. 2, the proxy redirector of the present invention could Io be implemented through other means, using hardware, software, or a combination of both. As an example, a level 4 switch having a fixed program to perform the required packet manipulations required by the present invention could be used.
As described, the proxy cache returns requested objects to the is address from which a request originated as indicated by the saddr and sport parameters in the IP header information, which is the address of the proxy redirector 104 when the proxy cache is not connected on the network so that all responses do not automatically pass through the proxy redirector.
The interactions between the requesting client and the proxy cache are Zo transparent to both the client and the proxy cache, since the client does not "know" that its request is being redirected to the proxy by the proxy redirector, and the proxy cache, when receiving a GET request with an absolute URL does not know that that absolute URL is not being formulated by the client's browser operating in a non-transparent mode.
2s Advantageously, the proxy cache requires no software modifications and standard proxy caches, connected anywhere on the network can be used in conjunction with the proxy redirector. If, however, the proxy is modified, Cohen-Rangarajan-Singh 2-5-2 30 using a programmable network element as previously described, for example, the requested object retrieved by the proxy from its own cache or received from an origin server, can be sent directly back to the client, thereby obviating the need to send such packets back to the proxy s redirector for address translations and redirection to the client. By performing only a half NAT at the proxy redirector and leaving the client's saddr and sport as the source IP address and port number in the header of the SYN packet, GET request packet(s), and other packets forwarded by proxy redirector 104 from the client, the proxy cache can return packets io responsive to the request directly to the client by substituting the origin server's IP address and port number as the source address for its own address. If the proxy redirector performs a full NAT and PAT, then another mechanism must be incorporated to provide the client address to the proxy cache, such as incorporating the client address information as part of an is appendix to the absolute address in the modified GET request and stripping the appended client address information at the proxy before determining whether the requested object is stored in the cache or whether a connection to the origin server need be made. Advantageously, by sending the packets from the proxy cache directly back to the client, the delay encountered by 2o transmitting such packets back to the proxy redirector for address translation and redirection is eliminated. Disadvantageously, the proxy cache must be modified to perform these functions, precluding use of standard available proxy caches.
Although described hereinabove in connection with GET requests, Zs the present invention can equally be applied to redirection of any type of request message in which the token is, for example, GET, POST or HEAD, or any other type of token yet to be implemented and/or standardized.
Cohen-Rangarajan-Singh 2-5-2 31 The foregoing therefore merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the invention and are included s within its spirit and scope. Furthermore, all examples and conditional language recited hereinabove are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventors to furthering the art, and are to be construed as being without limitation to such specifically io recited examples and conditions. Moreover, all statements hereinabove reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents Is developed in the future, i.e., any elements developed that perform the same function, regardless of structure.
Thus, for example, it will be appreciated by those skilled in the art that the block diagrams and flowcharts described hereinabove represent conceptual views of illustrative circuitry and processes embodying the 2o principles of the invention. Similarly, it will be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such a computer or processor is explicitly shown.
2s The functions of the various elements shown in the FIGS., including functional blocks labeled as "processors" may be provided through the use of dedicated hardware as well as hardware capable of executing software in Cohen-Rangarajan-Singh 2-5-2 32 association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller"
s should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any to switches shown in the FIGS. are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementor as more specifically understood from the context.
Is In the claims hereof any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements which performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate 2o circuitry for executing that software to perform the function. The invention as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. Applicant thus regards any means which can provide those functionalities as equivalent to those shown hereinabove.
Claims (55)
1. A method at a Layer 4 switch for transparently redirecting an HTTP connection request that is directed to an origin server to a proxy cache over a packet-based computer network comprising the steps of:
receiving at least one packet containing a request message within the HTTP connection, the at least one packet having an IP header comprising a destination address of an origin server, the request message including a complete address of a specified object at the origin server;
modifying the request message by combining the destination address of the origin server with the complete address; and forwarding the at least one packet containing the modified request message to the proxy cache over the packet-based network.
receiving at least one packet containing a request message within the HTTP connection, the at least one packet having an IP header comprising a destination address of an origin server, the request message including a complete address of a specified object at the origin server;
modifying the request message by combining the destination address of the origin server with the complete address; and forwarding the at least one packet containing the modified request message to the proxy cache over the packet-based network.
2. The method of claim 1 wherein the step of modifying comprises the step of prefixing the complete address in the request message with the destination address of the origin server.
3. The method of claim 2 further comprising the step of:
translating the destination address in an IP header of the at least one packet containing the modified request message to the address of the proxy cache.
translating the destination address in an IP header of the at least one packet containing the modified request message to the address of the proxy cache.
4. The method of claim 3 further comprising the step of:
translating a source address in the IP header of the at least one packet containing the modified request message from an address of the client to an address of the Layer 4 switch.
translating a source address in the IP header of the at least one packet containing the modified request message from an address of the client to an address of the Layer 4 switch.
5. The method of claim 3 further comprising the step of:
in a TCP header in packets received from the proxy cache commencing with an acknowledgment to the modified request message, modifying a value in a acknowledged byte sequence number field to reflect the increased number of bytes in the modified request message resulting from the step of prefixing the complete address with the destination address of the origin server.
in a TCP header in packets received from the proxy cache commencing with an acknowledgment to the modified request message, modifying a value in a acknowledged byte sequence number field to reflect the increased number of bytes in the modified request message resulting from the step of prefixing the complete address with the destination address of the origin server.
6. The method of claim 5 wherein the step of modifying the value in the acknowledged byte sequence number field comprises the step of decreasing the value in the acknowledged byte sequence number field by the number of bytes added by prefixing the destination address of the origin server to the complete address in the request message.
7. The method of claim 6 further comprising the step of:
translating in the IP header the destination address to the address of the client and the source address to that of the origin server in the packets received from the proxy cache commencing with the acknowledgment to the request message.
translating in the IP header the destination address to the address of the client and the source address to that of the origin server in the packets received from the proxy cache commencing with the acknowledgment to the request message.
8. The method of claim 3 further comprising the step of:
modifying a value in a sent byte sequence number field to reflect the increased number of bytes in the modified request message resulting from prefixing the complete address with the destination address of the origin server in a TCP header in packets received from the client following receipt of the request message.
modifying a value in a sent byte sequence number field to reflect the increased number of bytes in the modified request message resulting from prefixing the complete address with the destination address of the origin server in a TCP header in packets received from the client following receipt of the request message.
9. The method of claim 8 wherein the step of modifying the value in the sent byte sequence number field comprises the step of increasing the value in the sent byte sequence number field by the number of bytes added by prefixing the destination address of the origin server to the complete address in the request message.
10. The method of claim 9 further comprising the step of:
translating the destination address to the address of the proxy cache in the IP header in each packet received from the client following receipt of the request message.
translating the destination address to the address of the proxy cache in the IP header in each packet received from the client following receipt of the request message.
11. The method of claim of claim 1 further comprising the step of selecting the proxy cache from a plurality of different proxy caches prior to receiving the at least one packet containing the request message.
12. The method of claim 2 further comprising, prior to the step of receiving the at least one packet containing the request message, the steps of:
receiving a packet from the proxy cache indicating a maximum segment size that packets sent to it thereafter should have;
reducing by a predetermined number the maximum segment size of packets to be thereafter sent to the proxy cache; and sending a packet to the client indicating the reduced maximum segment size that packets thereafter sent by the client to the origin server should have.
receiving a packet from the proxy cache indicating a maximum segment size that packets sent to it thereafter should have;
reducing by a predetermined number the maximum segment size of packets to be thereafter sent to the proxy cache; and sending a packet to the client indicating the reduced maximum segment size that packets thereafter sent by the client to the origin server should have.
13. The method of claim 12 wherein the predetermined number is equal at least to the maximum number of bytes added by the step of prefixing the destination address to the complete address in the request message.
14. The method of claim 13 further comprising the steps of:
successively shifting to a next packet in the request message overflow bytes caused by the step of prefixing the destination address to the complete address in the request message, if the request message is contained within more than one packet; and changing a length-of-packet parameter in the IP header in a last packet of a multi-packet request message to reflect the bytes shifted into the last packet from a previous packet.
successively shifting to a next packet in the request message overflow bytes caused by the step of prefixing the destination address to the complete address in the request message, if the request message is contained within more than one packet; and changing a length-of-packet parameter in the IP header in a last packet of a multi-packet request message to reflect the bytes shifted into the last packet from a previous packet.
15. The method of claim 13 further comprising the step of changing a length-of packet parameter in the IP header to reflect the change in the length of that packet caused by the step of prefixing the destination address to the complete address in the request message, if the request message is contained within one packet.
16. The method of claim 1 wherein the request message is a GET
request.
request.
17. The method of claim 1 wherein the request message is a POST
request.
request.
18. The method of claim 1 wherein the request message is a HEAD
request.
request.
19. A proxy redirector for transparently redirecting an HTTP
connection request from a client that is directed to an origin server request message to a proxy cache over a packet-based computer network comprising:
means for receiving at least one packet containing the request message, the at least one packet having an IP header comprising a destination address of an origin server, the request message including a complete address of a specified object at the origin server;
means for modifying the request message by combining the destination address of the origin server with the complete address; and means for forwarding the at least one packet containing the modified request message to the proxy cache over the packet-based network.
connection request from a client that is directed to an origin server request message to a proxy cache over a packet-based computer network comprising:
means for receiving at least one packet containing the request message, the at least one packet having an IP header comprising a destination address of an origin server, the request message including a complete address of a specified object at the origin server;
means for modifying the request message by combining the destination address of the origin server with the complete address; and means for forwarding the at least one packet containing the modified request message to the proxy cache over the packet-based network.
20. The proxy redirector of claim 19 wherein the means for modifying comprises means for prefixing the complete address in the request message with the destination address of the origin server.
21. The proxy redirector of claim 20 further comprising:
means for translating the destination address in an IP header of the at least one packet containing the modified request message to the address of the proxy cache.
means for translating the destination address in an IP header of the at least one packet containing the modified request message to the address of the proxy cache.
22. The proxy redirector of claim 21 further comprising:
means for translating a source address in the IP header of the at least one packet containing the modified request message from an address of the client to an address of the proxy redirector.
means for translating a source address in the IP header of the at least one packet containing the modified request message from an address of the client to an address of the proxy redirector.
23. The proxy redirector of claim 21 further comprising:
means for modifying a value in an acknowledged byte sequence number field in a TCP header in packets received from the proxy cache, commencing with an acknowledgment to the modified request message, to reflect the increased number of bytes in the modified request message resulting from prefixing the complete address with the destination address of the origin server.
means for modifying a value in an acknowledged byte sequence number field in a TCP header in packets received from the proxy cache, commencing with an acknowledgment to the modified request message, to reflect the increased number of bytes in the modified request message resulting from prefixing the complete address with the destination address of the origin server.
24. The proxy redirector of claim 23 wherein the means for modifying the value in the acknowledged byte sequence number field decreases the value in the acknowledged byte sequence number field by the number of bytes added by prefixing the destination address of the origin server to the complete address in the request message.
25. The proxy redirector of claim 24 further comprising:
means for translating in the IP header the destination address to the address of the client and the source address to that of the origin server in the packets received from the proxy cache commencing with the acknowledgment to the request message.
means for translating in the IP header the destination address to the address of the client and the source address to that of the origin server in the packets received from the proxy cache commencing with the acknowledgment to the request message.
26. The proxy redirector of claim 21 further comprising:
means for modifying a value in a sent byte sequence number field to reflect the increased number of bytes in the modified request message resulting from prefixing the complete address with the destination address of the origin server in a TCP header in packets received from the client following receipt of the request message.
means for modifying a value in a sent byte sequence number field to reflect the increased number of bytes in the modified request message resulting from prefixing the complete address with the destination address of the origin server in a TCP header in packets received from the client following receipt of the request message.
27. The proxy redirector of claim 26 wherein the means for modifying the value in the sent byte sequence number field increases the value in the sent byte sequence number field by the number of bytes added by prefixing the destination address of the origin server to the complete address in the request message.
28. The proxy redirector of claim 27 further comprising:
means for translating the destination address to the address of the proxy cache in the IP header each packet received from the client following receipt of the Request message.
means for translating the destination address to the address of the proxy cache in the IP header each packet received from the client following receipt of the Request message.
29. The proxy redirector of claim 19 further comprising means for selecting the proxy cache from a plurality of different proxy caches.
30. The proxy redirector of claim 20 further comprising:
means for receiving a packet from the proxy cache indicating a maximum segment size that packets sent to it thereafter should have;
means for reducing by a predetermined number the maximum segment size of packets to be thereafter sent to the proxy cache; and means for sending a packet to the client indicating the reduced maximum segment size that packets thereafter sent by the client to the origin server should have.
means for receiving a packet from the proxy cache indicating a maximum segment size that packets sent to it thereafter should have;
means for reducing by a predetermined number the maximum segment size of packets to be thereafter sent to the proxy cache; and means for sending a packet to the client indicating the reduced maximum segment size that packets thereafter sent by the client to the origin server should have.
31. The proxy redirector of claim 30 wherein the predetermined number is equal at least to the maximum number of bytes added by the prefix of the destination address to the complete address in the request message.
32. The proxy redirector of claim 31 further comprising:
means for successively shifting to a next packet in the request message overflow bytes caused by the prefix of the destination address to the complete address in the request message, if the request message is contained within more than one packet; and means for changing a length-of-packet parameter in the IP header in a last packet of a multi-packet request message to reflect the bytes shifted into the last packet from a previous packet.
means for successively shifting to a next packet in the request message overflow bytes caused by the prefix of the destination address to the complete address in the request message, if the request message is contained within more than one packet; and means for changing a length-of-packet parameter in the IP header in a last packet of a multi-packet request message to reflect the bytes shifted into the last packet from a previous packet.
33. The proxy redirector of claim 31 wherein the proxy cache further comprises means for changing a length-of-packet parameter in the IP
header to reflect the change in the length of that packet caused by the prefix of the destination address to the complete address in the request message, if the length of the request message is contained within one packet.
header to reflect the change in the length of that packet caused by the prefix of the destination address to the complete address in the request message, if the length of the request message is contained within one packet.
34. The proxy redirector of claim 19 wherein the means for modifying the request message is a gateway program dynamically loaded on a programmable network element.
35. The proxy redirector of claim 19 wherein the request message is a GET request.
36. The proxy redirector of claim 19 wherein the request message is a POST request.
37. The proxy redirector of claim 19 wherein the request message is a HEAD request.
38. A computer readable medium storing computer program instructions which are executable on a computer system implementing a Layer 4 switch for transparently redirecting an HTTP connection request from a client to a proxy cache over a packet-based computer network, said computer program instructions comprising instructions defining the steps of:
receiving at least one packet containing the request message, the at least one packet having an IP header comprising a destination address of an origin server, the request message including a complete address of a specified object at the origin server;
modifying the request message by combining the destination address of the origin server with the complete address; and forwarding the at least one packet containing the modified request message to the proxy cache over the packet-based network.
receiving at least one packet containing the request message, the at least one packet having an IP header comprising a destination address of an origin server, the request message including a complete address of a specified object at the origin server;
modifying the request message by combining the destination address of the origin server with the complete address; and forwarding the at least one packet containing the modified request message to the proxy cache over the packet-based network.
39. The computer readable memory of claim 37 wherein the step of modifying comprises the step of prefixing the complete address in the request message with the destination address of the origin server.
40. The computer readable memory of claim 39 wherein said computer program instructions further comprise instructions defining the step of:
translating the destination address in an IP header of the at least one packet containing the modified request message to the address of the proxy cache.
translating the destination address in an IP header of the at least one packet containing the modified request message to the address of the proxy cache.
41. The computer readable memory of claim 40 wherein said computer program instructions further comprise instructions defining the step of:
translating a source address in the IP header of the at least one packet containing the modified request message from an address of the client to an address of the Layer 4 switch.
translating a source address in the IP header of the at least one packet containing the modified request message from an address of the client to an address of the Layer 4 switch.
42. The computer readable memory of claim 40 wherein said computer program instructions further comprise instructions defining the step of:
in a TCP header in packets received from the proxy cache commencing with an acknowledgment to the modified request message, modifying a value in a acknowledged byte sequence number field to reflect the increased number of bytes in the modified request message resulting from the step of prefixing the complete address with the destination address of the origin server.
in a TCP header in packets received from the proxy cache commencing with an acknowledgment to the modified request message, modifying a value in a acknowledged byte sequence number field to reflect the increased number of bytes in the modified request message resulting from the step of prefixing the complete address with the destination address of the origin server.
43. The computer readable memory of claim 42 wherein the step of modifying the value in the acknowledged byte sequence number field comprises the step of decreasing the value in the acknowledged byte sequence number field by the number of bytes added by prefixing the destination address of the origin server to the complete address in the request message.
44. The computer readable memory of claim 43 wherein said computer program instructions further comprise instructions defining the step of:
translating in the IP header the destination address to the address of the client and the source address to that of the origin server in the packets received from the proxy cache commencing with the acknowledgment to the request message.
translating in the IP header the destination address to the address of the client and the source address to that of the origin server in the packets received from the proxy cache commencing with the acknowledgment to the request message.
45. The computer readable memory of claim 40 wherein said computer program instructions further comprise instructions defining the step of:
modifying a value in a sent byte sequence number field to reflect the increased number of bytes in the modified request message resulting from prefixing the complete address with the destination address of the origin server in a TCP header in packets received from the client following receipt of the request message.
modifying a value in a sent byte sequence number field to reflect the increased number of bytes in the modified request message resulting from prefixing the complete address with the destination address of the origin server in a TCP header in packets received from the client following receipt of the request message.
46. The computer readable memory of claim 45 wherein the step of modifying the value in the sent byte sequence number field comprises the step of increasing the value in the sent byte sequence number field by the number of bytes added by prefixing the destination address of the origin server to the complete address in the fequest message.
47. The computer readable memory of claim 46 wherein said computer program instructions further comprise instructions defining the step of:
translating the destination address to the address of the proxy cache in the IP header each packet received from the client following receipt of the request message.
translating the destination address to the address of the proxy cache in the IP header each packet received from the client following receipt of the request message.
48. The computer readable memory of claim of claim 38 wherein said computer program instructions further comprise instructions defining the step of selecting the proxy cache from a plurality of different proxy caches prior to receiving the at least one packet containing the request message.
49. The computer readable memory of claim 39 wherein said computer program instructions further comprises instructions defining, prior to the step of receiving the at least one packet containing the request message, the steps of:
receiving a packet from the proxy cache indicating a maximum segment size that packets sent to it thereafter should have;
reducing by a predetermined number the maximum segment size of packets to be thereafter sent to the proxy cache; and sending a packet to the client indicating the reduced maximum segment size that packets thereafter sent by the client to the origin server should have.
receiving a packet from the proxy cache indicating a maximum segment size that packets sent to it thereafter should have;
reducing by a predetermined number the maximum segment size of packets to be thereafter sent to the proxy cache; and sending a packet to the client indicating the reduced maximum segment size that packets thereafter sent by the client to the origin server should have.
50. The computer readable memory of claim 49 wherein the predetermined number is equal at least to the maximum number of bytes added by the step of prefixing the destination address to the complete address in the request message.
51. The computer readable memory of claim 50 wherein said computer program instructions further comprise instructions defining the steps of:
successively shifting to a next packet in the request message overflow bytes caused by the step of prefixing the destination address to the complete address in the request message, if the request message is contained within more than one packet; and changing a length-of-packet parameter in the IP header in a last packet of a multi-packet request message to reflect the bytes shifted into the last packet from a previous packet.
successively shifting to a next packet in the request message overflow bytes caused by the step of prefixing the destination address to the complete address in the request message, if the request message is contained within more than one packet; and changing a length-of-packet parameter in the IP header in a last packet of a multi-packet request message to reflect the bytes shifted into the last packet from a previous packet.
52. The computer readable memory of claim 50 wherein said computer program instructions further comprise instructions defining the step of changing a length-of-packet parameter in the IP header to reflect the change in the length of that packet caused by the step of prefixing the destination address to the complete address in the request message, if the request message is contained within one packet.
53. The computer readable memory of claim 38 wherein the request message is a GET request.
54. The computer readable memory of claim 38 wherein the request message is a POST request.
55. The computer readable memory of claim 38 wherein the request message is a HEAD request.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/212,980 | 1998-12-16 | ||
US09/212,980 US6389462B1 (en) | 1998-12-16 | 1998-12-16 | Method and apparatus for transparently directing requests for web objects to proxy caches |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2288488A1 true CA2288488A1 (en) | 2000-06-16 |
Family
ID=22793236
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002288488A Abandoned CA2288488A1 (en) | 1998-12-16 | 1999-11-03 | Method and apparatus for transparently directing requests for web objects to proxy caches |
Country Status (4)
Country | Link |
---|---|
US (1) | US6389462B1 (en) |
EP (1) | EP1011244B1 (en) |
CA (1) | CA2288488A1 (en) |
DE (1) | DE69919965T2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100498756C (en) * | 2002-02-14 | 2009-06-10 | 第三雷沃Cdn国际公司 | Managed object replication and delivery method and system |
US8930538B2 (en) | 2008-04-04 | 2015-01-06 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
US9762692B2 (en) | 2008-04-04 | 2017-09-12 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
US10924573B2 (en) | 2008-04-04 | 2021-02-16 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
CN114329437A (en) * | 2022-03-14 | 2022-04-12 | 北京指掌易科技有限公司 | Data processing method, device, equipment and storage medium |
Families Citing this family (505)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6189030B1 (en) * | 1996-02-21 | 2001-02-13 | Infoseek Corporation | Method and apparatus for redirection of server external hyper-link references |
KR100528156B1 (en) | 1997-03-12 | 2005-11-15 | 노마딕스, 인코포레이티드 | Nomadic Translator or Router |
US6760746B1 (en) | 1999-09-01 | 2004-07-06 | Eric Schneider | Method, product, and apparatus for processing a data request |
US6256620B1 (en) * | 1998-01-16 | 2001-07-03 | Aspect Communications | Method and apparatus for monitoring information access |
US6298356B1 (en) * | 1998-01-16 | 2001-10-02 | Aspect Communications Corp. | Methods and apparatus for enabling dynamic resource collaboration |
US20070078978A1 (en) * | 1998-06-01 | 2007-04-05 | Sri International | Method and apparatus for updating information in a low-bandwidth client/server object-oriented system |
US6665702B1 (en) | 1998-07-15 | 2003-12-16 | Radware Ltd. | Load balancing |
US6763370B1 (en) * | 1998-11-16 | 2004-07-13 | Softricity, Inc. | Method and apparatus for content protection in a secure content delivery system |
US7017188B1 (en) * | 1998-11-16 | 2006-03-21 | Softricity, Inc. | Method and apparatus for secure content delivery over broadband access networks |
US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
JP3563990B2 (en) * | 1999-02-24 | 2004-09-08 | キヤノン株式会社 | Network device, network device control method, and recording medium |
US9141717B2 (en) | 1999-03-22 | 2015-09-22 | Esdr Network Solutions Llc | Methods, systems, products, and devices for processing DNS friendly identifiers |
US7188138B1 (en) | 1999-03-22 | 2007-03-06 | Eric Schneider | Method, product, and apparatus for resource identifier registration and aftermarket services |
US8037168B2 (en) | 1999-07-15 | 2011-10-11 | Esdr Network Solutions Llc | Method, product, and apparatus for enhancing resolution services, registration services, and search services |
USRE43690E1 (en) | 1999-03-22 | 2012-09-25 | Esdr Network Solutions Llc | Search engine request method, product, and apparatus |
US6338082B1 (en) * | 1999-03-22 | 2002-01-08 | Eric Schneider | Method, product, and apparatus for requesting a network resource |
US6665681B1 (en) * | 1999-04-09 | 2003-12-16 | Entrieva, Inc. | System and method for generating a taxonomy from a plurality of documents |
US7370071B2 (en) | 2000-03-17 | 2008-05-06 | Microsoft Corporation | Method for serving third party software applications from servers to client computers |
US6938096B1 (en) * | 1999-04-12 | 2005-08-30 | Softricity, Inc. | Method and system for remote networking using port proxying by detecting if the designated port on a client computer is blocked, then encapsulating the communications in a different format and redirecting to an open port |
US7730169B1 (en) | 1999-04-12 | 2010-06-01 | Softricity, Inc. | Business method and system for serving third party software applications |
US20030229809A1 (en) * | 1999-04-15 | 2003-12-11 | Asaf Wexler | Transparent proxy server |
US6804778B1 (en) * | 1999-04-15 | 2004-10-12 | Gilian Technologies, Ltd. | Data quality assurance |
US8200837B1 (en) * | 1999-04-26 | 2012-06-12 | Hewlett-Packard Development Company, L.P. | Method and system for maintaining a content server at safe load conditions |
EP1049307A1 (en) * | 1999-04-29 | 2000-11-02 | International Business Machines Corporation | Method and system for dispatching client sessions within a cluster of servers connected to the World Wide Web |
US8099758B2 (en) | 1999-05-12 | 2012-01-17 | Microsoft Corporation | Policy based composite file system and method |
US7305473B2 (en) * | 1999-05-28 | 2007-12-04 | The Coca-Cola Company | Provision of transparent proxy services to a user of a client device |
US7146505B1 (en) * | 1999-06-01 | 2006-12-05 | America Online, Inc. | Secure data exchange between date processing systems |
US6751191B1 (en) | 1999-06-29 | 2004-06-15 | Cisco Technology, Inc. | Load sharing and redundancy scheme |
US6650641B1 (en) * | 1999-07-02 | 2003-11-18 | Cisco Technology, Inc. | Network address translation using a forwarding agent |
US6970933B1 (en) * | 1999-07-15 | 2005-11-29 | F5 Networks, Inc. | Enabling application level persistence between a server and another resource over a network |
US7346695B1 (en) | 2002-10-28 | 2008-03-18 | F5 Networks, Inc. | System and method for performing application level persistence |
US7287084B1 (en) | 1999-07-15 | 2007-10-23 | F5 Networks, Inc. | Enabling encryption of application level persistence between a server and a client |
US6567857B1 (en) * | 1999-07-29 | 2003-05-20 | Sun Microsystems, Inc. | Method and apparatus for dynamic proxy insertion in network traffic flow |
US6735741B1 (en) * | 1999-07-30 | 2004-05-11 | International Business Machines Corporation | Method system, and program for dynamic resource linking when copies are maintained at different storage locations |
US6606650B2 (en) * | 1999-08-30 | 2003-08-12 | Nortel Networks Limited | Bump in the wire transparent internet protocol |
USRE44207E1 (en) | 1999-09-01 | 2013-05-07 | Esdr Network Solutions Llc | Network resource access method, product, and apparatus |
US6594260B1 (en) * | 1999-09-03 | 2003-07-15 | Cisco Technology, Inc. | Content routing |
US7831512B2 (en) | 1999-09-21 | 2010-11-09 | Quantumstream Systems, Inc. | Content distribution system and method |
US9451310B2 (en) | 1999-09-21 | 2016-09-20 | Quantum Stream Inc. | Content distribution system and method |
US6877036B1 (en) * | 1999-09-24 | 2005-04-05 | Akamba Corporation | System and method for managing connections between a client and a server |
FR2800224B1 (en) * | 1999-10-21 | 2002-12-27 | Ibm | METHOD AND SYSTEM FOR CATCHING HTTP DATA TRANSPORTED WITH SOCKS DATA IN IP DATAGRAMS |
US6792463B1 (en) * | 1999-10-21 | 2004-09-14 | International Business Machines Corporation | System, method and program product for providing invisibility to a proxy-server |
US6760771B1 (en) * | 1999-10-21 | 2004-07-06 | International Business Machines Corporation | Method and system for optimally dispatching internetwork traffic |
ES2320724T3 (en) | 1999-10-22 | 2009-05-28 | Nomadix, Inc. | SYSTEMS AND PROCEDURES FOR THE DYNAMIC MANAGEMENT OF THE BANDWIDTH BY PAYABLE IN A COMMUNICATIONS NETWORK. |
US7401115B1 (en) * | 2000-10-23 | 2008-07-15 | Aol Llc | Processing selected browser requests |
AU1224101A (en) | 1999-10-22 | 2001-05-08 | Nomadix, Inc. | Gateway device having an xml interface and associated method |
US7136930B1 (en) * | 1999-11-05 | 2006-11-14 | Nokia Corporation | System and method for effective use of air link between mobile stations and gateway servers |
JP3463803B2 (en) * | 1999-11-09 | 2003-11-05 | 松下電器産業株式会社 | Cluster server device |
US6697856B1 (en) * | 1999-11-19 | 2004-02-24 | Cisco Technology, Inc. | Healing of incomplete circuits in networks |
US6694358B1 (en) * | 1999-11-22 | 2004-02-17 | Speedera Networks, Inc. | Performance computer network method |
US6405252B1 (en) * | 1999-11-22 | 2002-06-11 | Speedera Networks, Inc. | Integrated point of presence server network |
US7051103B1 (en) * | 1999-11-25 | 2006-05-23 | International Business Machines Corporation | Method and system for providing SNA access to telnet 3270 and telnet 3270 enhanced services over wide area networks |
EP1104133A1 (en) * | 1999-11-29 | 2001-05-30 | BRITISH TELECOMMUNICATIONS public limited company | Network access arrangement |
US6683873B1 (en) * | 1999-12-27 | 2004-01-27 | Cisco Technology, Inc. | Methods and apparatus for redirecting network traffic |
US6983330B1 (en) * | 1999-12-29 | 2006-01-03 | Emc Corporation | Method and apparatus for using multiple paths for processing out of band commands |
US20010030977A1 (en) * | 1999-12-30 | 2001-10-18 | May Lauren T. | Proxy methods for IP address assignment and universal access mechanism |
US7069432B1 (en) * | 2000-01-04 | 2006-06-27 | Cisco Technology, Inc. | System and method for providing security in a telecommunication network |
US7006494B1 (en) | 2000-01-04 | 2006-02-28 | Cisco Technology, Inc. | System and method for a virtual telephony intermediary |
US7079495B1 (en) | 2000-01-04 | 2006-07-18 | Cisco Technology, Inc. | System and method for enabling multicast telecommunications |
US6804254B1 (en) | 2000-01-04 | 2004-10-12 | Cisco Technology, Inc. | System and method for maintaining a communication link |
US7954144B1 (en) * | 2000-01-18 | 2011-05-31 | Novell, Inc. | Brokering state information and identity among user agents, origin servers, and proxies |
US6839829B1 (en) | 2000-01-18 | 2005-01-04 | Cisco Technology, Inc. | Routing protocol based redundancy design for shared-access networks |
US7058007B1 (en) | 2000-01-18 | 2006-06-06 | Cisco Technology, Inc. | Method for a cable modem to rapidly switch to a backup CMTS |
JP2001202345A (en) * | 2000-01-21 | 2001-07-27 | Hitachi Ltd | Parallel processor |
US7072933B1 (en) * | 2000-01-24 | 2006-07-04 | Microsoft Corporation | Network access control using network address translation |
US7925693B2 (en) * | 2000-01-24 | 2011-04-12 | Microsoft Corporation | NAT access control with IPSec |
US6671757B1 (en) | 2000-01-26 | 2003-12-30 | Fusionone, Inc. | Data transfer and synchronization system |
US6694336B1 (en) * | 2000-01-25 | 2004-02-17 | Fusionone, Inc. | Data transfer and synchronization system |
US8620286B2 (en) | 2004-02-27 | 2013-12-31 | Synchronoss Technologies, Inc. | Method and system for promoting and transferring licensed content and applications |
US7505762B2 (en) * | 2004-02-27 | 2009-03-17 | Fusionone, Inc. | Wireless telephone data backup system |
US8156074B1 (en) | 2000-01-26 | 2012-04-10 | Synchronoss Technologies, Inc. | Data transfer and synchronization system |
US6934761B1 (en) | 2000-02-25 | 2005-08-23 | Sun Microsystems, Inc. | User level web server cache control of in-kernel http cache |
US7266555B1 (en) | 2000-03-03 | 2007-09-04 | Intel Corporation | Methods and apparatus for accessing remote storage through use of a local device |
US6952737B1 (en) * | 2000-03-03 | 2005-10-04 | Intel Corporation | Method and apparatus for accessing remote storage in a distributed storage cluster architecture |
US7506034B2 (en) * | 2000-03-03 | 2009-03-17 | Intel Corporation | Methods and apparatus for off loading content servers through direct file transfer from a storage center to an end-user |
US7203731B1 (en) * | 2000-03-03 | 2007-04-10 | Intel Corporation | Dynamic replication of files in a network storage system |
US7281168B1 (en) | 2000-03-03 | 2007-10-09 | Intel Corporation | Failover architecture for local devices that access remote storage |
US7428540B1 (en) | 2000-03-03 | 2008-09-23 | Intel Corporation | Network storage system |
US7930285B2 (en) | 2000-03-22 | 2011-04-19 | Comscore, Inc. | Systems for and methods of user demographic reporting usable for identifying users and collecting usage data |
US7493655B2 (en) * | 2000-03-22 | 2009-02-17 | Comscore Networks, Inc. | Systems for and methods of placing user identification in the header of data packets usable in user demographic reporting and collecting usage data |
US7650376B1 (en) * | 2000-03-27 | 2010-01-19 | Blumenau Trevor I | Content distribution system for distributing content over a network, with particular applicability to distributing high-bandwidth content |
US7177901B1 (en) * | 2000-03-27 | 2007-02-13 | International Business Machines Corporation | Method, system, and computer program product to redirect requests from content servers to load distribution servers and to correct bookmarks |
US7266604B1 (en) * | 2000-03-31 | 2007-09-04 | Microsoft Corporation | Proxy network address translation |
US7123613B1 (en) * | 2000-04-07 | 2006-10-17 | Sun Microsystems, Inc. | Apparatus and method for providing a transparent proxy server |
US8510468B2 (en) * | 2000-04-17 | 2013-08-13 | Ciradence Corporation | Route aware network link acceleration |
US6996616B1 (en) * | 2000-04-17 | 2006-02-07 | Akamai Technologies, Inc. | HTML delivery from edge-of-network servers in a content delivery network (CDN) |
US7043563B2 (en) | 2000-04-17 | 2006-05-09 | Circadence Corporation | Method and system for redirection to arbitrary front-ends in a communication system |
US8996705B2 (en) | 2000-04-17 | 2015-03-31 | Circadence Corporation | Optimization of enhanced network links |
US20110128972A1 (en) | 2000-04-17 | 2011-06-02 | Randy Thornton | Peer to peer dynamic network link acceleration |
US6965924B1 (en) * | 2000-04-26 | 2005-11-15 | Hewlett-Packard Development Company, L.P. | Method and system for transparent file proxying |
US6742044B1 (en) * | 2000-05-10 | 2004-05-25 | Cisco Technology, Inc. | Distributed network traffic load balancing technique implemented without gateway router |
US6662270B1 (en) * | 2000-05-16 | 2003-12-09 | Xerox Corporation | System and method for caching of reusable objects |
US7509490B1 (en) | 2000-05-26 | 2009-03-24 | Symantec Corporation | Method and apparatus for encrypted communications to a secure server |
US7673329B2 (en) * | 2000-05-26 | 2010-03-02 | Symantec Corporation | Method and apparatus for encrypted communications to a secure server |
US6879998B1 (en) | 2000-06-01 | 2005-04-12 | Aerocast.Com, Inc. | Viewer object proxy |
US6850980B1 (en) * | 2000-06-16 | 2005-02-01 | Cisco Technology, Inc. | Content routing service protocol |
US8204082B2 (en) | 2000-06-23 | 2012-06-19 | Cloudshield Technologies, Inc. | Transparent provisioning of services over a network |
US6829654B1 (en) * | 2000-06-23 | 2004-12-07 | Cloudshield Technologies, Inc. | Apparatus and method for virtual edge placement of web sites |
US7114008B2 (en) * | 2000-06-23 | 2006-09-26 | Cloudshield Technologies, Inc. | Edge adapter architecture apparatus and method |
US7003555B1 (en) | 2000-06-23 | 2006-02-21 | Cloudshield Technologies, Inc. | Apparatus and method for domain name resolution |
US7032031B2 (en) * | 2000-06-23 | 2006-04-18 | Cloudshield Technologies, Inc. | Edge adapter apparatus and method |
US9444785B2 (en) | 2000-06-23 | 2016-09-13 | Cloudshield Technologies, Inc. | Transparent provisioning of network access to an application |
US6704781B1 (en) * | 2000-06-27 | 2004-03-09 | Intel Corporation | System and method for content caching implementing compensation for providing caching services |
US6910063B1 (en) * | 2000-06-28 | 2005-06-21 | Microsoft Corporation | System and method of enhancing web server throughput in single and multiple processor systems |
US7062571B1 (en) * | 2000-06-30 | 2006-06-13 | Cisco Technology, Inc. | Efficient IP load-balancing traffic distribution using ternary CAMs |
US7020709B1 (en) | 2000-06-30 | 2006-03-28 | Intel Corporation | System and method for fault tolerant stream splitting |
US20020013831A1 (en) * | 2000-06-30 | 2002-01-31 | Arto Astala | System having mobile terminals with wireless access to the internet and method for doing same |
US7318107B1 (en) | 2000-06-30 | 2008-01-08 | Intel Corporation | System and method for automatic stream fail-over |
CA2313802A1 (en) * | 2000-07-11 | 2002-01-11 | Michael Corcoran | Dynamic web page caching system and method |
US7895334B1 (en) | 2000-07-19 | 2011-02-22 | Fusionone, Inc. | Remote access communication architecture apparatus and method |
US8073954B1 (en) | 2000-07-19 | 2011-12-06 | Synchronoss Technologies, Inc. | Method and apparatus for a secure remote access system |
US6829638B1 (en) * | 2000-08-03 | 2004-12-07 | International Business Machines Corporation | System and method for managing multiple proxy servers |
FR2812991B1 (en) * | 2000-08-08 | 2003-01-24 | France Telecom | TRANSLATION OF USER INSTALLATION TERMINAL IDENTIFIERS IN A PACKET NETWORK |
US7571217B1 (en) * | 2000-08-16 | 2009-08-04 | Parallel Networks, Llc | Method and system for uniform resource locator transformation |
US20020026507A1 (en) * | 2000-08-30 | 2002-02-28 | Sears Brent C. | Browser proxy client application service provider (ASP) interface |
US7028091B1 (en) * | 2000-08-31 | 2006-04-11 | Sun Microsystems, Inc. | Web server in-kernel interface to data transport system and cache manager |
US7720903B1 (en) * | 2000-08-31 | 2010-05-18 | Intel Corporation | Client messaging in multicast networks |
US6807572B1 (en) * | 2000-08-31 | 2004-10-19 | Intel Corporation | Accessing network databases |
US9130954B2 (en) * | 2000-09-26 | 2015-09-08 | Brocade Communications Systems, Inc. | Distributed health check for global server load balancing |
US7454500B1 (en) | 2000-09-26 | 2008-11-18 | Foundry Networks, Inc. | Global server load balancing |
US7657629B1 (en) * | 2000-09-26 | 2010-02-02 | Foundry Networks, Inc. | Global server load balancing |
US7562147B1 (en) * | 2000-10-02 | 2009-07-14 | Microsoft Corporation | Bi-directional HTTP-based reliable messaging protocol and system utilizing same |
US6865605B1 (en) * | 2000-10-04 | 2005-03-08 | Microsoft Corporation | System and method for transparently redirecting client requests for content using a front-end indicator to preserve the validity of local caching at the client system |
US6823391B1 (en) * | 2000-10-04 | 2004-11-23 | Microsoft Corporation | Routing client requests to back-end servers |
US7203741B2 (en) | 2000-10-12 | 2007-04-10 | Peerapp Ltd. | Method and system for accelerating receipt of data in a client-to-client network |
US7801978B1 (en) * | 2000-10-18 | 2010-09-21 | Citrix Systems, Inc. | Apparatus, method and computer program product for efficiently pooling connections between clients and servers |
US7788407B1 (en) | 2000-10-21 | 2010-08-31 | Cisco Technology, Inc. | Apparatus and methods for providing an application level gateway for use in networks |
US7792676B2 (en) * | 2000-10-25 | 2010-09-07 | Robert Glenn Klinefelter | System, method, and apparatus for providing interpretive communication on a network |
JP2002140309A (en) * | 2000-11-02 | 2002-05-17 | Hitachi Ltd | Service system |
US7587446B1 (en) | 2000-11-10 | 2009-09-08 | Fusionone, Inc. | Acquisition and synchronization of digital media to a personal information space |
US7739398B1 (en) * | 2000-11-21 | 2010-06-15 | Avaya Inc. | Dynamic load balancer |
AU2002232423A1 (en) * | 2000-11-22 | 2002-06-24 | Azoth Technologies, Inc. | Method, architecture, and apparatus for dynamic content translation and switching |
US6665642B2 (en) * | 2000-11-29 | 2003-12-16 | Ibm Corporation | Transcoding system and method for improved access by users with special needs |
US7313600B1 (en) * | 2000-11-30 | 2007-12-25 | Cisco Technology, Inc. | Arrangement for emulating an unlimited number of IP devices without assignment of IP addresses |
US20020069241A1 (en) * | 2000-12-06 | 2002-06-06 | Girija Narlikar | Method and apparatus for client-side proxy selection |
US7818435B1 (en) * | 2000-12-14 | 2010-10-19 | Fusionone, Inc. | Reverse proxy mechanism for retrieving electronic content associated with a local network |
US8452850B2 (en) * | 2000-12-14 | 2013-05-28 | International Business Machines Corporation | Method, apparatus and computer program product to crawl a web site |
US6850982B1 (en) * | 2000-12-19 | 2005-02-01 | Cisco Technology, Inc. | Methods and apparatus for directing a flow of data between a client and multiple servers |
US6697206B2 (en) * | 2000-12-19 | 2004-02-24 | Imation Corp. | Tape edge monitoring |
US7421505B2 (en) * | 2000-12-21 | 2008-09-02 | Noatak Software Llc | Method and system for executing protocol stack instructions to form a packet for causing a computing device to perform an operation |
US20020116605A1 (en) * | 2000-12-21 | 2002-08-22 | Berg Mitchell T. | Method and system for initiating execution of software in response to a state |
US7512686B2 (en) * | 2000-12-21 | 2009-03-31 | Berg Mitchell T | Method and system for establishing a data structure of a connection with a client |
US7546369B2 (en) * | 2000-12-21 | 2009-06-09 | Berg Mitchell T | Method and system for communicating a request packet in response to a state |
US20020116397A1 (en) * | 2000-12-21 | 2002-08-22 | Berg Mitchell T. | Method and system for communicating an information packet through multiple router devices |
US7287090B1 (en) * | 2000-12-21 | 2007-10-23 | Noatak Software, Llc | Method and system for identifying a computing device in response to a request packet |
US20020116532A1 (en) * | 2000-12-21 | 2002-08-22 | Berg Mitchell T. | Method and system for communicating an information packet and identifying a data structure |
JP3760767B2 (en) * | 2000-12-21 | 2006-03-29 | 株式会社日立製作所 | Network management apparatus and network management method |
US7418522B2 (en) * | 2000-12-21 | 2008-08-26 | Noatak Software Llc | Method and system for communicating an information packet through multiple networks |
US7266556B1 (en) | 2000-12-29 | 2007-09-04 | Intel Corporation | Failover architecture for a distributed storage system |
US6651141B2 (en) | 2000-12-29 | 2003-11-18 | Intel Corporation | System and method for populating cache servers with popular media contents |
US20020087722A1 (en) * | 2000-12-29 | 2002-07-04 | Ragula Systems D/B/A/ Fatpipe Networks | Domain name resolution making IP address selections in response to connection status when multiple connections are present |
US7096266B2 (en) * | 2001-01-08 | 2006-08-22 | Akamai Technologies, Inc. | Extending an Internet content delivery network into an enterprise |
US7254237B1 (en) * | 2001-01-12 | 2007-08-07 | Slt Logic, Llc | System and method for establishing a secure connection |
US20020107910A1 (en) * | 2001-02-02 | 2002-08-08 | Yan Zhao | Client/server two-way communication system framework under HTTP protocol |
US20030235206A1 (en) * | 2001-02-15 | 2003-12-25 | Tantivy Communications, Inc. | Dual proxy approach to TCP performance improvements over a wireless interface |
US20020120782A1 (en) * | 2001-02-26 | 2002-08-29 | Douglas Dillon | Transparent proxying enhancement |
US20020138596A1 (en) * | 2001-03-09 | 2002-09-26 | Matthew Darwin | Method to proxy IP services |
US7509435B2 (en) * | 2001-03-12 | 2009-03-24 | International Business Machines Corporation | Network Address Translation and Port Mapping |
JP2002278903A (en) * | 2001-03-15 | 2002-09-27 | Sony Corp | Information processor, information processing method, recording medium and program |
US7499888B1 (en) | 2001-03-16 | 2009-03-03 | Fusionone, Inc. | Transaction authentication system and method |
DE60110744D1 (en) * | 2001-03-23 | 2005-06-16 | Sun Microsystems Inc | Client query redirection |
US8615566B1 (en) | 2001-03-23 | 2013-12-24 | Synchronoss Technologies, Inc. | Apparatus and method for operational support of remote network systems |
US7149797B1 (en) * | 2001-04-02 | 2006-12-12 | Akamai Technologies, Inc. | Content delivery network service provider (CDNSP)-managed content delivery network (CDN) for network service provider (NSP) |
US20020156841A1 (en) * | 2001-04-13 | 2002-10-24 | Bjorn Landfeldt | Accessing distributed proxy configurations |
US7200679B2 (en) * | 2001-04-13 | 2007-04-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Creating distributed proxy configurations |
JP4352630B2 (en) * | 2001-04-27 | 2009-10-28 | 沖電気工業株式会社 | Connection proxy device |
US8572278B2 (en) * | 2001-04-30 | 2013-10-29 | Facebook, Inc. | Generating multiple data streams from a single data source |
US7124173B2 (en) * | 2001-04-30 | 2006-10-17 | Moriarty Kathleen M | Method and apparatus for intercepting performance metric packets for improved security and intrusion detection |
US7237033B2 (en) * | 2001-04-30 | 2007-06-26 | Aol Llc | Duplicating switch for streaming data units to a terminal |
WO2003105006A1 (en) * | 2001-04-30 | 2003-12-18 | America Online, Inc. | Load balancing with direct terminal response |
US7124166B2 (en) | 2001-04-30 | 2006-10-17 | Aol Llc | Duplicating digital streams for digital conferencing using switching technologies |
JP3493660B2 (en) * | 2001-05-16 | 2004-02-03 | 日本電気株式会社 | Protocol conversion device, protocol conversion method thereof, and protocol conversion program |
US8019807B2 (en) * | 2001-05-23 | 2011-09-13 | Wireless Enterprise Solutions Technology Limited | Method and system for communication between computer systems |
WO2002098100A1 (en) * | 2001-05-31 | 2002-12-05 | Preventon Technologies Limited | Access control systems |
US7730528B2 (en) * | 2001-06-01 | 2010-06-01 | Symantec Corporation | Intelligent secure data manipulation apparatus and method |
US7624184B1 (en) * | 2001-06-06 | 2009-11-24 | Cisco Technology, Inc. | Methods and apparatus for managing access to data through a network device |
US20020188730A1 (en) * | 2001-06-12 | 2002-12-12 | Wenting Tang | Method and system for a modular transmission control protocol (TCP) frequent-handoff design in a streams based transmission control protocol internet protocol (TCP/IP) implementation |
US20030009561A1 (en) * | 2001-06-14 | 2003-01-09 | Sollee Patrick N. | Providing telephony services to terminals behind a firewall and /or network address translator |
US7068655B2 (en) * | 2001-06-14 | 2006-06-27 | Nortel Networks Limited | Network address and/or port translation |
US7881208B1 (en) | 2001-06-18 | 2011-02-01 | Cisco Technology, Inc. | Gateway load balancing protocol |
KR100405113B1 (en) * | 2001-06-22 | 2003-11-10 | 주식회사 엑스큐어넷 | Method for implementing transparent gateway or proxy in a network |
US8041814B2 (en) * | 2001-06-28 | 2011-10-18 | International Business Machines Corporation | Method, system and computer program product for hierarchical load balancing |
US7908472B2 (en) * | 2001-07-06 | 2011-03-15 | Juniper Networks, Inc. | Secure sockets layer cut through architecture |
US7853781B2 (en) * | 2001-07-06 | 2010-12-14 | Juniper Networks, Inc. | Load balancing secure sockets layer accelerator |
US7228412B2 (en) * | 2001-07-06 | 2007-06-05 | Juniper Networks, Inc. | Bufferless secure sockets layer architecture |
US7149892B2 (en) * | 2001-07-06 | 2006-12-12 | Juniper Networks, Inc. | Secure sockets layer proxy architecture |
US6918013B2 (en) * | 2001-07-16 | 2005-07-12 | Bea Systems, Inc. | System and method for flushing bean cache |
US7409420B2 (en) * | 2001-07-16 | 2008-08-05 | Bea Systems, Inc. | Method and apparatus for session replication and failover |
US7702791B2 (en) * | 2001-07-16 | 2010-04-20 | Bea Systems, Inc. | Hardware load-balancing apparatus for session replication |
US20030023898A1 (en) * | 2001-07-16 | 2003-01-30 | Jacobs Dean Bernard | Layered architecture for data replication |
US7571215B2 (en) * | 2001-07-16 | 2009-08-04 | Bea Systems, Inc. | Data replication protocol |
US6981029B1 (en) * | 2001-07-17 | 2005-12-27 | Cisco Technology, Inc. | System and method for processing a request for information in a network |
US7774492B2 (en) * | 2001-07-26 | 2010-08-10 | Citrix Systems, Inc. | System, method and computer program product to maximize server throughput while avoiding server overload by controlling the rate of establishing server-side net work connections |
US7543067B2 (en) * | 2001-08-01 | 2009-06-02 | Canon Kabushiki Kaisha | Flexible secure network data transfer and messaging |
US7398314B2 (en) * | 2001-08-08 | 2008-07-08 | Flash Networks Ltd | System and a method for accelerating communication of TCP/IP based content through the use of fake host names |
US7028030B2 (en) * | 2001-08-30 | 2006-04-11 | Bea Systems, Inc. | Cluster caching with concurrency checking |
US20030046230A1 (en) * | 2001-08-30 | 2003-03-06 | Jacobs Dean Bernard | Method for maintaining account consistency |
US20030046419A1 (en) * | 2001-08-31 | 2003-03-06 | King Peter F. | Stateful load balancing |
US6826601B2 (en) | 2001-09-06 | 2004-11-30 | Bea Systems, Inc. | Exactly one cache framework |
AU2002332845B2 (en) * | 2001-09-06 | 2008-06-12 | Oracle International Corporation | Exactly once cache framework |
US7113980B2 (en) * | 2001-09-06 | 2006-09-26 | Bea Systems, Inc. | Exactly once JMS communication |
CN1158615C (en) * | 2001-09-06 | 2004-07-21 | 华为技术有限公司 | Load balancing method and equipment for convective medium server |
US7475157B1 (en) * | 2001-09-14 | 2009-01-06 | Swsoft Holding, Ltd. | Server load balancing system |
US7089312B2 (en) * | 2001-09-20 | 2006-08-08 | Intel Corporation | System and method for reducing retransmissions due to tunneled TCP-in-TCP communication in a network |
JP4053269B2 (en) * | 2001-09-27 | 2008-02-27 | 株式会社東芝 | Data transfer apparatus and data transfer method |
US6839758B2 (en) * | 2001-09-28 | 2005-01-04 | Intel Corporation | Network processor for cache array routing |
US7155478B2 (en) * | 2001-10-03 | 2006-12-26 | International Business Machines Corporation | Selectively handling data processing requests in a computer communications network |
JP2003122658A (en) * | 2001-10-11 | 2003-04-25 | Hitachi Ltd | Data distribution method |
US20030093566A1 (en) * | 2001-11-09 | 2003-05-15 | Jardin Cary A. | System and method for network and application transparent database acceleration |
US7149809B2 (en) * | 2001-11-13 | 2006-12-12 | One Touch Systems | System for reducing server loading during content delivery |
US7650420B2 (en) * | 2001-12-28 | 2010-01-19 | The Directv Group, Inc. | System and method for content filtering |
US8090866B1 (en) * | 2002-01-18 | 2012-01-03 | Cisco Technology, Inc. | TCP proxy connection management in a gigabit environment |
US7930704B2 (en) * | 2002-02-06 | 2011-04-19 | Oracle International Corporation | J2EE component extension architecture |
US20030149755A1 (en) * | 2002-02-06 | 2003-08-07 | Emek Sadot | Client-controlled load balancer |
AU2003216332A1 (en) * | 2002-02-21 | 2003-09-09 | Bea Systems, Inc. | System and method for message driven bean service migration |
US7392302B2 (en) * | 2002-02-21 | 2008-06-24 | Bea Systems, Inc. | Systems and methods for automated service migration |
US7178050B2 (en) * | 2002-02-22 | 2007-02-13 | Bea Systems, Inc. | System for highly available transaction recovery for transaction processing systems |
US7617289B2 (en) * | 2002-02-22 | 2009-11-10 | Bea Systems, Inc. | System and method for using a data replication service to manage a configuration repository |
US7152181B2 (en) * | 2002-02-22 | 2006-12-19 | Bea Systems, Inc. | Method for highly available transaction recovery for transaction processing systems |
US8224986B1 (en) * | 2002-03-07 | 2012-07-17 | Cisco Technology, Inc. | Methods and apparatus for redirecting requests for content |
US7313635B1 (en) * | 2002-03-21 | 2007-12-25 | Cisco Technology | Method and apparatus for simulating a load on an application server in a network |
WO2003083692A1 (en) * | 2002-03-27 | 2003-10-09 | First Virtual Communications | System and method for traversing firewalls with protocol communications |
ATE316312T1 (en) | 2002-04-05 | 2006-02-15 | TRANSMISSION CONTROL FOR OBJECTS IN A COMMUNICATIONS NETWORK | |
US7133905B2 (en) * | 2002-04-09 | 2006-11-07 | Akamai Technologies, Inc. | Method and system for tiered distribution in a content delivery network |
US7640347B1 (en) * | 2002-05-02 | 2009-12-29 | F5 Networks, Inc. | Method and system for inserting POST data into the GET request to apply normal caching rules |
US7676579B2 (en) * | 2002-05-13 | 2010-03-09 | Sony Computer Entertainment America Inc. | Peer to peer network communication |
US7437451B2 (en) * | 2002-05-16 | 2008-10-14 | Hewlett-Packard Development Company, L.P. | System and method for collecting desired information for network transactions at the kernel level |
US8392499B2 (en) * | 2002-05-16 | 2013-03-05 | Hewlett-Packard Development Company, L.P. | System and method for relating aborted client accesses of data to quality of service provided by a server in a client-server network |
US7487508B2 (en) * | 2002-05-16 | 2009-02-03 | Hewlett-Packard Development Company, L.P. | System and method for reconstructing client web page accesses from captured network packets |
WO2003105010A1 (en) | 2002-06-06 | 2003-12-18 | Neoteris, Inc. | Method and system for providing secure access to private networks |
US20030229846A1 (en) * | 2002-06-07 | 2003-12-11 | Anil Sethi | System and method for capturing digital data directly from an electronic device and processing the data into XML form on a computer chip |
US7173933B1 (en) * | 2002-06-10 | 2007-02-06 | Cisco Technology, Inc. | System and method for providing source awareness in a network environment |
US20030233470A1 (en) * | 2002-06-12 | 2003-12-18 | International Business Machines Corporation | Network storage data redirection |
US8028092B2 (en) | 2002-06-28 | 2011-09-27 | Aol Inc. | Inserting advertising content |
WO2004006115A1 (en) * | 2002-07-02 | 2004-01-15 | Netscaler, Inc | System, method and computer program product to avoid server overload by controlling http denial of service (dos) attacks |
US8370420B1 (en) * | 2002-07-11 | 2013-02-05 | Citrix Systems, Inc. | Web-integrated display of locally stored content objects |
US7506342B2 (en) * | 2002-07-23 | 2009-03-17 | Bea Systems, Inc. | System and method for implementing J2EE connector architecture |
US8060626B2 (en) | 2008-09-22 | 2011-11-15 | Sony Computer Entertainment America Llc. | Method for host selection based on discovered NAT type |
US8224985B2 (en) * | 2005-10-04 | 2012-07-17 | Sony Computer Entertainment Inc. | Peer-to-peer communication traversing symmetric network address translators |
US7676576B1 (en) | 2002-08-01 | 2010-03-09 | Foundry Networks, Inc. | Method and system to clear counters used for statistical tracking for global server load balancing |
US7086061B1 (en) | 2002-08-01 | 2006-08-01 | Foundry Networks, Inc. | Statistical tracking of global server load balancing for selecting the best network address from ordered list of network addresses based on a set of performance metrics |
US7574508B1 (en) | 2002-08-07 | 2009-08-11 | Foundry Networks, Inc. | Canonical name (CNAME) handling for global server load balancing |
US7571206B2 (en) * | 2002-08-12 | 2009-08-04 | Equallogic, Inc. | Transparent request routing for a partitioned application service |
US7698434B2 (en) * | 2002-08-29 | 2010-04-13 | Bea Systems, Inc. | J2EE connector architecture |
US7430755B1 (en) | 2002-09-03 | 2008-09-30 | Fs Networks, Inc. | Method and system for providing persistence in a secure network access |
US7058633B1 (en) * | 2002-09-09 | 2006-06-06 | Cisco Technology, Inc. | System and method for generalized URL-rewriting |
JP3445986B1 (en) * | 2002-09-27 | 2003-09-16 | 松下電器産業株式会社 | Servers, devices and communication systems connected to the Internet |
US7774325B2 (en) * | 2002-10-17 | 2010-08-10 | Intel Corporation | Distributed network attached storage system |
US7302674B1 (en) * | 2002-11-26 | 2007-11-27 | Unisys Corporation | Automating document reviews in a project management system |
US7386619B1 (en) * | 2003-01-06 | 2008-06-10 | Slt Logic, Llc | System and method for allocating communications to processors in a multiprocessor system |
US7114006B2 (en) | 2003-01-06 | 2006-09-26 | International Business Machines Corporation | Apparatus and method to remotely change IP address of server |
US7082526B2 (en) | 2003-03-14 | 2006-07-25 | Elegent Technologies, Inc. | Mechanism for intuitively invoking one or more auxiliary programs during a computer booting process |
US7305479B1 (en) | 2003-05-13 | 2007-12-04 | Cisco Technology, Inc. | Methods and apparatus for delivery of content requests within a content delivery network |
US7760729B2 (en) * | 2003-05-28 | 2010-07-20 | Citrix Systems, Inc. | Policy based network address translation |
US6889160B2 (en) * | 2003-05-30 | 2005-05-03 | Hewlett-Packard Development Company, L.P. | Simulation of network service test environments |
US8352588B2 (en) * | 2003-07-09 | 2013-01-08 | Hewlett-Packard Development Company, L.P. | Systems and methods for collecting data regarding network service operation |
WO2005010715A2 (en) | 2003-07-21 | 2005-02-03 | Fusionone, Inc. | Device message management system |
US7493387B2 (en) * | 2003-09-19 | 2009-02-17 | International Business Machines Corporation | Validating software in a grid environment using ghost agents |
US7516443B2 (en) * | 2003-09-19 | 2009-04-07 | International Business Machines Corporation | Performing tests with ghost agents |
US9584360B2 (en) * | 2003-09-29 | 2017-02-28 | Foundry Networks, Llc | Global server load balancing support for private VIP addresses |
US7447797B2 (en) * | 2003-10-29 | 2008-11-04 | International Business Machines Corporation | Method and system for processing a service request associated with a particular priority level of service in a network data processing system using parallel proxies |
US7564792B2 (en) * | 2003-11-05 | 2009-07-21 | Juniper Networks, Inc. | Transparent optimization for transmission control protocol flow control |
US7058058B2 (en) | 2003-11-05 | 2006-06-06 | Juniper Networks, Inc. | Transparent optimization for transmission control protocol initial session establishment |
US7634509B2 (en) * | 2003-11-07 | 2009-12-15 | Fusionone, Inc. | Personal information space management system and method |
US7978716B2 (en) | 2003-11-24 | 2011-07-12 | Citrix Systems, Inc. | Systems and methods for providing a VPN solution |
TWI241102B (en) * | 2003-12-30 | 2005-10-01 | Icp Electronics Inc | System for actively updating encryption/decryption module in security gateway and method |
US7584301B1 (en) * | 2004-05-06 | 2009-09-01 | Foundry Networks, Inc. | Host-level policies for global server load balancing |
US7496651B1 (en) | 2004-05-06 | 2009-02-24 | Foundry Networks, Inc. | Configurable geographic prefixes for global server load balancing |
EP1759521B1 (en) | 2004-05-12 | 2016-06-29 | Synchronoss Technologies, Inc. | Advanced contact identification system |
US9542076B1 (en) | 2004-05-12 | 2017-01-10 | Synchronoss Technologies, Inc. | System for and method of updating a personal profile |
US8739274B2 (en) * | 2004-06-30 | 2014-05-27 | Citrix Systems, Inc. | Method and device for performing integrated caching in a data communication network |
US8495305B2 (en) * | 2004-06-30 | 2013-07-23 | Citrix Systems, Inc. | Method and device for performing caching of dynamically generated objects in a data communication network |
US7757074B2 (en) | 2004-06-30 | 2010-07-13 | Citrix Application Networking, Llc | System and method for establishing a virtual private network |
US7827558B2 (en) * | 2004-06-30 | 2010-11-02 | Devicevm, Inc. | Mechanism for enabling a program to be executed while the execution of an operating system is suspended |
US7921226B2 (en) * | 2004-07-20 | 2011-04-05 | Alcatel-Lucent Usa Inc. | User specific request redirection in a content delivery network |
US7509422B2 (en) * | 2004-07-21 | 2009-03-24 | Microsoft Corporation | System and method for locating web services |
CN101199187A (en) | 2004-07-23 | 2008-06-11 | 茨特里克斯系统公司 | A method and systems for securing remote access to private networks |
US7808906B2 (en) | 2004-07-23 | 2010-10-05 | Citrix Systems, Inc. | Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgements |
US7423977B1 (en) * | 2004-08-23 | 2008-09-09 | Foundry Networks Inc. | Smoothing algorithm for round trip time (RTT) measurements |
US8224966B2 (en) * | 2004-08-24 | 2012-07-17 | Cisco Technology, Inc. | Reproxying an unproxied connection |
US20070254727A1 (en) * | 2004-09-08 | 2007-11-01 | Pat Sewall | Hotspot Power Regulation |
US8732808B2 (en) * | 2004-09-08 | 2014-05-20 | Cradlepoint, Inc. | Data plan activation and modification |
US9584406B2 (en) * | 2004-09-08 | 2017-02-28 | Cradlepoint, Inc. | Data path switching |
US9294353B2 (en) * | 2004-09-08 | 2016-03-22 | Cradlepoint, Inc. | Configuring a wireless router |
US9232461B2 (en) * | 2004-09-08 | 2016-01-05 | Cradlepoint, Inc. | Hotspot communication limiter |
US7764784B2 (en) * | 2004-09-08 | 2010-07-27 | Cradlepoint, Inc. | Handset cradle |
US20090172658A1 (en) * | 2004-09-08 | 2009-07-02 | Steven Wood | Application installation |
US8477639B2 (en) | 2004-09-08 | 2013-07-02 | Cradlepoint, Inc. | Communicating network status |
US8249052B2 (en) * | 2004-09-08 | 2012-08-21 | Cradlepoint, Inc. | Automated access of an enhanced command set |
US9237102B2 (en) * | 2004-09-08 | 2016-01-12 | Cradlepoint, Inc. | Selecting a data path |
US7962569B2 (en) * | 2004-09-08 | 2011-06-14 | Cradlepoint, Inc. | Embedded DNS |
US7490197B2 (en) * | 2004-10-21 | 2009-02-10 | Microsoft Corporation | Using external memory devices to improve system performance |
US7774789B1 (en) | 2004-10-28 | 2010-08-10 | Wheeler Thomas T | Creating a proxy object and providing information related to a proxy object |
US8266631B1 (en) * | 2004-10-28 | 2012-09-11 | Curen Software Enterprises, L.L.C. | Calling a second functionality by a first functionality |
US7823169B1 (en) | 2004-10-28 | 2010-10-26 | Wheeler Thomas T | Performing operations by a first functionality within a second functionality in a same or in a different programming language |
WO2006050753A1 (en) * | 2004-11-15 | 2006-05-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for modifying mss |
US8458467B2 (en) | 2005-06-21 | 2013-06-04 | Cisco Technology, Inc. | Method and apparatus for adaptive application message payload content transformation in a network infrastructure element |
US7664879B2 (en) * | 2004-11-23 | 2010-02-16 | Cisco Technology, Inc. | Caching content and state data at a network element |
JP2006155188A (en) * | 2004-11-29 | 2006-06-15 | Sony Corp | Information processing system, device and method for providing information, electronic device and method, device and method for processing information, recording medium, and program |
US7987272B2 (en) | 2004-12-06 | 2011-07-26 | Cisco Technology, Inc. | Performing message payload processing functions in a network element on behalf of an application |
US7398382B2 (en) * | 2004-12-29 | 2008-07-08 | Intel Corporation | Method and apparatus to enhance platform boot efficiency |
US8706877B2 (en) | 2004-12-30 | 2014-04-22 | Citrix Systems, Inc. | Systems and methods for providing client-side dynamic redirection to bypass an intermediary |
US8700695B2 (en) | 2004-12-30 | 2014-04-15 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP pooling |
US8954595B2 (en) | 2004-12-30 | 2015-02-10 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP buffering |
US7810089B2 (en) | 2004-12-30 | 2010-10-05 | Citrix Systems, Inc. | Systems and methods for automatic installation and execution of a client-side acceleration program |
US8549149B2 (en) | 2004-12-30 | 2013-10-01 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing |
US8255456B2 (en) | 2005-12-30 | 2012-08-28 | Citrix Systems, Inc. | System and method for performing flash caching of dynamically generated objects in a data communication network |
US9118717B2 (en) * | 2005-02-18 | 2015-08-25 | Cisco Technology, Inc. | Delayed network protocol proxy for packet inspection in a network |
US7685289B2 (en) * | 2005-03-15 | 2010-03-23 | International Business Machines Corporation | Method and apparatus for proxying initial client requests to support asynchronous resource initialization |
US20060248194A1 (en) * | 2005-03-18 | 2006-11-02 | Riverbed Technology, Inc. | Connection forwarding |
US7861212B1 (en) | 2005-03-22 | 2010-12-28 | Dubagunta Saikumar V | System, method, and computer readable medium for integrating an original application with a remote application |
US8589561B2 (en) * | 2005-03-22 | 2013-11-19 | Alcatel Lucent | Session level technique for improving web browsing performance on low speed links |
US7797688B1 (en) | 2005-03-22 | 2010-09-14 | Dubagunta Saikumar V | Integrating applications in multiple languages |
US8578349B1 (en) | 2005-03-23 | 2013-11-05 | Curen Software Enterprises, L.L.C. | System, method, and computer readable medium for integrating an original language application with a target language application |
EP1889169A4 (en) * | 2005-05-19 | 2011-12-28 | Fusionone Inc | Mobile device address book builder |
US7840682B2 (en) | 2005-06-03 | 2010-11-23 | QNX Software Systems, GmbH & Co. KG | Distributed kernel operating system |
US8667184B2 (en) | 2005-06-03 | 2014-03-04 | Qnx Software Systems Limited | Distributed kernel operating system |
US7719995B2 (en) * | 2005-09-09 | 2010-05-18 | Zeugma Systems Inc. | Application driven fast unicast flow replication |
US20070061465A1 (en) * | 2005-09-15 | 2007-03-15 | Hostway Corporation | Host migration system |
US7818454B2 (en) * | 2005-09-15 | 2010-10-19 | Hostway Corporation | Host migration system |
US7886068B1 (en) * | 2005-10-27 | 2011-02-08 | Network Appliance, Inc. | Management of streaming media playlists |
US8447837B2 (en) * | 2005-12-30 | 2013-05-21 | Akamai Technologies, Inc. | Site acceleration with content prefetching enabled through customer-specific configurations |
US7921184B2 (en) | 2005-12-30 | 2011-04-05 | Citrix Systems, Inc. | System and method for performing flash crowd caching of dynamically generated objects in a data communication network |
US8301839B2 (en) | 2005-12-30 | 2012-10-30 | Citrix Systems, Inc. | System and method for performing granular invalidation of cached dynamically generated objects in a data communication network |
CN1997006B (en) * | 2006-01-06 | 2011-06-22 | 鸿富锦精密工业(深圳)有限公司 | Forwarding control system and method in the network communication |
CA2637413A1 (en) * | 2006-01-20 | 2007-07-26 | Paxfire, Inc. | Systems and methods for discerning and controlling communication traffic |
US8966113B2 (en) * | 2006-03-03 | 2015-02-24 | Cisco Technology, Inc. | Technique for dynamically restoring original TE-LSP attributes for interdomain TE-LSPs |
US8447802B2 (en) | 2006-03-08 | 2013-05-21 | Riverbed Technology, Inc. | Address manipulation to provide for the use of network tools even when transaction acceleration is in use over a network |
US8819181B2 (en) * | 2006-03-17 | 2014-08-26 | Apple Inc. | Adaptable network service access through dynamic request routing |
JP4702151B2 (en) * | 2006-04-10 | 2011-06-15 | パナソニック株式会社 | Network relay device and network communication system |
JP4632450B2 (en) * | 2006-04-17 | 2011-02-16 | キヤノン株式会社 | COMMUNICATION DEVICE AND ITS CONTROL METHOD |
US7810140B1 (en) | 2006-05-23 | 2010-10-05 | Lipari Paul A | System, method, and computer readable medium for processing a message in a transport |
US7941560B1 (en) | 2006-07-14 | 2011-05-10 | Intuit Inc. | Client caching of target addresses for network requests |
US7844759B1 (en) | 2006-07-28 | 2010-11-30 | Cowin Gregory L | System, method, and computer readable medium for processing a message queue |
US8566452B1 (en) | 2006-08-03 | 2013-10-22 | F5 Networks, Inc. | Intelligent HTTP based load-balancing, persistence, and application traffic management of SSL VPN tunnels |
US8079077B2 (en) | 2006-08-08 | 2011-12-13 | A10 Networks, Inc. | System and method for distributed multi-processing security gateway |
US8332925B2 (en) * | 2006-08-08 | 2012-12-11 | A10 Networks, Inc. | System and method for distributed multi-processing security gateway |
WO2008042804A2 (en) | 2006-09-29 | 2008-04-10 | Nomadix, Inc. | Systems and methods for injecting content |
US20080091868A1 (en) * | 2006-10-17 | 2008-04-17 | Shay Mizrachi | Method and System for Delayed Completion Coalescing |
US20080115202A1 (en) * | 2006-11-09 | 2008-05-15 | Mckay Michael S | Method for bidirectional communication in a firewalled environment |
US8132179B1 (en) | 2006-12-22 | 2012-03-06 | Curen Software Enterprises, L.L.C. | Web service interface for mobile agents |
US8200603B1 (en) | 2006-12-22 | 2012-06-12 | Curen Software Enterprises, L.L.C. | Construction of an agent that utilizes as-needed canonical rules |
US7664721B1 (en) | 2006-12-22 | 2010-02-16 | Hauser Robert R | Moving an agent from a first execution environment to a second execution environment using supplied and resident rules |
US7702604B1 (en) | 2006-12-22 | 2010-04-20 | Hauser Robert R | Constructing an agent that utilizes supplied rules and rules resident in an execution environment |
US7702602B1 (en) | 2006-12-22 | 2010-04-20 | Hauser Robert R | Moving and agent with a canonical rule from one device to a second device |
US7698243B1 (en) | 2006-12-22 | 2010-04-13 | Hauser Robert R | Constructing an agent in a first execution environment using canonical rules |
US20080155016A1 (en) * | 2006-12-22 | 2008-06-26 | Tsai Wei K | Content procurement architecture |
US7702603B1 (en) | 2006-12-22 | 2010-04-20 | Hauser Robert R | Constructing an agent that utilizes a compiled set of canonical rules |
US7970724B1 (en) | 2006-12-22 | 2011-06-28 | Curen Software Enterprises, L.L.C. | Execution of a canonical rules based agent |
US9311141B2 (en) | 2006-12-22 | 2016-04-12 | Callahan Cellular L.L.C. | Survival rule usage by software agents |
US7660780B1 (en) | 2006-12-22 | 2010-02-09 | Patoskie John P | Moving an agent from a first execution environment to a second execution environment |
US7860517B1 (en) | 2006-12-22 | 2010-12-28 | Patoskie John P | Mobile device tracking using mobile agent location breadcrumbs |
US7949626B1 (en) | 2006-12-22 | 2011-05-24 | Curen Software Enterprises, L.L.C. | Movement of an agent that utilizes a compiled set of canonical rules |
US7660777B1 (en) | 2006-12-22 | 2010-02-09 | Hauser Robert R | Using data narrowing rule for data packaging requirement of an agent |
US8423496B1 (en) | 2006-12-22 | 2013-04-16 | Curen Software Enterprises, L.L.C. | Dynamic determination of needed agent rules |
US8644272B2 (en) * | 2007-02-12 | 2014-02-04 | Cradlepoint, Inc. | Initiating router functions |
US9021081B2 (en) * | 2007-02-12 | 2015-04-28 | Cradlepoint, Inc. | System and method for collecting individualized network usage data in a personal hotspot wireless network |
US20080205388A1 (en) * | 2007-02-22 | 2008-08-28 | Microsoft Corporation | Discovery of network devices logically located between a client and a service |
US9021140B2 (en) * | 2007-03-12 | 2015-04-28 | Citrix Systems, Inc. | Systems and methods for error detection |
US8572160B2 (en) * | 2007-03-12 | 2013-10-29 | Citrix Systems, Inc. | Systems and methods for script injection |
US20080235326A1 (en) * | 2007-03-21 | 2008-09-25 | Certeon, Inc. | Methods and Apparatus for Accelerating Web Browser Caching |
US7743160B2 (en) * | 2007-03-29 | 2010-06-22 | Blue Coat Systems, Inc. | System and method of delaying connection acceptance to support connection request processing at layer-7 |
KR20080090053A (en) * | 2007-04-03 | 2008-10-08 | 삼성전자주식회사 | Network bridge apparatus and method for communication thereof |
US7995478B2 (en) * | 2007-05-30 | 2011-08-09 | Sony Computer Entertainment Inc. | Network communication with path MTU size discovery |
TW200847711A (en) * | 2007-05-31 | 2008-12-01 | Wistron Corp | Method and related system for building up a network connection between clients and servers through a stream fork by utilizing http protocol |
US20080298366A1 (en) * | 2007-05-31 | 2008-12-04 | Microsoft Corporation | Agnostic Network Architecture |
FR2917257B1 (en) | 2007-06-08 | 2009-07-17 | Alcatel Lucent Sas | MMS ROUTING USING A TRANSPARENT PROXY SERVER |
US8615008B2 (en) | 2007-07-11 | 2013-12-24 | Foundry Networks Llc | Duplicating network traffic through transparent VLAN flooding |
US7933273B2 (en) | 2007-07-27 | 2011-04-26 | Sony Computer Entertainment Inc. | Cooperative NAT behavior discovery |
US8121117B1 (en) | 2007-10-01 | 2012-02-21 | F5 Networks, Inc. | Application layer network traffic prioritization |
US8248928B1 (en) | 2007-10-09 | 2012-08-21 | Foundry Networks, Llc | Monitoring server load balancing |
TW200929974A (en) * | 2007-11-19 | 2009-07-01 | Ibm | System and method for performing electronic transactions |
US7856501B2 (en) | 2007-12-04 | 2010-12-21 | Sony Computer Entertainment Inc. | Network traffic prioritization |
US8181111B1 (en) | 2007-12-31 | 2012-05-15 | Synchronoss Technologies, Inc. | System and method for providing social context to digital activity |
US7856506B2 (en) * | 2008-03-05 | 2010-12-21 | Sony Computer Entertainment Inc. | Traversal of symmetric network address translator for multiple simultaneous connections |
US8667175B2 (en) * | 2008-03-13 | 2014-03-04 | Cisco Technology, Inc. | Server selection for routing content to a client using application layer redirection |
US7861001B2 (en) | 2008-04-29 | 2010-12-28 | Microsoft Corporation | Transport independent redirection |
JP4221055B1 (en) * | 2008-05-12 | 2009-02-12 | 株式会社クリエイティヴ・リンク | Web page creation method, web page creation system, linkage server device, and computer program |
US7788351B2 (en) * | 2008-05-27 | 2010-08-31 | Microsoft Corporation | Scalable transfer feedback |
US7783731B2 (en) * | 2008-05-27 | 2010-08-24 | Microsoft Corporation | Firmware cache coherence |
CN101662464A (en) | 2008-08-26 | 2010-03-03 | 阿里巴巴集团控股有限公司 | System for realizing HTTP request service and method thereof |
EP2173077A1 (en) * | 2008-10-06 | 2010-04-07 | Alcatel, Lucent | Shared content addressing protocol |
US8131822B2 (en) * | 2009-07-01 | 2012-03-06 | Suresh Srinivasan | Access of elements for a secure web page through a non-secure channel |
US20110030037A1 (en) | 2009-07-07 | 2011-02-03 | Vadim Olshansky | Zone migration in network access |
US8560604B2 (en) | 2009-10-08 | 2013-10-15 | Hola Networks Ltd. | System and method for providing faster and more efficient data communication |
US10721269B1 (en) | 2009-11-06 | 2020-07-21 | F5 Networks, Inc. | Methods and system for returning requests with javascript for clients before passing a request to a server |
US8255006B1 (en) | 2009-11-10 | 2012-08-28 | Fusionone, Inc. | Event dependent notification system and method |
US8806056B1 (en) | 2009-11-20 | 2014-08-12 | F5 Networks, Inc. | Method for optimizing remote file saves in a failsafe way |
US20110154469A1 (en) * | 2009-12-17 | 2011-06-23 | At&T Intellectual Property Llp | Methods, systems, and computer program products for access control services using source port filtering |
US8769156B2 (en) * | 2009-12-23 | 2014-07-01 | Citrix Systems, Inc. | Systems and methods for maintaining transparent end to end cache redirection |
CN101841573B (en) * | 2010-01-20 | 2013-08-07 | 中国科学院计算机网络信息中心 | Method and device for processing address information of Internet and Internet system |
US9923995B1 (en) * | 2010-02-27 | 2018-03-20 | Sitting Man, Llc | Methods, systems, and computer program products for sharing information for detecting an idle TCP connection |
US9049247B2 (en) | 2010-04-01 | 2015-06-02 | Cloudfare, Inc. | Internet-based proxy service for responding to server offline errors |
US9634993B2 (en) | 2010-04-01 | 2017-04-25 | Cloudflare, Inc. | Internet-based proxy service to modify internet responses |
US9420049B1 (en) | 2010-06-30 | 2016-08-16 | F5 Networks, Inc. | Client side human user indicator |
US9503375B1 (en) | 2010-06-30 | 2016-11-22 | F5 Networks, Inc. | Methods for managing traffic in a multi-service environment and devices thereof |
US8347100B1 (en) | 2010-07-14 | 2013-01-01 | F5 Networks, Inc. | Methods for DNSSEC proxying and deployment amelioration and systems thereof |
CA2807011A1 (en) * | 2010-08-03 | 2012-02-09 | Ht S.R.L. | Method and device for network traffic manipulation |
US8887012B2 (en) * | 2010-08-24 | 2014-11-11 | Advanced Micro Devices, Inc. | Method and apparatus for saving and restoring soft repair data |
US8549148B2 (en) | 2010-10-15 | 2013-10-01 | Brocade Communications Systems, Inc. | Domain name system security extensions (DNSSEC) for global server load balancing |
US8943428B2 (en) | 2010-11-01 | 2015-01-27 | Synchronoss Technologies, Inc. | System for and method of field mapping |
JP6035248B2 (en) | 2010-12-30 | 2016-11-30 | ピーラップ リミテッド | Data transmission method and system via computer network |
CN107094176B (en) | 2010-12-30 | 2021-07-30 | 皮尔爱普有限公司 | Method and system for caching data traffic on a computer network |
US20120209990A1 (en) * | 2011-02-13 | 2012-08-16 | Openwave Systems Inc. | Method and system for providing a zero rating service to an end-user device |
US8688817B2 (en) | 2011-03-14 | 2014-04-01 | Edgecast Networks, Inc. | Network connection hand-off using state transformations |
US9654601B2 (en) | 2011-03-14 | 2017-05-16 | Verizon Digital Media Services Inc. | Network connection hand-off and hand-back |
US9130899B1 (en) | 2011-04-27 | 2015-09-08 | Cisco Technology, Inc. | Integrated user interface for unified communications applications |
WO2012158854A1 (en) | 2011-05-16 | 2012-11-22 | F5 Networks, Inc. | A method for load balancing of requests' processing of diameter servers |
US8285808B1 (en) | 2011-05-20 | 2012-10-09 | Cloudflare, Inc. | Loading of web resources |
US9225763B2 (en) * | 2011-06-07 | 2015-12-29 | Cisco Technology, Inc. | Distributed overlay browser for transparent streaming media support in virtualized desktop environment |
US8769011B2 (en) * | 2011-06-21 | 2014-07-01 | Cisco Technology, Inc. | Survivable browsing in virtualized desktop environment when host connectivity is lost |
US8745266B2 (en) * | 2011-06-30 | 2014-06-03 | Citrix Systems, Inc. | Transparent layer 2 redirection of request to single sign in service based on applying policy to content of request |
US8396836B1 (en) | 2011-06-30 | 2013-03-12 | F5 Networks, Inc. | System for mitigating file virtualization storage import latency |
US9747592B2 (en) * | 2011-08-16 | 2017-08-29 | Verizon Digital Media Services Inc. | End-to-end content delivery network incorporating independently operated transparent caches and proxy caches |
US9026670B2 (en) * | 2011-08-22 | 2015-05-05 | Allot Communications Ltd. | System and method for efficient caching and delivery of adaptive bitrate streaming |
US8463850B1 (en) | 2011-10-26 | 2013-06-11 | F5 Networks, Inc. | System and method of algorithmically generating a server side transaction identifier |
US10230566B1 (en) | 2012-02-17 | 2019-03-12 | F5 Networks, Inc. | Methods for dynamically constructing a service principal name and devices thereof |
US9020912B1 (en) | 2012-02-20 | 2015-04-28 | F5 Networks, Inc. | Methods for accessing data in a compressed file system and devices thereof |
US9244843B1 (en) | 2012-02-20 | 2016-01-26 | F5 Networks, Inc. | Methods for improving flow cache bandwidth utilization and devices thereof |
US9462071B2 (en) * | 2012-03-06 | 2016-10-04 | Cisco Technology, Inc. | Spoofing technique for transparent proxy caching |
US9215127B2 (en) * | 2012-03-12 | 2015-12-15 | Network Coding, Inc. | Non-intrusive proxy system and method for applications without proxy support |
US9118618B2 (en) | 2012-03-29 | 2015-08-25 | A10 Networks, Inc. | Hardware-based packet editor |
US9378339B2 (en) | 2012-04-06 | 2016-06-28 | Wayne Odom | System, method, and device for delivering communications and storing and delivering data |
US8677510B2 (en) | 2012-04-06 | 2014-03-18 | Wayne Odom | System, method, and device for communicating and storing and delivering data |
US8572720B1 (en) | 2013-05-20 | 2013-10-29 | Wayne Odom | System, method, and device for communicating and storing and delivering data |
US8448236B1 (en) | 2012-12-07 | 2013-05-21 | Wayne Odom | System, method, and device for storing and delivering data |
US9043934B2 (en) | 2012-04-06 | 2015-05-26 | Wayne Odom | System, method, and device for delivering communications and storing and delivering data |
US8844054B2 (en) | 2012-04-06 | 2014-09-23 | Wayne Odom | System, method, and device for communicating and storing and delivering data |
EP2853074B1 (en) | 2012-04-27 | 2021-03-24 | F5 Networks, Inc | Methods for optimizing service of content requests and devices thereof |
US9596286B2 (en) | 2012-05-25 | 2017-03-14 | A10 Networks, Inc. | Method to process HTTP header with hardware assistance |
US8925059B2 (en) * | 2012-06-08 | 2014-12-30 | Lockheed Martin Corporation | Dynamic trust connection |
US9442618B2 (en) * | 2012-09-17 | 2016-09-13 | Sap Se | Mobile device interface generator |
US10021174B2 (en) | 2012-09-25 | 2018-07-10 | A10 Networks, Inc. | Distributing service sessions |
CN108027805B (en) | 2012-09-25 | 2021-12-21 | A10网络股份有限公司 | Load distribution in a data network |
CN103699367B (en) * | 2012-09-27 | 2017-07-07 | 中国电信股份有限公司 | HTTP application programming interfaces call method and device |
US10033837B1 (en) | 2012-09-29 | 2018-07-24 | F5 Networks, Inc. | System and method for utilizing a data reducing module for dictionary compression of encoded data |
CN103731447B (en) * | 2012-10-11 | 2019-03-26 | 腾讯科技(深圳)有限公司 | A kind of data query method and system |
US9578090B1 (en) | 2012-11-07 | 2017-02-21 | F5 Networks, Inc. | Methods for provisioning application delivery service and devices thereof |
US10375155B1 (en) | 2013-02-19 | 2019-08-06 | F5 Networks, Inc. | System and method for achieving hardware acceleration for asymmetric flow connections |
US9497614B1 (en) | 2013-02-28 | 2016-11-15 | F5 Networks, Inc. | National traffic steering device for a better control of a specific wireless/LTE network |
US9634935B2 (en) | 2013-04-24 | 2017-04-25 | Secured Connectivity, Llc | Method, name server, and system for directing network traffic utilizing profile records |
US10027761B2 (en) | 2013-05-03 | 2018-07-17 | A10 Networks, Inc. | Facilitating a secure 3 party network session by a network device |
US9654473B2 (en) | 2013-06-28 | 2017-05-16 | Bmc Software, Inc. | Authentication proxy agent |
US10951726B2 (en) | 2013-07-31 | 2021-03-16 | Citrix Systems, Inc. | Systems and methods for performing response based cache redirection |
US9009461B2 (en) | 2013-08-14 | 2015-04-14 | Iboss, Inc. | Selectively performing man in the middle decryption |
US9241044B2 (en) | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
US10187317B1 (en) | 2013-11-15 | 2019-01-22 | F5 Networks, Inc. | Methods for traffic rate control and devices thereof |
WO2015074171A1 (en) * | 2013-11-19 | 2015-05-28 | Telefonaktiebolaget L M Ericsson (Publ) | Testing the performance of a layer 3 proxy device using traffic amplification |
US9565138B2 (en) | 2013-12-20 | 2017-02-07 | Brocade Communications Systems, Inc. | Rule-based network traffic interception and distribution scheme |
US20150188999A1 (en) * | 2013-12-28 | 2015-07-02 | Johnson Manuel-Devadoss | System and method to extend the capabilities of a web browser to improve the web application performance |
US9686343B2 (en) | 2013-12-31 | 2017-06-20 | Amadeus S.A.S. | Metasearch redirection system and method |
US9648542B2 (en) | 2014-01-28 | 2017-05-09 | Brocade Communications Systems, Inc. | Session-based packet routing for facilitating analytics |
US10020979B1 (en) | 2014-03-25 | 2018-07-10 | A10 Networks, Inc. | Allocating resources in multi-core computing environments |
US9806943B2 (en) | 2014-04-24 | 2017-10-31 | A10 Networks, Inc. | Enabling planned upgrade/downgrade of network devices without impacting network sessions |
WO2015164079A1 (en) * | 2014-04-25 | 2015-10-29 | Cisco Technology, Inc. | Managing sequence values with added headers in computing devices |
US9848067B2 (en) * | 2014-04-25 | 2017-12-19 | Cisco Technology, Inc. | Managing sequence values with added headers in computing devices |
CA2950453C (en) * | 2014-06-13 | 2022-12-06 | Teclo Networks Ag | Proxy node for transferring packets between a server and a client using port sharding |
US11838851B1 (en) | 2014-07-15 | 2023-12-05 | F5, Inc. | Methods for managing L7 traffic classification and devices thereof |
EP3205064A2 (en) * | 2014-10-07 | 2017-08-16 | Interdigital Patent Holdings, Inc. | Supporting internet protocol (ip) clients in an information centric network (icn) |
AU2014101252B4 (en) * | 2014-10-15 | 2015-04-23 | Parametric Systems Pty Ltd | Net2Core - An Innovative Computer Systems Design to Protect Computer Systems where System Access through the Internet is Desired or Required. |
WO2016075762A1 (en) * | 2014-11-11 | 2016-05-19 | 株式会社シンメトリック | Data processsing system, data processing device, and program for editing webpage |
US10182013B1 (en) | 2014-12-01 | 2019-01-15 | F5 Networks, Inc. | Methods for managing progressive image delivery and devices thereof |
US11895138B1 (en) | 2015-02-02 | 2024-02-06 | F5, Inc. | Methods for improving web scanner accuracy and devices thereof |
EP3070911A1 (en) * | 2015-03-20 | 2016-09-21 | Ucopia Communications | Method for controlling access to a private network |
US10911353B2 (en) | 2015-06-17 | 2021-02-02 | Extreme Networks, Inc. | Architecture for a network visibility system |
US9866478B2 (en) | 2015-03-23 | 2018-01-09 | Extreme Networks, Inc. | Techniques for user-defined tagging of traffic in a network visibility system |
US10129088B2 (en) | 2015-06-17 | 2018-11-13 | Extreme Networks, Inc. | Configuration of rules in a network visibility system |
US10771475B2 (en) | 2015-03-23 | 2020-09-08 | Extreme Networks, Inc. | Techniques for exchanging control and configuration information in a network visibility system |
US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
US10505818B1 (en) | 2015-05-05 | 2019-12-10 | F5 Networks. Inc. | Methods for analyzing and load balancing based on server health and devices thereof |
US11350254B1 (en) | 2015-05-05 | 2022-05-31 | F5, Inc. | Methods for enforcing compliance policies and devices thereof |
US9639570B2 (en) | 2015-05-14 | 2017-05-02 | Walleye Software, LLC | Data store access permission system with interleaved application of deferred access control filters |
US11057446B2 (en) | 2015-05-14 | 2021-07-06 | Bright Data Ltd. | System and method for streaming content from multiple servers |
US10057126B2 (en) | 2015-06-17 | 2018-08-21 | Extreme Networks, Inc. | Configuration of a network visibility system |
US10530688B2 (en) | 2015-06-17 | 2020-01-07 | Extreme Networks, Inc. | Configuration of load-sharing components of a network visibility router in a network visibility system |
US10771391B2 (en) * | 2015-11-05 | 2020-09-08 | Hewlett Packard Enterprise Development Lp | Policy enforcement based on host value classification |
CN108886533B (en) * | 2015-12-04 | 2021-05-18 | 维尔塞特公司 | Accelerating connections to host servers |
US11757946B1 (en) | 2015-12-22 | 2023-09-12 | F5, Inc. | Methods for analyzing network traffic and enforcing network policies and devices thereof |
US10187475B2 (en) * | 2015-12-31 | 2019-01-22 | Hughes Network Systems, Llc | Method and system for automatically bypassing network proxies in the presence of interdependent traffic flows |
US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
US10797888B1 (en) | 2016-01-20 | 2020-10-06 | F5 Networks, Inc. | Methods for secured SCEP enrollment for client devices and devices thereof |
US11178150B1 (en) | 2016-01-20 | 2021-11-16 | F5 Networks, Inc. | Methods for enforcing access control list based on managed application and devices thereof |
EP3200429B1 (en) | 2016-02-01 | 2019-04-17 | Volkswagen Aktiengesellschaft | Method for retrieving a data stream from a server and vehicle with network access point |
US10091075B2 (en) | 2016-02-12 | 2018-10-02 | Extreme Networks, Inc. | Traffic deduplication in a visibility network |
US10999200B2 (en) | 2016-03-24 | 2021-05-04 | Extreme Networks, Inc. | Offline, intelligent load balancing of SCTP traffic |
US9680801B1 (en) | 2016-05-03 | 2017-06-13 | Iboss, Inc. | Selectively altering references within encrypted pages using man in the middle |
CN105959228B (en) * | 2016-06-23 | 2020-06-16 | 华为技术有限公司 | Traffic processing method and transparent cache system |
US10567259B2 (en) | 2016-10-19 | 2020-02-18 | Extreme Networks, Inc. | Smart filter generator |
US10412198B1 (en) | 2016-10-27 | 2019-09-10 | F5 Networks, Inc. | Methods for improved transmission control protocol (TCP) performance visibility and devices thereof |
US11063758B1 (en) | 2016-11-01 | 2021-07-13 | F5 Networks, Inc. | Methods for facilitating cipher selection and devices thereof |
US10505792B1 (en) | 2016-11-02 | 2019-12-10 | F5 Networks, Inc. | Methods for facilitating network traffic analytics and devices thereof |
US10812266B1 (en) | 2017-03-17 | 2020-10-20 | F5 Networks, Inc. | Methods for managing security tokens based on security violations and devices thereof |
US11343237B1 (en) | 2017-05-12 | 2022-05-24 | F5, Inc. | Methods for managing a federated identity environment using security and access control data and devices thereof |
US11122042B1 (en) | 2017-05-12 | 2021-09-14 | F5 Networks, Inc. | Methods for dynamically managing user access control and devices thereof |
US10241965B1 (en) | 2017-08-24 | 2019-03-26 | Deephaven Data Labs Llc | Computer data distribution architecture connecting an update propagation graph through multiple remote query processors |
EP4199479A1 (en) | 2017-08-28 | 2023-06-21 | Bright Data Ltd. | Improving content fetching by selecting tunnel devices grouped according to geographic location |
US11190374B2 (en) | 2017-08-28 | 2021-11-30 | Bright Data Ltd. | System and method for improving content fetching by selecting tunnel devices |
US11223689B1 (en) | 2018-01-05 | 2022-01-11 | F5 Networks, Inc. | Methods for multipath transmission control protocol (MPTCP) based session migration and devices thereof |
CN109547291A (en) * | 2018-12-06 | 2019-03-29 | 珠海西山居移动游戏科技有限公司 | A kind of method and device of quick positioning high frequency bandwidth consumption |
CN109361784B (en) * | 2018-12-07 | 2021-09-21 | 成都知道创宇信息技术有限公司 | Method for acquiring real IP of client under four-layer proxy network environment |
EP4220441A1 (en) | 2019-02-25 | 2023-08-02 | Bright Data Ltd. | System and method for url fetching retry mechanism |
WO2020202135A2 (en) | 2019-04-02 | 2020-10-08 | Luminati Networks Ltd. | System and method for managing non-direct url fetching service |
CN115428415A (en) * | 2020-04-16 | 2022-12-02 | 华为技术有限公司 | System and method for forwarding packets in a hierarchical network architecture using variable length addresses |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6081829A (en) * | 1996-01-31 | 2000-06-27 | Silicon Graphics, Inc. | General purpose web annotations without modifying browser |
US6189030B1 (en) * | 1996-02-21 | 2001-02-13 | Infoseek Corporation | Method and apparatus for redirection of server external hyper-link references |
US5838910A (en) * | 1996-03-14 | 1998-11-17 | Domenikos; Steven D. | Systems and methods for executing application programs from a memory device linked to a server at an internet site |
US5864852A (en) * | 1996-04-26 | 1999-01-26 | Netscape Communications Corporation | Proxy server caching mechanism that provides a file directory structure and a mapping mechanism within the file directory structure |
US5774660A (en) * | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
US5905872A (en) * | 1996-11-05 | 1999-05-18 | At&T Corp. | Method of transferring connection management information in world wideweb requests and responses |
US6138162A (en) * | 1997-02-11 | 2000-10-24 | Pointcast, Inc. | Method and apparatus for configuring a client to redirect requests to a caching proxy server based on a category ID with the request |
US6065058A (en) * | 1997-05-09 | 2000-05-16 | International Business Machines Corp. | Dynamic push filtering based on information exchanged among nodes in a proxy hierarchy |
US5987523A (en) * | 1997-06-04 | 1999-11-16 | International Business Machines Corporation | Applet redirection for controlled access to non-orginating hosts |
US6098108A (en) * | 1997-07-02 | 2000-08-01 | Sitara Networks, Inc. | Distributed directory for enhanced network communication |
US6006264A (en) * | 1997-08-01 | 1999-12-21 | Arrowpoint Communications, Inc. | Method and system for directing a flow between a client and a server |
US6112212A (en) * | 1997-09-15 | 2000-08-29 | The Pangea Project Llc | Systems and methods for organizing and analyzing information stored on a computer network |
US5941954A (en) * | 1997-10-01 | 1999-08-24 | Sun Microsystems, Inc. | Network message redirection |
US6081900A (en) * | 1999-03-16 | 2000-06-27 | Novell, Inc. | Secure intranet access |
-
1998
- 1998-12-16 US US09/212,980 patent/US6389462B1/en not_active Expired - Lifetime
-
1999
- 1999-11-03 CA CA002288488A patent/CA2288488A1/en not_active Abandoned
- 1999-12-07 EP EP99309826A patent/EP1011244B1/en not_active Expired - Lifetime
- 1999-12-07 DE DE69919965T patent/DE69919965T2/en not_active Expired - Lifetime
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100498756C (en) * | 2002-02-14 | 2009-06-10 | 第三雷沃Cdn国际公司 | Managed object replication and delivery method and system |
US8924466B2 (en) | 2002-02-14 | 2014-12-30 | Level 3 Communications, Llc | Server handoff in content delivery network |
US9167036B2 (en) | 2002-02-14 | 2015-10-20 | Level 3 Communications, Llc | Managed object replication and delivery |
US9992279B2 (en) | 2002-02-14 | 2018-06-05 | Level 3 Communications, Llc | Managed object replication and delivery |
US10979499B2 (en) | 2002-02-14 | 2021-04-13 | Level 3 Communications, Llc | Managed object replication and delivery |
US8930538B2 (en) | 2008-04-04 | 2015-01-06 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
US9762692B2 (en) | 2008-04-04 | 2017-09-12 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
US10218806B2 (en) | 2008-04-04 | 2019-02-26 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
US10924573B2 (en) | 2008-04-04 | 2021-02-16 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
CN114329437A (en) * | 2022-03-14 | 2022-04-12 | 北京指掌易科技有限公司 | Data processing method, device, equipment and storage medium |
CN114329437B (en) * | 2022-03-14 | 2022-06-14 | 北京指掌易科技有限公司 | Data processing method, device, equipment and storage medium |
Also Published As
Publication number | Publication date |
---|---|
US6389462B1 (en) | 2002-05-14 |
EP1011244A3 (en) | 2002-06-05 |
EP1011244A2 (en) | 2000-06-21 |
EP1011244B1 (en) | 2004-09-08 |
DE69919965D1 (en) | 2004-10-14 |
DE69919965T2 (en) | 2005-09-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6389462B1 (en) | Method and apparatus for transparently directing requests for web objects to proxy caches | |
US6857009B1 (en) | System and method for network access without reconfiguration | |
EP1234246B1 (en) | System and method for network access without reconfiguration | |
US8406240B2 (en) | Packet fragmentation prevention | |
US7624142B2 (en) | System and method for processing packets according to user specified rules governed by a syntax | |
US6532493B1 (en) | Methods and apparatus for redirecting network cache traffic | |
US7114008B2 (en) | Edge adapter architecture apparatus and method | |
US6128298A (en) | Internet protocol filter | |
US6006272A (en) | Method for network address translation | |
US7290050B1 (en) | Transparent load balancer for network connections | |
US6327626B1 (en) | Method and apparatus for MSS spoofing | |
WO2021196568A1 (en) | Traffic flow proxy method, server, and storage medium | |
EP2069955A1 (en) | Handoff and optimization of a network protocol stack | |
US20030009588A1 (en) | Resource request forwarding in havi and other internetworking devices | |
US20030229713A1 (en) | Server network controller including server-directed packet forwarding and method therefor | |
US7564848B2 (en) | Method for the establishing of connections in a communication system | |
WO2015167375A1 (en) | Method and tcp proxy for supporting communication between a client device and a server node | |
Cisco | IP Commands | |
CN117081990B (en) | MPLS flow agent method, system, equipment and storage medium | |
Cheng | Routing-independent Anycast for IPv6 content delivery networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Discontinued |