Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Woher weiß mein Rechner mit welcher Geschwindigkeit er senden darf?

Frage Netzwerke Netzwerkprotokolle

Mitglied: kismet

kismet (Level 1) - Jetzt verbinden

20.12.2012 um 18:41 Uhr, 7181 Aufrufe, 26 Kommentare

Ethernet II - TCP/IP - Flowcontroll oder Windowing?

Hi,

peinliche Frage, ich trau mich garnicht zu Fragen, da es eigentlich Grundwissen sein sollte, aber

Woher weiß mein Rechner mit welcher Geschwindigkeit er senden darf / kann?

Szenario:
PC <--- 100Mbit ----> SWITCH <---- 10 Mbit ----> SWITCH <---- 100Mbit ----> PC

Annahme:
- alles Vollduplex
- Beide PCs gehen von einer 100 Mbit Verbindung aus
- Flaschenhals sind jedoch 10 Mbit (SWITCH <-> SWITCH)
- Offset / Header einfach mal weg denken
- Beide PCs können 100Mbit/s verarbeiten
- keine Unterscheidungs zwischen brutto / netto datenraten

erste Recherchen:

TCP-Window:
Hier würde ich aber annhmen das der Empfänger die Paket Anzahl erhöhen würde (er kann schließlich 100 Mbit/s verarbeiten, bekommt aber nur 10 Mbit/s).

