Hallo,
In unserem kleinen local-lan teilen wir uns einen DSL-anschluss (768/128) über
eine debian-kiste als router. Leider ist es so, das einige diese filesharing-tools
verwenden was zur folge hat, das der webserver, der ebenfalls auf dem router
läuft, von aussen nicht (oder nur schwer) erreichbar ist.
Nun bin ich auf der suche nach einer lösung über QoS gestolpert. Leider ist
QoS (für mich) nicht grade unkompliziert, und ich weiss nicht wirklich, ob es
damit ohne weiteres möglich ist, eingehende verbindung mit einer höheren
priorität zu versehen.
Ist QoS das was ich suche ?
Wenn ja, gibt es eine all-inclusive-lösung für solche probleme, oder muss ich in
den sauren apfel beissen und mir die gesamte QoS-doku durchlesen (und auch verstehen) ?
Kennt jemand eine Website, die sich mit genau diesem thema beschäftigt ?
Vielen dank schonmal im vorraus ...
MfG
finupsen
QoS - eingehende verbindung
- finupsen
- Beiträge: 1327
- Registriert: 21.04.2004 20:07:05
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
QoS - eingehende verbindung
Niemand hat vor eine zentrale Datensammelbehörde aufzubauen. Es handelt sich vielmehr um dezentrale IT-Systeme die miteinander vernetzt werden.
... und Wasser ist naß.
... und Wasser ist naß.
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
Jap, QOS ist genau das was du suchst. Allerdings habe ich bei meinen Versuchen mit QOS die Filesharing-Tools zu bändigen, damit mein Ping beim Online-Gamen nicht in die Höhe schiesst, nicht den größten Erfolg gehabt. Ich konnte den Up- und Download von Emule und Co. zwar erfolgreich heruntersetzen, aber meinem Ping hat das nicht wirklich geholfen.
Naja, aber für die Erreichbarkeit eines Webservers kommt es ja auf 100ms Antwortzeit mehr oder weniger auch nicht an
Eine kleine Einführung und ein Beispielskript findest du hier:
http://www.gubler.cjb.net/elwms/shaping.php
Naja, aber für die Erreichbarkeit eines Webservers kommt es ja auf 100ms Antwortzeit mehr oder weniger auch nicht an
Eine kleine Einführung und ein Beispielskript findest du hier:
http://www.gubler.cjb.net/elwms/shaping.php
- finupsen
- Beiträge: 1327
- Registriert: 21.04.2004 20:07:05
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
hallo,
Danke erstmal für deine antwort, aber das problem das du hast, lässt sich mit
qos sehr gut lösen (zumindest was die bandbreite betrifft - latenz, keine ahnung)
Ich selbst benutze SFQ um die bandbreite aller nutzer gerecht aufzuteilen.
Das ist aber nicht das problem, sondern es sind die eingehenden verbindungen.
Daher nochmal meine frage:
Ist es möglich mit QOS eingehende verbindungen höher zu priorisieren ?
CBQ z.B. bezieht sich ja nur auf die Ausgangs-Queue ...
Danke erstmal für deine antwort, aber das problem das du hast, lässt sich mit
qos sehr gut lösen (zumindest was die bandbreite betrifft - latenz, keine ahnung)
Ich selbst benutze SFQ um die bandbreite aller nutzer gerecht aufzuteilen.
Das ist aber nicht das problem, sondern es sind die eingehenden verbindungen.
Daher nochmal meine frage:
Ist es möglich mit QOS eingehende verbindungen höher zu priorisieren ?
CBQ z.B. bezieht sich ja nur auf die Ausgangs-Queue ...
Zuletzt geändert von finupsen am 30.05.2004 17:23:45, insgesamt 1-mal geändert.
Niemand hat vor eine zentrale Datensammelbehörde aufzubauen. Es handelt sich vielmehr um dezentrale IT-Systeme die miteinander vernetzt werden.
... und Wasser ist naß.
... und Wasser ist naß.
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
Nein, wenn die Leitung dicht ist, ist sie dicht. Normalerweise nimmt man dann einfach beim Traffic Shaping einfach den Trick, dass man dafür sorgt, dass der Router die Queues im Modem immer möglichst leer hält, indem die Bandbreite zum und vom Modem schon im Router begrenzt wird. Damit fixed man das Standard DSL Problem, dass ein ausgelasteter Upstream den Downstream kaputtmacht. Damit solltest Du auf jeden Fall soweit kommen, dass der Apache erreichbar ist.
Das eigentliche Problem, was man bei ADSL normalerweise lösen muss, ist der, dass der Router die Upstream Daten mit voller Ethernet Bandbreiten (meistens 10MBit/s) zum Modem schickt, das Modem aber nur mit 128kBit/s ins Internet senden kann. Daher laufen die (zwischen Up- und Downstream geshareten) Queues im Modem voll und bleiben auch voll. Dadurch kommt es dazu, dass bei ankommenden Downstream Paketen die Queues im Modem voll sind, und das Paket daher verloren geht. Die Protokolle auf den höheren Ebenen sorgen normalerweise für Retransmits, aber auch nicht unendlich oft (Timeout). Indem man jetzt die Bandbreiten schon auf dem Router begrenzt, sendet der nicht mit 10MBit/s ans Modem, sondern nur noch mit 124-126kBit/s (man stellt das etwas niedriger ein, weil der Datenstrom ja aus Paketen besteht und daher nicht "kontinuierlich ist). So laufen die Modem Queues nicht mehr voll und der Durchsatz verbessert sich normalerweise spürbar.
Überzeugt, den Ansatz 'mal auszuprobieren? Suche 'mal nach "Wondershaper" auf Google, das System sorgt (mit ein paar Extras) für genau das...
Patrick
Das eigentliche Problem, was man bei ADSL normalerweise lösen muss, ist der, dass der Router die Upstream Daten mit voller Ethernet Bandbreiten (meistens 10MBit/s) zum Modem schickt, das Modem aber nur mit 128kBit/s ins Internet senden kann. Daher laufen die (zwischen Up- und Downstream geshareten) Queues im Modem voll und bleiben auch voll. Dadurch kommt es dazu, dass bei ankommenden Downstream Paketen die Queues im Modem voll sind, und das Paket daher verloren geht. Die Protokolle auf den höheren Ebenen sorgen normalerweise für Retransmits, aber auch nicht unendlich oft (Timeout). Indem man jetzt die Bandbreiten schon auf dem Router begrenzt, sendet der nicht mit 10MBit/s ans Modem, sondern nur noch mit 124-126kBit/s (man stellt das etwas niedriger ein, weil der Datenstrom ja aus Paketen besteht und daher nicht "kontinuierlich ist). So laufen die Modem Queues nicht mehr voll und der Durchsatz verbessert sich normalerweise spürbar.
Überzeugt, den Ansatz 'mal auszuprobieren? Suche 'mal nach "Wondershaper" auf Google, das System sorgt (mit ein paar Extras) für genau das...
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
Meine Erfahrungen mit dem Wondershaper sind etwas zweigespalten. Der ingres Teil funktioniert in vielen Situationen nicht so wie erwartet (z.B. bei NNTP).
Bessere Erfahrungen mit dem Bremsen von eintreffenden Traffic habe ich gemacht wenn man auf der internen NIC bremst. Ist zwar ein wenig kontraproduktiv, da möglicherweise ein Paket verworfen wird obwohl es schon zugestellt wurde (Wondershaper würde das auch) aber was ist das schon gegenüber der totalen Kontrolle
Bessere Erfahrungen mit dem Bremsen von eintreffenden Traffic habe ich gemacht wenn man auf der internen NIC bremst. Ist zwar ein wenig kontraproduktiv, da möglicherweise ein Paket verworfen wird obwohl es schon zugestellt wurde (Wondershaper würde das auch) aber was ist das schon gegenüber der totalen Kontrolle
Ciao, Hendri
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
Das Hauptproblem ist natürlich dabei, dass man ingres nicht wirklich kontrollieren kann. Man kann halt nur Pakete verwerfen, um damit die Windowsize zu reduzieren und damit den Durchsatz der gegenstelle zu bremsen... Richtig funktionieren tut das allerdings nicht, da man auf die Kooperation der Gegenstelle angewiesen ist...
Patrick
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
Besser als mit dem ingess des Wondershapers funkt es auf jeden Fall! Die droppings halten sich in Grenzen, was für mich ein Indiz für eine funktionierende Interaktion der beiden Seiten darstellt.
Mit dem Wondershaper ist es z.B. nicht möglich Binary News-Groups zu benutzen (mit aktiviertem ingress) - Immer wieder Verbindungsabbrüche.
Traffic ist mit HTB und teilweise SFQ gut beherrschbar. Bei weitem nicht optimal das ist richtig, aber was soll's. (works for me )
ECN ist leider meist fehlend bzw. falsch in vielen Firewalls implementiert als das man es sinnvoll einsetzen könnte...
@finupsen: Das IMQ ist auch noch zu erwähnen für eintreffenden Traffic was aber mit vielen iptables patches (PatchOmatic) nicht kompatibel ist. Wenn man auf diese verzichten kann/will egal...
Mit dem Wondershaper ist es z.B. nicht möglich Binary News-Groups zu benutzen (mit aktiviertem ingress) - Immer wieder Verbindungsabbrüche.
Traffic ist mit HTB und teilweise SFQ gut beherrschbar. Bei weitem nicht optimal das ist richtig, aber was soll's. (works for me )
ECN ist leider meist fehlend bzw. falsch in vielen Firewalls implementiert als das man es sinnvoll einsetzen könnte...
@finupsen: Das IMQ ist auch noch zu erwähnen für eintreffenden Traffic was aber mit vielen iptables patches (PatchOmatic) nicht kompatibel ist. Wenn man auf diese verzichten kann/will egal...
Ciao, Hendri