Seite von http auf https umleiten? Sinnvoll oder nicht?

[oxo888oxo]

Hallo

Seitens meines Webhosters (1&1) ist meine Website mit wwww und ohne www erreichbar. Mit einer htaccess-Datei habe ich es so eingerichtet, dass man grundsätzlich immer auf die Variante ohne www geleitet wird.

Nun ist meine Seite auch unter http und https erreichbar. Es handelt sich bei meiner Seite um einen Online-Shop. Aktuell habe ich es so eingerichtet, dass der Bestellprozess immer per https aufgerufen wird.

Nun hat Google ja kürzlich angefangen, die https-Erreichbarkeit auch in die Ranking-Faktoren aufzunehmen. Darum überlege ich nun, ob ich meine komplette Seite auf https umstellen sollte.

Wie denkt Ihr darüber? Gerade auch im Bezog auf Google-Ranking? Oder gibt es auch Dinge, die wirklich dagegen sprechen?

Gruß Otto

[NSA]

Hallo Du,

Seitens meines Webhosters (1&1) ist meine Website mit www und ohne www erreichbar. Mit einer htaccess-Datei habe ich es so eingerichtet, dass man grundsätzlich immer auf die Variante ohne www geleitet wird.

Nun ist meine Seite auch unter http und https erreichbar. Es handelt sich bei meiner Seite um einen Online-Shop. Aktuell habe ich es so eingerichtet, dass der Bestellprozess immer per https aufgerufen wird.

Nun hat Google ja kürzlich angefangen, die https-Erreichbarkeit auch in die Ranking-Faktoren aufzunehmen. Darum überlege ich nun, ob ich meine komplette Seite auf https umstellen sollte.

Wenn die Applikation individuelle Benutzereingaben, speziell Konto- und Zugangsdaten entgegen nimmt, sollte man sie keinesfalls mehr im Klartext ohne Security betreiben. Wenn Du also schon ein Zertifikat zur Verfügung hast, dann benutze es auch!

LG Chinese

[oxo888oxo]

Wenn die Applikation individuelle Benutzereingaben, speziell Konto- und Zugangsdaten entgegen nimmt, sollte man sie keinesfalls mehr im Klartext ohne Security betreiben. Wenn Du also schon ein Zertifikat zur Verfügung hast, dann benutze es auch!

Ich hatte ja geschrieben, dass es sich um einen Online-Shop handelt. Somit nimmt die Applikation individuelle Benutzereingaben entgegen, wenn ein Kunde etwas bestellt.

Verstehe ich Dich jetzt richtig? Du würdest mir raten, die komplette Site nur verschlüsselt anzubieten?

[Gangsters]

Hi,

Wenn die Applikation individuelle Benutzereingaben, speziell Konto- und Zugangsdaten entgegen nimmt, sollte man sie keinesfalls mehr im Klartext ohne Security betreiben. Wenn Du also schon ein Zertifikat zur Verfügung hast, dann benutze es auch!

Ich hatte ja geschrieben, dass es sich um einen Online-Shop handelt. Somit nimmt die Applikation individuelle Benutzereingaben entgegen, wenn ein Kunde etwas bestellt.

Verstehe ich Dich jetzt richtig? Du würdest mir raten, die komplette Site nur verschlüsselt anzubieten?

Zumindest den Shop, ab der Stelle, ab der der Kunde etwas bestellen kann. Das ist also die Stelle, an der ein Token (Session-ID) vergeben wird für die Wiedererkennung und Zuordnung des Warenkorbes zu den Kundendaten.

Bei allen "nur betrachten"-Seiten würde ich das nicht unbedingt so kritisch sehen, wenn da keine Verbindung zum Real-Menschen hergestellt werden kann, also das berühmte Tracking (hier aber ohne dein Mittun).

Die Gangsters

[Jörg Reinholz]

Moin!

Bei allen "nur betrachten"-Seiten würde ich das nicht unbedingt so kritisch sehen, wenn da keine Verbindung zum Real-Menschen hergestellt werden kann, also das berühmte Tracking (hier aber ohne dein Mittun).

Stellt sich die Frage, was es den NSA angeht, welche Produkte ich mir ansehe. Oder erstellen die dann solche Webseiten wie,

"Wer sich nach Wasserstoffperoxid umgesehen hat, der hat sich davor oder danach auch Angebote mit Kühlschränken, Aceton, Salzsäure, Schwefelsäure oder Phosphorsäure angesehen und bei Wikipedia über Acetonperoxid nachgelesen."

Jörg Reinholz

P.S. Ja. Schitt! Genau das machen die. Nur sind diese Seiten nicht öffentlich abrufbar. Jedenfalls nicht so lange Snowden nicht deren Adresse veröffentlicht.

[woodfighter]

Tach,

Nun ist meine Seite auch unter http und https erreichbar. Es handelt sich bei meiner Seite um einen Online-Shop. Aktuell habe ich es so eingerichtet, dass der Bestellprozess immer per https aufgerufen wird.

d.h. also ein Angreifer kann auf die eingegebenen Kundendaten zugreifen, indem er die unverschlüsselte Verbindung ablauscht, sich das Session-Token aus der URL oder dem Cookie holt und dann auf die Seesion zugreift, nachdem der Kunde seine Daten eingegeben hat?

Nun hat Google ja kürzlich angefangen, die https-Erreichbarkeit auch in die Ranking-Faktoren aufzunehmen. Darum überlege ich nun, ob ich meine komplette Seite auf https umstellen sollte.

