mod_qos

In computer networking, the term quality of services (QoS) describes resource management rather than the quality of a service. Quality of services implements control mechanism to provide different priority to different users, applications, and data connections. It is used to guarantee a certain level of performance to data resources. The term quality of service is often used in the field of wide area network protocols (e.g. ATM) and telephony (e.g. VoIP) but rarely in conjunction with web applications. mod_qos is a quality of service module for the Apache web server implementing control mechanisms that can provide different priority to different requests.

But why do you need quality of service for a web application? Well, web servers require threads and processes to serve HTTP requests. Each TCP connection to the web server occupies one of these threads respectively processes. Sometimes a server gets too busy to serve every request due the lack of free processes or threads. Another parameter requiring control by mod_qos is the available bandwidth: all clients communicates to the server over a network link with a limited bandwidth. Overfilling the link, results in network congestion and poor performance.

Example situations where web applications require QoS:

• More resources are consumed if request processing takes a long time by an application, e.g. when request processing includes time consuming database queries.
• Oversubscription of link capabilities due too many concurrent clients uploading or downloading data.
• Penetration of the web server by attackers (DDoS).

mod_qos may be used to determine which requests should be served and which shouldn't in order to avoid resource oversubscription. The module collects different attributes such as the request URL, HTTP request and response headers, the IP source address, the HTTP response code, history data (user session and on per source IP address basis), the number of concurrent requests to the server (total or requests having similar attributes), the number of concurrent TCP connections (total or from a single source IP), and so forth.

Counteractive measures to enforce the defined rules are: request blocking, dynamic timeout adjustment, request delay, response throttling, and dropping of TCP connections.

The current release of the mod_qos module implements control mechanisms to manage:

• The maximum number of concurrent requests to a location/resouce (URL) or virtual host.
• Limitation of the bandwidth such as the maximum allowed number of requests per second to an URL or the maximum of downloaded kbytes per second.
• Limits the number of request events per second.
• It can also "detect" very important persons (VIP) which may access the web server without or with fewer restrictions.
• Generic request line and header filter to deny unauthorized operations.
• Limitations on the TCP connection level, e.g. the maximum of allowed connections from a single IP source address or dynamic keep-alive control.
• Prefers known IP addresses when server runs out of free TCP connections.

mod_qos is available at SourceForge.net under the GNU General Public License.

More information about mod_qos:

• Build
• Source
• Changes
• Configuration
• Request Level Control
• Events
• Request Level, Generic Filter
• Connection Level Control
• Client Level Control
• Log Messages
• Error Log
• Access Log
• Request Statistics
• Status Viewer
• User Interface
• Use Cases

Source

mod_qos is available for Apache version 2.0 and 2.2.

Configuration

Configuration is made on a per server basis (except the generic request filter). Commands within a virtual host overwrites the global configuration (requires the definition of a QS_LocRequestLimit*, QS_LocRequestPerSecLimit*, QS_LocKBytesPerSecLimit*, QS_CondLocRequestLimitMatch, QS_EventRequestLimit, QS_EventPerSecLimit, QS_SrvMaxConnPerIP or QS_SrvMaxConn directive).
The QS_SrvMinDataRate, QS_SrvRequestRate, QS_SrvPreferNet, QS_RequestHeaderFilterRule, and all QS_Client* directives may be used outside of virtual host configurations only.

Request Level Control

• QS_LocRequestLimitMatch <regex> <number>
  Defines the number of concurrent requests for the specified request pattern (applied to the unparsed URL). The rule with the lowest number of allowed concurrent connection has the highest priority if multiple expressions match the request. By default, no limitations are active.
• QS_LocRequestPerSecLimitMatch <regex> <number>
  Defines the allowed number of requests per second to the URL (path and query) pattern. Requests are limited by adding a delay to each requests (linear). By default, no limitation is active. This directive should be used in conjunction with QS_LocRequestLimitMatch only (you must use the very same regex pattern with the QS_LocRequestPerSecLimitMatch and QS_LocRequestLimitMatch directive).
• QS_LocKBytesPerSecLimitMatch <regex> <number>
  Defines the allowed download bandwidth to the location matching the defined URL (path and query) pattern. Responses are slowed down by adding a delay to each response (non-linear, bigger files get longer delay than smaller ones). By default, no limitation is active. This directive should be used in conjunction with QS_LocRequestLimitMatch only (you must use the very same regex pattern with the QS_LocKBytesPerSecLimitMatch and QS_LocRequestLimitMatch directive).
