[ieee comput. soc ieee/wic international conference on web intelligence (wi 2003) - halifax, ns,...

CARP Compliant Proxy Enforcer Frame Work

Khaled E. A. NegmEtisalat College of Engineering

Sharjah, POB 980, [email protected]

Abstract

One of the important aspects of network management is the proxy usage. Nowadays it is a common practiceto force the user to connect to some network services via the proxy. The disadvantage of this method is that it requires from the user an additional networkknowledge and manual client configuration. Theproblem can be solved by developing a system that will enforce proxy usage and should remain completely transparent to user. In addition to that, the enforcing should reduce network traffic, increase the speed and thus increase performance.

In this research we present a frame work of a proxy system that is able to process the requests of a number of different application level protocols. The systemdeals with program redirection of HTTP protocolrequests, but the same scheme can be applied toimplement the enforcer for other protocols too. The system is implemented on Linux Red Hat platform and can run on new distribution of host operating systems that implements IP firewall (ipfw). This system also posses a different dimension of implementing andenforcing security policy among enterprises. Thiscould be achieved by stopping any proxy bypass event processed by clients to browse for prohibited sites during the working hours according to certaincompanies’ security policies. The system can beinstalled on host operating system to provide support to all clients independent of their platforms.

The system is tested in a private network that simulates the real traffic environment with 10 proxy servers, 50 hosts that serve 250,000 clients connected via different network topologies, technologies and services. Thesystem showed feasibility and efficiency for improving network performance between 17-23 % which is a fairly successful result.

1. Introduction

The World Wide Web is a fascinating example of adistributed system on an immense scale. Its large scale

and increasingly important role in society make it an important object of study and evolution. At the time,since the Web is not centrally planned or configured, many basic questions about its nature is still open.

The question that motivates our work is a basic one: why is the Web so slow? More precisely: what is the root causes of long response times in the Web? Attempting to answer this question immediately exposes gaps in the research to date on Internet management andmeasurements. In terms of proxy caching management and enforcing we started to address this problem.

Due to the explosive growth in global networkinginfrastructures a new problem is created that is the idea of "smart" network administration. Administrativeautonomy considerations imply that the actualestablishment of agreements must be effectively formed and transparent for regular user as much as possible. A number of users connected to LANs permanently grows, the network topology is becoming more and moresophisticated and as a result of that the rightadministration become more important. However theglobal network management should not involve anordinary user. The meaning is that the changes of network topology or other parameters would not requireadditional operations on client's computer.

One of the solutions for the problem described is a proxy enforcer. The proxy enforcer is an application that runs on a gateway or a firewall machine and completelytransparent to the end user. It collects all packets that were sent from the local network hosts to the outside Web servers and redirects them to proxy.Using of a single proxy can lead to the known"bottleneck" problem on the proxy. In order to reduce the load a special proxy routing protocol is used. Itdistributes outgoing client requests among array ofproxies, namely cache array routing protocol (CARP) [1-3]. So that the requirements for the routing will be one of the following (or both):• the request is routed in such a way that the same

URL is redirected to the same proxy, if possible allowing avoiding many downloads of the same file

Proceedings of the IEEE/WIC International Conference on Web Intelligence (WI’03)

0-7695-1932-6/03 $17.00 © 2003 IEEE

from the remote server and to use its local copy stored on one of the local network proxies.

• the request is routed to the proxy with the minimal load factor allowing avoiding the bottleneck problem [2].

In this research we present design and implementation of cache CARP. The system can run with the new releases of host servers that have an ipfw built in [4].

The organization of this papers is as follows. In section 2, we present an overview about the CARP and related work to the current research. In section 3, we present an over view about the system. The main constituent units of the system are discussed in dedicated sub-section. In section 4, full details of the system design, modules and interfaces are comprehensively discussed in details. In section 5, we discuss the implementation features of the system. In section 6, we present the testing results for the system that showed an excellent performance. We end by conclusion in section 7.

2. CARP and Related Work

The CARP describes a distributed caching routingprotocol based on known membership list of looselycoupled proxies and hash function for dividing URLspace among those proxies [3,5,6]. The Proxy ArrayMembership Table (PAMT) is defined as a plain ASCIItext file retrieved from an Array Configuration URL.CARP was designed as a potential replacement for the Internet Cache Protocol (ICP), the existing Internetstandard for caching protocol, currently implemented in Harvest and Squid proxy cache packages [6-8]. WithCARP it became possible to create arrays of proxyservers, which work like a single virtual proxy server cache. There are two powerful benefits of CARP are [9]:• It uses hash-based routing to provide a deterministic

request resolution path. Because of this there is none of the query messaging between proxy servers would occur. On the contrary of the ICP whichcreates a heavier congestion of queries as thenumber of server’s increases.

• It eliminates the duplication of contents that occurs on an array of proxy servers. With an ICP network, an array of “n” proxy servers can rapidly evolve into essentially duplicate caches of the most frequently requested URLs. The hash-based routing of CARP keeps this from happening, allowing all “n” proxy servers to exist as a single logical cache. The result is a faster response to requests and a more efficient use of server resources.

ICP was designed with hierarchical cache in mind, and assumes that at any given single point in the hierarchy only one or two ICP servers as maximum are needed. CARP also supports hierarchical routing, but in addition it provides the possibility to build a large cache array at one of the levels of hierarchy [3].

Internet

Packet/inPacket/out

Packet Filter

Enforcer Port

session isredirected

to thecache

enforcer'sport

LAN

Proxy 1 Proxy 2 Proxy n

Transparent zoneto the user

Client Host

Remote WebProxy

ROUTER

Figure 1: General View of Proxy Auto Confi guration System Modules

CARP makes it possible to plug additional servers into the cache array or remove a server from the array without massive reconfigurations and without significant cache reassigning. Its cache-management features provide both load balancing and fault tolerance [3].

3. System Overview

Generally the caching Web server is used to cut down on overall network traffic and to provide advancedadministrative control over web traffic routing. In which the proxy server is able to make routing and filteringdecisions and to log every access with the URL and the client IP address.

One of the main disadvantages of the web caching is the tunneling effect, which can increase network load at a local level, since accesses to local Web servers will normally go via the cache, causing two trips over the local net, rather than one. In addition to that caching is not suitable for all network content.

A caching proxy server acts as an invisible intermediary between a client browser and the servers that providecontent [10,11]. This is an effort to make use of the caching principle of temporal and spatial locality. In the case of a web cache, cacheable objects are alwaysseparate and are always read in their entity with noprefetching. The only spatial locality we get is thatseveral requests may go to the same server, and then we get a benefit from HTTP keep-alive. Since the client browser always talks to the same cache, keep-alive is quite beneficial [12].When we started to design the system we took into consideration the following essential features:• should have scalable architecture


0-7695-1932-6/03 $17.00 © 2003 IEEE

• intelligent in a sense not to add a work load to the running systems and handles the URL hashing in a complete transparent way, so the user client will not feel any of the processes behind his end socket, and

• user friendly.

All these features were achieved by using a novel module called “Proxy Auto Configuration System Module”(PACSM). The PACSM is a of special format that can reside anywhere on the shared network and up to nowhard to attack or by passed by the normal known kernel attacks to the networked systems [4,13]. This will allow an auto run browser proxy configuration for networked machines and installs all the suitable modules for the client’s operating system, see Figure 1. The user will run the setup file on the network only one time. When setup runs successfully, it allows dynamic assignment of proxy servers and ports. This is especially suitable for bignetworks, as once the client’s machine is setup, only one machine needs configuration.

3.1 Proxy Cache Scalable Architecture

The idea of using CARP with Automatic ProxyConfiguration protocol is to implement the Java Script (JS_function) FindProxyPorURL() using distributed caching proxying based on URL hash computing [14-16].The advantages of this approach are:a. the hash based URL routing allows performance of

deterministic URL routing, b. have a small latency for URL routing, c. provide no duplicated objects, efficient caching,

afford predetermined load balancing, andd. security access point of that guarantee no new

protocol is introduced.

Because all of the above reasons it would allow us to have a real scalability in the cache proxy architecture.

3.2 The URL Hashing

Assume there are “n” caching proxies. In order toperform hash computation for each URL, i.e., convert URL string into unique and random integer number by computing checksum and modulo, then we have tocalculate the hashing function “i =Modulo(checksum(URL),n)” for each requested URL.Then route the client request to i-th proxy. The advantage of this is that the hash based URL routing will be having the same URL routed to the same proxy which assures cache hits.

In our implementation we designed the ProxyJS_script that is provided from client’s Web server. So the clients browsers’ will download the same proxyscript [17]. Note that this hash function is designed to provide equal load balancing up to 100 proxies or any precise load balance design.

In this respect the proxy array could be configured as a cache disk array to afford running multiple proxies in the same machine in which each proxy controls cache disks. Note that disk heads seek in parallel. Then the diskconcatenation is achieved by M (in GB) disk x n proxies = m x n (in GB).

In order to make use of URL proxy hashing transparent for client we have to make redirector proxy with URL hashing working on router, redirect all connections from the router to the redirector proxy and configure clients to use direct connection.

4. System Design

The system is designed to run a proxy enforcer task. This enforcer is composed of several units and modulesincluding controlling and supporting interfaces. Even though it has a fairly complex structure, but it runs very smooth and as we stated before it is completelytransparent to the user and light weight as well. Some of these modules will have an administrator interface while other has not. In the following we will describe these main units along with their conjugated interface if any.

Packet catcher)

