(12) United States Patent
`Cohen et al.
`
`USOO63894.62B1
`(10) Patent No.:
`US 6,389,462 B1
`(45) Date of Patent:
`May 14, 2002
`
`(*) Notice:
`
`(54) METHOD AND APPARATUS FOR
`TRANSPARENTLY DIRECTING REQUESTS
`FOR WEB OBJECTS TO PROXY CACHES
`(75) Inventors: Ariel Cohen, Berkeley Heights;
`Sampath Rangarajan, Bridgewater;
`Navjot Singh, Morristown, all of NJ
`(US)
`(73) Assignee: Lucent Technologies Inc., Murray Hill,
`NJ (US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`(21) Appl. No.: 09/212,980
`(22) Filed:
`Dec. 16, 1998
`(51) Int. Cl. ................................................ G06F 15/16
`(52) U.S. Cl. ....................... 709/218; 709/201; 709/203;
`709/219; 709/229; 709/231; 709/239; 707/10;
`707/501
`(58) Field of Search ................................. 709/218, 203,
`709/219, 201, 224, 229, 239, 231; 707/10,
`501; 713/201
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`5,774,660 A * 6/1998 Brendel et al. ............. 709/201
`5,838,916 A * 11/1998 Domenikos et al. ........ 709/219
`5,864,852 A
`1/1999 Luotonen ..................... 707/10
`5,905,872 A * 5/1999 DeSimone et al. ......... 709/245
`5.941,954. A * 8/1999 Kalajan ...................... 709/239
`(List continued on next page.)
`OTHER PUBLICATIONS
`ACEdirector 2 Data Sheet, ACElerate Layer 4 Services,
`Server Switching Services, http://www.alteon.com.
`“Deploying Transparent Caching With Inktomi's Traffic
`Server”, http://www.inktomi.com.
`Danzig, Peter, Network Appliance, Inc., “NetCache Archi
`tecture
`and
`Deployment',
`http://www.network
`application.com.
`(List continued on next page.)
`
`
`
`Primary Examiner Ayaz Sheikh
`ASSistant Examiner-Frantz B. Jean
`(74) Attorney, Agent, or Firm-Stephen M. Gurey
`(57)
`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 desti
`nation 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 acknowl
`edgement 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 for
`warded by the proxy redirector to the proxy cache.
`
`55 Claims, 4 Drawing Sheets
`
`O7
`
`6
`10
`ORIGIN
`SERVER
`
`GUEST TEK EXHIBIT 1010
`Guest Tek v. Nomadix, IPR2019-01191
`
`

`

`US 6,389,462 B1
`Page 2
`
`U.S. PATENT DOCUMENTS
`
`
`
`5.987,523 A * 11/1999 Hind et al. ................. 709/245
`6,065,058 A * 5/2000 Hailpern et al. ..
`... 709/231
`6,081,829. A
`6/2000 Sidana ................ ... 709/203
`6,081,900 A * 6/2000 Subramaniam et al. ..... 713/201
`6,098,108 A * 8/2000 Sridhar et al. .......
`... 709/239
`6,112,212 A
`8/2000 Heitler ....................... 707/501
`6,138,162 A * 10/2000 Pistriotto et al. ........... 709/229
`6,189,030 B1 * 2/2001 Kirsch et al. ............... 709/224
`OTHER PUBLICATIONS
`“High-Performance Web Caching White Paper', Cache
`Flow, Document Center, http://www.cacheflow.com.
`“Shared Network Caching and Cisco Cache Engine', http://
`www.cisco.com.
`
`“The Content Smart Internet”, ArrowPoint, ArrowPoint
`Communications, 235 Littleton Road, Westford, MA 01886,
`http://www.arrowpoint.com.
`Danzig, P. and Swartz, K. L., “Transparent, Scalable,
`Fail-Safe Web Caching”, Network Appliance, Inc., http://
`www.networkappliance.com.
`RND Networks Inc., “Cache Directing Technology-White
`Paper”, http://www.rndnetworks.com.
`Foundry Products, “ServerIron Server Load Balancing and
`Transparent Caching Swithch'. http://www.foundrynet.com.
`
`* cited by examiner
`
`

`

