Ethernet - wie wir der Traffic gedrosselt?

Computer: Hardware Netzwerk
#1

Hallo.

Ich habe das eine Wissenslücke:

Nehmen wir folgendes Netzwerk an: Ein Router oder eine Switch die „nach außen“ mit 10 GBit/s angebunden ist und ein Computer A der dahinter mit 10 MBit/s angeschlossen ist.

Wenn jetzt Computer B von außen versucht mit einem sehr hohen Datendurchsatz von sagen wir 100 MBit/s Daten an den Computer A zu übertragen, kann dies ja niemals in der Bandbreite beim Computer A ankommen.

Welche Dinge müssen passieren, damit Computer B seine Datendurchsatz reduziert? Gibt es dazu irgenwelche Protokolle im Ethernet? Wo sind solche Protokolle genutzt? Nur in Routern? oder auch in Switches? Oder geschieht es einfach dadurch, daß Pakete verworfen werden, Computer B dies mit bekommt und demensprechend langsamer Daten sendet?

(kurzer mir bekannter Hintergrund: Ethernet garantiert nicht die übertragung von Datenpacketen auf unterster Schicht- Dies übernehmen höhere Schichten zB TCP, welches auf anfrage verloren gegeangene Datenpacket noch mal sendet)

Ich hoffe, ich habe meine Frage verständlich ausgedrückt. Falls nicht, fragt bitte nach.

Gruß sadran

#2

Viel lesen
http://www.netzmafia.de/skripten/netze/netz8.html

TCP - Transmission Control Protocol

Das Prinzip des Fenstermechanismus ist eigentlich ganz einfach. Wenn man das Bild betrachtet, ergibt sich folgende Sachverhalt:

 Die Fenster größe im Beispiel beträgt drei Bytes.
 Byte 1 wurde von der Datenquelle gesendet und vom Empfänger quittiert.
 Die Quelle hat die Bytes 2, 3 und 4 gesendet, sie wurden aber vom Empfänger noch nicht quittiert (Quittung eventuell noch unterwegs).
 Byte 5 wurde von der Quelle noch nicht gesendet. Er geht erst dann auf die Reise, wenn die Quittung für Byte 2 (oder höher) eingetroffen ist.

Jedes Protokoll übernimmt viel arbeit. Und es gibt Viel Viel Overhead im Internet.
Aber zum glück hat ein Paket eine TTL , wenn die auf 0 geht , stirbt das Paket automatisch. Dafür ist dann aber wieder eine andere Schicht zuständig das dem Sender mitzuteilen .Und bei der ganzen Sache sind dann noch super Algorithmen die das ganz ausgeklügelt verteilen.
Das Ganze zusammen ergibt dann eine effiziente Verteilung.

Schau dir einfach mal in dem Text die einzelnen Protokolle und Ihre Werte an , dann siehst du das alles nötige da ist um zu kontrollieren.
Wie du nun z.b. dein Trafic zuhause gleichmässig aufteilst auf 2 Leitung geht nur mit einer Software die das auch kann.

Thomas Punkt.

#3

Guten Tag,

TCP - Transmission Control Protocol

Das Prinzip des Fenstermechanismus ist eigentlich ganz
einfach. Wenn man das Bild betrachtet, ergibt sich folgende
Sachverhalt:

Die Fenster größe im Beispiel beträgt drei Bytes.
Byte 1 wurde von der Datenquelle gesendet und vom Empfänger
quittiert.
Die Quelle hat die Bytes 2, 3 und 4 gesendet, sie wurden aber
vom Empfänger noch nicht quittiert (Quittung eventuell noch
unterwegs).
Byte 5 wurde von der Quelle noch nicht gesendet. Er geht erst
dann auf die Reise, wenn die Quittung für Byte 2 (oder höher)
eingetroffen ist.

Was du damit mir wohl sagen willst, daß meine Annahme, daß ein Packet einfach weggeworfen wird, sobald durch eine physikalische Datendurchsatz verringerung ein Stau von Packeten entsteht (siehe mein vorheriges Beispiel)

richtig?

Wie du nun z.b. dein Trafic zuhause gleichmässig aufteilst auf
2 Leitung geht nur mit einer Software die das auch kann.

Das steckte nicht hinter meiner Frage :smile:
Aber ich verrate die Intention meiner Frage:

In einem Server laufen einige virtuelle Server, ihr Netzwerkverkehr wird über Software mittels NAT oder auch Bridge an sie verteilt. Jetzt würde ich gerne aber einige der virtuellen Server, die zB eine Traffic-grenze überschritten haben, von den pysikalisch Möglichen 1 GBit/s auf zB 10 MBit/s drosseln.