• QS_LocRequestLimit <location> <number>
  Defines the number of concurrent requests for the specified location (applied to the parsed path). By default, no limitations are active for locations. Has lower priority than QS_LocRequestLimitMatch directives.
• QS_LocRequestLimitDefault <number>
  Defines the default limitation for the maximum of concurrent per locations for those locations not defined by any QS_LocRequestLimit directive. It could also be used to limit the number of concurrent requests to a virtual host.
• QS_LocRequestPerSecLimit <location> <number>
  Defines the allowed number of requests per second to a location. The maximum number of requests is limited by adding a delay to each request (linear, each request gets the same delay). By default, no limitation is active. This directive should be used in conjunction with QS_LocRequestLimit only (you must use the same location for both directives). Has lower priority than QS_LocRequestPerSecLimitMatch.
• QS_LocKBytesPerSecLimit <location> <number>
  Throttles the download bandwidth to the defined kbytes per second. Responses are slowed by adding a delay to each response (non-linear, bigger files get longer delay than smaller ones). By default, no limitation is active. This directive should be used in conjunction with QS_LocRequestLimit only (you must use the same location for both directives). Has lower priority than QS_LocKBytesPerSecLimitMatch.
• QS_ErrorPage <url>
  Defines an error page to be returend when a request is denied. The defined URL must be a HTML document accessible by the client.
• QS_ErrorResponseCode <code>
  Defines the HTTP response code which is used when a request is denied. Default is 500.

• QS_VipHeaderName <header name>
  Defines a HTTP response header which marks a user as a VIP. mod_qos creates a session for this user by setting a cookie. Whenever an application handler sets this response header (e.g. after successful user authentication), the user gets unlimited access to any location. This directive works in conjunction with QS_Loc*, QS_CondLoc*, QS_ClientPrefer, and QS_SrvPreferNet directives. Limitations defined by these directives are not active for requests having a VIP session cookie. The QS_ClientPrefer and QS_SrvPreferNet directives store the VIP session information persistent to the data record of the corresponding IP address. All other commands require the mod_qos session cookie to identify subsequent requests coming from the same user. A client request containing a valid mod_qos session cookie gets also the environment variable QS_VipRequest set in the process environment which may be evaluated by rules ignoring VIP status client normally, such as the QS_EventPerSecLimit directive. See the QS_Session* directives for further session attribute settings.
• QS_VipIPHeaderName <header name>
  Defines a HTTP response header which marks a client source IP address as a VIP. This header may be used in conjunction with the QS_ClientPrefer and QS_SrvPreferNet directives only.
• QS_VipUser
  Creates a VIP session for users which has been authenticated by the Apache server, e.g. by the standard mod_auth* modules. The command may be used in conjunction with the QS_ClientPrefer and QS_SrvPreferNet directives too (simplar to QS_VipHeaderName).
• QS_VipIPUser
  Marks a source IP address as a VIP if the user has been been authenticated by the Apache server, e.g. by the standard mod_auth* modules. The command may only be used in conjunction with the QS_ClientPrefer and QS_SrvPreferNet directives (similar to QS_VipIPHeaderName).
• QS_SessionTimeout <seconds>
  Defines the session life time for a VIP. It is only used for session based (cookie) VIP identification (not for IP based). Default are 3600 seconds.
• QS_SessionCookieName <name>
  A cookie is used to identify requests coming from a user which has been identified as a VIP. This directive defines a custom cookie name for the mod_qos session cookie. Default is MODQOS.
• QS_SessionCookiePath <path>
  Defines a the cookie path. Default is "/".
• QS_SessionKey <string>
  Secret key used for cookie encryption. Used when using the same session cookie for multiple web servers (load balancing) or sessions should survive a server restart. By default, a random key is used which changes every server restart.

QS_ErrorPage                  /error-docs/qs_error.html

# restricts max concurrent requests for any location which has no
# individual rule:
QS_LocRequestLimitDefault                              200

# limits access to *.gif files to 100 concurrent requests:
QS_LocRequestLimitMatch       "^.*\.gif$"              100

# limits concurrent requests to the locations /images and /app/a:
QS_LocRequestLimit            /images                  100
QS_LocRequestLimit            /app/a                   300
# limits download bandwidth to 5Mbit/sec:
QS_LocKBytesPerSecLimit       /app/a                   640

# two locations (/app/b and /app/c) representing a single application:
QS_LocRequestLimitMatch       "^(/app/b/|/app/c/).*$"  300