Wie denkt Ihr darüber?

Außer dem oben genannten potentiellen Angriff, ist es allgemein eine gute Idee; Zertifikate sind ab kostenlos zu haben, Webserver-CPUs drehen eh im wesentlichen Däumchen und wir haben inzwischen sogar Beweise dafür, dass ohne Verschlüsselung Angreifer auf die Verbindungen zugreifen.

mfg
Woodfighter

[oxo888oxo]

Nun ist meine Seite auch unter http und https erreichbar. Es handelt sich bei meiner Seite um einen Online-Shop. Aktuell habe ich es so eingerichtet, dass der Bestellprozess immer per https aufgerufen wird.

d.h. also ein Angreifer kann auf die eingegebenen Kundendaten zugreifen, indem er die unverschlüsselte Verbindung ablauscht, sich das Session-Token aus der URL oder dem Cookie holt und dann auf die Seesion zugreift, nachdem der Kunde seine Daten eingegeben hat?

Das würde ja dann bedeuten, dass bei 99,9% aller Online-Shops im Internet solch ein Angriff möglich ist. Ich kenne eigentlich so gut wie gar keinen Online-Shop, bei dem man grundsätzlich auf https geleitet wird. Selbst bei Amazon und Ebay ist das doch nicht der Fall.

Oder habe ich Dich da jetzt irgendwie falsch verstanden?

[woodfighter]

Tach,

Das würde ja dann bedeuten, dass bei 99,9% aller Online-Shops im Internet solch ein Angriff möglich ist. Ich kenne eigentlich so gut wie gar keinen Online-Shop, bei dem man grundsätzlich auf https geleitet wird. Selbst bei Amazon und Ebay ist das doch nicht der Fall.

Oder habe ich Dich da jetzt irgendwie falsch verstanden?

nö, ist ein üblicher Implementierungsfehler; Amazon macht da noch ein bisschen Magie im Hintergrund, um das zu verhindern (im wesentlichen Wiedererkennung über mehr als nur das Session-Token) und fordert dann leiber nochmal das User-PW an.

mfg
Woodfighter

[CIA]

Nun hat Google ja kürzlich angefangen, die https-Erreichbarkeit auch in die Ranking-Faktoren aufzunehmen. Darum überlege ich nun, ob ich meine komplette Seite auf https umstellen sollte.

Wie denkt Ihr darüber?

Du hast für das Zertifikat bezahlt, also darfst du es auch benutzen.

Nur für einen kleinen Teilbereich Verschlüsselung anzubieten, ist Quatsch, Parallelbetrieb von http und https über das gesamte Angebot sollte das Mindeste sein. Ob man die Verschlüsselung obligatorisch macht, d.h. strikt alle Anfragen an http auf https umzuleiten, hängt von Serverfähigkeiten und Zielgruppe ab, siehe unten.

Gerade auch im Bezog auf Google-Ranking?

Falls deine Seite wegen der Verschlüsselung merklich besser bewertet würde, hättest du noch ganz andere Probleme als die Verschlüsselung.

Google bewertet immer noch so, dass für den Suchenden eine brauchbare Ergebnisliste rauskommt. Verschlüsselung ist in dieser Hinsicht ungefähr so wichtig wie die Vorliebe des Seitenbetreibers für Schokoladeneis.

Du solltest nicht jedem Pups, der im SEO-Wald ertönt, Beachtung schenken. Die Verschlüsselungsnummer von Google ist zu einem Großteil politisch zu sehen. "Die Regierung" hat Google ans Bein gepinkelt, sie hat auch Googles Nutzern ans Bein gepinkelt, Google befürchtet das Ausbleiben von Nutzern, was einen Knick bei den Werbeumsätzen zur Folge hätte, und wenn Google eins noch mehr liebt als Amerika, dann Geld, also: Google pinkelt zurück. So in etwa.

Oder gibt es auch Dinge, die wirklich dagegen sprechen?

Der IE 6 vielleicht. Android 2 eventuell noch eher, denn das kann über verschlüsselte Verbindungen keine Server auswählen, sondern nimmt was immer 1&1 unter der deiner Seite zugeordneten IP als erstes konfiguriert hat.

Du hast https://www.ssllabs.com/ssltest/ über deine Seite laufen lassen?

[oxo888oxo]

Nur für einen kleinen Teilbereich Verschlüsselung anzubieten, ist Quatsch, Parallelbetrieb von http und https über das gesamte Angebot sollte das Mindeste sein.

Das würde dann doch bedeuten, auch der Bestellprozess mit Dateneingabe usw. sollte man parallel per http und https anbieten? Das kann ich ja fast nicht glauben. Da habe ich Dich doch bestimmt falsch verstanden, oder? Bitte kläre mich auf.

Du hast https://www.ssllabs.com/ssltest/ über deine Seite laufen lassen?

Ja das habe ich gemacht. Da meine Fachkenntnisse und auch mein Englisch nicht so gut ist, kann ich mit dem sehr umfangreichen Ergebnis nicht so richtig viel anfangen. Könnte mir da evtl. jemand behilflich sein?

[Auge]

Hallo

Nur für einen kleinen Teilbereich Verschlüsselung anzubieten, ist Quatsch, Parallelbetrieb von http und https über das gesamte Angebot sollte das Mindeste sein.

Das würde dann doch bedeuten, auch der Bestellprozess mit Dateneingabe usw. sollte man parallel per http und https anbieten? Das kann ich ja fast nicht glauben. Da habe ich Dich doch bestimmt falsch verstanden, oder? Bitte kläre mich auf.

