|
Hi,
> As I know, TCPSP'work as follows:
> 1. Client builds up the connection with director firstly.
> 2. After the director receives the client requests, then
> sets up connection with selected real-server and sends the
> requests to it.
Yes parse client request at layer7 level, then select
the remote realserver to connect to (run the loadbalancing
algorithm). When selected, it create a new socket to remote
realserver elected.
When remote realserver is connected it forward at layer7
the incoming client request. But here with linux kernel we
have zerocopy provision, so the client request is forwarded
to realserver elected using linux zerocopy provision to speed
up the forwarding processing.
> 3. Real-server send replies to director.
> 4. Director receives the replies from the realserver and
> responses to the client through tcp-splicing.
To speed up process, both socket are spliced when realserver
has been elected and connected that way we optimize time for
upstream forwarding.
After there is a need to know how to unsplice socket pair...
unsplicing can be done using the application specific header
to detect end of stream forwarding. For HTTP/SSL we can use
for example the "Content-Length:" header value to detect
end of stream and to unsplice socket pair. But For efficient
applications and because most of webserver are using HTTP/1.1
there is a big benefit keeping as possible the socket pair
spliced since client->webserver are using "HTTP/1.1 keepalive"
connection (persistent), so that remote webserver still connected
after the first GET is processed. This optimize the forwarding
but here it is more difficult to know when socket pair must be
unspliced...
Best regards,
Alexandre
|
