News Streitgespräch auf Re:publica 25: Inwieweit die Telekom absichtlich das Netz verlangsamt

Piktogramm schrieb:
VPN wir dir immer die Latenzen erhöhen. Für minimierte Latenzen wäre herauszufinden, wo der nächste Exchange steht und bei welchem Anbieter du dir einen (dedizierten) VServer als privaten Endpunkt mieten kannst.
Latenzen sind nicht das Problem. Rein auf Latenz bezogen müsste ich das beste Erlebnis in Frankfurt haben, aber dem ist nicht so, es ist sogar das Schlechteste, trotz, je nach Zeit, mit 5-12 ms Ping.
Gerade in Counter Strike, alles was über Frankfurt läuft oder geroutet wird, laggt wie die Pest. Nach Warschau über Frankfurt = Lag, direkt nach Frankfurt = Lag. Über Amsterdam nach UK, alles super. Von Paris nach Frankfurt, geht auch.
Sprich, selbst mit 40-50ms Ping habe ich das bessere Erlebnis.
In Zahlen betrachtet, dürfte man einen Ping von 5-12ms überhaupt nicht wahrnehmen können als Mensch, trotzdem kann ich ständig zugucken, wie viele Tage es braucht, bis endlich mal der Kill confirmed wird, wenn ich überhaupt reagieren durfte, weil der Gegner wieder mal unsichtbar war als er um die Ecke kam für mehrere Frames, als hätte ich Vsync an.
Genauso mit 40-50ms, das ist schlicht und ergreifend noch zu wenig um es bemerken zu dürfen. Das fängt erst ab 80ms an, wo man langsam Zweifel bekommt.
 
fdsonne schrieb:
@WetMar
und deine besagte Seite uupdump.net?
100ms und mehr und über den Atlantik?
Ping.png
 

Anhänge

  • ipv6_01.png
    ipv6_01.png
    14,9 KB · Aufrufe: 120
  • ipv6_02.png
    ipv6_02.png
    20,9 KB · Aufrufe: 121
  • ipv4_02.png
    ipv4_02.png
    15,9 KB · Aufrufe: 123
  • ipv4_01.png
    ipv4_01.png
    20,6 KB · Aufrufe: 121
  • Gefällt mir
Reaktionen: lynx007 und Piktogramm
eax1990 schrieb:
Wenn das Thema aktuell schon so passt, kennt denn Jemand einen VPN Anbieter der fürs Peering gut zahlt oder ein Routing nutzt, welches die gesamte Telekom ausklammert und beim Thema Gaming die Probleme anpackt?
Ich lese oft davon, dass Proton-VPN gut sein soll.
An deiner Stelle würde ich aber den ISP/Anbieter wechseln, wenn es eine Alternative in deiner Gegend gibt.

OpticalFiber schrieb:
Mit Leuten habe ich mich unterhalten von den anderen Ländern, sie sagen wenn (die Anbieter nicht ausbauen oder in ihre Netzwerke investieren muss der Staat sehr hart durchgreifen, ganz einfach ist das, wieso funktioniert das bei uns und in Deutschland nicht).
OpticalFiber schrieb:
Wieso greift nicht der Staat ein, der Telekom mit saftigen Geldstrafen in Milliarden Höhen.
Weil der "Staat" ungefähr 40% der Telekom-Aktien hält.
Die nächste Gewinnausschüttung würde da sicherlich geringer sein, wenn sie der DT-Kom Strafen aufbrummen. Sie verdienen (vermutlich) direkt daran. 😉
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: lynx007
Viele Beiträge hier sind logisch nicht nachvollziehbar, da Autoren die Bedeutung von "scheinbar" anscheinend nicht kennen.
 
  • Gefällt mir
Reaktionen: h_calenberg
Code:
ping computerbase.de
PING computerbase.de (212.83.33.137) 56(84) Bytes an Daten.
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=1 ttl=54 Zeit=29.0 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=2 ttl=54 Zeit=29.6 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=3 ttl=54 Zeit=28.8 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=4 ttl=54 Zeit=27.1 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=5 ttl=54 Zeit=34.0 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=6 ttl=54 Zeit=30.4 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=7 ttl=54 Zeit=27.8 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=8 ttl=54 Zeit=31.5 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=9 ttl=54 Zeit=28.5 ms
64 Bytes von www.computerbase.de (212.83.33.137): icmp_seq=10 ttl=54 Zeit=31.4 ms
--- computerbase.de Ping-Statistiken ---
10 Pakete übertragen, 10 empfangen, 0% packet loss, time 21033ms
rtt min/avg/max/mdev = 26.911/29.792/34.022/2.065 ms

