On Thu, Mar 24, 2011 at 05:14:29PM -0600, Jason J. W. Williams wrote:
> >
> > Anyway the purist in me will say that this is not NAT, as there is no
> > relation between the packets of each side, this is still proxying but
> > with spoofed addresses.
>
>
> Hey, I don't care what HAProxy wants to call it...y'all have it is all that
> matters for me. :)
>
> I just come from a traditional HW SLB background where it's called half-NAT.
Excuse-me for insisting, but this is still different and the difference matters. When a component does NAT (half, full, etc...) it is in the middle of the connection, it just mangles *packets* but does not interact with TCP management (congestion window, segmentation, etc...). The end point still is in charge of the session management. That means that if the server uses small windows or emits lots of small packets, the client will be affected by that. In turn, if the server's TCP stack has some vulnerabilities, they will be exposed.
With a proxy, the connection from the client is terminated on the proxy and another connection is established with the server. Data are copied between those two connections. This means that the issues above do not happen, but that in turn the proxy's TCP stack must be properly tuned. A proxy also enables protocol conversion and MTU adaptation. You can run jumbo frames on your internal network, and you can offer IPv6 service from an IPv4-only server farm.
Last, doing L7 transformations on packets is a nightmare and generally doesn't work very well, because retransmits, fragments and out-of-order packets are hard to handle. Doing them on a buffered stream is a lot easier. Nowadays, almost all L7 load balancers involve proxies, even if they're not explicitly shown. A few L4 LBs with some L7 features still work on packets and cause a lot of issues when L7 is enabled.
None is better than the other for all tasks. However, L7 should always be performed by proxies, while L4 is often better done by "packet switches".
I hope this clarifies the difference.
Regards,
Willy
Received on 2011/03/25 06:20
This archive was generated by hypermail 2.2.0 : 2011/03/25 06:30 CET