Gelöst

RDP-Verbindung über VPN mit MAGENTA ZUHAUSE HYBRID-Anschluss extrem langsam

+4 weitere

vor 7 Jahren

Hallo Community,

 

ich habe seit dem 19.12.2017 einen MAGENTA ZUHAUSE HYBRID-Anschluss. Diese ersetzt einen alte ISDN-Anschluss mit extrem langsamer DSL-Verbindung. Da mein Wohngebiet kein schnelles über längere Sicht verfügbar ist, habe ich mich zu dieser Alternative entschlossen.

Meine DSL-Geschwindigkeit im Downstream beträgt 3450 kbit/s und im Upstream 2094. Diese sind zwar nicht gerade berauschen, aber immer noch besser als über meinen alten ISDN-Anschluss. Dazu kommt noch die LTE -Geschwindigkeit, welche je nach Uhrzeit bis zu 40Mbit/s bieten kann.

Mein Problem seit Bestehen des neuen Anschlusses ist folgender Sachverhalt. Ich greife über eine RDP-Verbindung in einem VPN -Tunnel auf einen entfernten Server zu. Die einzelnen Verbindungswege DSL oder LTE lassen ein Arbeiten auf den Server zu. Das Verwenden der Kombination DSL+ LTE , der eigentliche Sinn eines Hybridanschlusses, führt von minutenlangen Verzögerungen bis hin zu Verbindungsabbrüchen.

Ich bitte um Eure Mithilfe, da mir kein Mitarbeiter aus dem Telekom-Support nach endlosen Gescprächen bisher eine Erklärung bzw. Lösung anbieten konnte.

Ich kann mir auch nicht vorstellen, dass ich der einzige bin, der dieses spezielle Problem hat.

 

Grüße

KM

Letzte Aktivität

vor 7 Jahren

von

1932

0

29

  • Akzeptierte Lösung

    akzeptiert von

    vor 7 Jahren

    Hallo @Andy1762,

    Ich frage mich, an welcher Stelle entsteht nun mein Problem bei meiner VPN -Verbindung. Bei der Client-Software, im Client- PC, in der Verbindung zum Router bzw. Heinnetzwerk, beim VPN -Server, im Router oder doch beim Bonding, dem Zusammenschalten von DSL und LTE zu einer Verbindung?

    Ich frage mich, an welcher Stelle entsteht nun mein Problem bei meiner VPN -Verbindung. Bei der Client-Software, im Client- PC, in der Verbindung zum Router bzw. Heinnetzwerk, beim VPN -Server, im Router oder doch beim Bonding, dem Zusammenschalten von DSL und LTE zu einer Verbindung?
    Ich frage mich, an welcher Stelle entsteht nun mein Problem bei meiner VPN -Verbindung. Bei der Client-Software, im Client- PC, in der Verbindung zum Router bzw. Heinnetzwerk, beim VPN -Server, im Router oder doch beim Bonding, dem Zusammenschalten von DSL und LTE zu einer Verbindung?

    Wenn eine Anwendung über LTE und DSL getrennt jeweils einen guten Speed erreicht, dies im Bonding aber nicht der Fall ist, ist die Erklärung in den meisten Fällen auf der TCP-Ebene zu suchen.

    Ich kopiere dazu mal eine Erklärung aus einem anderen Thread:

    Wenn die Datenpakete, die über LTE an den Router gesendet werden, wesentlich länger brauchen als die Datenpakete, die über DSL an den Router geschickt werden (oder auch umgekehrt), greifen die Sicherheitsmechanismen des TCP-Protokolls. Dieses bemerkt die unterschiedlichen Laufzeiten der verschiedenen Datenpakete (Round Trip Time (RTT)), geht dann von Störungen im Netz aus und veranlasst den Versender der Daten (also z. B. den Server von dem Sie etwas runterladen) mit verringerter Geschwindigkeit zu senden. Der Versender weiß an dieser Stelle natürlich nicht, dass Sie eine bestimmte Rate stabil über DSL empfangen können, und regelt die Geschwindigkeit auch unter diesen Wert. Nach kurzer Zeit wird dann vom TCP-Protokoll bemerkt, dass die Daten wieder gleichmäßig ankommen und die Geschwindigkeit wird vom Versender schrittweise wieder erhöht ... bis LTE dazugeschaltet wird und der Mechanismus von vorne beginnt. Dies führt dann zu einer durchschnittlichen Geschwindigkeit, die unter dem DSL-Niveau liegt.

    Wenn die Datenpakete, die über LTE an den Router gesendet werden, wesentlich länger brauchen als die Datenpakete, die über DSL an den Router geschickt werden (oder auch umgekehrt), greifen die Sicherheitsmechanismen des TCP-Protokolls. Dieses bemerkt die unterschiedlichen Laufzeiten der verschiedenen Datenpakete (Round Trip Time (RTT)), geht dann von Störungen im Netz aus und veranlasst den Versender der Daten (also z. B. den Server von dem Sie etwas runterladen) mit verringerter Geschwindigkeit zu senden. Der Versender weiß an dieser Stelle natürlich nicht, dass Sie eine bestimmte Rate stabil über DSL empfangen können, und regelt die Geschwindigkeit auch unter diesen Wert. Nach kurzer Zeit wird dann vom TCP-Protokoll bemerkt, dass die Daten wieder gleichmäßig ankommen und die Geschwindigkeit wird vom Versender schrittweise wieder erhöht ... bis LTE dazugeschaltet wird und der Mechanismus von vorne beginnt. Dies führt dann zu einer durchschnittlichen Geschwindigkeit, die unter dem DSL-Niveau liegt.
    Wenn die Datenpakete, die über LTE an den Router gesendet werden, wesentlich länger brauchen als die Datenpakete, die über DSL an den Router geschickt werden (oder auch umgekehrt), greifen die Sicherheitsmechanismen des TCP-Protokolls. Dieses bemerkt die unterschiedlichen Laufzeiten der verschiedenen Datenpakete (Round Trip Time (RTT)), geht dann von Störungen im Netz aus und veranlasst den Versender der Daten (also z. B. den Server von dem Sie etwas runterladen) mit verringerter Geschwindigkeit zu senden. Der Versender weiß an dieser Stelle natürlich nicht, dass Sie eine bestimmte Rate stabil über DSL empfangen können, und regelt die Geschwindigkeit auch unter diesen Wert. Nach kurzer Zeit wird dann vom TCP-Protokoll bemerkt, dass die Daten wieder gleichmäßig ankommen und die Geschwindigkeit wird vom Versender schrittweise wieder erhöht ... bis LTE dazugeschaltet wird und der Mechanismus von vorne beginnt. Dies führt dann zu einer durchschnittlichen Geschwindigkeit, die unter dem DSL-Niveau liegt.



    Je nach TCP-Implementierung reagieren einge Anwendungen dann stärker auf diese Phänomen als andere.

    Viele Grüße
    Henning H.

    0