Ein Software dazu habe ich nicht gefunden. Eine zu schreiben, wenn ich genug Zeit hätte, traue ich mir zu :smile: Was ich jetzt machen muss, ist mir klar: Innerhalb einer Zeiteinheit (möglichst klein) ausrechnen, wieviel Packet durchdürfen für 10 MBits/s. Alle Packet, die die Grenze überschreiten, wegschmeißen.

Mal sehen, ob ich jemals Zeit dafür finde :smile:

Gruß Andreas

#4

Servus,

googel nach 3-way-handshake und Auto-Negotation.

widecrypt

#5

Sorry,

Dein Beitrag hat mich überhaupt nicht weiter gebracht.

3-way-handshake

Falls du bemerkt hast in meinem Posting: Ich kenne TCP. Und nichts anderes macht TCP: 3-way-handshake

Auto-Negotation.

Das hat was mit der Aushandlung der physikalischen Übertragungsgeschwindigkeit zwischen zwei direkten Partner über eine einzige Ethernetstrecke zu tun. Hintergrund: Die zwei Partner können unterschiedliche Ethernet-speks implentiert haben (zB 1GBit/s oder 100MBit/s oder 10MBit/s). Es wird der größte gemeinsame Übertragunggeschwindigkeit ausgehandelt.

Wie du merkst, hat auch dies nichts mit meinem Problem zu tun.

Sorry, wenn ich jetzt unverschämt werde:
Man sollte schon die Begriffe, mit denen man um sich wirft, einordnen können.

Gruß sadran

1 Like
#6

Es gibt router die haben diese software , oder proxys
die da auch können.

Auf linux-router könntest du das programm tc nehmen um das zu kontrollieren.

Ansonsten augen auf bei Routerkauf .

#7

Bei Routern ist es z.b.
Configuring the QoS Ruleset of Your Router

#8

Auf linux-router könntest du das programm tc nehmen um das zu
kontrollieren.

Das ist mal ein sehr guter Tipp. Jetzt muss ich nur noch rausbekommen, wie ich es mit der Virtualisierungssoftware zum laufen bekomme :smile:

…router kauf

Wie erwähnt, geht es nicht um physikalische Router :smile:

Vielen Dank und Gruß
Andreas

#9

Moin moin,

…router kauf

Wie erwähnt, geht es nicht um physikalische Router :smile:

Das ist für die mitlesenden , die Ihren haushalt aufteilen wollen :smile:

Thomas Punkt.

#10

Das steckte nicht hinter meiner Frage :smile:
Aber ich verrate die Intention meiner Frage:

Das liebe ich ja, den eigentlichen Sinn erst im Nachhinein posten…

In einem Server laufen einige virtuelle Server, ihr
Netzwerkverkehr wird über Software mittels NAT oder auch
Bridge an sie verteilt. Jetzt würde ich gerne aber einige der
virtuellen Server, die zB eine Traffic-grenze überschritten
haben, von den pysikalisch Möglichen 1 GBit/s auf zB 10 MBit/s
drosseln.

Sowas macht ein physikalischer Router dadurch, dass er Pakete einfach verwirft.
Bei Lancom Modellen kannst du z.B. im Bereich Firewall einstellen, dass als Trigger Datenverkehr mit sagen wir mal >1MBit/s genommen wird (kann man auf IP oder MAC Adressen beziehen, als Ziel kann man bestimmte IP Adressen nehmen oder den ganzen Traffic oder auch nur zum WAN), die auszuführende Aktion ist dann eifnach „pack die Pakete in den Müll“.

Ein Software dazu habe ich nicht gefunden.

Wäre Netlimiter was für dich?

(Kenne ich nicht, die Beschreibung habe ich überflogen, scheint geeignet zu sein.)
Mit nem Stück Hardware habe ich das bereits gemacht.
Wobei ich mich frage, ob durch das Entsorgen zu schneller Pakete nicht zusätzlicher Verkehr erzeugt wird. Aber das mögen Leute mit tieferen TCP Kenntnissen beantowrten.

#11

Das steckte nicht hinter meiner Frage :smile:
Aber ich verrate die Intention meiner Frage:

Das liebe ich ja, den eigentlichen Sinn erst im Nachhinein
posten…

oh… denn kommentar hättest du dir sparen können.
Mein Anfangsposting war in sich abgeschlossen. Es hätte eigentlich niemand wissen müssen, warum ich das frage!