Biete den Parallelbetreib über alle deine Angebote an, statt nur über die Seiten des Bestellprozesses. Für den Bestellprozess behalte aber den Pflichtbetrieb von HTTPS.

Tschö, Auge

[oxo888oxo]

Hallo Auge

Biete den Parallelbetreib über alle deine Angebote an, statt nur über die Seiten des Bestellprozesses. Für den Bestellprozess behalte aber den Pflichtbetrieb von HTTPS.

Spricht denn Deiner Meinung nach etwas dagegen, die ganze Seite komplett auf Pflichtbetrieb von HTTPS umzustellen?

[Auge]

Hallo

Biete den Parallelbetreib über alle deine Angebote an, statt nur über die Seiten des Bestellprozesses. Für den Bestellprozess behalte aber den Pflichtbetrieb von HTTPS.

Spricht denn Deiner Meinung nach etwas dagegen, die ganze Seite komplett auf Pflichtbetrieb von HTTPS umzustellen?

Wenn die Weiterleitung von HTTP-Aufrufen sauber funktioniert, also kein Aufruf im Nirwana landet, spricht meiner Meinung nach nichts gegen den „Pflichtbetrieb“ von HTTPS.

Tschö, Auge

[CIA]

Nur für einen kleinen Teilbereich Verschlüsselung anzubieten, ist Quatsch, Parallelbetrieb von http und https über das gesamte Angebot sollte das Mindeste sein.

Das würde dann doch bedeuten, auch der Bestellprozess mit Dateneingabe usw. sollte man parallel per http und https anbieten?

Das hast du falsch verstanden. Verschlüsselung ist grundsätzlich positiv zu sehen; mit dem Parallelbetrieb als dem Mindesten ist ein höherer Anspruch der ausschließlich verschlüsselte Betrieb (mit Weiterleitungen von http nach https natürlich).

Du liegst mit den teilweise unverschlüsselten Seiten darunter.

Du hast https://www.ssllabs.com/ssltest/ über deine Seite laufen lassen?

Ja das habe ich gemacht. Da meine Fachkenntnisse und auch mein Englisch nicht so gut ist, kann ich mit dem sehr umfangreichen Ergebnis nicht so richtig viel anfangen.

So lange da ein A oder gar A+ rauskommt, bist du zumindest auf der sicheren Seite.

Beachtung solltest du der Browser-Liste schenken, die roten Einträge betreffen Browser, die die verschlüsselten Seiten nicht abrufen können; meist betrifft das nur den IE unter Windows XP.

Ein Problem könnten die kleinen gelben Hinweise "No SNI" stellen: Diese Browser bekommen unter Umständen bei Abruf deiner verschlüsselten Seiten nicht deine Seite, sondern eine andere zu sehen, die auf derselben Maschine (lies: derselben IP) untergebracht ist. Sofern du aber nur ein Hosting-Angebot nutzt, keinen eigenen Server, kannst du daran leider nichts ändern.

[oxo888oxo]

So lange da ein A oder gar A+ rauskommt, bist du zumindest auf der sicheren Seite.

Leider kommt bei mir insgesamt nur ein C heraus.

Hier mal die Ergebnisse der 4 Balken oben:

Certificate / grün / 100

Protocol Support / gelb / 50

Key Exchange / grün / 80

Cipher Strength / grün / 90

Darunter sind dann 4 orange hinterlegte Hinweise:

• This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. MORE INFO »

• Intermediate certificate has a weak signature. Upgrade to SHA2 as soon as possible to avoid browser warnings. MORE INFO »

• The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C. MORE INFO »

• The server does not support Forward Secrecy with the reference browsers. MORE INFO »

Beachtung solltest du der Browser-Liste schenken, die roten Einträge betreffen Browser, die die verschlüsselten Seiten nicht abrufen können; meist betrifft das nur den IE unter Windows XP.

Ja da wird bei mir auch nur "IE 6 / XP" bemängelt. Damit kann ich leben, denke ich :)

Ein Problem könnten die kleinen gelben Hinweise "No SNI" stellen: Diese Browser bekommen unter Umständen bei Abruf deiner verschlüsselten Seiten nicht deine Seite, sondern eine andere zu sehen, die auf derselben Maschine (lies: derselben IP) untergebracht ist. Sofern du aber nur ein Hosting-Angebot nutzt, keinen eigenen Server, kannst du daran leider nichts ändern.

Mit "No SNI" markiert sind:

• Android 2.3.7

• IE 6 / XP

• IE 8 / XP

• Java 6u45

[CIA]

• The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C. MORE INFO »

Daran kannst du, falls du Hosting-Kunde bist, dummerweise nichts ändern (außer einem Wechsel des Hosters). Erstens muss die Software das Protokoll kennen (du kannst als Hosting-Kunde aber keine neue Software im System installieren), zweitens musst du in der Lage sein, das Protokoll zu aktivieren (die entsprechende Einstellung ist zumindest beim Apache-Webserver nur für den Serveradministrator zugänglich).

Leider wirst du damit auch erstmal übers C nicht hinauskommen, aber das heisst ja nicht, dass du an den anderen Sachen nicht noch schrauben könntest.

• Intermediate certificate has a weak signature. Upgrade to SHA2 as soon as possible to avoid browser warnings. MORE INFO »