Das könnte Ihnen auch weiterhelfen

Beliebte Tags letzte 7 Tage

Cookies and similar technologies

We use cookies and similar technologies (including ) on our website to save, read out and process information on your device. In doing so, we enhance your experience, analyze site traffic, and show you content and ads that interest you. User profiles are created across websites and devices for this purpose. Our partners use these technologies as well.


By selecting “Only Required”, you only accept cookies that make our website function properly. “Accept All” means that you allow access to information on your device and the use of all cookies for analytics and marketing purposes by Telekom Deutschland GmbH and our partners. Your data might then be transferred to countries outside the European Union where we cannot ensure the same level of data protection as in the EU (see Art. 49 (1) a GDPR). Under “Settings”, you can specify everything in detail and change your consent at any time.


Find more information in the Privacy Policy and Partner List.


Use of Utiq technology powered by your telecom operator


We, Telekom Deutschland GmbH, use the Utiq technology for digital marketing or analytics (as described on this consent notice) based on your browsing activity across our websites (only if you are using a supported internet connection provided by a participating telecom operator and consent on each website).

The Utiq technology is privacy centric to give you choice and control.

It uses an identifier created by your telecom operator based on your IP address and a telecom reference such as your telecom account (e.g., mobile number).

The identifier is assigned to the internet connection, so anyone connecting their device and consenting to the Utiq technology will receive the same identifier. Typically:

  • on a broadband connection (e.g., Wi-Fi), the marketing or analytics will be performed based on the browsing activities of consenting household members’.
  • on mobile data, the marketing will be more personalised, as it will be based on the browsing of the individual mobile user only.

By consenting, you confirm that you have permission from the telecom account holder to enable the Utiq technology on this internet connection.

You can withdraw this consent anytime via "Manage Utiq" at the bottom of this site or in Utiq’s privacy portal (“consenthub”). For more, see Utiq's privacy statement.