One-way architecture

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 clients. 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.

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.