Code:
traceroute computerbase.de
traceroute to computerbase.de (212.83.33.137), 30 hops max, 60 byte packets
 1  _gateway (192.168.188.1)  1.099 ms  1.416 ms  1.805 ms
 2  fritz.box (192.168.178.1)  18.440 ms  18.494 ms  18.543 ms
 3  100.75.96.20 (100.75.96.20)  32.947 ms  33.058 ms  33.166 ms
 4  s-ltrz-101-v31.net.encoline.de (5.102.167.41)  33.706 ms  38.398 ms  38.458 ms
 5  s-er-102-l6.net.encoline.de (5.102.167.200)  39.059 ms  41.525 ms  41.609 ms
 6  r-er-09-l0.net.encoline.de (5.102.166.251)  43.578 ms  43.578 ms  43.421 ms
 7  r-fra-02-l0.net.encoline.de (5.102.166.241)  50.627 ms  29.075 ms  50.705 ms
 8  ae0-500.fra20.core-backbone.com (80.255.15.145)  37.145 ms  37.206 ms  37.263 ms
 9  decix.bb01.net.23m.com (80.81.195.255)  47.174 ms  32.375 ms  33.132 ms
10  ae1-0.gw01.fra01.net.23m.com (62.113.192.66)  35.284 ms  35.321 ms ae2-0.gw02.fra01.net.23m.com (62.113.192.88)  36.452 ms

Code:
ping uupdump.net
PING uupdump.net (172.67.140.132) 56(84) Bytes an Daten.
64 Bytes von 172.67.140.132: icmp_seq=1 ttl=55 Zeit=31.4 ms
64 Bytes von 172.67.140.132: icmp_seq=2 ttl=55 Zeit=29.0 ms
64 Bytes von 172.67.140.132: icmp_seq=3 ttl=55 Zeit=27.4 ms
64 Bytes von 172.67.140.132: icmp_seq=4 ttl=55 Zeit=31.1 ms
64 Bytes von 172.67.140.132: icmp_seq=5 ttl=55 Zeit=35.3 ms
64 Bytes von 172.67.140.132: icmp_seq=6 ttl=55 Zeit=27.4 ms
64 Bytes von 172.67.140.132: icmp_seq=7 ttl=55 Zeit=33.8 ms
64 Bytes von 172.67.140.132: icmp_seq=8 ttl=55 Zeit=29.6 ms
64 Bytes von 172.67.140.132: icmp_seq=9 ttl=55 Zeit=27.5 ms
64 Bytes von 172.67.140.132: icmp_seq=10 ttl=55 Zeit=32.4 ms
--- uupdump.net Ping-Statistiken ---
10 Pakete übertragen, 10 empfangen, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 27.405/30.479/35.295/2.646 ms

Code:
traceroute uupdump.net
traceroute to uupdump.net (172.67.140.132), 30 hops max, 60 byte packets
 1  _gateway (192.168.188.1)  0.767 ms  1.196 ms  1.502 ms
 2  fritz.box (192.168.178.1)  19.468 ms  19.523 ms  19.570 ms
 3  100.75.96.20 (100.75.96.20)  37.357 ms  29.433 ms  37.411 ms
 4  s-ltrz-101-v31.net.encoline.de (5.102.167.41)  37.528 ms  37.454 ms  37.648 ms
 5  s-er-102-l6.net.encoline.de (5.102.167.200)  37.730 ms  39.208 ms  42.277 ms
 6  r-er-09-l0.net.encoline.de (5.102.166.251)  42.331 ms  45.001 ms  44.584 ms
 7  r-jes-07-e1-1001.net.encoline.de (5.102.167.28)  44.448 ms  28.536 ms  28.573 ms
 8  r-ber-01-l0.net.encoline.de (5.102.166.242)  35.026 ms  35.344 ms  28.844 ms
 9  cloudflare.bcix.de (193.178.185.17)  54.862 ms  54.963 ms  55.050 ms
10  172.67.140.132 (172.67.140.132)  36.954 ms  37.014 ms  39.140 ms

... und per Live Server Terminal:

Code:
.Server created on 19:20 30-05-2025 UTC. Powered by https://aeza.net hosting.
root@377d8b:~# traceroute computerbase.de
traceroute to computerbase.de (212.83.33.137), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.054 ms  0.074 ms  0.040 ms
 2  fra1-core.aeza.network (109.120.149.25)  0.164 ms  0.154 ms  0.171 ms
 3  10.61.215.49 (10.61.215.49)  0.227 ms  0.119 ms  0.114 ms
 4  core01.ffm1.de.aurologic.net (45.138.175.171)  0.418 ms  0.361 ms  0.338 ms
 5  * * *
 6  ae0-core01.core02.ffm5.de.aurologic.net (45.138.175.136)  1.390 ms 100.64.10.110 (100.64.10.110)  1.109 ms ae0-core01.core02.ffm5.de.aurologic.net (45.138.175.136)  1.413 ms
 7  87.119.95.132 (87.119.95.132)  0.494 ms ae0-core01.core02.ffm5.de.aurologic.net (45.138.175.136)  1.564 ms 87.119.95.132 (87.119.95.132)  0.469 ms
 8  fra-eq6-tr1.zet.net (103.246.249.28)  0.822 ms  0.818 ms ae22.cr11-fra2.ip4.gtt.net (89.149.180.226)  1.002 ms
 9  fra-eq6-tr1.zet.net (103.246.249.28)  0.783 ms  0.812 ms *
10  62.67.110.46 (62.67.110.46)  1.244 ms be5970.ccr42.fra05.atlas.cogentco.com (154.54.59.54)  1.449 ms  1.364 ms
11  62.67.110.46 (62.67.110.46)  1.210 ms * ae1-0.gw01.fra01.net.23m.com (62.113.192.66)  1.136 ms
12  be4167.nr21.b015759-0.fra06.atlas.cogentco.com (154.25.3.178)  7.256 ms ae1-0.gw01.fra01.net.23m.com (62.113.192.66)  1.200 ms be4167.nr21.b015759-0.fra06.atlas.cogentco.com (154.25.3.178)  7.696 ms
13  * * 149.11.20.223 (149.11.20.223)  1.470 ms
14  * ae1-0.gw01.fra01.net.23m.com (62.113.192.66)  1.225 ms *

Code:
root@377d8b:~# traceroute uupdump.net
traceroute to uupdump.net (104.21.49.32), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.066 ms  0.034 ms  0.032 ms
 2  fra1-core.aeza.network (109.120.149.25)  0.264 ms  0.239 ms  0.248 ms
 3  10.61.215.49 (10.61.215.49)  0.281 ms  0.283 ms  0.258 ms
 4  185.0.27.4 (185.0.27.4)  13.455 ms  13.612 ms  13.587 ms
 5  162.158.84.159 (162.158.84.159)  1.117 ms 162.158.84.185 (162.158.84.185)  3.300 ms  3.265 ms
 6  104.21.49.32 (104.21.49.32)  1.046 ms  1.061 ms  1.050 ms

@WetMar
Sieht bei mir anders aus als bei dir. Was sagt das jetzt aus?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: lynx007
fdsonne schrieb:
Wie erwähnt, was ist mit der naheliegensten Methode, dass die Telekom hier einfach Cloudflare US IPs eben in Amerika ins Netz lässt? Und das hier einfach nur im DNS die falsche IP eingetragen wurde?
Das wäre für mich nicht die naheliegenste Methode, um zu einem CDN zu routen, sondern die mit Abstand denkbar dämlichste Methode. Bei einem CDN gibt es doch gerade keine US-IPs oder EU-IPs mehr. Der ganze Sinn von CDNs ist doch, dass man immer einen Mirror hat, der nahe am Endkunden liegt. Dann sollte der Endkunden-Provider logischerweise auch möglichst nah am Endkunden in das CDN-Netz übergeben?!
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Zumal der Staat, genauer gesagt die Bundesrepublik Deutschland (Wir) und die KfW, aktuell gemeinsam 27,8 % der Anteile an der Deutschen Telekom besitzen. Davon entfallen 13,8 % direkt auf den Bund und 14 % auf die KfW.
Somit ist die Telekom uns Rede und Auskunft Pflichtig, ich meine Wir bezahlen Steuern und die Telekom profitiert davon.
 
