Mal gewinnt man, mal verliert man …

Bei Google ist nun seit einiger Zeit etwas im Gange. Die Anzahl der pro Site gelisteten Seiten schwankt recht häufig, sprich es herrscht eine hohe Varianz. Interessant hierbei ist, dass es (mindestens) zwei verschiedene Klassen von Sites zu geben scheint: Wenn für die eine mehr Seiten im Index ausgewiesen werden, ist es bei der anderen Klasse gerade weniger.

Man betrachte die folgende Grafik:

Google-Ranking

Geht es bei der schwarzen und grünen Kurve nach unten, steigt's bei der blauen und lila-farbenen an.

Sicher ist sicher — zumindest von vorne

Bruce Schneier berichtet in seinem Blog über einen, der einfach über den Zaun des Flughafens von Raleigh-Durham in den USA geklettert ist und dann an Bord eines Flugzeugs gegangen ist.

Soviel also zu den Sicherheitsvorkehrungen — Ich bin wirklich beruhigt, dass Tante Erna nicht mehr ihr "Echt Kölnisch Wasser" mit ins Flugzeug nehmen kann und durch den "markanten" Geruch Kontrolle über das Flugzeug gewinnen kann. Wen stört es dann, wenn man die Bombe einfach auf einem anderen Weg ins Flugzeug bringen kann?

Mir ist klar, dass derjenige, der für Sicherheit zuständig ist, immer der Depp ist. Absolute Sicherheit gibt es nicht. Es wird immer Wege geben, Sicherheitsvorkehrungen zu umgehen. Aber man sollte insgesamt doch die Verhältnismäßigkeit wahren.

Eine neue Leitung

Seit Dienstag, 19.12.2006 lag die SNR meiner DSL-Leitung nur noch bei 3dB. Am Mittwoch war es dann soweit: Die SNR brach gänzlich ein. Sie schwankte zwischen 0dB und 1,5dB.

SNR

Die CRC-Fehler, die ich aus meinem Teledat 302 auslese, schnellten soweit in die Höhe, dass sie zunächst überhaupt nicht mehr durch cacti protokolliert werden. Erst durch ein Erhöhen der Grenzwerte wurden sie in der Grafik festgehalten:

CRC Error

Dass die Leitung wirklich eine grauenvolle Qualität hatte, sieht man auch an den Rohdaten, die das Modem liefert. Zum Teil lag die über 15 Minuten gemittelte SNR bei 0dB!

DSL Stats

Interessant ist in diesem Zusammenhang, dass die DSL-Verbindung — wie man auch aus dem System-Log des Teledat 302 erkennen kann — mehrfach abbrach.Teilweise hielt sie keine 10 Minuten.

DSL-System-Log

Die pppoe-Verbindung hingegen brach nicht ganz so oft ab! Da sie es aber trotzdem mehrfach an diesem Tag tat, habe ich eine Störungsmeldung abgesetzt und das ganze Dilemma beschrieben. Am nächsten Tag rief der T-Com-Techniker an. Er schaltete mich auf eine andere Leitung. Seit dem schwankt die SNR zwischen 8dB und 10 dB. Ich nutzte gleich die Gelegenheit, ihn zu fragen, was den die Ursache für die Verschlechterung der Leitungsqualität sein kann. Er meinte, dass wohl im letzten halben Jahr immer mehr DSL-Anschlüsse hinzugekommen seien, die sich dann gegenseitig beeinflussen würden.

Es bleibt nur zu hoffen, dass die T-Com es nicht versäumt, rechtzeitig an einen Ausbau der Leitungskapazität zu denken. Vorallem vor dem Hintergrund des Vorantreibens der VoIP-Angbote graut mir aber. Nach einem halben Jahr war mein DSL-Anschluss wieder drastisch gestört. Die Telefonleitungen, die ich bisher genutzt habe, zeigten eine deutlich höhere Stabilität. Wie sieht dies aus, wenn man nur noch VoIP nutzt und einen Notruf absetzen muss, der DSL-Anschluss aber tot ist? "Man wollte noch den Notarzt rufen, doch die Leitung war tot" sieht gar nicht gut auf einem Grabstein aus.

Ein geändertes Routing bringt einen übebrraschenden Erfolg

Mit einem Schlag war die Erreichbarkeit meines vServers gegeben.

Paketverluste

Erstaunlicherweise hat sich aber nicht das Routing bei der DTAG geändert, sondern der nächste Hop:

Bis 21:20 Uhr sah der Paketverlauf so aus:

firewall:/root # ./mtr -rc 1000 www.jerrywho.de
HOST: firewall.mst Loss% Snt Last Avg Best Wrst StDev
1. ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
2. 217.0.66.2 0.0% 1000 7.2 7.2 6.5 26.6 1.3
3. l-eb1.L.DE.net.DTAG.DE 0.0% 1000 13.3 13.9 12.8 84.1 4.5
4. 62.156.139.98 2.1% 1000 15.6 15.2 14.4 66.3 2.1
5. kpn.dhk.nbg.v-bone.net 2.0% 1000 15.4 15.8 14.7 108.5 4.7
6. AS33956.RS8600.v-bone.net 1.1% 1000 15.8 16.0 14.8 119.3 5.2
7. AS33956.RS8000.v-bone.net 1.2% 1000 15.4 16.2 14.9 162.0 6.2
8. m15s09.vlinux.de 2.6% 1000 15.2 15.7 14.7 84.2 3.6

 

bzw. als IP-Adressen

HOST: firewall.mst				   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2. 217.0.66.2 0.0% 10 7.0 7.2 7.0 7.6 0.2
3. 62.154.89.102 0.0% 10 14.0 14.1 13.5 14.3 0.2
4. 62.156.139.98 0.0% 10 15.3 15.1 14.8 15.4 0.2
5. 134.222.107.34 10.0% 10 16.4 16.7 16.4 17.6 0.4
6. 80.244.255.234 0.0% 10 15.7 15.6 15.2 16.4 0.3
7. 80.244.255.242 0.0% 10 15.3 15.8 15.1 16.3 0.4
8. 83.151.28.203 0.0% 10 15.7 15.5 15.2 15.8 0.3

Und nun sieht er so aus:

firewall:/root # ./mtr -rc 10 www.jerrywho.de
HOST: firewall.mst Loss% Snt Last Avg Best Wrst StDev
1. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2. 217.0.66.2 0.0% 10 7.8 7.1 6.5 7.8 0.4
3. l-eb1.L.DE.net.DTAG.DE 0.0% 10 13.6 13.5 13.0 13.9 0.3
4. 62.156.139.98 0.0% 10 14.6 15.0 14.6 15.3 0.3
5. cbb.dhk.nbg.v-bone.net 0.0% 10 15.5 15.2 14.6 16.4 0.6
6. AS33956.RS8600.v-bone.net 0.0% 10 14.6 14.9 14.4 15.5 0.4
7. AS33956.RS8000.v-bone.net 0.0% 10 14.7 15.2 14.6 15.8 0.4
8. m15s09.vlinux.de 0.0% 10 15.1 14.9 14.4 15.7 0.4

bzw. als IP-Adressen

HOST: firewall.mst                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2. 217.0.66.2 0.0% 10 7.2 7.3 6.8 7.5 0.2
3. 62.154.89.102 0.0% 10 13.2 13.3 13.0 13.5 0.2
4. 62.156.139.98 0.0% 10 14.8 15.2 14.8 16.8 0.6
5. 81.95.15.30 0.0% 10 15.6 15.2 14.5 16.2 0.5
6. 80.244.255.234 0.0% 10 15.0 14.9 14.5 15.3 0.3
7. 80.244.255.242 0.0% 10 14.7 15.0 14.7 15.8 0.4
8. 83.151.28.203 0.0% 10 14.8 14.8 14.4 15.4 0.3

Statt über kpn.dhk.nbg.v-bone.net läuft es nun also über cbb.dhk.nbg.v-bone.net.

Schaut man sich die Ping-Zeiten in der Rückrichtung an, so sieht man auch hier eine deutliche Änderung:

Retour

 

Es scheint also wohl doch eher ein Problem bei kpn gewesen zu sein, denn über die Core-Backbone GmbH läuft es ja deutlich besser.

 

 

Und wieder die Erreichbarkeit ….

Man hätte ja fast die Uhr nach stellen können: In der letzten Zeit waren die Paketverluste zu meinem vServer so gut wie nicht vorhanden. Aber kaum naht die Zeit, in der ich wieder etwas mehr Zeit habe, sieht es wieder richtig mau aus:

Paketverluste

Und wieder scheint der letzte Telekom-Hop 62.156.139.98 der Übeltäter zu sein. Es ist schon frustrierend, immer wieder mit den gleichen Problemen kämpfen zu müssen. Keinen interessiert es bei der T-Com, dass sie dort vermutlich ein Problem haben. vollmar.net könnte zwar etwas dagegen tun, indem sie umrouten. Dadurch handeln sie sich aber andere Probleme ein. Also ziehe ich wieder den Kürzeren.

Firebug: Eine sehr praktische Firefox-Erweiterung

Die Tage stolperte ich über Firebug, zu haben unter http://getfirebug.com/. Damit kann man sehr schön den HTML-Code einer Seite analysieren, sehen welche Style-Eigenschaften ein Element hat und, was ich besonders praktisch finde, auch erkennen, welche Eigenschaft es von welchem Eltern-Element geerbt hat. Man kann auch die Seite bearbeiten. Man muss also nicht erst den tatsächlichen Quellcode verändern, auf den Webserver spielen und dann die Seite neu laden, um die Auswirkungen zu sehen.