In einem Server laufen einige virtuelle Server, ihr
Netzwerkverkehr wird über Software mittels NAT oder auch
Bridge an sie verteilt. Jetzt würde ich gerne aber einige der
virtuellen Server, die zB eine Traffic-grenze überschritten
haben, von den pysikalisch Möglichen 1 GBit/s auf zB 10 MBit/s
drosseln.

Sowas macht ein physikalischer Router dadurch, dass er Pakete
einfach verwirft.

Danke. Endlich mal eine ganz eindeutige Aussage dazu.

Wäre Netlimiter was für dich?

Windows-gedöhns :smile: Ich brauche was für Linux, was mit der Virtualisierungssoftware zusammenarbeitet. Das vorherige „tc“ scheint dazu geeignet zu sein.

Aber trotzdem vielen Dank

Wobei ich mich frage, ob durch das Entsorgen zu schneller
Pakete nicht zusätzlicher Verkehr erzeugt wird.

Bei TCP: Klar, erstmal schon. Die Packete, die verworfen werden, werden von TCP erneut gesendet. Daher muss auch in TCP sowas implentiert sein wie: „muss ich viele Packet erneut senden, muss ich die Datenrate reduzieren, mit denen ich die Packete sende“ - bekannt ist mir sowas nicht. Wer TCP bis ins Detail kennt, wird mich vielleicht in dieser Annahme bestätigen können.

Gruß sadran

#12

Moin moin,

Bei TCP: Klar, erstmal schon. Die Packete, die verworfen
werden, werden von TCP erneut gesendet. Daher muss auch in TCP
sowas implentiert sein wie: „muss ich viele Packet erneut
senden, muss ich die Datenrate reduzieren, mit denen ich die
Packete sende“ - bekannt ist mir sowas nicht.

http://de.wikipedia.org/wiki/Paketumlaufzeit

http://de.wikipedia.org/wiki/Verz%C3%B6gerung_%28Tel…

das regelt das . TCP ist ja dafür gemacht worden bandbreiten unabhängig zu übertragen.

#13

Bei TCP: Klar, erstmal schon. Die Packete, die verworfen
werden, werden von TCP erneut gesendet. Daher muss auch in TCP
sowas implentiert sein wie: „muss ich viele Packet erneut
senden, muss ich die Datenrate reduzieren, mit denen ich die
Packete sende“ - bekannt ist mir sowas nicht.

http://de.wikipedia.org/wiki/Paketumlaufzeit

das regelt das . TCP ist ja dafür gemacht worden bandbreiten
unabhängig zu übertragen.

So mißverständlich, bzw. auch falsch. Super das du mir gleich den Link lieferst, der meine Auffassung bestätigt:

Zitat aus http://de.wikipedia.org/wiki/Paketumlaufzeit
„Diese Maßnahme dient dazu, das Protokollverhalten abhängig von den verfügbaren Transportkapazitäten und bei wechselnden Lastzuständen anzupassen.“

Dh TCP berücksichtig durchaus momentan zur Verfügung stehende Transportkapazitäten d.h Bandbreiten und meine Annahme oben ist durchaus richtig.

In meinem Beispiel, in der zunächst eine 1GBit/s Leitung geschaltet ist, die dann im letzten Stück in einem 10MBit/s Leitung endet, bedeutet dass nichts anders, als das TCP zunächst mit maximaler Möglichkeit sendet, dann aber irgendwann seinen Datenverkehr auf 10MBit/s einpendelt, weil eben ständig Pakete neu gesendet werden müssen

http://de.wikipedia.org/wiki/Verz%C3%B6gerung_%28Tel…

Was hat Verzögerung mit unsere Diskusion über Datendurchsatz zu tun? Das eine hat mit dem anderen nichts zu tun.

Gruß sadran

#14

Hallo,

Wer TCP bis ins
Detail kennt, wird mich vielleicht in dieser Annahme
bestätigen können.

Ja, TCP hat so einen Mechanismus („exponential backoff“); UDP dahingegen nicht. Wer UDP einsetzt, muß sich Gedanken machen, wie er mit Bandbreitenproblemen umgeht. Achja, und es gibt not ECN (Early Congestion Notification), wie gut das derzeit von Routern (!) unterstützt wird, weiß ich nicht, für klassische Switches ist das meines Wissens nach nicht relevant.

HTH,

Sebastian

#15

Ja, TCP hat so einen Mechanismus („exponential backoff“);

Sorry. Wikipedia sagt zu „exponential backoff“ was anderes:
Der Binary Exponential Backoff ist ein Stauauflösungsmechanismus im Ethernet nach IEEE 802.3.