Die Zertifikate findest im Abschnitt Certification Paths, dort sollte auch stehen, welches Zertifikat schwach signiert wurde. Beim Aussteller müsstest du dich dann um ein besseres bemühen und gegebenenfalls auf deinen Server spielen (das Zwischenzertifikat ist nicht dein Zertifikat, es könnte lediglich sein, dass es von deinem Server zusammen mit deinem Zertifikat an den Browser ausgeliefert wird, damit der Browser nicht erst noch woanders suchen muss).

• The server does not support Forward Secrecy with the reference browsers. MORE INFO »

• This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. MORE INFO »

An diesen beiden Punkten kannst du eventuell etwas ändern. Beim Apache ist die Einstellung SSLCipherSuite dafür zuständig, siehe https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite .

Mit HIGH:!DH:!aNULL:!MD5:!RC4:!DSS ist ein A möglich; in HIGH sollte Forward Secrecy enthalten sein, so die Software es unterstützt, !DH entfernt die besagten "weak Diffie-Hellman (DH) key exchange parameters". Eine Neuprüfung ist natürlich notwendig, je nach Alter der Software kann es auch passieren, dass nur noch Müll übrig bleibt, dann bist du mit DH immer noch besser bedient.

[Auge]

Hallo

Daran kannst du, falls du Hosting-Kunde bist, dummerweise nichts ändern (außer einem Wechsel des Hosters).

Als Ergänzung: Ich kann mir nicht vorstellen, dass 1&1, um die es hier geht, nicht auf die Ereignisse der letzten zwei Jahre (Snowden, Heart-Bleed, etc. pp.) reagiert haben. Oftmals werden aber leider gegenüber dem vorherigen Iststand verbesserte Angebote nicht den Bestandskunden unterbreitet, sondern nur Neukunden.

Eventuell (und vermutlich) ist es möglich, bei 1&1 selbst zu bleiben und einen Paketwechsel durchzuführen. Ob oxo888oxo das will oder nicht, ist davon unbelassen. Bei 1&1 fragen sollte er zumindest einmal.

Tschö, Auge

[Der Martin]

Hi,

Oder gibt es auch Dinge, die wirklich dagegen sprechen?

ja, eventuell Performance: Der SSL-Verbindungsaufbau dauert immer etwas länger als ein unverschlüsselter Verbindungsaufbau. Der zusätzliche Zeitbedarf liegt, je nachdem wie gut der Server in Form ist, zwischen einer halben und fünf Sekunden pro Seitenabruf.

Man sollte also im Einzelfall testen, wie sehr die SSL-Verbindung tatsächlich ins Gewicht fällt. Google scheint ein Positiv-Beispiel zu sein, da ist der Performance-Unterschied zwischen http: und https: quasi nicht feststellbar. Aldi ist eher ein Negativ-Beispiel: Da dauert der Abruf jeder Seite etwa 1..2s länger, seit die ohne erkennbaren Grund alles auf SSL umgestellt haben.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

Oder gibt es auch Dinge, die wirklich dagegen sprechen?

ja, eventuell Performance: Der SSL-Verbindungsaufbau dauert immer etwas länger als ein unverschlüsselter Verbindungsaufbau. Der zusätzliche Zeitbedarf liegt, je nachdem wie gut der Server in Form ist, zwischen einer halben und fünf Sekunden pro Seitenabruf.

Mir ist kein einziger Fall bekannt, wo der SSL-Handshake mehr als 200ms dauert. Ich würde hier wirklich das Problem bei deiner Leitung suchen…

Aldi ist eher ein Negativ-Beispiel: Da dauert der Abruf jeder Seite etwa 1..2s länger, seit die ohne erkennbaren Grund alles auf SSL umgestellt haben.

mit http: 0.082 total, mit https: 0.423 total (inklusive startup time). Wobei die HTTP-Anfrage auf ein 403 stösst und vermutlich vom Backend gar nicht erst verarbeitet wird und deshalb < 100ms liegt. Ich habe nach wie vor deine lokalen Gegebenheiten in Verdacht.

LG,
CK

[Der Martin]

Moin,

Der SSL-Verbindungsaufbau dauert immer etwas länger als ein unverschlüsselter Verbindungsaufbau. Der zusätzliche Zeitbedarf liegt, je nachdem wie gut der Server in Form ist, zwischen einer halben und fünf Sekunden pro Seitenabruf.

Mir ist kein einziger Fall bekannt, wo der SSL-Handshake mehr als 200ms dauert.

mir ist kein Fall bekannt, wo ein reiner HTTP-Request-Response-Zyklus weniger als 200ms dauert, von SSL gar nicht zu reden. Außer natürlich der lokale Apache, der antwortet ohne spürbare Verzögerung.

Ich würde hier wirklich das Problem bei deiner Leitung suchen…

Leitung ist wahrscheinlich ein treffendes, aber eben sehr ungenaues Stichwort. An Browser/OS kann's nicht liegen, da sich Windows- und Linux-PCs mit ganz unterschiedlichen Browsern in diesem Punkt ähnlich anfühlen; am PC kann's nicht liegen, weil das Verhalten auf allen PCs hier im LAN/WLAN ähnlich ist; am Router kann's nicht liegen, weil ich im Lauf der Jahre schon drei verschiedene hatte; an der DSL-Hardware kann's m.E. auch nicht liegen, weil (nachdem die massiven Störungen von neulich wieder weg sind) das Protokoll der Fritzbüx eine stabile Verbindung meldet.
Bleibt also eine provider-seitige Bremse, die aber nicht die Transferrate bremst (die liegt bei bis zu 750kB/s downstream), sondern nur Totzeiten pro Paket zu verursachen scheint.