Piktogramm schrieb:
Wenn eine Spedition mit Geld abnimmt für einen Transport und dann am Endpunkt nochmals Geld zur Erfüllen des selben Transportauftrags will, könnte man der Spedition privatrechtlich den Arsch aufreißen. Wäre das in eine Spedition in einer marktdominierenden Stellung und würde das systematisch betreiben, wäre staatlicher Verbraucherschutz handlungsfähig.
Ganz abgesehen davon, dass die Gesetzgebung zur Netzneutralität da auch eindeutig ist. Es ist ja nicht so, als hätten div. Provider damit nicht bereits Erfahrung gemacht.
Unpassendes Beispiel - die eine Seite wird bezahlt um den Zugang bereit zu stellen, die andere Seite wird für Transit bzw. Traffik gebeten zu bezahlen. Und das scheint zumindest nach Aussage der Telekom gängige Praxis zu sein, dass man dort für ungleiches Volumen, also mehr Up wie Down bzw. umgekehrt eben die Hand auf hält. Was durchaus Sinn ergibt, weil wo kommen wir hin wenn Dritte in dein Netz einfach Bandbreitenlastig Traffik einleiten und an einem anderen Ort wieder ausleiten und du als Anbieter dafür zu zahlen hast?
Piktogramm schrieb:
https://www.telekom.de/produktinformationsblatt/magentazuhause-l-2-vdsl-100
Die Tkom schreibt selber, dass es sich um einen Internet-Zugang handelt und nicht um ein T-Netzzugang. Keine Ahnung, was du dir hier herbei fantasierst. Die Langversion vom Vertrag ändert da auch wenig dran.
Einfach auch mal die Kirche im Dorf lassen. Wie bitte soll dir ein Internet Anbieter zu jeder erdenklichen IP im Netz die Bandbreite garantieren, die du in deinem Vertrag stehen hast!?
Das ist technisch schlicht unmöglich... Das ganze Argument ist also quatsch, wenn man meint dass nur weil man da ne Bandbreite stehen hast, dem ISP das für alle erdenklichen Endpunkte aufdrücken kann.

Und ja, die Telekom ist da als quasi Monopolist und Erbe der alten Post Infrastruktur sogar noch in einer gewissermaßen höheren Verantwortung ggü. kleineren ISPs. Aber auch die können das technisch nicht gewährleisten, weil es technisch nicht möglich ist.
Piktogramm schrieb:
De-CIX hat mehrere Standorte und nirgends in Deutschland lebt man so weit ab vom Schuss, dass nicht in <200km der nächste Exchange steht. Einzig in Berlin/Brandenburg sollte man ein paar Anschlüsse im BCIX buchen.
Das ist doch aber völlig egal für die Aussage!? Je nach Endpunkt ist es total egal, ob irgendwo anders noch andere DE-CIX Knoten existieren, weil bspw. www.computerbase.de eine Single IP in Frankfurt bei 23M betreibt. Was bringt deine Aussage in dem Zusammenhang? Von hier aus sind es 400km bis Frankfurt. Und das macht ungefähr 10ms aus. Von Nürnberg sind es deutlich weniger Strecke, das resultiert in ca. 3-4ms.

Die Aussage da oben war, das die Masse letztlich in Frankfurt peert. -> das behebt das Problem exakt gar nicht. Frankfurt Peering und dann trotzdem über Cloudflare US Systeme geschickt machen auch 100ms aus. Einfach wegen der Strecke.

