Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
lua-resty-limit-traffic — Libreria Lua per limitare e controllare il traffico in OpenResty/ngx_lua | Kitploit
Strumenti/GitHubGitHub/openresty/lua-resty-limit-traffic
Strumenti DifensiviUtilità GenericheSicurezza Web
GitHubopenresty/lua-resty-limit-traffic

lua-resty-limit-traffic

Libreria Lua per limitare e controllare il traffico in OpenResty/ngx_lua

Vedi Repository

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
8521571 mese faRevisionato da Kitploit

Nome

lua-resty-limit-traffic - Libreria Lua per limitare e controllare il traffico in OpenResty/ngx_lua

Indice

  • Nome
  • Stato
  • Sinossi
  • Descrizione
  • Installazione
  • Comunità
    • Mailing list in inglese
    • Mailing list in cinese
  • Bug e patch
  • Autore
  • Copyright e licenza
  • Vedi anche

Stato

Questa libreria è già utilizzabile, sebbene sia ancora altamente sperimentale.

L'API Lua è ancora in evoluzione e potrebbe cambiare nel prossimo futuro senza preavviso.

Sinossi

root@kitploit:~
# demonstrate the usage of the resty.limit.req module (alone!)
http {
    lua_shared_dict my_limit_req_store 100m;

    server {
        location / {
            access_by_lua_block {
                -- well, we could put the require() and new() calls in our own Lua
                -- modules to save overhead. here we put them below just for
                -- convenience.

                local limit_req = require "resty.limit.req"

                -- limit the requests under 200 req/sec with a burst of 100 req/sec,
                -- that is, we delay requests under 300 req/sec and above 200
                -- req/sec, and reject any requests exceeding 300 req/sec.
                local lim, err = limit_req.new("my_limit_req_store", 200, 100)
                if not lim then
                    ngx.log(ngx.ERR,
                            "failed to instantiate a resty.limit.req object: ", err)
                    return ngx.exit(500)
                end

                -- the following call must be per-request.
                -- here we use the remote (IP) address as the limiting key
                local key = ngx.var.binary_remote_addr
                local delay, err = lim:incoming(key, true)
                if not delay then
                    if err == "rejected" then
                        return ngx.exit(503)
                    end
                    ngx.log(ngx.ERR, "failed to limit req: ", err)
                    return ngx.exit(500)
                end

                if delay >= 0.001 then
                    -- the 2nd return value holds the number of excess requests
                    -- per second for the specified key. for example, number 31
                    -- means the current request rate is at 231 req/sec for the
                    -- specified key.
                    local excess = err

                    -- the request exceeding the 200 req/sec but below 300 req/sec,
                    -- so we intentionally delay it here a bit to conform to the
                    -- 200 req/sec rate.
                    ngx.sleep(delay)
                end
            }

            # content handler goes here. if it is content_by_lua, then you can
            # merge the Lua code above in access_by_lua into your content_by_lua's
            # Lua handler to save a little bit of CPU time.
        }
    }
}
root@kitploit:~
# demonstrate the usage of the resty.limit.conn module (alone!)
http {
    lua_shared_dict my_limit_conn_store 100m;

    server {
        location / {
            access_by_lua_block {
                -- well, we could put the require() and new() calls in our own Lua
                -- modules to save overhead. here we put them below just for
                -- convenience.

                local limit_conn = require "resty.limit.conn"

                -- limit the requests under 200 concurrent requests (normally just
                -- incoming connections unless protocols like SPDY is used) with
                -- a burst of 100 extra concurrent requests, that is, we delay
                -- requests under 300 concurrent connections and above 200
                -- connections, and reject any new requests exceeding 300
                -- connections.
                -- also, we assume a default request time of 0.5 sec, which can be
                -- dynamically adjusted by the leaving() call in log_by_lua below.
                local lim, err = limit_conn.new("my_limit_conn_store", 200, 100, 0.5)
                if not lim then
                    ngx.log(ngx.ERR,
                            "failed to instantiate a resty.limit.conn object: ", err)
                    return ngx.exit(500)
                end

                -- the following call must be per-request.
                -- here we use the remote (IP) address as the limiting key
                local key = ngx.var.binary_remote_addr
                local delay, err = lim:incoming(key, true)
                if not delay then
                    if err == "rejected" then
                        return ngx.exit(503)
                    end
                    ngx.log(ngx.ERR, "failed to limit req: ", err)
                    return ngx.exit(500)
                end

                if lim:is_committed() then
                    local ctx = ngx.ctx
                    ctx.limit_conn = lim
                    ctx.limit_conn_key = key
                    ctx.limit_conn_delay = delay
                end

                -- the 2nd return value holds the current concurrency level
                -- for the specified key.
                local conn = err

                if delay >= 0.001 then
                    -- the request exceeding the 200 connections ratio but below
                    -- 300 connections, so
                    -- we intentionally delay it here a bit to conform to the
                    -- 200 connection limit.
                    -- ngx.log(ngx.WARN, "delaying")
                    ngx.sleep(delay)
                end
            }

            # content handler goes here. if it is content_by_lua, then you can
            # merge the Lua code above in access_by_lua into your
            # content_by_lua's Lua handler to save a little bit of CPU time.

            log_by_lua_block {
                local ctx = ngx.ctx
                local lim = ctx.limit_conn
                if lim then
                    -- if you are using an upstream module in the content phase,
                    -- then you probably want to use $upstream_response_time
                    -- instead of ($request_time - ctx.limit_conn_delay) below.
                    local latency = tonumber(ngx.var.request_time) - ctx.limit_conn_delay
                    local key = ctx.limit_conn_key
                    assert(key)
                    local conn, err = lim:leaving(key, latency)
                    if not conn then
                        ngx.log(ngx.ERR,
                                "failed to record the connection leaving ",
                                "request: ", err)
                        return
                    end
                end
            }
        }
    }
}
root@kitploit:~
# demonstrate the usage of the resty.limit.traffic module
http {
    lua_shared_dict my_req_store 100m;
    lua_shared_dict my_conn_store 100m;

    server {
        location / {
            access_by_lua_block {
                local limit_conn = require "resty.limit.conn"
                local limit_req = require "resty.limit.req"
                local limit_traffic = require "resty.limit.traffic"

                local lim1, err = limit_req.new("my_req_store", 300, 200)
                assert(lim1, err)
                local lim2, err = limit_req.new("my_req_store", 200, 100)
                assert(lim2, err)
                local lim3, err = limit_conn.new("my_conn_store", 1000, 1000, 0.5)
                assert(lim3, err)

                local limiters = {lim1, lim2, lim3}

                local host = ngx.var.host
                local client = ngx.var.binary_remote_addr
                local keys = {host, client, client}

                local states = {}

                local delay, err = limit_traffic.combine(limiters, keys, states)
                if not delay then
                    if err == "rejected" then
                        return ngx.exit(503)
                    end
                    ngx.log(ngx.ERR, "failed to limit traffic: ", err)
                    return ngx.exit(500)
                end

                if lim3:is_committed() then
                    local ctx = ngx.ctx
                    ctx.limit_conn = lim3
                    ctx.limit_conn_key = keys[3]
                end

                print("sleeping ", delay, " sec, states: ",
                      table.concat(states, ", "))

                if delay >= 0.001 then
                    ngx.sleep(delay)
                end
            }

            # content handler goes here. if it is content_by_lua, then you can
            # merge the Lua code above in access_by_lua into your
            # content_by_lua's Lua handler to save a little bit of CPU time.

            log_by_lua_block {
                local ctx = ngx.ctx
                local lim = ctx.limit_conn
                if lim then
                    -- if you are using an upstream module in the content phase,
                    -- then you probably want to use $upstream_response_time
                    -- instead of $request_time below.
                    local latency = tonumber(ngx.var.request_time)
                    local key = ctx.limit_conn_key
                    assert(key)
                    local conn, err = lim:leaving(key, latency)
                    if not conn then
                        ngx.log(ngx.ERR,
                                "failed to record the connection leaving ",
                                "request: ", err)
                        return
                    end
                end
            }
        }
    }
}