# allows the application to nominate VIP users by sending a
# "mod-qos-vip" HTTP response header:
QS_VipHeaderName              mod-qos-vip
QS_SessionKey                 na&5san-sB.F4_0a=%D200ahLK1

Variables

• QS_VipRequest=yes
  Disables the pre location restrictions for this request. Requires the definition of a VIP header using the QS_VipHeaderName directive (this activates VIP verification). However, such an event does not create a VIP session. The user has the VIP status only for a single request (does not affect the QS_ClientPrefer, and QS_SrvPreferNet directives).
• QS_KeepAliveTimeout=<seconds>
  Applies dynamic connection keep-alive settings overriding the Apache KeepAliveTimeout directive settings.
• QS_ErrorPage=<url>
  Defines the error page overriding the setting made by the QS_ErrorPage directive.

# unlimited access for curl clients:
BrowserMatch             "curl"                   QS_VipRequest=yes

# allows unlimited access to a single resource:
SetEnvIf     Request_URI /app/start.html          QS_VipRequest=yes

# allows unlimited access from a specified source address
# or source address range:
SetEnvIf     Remote_Addr 172.18.3.32              QS_VipRequest=yes
SetEnvIf     Remote_Addr 192.168.10.              QS_VipRequest=yes

# set keep-alive timeout for MSIE version 5.x browser to 65 seconds:
BrowserMatch             "(MSIE 5\.)"             QS_KeepAliveTimeout=65

# dynamic error page url (per host error page):
SetEnvIf     Host        (.*)                     QS_ErrorPage=/error-docs/$1.html

Conditional Rules

• QS_CondLocRequestLimitMatch <regex> <number> <condition>
  Rule works similar to QS_LocRequestLimitMatch but it is only enforced for requests whose QS_Cond variable matches the specified condition (regular expression). Every request matching the defined pattern is counted but the defined limitation is only enforced for those requests matching the specified condition.

# set the conditional variable to spider if detecting a
# "slurp" or "googlebot" search engine:
BrowserMatch             "slurp"                  QS_Cond=spider
BrowserMatch             "googlebot"              QS_Cond=spider

# limits the number of concurrent requests to two applications
# (/app/b and /app/c) to 300 but does not allow access by a "spider"
# if the number of conurrent requests exceeds the limit of 10:
QS_LocRequestLimitMatch       "^(/app/b/|/app/c/).*$"  300
QS_CondLocRequestLimitMatch   "^(/app/b/|/app/c/).*$"  10   spider

Events

• QS_EventRequestLimit <env-variable> <number>
  Defines the number of concurrent events. Directive works similar to QS_LocRequestLimit but counting the requests having the same environment variable set rather than having the same URL pattern. Ignores VIP privileges normally but you may evaluate the QS_VipRequest variable, e.g. by using QS_SetEnvIf.
• QS_EventPerSecLimit [!]<env-variable> <number>
  Defines how often requests may have the defined environment variable (literal string) set. It measures the occurence of the defined environment variable on a request per seconds level and tries to limit this occurence to the defined number. It works similar as QS_LocRequestPerSecLimit does but counts only the requests having the specified variable set (or not set if the variable name is prefixed by a "!"). Events are limited by adding a delay to each requests causing an event. Ignores VIP privileges normally but you may evaluate the QS_VipRequest variable.
• QS_SetEnvIf [!]<env-variable1> [!]<env-variable2> <variable=value>
  Sets the "variable=value" (literal string) if variable1 (literal string) AND variable2 (literal string) are set in the request environment variable list (not case sensitive). This is used to combine multiple variables to a new event type.
• QS_SetEnvIfQuery <regex> [!]<env-variable>[=<value>]
  Directive works quite simliar to the SetEnvIf directive of the Apache module mod_setenvif but the specified regex is applied against the query string portion of the request line.
• QS_SetEnvStatus <code> <env-variable>
  Sets the defined variable in the request environment if the HTTP response status code matches the defined value. This may be used in conjunction with the QS_ClientEventBlockCount directive.
• QS_SetEnvResHeader <header name> [drop]
  Adds the defined HTTP response header to the request environment variables. Deletes the specified header if the action 'drop' has been specified.
• QS_SetEnvResHeaderMatch <header name> <regex>
  Adds the defined HTTP response header to the request environment variables if the specified regular expression (pcre not case sensitive) matches the header value.

