|
Hi Alexandre,
> You need to bridge the traffic in order to perform accurate layer7
> switching decision especially for HTTP/1.1 where multiple requests are
> sent into the same persitent connection. So L7SW must be a proxy but a
> high speed proxy. I mean, with the current design, socket API is used in
> order to have a compatibility layer with current proxy software and
> proxy design, but as soon as the socket are spliced the socket context
> for each connection is released. tcp_splice module create a layer4
> forwarding rules, so packets are switched from on side to the other just
> with the same performance as layer4 switching system (IPVS). We just
> have context switching overhead induced by client GET request relaying
> from client to server. Parallel balancing can be handled by an upper
> layer4 balancing system (IPVS) to a pool of L7SW.
What about the TCP sequence masquerade for incoming & outcoming packet of
the fake pipe after scheduled (Given at this time, the real connections
to bridge the client and real server has been released), on which I think
the TCP splicing will base. The masquerade may consume a bit CPU time.
I think one NIC with TCP/IP checksum capability may be a good auxiliary
thing to implement splicing-style L7 switch, right? :-)
On the other hand, to do Parallel balancing, the sole toplevel ipvs L4
director that you said, brings in another new performance bottleneck,
I think.
Cheers,
Jinhua
|