Client

Non HTTPCatcher

OutgoingRouter

HTTP Packet

PacketURL

Result of HTTPRequest

Internet

Proxy 1

Router

Packet Filter

TCP Port

TCP/IP Data Link Frame

IP Packet

HTTPPipe 1

JS_Interpreter

SELECT URL

SysAdmn(Configuration

Loader)

Proxy 2

Proxy n

.

.

.

PROXY ADDRESS

ConfigurationFile

PROXY SELECTOR UNIT

PACKETCATCHER UNIT

PROXYDISTRIBUTOR

UNIT

HTTPPipe 2...

HTTPPipe x

RemoteWebProxy

PROXYREDIRECTOR

UNIT

Figure 2: Packets task flow for the enforcer among different system’s units

The proxy enforcer consists of following main three units (see Figure 2), • the IP packet catcher unit, • the packet redirector unit, and • The proxy selector unit. The work flow of the proxy enforcer could be seen in the following steps: • The IP packet catcher waits for IP packets sent to the

firewall machine and forwards them to the packet redirector.


0-7695-1932-6/03 $17.00 © 2003 IEEE

• Then the packet redirector forwards packet to one of firewall proxies.

The hash function plus routing algorithm defined in this document take member proxies described in the Proxy Array Membership Table and make an on-the-flydetermination as to which Proxy Array member should be the proper receptacle for a cached version of aresource keyed by URL. Downstream agents may then access the cached resource by forwarding the proxied HTTP request for that resource to the appropriatemember of the Proxy Array.