Aldi ist eher ein Negativ-Beispiel: Da dauert der Abruf jeder Seite etwa 1..2s länger, seit die ohne erkennbaren Grund alles auf SSL umgestellt haben.

mit http: 0.082 total, mit https: 0.423 total (inklusive startup time). Wobei die HTTP-Anfrage auf ein 403 stösst und vermutlich vom Backend gar nicht erst verarbeitet wird und deshalb < 100ms liegt.

Die Startseite von ALDI Süd braucht hier vom Drücken der Enter-Taste bis zum ersten sichtbaren Lebenszeichen im Browserfenster geschätzte 3 Sekunden. Folgeseiten kommen mit etwas geringerer Verzögerung, vermutlich weil einige Ressourcen schon im Cache sind.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

Der SSL-Verbindungsaufbau dauert immer etwas länger als ein unverschlüsselter Verbindungsaufbau. Der zusätzliche Zeitbedarf liegt, je nachdem wie gut der Server in Form ist, zwischen einer halben und fünf Sekunden pro Seitenabruf.

Mir ist kein einziger Fall bekannt, wo der SSL-Handshake mehr als 200ms dauert.

mir ist kein Fall bekannt, wo ein reiner HTTP-Request-Response-Zyklus weniger als 200ms dauert, von SSL gar nicht zu reden. Außer natürlich der lokale Apache, der antwortet ohne spürbare Verzögerung.

Du hast also viel Lag. Tut mir leid, aber es sieht für mich immer mehr nach Problemen entweder bei deinem Provider, bei deiner Leitung (im Sinne von physikalischer Leitung) oder deinem lokalen Netzwerk. Diese extremen Lag-Zeiten sind absolut nicht normal, auch nicht für plattes Land; wir leben ja selber auf dem Land, und mein Vater nochmal mehr (der bekommt nur DSL light mit 768kbit) und wir haben beide nicht diese Probleme. Hast du denn mal gemessen, ob du Paket-Verlust hast?

Ich würde hier wirklich das Problem bei deiner Leitung suchen…

Leitung ist wahrscheinlich ein treffendes, aber eben sehr ungenaues Stichwort.

Was daran liegt, dass ich keine Ahnung von deinen Gegebenheiten habe ;-)

Die Startseite von ALDI Süd braucht hier vom Drücken der Enter-Taste bis zum ersten sichtbaren Lebenszeichen im Browserfenster geschätzte 3 Sekunden. Folgeseiten kommen mit etwas geringerer Verzögerung, vermutlich weil einige Ressourcen schon im Cache sind.

Die Startseite von Aldi-Süd braucht lt. Dev-Tools bei mir 473ms bis alles vollständig geladen und gerendert ist, bei ausgeschaltetem Cache.

LG,
CK

[Der Martin]

Hallo Christian,

Du hast also viel Lag. Tut mir leid, aber es sieht für mich immer mehr nach Problemen entweder bei deinem Provider, bei deiner Leitung (im Sinne von physikalischer Leitung) oder deinem lokalen Netzwerk.

das muss dir nicht leid tun, du kannst ja nichts dafür. ;-)
Mein lokales Netzwerk können wir aus der Geschichte wohl auch ausklammern, denn wie ich schon erwähnte, habe ich (W)LAN-intern beim Zugriff auf meinen Test-Apache wahrscheinlich die kurzen Zugriffszeiten, die du auch extern gewöhnt bist - nämlich "nicht spürbar".

Diese extremen Lag-Zeiten sind absolut nicht normal

Ich empfinde sie als normal, weil ich es hier am 6Mbit-DSL-Anschluss nie anders erlebt habe. Ich habe das Internet noch mit einem 14400er-Modem kennengelernt, später mit einem 56k-Modem. Da war der Umstieg auf DSL (zunächst noch 1Mbit) natürlich schon ein Meilenstein. Die Totzeiten waren aber von Anfang an ähnlich wie übers Analog-Modem. Das war so, als die Telekom noch mein DSL-Anbieter war, und das ist auch beim Wechsel zu 1&1 und dem Upgrade auf 6Mbit so geblieben.

Schnellere Verbindungen (im Sinne von "kürzere Antwortzeiten") kenne ich eigentlich nur in Unternehmen oder Instituten, die eine permanente, feste Anbindung ans Internet haben. Insofern sehe ich da auch keinen Grund, mich zu ärgern; es ist einfach so.

Hast du denn mal gemessen, ob du Paket-Verlust hast?

Ähm ... nein, wie mache ich das? Ein ping kann ich jedenfalls über längere Zeit laufen lassen, ohne dass etwas auffällt. Zu forum.selfhtml.org (eben zum Probieren benutzt) bekomme ich Ping-Antwortzeiten von etwas über 30ms, zu anderen Hosts sind es meist auch 30..40ms, in seltenen Fällen auch mal über 50ms. Das erscheint mir recht flott.

LAN-intern liegen die Ping-Zeiten ungefähr um 1ms.

Leitung ist wahrscheinlich ein treffendes, aber eben sehr ungenaues Stichwort.

Was daran liegt, dass ich keine Ahnung von deinen Gegebenheiten habe ;-)

Logisch. :-)