Piktogramm schrieb:
Ja, gegen im Vergleich zu public Exchanges deutlich gesteigerten Kosten, das ist die Kritik am Konzern. -.-
Dann kritisiert man das halt - letztlich ist das doch deren Entscheidung!? Oder willst du hier einen Zwang auferlegen und ihnen das Recht dazu absprechen?
Piktogramm schrieb:
Ja sollte man als Kunde, oder wenigstens den ISP wechseln. Ich zahle doch nicht den teuerstem Anbieter im Lande für Internet, damit der Konzern mich als Kunde als Argument hernimmt um den Services die ich erreichen will nochmals Geld abzunehmen (oder sie halt auszubremsen)
Dann tue das - wechselt alle, am Ende sorgt das ggf. für den notwendigen Drang dass sich die Telekom da etwas bewegt. Aber immer nur meckern und die Schuld irgendwo suchen um dann am Ende doch nicht zu wechseln? (ist jetzt keine Unterstellung dir ggü. - ich kenne deine Situation nicht)
Es ist nur irgendwie auffällig, dass alle über die Telekom schimpfen, vor allem in den Foren, aber tortzdem am Ende die Masse eben Telekom Anschlüsse bucht. Das ist irgendwie unverständlich...
Piktogramm schrieb:
Die Tkom ist sowieso der teuerste Anbieter, es ist schon reichlich vermessen denen Einnahmenmangel zu unterstellen, wenn günstigere Anbieter das mit dem Peering besser hinbekommen.
Du hast die Aussage nicht verstanden. Niemand unterstellt "Einnahmemangel" - es ging argumentativ um den Umstand, dass die Möglichkeit dem ISP Kosten aufzudrücken dazu führt, dass Dritte diesen Umstand ausnutzen können. Es kann nicht das ISP Problem sein, wenn ein Kontent Anbieter aufgrund von einseitiger Endkunden Nachfrage für Kosten sorgt, die dann argumentativ dem ISP dazwischen aufgedrückt werden.

Cloudflare als Instanz zwischen zu schalten ist letztlich das Bier Kontent Anbieter. Und wer außer dieser sollte damit die Kosten tragen, wenn damit ISP Seitig Mehraufwände erzeugt werden?
Piktogramm schrieb:
Wenn man ein Rechenzentrum und/oder Vergleichbares betreibt muss man sich schon selber Fasern legen lassen, oder wenigstens den Anschluss bestehender, dunkler Fasern bezahlen. Insofern zahlt jeder Dienst seine Kosten für Infrastruktur selbst, da springt keine Tkom heldenhaft ein, die halten allenfalls die Hand auf, wenn die Fasern ihnen gehören.
Na es wäre ja schön wenn es so wäre ;)

Wieso wird noch gleich so oft die Verbindung von Telekom zu Cloudflare kritisiert!? Weil Cloudflare als Mittelsmann so viel dafür tut, dass ihre Systeme auch überall und immer so toll angebunden sind?
Oder wo ist deren Arangement in der Richtung als RZ Betreiber selbst für die Fasern zu sorgen und jeder Dienst muss für die Kosten selbst aufkommen? Äh Moment, das versuchst du doch gerade dem ISP aufzudrücken? Mhhhh

Piktogramm schrieb:
Das ähnelt irgendwie sehr dem Prinzip, dass Endkunden für Bereitstellung von Infrastruktur monatlich Geld berappen..
Nur die Telekom will dann halt nochmals Geld dafür, dass man zu ihnen peert. Zu Beträgen die deutlich(!) höher sind als die Kurse, die das De-CIX in Frankfurt haben will (als Hetzner die Option hatte für Tkom Peering als Serverbetreiber selber zu löhnen war es Faktor 4..5).
Mir scheint als würdest du Ursache und Maßnahme vertauschen.
Will die Telekom das Geld weil sie doppelt abkassieren will oder will sie vielleicht eher das Geld, weil andere Einseitig dort Dinge fabrizieren, die sie selbst nicht anders könnten?
Piktogramm schrieb:
Dein Gerechtigkeitsempfinden scheint sehr in Richtung: Der arme Konzern MUSS UNBEDINGT viel mehr Geld an Dienstleistungen verdienen, die es wo anders günstiger gibt. Das ist lächerlich.
Da ist dein Textverständnis aber leider ziemlich kaputt. Weil das ist bei weitem nicht mein Empfinden. Mir persönlich ist es doch Jacke wie Hose, was die Telekom da macht.

Ich hinterfrage aber manche Aussagen hier, weil Pausch immer feste drauf auf die Großkonzerne heuer ziemlich in Mode ist. Was ich in dem Zusammenhang aber nicht verstehe - warum man auf den hiesig hierzulande ansässigen Konzern drauf kloppt und nicht mal in die andere Richtung blickt. Wo wir uns bestimmt einig sind, dass das nicht Endkunden-Thema sein sollte.
Aber pauschal dem ISP die ganzen Dinge aufdrücken? -> mMn gehört hier der Kontentanbieter ins Boot und vor allem in die Kostenthematik mit einbezogen. Schau einfach mal auf Cloudflare was da so die Top10 an Traffik ist. Das bisschen Webseiten Traffik irgendwelcher Server ist das bei weitem nicht. Da stehen die Tech-Riesen ganz oben.
Piktogramm schrieb:
Der Anbieter zahlt für seine Leitung bis nach Frankfurt, und für den/die Ports im öffentlichen Xchange. Nur halt dort ein Vielfaches weniger als bei der Tkom. Die verweigert sich an der kosteneffizienten Variante teilzunehmen um Mehreinnahmen zu generieren.
Das Problem ist doch an ganz anderer Stelle gelagert. Was bringt mir die Strippe nach Frankfurt, wenn in Deutschland der Maßgebliche Teil der Endkunden nicht über Frankfurt mit dem Angebot angebunden werden kann bzw. angeboten wird!?

