* Anand SVR <[EMAIL PROTECTED]> 2005-08-08 15:07
> I am happy to know that there is a way of achieving http level packet
> classification once the connection tracking is also in place. We can
> even think of other string combinations for url based classification,
> not just what I mentioned in my earlier mail.
We already have a generic textsearch infrastructure which allows
for simple string matchings but also regular expression alike
matches so almost everything is possible already except for the
flow tracking part which should be quite easy to complete. The
problem with generic string matches really is efficiency, even
with dport filters in front and a fast path for flows already
classified the filtering is still way to expensive if at least
some accuracy is a requirement when parsing the HTTP header.
Therefore I propose to add some kind of specific ematch which
at least partially understands the HTTP header, maybe a small
example of what I have in mind helps:
(1) protocol tcp and destination port 80
(2) have we seen this flow before and is it classified?
-> goto fast path
(3) is a frament? -> ignore
(4a) assume http header starts at 4th layer and assume
a good default value for the maximum length of the
header and use the generic string matchers.
... or:
(4b) assume http header starts at 4th layer and parse
http header to find out its length and allow to
apply string matchers on a specific id=key pair
in the http header.
> All said done, since most of the traffic is anyway dominated by http,
> I feel it is worth providing differentation among the competing web
> flows. No ?
I agree with you, it was never an issue to me so far but I
can surely understand the importance of this to other folks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