# marks clients coming from the internal network:
SetEnvIf     Remote_Addr   "^192\.168\."          QS_Intra

# marks clients neither coming from the internal network
# nor are VIP clients as low priority clients:
QS_SetEnvIf !QS_VipRequest !QS_Intra              QS_LowPrio

# limits the request rate for low priority (neither VIP nor internal)
# clients (and no more than 400 concurrent requests for them):
QS_EventPerSecLimit        QS_LowPrio             100
QS_EventRequestLimit       QS_LowPrio             400

Request Level, Generic Filter

• QS_DenyRequestLine '+'|'-'<id> 'log'|'deny' <pcre>
  Generic request line (method, path, query, and protocol) filter used to deny access for requests matching the defined expression (pcre). The action taken for matching rules is either 'log' (access is granted but the rule match is logged) or 'deny' (access is denied).
• QS_DenyPath '+'|'-'<id> 'log'|'deny' <pcre>
  Generic abs_path (see RFC 2616 secion 3.2.2) filter used to deny access for requests matching the defined expression (pcre). The action taken for matching rules is either 'log' (access is granted but the rule match is logged) or 'deny' (access is denied).
• QS_DenyQuery '+'|'-'<id> 'log'|'deny' <pcre>
  Generic query (see RFC 2616 secion 3.2.2) filter used to deny access for requests matching the defined expression (pcre). The action taken for matching rules is either 'log' (access is granted but the rule match is logged) or 'deny' (access is denied).
• QS_PermitUri '+'|'-'<id> 'log'|'deny' <pcre>
  Generic URL (path and query) filter implementing a request pattern whitelist. Only requests matching at least one QS_PermitUri pattern are allowed. If a QS_PermitUri pattern has been defined an the request does not match any rule, the request is denied albeit of any server resource availability (whitelist). All rules must define the same action. pcre is case sensitve. You may use the qsfilter2 utility to generate rules based on access log files.
• QS_DenyInheritanceOff
  Disables inheritance of QS_Deny* and QS_Permit* directives to a location.
• QS_RequestHeaderFilter 'on'|'off'
  Filters request headers using validation rules provided by mod_qos. Suspicious headers are normally dropped (removed from the request). Abnormal content-* headers cause request blocking. Additional rules may be added using the QS_RequestHeaderFilterRule directive.
• QS_RequestHeaderFilterRule <header name> <pcre> 'drop'|'deny'
  Used to add custom request header filter rules, e.g. to override the internal rules (different pcre) or to add additional headers which should be allowed. Definitions are made globaly (outside VirtualHost). A list of all rules is shown at server startup when using LogLevel debug. pcre is case sensitive. The action 'drop' removes a header not matching the pcre, the action 'deny' rejects a request including such a header not matching the pcre.

QS_ErrorPage                     /error-docs/qs_error.html
QS_RequestHeaderFilterRule       UA-CPU "^[a-zA-Z0-9]+$" drop

<Location />
   QS_RequestHeaderFilter        on
   QS_DenyPath        +admin     deny "^/app/admin.jsp$"
   QS_DenyRequestLine +printable deny ".*[\x00-\x19].*"
</Location>

Connection Level Control

• QS_SrvMaxConn <number>
  Defines the maximum number of concurrent TCP connections for this server (virtual host).
• QS_SrvMaxConnClose <number>
  Defines the maximum number of connections supporting keep-alive. If the number of concurrent connections exceeds this threshold, the TCP connection gets closed after each request.
• QS_SrvMaxConnPerIP <number>
  Defines the maximum number of connections per source IP address.
• QS_SrvMaxConnExcludeIP <address>
  Defines an IP address or address range to be excluded from connection level control restrictions. An address range must end with a ".".
• QS_SrvMinDataRate <bytes per second> [<max bytes per second>]
  Defines the minumum upload/download throughput a client must generate (the bytes send/received by the client per seconds). This bandwidth is measured while receiving request data (request line, header fields, or body). The client connection get closed if the client does not fulfill this required minimal data rate and the IP address of the causing client get marked in order to be handled with low priority (see the QS_ClientPrefer directive). The "max bytes per second" activates dynamic minimum throughput control: The required minimal throughput is increased in parallel to the number of concurrent clients sending/receiving data. The "max bytes per second" setting is reached when the number of sending/receiving clients is equal to the MaxClients setting. No limitation is set by default.
• QS_SrvRequestRate <bytes per second> [<max bytes per second>]
  Same as QS_SrvMinDataRate but enforcing a minimal upload throughput only.