Descrizione

Questa libreria fornisce diversi moduli Lua per aiutare gli utenti di OpenResty/ngx_lua a controllare e limitare il traffico, sia la frequenza delle richieste che la concorrenza delle richieste (o entrambe).

  • resty.limit.req fornisce la limitazione e la regolazione della frequenza delle richieste basate sul metodo "leaky bucket".
  • resty.limit.count fornisce la limitazione della frequenza basata su un'implementazione a "finestra fissa" a partire da OpenResty 1.13.6.1+.
  • resty.limit.conn fornisce la limitazione del livello di concorrenza delle richieste e la relativa regolazione basate su ritardi aggiuntivi.
  • resty.limit.traffic fornisce un aggregatore per combinare più istanze delle classi resty.limit.req, resty.limit.count o resty.limit.conn (o tutte).

Per maggiori dettagli, consultare la documentazione specifica di questi moduli Lua.

Questa libreria offre alternative più flessibili ai moduli standard di NGINX ngx_limit_req e ngx_limit_conn. Ad esempio, i limitatori basati su Lua forniti da questa libreria possono essere utilizzati in qualsiasi contesto, come subito prima della procedura di handshake SSL a valle (come con ssl_certificate_by_lua) o subito prima di inoltrare le richieste al backend.

Torna all'indice

