Apache parallel downloaden blokkeren

[ScuL]

Hi,

Wij hebben een applicatie die gevoelig is voor misbruik en extreem veel dataverkeer genereert. Daarom mogen er maximaal 2 download streams tegelijkertijd worden geopend naar de server om iedereen een eerlijke kans te geven te downloaden. Als er meer dan 2 streams worden geopend dan krijgt de gebruiker eerst een waarschuwing en daarna een tijdelijke blokkade. Dit is ingeregeld via Cloudflare rate limits (dus niet serverside).

Sinds recente updates hebben onder andere Chrome en Opera nu download accellerators ingebouwd.
Dit betekent dat mensen onbewust soms 4 of 6 verschillende streams openen en Cloudflare ze prompt blokkeert omdat ze de limiet van 2 overschrijden. Met Firefox en Safari lijken er op het eerste oog geen problemen te zijn.

Het is voor onze applicatie nogal vervelend dat bepaalde browsers automatisch de server met zo veel tegelijktijdige verbindingen "spammen" en daarom vraag ik me af of het mogelijk is om serverside een signaal te geven aan bijv. een Chrome browser dat de site niet met parallel downloads benaderd moet worden.

Het alternatief is gebruikers vragen om zelf parallel downloaden uit te schakelen via:
chrome://flags/#enable-parallel-downloading
maar dit is omslachtig en zorgt ervoor dat de functie op andere websites niet meer werkt.

[MAX3400]

Een FAQ op je site plaatsen van 2 zinnen? Het is van de gekke dat je "elke week" je code moet gaan aanpassen omdat bepaalde browsers client-side het verzieken/veranderen.

En anders eens Googlen op "max request workers" of "maxclients"?

[ScuL]

MAX3400 schreef op zondag 18 september 2022 @ 11:36:
Een FAQ op je site plaatsen van 2 zinnen?

Haha, de site staat vol met meldingen in caps en font size 32 vet gedrukt maar de meeste mensen klikken door en lezen niet

Maar je hebt gelijk, het probleem is gecreeërd door het toepassen van IDM-achtige technieken in standaardbrowsers..

[Illusion]