Die Startseite von ALDI Süd braucht hier vom Drücken der Enter-Taste bis zum ersten sichtbaren Lebenszeichen im Browserfenster geschätzte 3 Sekunden. Folgeseiten kommen mit etwas geringerer Verzögerung, vermutlich weil einige Ressourcen schon im Cache sind.

Die Startseite von Aldi-Süd braucht lt. Dev-Tools bei mir 473ms bis alles vollständig geladen und gerendert ist, bei ausgeschaltetem Cache.

Wow. Davon kann ich träumen.

Ciao,
 Martin

[Christian Kruse]

Hallo Martin,

das muss dir nicht leid tun, du kannst ja nichts dafür. ;-)

Ich versuche nur immer den Eindruck zu vermeiden, ich wolle dir etwas vorwerfen oder etwas auf dich abwälzen. Ich glaube halt wirklich, dass es an dir im weitesten Sinne liegt. Nicht persönlich, sondern technisch.

Mein lokales Netzwerk können wir aus der Geschichte wohl auch ausklammern, denn wie ich schon erwähnte, habe ich (W)LAN-intern beim Zugriff auf meinen Test-Apache wahrscheinlich die kurzen Zugriffszeiten, die du auch extern gewöhnt bist - nämlich "nicht spürbar".

Das ist kein Argument, der Verkehr innerhalb des LANs ist technisch etwas anderes als Traffic nach extern. Da spielen dann, auch innerhalb des LANs, mehr Aspekte eine Rolle, z.B. die Switches. Kleines Beispiel: ich hatte einen Billig-Switch von Dell hier eine (kurze 😉) Zeit im Einsatz, der bei LAN-internem Verkehr keinerlei Probleme gemacht hat. Aber bei externem Verkehr, besonders gut zu bemerken bei SSH-Traffic, weil das da halt schnell auffällt, hatte er irgend ein Problem mit dem NATing meiner Fritzbox und hat sehr viele Retransmissions verursacht. Die Folge war dann ein. sehr laggige Verbindung. Nachdem ich das Gerät ausgetauscht habe, war das Problem vollständig verschwunden.

Diese extremen Lag-Zeiten sind absolut nicht normal

Ich empfinde sie als normal, weil ich es hier am 6Mbit-DSL-Anschluss nie anders erlebt habe.

Lass dir gesagt sein: sie sind nicht normal g

Ich habe das Internet noch mit einem 14400er-Modem kennengelernt, später mit einem 56k-Modem.

Ich habe da eine ähnliche Geschichte, nur dass ich vom 9600er auf ein 14400er auf eine ISDN-Karte umgestiegen bin. 56k ging bei uns nicht, zu weit ausserhalb.

Hast du denn mal gemessen, ob du Paket-Verlust hast?

Ähm ... nein, wie mache ich das?

Lass mal Wireshark oder tcpdump mitlaufen. Da kannst du genauer verfolgen, was eigentlich auf deiner Leitung passiert. Ein für mich unersetzliches Debug-Tool.

Ein ping [...]

Versuch mal nach und nach die Packet size zu erhöhen und schau mal, ob sich was ändert:

ping -s 64 -M do heise.de
ping -s 128 -M do heise.de
ping -s 256 -M do heise.de
ping -s 512 -M do heise.de
ping -s 1024 -M do heise.de
ping -s 2048 -M do heise.de
...

Wenn deine MTU falsch eingestellt ist, kann das auch zu von dir beschriebenen Problemen führen.

Edit: ich hatte den -M do-Parameter vergessen. Du solltest bis etwas über 1400 gehen können, Standard-MTU ist 1500.

Edit 2: unter OS X ist es der -D-Parameter, unter Windows scheint es der -f-Parameter zu sein (ich kann es aber nicht prüfen). Und genauer gesagt solltest du bis 1454 erhöhen können.

Die Startseite von ALDI Süd braucht hier vom Drücken der Enter-Taste bis zum ersten sichtbaren Lebenszeichen im Browserfenster geschätzte 3 Sekunden. Folgeseiten kommen mit etwas geringerer Verzögerung, vermutlich weil einige Ressourcen schon im Cache sind.

Die Startseite von Aldi-Süd braucht lt. Dev-Tools bei mir 473ms bis alles vollständig geladen und gerendert ist, bei ausgeschaltetem Cache.

Wow. Davon kann ich träumen.

Ich vermute nach wie vor ein technisches Problem auf deiner Seite, deine Bandbreite (6mbit hattest du ja gesagt) sollte das problemlos hergeben, viel mehr haben wir hier auch nicht.

LG,
CK

[Der Martin]

Hallo,

Mein lokales Netzwerk können wir aus der Geschichte wohl auch ausklammern, denn wie ich schon erwähnte, habe ich (W)LAN-intern beim Zugriff auf meinen Test-Apache wahrscheinlich die kurzen Zugriffszeiten, die du auch extern gewöhnt bist - nämlich "nicht spürbar".

Das ist kein Argument, der Verkehr innerhalb des LANs ist technisch etwas anderes als Traffic nach extern. Da spielen dann, auch innerhalb des LANs, mehr Aspekte eine Rolle, z.B. die Switches.

hmm, ich sehe nicht, warum das einen Unterschied machen sollte. Die sind ja beim LAN-internen Verkehr ebenso beteiligt wie beim Verkehr nach extern. Nur der Router (eine 7170er Fritzbüx) und die Strecke nach draußen machen einen Unterschied aus.

