{"id":154,"date":"2015-12-31T09:10:15","date_gmt":"2015-12-31T08:10:15","guid":{"rendered":"http:\/\/www.jacquescortes.fr\/blog\/?p=154"},"modified":"2016-01-05T22:56:48","modified_gmt":"2016-01-05T21:56:48","slug":"api-throttling-et-rate-limiting","status":"publish","type":"post","link":"http:\/\/www.jacquescortes.fr\/blog\/2015\/12\/api-throttling-et-rate-limiting\/","title":{"rendered":"API throttling et rate limiting"},"content":{"rendered":"

Nous allons aujourd’hui aborder\u00a02 concepts : l’API throttling et le rate limiting.<\/p>\n

Le premier sert \u00e0 prot\u00e9ger d’un trop grand nombre de requ\u00eates simultan\u00e9es sur une API REST par exemple, ou tout serveur HTTP et m\u00eame cluster de serveurs HTTP (au niveau du load balancer).<\/p>\n

Le deuxi\u00e8me sert \u00e0 s’auto-limiter en se fixant un nombre maximum d’actions par p\u00e9riode donn\u00e9e.
\nCela peut \u00eatre un nombre d’octets par seconde pour limiter l’usage de bande passante ou bien un nombre de requ\u00eates par minute vers un r\u00e9f\u00e9rentiel commun au SI qui n’a pas lui m\u00eame une protection avec une gestion de quota par exemple.<\/p>\n

API throttling<\/h1>\n

 <\/p>\n

C\u00f4t\u00e9 serveur<\/h2>\n

Dans la conception d’une API REST, il est bien dans les tests de charge de mesurer la limite du nombre de requ\u00eates simultan\u00e9es que peut accepter la plateforme et de mettre en place un syst\u00e8me emp\u00eachant de d\u00e9passer cette limite pour ne pas d\u00e9grader le fonctionnement pour l’ensemble des utilisateurs.<\/p>\n

L’exemple classique est l’application mobile qui suite \u00e0 un coup de pub re\u00e7oit un succ\u00e8s non pr\u00e9vu.
\nSi rien n’est fait, les utilisateurs vont constater des dysfonctionnements tels qu’ils risquent de ne plus revenir.
\nDes dysfonctionnements du genre login particuli\u00e8rement long (plus d’une minute), double d\u00e9bit sur la carte bleue lors d’un paiement, etc…
\nLe plus sage est de mettre en place un syst\u00e8me qui va r\u00e9pondre un code d’erreur HTTP lors du d\u00e9passement de la limite.
\nLe code HTTP pr\u00e9vu pour \u00e7a est le code 429 Too many requests<\/strong>.<\/p>\n

\"HTTP<\/a><\/p>\n

Cette erreur est pr\u00e9vue dans la\u00a0RFC 6585<\/a> Additional HTTP Status Codes<\/em>.<\/p>\n

Petit extrait :<\/p>\n

The 429 status code indicates that the user has sent too many requests in a given amount of time (\u00ab\u00a0rate limiting\u00a0\u00bb).<\/p>\n

The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request…<\/p>\n

Note that this specification does not define how the origin server identifies the user, nor how it counts requests.\u00a0For example, an origin server that is limiting request rates can do so based upon counts of requests on a per-resource basis, across the entire server, or even among a set of servers.\u00a0Likewise, it might identify the user by its authentication credentials, or a stateful cookie.<\/p>\n

Responses with the 429 status code MUST NOT be stored by a cache…
\n<\/code><\/p><\/blockquote>\n

Il y a diff\u00e9rentes fa\u00e7ons d’impl\u00e9menter une\u00a0limitation.
\nLe plus simple est le param\u00e9trage du load balancer s’il dispose de cette fonctionnalit\u00e9.
\nPar exemple pour HAProxy<\/strong> :\u00a0https:\/\/blog.codecentric.de\/en\/201n4\/12\/haproxy-http-header-rate-limiting\/
\n<\/a><\/p>\n

On peut aussi le faire au niveau des serveurs HTTP Apache frontaux avec un module. Il en existe des tout faits, mais on peut aussi en d\u00e9velopper un custom sur mesure qui \u00e0 l’aide d’un serveur memcached (ou Redis…) va centraliser pour l’ensemble des serveurs Apache les donn\u00e9es d’usage par utilisateur, IP ou tout autre identifiant qui peut \u00eatre g\u00e9r\u00e9 par cookie par exemple.<\/p>\n

L’int\u00e9r\u00eat d’un module sur mesure est de permettre de g\u00e9rer l’ensemble des r\u00e8gles de limitation qui peuvent exister.
\nPar exemple :<\/p>\n