Zitat:
Zitat von Pitland Auf jeden Fall muss das TuneUp runter. Das würde die Einstellungen nachträglich wieder verändern.
Ist gut, das du dir dann weitere Hilfe dazuholst.
Bis dann. |
-------------------------------------------------------
Habe eben von meinem Bekannten folgende Vorabmail erhalten:
Hallo Edgar,
anbei ein Forumsbeitrag, den ich zu diesem Thema gefunden habe. Alles recht technisch, aber die Grundaussage steht in den letzten 3 Absätzen. Wir unterhalten uns hierzu nochmal.
Gruß,
Heiko
-----------------------------------
Re: Fritzbox hat MTU=1500, PPPoe dagegen 1492 -schlimm?
--------------------------------------------------------------------------------
Die Geschichte der MTU ist eine Geschichte voller Missverständnisse
Zitat:
Zitat von NOC@IB2
da das ja ein maximum Wert ist, sollte doch der client eine automatische anpassung vornehemen, oder?
In einer perfekten Welt ja. Leider gibt es genügend hirntote wannabee-Firewall-Cowboys, die nichteinmal die rudimentärsten Kenntnisse des IP-Protokolls, und im besonderen ICMP, besitzen. Deshalb blocken sie ICMP komplett. Das trifft auf quasi alle Personal-Firewalls zu, weil sie dem Benutzer damit weißmachen wollen, dass, wenn er auf ein Echo-Request kein Echo-Reply schickt ("Ping beantworten"), er damit unsichtbar ist (das alleine ist schon so dumm, da gehen einem die Tischkanten bei aus - wäre da wirklich niemand, bekäme der Sender vom davorliegenden Router ein "Destination unreachable" zurück, so läuft es in einen Timeout, was für den Sender sovie bedeutet wie "Da ist was, aber es ist gerade kaputt oder versucht sich zu verstecken").
Und dann gibt es noch hirntote Admins auf der Gegenseite.
Mal grundsätzlich. Was passiert, wenn ich ein Paket sende und es ist zu groß (MTU zu hoch):
Der Router, der das nimmer weiterschicken kann, weil die Leitung "zu dünn" ist, würde es fragmentieren, also aus einem Paket zwei machen, damit es durch die Leitung passt.
Das erfordert allerdings Rechenkraft, davon hat der Router nicht unendlich, also ist das prinzipiell keine so gute Idee. Damit wir die Router schonen setzen wir deshalb bei jedem Paket das DF-Bit, das sagt dem Router "Mich darfst du nicht fragmentieren".
Wenn nun ein solches Paket ankommt, und der Router kann es nicht weiterschicken, schaut er nach, von wem das Paket kommt, sendet dort ein "Dest. unreachable - must fragment but DF-Bit set" hin und wirft das Paket dann weg. Diese Nachricht wir als ICMP-Nachricht gesendet, denn für soetwas gibt es ICMP.
Wenn der Sender nun aber ICMP stumpf blockt wird er diese Nachricht nie bekommen, und so erfährt er nie, dass sein Paket weggeworfen wurde.
Zitat:
wenn der router 1492 hat mein client 1500 und mein isp 1400, dann ist doch der mtu sowieso auf 1400 sync., oder?
Das Problem tritt klassisch da auf, wo der ISP die Pakete über L2TP zugeführt bekommt.
Praktisch liegt die MTU immer bei 1500 Byte, wenn man PPPoE nutzt fallen nochmals 8 Byte PPPoE-Overhead pro IP-Paket an, macht also 1492 B. Wenn dein ISP via ZISP die Pakete bekommt fällt nochmals Overhead an. Aber eigentlich sollte das schon während der PADS ausgehandelt werden, denn es ist im Protokoll vorgesehen, dass die MTU mitübergeben wird, das machen die ISPs auch heutzutage.
Um es kurz zu machen:
Man sollte am besten gar nicht an der MTU herumspielen, das ist heute kaum mehr vonnöten, wenn der ISP sein Netz unter Kontrolle hat. Außerdem kann er auch noch bei Three-Way-Handshake bei TCP-Verbindungen eingreifen, sodass erst gar keine größere MSS (MaximumSegmentSize, das sind die eigentlichen Nutzdaten, also die MTU abzüglich der 20 B IP- und der 20 B TCP-Header) vereinbart werden kann.
Das einzige, das man, wenn man Wintendo benutzt, anpassen sollte ist das RWIN. Besonders bei Win9x limitiert dieses nämlich bei hohen Datenraten.
Das RWIN gibt an, nach wieviel Daten ein ACK gesendet werden soll, das sagt dem Sender soviel wie "Jo, alles da, kannst weiter senden". Per default kann dieses nicht höher als rund 64 KB sein (default bei Windows mit NT-Kernel). Es gibt allerdings die Möglichkeit, Windows-Scaling zu nutzen und das RWIN sozusagen unendlich hoch zu setzen.
Sollte dein RWIN zu klein sein, und die Latenz relativ hoch, verringert sich dann auch dein Downstream, wenn du nämlich mehr ACKs senden müsstest, als dein Upstream das zulässt.
Nun könnte man sagen "OK, setze ich es halt auf unendlich hoch und bestätige somit nur ein Mal, auch wenn ich GB-weise Daten bekomme". Das wäre auch unklug, denn auf TCP gibt es keine Felerkorrektur, nur eine Fehlererkennung.
Wäre nun nur ein einziges Paket "kaputt" würde das gesamte RWIN weggeworfen werden, und es müsste alles nochmals übertragen werden.
Wer nun weiterhin "Extremtuning" bei ADSL betreiben möchte, dem sei auch dazu geraten, seine MSS als Vielfaches von 48 zu setzen, denn bei ADSL wird ATM zwischen Modem und DSLAM benutzt, und ATM hat eine fixe Zellengröße von 53 B, wobei 5 B Header sind, macht 48 B Payload.
Wintendo macht das per defaul, indem es die MTU auf 1480 B setzt, was einer MSS von 1440 B entspricht, und das sind 30 * $Payload (30 * 48 = 1440).
In der Praxis ist das aber von eher geringer Bedeutung, und die Gefahr, dass man hier "Kaputtoptimiert" aka "Verschlimmbessert" ist recht groß.
Deshalb - wenn alles OK ist, du keine Probleme hast auf Seiten wie
www.gmx.de oder
www.postbank.de zu kommen, und du auch problemlos Mails, die größer als rund 2 KB sind über deinen Anschluß versenden kannst, lass die Finger von Werten, wenn du nicht weiß, was der Parameter bewirkt.
Bei Wintendo ist das nämlich wirklich dumm geregelt, du musst jedesmal neu starten, wenn du etwas änderst, und das zieht sich dann ewiglich hin, und der Leistungsgewinn ist meist kaum messbar.
Früer war das, wie gesagt, recht schwierig, zum einen, weil die ISPs falsche oder gar keine MTU bei der PPPoE-Aushandlung mitgegeben haben, oder weil der Client damit nichts anzufangen wusste und das ignoriert hat. Dem ist heute nicht mehr so.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxx
[B][COLOR="Blue"]Achim, was hältst
DUdavon?