`U.S. Patent
`
`May 14, 2002
`
`Sheet 1 of 4
`
`US 6,389,462 B1
`
`101-1
`
`102
`
`Ee
`sues. A
`
`1
`FIC.
`PROYY
`CACHE
`
`115
`
`116
`
`103
`
`104
`
`107
`
`106
`ORIGIN
`SERVER
`
`105
`
`ORIGIN
`SERVER
`109
`
`117
`
`PROXY
`CACHE
`
`PROXY
`REDIRECTOR
`
`ROUTER
`
`ROUTER
`
`112
`
`111
`
`110-
`PROXY
`CACHE
`
`PROXY
`CACHE
`
`110-2
`
`FIC. 3
`
`
`
`
`
`
`
`
`
`RECEIVE SYN PACKET FROM CLIENT
`
`SELECT A PROXY CACHE
`
`-------wom
`
`DOFULL NAT:
`CHANGE DESTINATION P ADDRESS TO PROXY IP ADDRESS
`CHANGE SOURCE IP ADDRESS TO PADDRESS OF PROXY REDIRECTOR
`- H
`DO PAT:
`CHANGE SOURCE PORT TO BOGUS PORT
`CHANGE DESTINATION port TO PORT t ON PROXY CACHE
`
`
`
`
`
`SEND TO PROXY CACHE
`
`
`
`
`
`RECEIVE SYN ACK PACKET FROM PROXY CACHE
`
`REVERSE TRANSLATIONS ON IP ADDRESSES AND TCP PORT S
`CHANGE MSS IN TCP HEADER OF SYN ACK PACKET
`
`SEND TO CLIENT
`
`301
`
`502
`
`303
`
`304
`
`305
`
`306
`
`307
`
`308
`
`309
`
`

`

`U.S. Patent
`
`May 14, 2002
`
`Sheet 2 of 4
`
`US 6,389,462 B1
`
`FIC. 2
`
`
`
`
`
`REMOTE
`PROGRAM
`NJECTOR
`
`PROGRAM
`NJECTOR
`
`
`
`ADMISSION
`DAEMON
`
`MONITOR
`
`PRIVILEGED
`GATEWAY
`PROGRAM
`
`PRIVILEGED
`GATEWAY
`PROGRAM
`
`UNPRIVILEGED
`GATEWAY
`PROGRAM
`
`DISPATCHER
`PROCESS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PROTOCOL
`STACK
`
`PACKET
`FILTER
`
`RAW IP
`SOCKET
`
`2O3
`
`
`
`
`
`NETWORK
`INTERFACES
`LINUX KERNEL
`208
`----------------TY--------------------------
`
`
`
`
`
`NCOMING
`PACKETS
`
`OUGOING
`PACKETS
`
`

`

`U.S. Patent
`
`May 14, 2002
`
`Sheet 3 of 4
`
`US 6,389,462 B1
`
`FIG. 4
`
`RECEIVE ACK PACKET FROM CLIENT
`
`PERFORM FULL NAT AND PAT
`
`SEND PACKET TO PROXY CACHE
`
`RECEIVE GET PACKET FROM CLIENT
`
`PERFORM FULL NAT
`
`310
`
`311
`
`32
`
`313
`
`314
`
`315
`
`IS THIS FIRST PACE OF GET REQUEST
`NO
`PREFX OVERFLOW FROM PREVIOUS
`GET PACKET AND PUSH REST OUT
`
`PERFORM PAT
`
`317
`
`:
`YES
`PREFIX IP
`DESTINATION ADDRESS TO
`COMPLETE ADDRESS
`
`S THIS THE t
`No
`SEND PACKET TO PROXY CACHE
`
`20
`
`322
`
`is
`PACKET OF A GET MESSAGE2
`CHANGE IP PACKET LENGTH
`SEND PACKET TO PROXY CACHE
`
`319
`
`

`

`U.S. Patent
`
`May 14, 2002
`
`Sheet 4 of 4
`
`US 6,389,462 B1
`
`FIC. 5
`
`RECEIVE ACK TO GET REQUEST OR SUBSEQUENT PACKET
`
`PERFORM REVERSE TRANSLATION NAT & PAT
`
`MODIFY ACK SEQ NUMBER BY DECREASING BY NUMBER
`OF BYTES ADDED BY GET MODIFICATION
`
`
`
`SEND PACKET TO CLIENT
`
`RECEIVE SUBSEQUENT PACKET TO GET REQUEST FROM CLIENT
`
`PERFORM FULL NAT AND PAT
`
`INCREMENT SEO NO BY NUMBER OF BYTES ADDED
`
`SEND PACKET TO PROXY CACHE
`
`
`
`502
`
`503
`
`504
`
`602
`
`604
`
`

