| |||||||||||||
Xtables2 vs. nftablesXtables2 vs. nftablesPosted Jan 15, 2013 5:41 UTC (Tue) by malor (subscriber, #2973)In reply to: Xtables2 vs. nftables by intgr Parent article: Xtables2 vs. nftables Right now each firewall rule has to stand on its own and you get no control over which order certain terms are evaluated. Are we talking about the same thing? The language you're using in your examples isn't anything I recognize as being iptables-related, and I don't see anything being done with chains, which is kind of the point of the whole system. Are you confusing it with something else, maybe? In iptables, there are five root chains in the network stack: PREROUTING, FORWARD, INPUT, OUTPUT, and POSTROUTING, plus any arbitrary number of user chains inserted wherever one likes. Typically, the great majority of the work is done on the FORWARD and INPUT chains. Because you can have any number of chains, it's fairly typical to 'divide and conquer'; that is, test if it's a TCP packet, and jump to a TCP chain, which then checks for port matches, and then makes decisions. And this full evaluation process is not normally followed for every packet; typically, packets that match the keywords ESTABLISHED and RELATED are short-circuit accepted, without any further processing, and this basically consists of a lookup in a connection table. So it's really fast with most of the packets in a session (usually all but the first couple). Novel packets, ones that either signify a new connection or are unwanted, are usually navigating down a tree of tests, which means that any given packet won't usually need very many decisions. I imagine this condenses down into quite a short number of actual hardware instructions. Whatever the internals actually look like, it certainly seems efficient, as a Linux router/firewall is able to move a very large amount of traffic without needing dedicated hardware support. So, a virtual machine is cleaner, but probably less efficient. And I'm wondering if a general code cleanup on the existing system might not end up being better. I cheerfully concede that it's ugly as hell, but it seems very, very fast. That's an absolutely critical feature in firewalls, perhaps the crucial feature, after being able to do basic stateful inspection. The nastiness with having to pass off to user processes for advanced inspection is something that only people who want that functionality have to deal with, where putting a VM in there may potentially slow everyone down, making all of us pay for a few corner cases that most of us have no interest in. All I really care about is speed, so if they can make the VM run as fast as regular iptables, then I have no other objection. It's not like my objection really matters anyway, I don't suppose, since I'm not writing the code, but still.
(Log in to post comments)
|
|||||||||||||