4.1 IP Packet Catcher Unit

LoadRules()

FindProxyForURL()

JSCacheRedirector

execution result

script Interpreter

stdin

stdout

map of nativefunctions

map of interpretedfunctions

JS Environment

Figure 3: IP Packet catcher

The main purpose of IP packet catcher is to collect the packets arriving to the firewall and send them to packet redirector (see Figures 2 and 3). Notice, that not all the packets would be sent to the redirector but only those with certain target HTTP ports (in our case there are 80, 8080, etc). There are several methods to catch IPpackets.• The first method is to use special firewall packet

filter that redirects all packets from the inside HTTP client to our application running on the firewall host through which the application runs on user level.This method is more flexible for future changes and easy to implement. But, it is not suitable for heavy traffic in a local network. From security point of view we can monitor only packages for the specific ports also [18-21].

• The second method is to implement the code on the operating system kernel level. The advantage of such approach is that the application accesses the kernel data structures without any additional processes and can easily change them. It simplifies packet routing and allows increasing system performance [12, 22].

In this research we made the use the first method of firewall with packet redirection for IP packet catcher in order to afford the system as an easy ad-hoc module to the ipfw.

4.2 Session Redirector Module

This module implements the IP packet catcher unit. It uses transparent proxying technique to redirect TCPsessions to packet redirector. This is not only relying on special user-level software (modified proxy servers), but it also requires kernel-level support, which is nowincluded in Linux Red Hat [23].

Transparent proxying redirects sessions passing thefirewall to packet redirector in a fully transparent way. clients do not know that their session is handed over to our program process and they still think they have adirect connection with the target they specified. Because it relies on port numbers, transparent proxying onlyworks for TCP or UDP traffic. In the Linux Red Hat kernel, packet redirection for transparent proxying ismainly handled by the input firewall [24-25].

4.3 Packet Redirector ModuleThe main goal of the packet redirector is to detect the type of HTTP request and forward it to the correct proxy.After the request type detection, the catcher decides whether the HTTP request must be changed before the redirection. In case of direct server request, a protocol type and the full URL are to be added. In this research the packet redirector is implemented as Unix-like daemon by which we implemented the following two servicemechanisms will run:a. When a normal HTTP request is made by a client, the

