Philipp Hasenfratz: Caching

Beitrag lesen

Halihallo Alexander

Wenn du wie gesagt, alle Ressourcen misst, dann hättest du auch dann eine, wenn auch sehr ungenügende, Referenzzeit (eg. weil der Nicht-Bildlader das laden von externen .js Dateien nicht unterbinden kann)...

Doch, doch: Keine Bilder, kein Javascript, keine Cookies, keine Style Sheets (Hallo Lynx!) und schon bekomme ich nur noch die HTML-Seite.

Ja, klar. Die wahrscheinlichkeit ist aber dennoch grösser, je mehr "Unterobjekte" man erfasst. Aber der Extremfall, wie du ihn beschrieben hast, naja, da ist dann wirklich Endefeuer ;)

Aber wie ich auch schon sagte, habe ich es vorwiegend mit 0815-Usern zu tun => Cookies aktiv, JS aktiv, Bilder aktiv, Sicherheitslücken aktiv ;)

Na denn schieb' ihnen doch gleich eine Hand voll unsignierter ActiveX-Controls unter! ;-)

Au waya... Da erschiess ich mich doch lieber gleich ;-))

Aber die Kombination aus Zeit (sekundengenau), Client-IP-Adresse und einer Zufallszahl sollte einen einzelnen Surfer -- für diese Messung -- ausreichend genau identifizieren. Man kann das sicher noch weiter spinnen, z.B. den HTTP_USER_AGENT noch mit aufnehmen, oder den REMOTE_PORT (in der HTML-Seite als Parameter für das Bild). Man kann natürlich auch noch versuchen, einen eindeutigen Cookie zu setzen und den auch noch mit "verwursten".

Entscheidend ist, möglichst viele Informationen zu einem möglichst eindeutigen Key zusammenzufassen.

Und dann einen MD5 darüber legen und schon hat man einen durchaus zu gebrauchenden und nahezu uniquen Fingerprint des Clients, der auch nur 128bit gross ist :-)

Tja, wenn Du ohnehin mit CGI (oder ASP/PHP/JSP/...) arbeitest,

^^^^^^^^^^^^^^^^^^^^^^^^^^

Pfui! CGI oder PHP, ja? :-))

kannst Du ja auch noch 'ne MD5-Summe über die (pro Client) unveränderlichen HTTP-Header machen.

Das ward ja oben beschrieben oder nicht!?

Nur: Ich habe diverse Dateien (JPEGs), die identische MD5-Summen haben, trotz unterschiedlichem Inhalt. Bei manchen Daten ist das Ergebnis von MD5 wohl auf einen sehr kleinen Bereich aus den 2^128 Möglichkeiten begrenzt. Deswegen setze ich MD5 nicht mehr als ausschließliches Verfahren ein, sondern noch mindestens ein zweites Verfahren (XOR-Summe, 16bit-Summe ohne überlauf, ...).

Gut, wenn du die Eineindeutigkeit sicher stellen musst, dann wirst du das wirklich tun müssen. Aber ich glaube, dass wir in dieser Aufgabenstellung nicht auf eine 100% sichere Eineindeutigkeit angewiesen sind. Aber naja, wenn schon, denn schon ;)

Stellt sich also die Frage, ob man die Client-Daten wirklich mit MD5 auf 128 Bit eindampfen muß, wo 1 MByte Festplatte doch so billig ist. ;-)

und wenn's finanziell mal knapp wird, kann man auf &Compress::Zlib::compress ausweichen :-)
Wobei die Ratio bei derart kleinen Incore-Strings wohl negativ wird ;-)

Viele Grüsse

Philipp