Salve,
inquesti ultimo periodo (ma probabilmente da tempo), mi sono accorto che nei nostri wms arrivano a ondate periodiche richieste che ci saturano completamente isistemi. Parlo di richiesta a distanza di qualche millesimo di secondo . Tutte dai medesimi indirizzi (piu' di uno). Ecco un esempio delle tempistiche che rilevo: "2019-01-24T17:14:12.238Z" "2019-01-24T17:14:12.245Z", "2019-01-24T17:14:12.256Z", "2019-01-24T17:14:12.261Z" "2019-01-24T17:14:12.275Z", "2019-01-24T17:14:12.279Z", "2019-01-24T17:14:12.292Z", "2019-01-24T17:14:12.295Z", "2019-01-24T17:14:12.314Z", "2019-01-24T17:14:12.316Z" "2019-01-24T17:14:12.332Z", "2019-01-24T17:14:12.337Z", "2019-01-24T17:14:12.350Z", Il nostro server wms non riesce a stare dietro a questa bombardata di richieste. E di conseguenza diventa lento e finisce per mandare a vuoto le richieste di utenti piu' seri che lo utilizzano per bene. Sarei interessato a sapere se esistono soluzioni note a questo tipo di problema. Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha trovato una qualche forma di soluzione. Io immaginerei una qualche soluzione tesa a limitare o addirittura rifiutare le richiste a utenti che ne stanno facendo troppe in un tempo troppo breve. Tenderei a escludere soluzioni che prevedano la profilazione di utenti per varie ragioni anche tecniche. Grazie, -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Ciao Andrea,
vi serve una protezione anti DDoS. Ce ne sono diverse, più o meno sofisticate, ma la maggior parte offre schemi di difesa (rate limiting) da richieste come quelle che stai rilevando. Giovanni Il giorno gio 7 feb 2019, 18:53 Andrea Peri <[hidden email]> ha scritto: > Salve, > > inquesti ultimo periodo (ma probabilmente da tempo), > mi sono accorto che nei nostri wms arrivano a ondate periodiche richieste > che ci saturano completamente isistemi. > > Parlo di richiesta a distanza di qualche millesimo di secondo . > Tutte dai medesimi indirizzi (piu' di uno). > > Ecco un esempio delle tempistiche che rilevo: > > "2019-01-24T17:14:12.238Z" > "2019-01-24T17:14:12.245Z", > "2019-01-24T17:14:12.256Z", > "2019-01-24T17:14:12.261Z" > "2019-01-24T17:14:12.275Z", > "2019-01-24T17:14:12.279Z", > "2019-01-24T17:14:12.292Z", > "2019-01-24T17:14:12.295Z", > "2019-01-24T17:14:12.314Z", > "2019-01-24T17:14:12.316Z" > "2019-01-24T17:14:12.332Z", > "2019-01-24T17:14:12.337Z", > "2019-01-24T17:14:12.350Z", > > Il nostro server wms non riesce a stare dietro a questa bombardata di > richieste. > E di conseguenza diventa lento e finisce per mandare a vuoto le richieste > di utenti piu' seri che lo utilizzano per bene. > > Sarei interessato a sapere se esistono soluzioni note a questo tipo di > problema. > Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha trovato > una qualche forma di soluzione. > Io immaginerei una qualche soluzione tesa a limitare o addirittura > rifiutare le richiste a utenti che ne stanno facendo troppe in un tempo > troppo breve. > > Tenderei a escludere soluzioni che prevedano la profilazione di utenti per > varie ragioni anche tecniche. > > Grazie, > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
postilla alla precedente risposta. Immagino abbiate già verificato che non
si tratti di richiesta WMS tilizzate. Il giorno gio 7 feb 2019, 19:26 G. Allegri <[hidden email]> ha scritto: > Ciao Andrea, > vi serve una protezione anti DDoS. Ce ne sono diverse, più o meno > sofisticate, ma la maggior parte offre schemi di difesa (rate limiting) da > richieste come quelle che stai rilevando. > > Giovanni > > > > Il giorno gio 7 feb 2019, 18:53 Andrea Peri <[hidden email]> ha > scritto: > >> Salve, >> >> inquesti ultimo periodo (ma probabilmente da tempo), >> mi sono accorto che nei nostri wms arrivano a ondate periodiche richieste >> che ci saturano completamente isistemi. >> >> Parlo di richiesta a distanza di qualche millesimo di secondo . >> Tutte dai medesimi indirizzi (piu' di uno). >> >> Ecco un esempio delle tempistiche che rilevo: >> >> "2019-01-24T17:14:12.238Z" >> "2019-01-24T17:14:12.245Z", >> "2019-01-24T17:14:12.256Z", >> "2019-01-24T17:14:12.261Z" >> "2019-01-24T17:14:12.275Z", >> "2019-01-24T17:14:12.279Z", >> "2019-01-24T17:14:12.292Z", >> "2019-01-24T17:14:12.295Z", >> "2019-01-24T17:14:12.314Z", >> "2019-01-24T17:14:12.316Z" >> "2019-01-24T17:14:12.332Z", >> "2019-01-24T17:14:12.337Z", >> "2019-01-24T17:14:12.350Z", >> >> Il nostro server wms non riesce a stare dietro a questa bombardata di >> richieste. >> E di conseguenza diventa lento e finisce per mandare a vuoto le richieste >> di utenti piu' seri che lo utilizzano per bene. >> >> Sarei interessato a sapere se esistono soluzioni note a questo tipo di >> problema. >> Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha trovato >> una qualche forma di soluzione. >> Io immaginerei una qualche soluzione tesa a limitare o addirittura >> rifiutare le richiste a utenti che ne stanno facendo troppe in un tempo >> troppo breve. >> >> Tenderei a escludere soluzioni che prevedano la profilazione di utenti per >> varie ragioni anche tecniche. >> >> Grazie, >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- >> _______________________________________________ >> [hidden email] >> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >> Questa e' una lista di discussione pubblica aperta a tutti. >> I messaggi di questa lista non hanno relazione diretta con le posizioni >> dell'Associazione GFOSS.it. >> 796 iscritti al 28/12/2017 > > [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Non sono in grado di distinguere una chiamata tilizzata da una non.
Ma se anche lo fosse il risultato non cambia. Se mimandano 2000 richieste al secondo il sistema impazzisce perche' la sua coda delle richieste si esaurisce prima. Il giorno gio 7 feb 2019 alle ore 20:14 G. Allegri <[hidden email]> ha scritto: > postilla alla precedente risposta. Immagino abbiate già verificato che non > si tratti di richiesta WMS tilizzate. > > Il giorno gio 7 feb 2019, 19:26 G. Allegri <[hidden email]> ha > scritto: > >> Ciao Andrea, >> vi serve una protezione anti DDoS. Ce ne sono diverse, più o meno >> sofisticate, ma la maggior parte offre schemi di difesa (rate limiting) da >> richieste come quelle che stai rilevando. >> >> Giovanni >> >> >> >> Il giorno gio 7 feb 2019, 18:53 Andrea Peri <[hidden email]> ha >> scritto: >> >>> Salve, >>> >>> inquesti ultimo periodo (ma probabilmente da tempo), >>> mi sono accorto che nei nostri wms arrivano a ondate periodiche richieste >>> che ci saturano completamente isistemi. >>> >>> Parlo di richiesta a distanza di qualche millesimo di secondo . >>> Tutte dai medesimi indirizzi (piu' di uno). >>> >>> Ecco un esempio delle tempistiche che rilevo: >>> >>> "2019-01-24T17:14:12.238Z" >>> "2019-01-24T17:14:12.245Z", >>> "2019-01-24T17:14:12.256Z", >>> "2019-01-24T17:14:12.261Z" >>> "2019-01-24T17:14:12.275Z", >>> "2019-01-24T17:14:12.279Z", >>> "2019-01-24T17:14:12.292Z", >>> "2019-01-24T17:14:12.295Z", >>> "2019-01-24T17:14:12.314Z", >>> "2019-01-24T17:14:12.316Z" >>> "2019-01-24T17:14:12.332Z", >>> "2019-01-24T17:14:12.337Z", >>> "2019-01-24T17:14:12.350Z", >>> >>> Il nostro server wms non riesce a stare dietro a questa bombardata di >>> richieste. >>> E di conseguenza diventa lento e finisce per mandare a vuoto le richieste >>> di utenti piu' seri che lo utilizzano per bene. >>> >>> Sarei interessato a sapere se esistono soluzioni note a questo tipo di >>> problema. >>> Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha >>> trovato >>> una qualche forma di soluzione. >>> Io immaginerei una qualche soluzione tesa a limitare o addirittura >>> rifiutare le richiste a utenti che ne stanno facendo troppe in un tempo >>> troppo breve. >>> >>> Tenderei a escludere soluzioni che prevedano la profilazione di utenti >>> per >>> varie ragioni anche tecniche. >>> >>> Grazie, >>> >>> -- >>> ----------------- >>> Andrea Peri >>> . . . . . . . . . >>> qwerty àèìòù >>> ----------------- >>> _______________________________________________ >>> [hidden email] >>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>> Questa e' una lista di discussione pubblica aperta a tutti. >>> I messaggi di questa lista non hanno relazione diretta con le posizioni >>> dell'Associazione GFOSS.it. >>> 796 iscritti al 28/12/2017 >> >> -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Andrea,
le puoi riconoscere se i parametri WIDTH e HEIGHT della get hanno valori tipo 256 e 256 o 512 e 512, che sono i due default per le tile. è vero che non ti cambia nulla saperlo, ma almeno puoi distinguere le richieste vere dai robot. saluti, francesco Il giorno gio 7 feb 2019 alle ore 20:28 Andrea Peri <[hidden email]> ha scritto: > Non sono in grado di distinguere una chiamata tilizzata da una non. > > _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
In reply to this post by Andrea Peri
Preciso meglio:
Non sono in grado di distinguerle perche' non conosco le chiamate tilizzate. Non le conosco perche' io non lavoro con i tile-servers. Pero' conosco a menadito le chiamate wms e a me sembrano proprio delle belle e chiare chiamate wms. In questo esempio specifico su tasselli 256x256 , ma questo non significa che sia un server tiled. resta il fatto che sono migliaia di chiamate al secondo dai medesimi indirizzi. Ovviamente mentre il sistema ne riceve molte anche da altri utenti. Il mio obiettivo è discriminare queste chiamate che sono in numero abnorme e scartarle, senza scartare , invece, quelle piu' normali di altri utenti che panneggiano o zoomano normalmente a video o roba del genere... NOn avrei nulla in contario a queste chiamate serializzate se fossero usate "cum grano salis", ma visto che quando partono queste bambole tutti gli altri utenti ne soffrono, non vedo altra soluzione che combatterle con ogni mezzo. Ce stato un periodo che tutti i giorni alla medesima ora partiva questa bambola e per meta' mattinata e il primo pomeriggio i nostri servers wms si saturavano. Mo' basta. A. Il giorno gio 7 feb 2019 alle ore 20:28 Andrea Peri <[hidden email]> ha scritto: > Non sono in grado di distinguere una chiamata tilizzata da una non. > Ma se anche lo fosse il risultato non cambia. > Se mimandano 2000 richieste al secondo il sistema impazzisce perche' la > sua coda delle richieste si esaurisce prima. > > > Il giorno gio 7 feb 2019 alle ore 20:14 G. Allegri <[hidden email]> > ha scritto: > >> postilla alla precedente risposta. Immagino abbiate già verificato che >> non si tratti di richiesta WMS tilizzate. >> >> Il giorno gio 7 feb 2019, 19:26 G. Allegri <[hidden email]> ha >> scritto: >> >>> Ciao Andrea, >>> vi serve una protezione anti DDoS. Ce ne sono diverse, più o meno >>> sofisticate, ma la maggior parte offre schemi di difesa (rate limiting) da >>> richieste come quelle che stai rilevando. >>> >>> Giovanni >>> >>> >>> >>> Il giorno gio 7 feb 2019, 18:53 Andrea Peri <[hidden email]> ha >>> scritto: >>> >>>> Salve, >>>> >>>> inquesti ultimo periodo (ma probabilmente da tempo), >>>> mi sono accorto che nei nostri wms arrivano a ondate periodiche >>>> richieste >>>> che ci saturano completamente isistemi. >>>> >>>> Parlo di richiesta a distanza di qualche millesimo di secondo . >>>> Tutte dai medesimi indirizzi (piu' di uno). >>>> >>>> Ecco un esempio delle tempistiche che rilevo: >>>> >>>> "2019-01-24T17:14:12.238Z" >>>> "2019-01-24T17:14:12.245Z", >>>> "2019-01-24T17:14:12.256Z", >>>> "2019-01-24T17:14:12.261Z" >>>> "2019-01-24T17:14:12.275Z", >>>> "2019-01-24T17:14:12.279Z", >>>> "2019-01-24T17:14:12.292Z", >>>> "2019-01-24T17:14:12.295Z", >>>> "2019-01-24T17:14:12.314Z", >>>> "2019-01-24T17:14:12.316Z" >>>> "2019-01-24T17:14:12.332Z", >>>> "2019-01-24T17:14:12.337Z", >>>> "2019-01-24T17:14:12.350Z", >>>> >>>> Il nostro server wms non riesce a stare dietro a questa bombardata di >>>> richieste. >>>> E di conseguenza diventa lento e finisce per mandare a vuoto le >>>> richieste >>>> di utenti piu' seri che lo utilizzano per bene. >>>> >>>> Sarei interessato a sapere se esistono soluzioni note a questo tipo di >>>> problema. >>>> Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha >>>> trovato >>>> una qualche forma di soluzione. >>>> Io immaginerei una qualche soluzione tesa a limitare o addirittura >>>> rifiutare le richiste a utenti che ne stanno facendo troppe in un tempo >>>> troppo breve. >>>> >>>> Tenderei a escludere soluzioni che prevedano la profilazione di utenti >>>> per >>>> varie ragioni anche tecniche. >>>> >>>> Grazie, >>>> >>>> -- >>>> ----------------- >>>> Andrea Peri >>>> . . . . . . . . . >>>> qwerty àèìòù >>>> ----------------- >>>> _______________________________________________ >>>> [hidden email] >>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>>> Questa e' una lista di discussione pubblica aperta a tutti. >>>> I messaggi di questa lista non hanno relazione diretta con le posizioni >>>> dell'Associazione GFOSS.it. >>>> 796 iscritti al 28/12/2017 >>> >>> > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
In reply to this post by francesco marucci-2
Si, sono tutte a dimensioni 256x256,
ma a parer mio il fatto che siano 256x256 non implica che sia un tile-server. Prendi ad esempio: QGIS desktopse si invoca una stampa di un pdf (esportazione) gli si puo' dire di fare a tassellini di 256x256 . Non ha senso , lo so', ma uno puo' pensare che sia una furbata. Pure il nostro frmework tolomeo puo' essere impostato per invocare un server wms a tasselli di 256x256. La differenza e' che QGIS quando si invia una richiesta di stampa a tsselli 256x256 a 300 dpi, invia tutte richieste in sequenza, ma con un intervallo di tempo tra una richiesta e la successiva che non è 1 millisecondo. Il problema non è invocare tassellini di 256x256 (e' stupido, ma niente di piu'). Il problema e' quando le richieste sono moltissime e a ritmi di 1 ogni 1-2-3 millisecondi. Allora le code di richieste si riempono e finiscono per rifiutare ogni altra richiesta, mettendo fuori gioco altri utenti che vorrebbero panneggiare o zoomare o interrogare. A. Il giorno gio 7 feb 2019 alle ore 20:37 francesco marucci < [hidden email]> ha scritto: > Andrea, > le puoi riconoscere se i parametri WIDTH e HEIGHT della get hanno valori > tipo 256 e 256 o 512 e 512, che sono i due default per le tile. > è vero che non ti cambia nulla saperlo, ma almeno puoi distinguere le > richieste vere dai robot. > > saluti, > francesco > > Il giorno gio 7 feb 2019 alle ore 20:28 Andrea Peri <[hidden email]> > ha scritto: > > > Non sono in grado di distinguere una chiamata tilizzata da una non. > > > > > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
In reply to this post by Andrea Peri
Come dicevo nella prima risposta, ti serve una protezione anti DDoS. Ce ne
sono in tutte le salse e per tutte le tasche. Giovanni Il giorno gio 7 feb 2019, 20:37 Andrea Peri <[hidden email]> ha scritto: > Preciso meglio: > > Non sono in grado di distinguerle perche' non conosco le chiamate > tilizzate. Non le conosco perche' io non lavoro con i tile-servers. > Pero' conosco a menadito le chiamate wms e a me sembrano proprio delle > belle e chiare chiamate wms. > In questo esempio specifico su tasselli 256x256 , ma questo non significa > che sia un server tiled. > > resta il fatto che sono migliaia di chiamate al secondo dai medesimi > indirizzi. > > Ovviamente mentre il sistema ne riceve molte anche da altri utenti. > > Il mio obiettivo è discriminare queste chiamate che sono in numero abnorme > e scartarle, senza scartare , invece, quelle piu' normali di altri utenti > che panneggiano o zoomano normalmente a video o roba del genere... > > NOn avrei nulla in contario a queste chiamate serializzate se fossero > usate "cum grano salis", ma visto che quando partono queste bambole tutti > gli altri utenti ne soffrono, > non vedo altra soluzione che combatterle con ogni mezzo. > > Ce stato un periodo che tutti i giorni alla medesima ora partiva questa > bambola e per meta' mattinata e il primo pomeriggio i nostri servers wms si > saturavano. > > Mo' basta. > > A. > > > Il giorno gio 7 feb 2019 alle ore 20:28 Andrea Peri <[hidden email]> > ha scritto: > >> Non sono in grado di distinguere una chiamata tilizzata da una non. >> Ma se anche lo fosse il risultato non cambia. >> Se mimandano 2000 richieste al secondo il sistema impazzisce perche' la >> sua coda delle richieste si esaurisce prima. >> >> >> Il giorno gio 7 feb 2019 alle ore 20:14 G. Allegri <[hidden email]> >> ha scritto: >> >>> postilla alla precedente risposta. Immagino abbiate già verificato che >>> non si tratti di richiesta WMS tilizzate. >>> >>> Il giorno gio 7 feb 2019, 19:26 G. Allegri <[hidden email]> ha >>> scritto: >>> >>>> Ciao Andrea, >>>> vi serve una protezione anti DDoS. Ce ne sono diverse, più o meno >>>> sofisticate, ma la maggior parte offre schemi di difesa (rate limiting) da >>>> richieste come quelle che stai rilevando. >>>> >>>> Giovanni >>>> >>>> >>>> >>>> Il giorno gio 7 feb 2019, 18:53 Andrea Peri <[hidden email]> ha >>>> scritto: >>>> >>>>> Salve, >>>>> >>>>> inquesti ultimo periodo (ma probabilmente da tempo), >>>>> mi sono accorto che nei nostri wms arrivano a ondate periodiche >>>>> richieste >>>>> che ci saturano completamente isistemi. >>>>> >>>>> Parlo di richiesta a distanza di qualche millesimo di secondo . >>>>> Tutte dai medesimi indirizzi (piu' di uno). >>>>> >>>>> Ecco un esempio delle tempistiche che rilevo: >>>>> >>>>> "2019-01-24T17:14:12.238Z" >>>>> "2019-01-24T17:14:12.245Z", >>>>> "2019-01-24T17:14:12.256Z", >>>>> "2019-01-24T17:14:12.261Z" >>>>> "2019-01-24T17:14:12.275Z", >>>>> "2019-01-24T17:14:12.279Z", >>>>> "2019-01-24T17:14:12.292Z", >>>>> "2019-01-24T17:14:12.295Z", >>>>> "2019-01-24T17:14:12.314Z", >>>>> "2019-01-24T17:14:12.316Z" >>>>> "2019-01-24T17:14:12.332Z", >>>>> "2019-01-24T17:14:12.337Z", >>>>> "2019-01-24T17:14:12.350Z", >>>>> >>>>> Il nostro server wms non riesce a stare dietro a questa bombardata di >>>>> richieste. >>>>> E di conseguenza diventa lento e finisce per mandare a vuoto le >>>>> richieste >>>>> di utenti piu' seri che lo utilizzano per bene. >>>>> >>>>> Sarei interessato a sapere se esistono soluzioni note a questo tipo di >>>>> problema. >>>>> Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha >>>>> trovato >>>>> una qualche forma di soluzione. >>>>> Io immaginerei una qualche soluzione tesa a limitare o addirittura >>>>> rifiutare le richiste a utenti che ne stanno facendo troppe in un tempo >>>>> troppo breve. >>>>> >>>>> Tenderei a escludere soluzioni che prevedano la profilazione di utenti >>>>> per >>>>> varie ragioni anche tecniche. >>>>> >>>>> Grazie, >>>>> >>>>> -- >>>>> ----------------- >>>>> Andrea Peri >>>>> . . . . . . . . . >>>>> qwerty àèìòù >>>>> ----------------- >>>>> _______________________________________________ >>>>> [hidden email] >>>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>>>> Questa e' una lista di discussione pubblica aperta a tutti. >>>>> I messaggi di questa lista non hanno relazione diretta con le >>>>> posizioni dell'Associazione GFOSS.it. >>>>> 796 iscritti al 28/12/2017 >>>> >>>> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- >> > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
ok, guardo un po' che trovo in giro.
Grazie, A. Il giorno gio 7 feb 2019 alle ore 20:48 G. Allegri <[hidden email]> ha scritto: > Come dicevo nella prima risposta, ti serve una protezione anti DDoS. Ce ne > sono in tutte le salse e per tutte le tasche. > > Giovanni > > Il giorno gio 7 feb 2019, 20:37 Andrea Peri <[hidden email]> ha > scritto: > >> Preciso meglio: >> >> Non sono in grado di distinguerle perche' non conosco le chiamate >> tilizzate. Non le conosco perche' io non lavoro con i tile-servers. >> Pero' conosco a menadito le chiamate wms e a me sembrano proprio delle >> belle e chiare chiamate wms. >> In questo esempio specifico su tasselli 256x256 , ma questo non significa >> che sia un server tiled. >> >> resta il fatto che sono migliaia di chiamate al secondo dai medesimi >> indirizzi. >> >> Ovviamente mentre il sistema ne riceve molte anche da altri utenti. >> >> Il mio obiettivo è discriminare queste chiamate che sono in numero >> abnorme e scartarle, senza scartare , invece, quelle piu' normali di altri >> utenti che panneggiano o zoomano normalmente a video o roba del genere... >> >> NOn avrei nulla in contario a queste chiamate serializzate se fossero >> usate "cum grano salis", ma visto che quando partono queste bambole tutti >> gli altri utenti ne soffrono, >> non vedo altra soluzione che combatterle con ogni mezzo. >> >> Ce stato un periodo che tutti i giorni alla medesima ora partiva questa >> bambola e per meta' mattinata e il primo pomeriggio i nostri servers wms si >> saturavano. >> >> Mo' basta. >> >> A. >> >> >> Il giorno gio 7 feb 2019 alle ore 20:28 Andrea Peri <[hidden email]> >> ha scritto: >> >>> Non sono in grado di distinguere una chiamata tilizzata da una non. >>> Ma se anche lo fosse il risultato non cambia. >>> Se mimandano 2000 richieste al secondo il sistema impazzisce perche' la >>> sua coda delle richieste si esaurisce prima. >>> >>> >>> Il giorno gio 7 feb 2019 alle ore 20:14 G. Allegri <[hidden email]> >>> ha scritto: >>> >>>> postilla alla precedente risposta. Immagino abbiate già verificato che >>>> non si tratti di richiesta WMS tilizzate. >>>> >>>> Il giorno gio 7 feb 2019, 19:26 G. Allegri <[hidden email]> ha >>>> scritto: >>>> >>>>> Ciao Andrea, >>>>> vi serve una protezione anti DDoS. Ce ne sono diverse, più o meno >>>>> sofisticate, ma la maggior parte offre schemi di difesa (rate limiting) da >>>>> richieste come quelle che stai rilevando. >>>>> >>>>> Giovanni >>>>> >>>>> >>>>> >>>>> Il giorno gio 7 feb 2019, 18:53 Andrea Peri <[hidden email]> ha >>>>> scritto: >>>>> >>>>>> Salve, >>>>>> >>>>>> inquesti ultimo periodo (ma probabilmente da tempo), >>>>>> mi sono accorto che nei nostri wms arrivano a ondate periodiche >>>>>> richieste >>>>>> che ci saturano completamente isistemi. >>>>>> >>>>>> Parlo di richiesta a distanza di qualche millesimo di secondo . >>>>>> Tutte dai medesimi indirizzi (piu' di uno). >>>>>> >>>>>> Ecco un esempio delle tempistiche che rilevo: >>>>>> >>>>>> "2019-01-24T17:14:12.238Z" >>>>>> "2019-01-24T17:14:12.245Z", >>>>>> "2019-01-24T17:14:12.256Z", >>>>>> "2019-01-24T17:14:12.261Z" >>>>>> "2019-01-24T17:14:12.275Z", >>>>>> "2019-01-24T17:14:12.279Z", >>>>>> "2019-01-24T17:14:12.292Z", >>>>>> "2019-01-24T17:14:12.295Z", >>>>>> "2019-01-24T17:14:12.314Z", >>>>>> "2019-01-24T17:14:12.316Z" >>>>>> "2019-01-24T17:14:12.332Z", >>>>>> "2019-01-24T17:14:12.337Z", >>>>>> "2019-01-24T17:14:12.350Z", >>>>>> >>>>>> Il nostro server wms non riesce a stare dietro a questa bombardata di >>>>>> richieste. >>>>>> E di conseguenza diventa lento e finisce per mandare a vuoto le >>>>>> richieste >>>>>> di utenti piu' seri che lo utilizzano per bene. >>>>>> >>>>>> Sarei interessato a sapere se esistono soluzioni note a questo tipo di >>>>>> problema. >>>>>> Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha >>>>>> trovato >>>>>> una qualche forma di soluzione. >>>>>> Io immaginerei una qualche soluzione tesa a limitare o addirittura >>>>>> rifiutare le richiste a utenti che ne stanno facendo troppe in un >>>>>> tempo >>>>>> troppo breve. >>>>>> >>>>>> Tenderei a escludere soluzioni che prevedano la profilazione di >>>>>> utenti per >>>>>> varie ragioni anche tecniche. >>>>>> >>>>>> Grazie, >>>>>> >>>>>> -- >>>>>> ----------------- >>>>>> Andrea Peri >>>>>> . . . . . . . . . >>>>>> qwerty àèìòù >>>>>> ----------------- >>>>>> _______________________________________________ >>>>>> [hidden email] >>>>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>>>>> Questa e' una lista di discussione pubblica aperta a tutti. >>>>>> I messaggi di questa lista non hanno relazione diretta con le >>>>>> posizioni dell'Associazione GFOSS.it. >>>>>> 796 iscritti al 28/12/2017 >>>>> >>>>> >>> >>> -- >>> ----------------- >>> Andrea Peri >>> . . . . . . . . . >>> qwerty àèìòù >>> ----------------- >>> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- >> > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Uno sicuramente da valutare è HAProxy. Uno dei suoi più noti utenti è
GitHub. Giovanni Il giorno gio 7 feb 2019, 20:49 Andrea Peri <[hidden email]> ha scritto: > ok, guardo un po' che trovo in giro. > > Grazie, > A. > > > Il giorno gio 7 feb 2019 alle ore 20:48 G. Allegri <[hidden email]> > ha scritto: > >> Come dicevo nella prima risposta, ti serve una protezione anti DDoS. Ce >> ne sono in tutte le salse e per tutte le tasche. >> >> Giovanni >> >> Il giorno gio 7 feb 2019, 20:37 Andrea Peri <[hidden email]> ha >> scritto: >> >>> Preciso meglio: >>> >>> Non sono in grado di distinguerle perche' non conosco le chiamate >>> tilizzate. Non le conosco perche' io non lavoro con i tile-servers. >>> Pero' conosco a menadito le chiamate wms e a me sembrano proprio delle >>> belle e chiare chiamate wms. >>> In questo esempio specifico su tasselli 256x256 , ma questo non >>> significa che sia un server tiled. >>> >>> resta il fatto che sono migliaia di chiamate al secondo dai medesimi >>> indirizzi. >>> >>> Ovviamente mentre il sistema ne riceve molte anche da altri utenti. >>> >>> Il mio obiettivo è discriminare queste chiamate che sono in numero >>> abnorme e scartarle, senza scartare , invece, quelle piu' normali di altri >>> utenti che panneggiano o zoomano normalmente a video o roba del genere... >>> >>> NOn avrei nulla in contario a queste chiamate serializzate se fossero >>> usate "cum grano salis", ma visto che quando partono queste bambole tutti >>> gli altri utenti ne soffrono, >>> non vedo altra soluzione che combatterle con ogni mezzo. >>> >>> Ce stato un periodo che tutti i giorni alla medesima ora partiva questa >>> bambola e per meta' mattinata e il primo pomeriggio i nostri servers wms si >>> saturavano. >>> >>> Mo' basta. >>> >>> A. >>> >>> >>> Il giorno gio 7 feb 2019 alle ore 20:28 Andrea Peri <[hidden email]> >>> ha scritto: >>> >>>> Non sono in grado di distinguere una chiamata tilizzata da una non. >>>> Ma se anche lo fosse il risultato non cambia. >>>> Se mimandano 2000 richieste al secondo il sistema impazzisce perche' la >>>> sua coda delle richieste si esaurisce prima. >>>> >>>> >>>> Il giorno gio 7 feb 2019 alle ore 20:14 G. Allegri <[hidden email]> >>>> ha scritto: >>>> >>>>> postilla alla precedente risposta. Immagino abbiate già verificato che >>>>> non si tratti di richiesta WMS tilizzate. >>>>> >>>>> Il giorno gio 7 feb 2019, 19:26 G. Allegri <[hidden email]> ha >>>>> scritto: >>>>> >>>>>> Ciao Andrea, >>>>>> vi serve una protezione anti DDoS. Ce ne sono diverse, più o meno >>>>>> sofisticate, ma la maggior parte offre schemi di difesa (rate limiting) da >>>>>> richieste come quelle che stai rilevando. >>>>>> >>>>>> Giovanni >>>>>> >>>>>> >>>>>> >>>>>> Il giorno gio 7 feb 2019, 18:53 Andrea Peri <[hidden email]> ha >>>>>> scritto: >>>>>> >>>>>>> Salve, >>>>>>> >>>>>>> inquesti ultimo periodo (ma probabilmente da tempo), >>>>>>> mi sono accorto che nei nostri wms arrivano a ondate periodiche >>>>>>> richieste >>>>>>> che ci saturano completamente isistemi. >>>>>>> >>>>>>> Parlo di richiesta a distanza di qualche millesimo di secondo . >>>>>>> Tutte dai medesimi indirizzi (piu' di uno). >>>>>>> >>>>>>> Ecco un esempio delle tempistiche che rilevo: >>>>>>> >>>>>>> "2019-01-24T17:14:12.238Z" >>>>>>> "2019-01-24T17:14:12.245Z", >>>>>>> "2019-01-24T17:14:12.256Z", >>>>>>> "2019-01-24T17:14:12.261Z" >>>>>>> "2019-01-24T17:14:12.275Z", >>>>>>> "2019-01-24T17:14:12.279Z", >>>>>>> "2019-01-24T17:14:12.292Z", >>>>>>> "2019-01-24T17:14:12.295Z", >>>>>>> "2019-01-24T17:14:12.314Z", >>>>>>> "2019-01-24T17:14:12.316Z" >>>>>>> "2019-01-24T17:14:12.332Z", >>>>>>> "2019-01-24T17:14:12.337Z", >>>>>>> "2019-01-24T17:14:12.350Z", >>>>>>> >>>>>>> Il nostro server wms non riesce a stare dietro a questa bombardata di >>>>>>> richieste. >>>>>>> E di conseguenza diventa lento e finisce per mandare a vuoto le >>>>>>> richieste >>>>>>> di utenti piu' seri che lo utilizzano per bene. >>>>>>> >>>>>>> Sarei interessato a sapere se esistono soluzioni note a questo tipo >>>>>>> di >>>>>>> problema. >>>>>>> Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha >>>>>>> trovato >>>>>>> una qualche forma di soluzione. >>>>>>> Io immaginerei una qualche soluzione tesa a limitare o addirittura >>>>>>> rifiutare le richiste a utenti che ne stanno facendo troppe in un >>>>>>> tempo >>>>>>> troppo breve. >>>>>>> >>>>>>> Tenderei a escludere soluzioni che prevedano la profilazione di >>>>>>> utenti per >>>>>>> varie ragioni anche tecniche. >>>>>>> >>>>>>> Grazie, >>>>>>> >>>>>>> -- >>>>>>> ----------------- >>>>>>> Andrea Peri >>>>>>> . . . . . . . . . >>>>>>> qwerty àèìòù >>>>>>> ----------------- >>>>>>> _______________________________________________ >>>>>>> [hidden email] >>>>>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>>>>>> Questa e' una lista di discussione pubblica aperta a tutti. >>>>>>> I messaggi di questa lista non hanno relazione diretta con le >>>>>>> posizioni dell'Associazione GFOSS.it. >>>>>>> 796 iscritti al 28/12/2017 >>>>>> >>>>>> >>>> >>>> -- >>>> ----------------- >>>> Andrea Peri >>>> . . . . . . . . . >>>> qwerty àèìòù >>>> ----------------- >>>> >>> >>> >>> -- >>> ----------------- >>> Andrea Peri >>> . . . . . . . . . >>> qwerty àèìòù >>> ----------------- >>> >> > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Grazie.
A. Il giorno gio 7 feb 2019 alle ore 20:53 G. Allegri <[hidden email]> ha scritto: > Uno sicuramente da valutare è HAProxy. Uno dei suoi più noti utenti è > GitHub. > > Giovanni > > Il giorno gio 7 feb 2019, 20:49 Andrea Peri <[hidden email]> ha > scritto: > >> ok, guardo un po' che trovo in giro. >> >> Grazie, >> A. >> >> >> Il giorno gio 7 feb 2019 alle ore 20:48 G. Allegri <[hidden email]> >> ha scritto: >> >>> Come dicevo nella prima risposta, ti serve una protezione anti DDoS. Ce >>> ne sono in tutte le salse e per tutte le tasche. >>> >>> Giovanni >>> >>> Il giorno gio 7 feb 2019, 20:37 Andrea Peri <[hidden email]> ha >>> scritto: >>> >>>> Preciso meglio: >>>> >>>> Non sono in grado di distinguerle perche' non conosco le chiamate >>>> tilizzate. Non le conosco perche' io non lavoro con i tile-servers. >>>> Pero' conosco a menadito le chiamate wms e a me sembrano proprio delle >>>> belle e chiare chiamate wms. >>>> In questo esempio specifico su tasselli 256x256 , ma questo non >>>> significa che sia un server tiled. >>>> >>>> resta il fatto che sono migliaia di chiamate al secondo dai medesimi >>>> indirizzi. >>>> >>>> Ovviamente mentre il sistema ne riceve molte anche da altri utenti. >>>> >>>> Il mio obiettivo è discriminare queste chiamate che sono in numero >>>> abnorme e scartarle, senza scartare , invece, quelle piu' normali di altri >>>> utenti che panneggiano o zoomano normalmente a video o roba del genere... >>>> >>>> NOn avrei nulla in contario a queste chiamate serializzate se fossero >>>> usate "cum grano salis", ma visto che quando partono queste bambole tutti >>>> gli altri utenti ne soffrono, >>>> non vedo altra soluzione che combatterle con ogni mezzo. >>>> >>>> Ce stato un periodo che tutti i giorni alla medesima ora partiva questa >>>> bambola e per meta' mattinata e il primo pomeriggio i nostri servers wms si >>>> saturavano. >>>> >>>> Mo' basta. >>>> >>>> A. >>>> >>>> >>>> Il giorno gio 7 feb 2019 alle ore 20:28 Andrea Peri < >>>> [hidden email]> ha scritto: >>>> >>>>> Non sono in grado di distinguere una chiamata tilizzata da una non. >>>>> Ma se anche lo fosse il risultato non cambia. >>>>> Se mimandano 2000 richieste al secondo il sistema impazzisce perche' >>>>> la sua coda delle richieste si esaurisce prima. >>>>> >>>>> >>>>> Il giorno gio 7 feb 2019 alle ore 20:14 G. Allegri <[hidden email]> >>>>> ha scritto: >>>>> >>>>>> postilla alla precedente risposta. Immagino abbiate già verificato >>>>>> che non si tratti di richiesta WMS tilizzate. >>>>>> >>>>>> Il giorno gio 7 feb 2019, 19:26 G. Allegri <[hidden email]> ha >>>>>> scritto: >>>>>> >>>>>>> Ciao Andrea, >>>>>>> vi serve una protezione anti DDoS. Ce ne sono diverse, più o meno >>>>>>> sofisticate, ma la maggior parte offre schemi di difesa (rate limiting) da >>>>>>> richieste come quelle che stai rilevando. >>>>>>> >>>>>>> Giovanni >>>>>>> >>>>>>> >>>>>>> >>>>>>> Il giorno gio 7 feb 2019, 18:53 Andrea Peri <[hidden email]> >>>>>>> ha scritto: >>>>>>> >>>>>>>> Salve, >>>>>>>> >>>>>>>> inquesti ultimo periodo (ma probabilmente da tempo), >>>>>>>> mi sono accorto che nei nostri wms arrivano a ondate periodiche >>>>>>>> richieste >>>>>>>> che ci saturano completamente isistemi. >>>>>>>> >>>>>>>> Parlo di richiesta a distanza di qualche millesimo di secondo . >>>>>>>> Tutte dai medesimi indirizzi (piu' di uno). >>>>>>>> >>>>>>>> Ecco un esempio delle tempistiche che rilevo: >>>>>>>> >>>>>>>> "2019-01-24T17:14:12.238Z" >>>>>>>> "2019-01-24T17:14:12.245Z", >>>>>>>> "2019-01-24T17:14:12.256Z", >>>>>>>> "2019-01-24T17:14:12.261Z" >>>>>>>> "2019-01-24T17:14:12.275Z", >>>>>>>> "2019-01-24T17:14:12.279Z", >>>>>>>> "2019-01-24T17:14:12.292Z", >>>>>>>> "2019-01-24T17:14:12.295Z", >>>>>>>> "2019-01-24T17:14:12.314Z", >>>>>>>> "2019-01-24T17:14:12.316Z" >>>>>>>> "2019-01-24T17:14:12.332Z", >>>>>>>> "2019-01-24T17:14:12.337Z", >>>>>>>> "2019-01-24T17:14:12.350Z", >>>>>>>> >>>>>>>> Il nostro server wms non riesce a stare dietro a questa bombardata >>>>>>>> di >>>>>>>> richieste. >>>>>>>> E di conseguenza diventa lento e finisce per mandare a vuoto le >>>>>>>> richieste >>>>>>>> di utenti piu' seri che lo utilizzano per bene. >>>>>>>> >>>>>>>> Sarei interessato a sapere se esistono soluzioni note a questo tipo >>>>>>>> di >>>>>>>> problema. >>>>>>>> Se qualcuno che gestisce wms ha avuto gia' questi problemi e se ha >>>>>>>> trovato >>>>>>>> una qualche forma di soluzione. >>>>>>>> Io immaginerei una qualche soluzione tesa a limitare o addirittura >>>>>>>> rifiutare le richiste a utenti che ne stanno facendo troppe in un >>>>>>>> tempo >>>>>>>> troppo breve. >>>>>>>> >>>>>>>> Tenderei a escludere soluzioni che prevedano la profilazione di >>>>>>>> utenti per >>>>>>>> varie ragioni anche tecniche. >>>>>>>> >>>>>>>> Grazie, >>>>>>>> >>>>>>>> -- >>>>>>>> ----------------- >>>>>>>> Andrea Peri >>>>>>>> . . . . . . . . . >>>>>>>> qwerty àèìòù >>>>>>>> ----------------- >>>>>>>> _______________________________________________ >>>>>>>> [hidden email] >>>>>>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >>>>>>>> Questa e' una lista di discussione pubblica aperta a tutti. >>>>>>>> I messaggi di questa lista non hanno relazione diretta con le >>>>>>>> posizioni dell'Associazione GFOSS.it. >>>>>>>> 796 iscritti al 28/12/2017 >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> ----------------- >>>>> Andrea Peri >>>>> . . . . . . . . . >>>>> qwerty àèìòù >>>>> ----------------- >>>>> >>>> >>>> >>>> -- >>>> ----------------- >>>> Andrea Peri >>>> . . . . . . . . . >>>> qwerty àèìòù >>>> ----------------- >>>> >>> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- >> > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
In reply to this post by Andrea Peri
Le richieste tiled sono il default in molte librerie, anche in OpenLayers.
Se visualizzi una mappa a schermo pieno, anche su uno schermo anche di media risoluzione, partono decine di richieste in parallelo. Le richieste sono tilizzate di default perché si suppone che, mediamente, i servizi abbiano davanti una cache su griglie standard. Si può opinare, ma sta di fatto che le uniche opzioni che hai sono: - bufferizzare le richieste - introdurre un rate limiting - adottare una cache Giovanni Il giorno ven 8 feb 2019, 07:22 Andrea Peri <[hidden email]> ha scritto: > Si, sono tutte a dimensioni 256x256, > > ma a parer mio il fatto che siano 256x256 non implica che sia un > tile-server. > Prendi ad esempio: > QGIS desktopse si invoca una stampa di un pdf (esportazione) gli si puo' > dire di fare a tassellini di 256x256 . > Non ha senso , lo so', ma uno puo' pensare che sia una furbata. > > Pure il nostro frmework tolomeo puo' essere impostato per invocare un > server wms a tasselli di 256x256. > > La differenza e' che QGIS quando si invia una richiesta di stampa a tsselli > 256x256 a 300 dpi, invia tutte richieste in sequenza, > ma con un intervallo di tempo tra una richiesta e la successiva che non è 1 > millisecondo. > > Il problema non è invocare tassellini di 256x256 (e' stupido, ma niente di > piu'). > > Il problema e' quando le richieste sono moltissime e a ritmi di 1 ogni > 1-2-3 millisecondi. > Allora le code di richieste si riempono e finiscono per rifiutare ogni > altra richiesta, mettendo fuori gioco altri utenti che vorrebbero > panneggiare o zoomare o interrogare. > > A. > > > Il giorno gio 7 feb 2019 alle ore 20:37 francesco marucci < > [hidden email]> ha scritto: > > > Andrea, > > le puoi riconoscere se i parametri WIDTH e HEIGHT della get hanno valori > > tipo 256 e 256 o 512 e 512, che sono i due default per le tile. > > è vero che non ti cambia nulla saperlo, ma almeno puoi distinguere le > > richieste vere dai robot. > > > > saluti, > > francesco > > > > Il giorno gio 7 feb 2019 alle ore 20:28 Andrea Peri <[hidden email] > > > > ha scritto: > > > > > Non sono in grado di distinguere una chiamata tilizzata da una non. > > > > > > > > _______________________________________________ > > [hidden email] > > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > > Questa e' una lista di discussione pubblica aperta a tutti. > > I messaggi di questa lista non hanno relazione diretta con le posizioni > > dell'Associazione GFOSS.it. > > 796 iscritti al 28/12/2017 > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
In reply to this post by Andrea Peri
On Thu, Feb 07, 2019 at 06:53:38PM +0100, Andrea Peri wrote:
> > Parlo di richiesta a distanza di qualche millesimo di secondo . > Tutte dai medesimi indirizzi (piu' di uno). Lo stesso problema capita anche ai normali server web, cioè il problema è indipendente da chi riceve la richiesta HTTP (Apache, Nginx, ecc.) e da chi produce l'output (inteprete PHP, MapServer, ecc.). Per questo motivo cercherei una soluzione indipendente dallo stack software che hai in questa specifica situazione. Cercherei quindi una soluzione a livello TCP/IP. Se il server fosse una macchina GNU/Linux ci sono semplici ricette iptables (il firewall del kernel linux) che limitano il numero di pacchetti accettati da una singola sorgente. Come parola chiave cerca "iptables hashlimit". Giusto per fare un esempio questa è una regola che uso per limitare attacchi DDoS su server DNS (porta 53 UDP): iptables -I INPUT -p udp --dport 53 -m hashlimit \ --hashlimit-name DNS --hashlimit-above "2/second" \ --hashlimit-burst "25" --hashlimit-htable-expire "60000" \ --hashlimit-mode srcip --hashlimit-srcmask 32 -j DROP -- Niccolo Rigacci - http://www.rigacci.net/ Campi Bisenzio - Firenze - Italy Tel. Mobile: +39-327-5619352 _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Grazie Niccolo.
I nostri front-end sono gestiti da personale esterno, che ne ha anche la resposabilita', ma provero' a indagare se e' possibile farmi inserire nel front-end qualcosa che faccia da limitatore come te suggerisci, oppure un prodotto come quello indicatomi da Giovanni. Prima comunque vedo di studiare meglio entrambe le soluzioni per farmi una idea utile per scegliere la soluzione piu' idonea per le nostre esigenze. A. Il giorno ven 8 feb 2019 alle ore 10:35 Niccolo Rigacci <[hidden email]> ha scritto: > On Thu, Feb 07, 2019 at 06:53:38PM +0100, Andrea Peri wrote: > > > > Parlo di richiesta a distanza di qualche millesimo di secondo . > > Tutte dai medesimi indirizzi (piu' di uno). > > Lo stesso problema capita anche ai normali server web, cioè il > problema è indipendente da chi riceve la richiesta HTTP (Apache, > Nginx, ecc.) e da chi produce l'output (inteprete PHP, MapServer, > ecc.). > > Per questo motivo cercherei una soluzione indipendente dallo > stack software che hai in questa specifica situazione. Cercherei > quindi una soluzione a livello TCP/IP. Se il server fosse una > macchina GNU/Linux ci sono semplici ricette iptables (il firewall > del kernel linux) che limitano il numero di pacchetti accettati > da una singola sorgente. > > Come parola chiave cerca "iptables hashlimit". > > Giusto per fare un esempio questa è una regola che uso per > limitare attacchi DDoS su server DNS (porta 53 UDP): > > iptables -I INPUT -p udp --dport 53 -m hashlimit \ > --hashlimit-name DNS --hashlimit-above "2/second" \ > --hashlimit-burst "25" --hashlimit-htable-expire "60000" \ > --hashlimit-mode srcip --hashlimit-srcmask 32 -j DROP > > -- > Niccolo Rigacci - http://www.rigacci.net/ > Campi Bisenzio - Firenze - Italy > Tel. Mobile: +39-327-5619352 > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Free forum by Nabble | Edit this page |