• QS_SrvPreferNet
  mod_qos prefers "known networks" when server has less than 80% of free TCP connections. Preferred networks have VIP clients, see QS_VipHeaderName or QS_VipIPHeaderName directives. Netmask is 255.255.240.0 (each net represents 4096 hosts). Clients identified by QS_SrvMaxConnExcludeIP are excluded from connection restrictions.

# minimum request rate (bytes/sec at request reading):
QS_SrvRequestRate                                 120

# limits the connections for this virtual host:
QS_SrvMaxConn                                     800

# allows keep-alive support till the server reaches 600 connections:
QS_SrvMaxConnClose                                600

# allows max 50 connections from a single ip address:
QS_SrvMaxConnPerIP                                 50

# disables connection restrictions for certain clients:
QS_SrvMaxConnExcludeIP                    172.18.3.32
QS_SrvMaxConnExcludeIP                    192.168.10.

Client Level Control

• QS_ClientEntries <number>
  Defines the number of individual clients managed by mod_qos. Default are 50'000 concurrent IP addresses. Each client requires about 48 bytes of shared memory on a 32bit system or 96 bytes on a 64bit system respectively. Client IP source address store survives graceful server restart.
• QS_ClientEventPerSecLimit <number>
  Defines how often a client may cause a QS_Event per second. Such events are requests having the QS_Event variable set, e.g. defined by mod_setenvif or using the QS_SetEnvIf directive. The rule is enforced by adding a delay to requests causing the event (similar to the QS_LocRequestPerSecLimit directive. Ignores VIP status by default but you may use the QS_VipRequest variable to detect VIP clients.
• QS_ClientEventBlockCount <number> [<seconds>]
  Defines the maximum number of QS_Block events allowed within the defined time (default are 600 seconds). Client IP is blocked when reaching this counter for the specified time (blocked at connection level). Ignores VIP status by default but you may use the QS_VipRequest variable to detect VIP clients.
• QS_ClientPrefer [<percent>]
  Accepts only VIP and high priority clients when the server has less than 80% (or the defined percentage) of free TCP connections (similar to QS_SrvPreferNet but for individual IP source addresses). Use the QS_VipHeaderName or QS_VipIPHeaderName directive in order to identify VIP clients. The distinction between high and low priority clients is made based on the client data transfer behavior (clients sending slow or using small data packets get marked as low priority clients). Clients identified by QS_SrvMaxConnExcludeIP are excluded from connection restrictions. Filter is applied on connection level.

# don't allow a client IP to access /app/start.html 20 or
# more times within 10 minutes:
SetEnvIf     Request_URI /app/start.html          QS_Block=yes
QS_ClientEventBlockCount                          20

# don't allow more than 20 "403" status code responses
# (forbidden) for a client withn 10 minutes:
QS_SetEnvStatus          403                      QS_Block

Log Messages

Error Log

mod_qos writes messages to Apache's error log when enforcing a rule. Each error messages is prefixed by an id: mod_qos(<number>). These error codes (number only) are also written to the error notes in order to be processed within error pages using server side includes (SSI).

mod_qos(00x): initialisation event mod_qos(01x): request level control event mod_qos(02x): vip session event mod_qos(03x): connection level event mod_qos(04x): generic filter event mod_qos(05x): bandwidth limitation event mod_qos(06x): client control event

Access Log

mod_qos adds response headers to the request record which may be added to access log messages (the header is not sent to the client).

• mod_qos_ev
  This header stores mod_qos event messages. A single letter is used to signalize an event: "D"=denied, "S"=pass due an available VIP session, "V"=create VIP session, "K"=connection closed (no keep-alive), "T"=dynamic keep-alive, "r"=IP has marked as a slow/bad client, and "L"=means a request slow down.
• mod_qos_cr
  The number of concurrent requests to a location defined by the QS_LocRequestLimit or QS_LocRequestLimitMatch directive.
• mod_qos_con
  This header shows the number of concurrent connections to this server.
• UNIQUE_ID
  This is a unique request id generated by mod_unique_id. mod_qos uses this id to mark messages written to the error log. So it might be useful to log the UNIQUE_ID environment variable (not header) as well in order to correlate error to access log messages.

LogFormat "%h %t \"%r\" %>s %b %T \"%{User-Agent}i\" id=%{UNIQUE_ID}e \
            %{mod_qos_ev}o %{mod_qos_cr}o %{mod_qos_con}o #%P"

Request Statistics

The qslog tool, which is part of the support utilities of mod_qos, may be used to gather request statistics from Apache's access log data. This includes data such as the number of denied requests or new VIP session creations per minute but also total requests per second and other data. Refer to the usage text of the qslog utility for further details.

TransferLog "| ./bin/qslog -o logs/qs_log -f I..R.BT..Q"

Status Viewer

mod_qos features a handler showing the current connection and request status.

<Location /qos> SetHandler qos-viewer </Location>

User Interface

mod_qos features a graphical user interface (web application) which may be used to manage directives and to generate generic filter rules using the qsfilter2 utility. It is provided as an additional Apache module which is loaded into the server (usually a separate Apache instance which has write access to the main server's configuration files). The qos-control handler specifies the location under which the GUI is accessible.

LoadModule qos_control_module <path to module>/mod_qos_control.so LoadModule qos_module <path to module>/mod_qos.so # this is the working directory where the GUI stores its metadata to: QSC_WorkingDirectory /var/tmp/qosc # you must specify the location of the qsfilter2 utility which is used # to generate generic request filer rules based on access log files: QSC_Filter2Binary /usr/local/bin/qsfilter2 # the location/url where the GUI is accessible: <Location /qos_control> SetHandler qos-control </Location>

Use Cases

The following use cases may give you an idea about how to use mod_qos.

Slow Application

In the case an application is very slow (e.g. at location /ccc), requests wait until a timeout occurs. Due many waiting requests, the number of free TCP connections goes out and the web sever is not able to process other requests to applications still working fine, e.g. to /aaa, /bbb /dd1, and /dd2. mod_qos limits the concurrent requests to an application in order to assure the availability of other resources.

# maximum number of active TCP connections is limited to 256: MaxClients 256 # limits the maximum of concurrent requests per application to 100: QS_LocRequestLimit /aaa 100 QS_LocRequestLimit /bbb 100 QS_LocRequestLimit /ccc 100 QS_LocRequestLimitMatch "^(/dd1/|/dd2/).*$" 100

HTTP Keep-Alive

The keep-alive extension to HTTP 1.1 allows persistent TCP connections for multiple request/responses. This accelerates access to the web server due less and optimized network traffic. The disadvantage of these persistent connections is, that server resources are blocked even no data is exchanged between client and server. mod_qos allows a server to support keep-alive as long as sufficient connections are free but stopping the keep-alive support when reaching a defined connection threshold.
Example:

# maximum number of active TCP connections is limited to 256: MaxClients 256 # disables keep-alive when 70% of the TCP connections are occupied: QS_SrvMaxConnClose 180

Client Opens Many Concurrent Connections

A single client may open many TCP connections simultaneously in order to download different content from the web server. So the client gets many connections while other users may not be able to access the server due no free connections remain for them. mod_qos can limit the number of concurrent connections for a singe IP source address.
Example:

# maximum number of active TCP connections is limited to 256: MaxClients 256 # don't allow a single client to open more than 50 TCP connections: QS_SrvMaxConnPerIP 50

Many Requests to a Single URL

If you have to limit the number of requests to an URL, mod_qos can help with that too. You may limit the number ot requests per second to an URL by adding a delay to requests accessing this resource.
Example:

# does not allow more than 150 requests/sec: QS_LocRequestPerSecLimit /download/mod_qos.so.gz 150

Too Many Client Connections

mod_qos may prefer "known" client IP addresses in the case that too many clients access the server. "Known" clients are those which has once been identified by the application by setting the corresponding HTTP response header. Such identification may happen at successful user login. Connections from clients which are not known to mod_qos (never marked by the corresponding response header) are denied if the server runs on low TCP connection resources (20% or fewer free connections). mod_qos prefers also those clients which communicates instantaneous and fast with the server and denies access to slow clients sending data irregular in the case the server has not enougth resources. A minimal request bandwidth should be enforced too in order to close the connections comming from idle clients.
Example:

# maximum number of active TCP connections is limited to 256: MaxClients 256 # name of the HTTP response header which marks preferred clients: QS_VipIPHeaderName mod-qos-login # enables the known client perfer mode (server allows new TCP connections # to known clients when is has more than 205 open TCP connections): QS_ClientPrefer # handles two hundred thousand different client IP addresses: QS_ClientEntries 200000 # minimum request/response speed (deny slow clients blocking the server): QS_SrvMinDataRate 150 1200 # and limit request header and body: LimitRequestFields 30 LimitRequestBody 102400