Es hat was mit der aller untersten Schicht zu tun, nichts mit TCP. Dieses Verhalten kommt damit allen darüber liegenden Schichten zugute, auch UDP.

Aber es macht auch nicht das, was du von ihm erhoffst:

Es es nichts anderes um ein pysikalische Kollision auf dem Netz aufzulösen. Kurz erklärt:
In einem Ethernet-Netzwerk wären drei Computer A,B und C. A möchte an C senden und B möchte an C senden. Das Netz ist frei und rein zufällig beginnen sowohl A und B gleichzeitig an zu senden. Die Kollision wird festgestellt und das senden von A und auch B wird abgebrochen. A und B ermitteln eine Zufallszahl und warten diese Zeit, wodurch eine erneute Kollision hoffentlich verhindert wird. (Dieses Verfahren, hier etwas vereinfach dargestellt, ist „exponential backoff“ ).

Davon provitieren alle höheren Schichten, zunächst IP. von IP gehen UDp und Tcp ab. Obwohl pysikalisch eine sehr gut zuverläsigkeit der Datenpacket zustellung garantiert wird, garantiert IP die Zustellung nicht: erster Grund: Störung können die korrekte Übertragung von Packeten verhindern / zweiter Grund - da bin ich mir nachwievor nicht ganz sicher : die einfachere Handhabung bei Transportkapazitätproblemen, dh. das einfach wegwerfen von Packeten

Erst TCP stellt dann die sichere Datenpacket zustellung sicher, durch das 3-Handshake-Protokoll.

Wer UDP einsetzt, muß sich Gedanken machen, wie er mit :Bandbreitenproblemen umgeht.

Das stimmt dann wiederum. Bei UDP muss man sich generell Gedanken machen, was passiert, wenn Packete verloren gehen. Meistens wird UDP zB für Streams verwendet und da ist es nicht so schlimm, wenn mal ein Packet verloren geht, kommt halt dann zu kurzen Störungen in der Übertragung.

Gruß sadran

#16

Servus,

Sorry, wenn ich jetzt unverschämt werde:
Man sollte schon die Begriffe, mit denen man um sich wirft,
einordnen können.

Kann ich gut. Du bist schreib- und recherchefaul. Hättest deine Fragen präziser formulieren müssen.
Ich hab keine Glaskugel um deinen vollen Background zu ergründen. Die Anzahl der Antworten zeigt, wie oft nachgebohrt werden musste um dahinter zu kommen was du willst. Wollte dich ranführen an die Thematik. Ist unabdingbar zum schlüssigen Verständnis.

Über 3-way-handshake und Auto-Negotation landest du bei ernsthafter Recherche im ISO-OSI-Schichtenmodell und damit zwangsläufig im Ethernetpaket (ohne ck!) und dann im Ethernetframe. Von dort aus ist es dann ein Katzensprung zur technischen Realisierung.

widecrypt

#17

Kann ich gut. Du bist schreib- und recherchefaul. Hättest
deine Fragen präziser formulieren müssen.
Ich hab keine Glaskugel um deinen vollen Background zu
ergründen. Die Anzahl der Antworten zeigt, wie oft nachgebohrt
werden musste um dahinter zu kommen was du willst. Wollte dich
ranführen an die Thematik. Ist unabdingbar zum schlüssigen
Verständnis.

Über 3-way-handshake und Auto-Negotation landest du bei
ernsthafter Recherche im ISO-OSI-Schichtenmodell und damit
zwangsläufig im Ethernetpaket (ohne ck!) und dann im
Ethernetframe. Von dort aus ist es dann ein Katzensprung zur
technischen Realisierung.

*Schüttelt nur noch den Kopf*

Dann nenne mir mal bitte die exakte Stelle, wo genau beschrieben wird, was passiert, wenn der Traffic gedrosselt werden muss. Genau so wie ich es beschrieben habe.

Ich habe noch keine vernüftige Stelle dazu gefunden und ich habe schon einiges mit Internet darüber abgesucht und gelesen!

Aber nein: Man antwortet einfach mal mit pauscheln Begriffen und wenn man dann darauf hingewiesen wird, daß dies völlig am Thema vorbeigeht, dann hat man selber nicht was falsch gemacht sonder sein gegenüber. Der hätte ja schließlich bei den Begriffen lesen können und wenn du irgendwann die 20.000 Seite gelesen hast, wirst du es schon finden.

Nochmals: Mir ist das ISO/OSI-Modell, daß abweichende Ethernet-IP-TCP/UDP Modell sehr wohl bis ins Detail geläufig. Dennoch habe ich nie eine konkreite Aussage über mein Beispiel gefunden.

Gruß sadran