HTTP server gets only the path and keyword portion of the requested URL; other parts, namely theprotocol specifier "HTTP:" and the hostnames areobviously clear to the remote HTTP server. Therequested path specifies the document or a CGI script on the local file system of the server.

b. When a client sends a request to a proxy server the situation is slightly different. The client always uses HTTP for transactions with the proxy server even when accessing a resource served by a remote server using another protocol, like FTP. However, instead of specifying only the path name and possibly searchkeywords to the proxy server, the full URL isspecified. Through this the proxy server has all the information necessary to make the actual request to the remote server specified in the request URL [26-27].

4.4 Proxy Distributor UnitWhen the connection is established, the proxy distributor spawns a new process. The parent process is continuingto listen to the incoming connections while the new one processes the client request. Request processingincludes the following seven main steps (see Figure 2)• Step 1: get HTTP request from the client. • Step 2: get array of proxies for the requested URL

by calling Proxy selector unit for that URL• Step 3: change the request from server format to

proxy format (from security point of view, if proxy is specified as different from the return proxydefined by Proxy selector the request will be also stopped and logged.)

• Step 4: connect to the selected proxy. If, for any reason, proxy is unavailable then the next value from the array returned by Proxy selector will be used. If there are no more proxies in the array, an error will


0-7695-1932-6/03 $17.00 © 2003 IEEE

be sent to the client and connection terminated (see Appendix A for the respective error message.)

• Step 5: forward changed request to the proxy.• Step 6: wait for proxy reply. • Step 7: forward reply to the client using opened

connection.

Normally the connection first must be closed by proxy.In this case the proxy distributor sends all buffered data to the client and closes connection to it. If theconnection is terminated by client before the proxy, this will conclude an error condition. In such situation the connection to the proxy will be immediately closed.

The Proxy distributor provides logging facility in which all main parameters of all connections are logged bystandard syslog facility provided by the operating system.

4.5 Proxy Selector Unit

Proxy selector is a unit that defines the policy of load balancing. It gets the URL as an input and returns address of the proxy as an output. It aims to provide the list of available proxies ordered from the most preferable proxy to least preferable one.

Proxy Selector supplies selection services includingredirection rules loader that loads the specific rules for generating of redirection list. the proxy list generator generates list of proxies that can be used to redirect the request to the proxy cache according to the loadedredirection rules.

5. Internal Application Implementation

The main class of the proxy enforcer is the classHTTPServer. Since it is the main process of the program from user point of view, it must be started by operating system at boot time. Also it providesappropriate services as waiting for connection,connection establishing, closing

HTTPPipe

Client

Client SocketHTTP request

HTTP response

Pipe SocketHTTP request

HTTP responseProxyServer

Figure 4: HttpPipe

connection. It is able to create and initialize HTTPPipe object, see figure 4 (when connection is established).

The HTTPPipe object determines the address of the appropriate proxy according to target's URL and create the stream pipe between this proxy and the client. The class HTTPPipe is a process created by HTTPserver. It is responsible for handling of single http clientconnection. It parses connection input stream trying to find http request header. When the http header is found

the requested URL is fetched. Then proxy selector is asked for the proxy array that is suitable for this request. The request is changed and redirected to the first proxy server from proxy array. If the connection failed the second proxy server is used etc. When the answer is received from the proxy server the HTTPPipe redirects it to the client. When client or proxy server closes the connection, HTTPPipe exits. Each connection can serve several http requests because of http protocol keep alive option.

When the HTTPServer starts, it performs the following initialization tasks: • Initialize proxy selector by calling Init() function. • Register TERM signal handler: This handler will

carefully shutdown the application. • Register HUP signal handler: This handler will force

proxy selector to reload its redirection rules. • Create listen socket on predefined port. (ipfw will

redirect all connections from port 80 to this port.)• From this step it waits for connection on a

predefined port. When the connection is established a new HTTPPipe process is created to serve the request.

The configuration file for HTTPpiped is /etc/httppiped.conf and it contains the following information:• server port number: the port number of server listen

socket.• internal address: address of local network interface. • external address: address of interface connected to

Internet.• pacfile: path to "pac" file containing proxy

redirection rules.

6. Testing Environment and Results

Mirror 1/ WebServer 1




Load Balancing Server



Cisco 2507

Cisco 4000

WebServer 1

WebServer 2

WebServer 3

Cisco 7000

NET114 users

Simulated Users'WorkStation1



WWW

link 1

link 2link 3

link 4link 6

link 5link 7

link 8

link 10

link 11

link 12

link 13

link 9

Load Generator

NET225 users

NET38 0 users

