A web server can only serve a limited number of concurrent requests. QoS is used to ensure that important resources stay available under high server load. mod_qos is used to reject requests to unimportant resources while granting access to more important applications. It is also possible to disable access restrictions, for example, for requests to very important resources or for very important users. Control mechanisms are available at the following levels:
Request level control: mod_qos controls the number of concurrent requests to a name space. It is used to define different priorities to different pages or applications within a web server.
Connection level control: mod_qos controls the number of TCP connections to the web server. This helps limit the connections coming from a single client or from unknown networks, in order to reduce the maximum number of concurrent connections to a virtual server or to implement dynamic HTTP keep-alive settings.
Bandwidth level control: throttles requests/responses to certain URL on the web server.
Generic request line and header filter dropping suspicious request URLs or HTTP headers.
The module can be useful when used in a reverse proxy in order to divide up resources to different webserver.
Use Cases
Slow Application
The first use case shows how mod_qos can avoid service outage of a web server due to slow responses of a single application. In case an application is very slow, requests wait until a timeout occurs. Due to many waiting requests, the web server runs out of free TCP connections and is not able to process other requests to application /aaa or /bbb. mod_qos limits the concurrent requests to an application in order to assure the availability of other resources.
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 to less and optimised network traffic. The disadvantage of these persistent connections is that server resources are blocked even though no data is exchanged between client and server. mod_qos allows a server to support keep-alive as long as sufficient connections are free, stopping the keep-alive support when a defined connection threshold is reached.
Client opens many concurrent connections
A single client may open many simultaneous TCP connections in order to download different content from the web server. While the client gets many connections other users may not be able to access the server since no free connections remain for them. mod_qos can limit the number of concurrent connections for a single IP source address.
Many requests to a single URL
If you have to limit the number of requests to a URL, mod_qos can help with that too. mod_qos limits the maximum number of requests per second to this URL. The module may also control bandwidth. Simply specify the maximum allowed bandwidth and moq_qos starts throttling when it becomes necessary.
mod_qos may help to protect an Apache web server against low-bandwidth DoS attacks by enforcing a minimum upload/download throughput a client must generate.
History
The initial release of mod_qos was created in May 2007 and published on SourceForge.net as an open source software project. It was able to limit the number of concurrent HTTP requests for specified resources on the web server. More features were added and some of them were useful to protect Apache servers against DoS attacks. In 2012, mod_qos was included to the Ubuntu Linux distribution. Major releases:
May 2007, Version 1: Limits concurrent requests on a per URL path basis.
July 2007, Version 2.2: Introduction of support utilities.
August 2007, Version 3: Introduces connection level controls as well as a status viewer.
September 2007, Version 4: Request/response throttling and generic request filtering.
December 2007, Version 5: Limiting by user defined events.
March 2008, Version 6: Per client control mechanisms.
May 2008, Version 7: Enforces minimum upload/download throughput a client must generate.
September 2009, Version 9: Anomaly detection using client characteristic measurement.
February 2012, Version 10: Adds geolocation features.
May 2014, Version 11: Highly improves response throttling.
July 2015, Version 11.15: Serialization not only on a per server but also on a per client level.
