Re: [Linux-l7sw-devel] [ANNOUNCE] New Layer7 switching project

[home_king <hom...@16...>]

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