Hallo zusammen,

ich untersuche seit einiger Zeit extrem schwankende Uploads von einem Telekom-Festnetzanschluss zu einem ebenfalls im Telekom-Netz erreichbaren Server. Das Ziel ist clean.neo-wp.com / 91.11.153.98. Typisches Beispiel ist der Upload eines WordPress-Plugins: 7 MB dauern teilweise mehrere Minuten, obwohl derselbe Upload über einen externen Proxy oder zu Cloudflare normal schnell läuft.

Fehlerbild und Messwerte

• Direkter HTTPS-Upload von 7 MiB: einmal 6,11 s, danach 98,33 s, 122,17 s, 125,43 s und einmal Abbruch nach mehr als 120 s.

• Derselbe Upload über einen Proxy bei Hetzner (23.88.49.61): 6,74 s, 6,78 s und 8,24 s.

• Upload von 7 MiB zu Cloudflare: über IPv4 1,93–2,20 s, über IPv6 1,79–2,01 s.

• Direkter SCP-Upload von 7 MiB: 3,37 s bis 109,2 s. Über den Hetzner-Proxy etwa 3 s.

• Ein 50-MiB-Upload über den Proxy dauerte 15 s. Direkt zum Ziel hing die Verbindung; nach ungefähr einer Minute waren nur 7,08 MiB TCP-Nutzdaten übertragen, davon etwa 0,69 MiB Retransmits.

• Ein direkter Download von 50 MiB vom selben Server dauerte 13 s. Betroffen ist also vor allem die Upload-Richtung.

• In einer langsamen direkten Messung lagen die TCP-Retransmits bei rund 12 Prozent.

Der direkte IPv4-Pfad lief bei den Messungen über:

62.155.243.160 → 91.23.222.121 → 91.11.153.98

Der Fehler tritt nicht konstant auf. Einzelne Übertragungen sind normal schnell, die nächste kann um Größenordnungen langsamer werden. Sechs parallele direkte TCP-Verbindungen waren in einem Test ähnlich langsam; es sieht daher nicht nach einem einzelnen auffälligen ECMP-Pfad aus.

Was ich bereits geprüft habe

• Ein anderer Router und ein Test von einem anderen Anschluss bzw. Standort in Schweinfurt zeigten dasselbe Verhalten.

• Der lokale Anschluss erreicht zu Cloudflare die erwartete Uploadrate. WLAN/LAN, lokale Interface-Fehler und große Pings zum Router waren unauffällig.

• PMTU 1492 und MSS 1440 sind korrekt. Eine kleinere MSS von 1200 hat den Fehler nicht behoben.

• Das Ziel läuft hinter einer HAProxy-VM und einer Apache-VM in Parallels. Zwischen den beiden VMs liefen 5.000 Pakete mit 1.500 Byte ohne Verlust; der interne Durchsatz lag bei ungefähr 170 Mbit/s.

• Auf den Virtio-Interfaces des Zielsystems waren keine Queue-Drops, Errors, Missed-Pakete oder Timeouts sichtbar.

• TSO, GSO und GRO auf dem externen Virtio-Interface wurden testweise deaktiviert. Der direkte Upload blieb langsam, während der Upload über den Proxy weiterhin schnell war. Danach wurden die Einstellungen wieder zurückgesetzt.

• Apache, PHP, WordPress und Datenträger sind als Ursache sehr unwahrscheinlich, weil SCP genauso betroffen ist und der Proxy-Pfad zum exakt gleichen Ziel schnell funktioniert.

• Eine testweise veränderte HTTP/2-Fenstergröße in Apache brachte keine messbare Verbesserung und wurde wieder entfernt.

Mein Verdacht

Für mich sieht es nach einem sporadischen Forwarding-, Queue-, Policer- oder Transportproblem auf dem direkten Telekom-internen Pfad zwischen zwei Anschlüssen in AS3320 aus, möglicherweise im Bereich von 91.23.222.121 oder im Zielzugangsnetz. Denkbar wäre auch ein Problem, das nur bestimmte Quell-/Zielkombinationen trifft. Gegen ein grundsätzliches Problem des Zielservers spricht, dass derselbe Datenstrom über Hetzner zum identischen Ziel stabil schnell ist. Gegen ein allgemeines Problem meines Anschlusses sprechen die schnellen Uploads zu Cloudflare und die Reproduktion von einem anderen Standort.

Hilfreich wäre eine netzseitige Prüfung dieses Pfades, insbesondere auf Drops, Queue-Probleme, Policing oder fehlerhafte Transportstrecken in Upload-Richtung.

Ich kann ein öffentlich erreichbares HTTPS-Upload-Testziel auf clean.neo-wp.com bereitstellen und die direkten sowie über den Proxy geführten Vergleichsmessungen in einem abgestimmten Zeitfenster wiederholen.