Welche Schritte haben Sie unternommen, um das Problem zu lösen?
Wir haben mehrere Domains auf einem Free-Plan, um rudimentäre Sicherheitsfunktionen von Cloudflare zu nutzen, nachdem wir mit anderen Domains, die auf einem Pro Plan laufen, sehr zufrieden gewesen sind. Jetzt haben wir bei der Weiterentwicklung und Optimierung der Webseiten festgestellt, dass diese von unserem Business Telekom DSL-Anschluß kaum noch nutzbar gewesen sind. Anfangs war das nicht so, aktuell ist es aber leider so. Die Pro-Plan-Domains hatten diesbezüglich nie Probleme. Jetzt haben wir einen Free Plan ebenfalls auf einen Pro Plan angehoben und schon ist die Domain aus dem Telekom-Netz wunderbar nutzbar. Von einem Backup-Vodafone Kabelanschluss mit derselben Bandbreite wie der Telekom DSL-Anschluss gab es überhaupt keine Unterschiede in den Ping-Laufzeiten (Free-Plan und Pro-Plan gleiche Pingzeiten).
Hier mal die signifikanten Unterschiede im Telekom-Netz:
Hast du vernünftige Cache-Regeln angelegt? Meine deutsche Seite (https://baltic-labor.de) ist aus dem DTAG-Netz vernünftig erreichbar. Allerdings habe ich, genau wie du, eine ordentliche Portion “Lahmheit” festgestellt, bis ich eine “Cache Everything”-Regel für alle statischen Inhalte angelegt habe. Es gibt unter den Cache-Regeln eine Vorlage für “Cache Everything”. Man kann da noch URL-Regeln für dynamische Inhalte einfügen. Kann ich nur empfehlen das mal auszuprobieren.
Hat nichts mit irgendwelchen Einstellungen zu tun. Wenn ich deine Seite anpinge, habe ich folgende Antwortzeiten:
35 packets transmitted, 35 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 103.021/104.158/116.100/2.929 ms
Wenn du zum Vergleich mal deine direkte IP vom Server/Webhoster anpingst, solltest du einen vergleichbar sehr viel niedrigeren Wert erhalten, wenn dein Server/Webhoster ordentlich angebunden ist.
Bei meinen Seiten reden wir von Faktor 10 beim Ping-Verhalten und dazu entsprechend hohes Packetloss.
Möchtest du deinen Ping optimieren oder die Antwortzeit von HTTP-/HTTPS-Anfragen? Cloudflare ist für letzteres zuständig, dein Ping und das dahinterstehende ICMP-Protokoll hat damit nicht viel zu tun… Wie sehen HTTP(S) Anfragen zu deiner Seite aus? Also gemessen an relevanten Faktoren, wie Zeit bis zum ersten Byte (TTFB) oder ähnliche Metriken aus? Kann natürlich sein, dass du eine Seite betreibst, die deine Nutzer nur anpingen, dann ist das natürlich egal…
@kf5obs Firefox Devtools: Verbindungsaufbau und TLS-Aushandlung je ~100-110ms, dann ~300ms für die Datenübertragung von 1,46 KB, insgesamt 582ms. Habe dann testweise die aufgelöste IP von discord[.]com genommen und in meine Hosts-Datei für meine Free-Domain eingetragen. DNS-Cache geleert (about:networking#dns) und über die Discord-IP erreiche ich meine Free-Domain mit Verbindungsaufbau 20ms, 31ms TLS-Aushandlung und dann noch 51ms für Daten, insgesamt 104ms. Nehme ich es wieder raus aus der hosts-Datei und leere den DNS-Cache, bin ich wieder bei 100ms+.
Caching reduziert davon nur die Zeit, in der der Cloudflare-Server in den USA die Daten von meinem Server in Frankfurt abrufen muss - auf Daten warte ich dann nur ~130ms statt 300ms.
Verbindungsaufbauzeit deckt sich mit dem Ping aus traceroute. Eine andere Cloudflare-Free Domain (von wem anders) wurde ebenfalls über NYC (USA) geroutet, während das tracerouting bei zahlenden Cloudflare-Kunden, wie zB. spigotmc.org, discord.com oder auch cloudflare.com und 1.1.1.1 Deutschland nicht verlässt.
Ich persönlich habe jedoch keine Paketverlust festgestellt. Allgemein werden Ping-Pakete von überlasteten Routern sicher zuerst weggeworfen, daher halte ich das nicht für explizit aussagekräftig.
Ich weiß nur nicht, warum das angeblich an der DTAG liegen soll. Genau die Implikation, dass es am DTAG Peering liegt, gibt es ja hier im Forum und anderswo zu Genüge. Wenn die bezahlte Version von Cloudflare jedoch einwandfrei funktioniert, die kostenlose Version da jedoch Probleme macht, ist es schon mutig auf die DTAG zu zeigen…
Ich habe jetzt selbst mal ein wenig herumgespielt und dazu einen Cloudflare Loadbalancer mit proximity genommen. Proximity steering sollte heißen, dass Besucher aus der EU auf einem Server in DE landen sollen und Besucher aus den USA entsprechend auf einem US Server. Meine bezahlte Domäne (High Frequency Projects Blog) zeigt das erwartete Verhalten korrekt. Aus DE aufgerufen landet man beim DE Server und aus den USA aufgerufen auf dem US Server. Das funktioniert von der DTAG, Vodafone und Strato aus.
Dann bei der deutschen Domäne (Blog für Hochfrequenz- und Messtechnik) im kostenlosen Cloudflare-Paket zeigt sich tatsächlich folgendes: Aus den USA aufgerufen landet der Besucher beim US-Server. Von Vodafone oder Strato aus aufgerufen landet der Besucher korrekterweise auf dem US-Server. Vom Netz der DTAG aus DE aufgerufen, landet ein Besucher tatsächlich beim Origin in den USA. Faszinierend.
Okay, alles schön und gut, aber wäre das nicht etwas für ein Telekom-Forum? Was Cloudflare angeht: Komischerweise funktioniert es ja, wenn man zahlender Kunde bei Cloudflare ist. Mit Sicherheit ändert die DTAG dann Cloudflare zuliebe ihre Peering policy. Wenn man das mal ohne Bestätigungs-Bias betrachtet und den Grundsatz von Ockhams Rasiermesser anwendet, ist es dann nicht eher so, dass Cloudflare routing-technisch den kostenlosen Nutzern weniger ermöglicht?
Und noch mal zum Ping, da du selbst, die Leute im Reddit-Thread und andere darauf so fixiert sind als sei es eine verdeckte Paraphilie: Wer den Ping heutzutage auch nur ansatzweise als Referenz für HTTP(S) aufrufe verwendet ist entweder von der technologischen Bildung irgendwo in den 90ern hängen geblieben oder versteht das Internet nicht. Insbesondere, wenn Cloudflare davor sitzt. Zu keinem Zeitpunkt setzt du beim Ping auf meine Domäne einen Ping auf meine Server ab. Sondern auf den Edge-Server, den Cloudflare dir via DNS zurückwirft. Und im Falle DTAG scheint Cloudflare Edge-Server in den USA zu präsentieren. Zumindest bei den kostenlosen Kunden. Bei den zahlenden Kunden geht es ja anscheinend auch anders. Und selbst wenn du einen Webserver direkt pingen kannst, weil du seine IP kennst, werden die ICMP-Pakete des Ping von nahezu allen Netzbetreibern nachrangig behandelt. Das ist heutzutage eine ganz normale Quality of Service (QoS)-Regel. Wenn ein Netz zu Stoßzeiten meint dein Ping ist gerade nicht wichtig, dann kann er auch komplett verworfen werden. Das würdest du dann als Paketverlust sehen und auch hier vermutlich wieder die falschen Schlüsse draus ziehen. Dabei ist das nichtssagend für Protokolle mit besseren QoS-Regeln. Wenn du quantisieren möchtest wie gut ein HTTP(S)-Aufruf funktioniert, dann musst du halt eben auch das Protokoll nutzen.
Du kannst ja gerne von der DTAG genervt sein, dann würde ich aber vorschlagen das halt in einem DTAG-Forum zu diskutieren. Alternativ kann ich dir zur Vervollständigung der digitalen Desorientierung anbieten, dass wir hier weiter DTAG-Peering besprechen und wir uns dafür in einem DTAG-Forum treffen um über Cloudflare zu reden. Deal?
Willst oder Kannst Du es nicht verstehen?
Ganz offenkundig mangelt es dir an der “technologischen Bildung” und der Kritikfähigkeit was die Manipulationen der DTAG angeht.
Cloudflare ist für letzteres zuständig, dein Ping und das dahinterstehende ICMP-Protokoll hat damit nicht viel zu tun… Wie sehen HTTP(S) Anfragen zu deiner Seite aus? Also gemessen an relevanten Faktoren, wie Zeit bis zum ersten Byte (TTFB) oder ähnliche Metriken aus? Kann natürlich sein, dass du eine Seite betreibst, die deine Nutzer nur anpingen, dann ist das natürlich egal…
Wenn man das mal ohne Bestätigungs-Bias betrachtet und den Grundsatz von