Internet und Telefon gestört oder gar ganz ausgefallen? Speedprobleme, die nicht offensichtlich auf die verwendeten Geräte zurückzuführen sind? Dann ist dieses Forum genau richtig!
Bitte gib bei der Erstellung eines Threads im Feld „Präfix“ an, ob du Kunde von Vodafone Kabel Deutschland („[VFKD]“), von Vodafone West („[VF West]“), von eazy („[eazy]“) oder von O2 über Kabel („[O2]“) bist.
vigidr hat geschrieben:auch fuer unschuldige, ehrliche Surfer
Sorry aber das ist keine Basis für eine konstruktive Diskussion.
Du implizierst mit dieser Aussage, dass Benutzer der gedrosselten Protokolle entweder schuldig und/oder unehrlich sind. Und damit meinst du dann auch mich, weil beispielsweise bei mir neben UDP auch SFTP gedrosselt war, welches ich aus beruflichen Gründen in den Abend- und Nachtstunden massiv benutzen muss.
Und jetzt bin ich beispielsweise auf deine Erklärung eben jenes Umstandes gespannt: die Drosselung von Protokollen, die mit Filesharing üblicherweise gar nichts zu tun haben.
wolkenkrieger hat geschrieben:die Drosselung von Protokollen, die mit Filesharing üblicherweise gar nichts zu tun haben.
Derzeit wird doch fast jedes Protokoll bzw. jeder Port zur Tarnung von Filesharing etc. genutzt. Inzwischen ist P2P doch eh im Rückgang. One-Click-Hoster und deren Protokolle übernehmen das.
In einem wirst Du mir aber sicher recht geben:
Kein einziger Provider hätte mehr Kapazitäts-Probleme, wenn alle illegalen Downloads und alle Spam-Mails eingestellt würden.
Die Drosselung ist regional sehr unterschiedlich. An meinem Anschlusss findet sie z.B. gar nicht statt. Auch in fast zu 100% aus gelasteten Segmenten in meiner Naahe findet sie nicht statt. Dort geht der Speed für alle Protokolle gleichmäßig durch die Auslastung nach unten.
Auf jeden Fall heißt es: Gas geben beim Ausbau in hoch ausgelasteten Segmenten.
wolkenkrieger hat geschrieben:Du implizierst mit dieser Aussage, dass Benutzer der gedrosselten Protokolle entweder schuldig und/oder unehrlich sind.
Ich schreibe einzelne Wortpartien oder -gruppen nicht umsonst kursiv oder gar in Anfuehrungszeichen. Das soll diese Worte hervorheben und einen anderen Sinn verdeutlichen.
MB-Berlin hat geschrieben:Derzeit wird doch fast jedes Protokoll bzw. jeder Port zur Tarnung von Filesharing etc. genutzt. Inzwischen ist P2P doch eh im Rückgang. One-Click-Hoster und deren Protokolle übernehmen das.
Ports ja, Protokolle nein. Filesharing funktioniert ja eben wegen der speziellen Protokolle.
Aber der Punkt One-Click-Hoster ist recht interessant! Hier wird nämlich HTTP als Protokoll genutzt. Eine Drosselung würde hier in der Tat nur über den Hoster ansich funktionieren - sprich: alles, was über rapidshare (beispielsweise) rein oder raus geht, wird in der Leistung beschränkt.
Das würde aber bedeuten, dass es eine Blaclist geben müsste, da es ja derlei Hoster einige gibt.
Verwaltungstechnisch nicht machbar - ganz sicher nicht. Da wäre es doch wesentlich sinnvoller, die Kapazitäten auszubauen, womit ich wieder bei meinem bereits bestehenden Fazit bin: solche Maßnahmen müssen aufgrund technischen Unvermögens getroffen werden.
exit hat geschrieben:... nur noch ausschließlich mit Crypto zugelassen habe.
Interessant, nachdem K.D. ja wie mir bekannt ist (aus eigener Erfahrung), alle Verbindungen drosselt und nur HTTP-Verbindungen per Layer-7 von der Drosslung verschont.
Kann ich nichts zu sagen. Ich kenne niemanden bei KDG und schon gar keinen der damit was zu tun hat, aber ich kann sagen das es defdinitiv schon seit einiger Zeit so ist. Ich hatte regelmäßig keine Geschwindigkeit mehr und seit der Verschlüsselung läuft die Kiste ohne Probleme.
RcRaCk2k hat geschrieben:[...] und nur HTTP-Verbindungen per Layer-7 von der Drosslung verschont.
Das erklaere mal bitte etwas genauer. Wenn du mit »Layer-7« die OSI-Schicht 7 meinst, ergibt deine Aussage keinen wirklichen Sinn. Ich denke, dass solche Filteranlagen weiter unten angesiedelt sind, z.B. Schicht 3.
So bin ich darauf aufmerksam geworden:
Ich betreibe viele VP-Netzwerke die wahlweise auf UDP/IP und TCP/IP laufen, verschlüsselt und unverschlüsselt Arbeiten können. Grundsätzlich läuft das VPN auf Port 5000 UDP. Zu einigen Zeiten waren nicht mehr als 300kB/s möglich, und dass, obwohl auf Port 80 TCP HTTP-Payload mehr als 2,8MB/s möglich gewesen sind. Wohl bemerkt am gleichen Server und zur gleichen Zeit.
Also habe ich verschiedene Ports verwendet, UDP und TCP, mit Verschlüsslung (SSL) und ohne Verschlüsslung. Nachdem Port 80 HTTP volle 2,8MB/s bei einem Download mit dem Browser lieferte habe ich den Port auf 80 TCP umgestellt, Ergebnis war nach wie vor 300kB/s.
Umstellung auf SSL und Port 443 erbrachte das selbe Ergebnis. Dachte, dass K.D. berücksichtigt, dass 443 sowieso verschlüsselt ist, und daher ein Packet-Inspection keinen Sinn macht, und um HTTPS nicht auszubremsen, den Port 443 komplett frei zu geben... Aber Pustekuchen...
Als die "Bremse" wieder heraußen war, konnte auf allen Ports, egal ob UDP/IP oder TCP/IP 3,0MB/s erreicht werden. Kaum war die Bremse wieder drin, gab es kein Entrinnen für != HTTP Protokolle.
Weiteres ist während den Tests aufgefallen:
Selbst das Port-Aggregating / Link-Bonding / Trunken oder wie auch immer man das nennen mag hatte nicht funktioniert. Egal wieviele gleichzeitige Verbindungen aufgebaut wurden, es blieb bei 300kB/s, und das, obwohl alle Links die Daten wie sie sollten "load balanced" hatten.
Dieser Test lässt mich zur Erkenntnis kommen:
Kabel Deutschland sperrt alles außer Port 80, und selbst dieser wird auf das HTTP-Protokoll hin überprüft und nur dann hat man Speed.
![[ externes Bild ]](http://img4.abload.de/img/marquis-userbarz919.gif){kind=link}