upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-04-27 09:06:46 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
haproxy/include/proto/session.h

277 lines
8.4 KiB
C
Raw Normal View History

[LICENSE] licensing clarifications
2006-06-15 15:48:13 -04:00
/*
[MAJOR] frontend: split accept() into frontend_accept() and session_accept() A new function session_accept() is now called from the lower layer to instanciate a new session. Once the session is instanciated, the upper layer's frontent_accept() is called. This one can be service-dependant. That way, we have a 3-phase accept() sequence : 1) protocol-specific, session-less accept(), which is pointed to by the listener. It defaults to the generic stream_sock_accept(). 2) session_accept() which relies on a frontend but not necessarily for use in a proxy (eg: stats or any future service). 3) frontend_accept() which performs the accept for the service offerred by the frontend. It defaults to frontend_accept() which is really what is used by a proxy. The TCP/HTTP proxies have been moved to this mode so that we can now rely on frontend_accept() for any type of session initialization relying on a frontend. The next step will be to convert the stats to use the same system for the stats.
2010-06-01 11:45:26 -04:00
* include/proto/session.h
* This file defines everything related to sessions.
*
* Copyright (C) 2000-2010 Willy Tarreau - w@1wt.eu
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation, version 2.1
* exclusively.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
[LICENSE] licensing clarifications
2006-06-15 15:48:13 -04:00
[BIGMOVE] exploded the monolithic haproxy.c file into multiple files. The files are now stored under : - include/haproxy for the generic includes - include/types.h for the structures needed within prototypes - include/proto.h for function prototypes and inline functions - src/*.c for the C files Most include files are now covered by LGPL. A last move still needs to be done to put inline functions under GPL and not LGPL. Version has been set to 1.3.0 in the code but some control still needs to be done before releasing.
2006-06-25 20:48:02 -04:00
#ifndef _PROTO_SESSION_H
#define _PROTO_SESSION_H
[CLEANUP] included common/version.h everywhere
2006-06-29 12:54:54 -04:00
#include <common/config.h>
[MAJOR] migrated task, tree64 and session to pool2 task and tree64 are already very close in size and are merged together. Overall performance gained slightly by this simple change.
2007-05-13 13:43:47 -04:00
#include <common/memory.h>
[BIGMOVE] exploded the monolithic haproxy.c file into multiple files. The files are now stored under : - include/haproxy for the generic includes - include/types.h for the structures needed within prototypes - include/proto.h for function prototypes and inline functions - src/*.c for the C files Most include files are now covered by LGPL. A last move still needs to be done to put inline functions under GPL and not LGPL. Version has been set to 1.3.0 in the code but some control still needs to be done before releasing.
2006-06-25 20:48:02 -04:00
#include <types/session.h>
[MEDIUM] session counters: add conn_rate and sess_rate counters These counters maintain incoming connection rates and session rates in a stick-table, over a period which is defined in the configuration (2 ms to 24 days). They can be used to detect service abuse and enforce a certain accept rate per source address for instance, and block if the rate is passed over. Example : # block if more than 50 requests per 5 seconds from a source. stick-table type ip size 200k expire 1m store conn_rate(5s),sess_rate(5s) tcp-request track-counters src tcp-request reject if { trk_conn_rate gt 50 } # cause a 3 seconds pause to requests from sources in excess of 20 requests/5s tcp-request inspect-delay 3s tcp-request content accept if { trk_sess_rate gt 20 } WAIT_END
2010-06-20 05:19:22 -04:00
#include <proto/freq_ctr.h>
[MAJOR] session: add track-counters to track counters related to the session This patch adds the ability to set a pointer in the session to an entry in a stick table which holds various counters related to a specific pattern. Right now the syntax matches the target syntax and only the "src" pattern can be specified, to track counters related to the session's IPv4 source address. There is a special function to extract it and convert it to a key. But the goal is to be able to later support as many patterns as for the stick rules, and get rid of the specific function. The "track-counters" directive may only be set in a "tcp-request" statement right now. Only the first one applies. Probably that later we'll support multi-criteria tracking for a single session and that we'll have to name tracking pointers. No counter is updated right now, only the refcount is. Some subsequent patches will have to bring that feature.
2010-06-14 15:04:55 -04:00
#include <proto/stick_table.h>
[LICENSE] licensing clarifications
2006-06-15 15:48:13 -04:00
[MAJOR] migrated task, tree64 and session to pool2 task and tree64 are already very close in size and are merged together. Overall performance gained slightly by this simple change.
2007-05-13 13:43:47 -04:00
extern struct pool_head *pool2_session;
[MINOR] maintain a global session list in order to ease debugging Now the global variable 'sessions' will be a dual-linked list of all known sessions. The list element is set at the beginning of the session so that it's easier to follow them all with gdb.
2008-11-23 13:53:55 -05:00
extern struct list sessions;
[MAJOR] migrated task, tree64 and session to pool2 task and tree64 are already very close in size and are merged together. Overall performance gained slightly by this simple change.
2007-05-13 13:43:47 -04:00
MINOR: cli: report connection status in "show sess xxx" Connection flags, targets and transport layers are now reported in "show sess $PTR", as it is an absolute requirement in debugging.
2012-11-19 10:10:32 -05:00
extern struct data_cb sess_conn_cb;
[MAJOR] frontend: split accept() into frontend_accept() and session_accept() A new function session_accept() is now called from the lower layer to instanciate a new session. Once the session is instanciated, the upper layer's frontent_accept() is called. This one can be service-dependant. That way, we have a 3-phase accept() sequence : 1) protocol-specific, session-less accept(), which is pointed to by the listener. It defaults to the generic stream_sock_accept(). 2) session_accept() which relies on a frontend but not necessarily for use in a proxy (eg: stats or any future service). 3) frontend_accept() which performs the accept for the service offerred by the frontend. It defaults to frontend_accept() which is really what is used by a proxy. The TCP/HTTP proxies have been moved to this mode so that we can now rely on frontend_accept() for any type of session initialization relying on a frontend. The next step will be to convert the stats to use the same system for the stats.
2010-06-01 11:45:26 -04:00
int session_accept(struct listener *l, int cfd, struct sockaddr_storage *addr);
[LICENSE] licensing clarifications
2006-06-15 15:48:13 -04:00
[MAJOR] migrated task, tree64 and session to pool2 task and tree64 are already very close in size and are merged together. Overall performance gained slightly by this simple change.
2007-05-13 13:43:47 -04:00
/* perform minimal intializations, report 0 in case of error, 1 if OK. */
int init_session();
[BIGMOVE] exploded the monolithic haproxy.c file into multiple files. The files are now stored under : - include/haproxy for the generic includes - include/types.h for the structures needed within prototypes - include/proto.h for function prototypes and inline functions - src/*.c for the C files Most include files are now covered by LGPL. A last move still needs to be done to put inline functions under GPL and not LGPL. Version has been set to 1.3.0 in the code but some control still needs to be done before releasing.
2006-06-25 20:48:02 -04:00
[MEDIUM] session: make session_shutdown() an independant function We already had the ability to kill a connection, but it was only for the checks. Now we can do this for any session, and for this we add a specific flag "K" to the logs.
2011-09-07 17:01:56 -04:00
/* kill a session and set the termination flags to <why> (one of SN_ERR_*) */
void session_shutdown(struct session *session, int why);
[CLEANUP] session.c: Make functions static where possible
2011-06-07 20:19:07 -04:00
[MEDIUM] continous statistics By default, counters used for statistics calculation are incremented only when a session finishes. It works quite well when serving small objects, but with big ones (for example large images or archives) or with A/V streaming, a graph generated from haproxy counters looks like a hedgehog. This patch implements a contstats (continous statistics) option. When set counters get incremented continuously, during a whole session. Recounting touches a hotpath directly so it is not enabled by default, as it has small performance impact (~0.5%).
2007-11-24 16:12:47 -05:00
void session_process_counters(struct session *s);
[BUG] fix the dequeuing logic to ensure that all requests get served The dequeuing logic was completely wrong. First, a task was assigned to all servers to process the queue, but this task was never scheduled and was only woken up on session free. Second, there was no reservation of server entries when a task was assigned a server. This means that as long as the task was not connected to the server, its presence was not accounted for. This was causing trouble when detecting whether or not a server had reached maxconn. Third, during a redispatch, a session could lose its place at the server's and get blocked because another session at the same moment would have stolen the entry. Fourth, the redispatch option did not work when maxqueue was reached for a server, and it was not possible to do so without indefinitely hanging a session. The root cause of all those problems was the lack of pre-reservation of connections at the server's, and the lack of tracking of servers during a redispatch. Everything relied on combinations of flags which could appear similarly in quite distinct situations. This patch is a major rework but there was no other solution, as the internal logic was deeply flawed. The resulting code is cleaner, more understandable, uses less magics and is overall more robust. As an added bonus, "option redispatch" now works when maxqueue has been reached on a server.
2008-06-20 09:04:11 -04:00
void sess_change_server(struct session *sess, struct server *newsrv);
[MEDIUM] minor update to the task api: let the scheduler queue itself All the tasks callbacks had to requeue the task themselves, and update a global timeout. This was not convenient at all. Now the API has been simplified. The tasks callbacks only have to update their expire timer, and return either a pointer to the task or NULL if the task has been deleted. The scheduler will take care of requeuing the task at the proper place in the wait queue.
2009-03-08 04:38:41 -04:00
struct task *process_session(struct task *t);
[BUG] session: errors were not reported in termination flags in TCP mode In order to get termination flags properly updated, the session was relying a bit too much on http_return_srv_error() which is http-centric. A generic srv_error function was implemented in the session in order to catch all connection abort situations. It was then noticed that a request abort during a connection attempt was not reported, which is now fixed. Read and write errors/timeouts were not logged either. It was necessary to add those tests at 4 new locations. Now it looks like everything is correctly logged. Most likely some error checking code could now be removed from some analysers.
2009-03-15 17:34:05 -04:00
void default_srv_error(struct session *s, struct stream_interface *si);
[MAJOR] session: add track-counters to track counters related to the session This patch adds the ability to set a pointer in the session to an entry in a stick table which holds various counters related to a specific pattern. Right now the syntax matches the target syntax and only the "src" pattern can be specified, to track counters related to the session's IPv4 source address. There is a special function to extract it and convert it to a key. But the goal is to be able to later support as many patterns as for the stick rules, and get rid of the specific function. The "track-counters" directive may only be set in a "tcp-request" statement right now. Only the first one applies. Probably that later we'll support multi-criteria tracking for a single session and that we'll have to name tracking pointers. No counter is updated right now, only the refcount is. Some subsequent patches will have to bring that feature.
2010-06-14 15:04:55 -04:00
int parse_track_counters(char **args, int *arg,
int section_type, struct proxy *curpx,
struct track_ctr_prm *prm,
MEDIUM: cfgparse: use the new error reporting framework for remaining cfg_keywords All keywords registered using a cfg_kw_list now make use of the new error reporting framework. This allows easier and more precise error reporting without having to deal with complex buffer allocation issues.
2012-05-08 13:47:01 -04:00
struct proxy *defpx, char **err);
[MAJOR] session: add track-counters to track counters related to the session This patch adds the ability to set a pointer in the session to an entry in a stick table which holds various counters related to a specific pattern. Right now the syntax matches the target syntax and only the "src" pattern can be specified, to track counters related to the session's IPv4 source address. There is a special function to extract it and convert it to a key. But the goal is to be able to later support as many patterns as for the stick rules, and get rid of the specific function. The "track-counters" directive may only be set in a "tcp-request" statement right now. Only the first one applies. Probably that later we'll support multi-criteria tracking for a single session and that we'll have to name tracking pointers. No counter is updated right now, only the refcount is. Some subsequent patches will have to bring that feature.
2010-06-14 15:04:55 -04:00
MEDIUM: session: maintain per-backend and per-server time statistics Using the last rate counters, we now compute the queue, connect, response and total times per server and per backend with a 95% accuracy over the last 1024 samples. The operation is cheap so we don't need to condition it.
2014-06-17 06:19:18 -04:00
/* Update the session's backend and server time stats */
void session_update_time_stats(struct session *s);
MINOR: session: add a simple function to retrieve a session from a task This function only casts t->context to (struct session *). It will avoid some ugly and unsafe casts in upcoming changes.
2013-11-23 17:37:04 -05:00
/* returns the session from a void *owner */
static inline struct session *session_from_task(struct task *t)
{
return (struct session *)t->context;
}
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
/* sets the stick counter's entry pointer */
static inline void stkctr_set_entry(struct stkctr *stkctr, struct stksess *entry)
{
stkctr->entry = caddr_from_ptr(entry, 0);
}
/* returns the entry pointer from a stick counter */
static inline struct stksess *stkctr_entry(struct stkctr *stkctr)
{
return caddr_to_ptr(stkctr->entry);
}
/* returns the two flags from a stick counter */
static inline unsigned int stkctr_flags(struct stkctr *stkctr)
{
return caddr_to_data(stkctr->entry);
}
/* sets up to two flags at a time on a composite address */
static inline void stkctr_set_flags(struct stkctr *stkctr, unsigned int flags)
{
stkctr->entry = caddr_set_flags(stkctr->entry, flags);
}
/* returns the two flags from a stick counter */
static inline void stkctr_clr_flags(struct stkctr *stkctr, unsigned int flags)
{
stkctr->entry = caddr_clr_flags(stkctr->entry, flags);
}
[MAJOR] session: add track-counters to track counters related to the session This patch adds the ability to set a pointer in the session to an entry in a stick table which holds various counters related to a specific pattern. Right now the syntax matches the target syntax and only the "src" pattern can be specified, to track counters related to the session's IPv4 source address. There is a special function to extract it and convert it to a key. But the goal is to be able to later support as many patterns as for the stick rules, and get rid of the specific function. The "track-counters" directive may only be set in a "tcp-request" statement right now. Only the first one applies. Probably that later we'll support multi-criteria tracking for a single session and that we'll have to name tracking pointers. No counter is updated right now, only the refcount is. Some subsequent patches will have to bring that feature.
2010-06-14 15:04:55 -04:00
/* Remove the refcount from the session to the tracked counters, and clear the
* pointer to ensure this is only performed once. The caller is responsible for
* ensuring that the pointer is valid first.
*/
static inline void session_store_counters(struct session *s)
{
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
void *ptr;
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
int i;
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
MINOR: session: make the number of stick counter entries more configurable In preparation of more flexibility in the stick counters, make their number configurable. It still defaults to 3 which is the minimum accepted value. Changing the value alone is not sufficient to get more counters, some bitfields still need to be updated and the TCP actions need to be updated as well, but this update tries to be easier, which is nice for experimentation purposes.
2013-07-23 13:15:30 -04:00
for (i = 0; i < MAX_SESS_STKCTR; i++) {
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
if (!stkctr_entry(&s->stkctr[i]))
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
continue;
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
ptr = stktable_data_ptr(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]), STKTABLE_DT_CONN_CUR);
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
if (ptr)
stktable_data_cast(ptr, conn_cur)--;
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
stkctr_entry(&s->stkctr[i])->ref_cnt--;
stksess_kill_if_expired(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]));
stkctr_set_entry(&s->stkctr[i], NULL);
[MEDIUM] session: add concurrent connections counter The new "conn_cur" session counter has been added. It is automatically updated upon "track XXX" directives, and the entry is touched at the moment we increment the value so that we don't consider further counter updates as real updates, otherwise we would end up updating upon completion, which may not be desired. Probably that some other event counters (eg: HTTP requests) will have to be updated upon each event though. This counter can be matched against current session's source address using the "src_conn_cur" ACL.
2010-06-18 10:35:43 -04:00
}
[MAJOR] session: add track-counters to track counters related to the session This patch adds the ability to set a pointer in the session to an entry in a stick table which holds various counters related to a specific pattern. Right now the syntax matches the target syntax and only the "src" pattern can be specified, to track counters related to the session's IPv4 source address. There is a special function to extract it and convert it to a key. But the goal is to be able to later support as many patterns as for the stick rules, and get rid of the specific function. The "track-counters" directive may only be set in a "tcp-request" statement right now. Only the first one applies. Probably that later we'll support multi-criteria tracking for a single session and that we'll have to name tracking pointers. No counter is updated right now, only the refcount is. Some subsequent patches will have to bring that feature.
2010-06-14 15:04:55 -04:00
}
BUG/MEDIUM: counters: flush content counters after each request One year ago, commit 5d5b5d8 ("MEDIUM: proto_tcp: add support for tracking L7 information") brought support for tracking L7 information in tcp-request content rules. Two years earlier, commit 0a4838c ("[MEDIUM] session-counters: correctly unbind the counters tracked by the backend") used to flush the backend counters after processing a request. While that earliest patch was correct at the time, it became wrong after the second patch was merged. The code does what it says, but the concept is flawed. "TCP request content" rules are evaluated for each HTTP request over a single connection. So if such a rule in the frontend decides to track any L7 information or to track L4 information when an L7 condition matches, then it is applied to all requests over the same connection even if they don't match. This means that a rule such as : tcp-request content track-sc0 src if { path /index.html } will count one request for index.html, and another one for each of the objects present on this page that are fetched over the same connection which sent the initial matching request. Worse, it is possible to make the code do stupid things by using multiple counters: tcp-request content track-sc0 src if { path /foo } tcp-request content track-sc1 src if { path /bar } Just sending two requests first, one with /foo, one with /bar, shows twice the number of requests for all subsequent requests. Just because both of them persist after the end of the request. So the decision to flush backend-tracked counters was not the correct one. In practice, what is important is to flush countent-based rules since they are the ones evaluated for each request. Doing so requires new flags in the session however, to keep track of which stick-counter was tracked by what ruleset. A later change might make this easier to maintain over time. This bug is 1.5-specific, no backport to stable is needed.
2014-01-28 15:40:28 -05:00
/* Remove the refcount from the session counters tracked at the content level if
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
* any, and clear the pointer to ensure this is only performed once. The caller
* is responsible for ensuring that the pointer is valid first.
[MAJOR] session: add track-counters to track counters related to the session This patch adds the ability to set a pointer in the session to an entry in a stick table which holds various counters related to a specific pattern. Right now the syntax matches the target syntax and only the "src" pattern can be specified, to track counters related to the session's IPv4 source address. There is a special function to extract it and convert it to a key. But the goal is to be able to later support as many patterns as for the stick rules, and get rid of the specific function. The "track-counters" directive may only be set in a "tcp-request" statement right now. Only the first one applies. Probably that later we'll support multi-criteria tracking for a single session and that we'll have to name tracking pointers. No counter is updated right now, only the refcount is. Some subsequent patches will have to bring that feature.
2010-06-14 15:04:55 -04:00
*/
BUG/MEDIUM: counters: flush content counters after each request One year ago, commit 5d5b5d8 ("MEDIUM: proto_tcp: add support for tracking L7 information") brought support for tracking L7 information in tcp-request content rules. Two years earlier, commit 0a4838c ("[MEDIUM] session-counters: correctly unbind the counters tracked by the backend") used to flush the backend counters after processing a request. While that earliest patch was correct at the time, it became wrong after the second patch was merged. The code does what it says, but the concept is flawed. "TCP request content" rules are evaluated for each HTTP request over a single connection. So if such a rule in the frontend decides to track any L7 information or to track L4 information when an L7 condition matches, then it is applied to all requests over the same connection even if they don't match. This means that a rule such as : tcp-request content track-sc0 src if { path /index.html } will count one request for index.html, and another one for each of the objects present on this page that are fetched over the same connection which sent the initial matching request. Worse, it is possible to make the code do stupid things by using multiple counters: tcp-request content track-sc0 src if { path /foo } tcp-request content track-sc1 src if { path /bar } Just sending two requests first, one with /foo, one with /bar, shows twice the number of requests for all subsequent requests. Just because both of them persist after the end of the request. So the decision to flush backend-tracked counters was not the correct one. In practice, what is important is to flush countent-based rules since they are the ones evaluated for each request. Doing so requires new flags in the session however, to keep track of which stick-counter was tracked by what ruleset. A later change might make this easier to maintain over time. This bug is 1.5-specific, no backport to stable is needed.
2014-01-28 15:40:28 -05:00
static inline void session_stop_content_counters(struct session *s)
[MAJOR] session: add track-counters to track counters related to the session This patch adds the ability to set a pointer in the session to an entry in a stick table which holds various counters related to a specific pattern. Right now the syntax matches the target syntax and only the "src" pattern can be specified, to track counters related to the session's IPv4 source address. There is a special function to extract it and convert it to a key. But the goal is to be able to later support as many patterns as for the stick rules, and get rid of the specific function. The "track-counters" directive may only be set in a "tcp-request" statement right now. Only the first one applies. Probably that later we'll support multi-criteria tracking for a single session and that we'll have to name tracking pointers. No counter is updated right now, only the refcount is. Some subsequent patches will have to bring that feature.
2010-06-14 15:04:55 -04:00
{
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
void *ptr;
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
int i;
[MEDIUM] session-counters: automatically update tracked connection count When a session tracks a counter, automatically increase the cumulated connection count. This makes src_updt_conn_cnt() almost useless. In fact it might still be used to update different tables.
2010-06-18 15:03:20 -04:00
MINOR: session: make the number of stick counter entries more configurable In preparation of more flexibility in the stick counters, make their number configurable. It still defaults to 3 which is the minimum accepted value. Changing the value alone is not sufficient to get more counters, some bitfields still need to be updated and the TCP actions need to be updated as well, but this update tries to be easier, which is nice for experimentation purposes.
2013-07-23 13:15:30 -04:00
for (i = 0; i < MAX_SESS_STKCTR; i++) {
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
if (!stkctr_entry(&s->stkctr[i]))
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
continue;
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
if (!(stkctr_flags(&s->stkctr[i]) & STKCTR_TRACK_CONTENT))
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
continue;
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
ptr = stktable_data_ptr(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]), STKTABLE_DT_CONN_CUR);
[MEDIUM] session-counters: correctly unbind the counters tracked by the backend In case of HTTP keepalive processing, we want to release the counters tracked by the backend. Till now only the second set of counters was released, while it could have been assigned by the frontend, or the backend could also have assigned the first set. Now we reuse to unused bits of the session flags to mark which stick counters were assigned by the backend and to release them as appropriate.
2010-08-06 14:11:05 -04:00
if (ptr)
stktable_data_cast(ptr, conn_cur)--;
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
stkctr_entry(&s->stkctr[i])->ref_cnt--;
stksess_kill_if_expired(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]));
stkctr_set_entry(&s->stkctr[i], NULL);
[MEDIUM] session-counters: correctly unbind the counters tracked by the backend In case of HTTP keepalive processing, we want to release the counters tracked by the backend. Till now only the second set of counters was released, while it could have been assigned by the frontend, or the backend could also have assigned the first set. Now we reuse to unused bits of the session flags to mark which stick counters were assigned by the backend and to release them as appropriate.
2010-08-06 14:11:05 -04:00
}
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
}
[MEDIUM] session-counters: automatically update tracked connection count When a session tracks a counter, automatically increase the cumulated connection count. This makes src_updt_conn_cnt() almost useless. In fact it might still be used to update different tables.
2010-06-18 15:03:20 -04:00
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
/* Increase total and concurrent connection count for stick entry <ts> of table
* <t>. The caller is responsible for ensuring that <t> and <ts> are valid
* pointers, and for calling this only once per connection.
*/
static inline void session_start_counters(struct stktable *t, struct stksess *ts)
{
void *ptr;
ptr = stktable_data_ptr(t, ts, STKTABLE_DT_CONN_CUR);
if (ptr)
stktable_data_cast(ptr, conn_cur)++;
ptr = stktable_data_ptr(t, ts, STKTABLE_DT_CONN_CNT);
if (ptr)
stktable_data_cast(ptr, conn_cnt)++;
ptr = stktable_data_ptr(t, ts, STKTABLE_DT_CONN_RATE);
if (ptr)
update_freq_ctr_period(&stktable_data_cast(ptr, conn_rate),
t->data_arg[STKTABLE_DT_CONN_RATE].u, 1);
if (tick_isset(t->expire))
ts->expire = tick_add(now_ms, MS_TO_TICKS(t->expire));
}
[MEDIUM] session counters: add conn_rate and sess_rate counters These counters maintain incoming connection rates and session rates in a stick-table, over a period which is defined in the configuration (2 ms to 24 days). They can be used to detect service abuse and enforce a certain accept rate per source address for instance, and block if the rate is passed over. Example : # block if more than 50 requests per 5 seconds from a source. stick-table type ip size 200k expire 1m store conn_rate(5s),sess_rate(5s) tcp-request track-counters src tcp-request reject if { trk_conn_rate gt 50 } # cause a 3 seconds pause to requests from sources in excess of 20 requests/5s tcp-request inspect-delay 3s tcp-request content accept if { trk_sess_rate gt 20 } WAIT_END
2010-06-20 05:19:22 -04:00
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
/* Enable tracking of session counters as <stkctr> on stksess <ts>. The caller is
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
* responsible for ensuring that <t> and <ts> are valid pointers. Some controls
* are performed to ensure the state can still change.
*/
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
static inline void session_track_stkctr(struct stkctr *ctr, struct stktable *t, struct stksess *ts)
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
{
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
if (stkctr_entry(ctr))
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
return;
ts->ref_cnt++;
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
ctr->table = t;
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
stkctr_set_entry(ctr, ts);
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
session_start_counters(t, ts);
[MAJOR] session: add track-counters to track counters related to the session This patch adds the ability to set a pointer in the session to an entry in a stick table which holds various counters related to a specific pattern. Right now the syntax matches the target syntax and only the "src" pattern can be specified, to track counters related to the session's IPv4 source address. There is a special function to extract it and convert it to a key. But the goal is to be able to later support as many patterns as for the stick rules, and get rid of the specific function. The "track-counters" directive may only be set in a "tcp-request" statement right now. Only the first one applies. Probably that later we'll support multi-criteria tracking for a single session and that we'll have to name tracking pointers. No counter is updated right now, only the refcount is. Some subsequent patches will have to bring that feature.
2010-06-14 15:04:55 -04:00
}
[MEDIUM] continous statistics By default, counters used for statistics calculation are incremented only when a session finishes. It works quite well when serving small objects, but with big ones (for example large images or archives) or with A/V streaming, a graph generated from haproxy counters looks like a hedgehog. This patch implements a contstats (continous statistics) option. When set counters get incremented continuously, during a whole session. Recounting touches a hotpath directly so it is not enabled by default, as it has small performance impact (~0.5%).
2007-11-24 16:12:47 -05:00
[MEDIUM] session-counters: add HTTP req/err tracking This patch adds support for the following session counters : - http_req_cnt : HTTP request count - http_req_rate: HTTP request rate - http_err_cnt : HTTP request error count - http_err_rate: HTTP request error rate The equivalent ACLs have been added to check the tracked counters for the current session or the counters of the current source.
2010-06-23 05:44:09 -04:00
/* Increase the number of cumulated HTTP requests in the tracked counters */
static void inline session_inc_http_req_ctr(struct session *s)
{
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
void *ptr;
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
int i;
[MEDIUM] session-counters: add HTTP req/err tracking This patch adds support for the following session counters : - http_req_cnt : HTTP request count - http_req_rate: HTTP request rate - http_err_cnt : HTTP request error count - http_err_rate: HTTP request error rate The equivalent ACLs have been added to check the tracked counters for the current session or the counters of the current source.
2010-06-23 05:44:09 -04:00
MINOR: session: make the number of stick counter entries more configurable In preparation of more flexibility in the stick counters, make their number configurable. It still defaults to 3 which is the minimum accepted value. Changing the value alone is not sufficient to get more counters, some bitfields still need to be updated and the TCP actions need to be updated as well, but this update tries to be easier, which is nice for experimentation purposes.
2013-07-23 13:15:30 -04:00
for (i = 0; i < MAX_SESS_STKCTR; i++) {
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
if (!stkctr_entry(&s->stkctr[i]))
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
continue;
[MEDIUM] session-counters: add HTTP req/err tracking This patch adds support for the following session counters : - http_req_cnt : HTTP request count - http_req_rate: HTTP request rate - http_err_cnt : HTTP request error count - http_err_rate: HTTP request error rate The equivalent ACLs have been added to check the tracked counters for the current session or the counters of the current source.
2010-06-23 05:44:09 -04:00
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
ptr = stktable_data_ptr(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]), STKTABLE_DT_HTTP_REQ_CNT);
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
if (ptr)
stktable_data_cast(ptr, http_req_cnt)++;
MEDIUM: proto_tcp: add support for tracking L7 information Until now it was only possible to use track-sc1/sc2 with "src" which is the IPv4 source address. Now we can use track-sc1/sc2 with any fetch as well as any transformation type. It works just like the "stick" directive. Samples are automatically converted to the correct types for the table. Only "tcp-request content" rules may use L7 information, and such information must already be present when the tracking is set up. For example it becomes possible to track the IP address passed in the X-Forwarded-For header. HTTP request processing now also considers tracking from backend rules because we want to be able to update the counters even when the request was already parsed and tracked. Some more controls need to be performed (eg: samples do not distinguish between L4 and L6).
2012-12-09 06:00:04 -05:00
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
ptr = stktable_data_ptr(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]), STKTABLE_DT_HTTP_REQ_RATE);
MEDIUM: proto_tcp: add support for tracking L7 information Until now it was only possible to use track-sc1/sc2 with "src" which is the IPv4 source address. Now we can use track-sc1/sc2 with any fetch as well as any transformation type. It works just like the "stick" directive. Samples are automatically converted to the correct types for the table. Only "tcp-request content" rules may use L7 information, and such information must already be present when the tracking is set up. For example it becomes possible to track the IP address passed in the X-Forwarded-For header. HTTP request processing now also considers tracking from backend rules because we want to be able to update the counters even when the request was already parsed and tracked. Some more controls need to be performed (eg: samples do not distinguish between L4 and L6).
2012-12-09 06:00:04 -05:00
if (ptr)
update_freq_ctr_period(&stktable_data_cast(ptr, http_req_rate),
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
s->stkctr[i].table->data_arg[STKTABLE_DT_HTTP_REQ_RATE].u, 1);
MEDIUM: proto_tcp: add support for tracking L7 information Until now it was only possible to use track-sc1/sc2 with "src" which is the IPv4 source address. Now we can use track-sc1/sc2 with any fetch as well as any transformation type. It works just like the "stick" directive. Samples are automatically converted to the correct types for the table. Only "tcp-request content" rules may use L7 information, and such information must already be present when the tracking is set up. For example it becomes possible to track the IP address passed in the X-Forwarded-For header. HTTP request processing now also considers tracking from backend rules because we want to be able to update the counters even when the request was already parsed and tracked. Some more controls need to be performed (eg: samples do not distinguish between L4 and L6).
2012-12-09 06:00:04 -05:00
}
}
/* Increase the number of cumulated HTTP requests in the backend's tracked counters */
static void inline session_inc_be_http_req_ctr(struct session *s)
{
void *ptr;
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
int i;
MEDIUM: proto_tcp: add support for tracking L7 information Until now it was only possible to use track-sc1/sc2 with "src" which is the IPv4 source address. Now we can use track-sc1/sc2 with any fetch as well as any transformation type. It works just like the "stick" directive. Samples are automatically converted to the correct types for the table. Only "tcp-request content" rules may use L7 information, and such information must already be present when the tracking is set up. For example it becomes possible to track the IP address passed in the X-Forwarded-For header. HTTP request processing now also considers tracking from backend rules because we want to be able to update the counters even when the request was already parsed and tracked. Some more controls need to be performed (eg: samples do not distinguish between L4 and L6).
2012-12-09 06:00:04 -05:00
MINOR: session: make the number of stick counter entries more configurable In preparation of more flexibility in the stick counters, make their number configurable. It still defaults to 3 which is the minimum accepted value. Changing the value alone is not sufficient to get more counters, some bitfields still need to be updated and the TCP actions need to be updated as well, but this update tries to be easier, which is nice for experimentation purposes.
2013-07-23 13:15:30 -04:00
for (i = 0; i < MAX_SESS_STKCTR; i++) {
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
if (!stkctr_entry(&s->stkctr[i]))
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
continue;
MEDIUM: proto_tcp: add support for tracking L7 information Until now it was only possible to use track-sc1/sc2 with "src" which is the IPv4 source address. Now we can use track-sc1/sc2 with any fetch as well as any transformation type. It works just like the "stick" directive. Samples are automatically converted to the correct types for the table. Only "tcp-request content" rules may use L7 information, and such information must already be present when the tracking is set up. For example it becomes possible to track the IP address passed in the X-Forwarded-For header. HTTP request processing now also considers tracking from backend rules because we want to be able to update the counters even when the request was already parsed and tracked. Some more controls need to be performed (eg: samples do not distinguish between L4 and L6).
2012-12-09 06:00:04 -05:00
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
if (!(stkctr_flags(&s->stkctr[i]) & STKCTR_TRACK_BACKEND))
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
continue;
MEDIUM: proto_tcp: add support for tracking L7 information Until now it was only possible to use track-sc1/sc2 with "src" which is the IPv4 source address. Now we can use track-sc1/sc2 with any fetch as well as any transformation type. It works just like the "stick" directive. Samples are automatically converted to the correct types for the table. Only "tcp-request content" rules may use L7 information, and such information must already be present when the tracking is set up. For example it becomes possible to track the IP address passed in the X-Forwarded-For header. HTTP request processing now also considers tracking from backend rules because we want to be able to update the counters even when the request was already parsed and tracked. Some more controls need to be performed (eg: samples do not distinguish between L4 and L6).
2012-12-09 06:00:04 -05:00
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
ptr = stktable_data_ptr(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]), STKTABLE_DT_HTTP_REQ_CNT);
MEDIUM: proto_tcp: add support for tracking L7 information Until now it was only possible to use track-sc1/sc2 with "src" which is the IPv4 source address. Now we can use track-sc1/sc2 with any fetch as well as any transformation type. It works just like the "stick" directive. Samples are automatically converted to the correct types for the table. Only "tcp-request content" rules may use L7 information, and such information must already be present when the tracking is set up. For example it becomes possible to track the IP address passed in the X-Forwarded-For header. HTTP request processing now also considers tracking from backend rules because we want to be able to update the counters even when the request was already parsed and tracked. Some more controls need to be performed (eg: samples do not distinguish between L4 and L6).
2012-12-09 06:00:04 -05:00
if (ptr)
stktable_data_cast(ptr, http_req_cnt)++;
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
ptr = stktable_data_ptr(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]), STKTABLE_DT_HTTP_REQ_RATE);
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
if (ptr)
update_freq_ctr_period(&stktable_data_cast(ptr, http_req_rate),
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
s->stkctr[i].table->data_arg[STKTABLE_DT_HTTP_REQ_RATE].u, 1);
[MEDIUM] session-counters: add HTTP req/err tracking This patch adds support for the following session counters : - http_req_cnt : HTTP request count - http_req_rate: HTTP request rate - http_err_cnt : HTTP request error count - http_err_rate: HTTP request error rate The equivalent ACLs have been added to check the tracked counters for the current session or the counters of the current source.
2010-06-23 05:44:09 -04:00
}
}
/* Increase the number of cumulated failed HTTP requests in the tracked
* counters. Only 4xx requests should be counted here so that we can
* distinguish between errors caused by client behaviour and other ones.
* Note that even 404 are interesting because they're generally caused by
* vulnerability scans.
*/
static void inline session_inc_http_err_ctr(struct session *s)
{
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
void *ptr;
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
int i;
[MAJOR] session-counters: split FE and BE track counters Having a single tracking pointer for both frontend and backend counters does not work. Instead let's have one for each. The keyword has changed to "track-be-counters" and "track-fe-counters", and the ACL "trk_*" changed to "trkfe_*" and "trkbe_*".
2010-08-03 10:29:52 -04:00
MINOR: session: make the number of stick counter entries more configurable In preparation of more flexibility in the stick counters, make their number configurable. It still defaults to 3 which is the minimum accepted value. Changing the value alone is not sufficient to get more counters, some bitfields still need to be updated and the TCP actions need to be updated as well, but this update tries to be easier, which is nice for experimentation purposes.
2013-07-23 13:15:30 -04:00
for (i = 0; i < MAX_SESS_STKCTR; i++) {
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
if (!stkctr_entry(&s->stkctr[i]))
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
continue;
[MEDIUM] session-counters: add HTTP req/err tracking This patch adds support for the following session counters : - http_req_cnt : HTTP request count - http_req_rate: HTTP request rate - http_err_cnt : HTTP request error count - http_err_rate: HTTP request error rate The equivalent ACLs have been added to check the tracked counters for the current session or the counters of the current source.
2010-06-23 05:44:09 -04:00
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
ptr = stktable_data_ptr(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]), STKTABLE_DT_HTTP_ERR_CNT);
[MEDIUM] session-counters: add HTTP req/err tracking This patch adds support for the following session counters : - http_req_cnt : HTTP request count - http_req_rate: HTTP request rate - http_err_cnt : HTTP request error count - http_err_rate: HTTP request error rate The equivalent ACLs have been added to check the tracked counters for the current session or the counters of the current source.
2010-06-23 05:44:09 -04:00
if (ptr)
stktable_data_cast(ptr, http_err_cnt)++;
MEDIUM: counters: stop relying on session flags at all Till now, we had one flag per stick counter to indicate if it was tracked in a backend or in a frontend. We just had to add another flag per stick-counter to indicate if it relies on contents or just connection. These flags are quite painful to maintain and tend to easily conflict with other flags if their number is changed. The correct solution consists in moving the flags to the stkctr struct itself, but currently this struct is made of 2 pointers, so adding a new entry there to store only two bits will cause at least 16 more bytes to be eaten per counter due to alignment issues, and we definitely don't want to waste tens to hundreds of bytes per session just for things that most users don't use. Since we only need to store two bits per counter, an intermediate solution consists in replacing the entry pointer with a composite value made of the original entry pointer and the two flags in the 2 unused lower bits. If later a need for other flags arises, we'll have to store them in the struct. A few inline functions have been added to abstract the retrieval and assignment of the pointers and flags, resulting in very few changes. That way there is no more dependence on the number of stick-counters and their position in the session flags.
2014-01-28 17:18:23 -05:00
ptr = stktable_data_ptr(s->stkctr[i].table, stkctr_entry(&s->stkctr[i]), STKTABLE_DT_HTTP_ERR_RATE);
[MEDIUM] session-counters: add HTTP req/err tracking This patch adds support for the following session counters : - http_req_cnt : HTTP request count - http_req_rate: HTTP request rate - http_err_cnt : HTTP request error count - http_err_rate: HTTP request error rate The equivalent ACLs have been added to check the tracked counters for the current session or the counters of the current source.
2010-06-23 05:44:09 -04:00
if (ptr)
update_freq_ctr_period(&stktable_data_cast(ptr, http_err_rate),
CLEANUP: session: use an array for the stick counters The stick counters were in two distinct sets of struct members, causing some code to be duplicated. Now we use an array, which enables some processing to be performed in loops. This allowed the code to be shrunk by 700 bytes.
2012-12-09 09:55:40 -05:00
s->stkctr[i].table->data_arg[STKTABLE_DT_HTTP_ERR_RATE].u, 1);
[MEDIUM] session-counters: add HTTP req/err tracking This patch adds support for the following session counters : - http_req_cnt : HTTP request count - http_req_rate: HTTP request rate - http_err_cnt : HTTP request error count - http_err_rate: HTTP request error rate The equivalent ACLs have been added to check the tracked counters for the current session or the counters of the current source.
2010-06-23 05:44:09 -04:00
}
}
[MINOR] Add active connection list to server The motivation for this is to allow iteration of all the connections of a server without the expense of iterating over the global list of connections. The first use of this will be to implement an option to close connections associated with a server when is is marked as being down or in maintenance mode.
2011-06-21 01:34:57 -04:00
static void inline session_add_srv_conn(struct session *sess, struct server *srv)
{
sess->srv_conn = srv;
LIST_ADD(&srv->actconns, &sess->by_srv);
}
static void inline session_del_srv_conn(struct session *sess)
{
if (!sess->srv_conn)
return;
sess->srv_conn = NULL;
LIST_DEL(&sess->by_srv);
}
[BUG] session: risk of crash on out of memory (1.5-dev regression) Patch af5149 introduced an issue which can be detected only on out of memory conditions : a LIST_DEL() may be performed on an uninitialized struct member instead of a LIST_INIT() during the accept() phase, causing crashes and memory corruption to occur. This issue was detected and diagnosed by the Exceliance R&D team. This is 1.5-specific and very recent, so no existing deployment should be impacted.
2011-07-19 18:17:39 -04:00
static void inline session_init_srv_conn(struct session *sess)
{
sess->srv_conn = NULL;
LIST_INIT(&sess->by_srv);
}
[BIGMOVE] exploded the monolithic haproxy.c file into multiple files. The files are now stored under : - include/haproxy for the generic includes - include/types.h for the structures needed within prototypes - include/proto.h for function prototypes and inline functions - src/*.c for the C files Most include files are now covered by LGPL. A last move still needs to be done to put inline functions under GPL and not LGPL. Version has been set to 1.3.0 in the code but some control still needs to be done before releasing.
2006-06-25 20:48:02 -04:00
#endif /* _PROTO_SESSION_H */
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/
Reference in a new issue Copy permalink