Bij het KNMI ( https://developer.dataplatform.knmi.nl/get-started ) doe je een aanvraag en krijg je een url naar een .zip op een aws fileshare. Dat kan je zelf ook doen natuurlijk: niet direct hosten maar uploaden naar een fileshare dienst waar iemand het dan afhaalt.

Kan je ook gelijk een limit instellen: de volgende url wordt pas verstuurd (via email) als de vorige upload compleet is

[Voor 7% gewijzigd door Illusion op 18-09-2022 11:42]

[nachtnet]

Wat is de reden dat de server maar 2 streams aankan? En is die “extreme” hoeveelheid dataverkeer echt noodzakelijk voor de werking of is er een overload aan onnodige bits die steeds heen en weer gaan?

[Will_M]

Kun je die 'Rate Limit' in Cloudflare niet omhoog bijstellen naar '6' zónder dat je hele applicatieserver op z'n bek gaat?

[ScuL]

nachtnet schreef op zondag 18 september 2022 @ 11:41:
Wat is de reden dat de server maar 2 streams aankan? En is die “extreme” hoeveelheid dataverkeer echt noodzakelijk voor de werking of is er een overload aan onnodige bits die steeds heen en weer gaan?

Het is een round-robin selectie van 6 servers die vrijwel allemaal op 200% belasting draaien.
In een gemiddelde maand pompen we tussen de 60 en 90 TB aan data erdoor.

Will_M schreef op zondag 18 september 2022 @ 11:42:
Kun je die 'Rate Limit' in Cloudflare niet omhoog bijstellen naar '6' zónder dat je hele applicatieserver op z'n bek gaat?

Ja dat zou kunnen maar dan krijg je mensen die de boel misbruiken door ook 6 downloads tegelijk op te starten

[Voor 26% gewijzigd door ScuL op 18-09-2022 11:43]

[Jaaap]

Staat het ook default aan in Chrome of in Edge?
Dat zou echt heel vaag zijn.

Staat er Apache in je titel omdat je overweegt om het zelf te implementeren?
Dan zou je de eerste 2 connecties wel kunnen laten werken en alle volgende connecties afbreken.

[downtime]

Als Cloudflare rate limits mogelijk maakt dan zullen ze ook wel ervaring hebben met dit probleem want al hun klanten hebben er dan problemen mee. Heb je daar al eens gevraagd wat zij adviseren?

[MAX3400]

Je zou ook nog kunnen denken aan iets basaals als: voor elke gestarte download een "+1" in een tijdelijke database vastleggen. Plus natuurlijk een identifier zoals "visitor" of whatever. En dan tel je continu of een visitor in de database al 2 running / unfinished downloads heeft.

Indien ja, bij starten van 3 meteen de melding geven: fu

[ScuL]

Jaaap schreef op zondag 18 september 2022 @ 11:44:
Staat het ook default aan in Chrome of in Edge?
Dat zou echt heel vaag zijn.

Gezien de klachtenregen die we sinds de afgelopen 3 maanden krijgen neem ik aan dat het in Chrome default is ingeschakeld. Bij Opera was het sowieso al langer een probleem. Ik heb het vermoeden dat Chrome parallel downloaden misschien alleen in de alpha/beta versies standaard aan heeft staan.

Staat er Apache in je titel omdat je overweegt om het zelf te implementeren?
Dan zou je de eerste 2 connecties wel kunnen laten werken en alle volgende connecties afbreken.

Jep, maar omdat het een round-robin systeem is is het mogelijk dat 1 server de connectie accepteert en een andere server de volgende download krijgt. De servers praten onderling niet met elkaar..

[Will_M]

Al eens aan iets als een in-house Netscaler / Loadbalancer oplossing gedacht (Citrix / F5)?

Probleem wat je ervaart wordt, dankzij je interne 'Round-Robin' implementatie waarschijnlijk ook alleen maar groter als je nu zelf méér servers bij gaat plaatsen. Die '6' sessies per user uit je verhaal lijken er max. 6 te zijn omdat je ook 6 servers hebt draaien die vervolgens niets van elkaar lijken te weten.

Zaken als deze moet je niet aan de client kant op proberen te gaan lossen, over de client heb je 'niets' te zeggen (en dat moet je ook niet willen).

[Voor 90% gewijzigd door Will_M op 18-09-2022 12:14]

[ScuL]

Will_M schreef op zondag 18 september 2022 @ 11:51:
Al eens aan iets als een in-house Netscaler / Loadbalancer oplossing gedacht (Citrix / F5)?

Probleem wat je ervaart wordt, dankzij je 'Round-Robin' implementatie waarschijnlijk alleen maar groter als je nu zelf méér servers bij gaat plaatsen. Die '6' sessies per user uit je verhaal lijken er max. 6 te zijn omdat je ook 6 servers hebt draaien die vervolgens niets van elkaar lijken te weten.

De limiet is vastgesteld in Cloudflare (WAF regels). De servers weten inderdaad niet van elkaar en of een andere server al bezig is voor een bepaalde client.

Ik heb tot nu toe de volgende optie gevonden n.a.v. dit artikel van Sonicwall.

Als een "slimme" browser of download manager probeert meerdere streams tegelijk te openen dan beginnen ze niet vanaf byte 0 maar ergens halverwege.

Met deze setting die invloed heeft op de content-range
https://stackoverflow.com...on-in-http-request-header
zou het mogelijk moeten zijn om te voorkomen dat een stream ergens halverwege een bestand wordt opgestart.

Het enige nadeel daarvan is dat een download dan niet meer kan "resumen" maar alleen vanaf het begin opnieuw kan worden gestart

[Voor 4% gewijzigd door ScuL op 18-09-2022 12:17]

[OnTracK]

Zijn het statische bestanden die gedownload worden? Of worden ze door de server gegenereerd op het moment dat je een download start? Als dat laatste, waarom gebruik je niet een POST-request zodat een browser niet meerdere requests zal willen afvuren?

[ScuL]

OnTracK schreef op zondag 18 september 2022 @ 12:50:
Zijn het statische bestanden die gedownload worden?

Ja, statisch

[Mortis__Rigor]

Als het statische bestanden zijn, zou ik dat zelf niet proberen op te lossen, maar er eerder een caching server proberen tussen te zetten (zoals bv. cloudfront of cloudflare cdn). Dan wordt de backend server nog maar 1 keer belast met het doorgeven van die static content en is het nadien de caching server die dit voor zijn rekening neemt.

[Will_M]

Mortis__Rigor schreef op zondag 18 september 2022 @ 13:21:
Als het statische bestanden zijn, zou ik dat zelf niet proberen op te lossen, maar er eerder een caching server proberen tussen te zetten (zoals bv. cloudfront). Dan wordt de backend server nog maar 1 keer belast met het doorgeven van die static content en is het nadien de caching server die dit voor zijn rekening neemt.

Ik vermoed dat dat, gezien de hoeveelheid aan traffic, wel een 'beest' van een Caching Server moet gaan worden. Die 'statische content' bestaat waarschijnlijk niet uit één 'Linux Distributie' ?

[Jaaap]

90TB/maand is iets van 300 Mbit/sec
Die zouden al gemakkelijk door 1 lichte server afgehandeld kunnen worden, laat staan als je er een Cloudfront voor zet.

[Brahiewahiewa]

Jaaap schreef op zondag 18 september 2022 @ 14:26:
90TB/maand is iets van 300 Mbit/sec
Die zouden al gemakkelijk door 1 lichte server afgehandeld kunnen worden, laat staan als je er een Cloudfront voor zet.

als de clients netjes over 24 uur verdeeld zijn, wel. Als het bijv. om Nederlandse streams gaat kun je verwachten dat de piek tussen 10 uur en 16 uur plaatsvindt, of tussen 20 uur en 23 uur. In het laatste geval moet je dus gemiddeld 2,4 Gb/sec afhandelen

[Brahiewahiewa]

ScuL schreef op zondag 18 september 2022 @ 11:16:
...
Wij hebben een applicatie die gevoelig is voor misbruik en extreem veel dataverkeer genereert. Daarom mogen er maximaal 2 download streams tegelijkertijd worden geopend...

Ik vind misbruik en extreem veel dataverkeer een rare combinatie. Kun je wat meer vertellen over welke vorm van misbruik precies? Ook over dat "extreme" dataverkeer; je noemt 90 TB per maand maar zoals je aan @Jaaap's reactie kunt zien, zou dat voor 1 server eigenlijk al geen uitdaging moeten zijn. Dus waarom kunnen jouw 6 servers niet wat Jaaaps server in z'n eentje wel kan?

[MAX3400]

Jaaap schreef op zondag 18 september 2022 @ 14:26:
90TB/maand is iets van 300 Mbit/sec
Die zouden al gemakkelijk door 1 lichte server afgehandeld kunnen worden, laat staan als je er een Cloudfront voor zet.

Tja, gemiddeld. Kunst.

Andersom, als jij op je 5G-SIM bijvoorbeeld 100GB per maand krijgt, dan zit je ook niet te wachten op 40KB/s "want gemiddeld". Zoals elke download: je piekt kortstondig naar veel en daarna 2 uur niks ofzo.

En dan is "een lichte server" natuurlijk onderbemeten. En ik zeg: natuurlijk, want wat jij licht noemt, kan iemand anders zwaar noemen. Of niet eens als "server" klassificeren.

[ScuL]

MAX3400 schreef op woensdag 21 september 2022 @ 22:23:
[...]

Tja, gemiddeld. Kunst.

Andersom, als jij op je 5G-SIM bijvoorbeeld 100GB per maand krijgt, dan zit je ook niet te wachten op 40KB/s "want gemiddeld". Zoals elke download: je piekt kortstondig naar veel en daarna 2 uur niks ofzo.

Ja dat is het inderdaad. De data stroom is niet constant. Mensen downloaden meer gedurende piekuren, met name 's avonds en in het weekend. En het piekt zodra er nieuwe updates verschijnen voor een paar weken en daarna vlakt het weer af. Het gaat er met name om dat de servers de piekbelasting aan kunnen zodat iedereen een eerlijke kans krijgt om te downloaden en niet 1 hork met 10 verbindingen tegelijk de server spamt.

Brahiewahiewa schreef op woensdag 21 september 2022 @ 21:23:
[...]

Ik vind misbruik en extreem veel dataverkeer een rare combinatie. Kun je wat meer vertellen over welke vorm van misbruik precies?

Er zijn twee manieren om aan de software te komen;

Snelle methode:
Één betaalde link voor €1
(2GB in gemiddeld 5 minuten download afhankelijk van de verbinding van de downloader)

Langzame methode:
10 losse links als gesplitst bestand in delen van 250MB. De gratis optie is een mogelijkheid voor mensen die niet willen betalen maar dan vervolgens wel meer moeite willen doen. Deze optie duurt zo'n 2 uur.

Het probleem is dat als je download managers toe staat dat mensen dan alsnog de 10 bestanden tegelijkertijd kunnen downloaden binnen een korte periode en daarmee effectief de betaalde download omzeilen.

De balans is een erg fijne lijn, als we onvoldoende betaalde downloads verwerken dan zijn de kosten van het project hoger dan de inkomsten.

[Voor 3% gewijzigd door ScuL op 22-09-2022 04:39]

[OnTracK]

Maar je zei dat het statische bestanden waren? Of zit er op je server(s) nog wel een stukje software tussen die voorkomt dat je die bestanden "direct" kan bereiken?

[ScuL]

OnTracK schreef op donderdag 22 september 2022 @ 14:10:
Maar je zei dat het statische bestanden waren? Of zit er op je server(s) nog wel een stukje software tussen die voorkomt dat je die bestanden "direct" kan bereiken?

Het zijn 2 verschillende systemen. Het betaalde systeem wordt afgehandeld door AWS met een paywall. Het gratis systeem wordt afgehandeld door Apache2 servers met een PHP redirect naar de fysieke bestandslocatie.. In principe is die locatie te achterhalen en kun je die handmatig in je download manager gooien.

[Mortis__Rigor]

Als je al in het AWS ecosysteem zit, wat is de reden dat je uw eigen servers wilt gaan belasten om statische content te serven? Is het niet veel eenvoudiger om die content op een S3 bucket te zetten en alles door AWS te laten afhandelen? Zeker als je daar ook nog eens bv. cloudfront gaat voorzetten.

https://aws.amazon.com/bl...-match-made-in-the-cloud/

Ik ben er ook vrij zeker van dat als je een beetje verder zoekt hier ook perfecte oplossingen voor bestaan in combinatie met een paywall.

[ScuL]

Mortis__Rigor schreef op vrijdag 23 september 2022 @ 08:37:
Als je al in het AWS ecosysteem zit, wat is de reden dat je uw eigen servers wilt gaan belasten om statische content te serven? Is het niet veel eenvoudiger om die content op een S3 bucket te zetten en alles door AWS te laten afhandelen? Zeker als je daar ook nog eens bv. cloudfront gaat voorzetten.

https://aws.amazon.com/bl...-match-made-in-the-cloud/

Ik ben er ook vrij zeker van dat als je een beetje verder zoekt hier ook perfecte oplossingen voor bestaan in combinatie met een paywall.

De AWS host is via een externe partij, ik doe zelf nauwelijks iets met AWS.

Maar het punt is juist dat een CDN gelijk volle snelheid levert. Terwijl je op eigen servers controle daarover hebt