Flowcontroll bei Ethernet:
Meine Annahme hier, dass der Switch dem sendenen PC ein "PAUSE-Signal" sendet, bis er die Daten (inzwischen gebuffert) aus dem 10Mbit Port raus gepummpt hat.
Ich habe mit Wireshark mitprotokolliert und keine derartigen Pakete sehen können (http://upload.wikimedia.org/wikipedia/commons/f/f4/EthernetPauseFrame.j ...)

Nun, wie funktioniert das?
Es muss auch keine erklärung sein, ein Stichwort würde mir reichen, suchen kann ich selber, danke!
Mitglied: Lochkartenstanzer
20.12.2012, aktualisiert um 19:07 Uhr
Zitat von kismet:
Szenario:
PC <--- 100Mbit ----> SWITCH <---- 10 Mbit ----> SWITCH <---- 100Mbit ----> PC

In diesem Szenario arbeiten die Switches mit "store-and-forward", sind also nichts anderes als das, was man früher "Bridge" genannt hat. Wenn die Pakete so schnell kommen, daß der Puffer überläuft, werden sie einfach entsorgt. Die Korrekturmechanismen der höheren Schichten (z.B. TCP) sorgen dann dafür, daß Pakete nochmal gesendet werden oder die Sendegeschwindigkeit gedrosselt wird.

lks
Bitte warten ..
Mitglied: kismet
20.12.2012 um 19:09 Uhr
vielen dank

[quote]
Die Korrekturmechanismen der höheren Schichten (z.B. TCP) sorgen dann dafür, daß Pakete nochmal gesendet werden oder die Sendegeschwindigkeit gedrosselt wird.
[/quote]

Welche Mechanismenn sollen das sein?
ich habe das ganze mitprotokolliert, nach deiner aussage müsste ich ja "retransmitts" sehen... tu ich aber nicht, ich kann mit Wireshark (permon) keinen Paketverlust feststellen
Bitte warten ..
Mitglied: Lochkartenstanzer
20.12.2012 um 19:15 Uhr
Zitat von kismet:
vielen dank

[quote]
Die Korrekturmechanismen der höheren Schichten (z.B. TCP) sorgen dann dafür, daß Pakete nochmal gesendet werden
oder die Sendegeschwindigkeit gedrosselt wird.
[/quote]

Welche Mechanismenn sollen das sein?

z.B. Slow Start

ich habe das ganze mitprotokolliert, nach deiner aussage müsste ich ja "retransmitts" sehen... tu ich aber nicht,
ich kann mit Wireshark (permon) keinen Paketverlust feststellen

Macht Du die Leitung auch voll? Auf welcher Seite mißt Du?

lks
Bitte warten ..
Mitglied: MrNetman
20.12.2012 um 19:26 Uhr
Hi Kismet,

das wird nicht dem Schicksal überlassen sondern permanent korrigiert.

Im Übertragungsprotokoll ist das verankert.
Es klappt ja auch mit DSL 0,75Mbit und 50Mbit/s.

Das dominierende Protokoll ist das TCP Protokoll und das wird mittels eines Dreiwegehandshakes betrieben. Es gibt für alles eine Bestätigung. Wenn also die Bestättigung innerhalb des Sendefensters (typisch ca 64KByte) ausbleibt, dann muss der schnelle Rechner eben warten, bis er weiter machen kann. Die Gegenstellen richten sich also auf die maximal erreichare Durchsatzgeschwindigkeit pro Richtung ein. Wenn schlechter wird, dann werden diese Fenster verkürzt und mehr Bestätigungen angefordert. Wenn die Verbindung besser wird, dann kann das Fenster auch ein Vielfaches der Ausgangsgröße erreichen. Dann wird die Verbindung schneller.

Das Verfahren wird zur Zeit auch bei Videostreaming eingesetzt und bei Web-TV und Webradio. Deshalb kann es sein, dass die Sendung trotz passender Bandbreite schon mal ein paar Minuten länger dauert. Ursprünglich sollte UDP dafür verwendet werden, tut aber kaum jemand. Ausnahme VoIP und interaktive Echtzeitanwendungen. Da riskiert man lieber eine Lücke als den unmenschlichen Zeitversatz.

Jetzt solltest du das auch im Wireshark finden.
Wie kannst du es schnell prüfen:
Lade eine große Datei von einem europäischen Server und von einem amerikanischen. Da das Handshake (Ping-Zeit) länger dauert, wird auch eine geringere Bandbreite genutzt.

Switches haben typischerweise am Wenigsten mit der Geschwindigkeit zu tun. Sie haben auch nur einen lokalen Fokus. Wenn das Paket weg ist, dann ist es weg. Kein weiteres interesse. Router schon eher ein, da die Router die Pakete umkodieren müssen.

Aber alles kein Layer2.

Gruß
Netman
Bitte warten ..
Mitglied: kismet
20.12.2012 um 19:26 Uhr
danke nochmals für die antwort, ich werde mich in slow-start und weitere mechanismen von "Congestion control" einlesen.

ich messe auf der Sender seite... und nein, ich mach die Leitung nicht voll, sondern sende 10Mbit/s (was dem flaschenhals entspricht) ich würde nur gerne wissen, woher mein rechner denn weiß das er nur mit 10Mbit/s senden kann/darf

neben bei:
kann das sein das NetIO Wireshark zum absaufen bringt? sowohl sender als auch empfänger seinte?^^
Bitte warten ..
Mitglied: kismet
20.12.2012 um 19:31 Uhr
Hi, vielen dank
Ich werde mir das nochmal genauer anschauen und dir mit sicherheit feedback dazu geben.
thx
Bitte warten ..
Mitglied: it-frosch
20.12.2012 um 19:33 Uhr
Hallo Kismet,

wie sind die Switchports einstellt, Autonegoation oder feste Geschwindigkeit?

grüße vom it-frosch
Bitte warten ..
Mitglied: kn0rki
20.12.2012 um 19:47 Uhr
-> http://de.wikipedia.org/wiki/Autonegotiation
Das regelt wie schnell deine Karte Senden und Empfangen kann. Du kannst das in den Einstellungen der Netzwerkkarte ueberschreiben.

Das Wireshark ueberhaupt problemlos laeuft ist manchmal bei den Bug und Pufferueberlaufen eher ein Wunder.
Bitte warten ..
Mitglied: MrNetman
20.12.2012 um 20:17 Uhr
neben bei: kann das sein das NetIO Wireshark zum absaufen bringt? sowohl sender als auch empfänger seite?

NetIO will maximalen Durchsatz und das ohne Rücksicht. Also UDP und maximal einstellen. Was verloren geht ist weg...
Wireshark ist ja auch nur ein Teil deines Systems und NetIO will genau messen, also volle Kanne, alle Resourcen, wenn nötig.

Gruß
Netman
Bitte warten ..
Mitglied: Dobby
21.12.2012 um 08:22 Uhr
Hallo kismet,

es gibt keine falschen oder dummen Fragen, denn niemand weiß alles.

Aber da Du dir die Frage selber eigentlich beantwortet hast, kommt es einem dann eben auch wieder ein klein wenig komisch vor.

Woher weiß mein Rechner mit welcher Geschwindigkeit er senden darf / kann?
- Flaschenhals sind jedoch 10 Mbit (SWITCH <-> SWITCH)

Ist doch alles klar oder?
Tausch die Switche aus und gut ist es.

So nun zum messen, wenn Du die ganze Sache akkurat messen möchtest, kommt es natürlich auch auf das Equipment an was zum Einsatz kommt.

- Billiger Lanmeter (30 €)
- Fluke Lanmeter (Kauf Dir leiber ein Auto)
- Harware die mit Wireshark vertrieben wird (Kauf Dir lieber eine Wohnung)
- Extra Rechner wie zum Beispiel ein Linux Laptop
- Die Art, Beschaffenheit und die gebotenen Funktionen der eingesetzten Switche (Monitor oder Mirrored Port)
- Die Güte und Qualität der verbauten Netzwerkkarten und deren Treiber
- Das verwendete OS und vor allem anderen die darunter liegende Hardware
- Stehen Ethertabs zur Verfügung? und und und und......

Wenn Du uns schon schreibst:
>..kann das sein das NetIO Wireshark zum absaufen bringt? sowohl sender als auch empfänger seinte?^^
Das ist doch wohl nicht die Schuld von Wireshark, sondern wohl eher der verwendeten Hardware geschuldet.

Nun, wie funktioniert das?
Einfach anklicken

Ich habe mit Wireshark mitprotokolliert und keine derartigen Pakete sehen können
Was für Filter hast Du denn in WireShark gesetzt?

ich messe auf der Sender seite... und nein, ich mach die Leitung nicht voll, sondern sende 10Mbit/s (was > dem flaschenhals entspricht) ich würde nur gerne wissen, woher mein rechner denn weiß das er nur mit
10Mbit/s senden kann/darf
Wenn alle Partner auf Autonegoation eingestellt sind, wie @it-frosch das nachgefragt hat, handeln diese
Netzwerkkarten und Switche das untereinander automatisch aus.

Beide PCs gehen von einer 100 Mbit Verbindung aus
Ich denke eher das die beiden PC aufgrund der verbauten Netzwerkkarte dies unterstützen
und Du davon ausgehst das das dann auch so ist, allerdings begrenzen alleine die Switche das schon
von vorne herein. Denn wenn Dein PC eine 100 MBit/s Netzwerkkarte hat und an einen Switch angeschlossen
ist der nur 10 MBit/s kann, dann kann es ja nur einen 10 MBit/s Verbindung sein und nichts anderes!
Ob nun FullDublex oder HalfDublex spielt hier keine Rolle!

Mein Tipp an Dich:
Zwei 10/100/1000 MBit/s Netzwerkkarten kaufen
Billige gibt es für ca. ~6 € je Karte (Realtek basieren)
Etwas bessere gibt es für ~40 € (Intel basierend)
Zwei GB LAN fähige Switche organisieren
So wie das in Deiner Zeichnung aussieht ist das mit 40 € bis hin zu 120 € für zwei Switche erledigt.
Und das ganze Szenario kann dann auch schon einmal ganz anders ablaufen, denn wenn Du dann
einen freund oder Bekannten anrufst und die Messung noch einmal mit Wireshark veranstaltest
ist der Flaschenhals weg und mit einem Monitor Port am Switch und einen Linux Laptop kann man
zum einen mit Wireshark und zum Anderen mit iperf ganz schnell nachmessen was denn wann und wie
läuft.

Denn irgendwie, nimm es mir bitte nicht übel, habe ich das Gefühl das Du Dich da in was verbissen hast,
á la ich mach mich mal schlau und dann bekommen wir den Flaschenhals schon weg.
Falls das der Fall sein sollte ist das mit der neuen Hardware ein weitaus besserer Tipp bitte glaube mir.
Es ginge zur Not ja auch schon mit einem Switch, wenn man nur die Entfernung und den ganzen Rest kennen
würde!

Sollte das aber nur eine rein informative Frage sein, solltest Du vielleicht einen Laptop mit an den jeweiligen Switch hängen und noch einmal messen.

Gruß und viel Erfolg
Dobby
Bitte warten ..
Mitglied: kismet
21.12.2012 um 09:01 Uhr
Hi,

vielen Dank für die super Antwort, aber ich habe leider das Gefühl ich habe mich nicht gut genug ausgedrückt!
Ich habe kein "Problem" bzw. mein Problem ist ein anderes. Es ging mir um das "Verstädniss"

Ich will wissen WIESO und vorallem WIE es funktioniert, protokolle, datenaustausch, bis runter zum bitmuster sozusagen

Ich will also den Flaschenhals garnicht raus bekommen (da es ein theoretischer aufbau ist), ich will wissen welche Protokolle bzw. welcher Mechanismuss dafür sorgt, das ein PC der eine 100 Mbit Verbindung hat, nur mit der Geschwidigkeit seines Flaschenhalses (10 Mbit) sendet.

In dem Fall mit 10 Mbit und nich mit 100 Mbit (und 90% der pakete Verworfen werden müssen).

Ich habe das gefühl ich muss mich weiter in "flow-controll" bzw. TCP-Windowing einlesen
Bitte warten ..
Mitglied: MrNetman
21.12.2012 um 09:32 Uhr
Hi Dobby,

Das hat hier absolut nichts mit einer spezifischen Hardware und mit Autonegationsproblemen zu tun.
Es geht um die Bits, die mal Ethernet über Kupfer Vollduplex, mal geshartes Medium wie WLAN oder Hub, mal WAN-Technologie (ATM, Ethernet, VPN, ISDN, PDH) sein können.

Der Vorgang ist immer der selbe und er funktioniert. Zum Glück für TCP.

Daraus ergibt sich auch, dass man Durchsatzmessungen nicht mit TCP machen kann, wenn es nur um die reale Bandbreite geht.
Die zweite Messmethode mit TCP von einem Server hat in jedem Falle auch die lokalen Leistungs- und Serverparameter mit drin. Wer will schon defekte Dateien benutzen. Bei TCP gibt es das nicht - dank der Ende zu Ende Verifikation der Pakete, die Zeit braucht.

Gruß
Netman
Bitte warten ..
Mitglied: Dobby
21.12.2012 um 09:32 Uhr
@kismet

welcher Mechanismuss dafür sorgt, das ein PC der eine 100 Mbit Verbindung hat, nur mit der
Geschwidigkeit seines Flaschenhalses (10 Mbit) sendet.
Die Switche und niemand anderes, kein Protokoll und/oder sonst wer, nur die Switche.

Wenn die Switche 10/100 MBit/s können würden, wäre ja auch kein Flaschenhals mehr da, der ist
Hardware basieren oder besser Hardware existent und nicht Protokoll basierend!!!

Da kannst Du lesen bis Du den Doktorgrad erreichst, aber durch den Einsatz eines anderen Switches
ist das Problem, der Flaschenhals nicht mehr existent oder besser noch behoben.
Ist wie mit einem "platten" Reifen am Fahrrad, ist der erst einmal geflickt bzw. ausgetauscht, entweicht die Luft auch nicht mehr.

Wenn man nun einmal hergeht und sagt die Distanz zwischen den Switchen ist xyz Meter und man kauft einen 30 € Switch der 100 MBit/S kann ist der Flaschenhals weg, fertig.

Denn die Sendegeschwindigkeit der Netzwerkkarte mag ja 100 MBit/s haben, aber die des Switches eben nicht und daran ist der PC (die PCs) ja nun einmal angeschlossen!

Sei bitte nicht böse, aber es klingt mir so also ob:

Wenn Du einen Gartenschlauch hast und knickst den etwas, dann kommt eben auch kein Wasser oder nur noch ein bisschen Wasser mehr durch. Und Du möchtest Dich nun über die Wasserleitung und die beim Schlauch verwendeten Materialien schlau mach n(lesen) warum denn nur so wenig Wasser vorne aus dem Wasserschlauch kommt. Und ich versuche Dir eben nur zu erklären dass man nur den Schlauch nicht knicken
darf!

Viel Glück und Gruß
Dobby
Bitte warten ..
Mitglied: Dobby
21.12.2012 um 09:43 Uhr
Zitat von MrNetman:
Hi Dobby,
Hallöle,

die Karte am PC ist Punkt eins der Verbindung und ist, obwohl sie 100 MBit/s können würde,
doch aber nur mit 10 MBit/s mit dem Punkt zwei, nämlich dem Switch verbunden, oder irre ich mich jetzt so
sehr. Zumindest wenn ich seine Zeichnung sehe, kann die Karte niemals auf 100 MBit/s eingestellt sein!
Somit sendet diese auch nicht mit 100 sondern eben nur mit 10 MBit/s.

Wenn es nicht so sein sollte, bitte ich jetzt einmal um Korrektur.

Gruß
Dobby
Bitte warten ..
Mitglied: Lochkartenstanzer
21.12.2012 um 09:55 Uhr
Zitat von Dobby:
@kismet

> welcher Mechanismuss dafür sorgt, das ein PC der eine 100 Mbit Verbindung hat, nur mit der
> Geschwidigkeit seines Flaschenhalses (10 Mbit) sendet.
Die Switche und niemand anderes, kein Protokoll und/oder sonst wer, nur die Switche.

Hi dobby,

Da muß ich Dir widersprechen.

Wenn der PC an einem 100MBit-Switch vollduplex hängt, sendet der auch 100MBit vollduplex. Wenn es hinter dem switch nur mit 10 Mbit weitgergeht, schaltet er um auf store-andforward udn üuffert die Daten, bis sein Puffer überläuft. Ab da werden die Frames entsorgt.

D.h. der PC sendet ggf. weiter mit 100MBit, aber der switch leitet nicht alles weiter. Die höheren Protokollschichten müssen dann dafür sorgen, daß keine Datenverluste auftreten. Das kann TCP sein, oder aber auch andere Protokolle, die Fehlerkorrekturmechanismen implementiert haben.

TCP macht das mit u.a. "Flow-" und "Congestion Control".

lks
Bitte warten ..
Mitglied: Dobby
21.12.2012 um 10:02 Uhr
Ja ne schon klar

Wenn der PC an einem 100MBit-Switch vollduplex hängt,

nun habe ich es auch gesehen!

ich bin die ganze zeit von pc 100mbit/s -------->10 MBit/s Switch---------10 MBit/s--------->.......

Wer lesen kann war klar im Vorteil.

Gruß und schönen Weltuntergang
Dobby
Bitte warten ..
Mitglied: kismet
21.12.2012 um 10:03 Uhr
Hi Dobby...


annahme ist, die pcs hängt an einem switchport mit 100/mbit vollduplex und die verbindung zwischen den switchen ist 10Mbit vollduplex. (Der switch hat also sowohl einen 100 Mbit voll, wie auch eine 10 Mbit voll port)

die pcs sehen nur "ihre eigene 100 Mbit" welt... warum senden sie trotzdem mit 10 Mbit und nicht mit 100?
erste tests haben mir gerade gezeigt, das sie das nur bei TCP machen, und bei UDP tatsächlich 100 mbit gepumpt werden (NetIO)... stell ich sie auf 10 Mbit... naja, eh klar


wenn ich mit perfmon z.B. die ausgehenden byte/s anzeigen lasse (sagen wir bei einem Datentransfer oder mit NetIO) werden bei TCP max. 10 Mbit gepumpt, bei UDP 100mbit

Ich gehe also mal von einem TCP Mechanismuss aus.
Ein Mechanismuss der VERHINDERT das Datenpakete verloren gehen, nicht der SYN - ACK Mechanismuss (welcher für wiederholte Paketübertragung, bei Paketverlust, zuständig ist).

Annahme korrekt?
Bitte warten ..
Mitglied: Lochkartenstanzer
21.12.2012 um 10:11 Uhr
Zitat von kismet:
Ich gehe also mal von einem TCP Mechanismuss aus.
Ein Mechanismuss der VERHINDERT das Datenpakete verloren gehen, nicht der SYN - ACK Mechanismuss (welcher für wiederholte
Paketübertragung, bei Paketverlust, zuständig ist).

TCP verhindert nicht, daß Pakete verlorengehen. TCP sorgt nur dafür, daß Pakete nur so schnell gesendet werden, das möglichst wenig oder gar keine Pakete verlorengehen.

lks
Bitte warten ..
Mitglied: kismet
21.12.2012 um 10:13 Uhr
Zitat von Lochkartenstanzer:
> Zitat von kismet:
> ----
> Ich gehe also mal von einem TCP Mechanismuss aus.
> Ein Mechanismuss der VERHINDERT das Datenpakete verloren gehen, nicht der SYN - ACK Mechanismuss (welcher für
wiederholte
> Paketübertragung, bei Paketverlust, zuständig ist).

TCP verhindert nicht, daß Pakete verlorengehen. TCP sorgt nur dafür, daß Pakete nur so schnell gesendet werden,
das möglichst wenig oder gar keine Pakete verlorengehen.

lks

und das mit hilfe von?
Windowsize?
Bitte warten ..
Mitglied: MrNetman
21.12.2012 um 10:40 Uhr
Hi Kismet,

immer Syn Ack - das ist der Handshake.
Ohne ihn könnte man doch nicht erkennen, ob Pakete nicht ankommen oder ins Timeout laufen. Die Windowssize und das Vielfache davon, bestimmt nur die Datenmenge, die der Sender verschicken darf, ohne auf ein Ack zu warten. Damit hat man nicht nur die Bandbreite, sondern auch wackelige Verbindungen im Griff.
Eine Ausnahme gibt es im WLAN, das einen eigenen Layer2 Prozeß für verlorene Pakete hat. Der AP kontrolliert ja permanent die Verbindungen und bekommt es so mit. Deshalb der Prozeß des CSMA-CA mit der AP-Steuerung.

Während Wireshark beim Verbindungsaufbau gut zeigt, wie der Pozeß funktioniert muss man später sehr genau im Decode nachsehen für welche Paketnummer das ACK gesendet worden ist.

Gruß
Netman
Bitte warten ..
Mitglied: Lochkartenstanzer
21.12.2012 um 10:46 Uhr
Zitat von kismet:
> Zitat von Lochkartenstanzer:
> ----
> > Zitat von kismet:
> > ----
> > Ich gehe also mal von einem TCP Mechanismuss aus.
> > Ein Mechanismuss der VERHINDERT das Datenpakete verloren gehen, nicht der SYN - ACK Mechanismuss (welcher für
> wiederholte
> > Paketübertragung, bei Paketverlust, zuständig ist).
>
> TCP verhindert nicht, daß Pakete verlorengehen. TCP sorgt nur dafür, daß Pakete nur so schnell gesendet
werden,
> das möglichst wenig oder gar keine Pakete verlorengehen.
>
> lks

und das mit hilfe von?
Windowsize?

https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Data_transfe ...
Bitte warten ..
Mitglied: kismet
21.12.2012 um 10:55 Uhr
Zitat von MrNetman:
Die Windowssize und das Vielfache
davon, bestimmt nur die Datenmenge, die der Sender verschicken darf, ohne auf ein Ack zu warten. Damit hat man nicht nur die
Bandbreite, sondern auch wackelige Verbindungen im Griff.

das ist doch die aussage auf die ich seit gestern warte, zusammenfassend die erkentnisse:

Zusammenfassung:
TCP mit dem Window Mechanismuss = sorgt dafür das eine verbindungsorientierte Verbindung möglichst ohne Paketverlust auskommt bei einer Datenleitung (von Sender zu Empfänger) welche nicht die gleichbleibende Verbindungsqualität liefert (Geschwindigkeit / Zuverlässigkeit / Durchsatz).

UDP = pumpt was die lokale verbindung her gibt, wenn es dazwischen einen Flaschenhals gibt, und ein bufferüberlauf statt findet = pech (obriges Beispiel, gehen 90% der UDP Pakete bei einem Bufferüberlauf auf dem Switch verloren)

Syn-ACK - 3 Wege-Handshake = Aufbau der Verbindung

Autoneg. = hat nur physikalische bedeutung (Aushandlung einer Verbindungsgeschwindigkeit zwischen zwei Teilnehmern)

Irgendwelche ergänzungen oder korrekturen?^^

thx so weit!
Bitte warten ..
Mitglied: aqui
21.12.2012, aktualisiert um 14:53 Uhr
.@Lochkarte
Ein Switch "schaltet" niemals um auf Store and Forward, denn das kann er gar nicht, weil das in seinen Port ASICS fest vorgegeben, also in Silizium gegossen ist. Technisch kann ein Switch nur im cut through oder store and forward Mode arbeiten je nach Basis der verbauten Chips und Firmware.
Richtige Cut Through Switches sind extrem selten im Ethernet Bereich, da teuer was wieder die klassichen Kunden mit "HP Denke" nicht bezahlen wollen oder für unnötig halten. Das Gros aller Ethernet Switches, außer speziellen Rechenzentrums Fabric Switches, arbeitet immer mit Store and Forward. "Umschalten" ist also technischer Unsinn.

Ansonsten ist zu dem Thema ja bereits alles gesagt und die Testergebnisse von kismet bestätigen ja auch genau die Theorie in der Praxis.
Was maximal gesendet werden kann bestimmt einzig der Sliding Window Mechanismus unter TCP:
http://de.wikipedia.org/wiki/Sliding_Window
Nur damit ist eine Flusskontrolle überhaupt möglich in dem obigen Szenario, denn die 100 Mbit attachten Endgeräte wissen ja nichts vom 10 Mbit Engpass dazwischen. In der Beziehung ist der Einwand mit der Autonegotiation natürlich auch Unsinn !
So oder so ein klassisches Szenario bezogen aufs gesamte Internet. Die Exchange Points haben alle 100 Gigabit Ethernet Glasfaser oder sogar mehrere davon in einer Link Aggregation. Ein Enduser aber nur 3 Mbit DSL...gleiches Spielchen nur andersrum was aber der Theorie keinen Abbruch tut.
Bei anderen Protokollen die keinen Sliding Windows Mechanismus haben pumpt der Switch eben alles raus was er kann und seine HW hergibt, bzw. was seine DRAM Port Puffer aufnehmen können auf dem 10 Mbit Port. Port Buffer sind je nach Switchqualität und QoS Fähigkeit (mehrere Port Buffer Queues für Priorisierung) sehr unterschiedlich.
Wenn diese Port Buffer voll sind schmeisst er gnadenlos weg, was aber das angeschlossene 100 Mbit Endgerät nicht merkt ohne Sliding Windows.
802.3x Ethernet Flow Control wäre ein Mechanismus das Geräte basierend zu lösen:
https://www.juniper.net/techpubs/en_US/junos/topics/concept/cos-qfx-seri ...
Dann hätte man dies Flusskontrolle auf Basis der verwendten Infrastruktur. Wäre ideal, aber leider ist das beim Gros der Switches und auch der NICs nicht implementiert oder gar nicht aktiviert.
Inkonsistente Konfigurationen mit und ohne 802.3x Funktion auf Switches können somit zu erheblichen Problemen in Ethernet Netzwerken führen wo sowas kritiklos gemischt wird. Ein tägliches Problem hier bei Administrator.de da kein Hobby Netzwerk Admin auf sowas achtet geschweige denn Kenntniss davon hat. Die vielen Threads hier zeugen davon...
Genau das ist auch der Grund warum es auf dem Gros der ungemanagten Billigswitches gar nicht implementiert oder bei billigen Midrange Switches (und Highend im Default) nie aktiviert ist. Die meisten NIC Treiber haben es in den Settings ebenfalls deaktiviert. 802.3x ist sinnvoll angedacht aber in den meisten Ethernet Netzen kein Themaaus den genannten Problematiken.
Fazit ist, das damit mehr oder weniger alles von höheren Protokollschichten abhängt. Im reinen Layer 2 wird nur weggeschmissen bzw. gedropt, so einfach ist das.
Letztlich auch genau das, was die o.a. Testergebnisse ja bestätigen !
Bitte warten ..
Mitglied: kismet
21.12.2012 um 14:39 Uhr
danke... auf deinen Beitrag hab ich die ganze zeit gewartet
ungewöhnlich dass das fast 24h gedauert hat :P
Bitte warten ..
Mitglied: aqui
21.12.2012 um 14:46 Uhr
...ist ja Weihnachtszeit
Bitte warten ..
Mitglied: Lochkartenstanzer
21.12.2012 um 14:56 Uhr
Zitat von aqui:
.@Lochkarte
Ein Switch "schaltet" niemals um auf Store and Forward, denn das kann er gar nicht, weil das in seinen ASICS fest
vorgegeben ist. Technisch kann ein Switch nur im cut through oder store and forward Mode arbeiten je nach Baisi der verbauten
Chips und Firmware.
Richtige Cut Through Switches sind extrem selten im Ethernet Bereich, das Gros arbeitet immer mit Store and Forward.
"Umschalten" ist also technischer Unsinn.

Ich habe mich vermutlich mißverständliche ausgedrückt. Es gibt (oder besser es gab) viele switches, die beides können, store-and-forward und cut-trough. Diese haben, sofern möglich cut-trough verwendet und haben dann, wenn sich die gegebenheiten geändert haben (zuviele Kollisionen an einem Port, oder unterschiedliche Portgeschwindigkeiten) auf die Methode store-and-forward gewechselt. Wobei das so ist, daß der switch entweder die eine oder die andere Methode verwendet und keine Mischung.

Inwzischen werden viele switche auf die eine oder andere Methode "festverdrahtet". Siehe dazu auch ein Cisco-Whitepaper.

lks
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (20)

Frage von Xaero1982 zum Thema Microsoft ...

Outlook & Mail
gelöst Outlook 2010 findet ost datei nicht (19)

Frage von Floh21 zum Thema Outlook & Mail ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Festplatten, SSD, Raid
M.2 SSD wird nicht erkannt (14)

Frage von uridium69 zum Thema Festplatten, SSD, Raid ...