Vielmehr gehe ich davon aus, dass hier die Filterung durch Router / Providerhardware gemeint ist, die dadurch viel stärker belastet werden würde. HTTP ist ja Anwendungsschicht, also müsste die URL in jedem HTTP-Get-Request (und vermutlich vielen anderen HTTP-Anfragen, kenne mich da nicht aus) mit der Blacklist verglichen werden. Da man sehr viele HTTP-Connections / Webseite aufbaut, kann das schon recht arg die Performance beeinflussen, da so Hardware ja ehh meist “am Limit” läuft. Und dann wirds eben für alle langsamer.

Filterung nur auf DNS- oder IP-Ebene funktioniert ja nicht, wie wir alle wissen.

Sollte ich hier Mist schreiben, vertraue ich jetzt mal darauf das mich jemand korrigiert :)

Da wir nun konkret bei einer DNS-Sperrliste angelangt sind: Die Abzufragen dauert 1. nicht lange (und zwar wirklich und 2. wird der Client-Rechner hoffentlich nicht so bloed sein, fuer jeden einzelnen Request eines Objekts auf einer Seite seine DNS-Daten zu updaten.

Ich glaube der Herr hat sich nicht nur falsch ausgedrueckt – es scheint mir auch so, als ob sein Wissen in diesem Bereich beschraenkt ist…

Es ist ja im Endeffekt so: Der Herr Rotert sagt ja, dass bei vielen Filtereintraegen die Datenuebertragungsgeschwindigkeit nachlaesst – das ist so definitiv falsch, da man ja ueber das Netz mehr als nur HTTP uebertraegt. Und selbst wenn: Es waere abhaengig von der Seite, wie stark die Verbindung zusammenbricht. Und gerade bei Uebertragungslastigen Dingen wie grossen Bildern / Downloads duerfte die Filterliste eine vernachlaessigbare Rollte spielen.

Gehen wir nun mal davon aus, dass sich Herr Rotert nur auf HTTP-Anfragen beschraenkt. Dann wird von der Sperrliste jede URL in einer HTTP-Anfrage auf eine Sperrung ueberprueft. Das ist maximal eine pro Anfrage, aber es koennen natuerlich je nach Website mehrere Anfragen pro Webseitenaufruf geschehen (was eigentlich ziemlich wahrscheinlich ist).

Sagen wir mal Ein Zugriff auf eine ueberladene Website triggert ~100 weitere HTTP-Anfragen und die Sperrliste hat 5000 Eintraege. Das heisst – bei naiver Implementation der Liste sind das 500000 Zeichenkettenvergleiche fuer einen Webseitenaufruf. Jeder Zeichekettenvergleich wird so ca. hinter dem 10. Zeichen abbrechen, da es keinen match gibt – das heisst wir fuehren etwa 5’000’000 Operationen aus. Nehmen wir datenuebertragung zwischen RAM und CPU dazu sind es insgesamt vllt 50’0000’000 CPU-Zyklen. Okay, so eine CPU schafft heutzutage allerdings schonmal 5’000’000’000 Zyklen pro Sekunde, das heisst, mit genug Rechenleistung dauert eine Anfrage 10 ms laenger. (Man bedenke: Wenn es NAIV implementiert ist!)

So jemand, der so eine Filtersoftware implementiert, wird allerdings (hoffentlich!) nicht auf die Idee kommen tatsaechlich den URL mit jedem Eintrag in der Zeichenkette zu vergleichen, sondern mit einem B(*)-Baum oder aehnlichem arbeiten. Dann braucht man zum Vergleich einer URL vllt noch 100 Operationen, bei 100 URLs pro Seite sind das dann 10’000 Operationen. Eine Latenzzeit ist hier kaum noch feststellbar.

So… wie siehts aus? Die Rechnungen sind sicher nicht fehlerfrei, aber ich denke, die Dimensionen kommen einigermassen hin. Eine wirkliche begrenzung der Bandbreite sehe ich hier grade mal nicht.

Gruesse

Marvin

Dennoch ein nettes Interview und auch für weniger technikversierte Menschen einleuchtend erklärt.