Interessante Zeiten

Unbezahlbar: Innerorts von jemandem mit überhöhter Geschwindigkeit überholt zu werden, der drei Sekunden später geblitzt wird.

Kürzlich blieb beim Anstecken des iPhones der erhoffte Sync aus. Stattdessen kam bei den verschiedenen Synchronisationsversuchen der unbekannte Fehler 0xe8000001 und auch mal der Fehler 0xe800006b raus. Oops? Dabei brauchte das Gerät doch so dringend eine neue Ladung und nen Abgleich – Panik!

Irgendwie hat totgoogeln auch nicht so richtig geholfen. Schließlich hat ne kleine Fußnote des Rätsels Lösung offenbart: Wenn der Ladestand des iPhones zu niedrig ist, langt der Saft nicht mehr zum Quatschen mit dem Rechner (und auch der Ladevorang wird dann nicht angestoßen).

Also Fremder: Bevor du wie ich wie doof aus der Wäsche schaust: Lad‘ das Phone erstmal mit dem Ladegerät. Das war nämlich schon alles.

Kam kürzlich ein Anruf meiner Hosterin: Ob mit meiner Website soweit alles in Ordnung sei, der Traffic würde sich in so relativ astronomischen Regionen bewegen (und in meinem „Asbach Uralt“-Tarif sei ja nun einmal nicht soviel Inklusiv-Bandbreite enthalten)?

Angeregt durch den freundlichen Hinweis suchte ich dann die gute alte Logfile-Statistik auf und staunte Bauklötze: Namentlich die beiden Baby-Einschlafhilfen „Fön“ und „Wasserhahn“ brachten es im Oktober gemeinsam auf satte 50GB Transfervolumen. Und über 8.700 Downloads. Irre.

Da sind wir doch auf die Logfile-Einträge gespannt – halt, was ist das? Der Großteil der Zugriffe auf die Dateien kommt von iPhones??

Startet da etwa jemand mit einem hochgezüchteten iPhone eine Denial of Service-Attacke auf mein Blog? Zu Hilfe!

Des Rätsels Lösung: Das iPhone kann direkt im Browser MP3-Dateien abspielen. In diesem Fall ruft das Gerät aber nicht sofort die komplette Datei ab, sondern nur das jeweils benötigte Häppchen. Das ist z.B. von Vorteil, wenn man gleich bis kurz vor das Ende der Datei skippen möchte – es muss dann nicht erst gewartet werden, bis die vorher kommenden 90% der Datei durch die dünne Funkanbindung gekleckert sind. Das Telefon fragt beim Webserver mit einem sogenannten „Range Request“ direkt nach einem bestimmten Teil der Datei. Ebenso arbeiten auch Download-Beschleuniger, welche mehrere Teile einer Datei parallel herunterladen (nicht immer sehr ressourcenfreundlich). Wird ein Range-Request vom Webserver unterstützt, schlägt sich die Antwort im Logfile vermutlich mit dem HTTP-Statuscode „206 partial content“ nieder. Im Screenshot direkt neben der Spalte mit der 206 steht die übertragene Datenmenge – du liebe Güte, das sind immer über 16MB! Die Frage ist: Ist das auch wirklich immer durch die Leitung gewandert?

Wie die Gegenprobe mit dem Servermodul mod_logio ans Licht bringt, verlässt tatsächlich nur ein Bruchteil der Datenmenge bei den iPhone-Anfragen den Server (die letzten beiden Spalten stehen für eingehenden und ausgehenden Verkehr):

Das die Logfiles derart daneben liegen können, muss einem ja erst einmal gesagt werden. Meine 50GB Traffic sehen jedenfalls auf einmal ganz schön klein aus.

Da mod_logio dem Server zusätzlichen Aufwand beschert, wird aber sicherlich kaum ein Shared Hosting-Anbieter das Modul im normalen Betrieb ständig mitlaufen lassen.

Wir lernen:

• Traue nicht den Traffic-Angaben aus den Logfiles.
• Den richtigen Traffic misst man am besten dort, wo er entsteht – im Inneren des Netzwerk-Interface.