Desweiteren kann man sie die HTTP-Header des Requests genau anschauen. Bis jetzt habe ich dafür immer auf die Schnelle zu Wireshark (dem ehemaligen Ethereal) gegriffen, da ich die anderen Firefox-Erweiterungen dazu zu unhandlich fand.

Es gibt aber auch etwas Negatives zu berichten. Seit ich Firebug installiert habe, stürzt der Firefox bei mir häufiger ab. Ob da aber ein kausaler Zusammenhang besteht, vermag ich noch nicht zu sagen. Anschauen sollte man sich dieses Tool aber auf jeden Fall.

Stefan Esser schmeißt das Handtuch

Bemerkenswert fand ich die Meldung der letzten Woche, dass Stefan Esser, die PHP-Security Gruppe verlässt. Er beklagt, dass er keinen Sinn mehr darin sieht, PHP von innen heraus sicher machen zu wollen. Ihm würde immer vorgeworfen werden, er sei ein Verräter, wenn er die Sicherheit von PHP an sich kritisiert. Zu häufig wären alte Lücken wieder aufgetaucht, liest man an anderer Stelle. Er wolle nun auf Bugs aufmerksam machen, auch wenn es noch keinen Fix gebe.

Er hatte in den letzten Jahren diverse Fehler gefunden, die in der Regel dazu führten, dass man sein PHP aktualisieren musste. In der Tat ist PHP zur Zeit in meinen Augen weit von einer stabilen Plattform entfernt. Zu viel ist dort zur Zeit in der Entwicklung. Vergleicht man PHP mit Apache, sieht man, was ich meine. Wie oft musste man den Apache 1.3.X aktualisieren? Die Bugs, die dort gefunden wurden, betrafen nur spezielle Module. Setzt man diese nicht an, hat man ein ruhiges Leben. Bemerkenswert dabei ist auch, dass schon die übernächste stabile Version im Umlauf ist (neben Apache 2.0 nun auch Apache 2.2) und es immer noch Bugfixes für den Apache 1.3 gibt. Leider habe ich bei netcraft.com keine aufgeschlüsselten Statistiken nach Apache-Versionen gefunden. Die Verbreitung des 1.3er Zweiges dürfte natürlich auch daher kommen, dass einzelne Module wie z.B. mod_perl nicht so schnell an den aktuellen Apache-Zweig angepasst werden.

Es tut sich wieder was im Staate „SEOdistan“

Nachdem es die letzten Wochen sehr ruhig war, was die Anzahl der gelisteten Seiten, so kommt doch nun wieder Leben in die Entwicklung. Wie die Grafik zeigt, stürzte zunächst der Wert von Yahoo drastisch ab. Aber auch der Wert bei Google zeigt im Moment eine hohe Veränderlichkeit in kurzen Zeiträumen.

SEO

Dieses Verhalten betrifft aber nicht nur diese Site hier, wie die Grafik eines anderen großen Online-Angebotes zeigt:

SEO

Hier hat sich der Absturz bei Yahoo aber bereits vorher angedeutet:

SEO

Für Verschwörungstheoretiker: Es stellt sich die Frage, ob Yahoo es übel nimmt, wenn es im Header die Google-Tags entdeckt ….

Zu viel DSL in meiner Straße …

Nachdem die SNR in den letzten beiden Wochen regelmäßig nachmittags auf sehr geringe Werte zurückfiel, habe ich am Mittwoch Abend eine Meldung bei der T-Com aufgemacht und die Entwicklung beschrieben und auch auf meine Furcht vor erneuten Ausfällen, wie sie im Frühjahr auftraten, dargelegt. Auch protokolliere ich die durch mein DSL-Modem Teledat 302 gemeldeten Übertragungsfehler (TxCRC und RxCRC) nun mit. Man erkennt dort leicht einen Zusammenhang zur SNR:

DSL-SNR

CRC-Error

Wie eigentlich zu erwarten war, trat der obligatorische Rückfall am Donnerstag natürlich auch erst abends um 20:00 Uhr auf. Am Freitag nachmittag erhielt ich dann einen Anruf des T-Com Technikers. Und auch am Freitag kam der Abfall der SNR erst später…. Murphy lässt grüßen.

Der Techniker sagte mir, er hätte meinen Anschluss kurzfristig auf eine andere Ader umgestellt. Dort hätte der Rauschabstand aber nur bei 5-6dB gelegen. Daher hat er den Anschluss wieder auf die alte Ader umgestellt. Er meinte, es gäbe ja keine Ader ohne DSL mehr in der Straße…

Auch sei "meine" Ader extra geerdert worden. Das mache man eigentlich sonst nicht. Na gut, warten wir mal ab, ob die Leitung stabil bleibt.