Natürlich kann ich als Endkunde schimpfen - aber das behebt doch das Problem nicht?
 
Fragger911 schrieb:
(einige TB aufwärts für die grundsätzlichsten Weltdaten)

Naja, wen ich mir eine Leitung von der Telekom hole, dann kann ich schon davon ausgehen das die Bandbreite ankommt! Aber das kann jeder einklagen! Ich glaube an keine Drosselung. Weil dann direkt die Wutbürger ihre Rechtschutz einschalten würden. Früher konnte man nichts machen. Mitlerweile steht aber einem eine Bindesbandbreite zur verfügung. Natürlich nicht 24/7. Weil ein Netzt kann immer gestört oder überlastet sein.

In der Regel liegt es nur daran das man scheiß Kupferkabel hat. Also an der schlechten Infrastruktur vorort, leider.

Aber das weiß man vorher, bevor man Flightsimmulator streamt. Das TB zuviel zum runterladen wären, halte ich für eine Ausrede! Es geht da eher um Kontrolle durch Online Zwang. So wie Azure, oder Adobe Cloud. Das lässt sich schlechter Raubkopieren. TB Festplatten gibts wie Sand am mehr mitlerweile! Und en man ehrlich ist, das kostet VR, Joystick usw, wen es was vernünftiges sein soll nicht weniger... Also bei ner echten "Cockpit Ausstattung" würden die 150 bis 200€ auch nicht mehr weht tun.

Da geht es eher darum einen Dienst anzubieten! und das schöne an nem Streamingdienst ist, man schön alle kontrollieren und monetarisieren. Wen irgendwan nichts mehr aus der Frucht kommt, und eine Nachfolgerversion da ist, schaltet man einfach den Dienst ab. :evillol: :evillol: :evillol: :evillol: Gerade MS ist sehr stark darin die AGBs zu ungunsten des Kunden umzuschreiben.



1748634268493.png
 
Weyoun schrieb:
Das bedeutet im Klartext, mit kleinem DSL-Vertrag (16 MBit/s) kann man das Spiel komplett vergessen. :grr:

Nicht komplett, Minimum sind 10 Mbit, aber es schränkt Auflösung und Detailgrad ein.
 
  • Gefällt mir
Reaktionen: Weyoun
Web-Schecki schrieb:
Der ganze Sinn von CDNs ist doch, dass man immer einen Mirror hat, der nahe am Endkunden liegt. Dann sollte der Endkunden-Provider logischerweise auch möglichst nah am Endkunden in das CDN-Netz übergeben?!
Jein - das wäre eher der Sinn einer AnyCast IP. Also dass die immer selbe IP eben an verschiedenen Stellen im Netz möglichst gut zu erreichen ist. Bekanntes Beispiel ist die 8.8.8.8 -> egal von wo aus du die erreichen möchtest, du landest in aller Regel bei dem dir am nähesten zugewiesenen System.


Das was Cloudflare bspw. macht ist aber nicht zwingend das gleiche - sie nutzen in Teilen zwar auch AnyCast IPs um das so zu erreichen, dass diese Endpunkte lokal erreichbar sind. Aber dennoch muss es ja einen Unterschied geben, warum manche Cloudflare IPs eben über US und andere eben über lokal viel nähere Einstiegspunkte erreichbar sind.

Was witzig ist - dreh im DNS die IP manuell auf die für dich nähere und der Kontent kommt in schnell. Sprich das ist also nichtmal ein Weg, der real praktisch verbaut ist, sondern das ist ein Zustand, den offenbar eine der Parteien exakt so haben möchte. Entweder der, der den DNS auf exakt die IP setzt oder eben Cloudflare <> Telekom in dem Fall.
 
