Ongeveer een dag

Als we geluk hebben: er is geen beperking, we kunnen elke test uitvoeren met een HEAD-verzoek, kunnen veel tests uitvoeren op een enkele HTTP-verbinding met Keepalive, en kan veel gelijktijdige verbindingen hebben.

In dat geval zijn we meestal beperkt door bandbreedte. Stel dat we een strak verzoek maken van 100 bytes, dat betekent dat we in totaal 100 * 10 ¹⁰ bytes moeten verzenden. En laten we veronderstellen dat we een fatsoenlijke 100 Mbps-verbinding hebben, wat ongeveer 10 megabytes per seconde zal doen. Dat zou 100.000 seconden duren - iets meer dan een dag.

Dit is het beste, in de praktijk zijn er waarschijnlijk problemen waardoor het niet zo snel werkt. We zouden meerdere systemen tegelijk kunnen laten werken om het sneller te maken, maar op een gegeven moment zullen we de server overbelasten.

Het rollen van een 10-cijferig nummer duurt op de meeste systemen niet lang, ongeacht het gebruikte script / de taal. Het grotere probleem hier is het aantal verbindingen dat u tegelijkertijd opent en de vertraging tussen verzoeken. Een goed geconfigureerd systeem blokkeert te veel verzoeken die afkomstig zijn van hetzelfde adres (ofwel door de firewall of door de daemon zelf).

Bijvoorbeeld:

  #! / Bin / bashfor i in {1..1000} do curl "www. [ergens anders] .com / $ i" > "$ {i} _out.txt" gedaan  

Misschien wilt u draad dit.

Hangt af van verschillende factoren.

Serverzijde

• Serverbandbreedte
• Genereert dit gevraagde nummer een zoekopdracht naar een database?
• Een firewall / beveiligingsscript om dit soort activiteit te detecteren en te blokkeren
• Alle andere bronnen die een bottleneck kunnen zijn, zoals cpu of geheugen.
• Als jij dat bent soort gelukkige mensen die het zullen proberen op een server waarvan de logboeken worden opgeslagen op een zeer beperkt bestandssysteem, en dit soort activiteit verbruikt elke vrije byte ervan waardoor de toepassing stopt.

Clientzijde

• Uw bandbreedte

Mijn overwegingen met betrekking tot deze activiteit:

Voer eerst een DNS-query uit en kijk of er meer dan een server voor dat adres. Dat zal helpen, meer server, meer je kunt de belasting splitsen.

Test de firewall, neem een ​​VPS en doe wat tests om een ​​idee van je omgeving te krijgen zonder je ip-adres op de zwarte lijst te zetten. Test enkele snelheden, 100, 1000, 10000, per seconde. Test de gemiddelde reactietijd voor elk uur van de dag. Als de reactietijden veranderen, heeft uw server een aantal tijdvensters die meer verkeer / verzoeken ontvangen en dat is een goed moment om de server niet te belasten.

Met alle bovenstaande resultaten weet u wat u moet doen. Als de server meer bandbreedte heeft dan jij, wat er bijna altijd gebeurt, kun je een VPS krijgen om je te helpen, kies er een in de buurt van de server. U heeft uw plan over hoeveel verzoeken optimaal zullen zijn om uw oplossing te archiveren. Als de servers bijvoorbeeld 's ochtends meer belasting krijgen, kunt u 1000 / s gedurende de dag gebruiken, bijvoorbeeld van 8:00 tot 22:00 uur, en zoveel mogelijk de servers kunnen tussen 22.00 uur en 8.00 uur antwoorden.

Houd er rekening mee dat dit soort activiteiten ertoe kan leiden dat sommige services crashen of zo zwaar worden belast dat het de gebruikers niet kan beantwoorden en dat dit kan worden beschouwd als een Denial Of Service-aanval. Het kan je in de problemen brengen vanwege verschillende factoren, ik weet niet van alle landen, in verschillende landen is dit soort aanvallen een misdaad. Neem contact op met de systeembeheerder over uw bedoelingen voordat u een systeem laat crashen en verantwoordelijk wordt voor uitval.

Een dag is enorm onrealistisch , ongeacht de middelen.

Er zijn 86.400 seconden in een dag. Rond af naar 100k. Verdeel 1B door 100k en je krijgt 10.000 zoekopdrachten per seconde. Dit is wat groot. De server heeft een behoorlijk verhaal over de taakverdeling en een behoorlijke hoeveelheid computercapaciteit nodig. Ter referentie: als we 100 machines hebben met elk 8 cores (voor een totaal van 800 cores), moeten we elk verzoek binnen maximaal 80 ms omdraaien, wat krap is, maar niet volkomen onredelijk. De client heeft ook capaciteit nodig die evenredig is met die van de server, en aangenomen dat je een black hat-aanvaller bent, gebruik je waarschijnlijk een botnet of iets dergelijks.

Eigenlijk moet je een botnet, omdat de client zo geografisch moet worden verspreid dat de server het kan balanceren zonder netwerkverbindingen met hoge latentie te passeren. Dit is cruciaal omdat de latentie tussen server en client meetelt voor ons 80 ms-budget. Als de klant zich volledig in Amerika bevindt, maar de helft van de server in Europa, zal de transatlantische latentie onze prestaties volledig verpesten en zullen we aanzienlijk meer capaciteit nodig hebben om dit goed te maken (anders zullen we gewoon alle verzoeken moeten afhandelen met de Amerikaanse helft van de server, die vergelijkbare capaciteitsproblemen tegenkomt).

Maar wacht! U zei 'ongeacht de middelen'. Waarom gooi je resourcenummers naar me?

Omdat de mensen die webservices op deze schaal exploiteren over het algemeen goed genoeg toezicht hebben om een ​​plotselinge stroom van 10k QPS-verkeer van een botnet te detecteren. Naar alle waarschijnlijkheid zal uw doelwit bepalen dat u DDoS-aanvallen op hen uitvoert (wat eigenlijk is wat u doet) en standaardbeperkende maatregelen implementeren (bijv. 503s of CAPTCHA's bedienen, het verkeer op een zwarte holte, etc.). Op dit punt zal je aanval mislukken of in ieder geval veel langer duren dan je had gepland, en de autoriteiten zullen nu werken om je botnet te ontmantelen.

Dus als je wilt dat je aanval echt werkt, kun je dat niet doe het met deze snelheid. Of je doelwit kan het verkeer niet aan, of ze zijn slim genoeg om het te detecteren en te blokkeren.