The server, which receives the request from another node, generates and encrypts
the dynamic contents using the forwarded session key. Finally, it returns the reply
to the initial node, which sends the response back to the client.
Figure 4.3 depicts the ssl with bf model. Application servers in the cluster are
interconnected through a SAN. Steps 2 and 3 in Figure 4.3 show the backend forwarding
scheme between the cluster nodes. This backend forwarding uses the low overhead user
level communication like VIA/IBA to minimize the intra cluster communication latency.
The requests arriving at the webswitch of the network server are sent either to
the Web server layer or the application server layer according to the requested service
by the client. Since the SSL connection is served by a different type of http server (https)
and a different port number, the requests for the SSL connection are passed on to the
distributor in the application server layer. To solely focus on the performance of the
application server, we ignore the latency between the webswitch and the distributor,
and logically represent them as one unit.
When a request arrives at the distributor, it searches its lookup table to determine
whether there is a server which has the session information of the client, and then
forwards the request to the server. Otherwise, it picks up a new server to forward the
request. The forwarded server establishes a new SSL connection with the client. If the
request is forwarded to a highly loaded server, the server in turn sends the request with
the session information to a lightly loaded server.