Tanzmusikus schrieb:
Code:
traceroute uupdump.net
traceroute to uupdump.net (172.67.140.132), 30 hops max, 60 byte packets
 1  _gateway (192.168.188.1)  0.767 ms  1.196 ms  1.502 ms
 2  fritz.box (192.168.178.1)  19.468 ms  19.523 ms  19.570 ms
 3  100.75.96.20 (100.75.96.20)  37.357 ms  29.433 ms  37.411 ms
 4  s-ltrz-101-v31.net.encoline.de (5.102.167.41)  37.528 ms  37.454 ms  37.648 ms
 5  s-er-102-l6.net.encoline.de (5.102.167.200)  37.730 ms  39.208 ms  42.277 ms
 6  r-er-09-l0.net.encoline.de (5.102.166.251)  42.331 ms  45.001 ms  44.584 ms
 7  r-jes-07-e1-1001.net.encoline.de (5.102.167.28)  44.448 ms  28.536 ms  28.573 ms
 8  r-ber-01-l0.net.encoline.de (5.102.166.242)  35.026 ms  35.344 ms  28.844 ms
 9  cloudflare.bcix.de (193.178.185.17)  54.862 ms  54.963 ms  55.050 ms
10  172.67.140.132 (172.67.140.132)  36.954 ms  37.014 ms  39.140 ms


Tanzmusikus schrieb:
Sieht bei mir anders aus als bei dir. Was sagt das jetzt aus?

Das du...
1. Ne extrem große Latenz zu deinem Hauptrouter hast (fritz.box), weil du offenbar einen 2. Router als Repeater einsetzt. (Die meisten haben weniger zu den meisten Webseiten, als du alleine zu deiner FritzBox.)
2. Das du nicht bei der Telekom bist, sondern bei der Thüringer Netkom, die offenbar besseres Peering zu Cloudflare als die Telekom hat, erkennt man an der Latenz zu uupdump.net.
 
  • Gefällt mir
Reaktionen: Redundanz, konkretor, WetMar und eine weitere Person
Piktogramm schrieb:
Wenn eine Spedition mit Geld abnimmt für einen Transport und dann am Endpunkt nochmals Geld zur Erfüllen des selben Transportauftrags will, könnte man der Spedition privatrechtlich den Arsch aufreißen.
Schlechter Vergleich. Die Straßen würden besser passen und dafür müssen ja alle angeschlossenen Kunden & Firmen zahlen.
Piktogramm schrieb:
Wäre das in eine Spedition in einer marktdominierenden Stellung und würde das systematisch betreiben, wäre staatlicher Verbraucherschutz handlungsfähig.
Da quasi alle Kunden auch Alternativen haben würde ich hier kein Problem sehen, was nicht auch ohne Marktbeherrschung besteht.
Piktogramm schrieb:
Ganz abgesehen davon, dass die Gesetzgebung zur Netzneutralität da auch eindeutig ist. Es ist ja nicht so, als hätten div. Provider damit nicht bereits Erfahrung gemacht.
Dann wirds wohl mal Zeit, das da jemand klagt.
Piktogramm schrieb:
Die Tkom ist sowieso der teuerste Anbieter, es ist schon reichlich vermessen denen Einnahmenmangel zu unterstellen, wenn günstigere Anbieter das mit dem Peering besser hinbekommen.
Wobei sie ihre Ausgaben vielleicht in andere Bereiche lenken, die günstigere Anbieter eher vernachlässigen. Sprich: Hat alles Vor- & Nachteile.
Piktogramm schrieb:
Der Anbieter zahlt für seine Leitung bis nach Frankfurt, und für den/die Ports im öffentlichen Xchange. Nur halt dort ein Vielfaches weniger als bei der Tkom.
Wobei eine Anbindung nach Frankfurt je nach Distanz schon auch massiv Kosten verursachen kann, da kann ein Peering woanders, evtl. selbst mit einer Telekom, in der Nähe günstiger sein.
Ergänzung ()

