Seite von http auf https umleiten? Sinnvoll oder nicht?

[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