CARP ENFORCER BOX

Cisco 2507

ProxyArray

10proxy

servers

Figure 5: Testing Network

The testing network in this research is a small-scaleprototype intended to expose design issues and act as platform that simulates the real operational environment.The system is composed of a fairly complex structure as


0-7695-1932-6/03 $17.00 © 2003 IEEE

shown in Figure 5. The two simulated users’ inside the systems run 3000 simulated users each. Another “real users” are logging in via different nets as could be seen in Figure 5. The one outside the system simulatesanother 1500 users. The purpose of the enforcedallocated band width for each link is to representdifferent clients with their different link connectiontopologies and technologies. Table 1, lists the allocated bandwidth per each link and the enforced latencyparameters.

Table 1: Operational Parameters for the testing NetworkLink # Allocated Band

Width/MbpsEnforcedLatency/

ms1 6.000 152 2.000 183 0.100 164 2.000 145 0.110 206 0.384 147 0.080 128 0.256 189 0.384 1510 10.00 1011 40.00 512 50.00 213 0.056 20

The CARP enforcer box is installed on Linux red hat box with an ipfw built in. The array of the ten proxies are linked with Cisco 2507 that have a built in hub facility.The topology for each one of the proxy serve rs was simulated to have different hop distance from the CARP enforcer box. The load generator system runs Gstone workload generator which is used to adjust the amount of load on each server throughout the duration of the test [29]. The importance of this feature is to benchmark the tolerance of the system were some clients in realenvironment that tries to increase the number of hits drastically the proxy server in order to detour it via a third party proxy. Passive packet trace measurements are taken both at the clients’ and at the severs’ side. We used the technique of gathering packets level data at certain tap points, mainly before and after the CARP enforcer box, during this research we used tcpdump [30].Active measurements of the connections path arecollected during each transfer using Poisson Ping which

sends UDP packets along the same path as theconnection and measures the time averaged network state [31].During testing, two of the running servers wereconfigured to run performance monitoring tools so that detailed CPU, memory and network characteristics can be made during tests.

We were influenced by Paxon’s Network Probe Daemon study in terms of the number of remote sites we would like to have contacted within our system [32].

In table 2, we list part of our results for measuringeffective latencies with and without including oursystem. A very good performance is obvious for the two case of workloads low and high.

7. Conclusion

In this research, we presented a CARP enforcementcompliant proxy system. This system supports httpprotocol and the system can be installed within thefirewall host or gateways. It can work with any Unix-likeoperating system that implements ipfw within its kernel.

The system is completely transparent to the client, and on the contrary it adds up more efficiency to the user in terms of reducing latencies within the caching boxes.

This system was implemented and tested under LinuxRed Hat 9. It showed successes in providing a friendly operational environment for administrators withoutadding overload to the system or presents a bottleneck due to the fast algorithms constructed within it. One of the advantages of the system is that it can beimplemented within major ISP system that have multi proxy environment without adding latency to theoperation.

The proposed system showed an excellent performance in the different case of the servers workload. Also the system showed a very promising results in protectingnetwork resources against bypassing the present proxies and accessing security policy violating surfing via third party proxy.

Table 2. Comparative Summary of Network Performance under Using the CARP Enforcer System

FileSize/KB

Server

Load

numberof

TransferredFiles

MeanLatency

With CARPEnforcer

MeanLatency

Without CARPEnforcer

Std. Dev.Latency

Tcpdump%

packetloss

Poip%

packet loss

Poip meandelay

1 low 5000 0.173 0.235 0.058 0.00 0.00 0.02920 low 2500 0.445 0.678 0.173 0.09 0.10 0.032500 low 1500 2.033 2.554 0.213 0.00 0.10 0.0361 high 800 0.911 1.256 0.913 0.10 0.10 0.02620 high 600 1.106 1.662 1.004 0.10 0.10 0.029500 high 200 3.531 4.125 1.204 0.00 0.10 0.032


0-7695-1932-6/03 $17.00 © 2003 IEEE

8. Future Work

This research was restricted towards serving the http protocol. Currently we are developing another version that can support the other TCP/IP services. In addition to implementing it under the free BSD as well.

The next step in this research is to implement the code within the operating system kernel itself. This method will be much more effective, in which the application has a direct access to the operating system kernel memory, and no copying of data from kernel to user address space is needed. This avoids time consuming process, decrease the time of processing. From security point of view this is the best method by which we can monitor of all IP packets received by the kernel.