Installazione

Questa libreria è abilitata per impostazione predefinita in OpenResty 1.11.2.2+.

Se devi installare manualmente questa libreria, assicurati di utilizzare almeno OpenResty 1.11.2.1 o una build personalizzata di nginx che includa ngx_lua 0.10.6+. Inoltre, devi configurare la direttiva lua_package_path per aggiungere il percorso dell'albero dei sorgenti di lua-resty-limit-traffic al percorso di ricerca dei moduli Lua di ngx_lua, come segue

root@kitploit:~
# nginx.conf
http {
    lua_package_path "/path/to/lua-resty-limit-traffic/lib/?.lua;;";
    ...
}

e quindi caricare in Lua uno dei moduli forniti da questa libreria. Ad esempio,

root@kitploit:~
local limit_req = require "resty.limit.req"

Torna all'indice

Comunità

Torna all'indice

Mailing list in inglese

La mailing list openresty-en è per chi parla inglese.

Torna all'indice

Mailing list in cinese

La mailing list openresty è per chi parla cinese.

Torna all'indice

Bug e patch

Segnala bug o invia patch

  1. creando un ticket sul GitHub Issue Tracker,
  2. oppure scrivendo alla community di OpenResty.

Torna all'indice

Autore

Yichun "agentzh" Zhang (章亦春) [email protected], OpenResty Inc.

Torna all'indice

Copyright e licenza

Questo modulo è concesso in licenza secondo i termini della licenza BSD.

Copyright (C) 2015-2019, di Yichun "agentzh" Zhang, OpenResty Inc.

Tutti i diritti riservati.

La redistribuzione e l'utilizzo in forma sorgente e binaria, con o senza modifiche, sono consentiti alle seguenti condizioni:

  • Le redistribuzioni del codice sorgente devono conservare il suddetto avviso di copyright, questo elenco di condizioni e il seguente disclaimer.

  • Le redistribuzioni in forma binaria devono riprodurre il suddetto avviso di copyright, questo elenco di condizioni e il seguente disclaimer nella documentazione e/o negli altri materiali forniti con la distribuzione.

QUESTO SOFTWARE È FORNITO DAI TITOLARI DEL COPYRIGHT E DAI CONTRIBUTORI "COSÌ COM'È" E QUALSIASI GARANZIA ESPLICITA O IMPLICITA, INCLUSI, MA NON LIMITATI A, LE GARANZIE IMPLICITE DI COMMERCIABILITÀ E IDONEITÀ PER UNO SCOPO PARTICOLARE, SONO DECLINATE. IN NESSUN CASO IL TITOLARE DEL COPYRIGHT O I CONTRIBUTORI SARANNO RESPONSABILI PER QUALSIASI DANNO DIRETTO, INDIRETTO, INCIDENTALE, SPECIALE, ESEMPLARE O CONSEQUENZIALE (INCLUSI, MA NON LIMITATI A, L'APPROVVIGIONAMENTO DI BENI O SERVIZI SOSTITUTIVI; LA PERDITA DI UTILIZZO, DATI O PROFITTI; O L'INTERRUZIONE DELL'ATTIVITÀ AZIENDALE) COMUNQUE CAUSATO E IN BASE A QUALSIASI TEORIA DI RESPONSABILITÀ, SIA CONTRATTUALE, CHE EXTRACONTRATTUALE O ILLECITA (INCLUSA LA NEGLIGENZA O ALTRO), DERIVANTE IN QUALSIASI MODO DALL'UTILIZZO DI QUESTO SOFTWARE, ANCHE SE AVVISATI DELLA POSSIBILITÀ DI TALI DANNI.

Torna all'indice

Vedi anche

  • modulo resty.limit.req
  • modulo resty.limit.count
  • modulo resty.limit.conn
  • modulo resty.limit.traffic
  • il modulo ngx_lua: https://github.com/openresty/lua-nginx-module
  • OpenResty: https://openresty.org/

Torna all'indice

Scarica lo strumento