Unerklärliche Geschwindigkeitslimitierung bei Remote-Zugriff

  • Servus Allerseits,


    zwar bin noch nicht stolzer Besitzer eines NAS, habe aber die Anschaffung eines QNAP TS-653D in die Wege geleitet. Auch dank dieses Forums habe ich mir davon ein gutes Bild machen können, danke dafür. Vorab würde ich allerdings gerne ein Netzwerkproblem lösen, das ich bei meinem derzeitigen Arme-Leute-NAS feststelle: einem Raspberry Pi4. Diesen betreibe ich als Heimserver hinter einer Fritzbox 7490, in erster Linie als Datenspeicher mit SMB und NextCloud; auch eine selbst geschriebene ClojureScript-API läuft darauf.


    Bei Remote-Zugriffen plagt mich derzeit eine besonders langsame Datenübertragung. Im Heimnetz läuft alles annähernd mit Gigabit-Geschwindigkeit – ich kann mit 80MB/s und mehr vom Pi-Server herunterladen.


    Die Remote-Problematik erkläre ich am besten anhand eines Beispiels, das mit möglichst wenig Schnickschnack wie Gateways, Verschlüsselung, VPN, etc. auskommt, nämlich dem Download einer großen Datei mittels HTTP, serviert vom Apachen. Dieser horcht auf Port 81, der von der Fritzbox weitergeleitet wird.


    Mache ich einen CLI-Speedtest auf dem Pi4, komme ich annähernd auf die zugesicherten Geschwindigkeiten meiner 100/40er DSL-Leitung. Konkret messe ich ca. 35Mbit im Upload (interessanterweise auch einen ähnlichen Wert im Download, aber der ist hier nicht maßgeblich.).


    Um den externen Download zu prüfen (aus Sicht meines Pi4 also ein Upload), logge ich mich per SSH auf einem meiner Webspaces ein (z.B. Netcup) und lade die Datei mit `wget mein.heimserver.net/grosse_datei.ext` herunter. Die Anbindung des Rechenzentrums sollte über jeden Zweifel erhaben sein – die magere Geschwindigkeit von 250–300 kB/s (≈2 Mbit) muss also irgendwie in der Fritzbox oder bei meinem Provider (NetCologne) entstehen.


    Interessant finde ich außerdem dreierlei:

    1. Ob ich meinen Server über die derzeitige IP, oder aber über DynDNS identifiziere, macht keinen Unterschied.
    2. Das Problem tritt genauso auf, wenn ich probeweise meinen Hauptrechner (Thinkpad 580) anstelle des Pi4 einsetze. Ich erwarte daher mit dem QNAP das gleiche Problem.
    3. Wenn ich von demselben oder einem anderen Webspace parallel weitere Download-Instanzen anwerfe, so verlaufen diese ebenfalls mit 250–300 kB/s. Auf dem Monitor meiner FritzBox kann ich dabei nachverfolgen, wie mit jeder zusätzlichen Instanz die Upload-Auslastung entsprechend steigt. Die Hardware meines Heimnetzes scheint also nicht der Flaschenhals zu sein.

    Ich kann mir darauf keinen rechten Reim machen… warum kann nicht schon ein einzelner Download annähernd den vollen Upload meiner Leitung ausnutzen? Kann es am Ende sein, dass der Provider die maximale Geschwindigkeit pro externem Request drosselt?


    Wenn jemandem dazu etwas einfiele, könnte ich der Installation des QNAP sehr viel gelassener ins Auge sehen! Vielen Dank!

  • Warum sollte 1) auch einen Unterschied machen? Ob Du die IP oder den DynDNS verwendest, hat ausschließlich beim Verbindungsaufbau eine Aufwirkung, nämlich die, das zusätzlich (k)ein DNS-Resolv erfolgt. Für die anschließende Datenübertragung ist das total "Hupe". ;)


    Das Problem scheint also zu sein, dass Du maximal 300 kB/s pro TCP-Session "rausbekommst". Hast Du auf dem Pi irgendwelche Beschränkungen zur WindowSize? Wie ist der Roundtrip von Deinem Webspace zu Deinem Pi?

  • Servus und danke für die schnelle Antwort!

    Warum sollte 1) auch einen Unterschied machen?

    Ich hatte einen solchen Unterschied auch nicht erwartet, wollte damit nur einem oft gelesenen Ratschlag zuvorkommen (habe nämlich gefühlt das ganze Internet ausrecherchiert):


    Das Problem scheint also zu sein, dass Du maximal 300 kB/s pro TCP-Session "rausbekommst".

    Wäre ich Netzwerktechniker und nicht nur Webentwickler, hätte ich das vielleicht auch so auf den Punkt bringen können danke!

    Wie ist der Roundtrip von Deinem Webspace zu Deinem Pi?

    Hier ein paar ping-Zeiten von Uberspace:


    Code
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=56 time=17.1 ms
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=2 ttl=56 time=18.3 ms
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=3 ttl=56 time=17.1 ms
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=56 time=17.8 ms
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=56 time=22.7 ms

    Netcup stellt `ping` nicht zur Verfügung. Dort bekomme ich aber die gleichen Übertragungswerte.


    Hast Du auf dem Pi irgendwelche Beschränkungen zur WindowSize?

    Habe das erst überlesen. Der Begriff ist mir auch neu, so dass ich erstmal recherchieren muss. Aber: sowohl auf meinem Pi4 als auch auf meinem Hauptrechner habe ich nur wenig an Apache geschraubt, so dass ich die Default-Werte für Ubuntu 20.04 bzw. 22.04 annehmen würde.


    Sodale, habe mich grade mal eingelesen und mit iperf folgendes feststellen können:

    Code
    iperf -c 192.168.178.51 --window 8M
    ------------------------------------------------------------
    Client connecting to 192.168.178.51, TCP port 5001
    TCP window size:  416 KByte (WARNING: requested 8.00 MByte)
    ------------------------------------------------------------
    [  3] local 192.168.178.5 port 58068 connected with 192.168.178.51 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.0 sec  1.08 GBytes   932 Mbits/sec

    Mein Pi gestattet also 416 Kbyte window size. Bisher habe ich das nur lokal testen können, da iperf auf meinen Webspaces nicht installiert ist.

    2 Mal editiert, zuletzt von Phylax () aus folgendem Grund: Ein Beitrag von Phylax mit diesem Beitrag zusammengefügt.

  • Die Anbindung des Rechenzentrums sollte über jeden Zweifel erhaben sein

    Aber dass schliesst ja nicht aus, dass der Anbieter die Upload-Geschwindigkeit begrenzt. Ich würde die Ursache durchaus da vermuten. Je billiger der "Webspace", desto wahrscheinlicher.

  • Aber dass schliesst ja nicht aus, dass der Anbieter die Upload-Geschwindigkeit begrenzt. Ich würde die Ursache durchaus da vermuten. Je billiger der "Webspace", desto wahrscheinlicher.

    Danke. Ich bin aber recht sicher, dass es daran nicht liegt, zudem es ja hier um die Download-Geschwindigkeit der Webspaces geht – die ist bei beiden enorm. Gerade deshalb nehme ich sie zum Testen. Zudem habe ich das Problem auch bei Zugriff mit dem Handy oder letztens aus dem Haus meines Vaters. Dass ich jedesmal an das gleiche Maximum stoße (250–300 kB/s) ist sicher kein Zufall.

  • Um die Sache mit dem Webspace aber eventuell doch auszuschließen, wäre es ggf. gut, wenn Du mal von wo anders die Daten runterlädst.

    Ich weiß nicht, was sind das für Testdaten? Wenn Du einfach ich sag mal 10 GB "Datenmüll" hättest, könntest Du mir Deine IP bzw. die URL zu den Daten per PN senden.

    Die IP ändert sich eh nach ein paar Stunden (daher nicht die DynDNS) und, wie gesagt, wenn die Daten einfach nur 10 G random sind, könnte ich Dir sagen, "wie schnell" ein Download geht.

  • Um die Sache mit dem Webspace aber eventuell doch auszuschließen, wäre es ggf. gut, wenn Du mal von wo anders die Daten runterlädst.

    Ich halte das für gänzlich unwahrscheinlich, da ich bereits Downloads von zwei Webspaces/Rechenzentren, einer DSL 100/40er Leitung und einer 250/er Kabel-Leitung mit jeweils dem gleichen Ergebnis durchgeführt habe.

    Ich weiß nicht, was sind das für Testdaten? Wenn Du einfach ich sag mal 10 GB "Datenmüll" hättest, könntest Du mir Deine IP bzw. die URL zu den Daten per PN senden.

    Die IP ändert sich eh nach ein paar Stunden (daher nicht die DynDNS) und, wie gesagt, wenn die Daten einfach nur 10 G random sind, könnte ich Dir sagen, "wie schnell" ein Download geht.

    Ein weiterer Test kann nicht schaden. Habe dir eine PM mit Link auf ein Video geschickt – also realistische Daten. Wenn nötig, kann ich auch noch Zufallsdaten generieren. In jedem Fall danke!

  • Auch dank tatkräftiger Unterstützung durch Barungar habe ich NetCologne davon überzeugen können, dass das Problem bei ihnen liegt. Gestern wurde es behoben und ich kann wieder mit vollen 40Mbit hochladen – für das NAS ist nun also alles bereit und dieser Thread abgeschlossen. Vielen Dank nochmal für die Hilfe!