AcknowledgmentsI would like to thank Etisalat Academy for using its Testing Laboratory during running my codes. Also Iwould like to thank Cisco Systems-Dubai for providing major part of the needed hardware to perform thisresearch..

REFERENCES[1] A. Fledmann, et. al., Performance of Web Proxy

Caching in Heterogeneous BandwidthEnvironment, Proc. of IEEE INFOCOM, 1999,106-116.

[2] B. Duska, et al., The Measured AccessCharacteristics of World-Wide-Web ClientProxy, Proc. of the Symposium on InternetTechnologies and Systems, USENIX, 1997, 23-35.

[3] V. Valloppillil and K. Ross, Cash Array Routing Protocol 1.1, Feb 1998, Internet Draft, <draft-viond-carp-vl -0.3txt>.

[4] CERT CVE,http://cve.mitre.org/cve/refs/refmap/source-CERT.html

[5] Microsoft Corp., Microsoft Cache Array Routing Protocol. White paper

[6] D. Karger, et. al., Web Caching ConsistentHashing, Computer Networks, 31(11-16), 1999, 1203- 1213.

[7] D. Wessels, K. Claffy, Internet Cache Protocol (ICP), version 2. RFC 2186, Sept. 1997.

[8] D. Wessels, Web Caching, O’Reilly, Sebastopol, CA, 2001.

[9] Squid Web Proxy, http://www.squid-cache.org/.[10] A. Mahanti, Traffic Analysis of a Web Proxy

Caching Hierarchy, IEEE Network Magazine, June 2000.

[11] G. Phillips, et al., Scaling of Multi-cast Trees: Comments on the Chuang-Sirbu Scaling Law, In Proc. of ACM SIGCOMM'99, Harvard, 1999, 41-51.

[12] G. Barish and K. Obraczka, World Wide WebCaching: Trends and Techniques, IEEECommunications, Internet Technology Series,May 2000.

[13] Java HTTP Proxy Vulnerability, http://www.der-keiler.de

[14] L. Fan, et. al., Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol, Proc. ofSIGCOMM'98, pp., 1998, 254-265.

[15] P. Rodriguez, et al., Analysis of Web CachingArchitectures: Hierarchical and DistributedCaching, IEEE/ACM Trans. On Networking, 2001.

[16] G. Paxson, et. al., Framework for IP Performance Metrics, IETF RFC 2330, 1998.

[17] Super Proxy Script, Sharp Corp.,http://naragw.sharp.cojp/sps/.

[18] A. Wolman, et. al., On the Scale and Performance of Cooperative Web Proxy Caching, OperatingSystem Review, 34(5) 16-31, 1999.

[19] D. Karger, et. al., Web caching with Consistent Hashing, Proc. of the8th Int. World Wide Web Conf., 1999.

[20] K.W. Ross, “Hash-Routing for Collections ofShared Web Caches”, IEEE Network Magazine,11(7), 1997, 35-44

[21] J. Wang, “A Survey of Web Caching Schemes for the Internet”, ACM Computer CommunicationReview, 29 (5), 1999, 36-46.

[22] R. Tewari, et. al., Beyond Hierarchies: DesignConsiderations for Distributed Caching on theInternet, Technical report TR98-04, Univ. of Texas at Austin, 1998.

[23] Linux Firewall, www.fokus.gmd.de.[24] The linux NetFilter, http://www.netfilter.org.[25] O. Sptscheck et. al., Optimizing TCP Forwarder

Performance, IEEE/ACM Transactions onNetworking, 8(2) 146-157, 2000, 146-157.

[26] I. Cooper, et. al., Web Replication and Caching Taxonomy, IETF Internet draft, RFC 3040, 2001.

[27] A. Rousskov and D. Wessels, Cache Digests,Computer Networks and ISDN Systems, 30, 1998, 22-23.

[28] K. Claffy and H. Braun, Web TrafficCharacterization: an Assessment of the ImpactCaching Documents from NCSA's Web Server,Proc. of the 2nd World Wide Web Conference '94, 1994.

[29] The Web Workload Generator SURGE,www.net.uni-se.be.

[30] Tcpdump, http://ftp.ee.lbl.gov/tcpdump.tar.Z.[31] A. Adams, et. al., creating a Scalable Architecture

for Internet Measurement,http://www.psc.edu/~mahdavavi/nimi-paper/NIMI.html.

[32] V. Paxon, End-to-End Internet Packet Dynamics, Proc. ACM SIGCOMM, 1997.


0-7695-1932-6/03 $17.00 © 2003 IEEE