Kleines Beispiel: ich hatte einen Billig-Switch von Dell hier eine (kurze 😉) Zeit im Einsatz, der bei LAN-internem Verkehr keinerlei Probleme gemacht hat. Aber bei externem Verkehr, besonders gut zu bemerken bei SSH-Traffic, weil das da halt schnell auffällt, hatte er irgend ein Problem mit dem NATing meiner Fritzbox und hat sehr viele Retransmissions verursacht. Die Folge war dann ein. sehr laggige Verbindung. Nachdem ich das Gerät ausgetauscht habe, war das Problem vollständig verschwunden.

Hmm. Klingt für mich wie schwarze Magie, zumindest nicht rational erklärbar.

Hast du denn mal gemessen, ob du Paket-Verlust hast?

Ähm ... nein, wie mache ich das?

Lass mal Wireshark oder tcpdump mitlaufen. Da kannst du genauer verfolgen, was eigentlich auf deiner Leitung passiert. Ein für mich unersetzliches Debug-Tool.

Wireshark hätte mir auch einfallen können. Mit tcpdump kenne ich mich nicht aus, das stelle ich also erstmal zurück.

Die Wireshark-Analyse hat so einige interessante Erkenntnisse gebracht (auch wenn sie mich in der aktuellen Frage nicht weiterbringen):

Retransmissions sind mir während der ganzen Beobachtung bei unverschlüsselten Verbindungen keine begegnet, mein lokaler DNS beantwortet Anfragen in der Regel innerhalb von <2ms für Hostnamen, die er im Cache hat, und wenn er die Anfrage nach draußen weiterreichen muss, dauert's 50..70ms, bis die Antwort da ist.

Für die Gesamt-Threadliste (ohne Paging, aber die meisten Threads eingeklappt, weil gelesen) von http://forum.selfhtml.org/self ist die reine HTML-Ressource in etwa 3s geladen. Sind ja auch immerhin 54 Pakete mit insgesamt rund 75kB. Da ist vermutlich die Serverseite das bremsende Element, darauf hast du ja auch schon mehrmals hingewiesen.

Etwa 5s nach dem initialen HTTP-Request sehe ich ein TLS-Handshake mit 162.159.240.204 - wer ist das denn?? Ein whois sagt mir, dass diese IP zu cloudflare.com in Kalifornien gehört. Was zum Geier hab ich denn mit denen?? Das TLS-Handshaking, also die Zeit bis der Austausch der Nutzdaten via HTTPS beginnt, dauert übrigens etwa eine Sekunde. Diese Verbindung könnte aber auch aus einem anderen der zahlreichen offenen Browser-Tabs initiiert worden sein und muss nicht unbedingt mit selfhtml.org zusammenhängen.

Mir dämmert auch inzwischen, dass wir vielleicht von zwei ganz unterschiedlichen Dingen reden. Wenn ich sage, ein HTTP-Zyklus brauche gewöhnlich eine Sekunde oder länger, dann meine ich natürlich die komplette Übertragung der Response - vorher merke ich ja als Nutzer noch nichts. Das geht bei sehr kurzen Inhalten tatsächlich sehr schnell; sobald aber das HTML-Dokument als solches etwas länger wird, braucht das eben seine Zeit.

So, jetzt nochmal die Aldi-Startseite, die heute mittag schon als Test Case herhalten musste:

Hier braucht das TLS-Handshaking nur etwa 170ms, die komplette Übertragung bis zum Beenden der TLS-Verbindung etwa weitere 600ms. Hier gab's sogar ein paar Retransmissions innerhalb der TLS-verschlüsselten Daten - was immer ich davon halten soll.
Das ging aber auch gefühlt deutlich schneller als üblich; ich vermute, dass mein Browser z.B. die Bilder noch im Cache hatte und nicht mehr extra anfordern musste.

Ein ping [...]

Versuch mal nach und nach die Packet size zu erhöhen und schau mal, ob sich was ändert:

ping -s 64 -M do heise.de
ping -s 128 -M do heise.de
ping -s 256 -M do heise.de
ping -s 512 -M do heise.de
ping -s 1024 -M do heise.de
ping -s 2048 -M do heise.de
...

Ab 1024 steigt die Antwortzeit von anfangs rund 40ms auf etwa 55..60ms, 2048 geht nicht mehr (weil MTU nur 1500 ist).

Und was sagen mir nun alle diese Erkenntnisse? :-)

So long,
 Martin

[Christian Kruse]

Hallo Martin,

Kleines Beispiel: ich hatte einen Billig-Switch von Dell hier eine (kurze 😉) Zeit im Einsatz, der bei LAN-internem Verkehr keinerlei Probleme gemacht hat. Aber bei externem Verkehr, besonders gut zu bemerken bei SSH-Traffic, weil das da halt schnell auffällt, hatte er irgend ein Problem mit dem NATing meiner Fritzbox und hat sehr viele Retransmissions verursacht. Die Folge war dann ein. sehr laggige Verbindung. Nachdem ich das Gerät ausgetauscht habe, war das Problem vollständig verschwunden.

Hmm. Klingt für mich wie schwarze Magie, zumindest nicht rational erklärbar.

Das ist rational mit Sicherheit erklärbar, ist ja nur Technik. Aber mir fehlen die tiefergehenden Kenntnisse und das Interesse, um wirklich bis ins Detail zu klären woran es liegt.

Wireshark hätte mir auch einfallen können. Mit tcpdump kenne ich mich nicht aus, das stelle ich also erstmal zurück.

Wenn du Wireshark benutzt dann brauchst du kein tcpdump mehr, das ist das gleiche in Konsole :-)

