The first important design choice concerns the flow of the packet traffic
to and from the Web cluster. All client requests reach the Web
switch, so the most important difference is how the responses go to the
clients. In so called two-way architectures, server responses are
directed towards the Web switch, which directs them to clients.
In one-way architectures, responses are sent by the servers directly
to the clients, thus bypassing the Web switch.
One-way architectures limit the risks of system
bottleneck at the Web switch due to forward and backward handling of
each packet. The problem is that a
layer-7 one-way architecture is much harder to be implemented than a two-way switch because the distributed architecture must remain transparent to both the user and the client application.
Hence, each Web server must be able to change the
response packets in such a way that they seem
coming from the Web switch which is the only official interface for the
Our one-way solution is based on the TCP Handoff mechanism that has been
implemented on Linux operating system.
We point out the problems we had in designing efficient core
components of the TCP Handoff mechanisms, and give
also some hints on how to address issues in SMP practice.
To describe the operations performed by the nodes of a Web cluster,
we detail the sequence of events activated by
a client request. To this purpose, we refer to the
time diagram in Figure 1.
High level view of the TCP Handoff mechanism.
A client process connects to the Web switch through the standard TCP/IP
protocol. The switch tries to establish a TCP connection with the client
through a three-way handshake. Next, the client
sends a request. The switch parses the request and extracts
the application-level information, such as URL,
cookies or SSL identifiers. Next, the switch chooses a
Web server among those which are able to serve the requested
content. The switch then transfers the TCP connection to
the chosen Web server, along with the client request.
The Web server re-creates the TCP connection in the same
state it was before being transferred. We refer to the
connection state as to the set of necessary information
for cloning the connection on a different node.
Once the connection has been transferred, the client request is
inserted into the server process queues. The server builds
a response and sends it directly to the client, thus acting as
if it was the Web switch.
The client receives the response packet and sends an acknowledgement
(but also future requests, if the HTTP/1.1 or persistent TCP
connections are used) to the Web switch. Those packets cannot
be sent directly to the server because the client continues to
have the impression that the connection is established with the Web switch.
Thus, the switch must keep forwarding client and ACK packets until the
TCP connection is closed.
Next:Efficiency requirements Up:Design of a scalable Previous:Design of a scalable