`

`1
`METHOD AND APPARATUS FOR
`TRANSPARENTLY DIRECTING REQUESTS
`FOR WEB OBJECTS TO PROXY CACHES
`
`FIELD OF THE INVENTION
`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.
`BACKGROUND OF THE INVENTION
`Proxy caching is currently used to decrease both the
`latency of object retrieval and traffic on the Internet back
`bone. 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 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.
`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 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 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
`ISPs standpoint to allow its 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 requests will fail.
`It is therefore more desirable from an ISPs 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. 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
`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 per
`formed to determine from the 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. 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
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,389,462 B1
`
`2
`an IP address. First, a SYN packet is sent from the client to
`that origin Server, wherein the destination IP address Speci
`fied in 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 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. 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), and
`object information (e.g., index.html), a complete URL only
`identifies the particular object (e.g., index.html) that is
`requested Since the packet(s) 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 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 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 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 needs to “think'
`that it is connected to the origin server to which its SYN and
`the packet(s) 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
`ACKSYN packet and the packets containing the requested
`object must be that same origin server IP address 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 TCP connection. The proxy cache must then masquerade
`as the origin server when sending the ACKSYN 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 packet(s) containing a GET request must be
`redirected to the proxy cache and the request fulfilled either
`from the 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 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
`
`

`

`US 6,389,462 B1
`
`5
`
`15
`
`40
`
`3
`the network, a Layer 4 (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 gener
`ally 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 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 previ
`ously described in which the browser formulates a GET
`request with the absolute URL, for transparent caching 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 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
`25
`client's Source 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 mas
`querading as the origin Server address. This packet is trans
`ported through the L4 Switch onto the network over the TCP
`connection back to the client. The Subsequent packet(s) with
`the GET request from the client is redirected by the L4
`switch to the directly connected proxy. Since the GET
`packet(s) only contains the complete URL, 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
`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
`45
`HOST field in the packet(s) containing the GET request.
`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 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 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 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). When the client sends an ACK packet
`
`35
`
`50
`
`55
`
`60
`
`65
`
`4
`and then the packet(s) containing the GET request to the
`origin Server, the L4 Switch again performs a NAT, trans
`lating the destination IP address to the IP address of the
`proxy. Thus, when the packet(s) containing the GET request
`is received by the proxy, it does not know the IP address of
`the origin Server as in the directly connected proxy arrange
`ment 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 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 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 DNS look-up using the
`combination of the site URL in the HOST field and the
`complete URL in the GET request.
`The above described techniques for performing transpar
`ent 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 present
`in the packet(s) 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 art techniques require the proxy cache to perform
`the function of forming an absolute URL from the informa
`tion in the HOST field and in the packet(s) 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 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 disadvantages with respect to persistent connections
`defined by the HTTP 1.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
`connection, a client may “think it has established a persis
`tent 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
`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 persistent
`connection, each responsive DNS look-up to the logical
`name may direct a connection to an even different IP address
`
`

`

`25
`
`S
`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 through
`out the connection, are lost. A methodology is desirable 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
`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 herein
`after as a proxy redirector), through which the packets flow,
`is provided with the functionalities at the IP level necessary
`to transform the complete URL in each GET request trans
`mitted by a client to an appropriate absolute URL.
`Specifically, the IP address found in the destination field in
`the IP header of the packet(s) 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 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 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 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 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 packets
`returned from the proxy or the origin Server that logically
`follow receipt of the GET packet(s) 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 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 to be added to the GET request
`55
`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 indicated by a maximum segment size (MSS) field in
`packets from the proxy. The proxy redirector, upon receipt
`of the On, 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 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
`
`35
`
`40
`
`45
`
`50
`
`60
`
`65
`
`US 6,389,462 B1
`
`15
`
`6
`prefixed by the proxy redirector to form the absolute URL
`(whether the GET request is one or more segments long) is
`less than or 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 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,
`FIG. 2 is a block diagram showing the proxy redirector
`implemented on a programmable network element that
`manipulates packets in accordance with instructions pro
`Vided by a loaded program; and
`FIGS. 3, 4, 5 and 6 are flow charts detailing the operation
`of the proxy redirector.
`DETAILED DESCRIPTION
`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 (LA) switch 104 (proxy
`redirector) which interfaces the LAN with a wide area
`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 con
`nected to LAN 102 for objects stored in servers connected
`to the Internet 105 traverse proxy redirector 104 onto the
`Internet. The packets 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 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 linternet 105 pass
`through proxy redirector 104.
`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. The IP address returned to the browser is the IP
`address of a particular origin Server which contains the 5
`object requested through the logical URL. Since a logical
`name may in fact be associated with a plurality of essentially
`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 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.
`
`

`

`US 6,389,462 B1
`
`15
`
`25
`
`7
`With the IP address of the origin server determined and
`returned to the client, the browser establishes a TCP con
`nection 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 acknowledgement of receipt of that SYN packet
`through an ACKSYN 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 particu
`lar requested object.
`In accordance with the present invention, once the IP
`address of the 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 returned to the requesting client. A
`TCP connection, therefore, is not established over the Inter
`net 105, to the actual origin server 107 to provide the
`requested object to the requesting client. The coSS of trans
`mitting the 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 request is directed does not contain the requested
`object, a separate TCP connection is established between the
`proxy cache and the origin Server to