Thomas, Yes, I see your point that it is efficient to do specific matching rather than a generic one. The idea what you have proposed through the steps is very clear. Would try your work on our campus once you are ready.
Continuing the discussion further, may be performance impact for the text based searches, as in this case, have to be assessed based on per-application and user behavior rather than guided by generic set of rules. For eg., for http we can take into consideration i) Parsing of urls typically occur once during GET and at the beginning of a new connection and not for every packet ii) Persistent connections, if used, increase the duration of the existing connections, thus reducing the fraction of the time spent during the initial text search iii) User think times between requests iv) Related to i), and ii) the average life times of connections compared to the url parsing time v) Other exploits like caching Not sure if what I said above makes too much sense. Basically I am wondering if it is possible to make a system work better by examining its behavior on the kind of applications we run. Regards Anand On 8/8/05, Thomas Graf <[EMAIL PROTECTED]> wrote: > * 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