Für die Gesamt-Threadliste (ohne Paging, aber die meisten Threads eingeklappt, weil gelesen) von http://forum.selfhtml.org/self ist die reine HTML-Ressource in etwa 3s geladen. Sind ja auch immerhin 54 Pakete mit insgesamt rund 75kB. Da ist vermutlich die Serverseite das bremsende Element, darauf hast du ja auch schon mehrmals hingewiesen.

Ja, da ist auch schon echt gut optimiert. Das Problem ist hier wirklich Rails, dass sehr langsam ist beim Rendering. Ich hätte damals nicht auf die Community hören sollen und das so machen sollen, wie ich es für richtig halte… aber nun ist es zu spät.

Etwa 5s nach dem initialen HTTP-Request sehe ich ein TLS-Handshake mit 162.159.240.204 - wer ist das denn??

Das wird cdn.mathjax.org sein.

Das TLS-Handshaking, also die Zeit bis der Austausch der Nutzdaten via HTTPS beginnt, dauert übrigens etwa eine Sekunde.

Das ist zu lang und nicht normal… auch nicht bei 6mbit.

Mir dämmert auch inzwischen, dass wir vielleicht von zwei ganz unterschiedlichen Dingen reden. Wenn ich sage, ein HTTP-Zyklus brauche gewöhnlich eine Sekunde oder länger, dann meine ich natürlich die komplette Übertragung der Response

Ich auch.

Hier braucht das TLS-Handshaking nur etwa 170ms, […]

Ja, das ist ein normaler Wert.

die komplette Übertragung bis zum Beenden der TLS-Verbindung etwa weitere 600ms.

Das liegt IMHO auch im Normbereich.

Hier gab's sogar ein paar Retransmissions innerhalb der TLS-verschlüsselten Daten - was immer ich davon halten soll.

Erstmal gar nix, gelegentliche Retransmissions sind normal. Sie dürfen sich nur nicht häufen.

Und was sagen mir nun alle diese Erkenntnisse? :-)

Nix, denn die Werte sind im Wesentlichen unauffällig. Nach wie vor ist irgendwas spanisch bei dir und wir wissen weiterhin nicht was es ist.

LG,
CK

[Camping_RIDER]

Aloha ;)

Hast du denn mal gemessen, ob du Paket-Verlust hast?

Ähm ... nein, wie mache ich das? Ein ping kann ich jedenfalls über längere Zeit laufen lassen, ohne dass etwas auffällt. Zu forum.selfhtml.org (eben zum Probieren benutzt) bekomme ich Ping-Antwortzeiten von etwas über 30ms, zu anderen Hosts sind es meist auch 30..40ms, in seltenen Fällen auch mal über 50ms. Das erscheint mir recht flott.

Außer Ping wäre mir da jetzt auch nix eingefallen. Aber nur mal interessehalber: Hast du schonmal versucht, die Ressource per wget anzufordern und diese Zeit zu messen? Das sollte imho den "Overhead", den ein Browser verursacht, ausschalten und du könntest demnach die Problemzonen splitten. Wenns per wget schnell geht, liegts am Browser (z.B. auch evtl. Zeit zum Rendern ...), wenn wget auch sehr lange braucht, liegts am Netzwerk.

Natürlich fordert wget nicht das gleiche an wie der Browser (weil du damit ja nur das blanke html bekommst), aber wenn du die "Testseite" geschickt wählst (am besten eine Seite mit wenigen eingebundenen Ressourcen), sollte schon spürbar sein, ob da Totzeiten in der Leitung auftreten oder nicht...

Grüße,

RIDER

[Christian Kruse]

Hallo Camping_RIDER,

Natürlich fordert wget nicht das gleiche an wie der Browser (weil du damit ja nur das blanke html bekommst), aber wenn du die "Testseite" geschickt wählst (am besten eine Seite mit wenigen eingebundenen Ressourcen), sollte schon spürbar sein, ob da Totzeiten in der Leitung auftreten oder nicht...

Das können alle modernen Browser, inklusive Firefox, Chrome und Safari detailiert darstellen, Stichwort Network-Reiter in den Dev-Tools. Inklusive Wartezeit, Übertragungszeit, Rendering-Zeit, etc, pp:

LG,
CK

[Camping_RIDER]

Aloha ;)

Natürlich fordert wget nicht das gleiche an wie der Browser (weil du damit ja nur das blanke html bekommst), aber wenn du die "Testseite" geschickt wählst (am besten eine Seite mit wenigen eingebundenen Ressourcen), sollte schon spürbar sein, ob da Totzeiten in der Leitung auftreten oder nicht...

Das können alle modernen Browser, inklusive Firefox, Chrome und Safari detailiert darstellen, Stichwort Network-Reiter in den Dev-Tools. Inklusive Wartezeit, Übertragungszeit, Rendering-Zeit, etc, pp:

Ja, das ist mir schon bewusst. Trotzdem: Wenn der Browser aus irgendeinem Grund (welchem denkbaren oder undenkbarem auch immer, wenn nicht im Rendern, dann vielleicht im Request oder im Verbundungsaufbau) Totzeiten verursachen würde, wären die auch in den devtools verzeichnet. So lässt sich der Browser nicht wirklich konsequent ausschließen; das kann einzig und allein der Vergleich der (meinetwegen durch die devtools erhaltenen) Wartezeit+Übertragungszeit im Browser mit dem, was ein simples wget für die selbe Ressource braucht.

Grüße,

RIDER