Tanzmusikus schrieb:
Weil der "Staat" ungefähr 40% der Telekom-Aktien hält.
Laut Wiki nur noch ~28%, aber ja, das ist noch nennenswert.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
fdsonne schrieb:
Aber dennoch muss es ja einen Unterschied geben, warum manche Cloudflare IPs eben über US und andere eben über lokal viel nähere Einstiegspunkte erreichbar sind.
Naja, ich kann diese Unterscheidung bei cloudflare nicht beobachten: Habe für uupdump.net ein vier verschiedene Netze getestet, in denen ich Endpunkte habe (alle in DE). Per DNS bekomme ich immer dieselben beiden IPv4-Adressen und auch dieselben beiden IPv6-Adressen.
Die Endpunkte erreiche beide von allen Standorten in unter 15ms. Am schnellsten schafft es mein ionos-vServer in Berlin mit ~0.6ms.
Die Latenzen zu notebookcheck.com sind übrigens jeweils identisch, auch wenn es andere IPs sind. Die traceroutes sehen auch identisch aus.

Von US-IPs oder EU-IPs also keine Spur. Klar, es wäre möglich, per DNS je nach Herkunfts-IP eine andere IP auszuliefern, aber es sieht mir nicht danach aus, als würde cloudflare das tun. Und wenn du bei der Telekom auch die beiden IPv4-Adresse 172.67.140.132 und 104.21.49.32 bekommst und die trotzdem in den USA übergeben werden, dann ist an der Stelle das routing einfach extrem beacheuert. Und die Frage ist halt, wieso? Announced cloudflare gegenüber der Telekom sinnlose routen, die ihrem Geschäftsziel (Server in Endkundennähe antwortet) widersprechen?

Ja, es gibt keine Beweise, dass die Telekom an allem Schuld ist. Vielleicht haben sich auch die großen CDNs gegen die arme kleine Telekom verschworen, klar. Aber es ist schon komisch, dass niemand sonst hierzulande irgendwo in den USA ins cloudflare-Netz übergeben wird, außer Telekomkunden?
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Lurtz
@arvan
Danke für die Erklärung!
Bin von der teuren Thüringer Netkom enttäuscht. Sie bietet nur IPv4-only & ist teurer als die Telekom.
Zusätzlich ist die FN-Telefonie zum Mobilfunk nicht enthalten wie bei der Telekom, O², und andere ISPs.

Zur Telekom wechseln möchte ich aber auch nicht - gerade wegen dieser Peering-Probleme.
Momentan nutzt ich die Leitung meiner Familie mit. Bin eh kaum zu Hause.
GF soll es ggf. im Herbst geben, aber daran glaube ich nicht. Mir würde außerdem auch 100/40er DSL-Anschluss reichen. Bei 1&1 usw. könnte ich momentan leider nur DSL 16 buchen.

Oh, sehe gerade: O² bietet hier immerhin DSL Edit: LTE 50/10 an. Das wäre dann auch eine Option.
Da wäre sogar ein Tarif mit monatlicher Kündigungsfrist für 35 € möglich (inkl. Telefon-Flat in alle deutschen Netze).

Edit: Ist leider ein LTE-Vertrag. "Irgendeine Kröte muss man wohl immer schlucken." 😆
 

Anhänge

  • Bildschirmfoto_2025-05-30_23-29-04.png
    Bildschirmfoto_2025-05-30_23-29-04.png
    131,3 KB · Aufrufe: 133
  • Bildschirmfoto_2025-05-30_23-36-00.png
    Bildschirmfoto_2025-05-30_23-36-00.png
    191,8 KB · Aufrufe: 132
Zuletzt bearbeitet:
Tanzmusikus schrieb:
Oh, sehe gerade: O² bietet hier DSL 50/10 an. Das wäre dann ja auch eine Option
Im Screenshot ist deine vollständige Adresse zu sehen. Die 50 Mbit/s von o2 werden über 5G/LTE realisiert, DSL ist auch hier mit maximal 16 Mbit/s verfügbar.
Die Telekom selbst bietet bei dir auch nur mehr als 16 Mbit/s an, weil sie sich über ihre Regio-Tarife ins Netz der NetKom einmietet.
Wenn es sonst kein Coax oder Glasfaser bei dir gibt, bist du was die Anbieterauswahl angeht, schon sehr eingeschränkt.
 
  • Gefällt mir
Reaktionen: OpticalFiber und Tanzmusikus
Danke dir!! Hab die Adresse entfernt.

GF soll theoretisch Ende September (also Oktober) verfügbar sein.
Das kann aber auch erst Jahre später fertig sein. 😉

KD/VF gibt's anscheinend nicht. Bin eh kein Fan von.
DSL oder GF wären meine Favoriten.
 
Zurück
Oben