4. Maximale Geschwindigkeit mit Breitband-Internet Inhaltsverzeichnis

Es gibt diverse Möglichkeiten, Mac OS X für schnellere Internetverbindungen einzustellen.

In den folgenden Abschnitten werden bestimmte Netzwerk-Werte diskutiert und wie man sie setzen kann.

Ab 10.4 ist es jedoch Standard, solche Arbeiten nicht mehr mit einem StartupItem, sondern elegant mit einem LaunchDaemon zu erledigen.

Alternativ dazu kann man diese Netzwerk-Werte auch in der Datei /etc/sysctl.conf (danke an Michael Schäl, AUGE e.V.) definieren. Dabei verwendet man Zeilen wie beispielsweise net.inet.tcp.sendspace=49152. (Mehr dazu unten.) Die Datei ist normalerweise noch nicht vorhanden und da sie während des Rechnerstarts gelesen wird, sollte der Besitzer root und die Gruppe wheel sein und die Rechte 0644.

Ab 10.6 bieten die Sytem-Einstellungen Einstellmöglichkeiten für die MTU-Werte auch für das Funknetz.

Stichwort-Liste

4.1 Speicherpuffer Inhaltsverzeichnis

Wie die meisten Betriebssysteme nutzt Mac OS X standardmäßig nicht vollständig die Vorteile von Breitband-Internetzugängen beispielsweise DSL.

Bei Leopard sind die Puffergrößen schon passend groß eingestellt.

Das (nicht mehr verfügbare) vollautomatische StartupItem (so etwas ist seit 10.4 Tiger veraltet) "Broadband Optimizer" konnte die Netzwerk-Einstellungen von Mac OS X so verändern, daß es optimal eingestellt ist für DSL. In der werksseitigen Einstellung ist es auf Modemzugänge optimiert.

Die technische Seite sieht so aus, daß hiermit bestimmte Speicherpuffer für den Internetverkehr größer eingestellt werden.

Mit dem Programm namens Terminal kann man nachsehen, ob die Werte wie gewünscht eingestellt sind:

Mit sysctl -a lassen sich alle Zustandswerte des Kernels (Betriebssystem-Kern) anzeigen.

Da wir uns nur für vier bestimmte Werte interessieren, kann man die ausgegebene Liste auch entsprechend gefiltert anzeigen lassen:

sysctl -a | grep -E tcp.sendspace\
\|tcp.recvspace\
\|udp.recvspace\
\|tcp.delayed_ack

Das Zeichen "\" jeweils am Ende der Zeilen ermöglicht diese mehrzeilige Befehlseingabe. Es kommentiert den Zeilenumbruch aus.
Das Zeichen "\" vor "|" ermöglicht die Oder-Verknüpfung innerhalb des grep Kommandos.
Das Zeichen "|" vor grep sorgt dafür, daß die Ausgabe des ersten Kommandos (sysctl) als Eingabe für das zweite Kommando (grep) verwendet wird.

Wenn die Ausgabe dann so aussieht,

net.inet.tcp.sendspace: 65536
net.inet.tcp.recvspace: 65536
net.inet.tcp.delayed_ack: 0
net.inet.udp.recvspace: 73728

dann sind die neuen Werte tatsächlich aktiv.

Man kann mit anderen Werten herumexperimentieren, indem man Zeilen wie diese eingibt:

sudo sysctl -w net.inet.tcp.sendspace=49152

4.2 Paketgrößen Inhaltsverzeichnis

Ein weiterer Punkt ist der sogenannte MTU-Wert. Wenn man DSL nutzt, dann sollte man diesen Wert auf 1492 setzen. Das liegt daran, daß Ethernet maximal Pakete der Größe 1500 transportieren kann und das Protokoll PPPoE 6 Einheiten und PPP nochmal 2 Einheiten braucht. Der Standardwert 1500 ist zu groß und kann bei manchen Webseiten zu Problemen führen.

Falls der Rechner direkt mit dem DSL-Modem verbunden ist, dann verwendet er automatisch die richtige Paketgröße, weil er selbst aktiv am PPPoE-Protokoll beteiligt ist.

Wenn jedoch ein Router B (oder ein anderer Rechner B), der PPPoE macht, zwischen Rechner A und dem DSL-Modem liegt, dann muß man den Wert an Rechner A per Hand um die 8 Bytes heruntersetzen, um genug Platz in den Nutzdaten zu lassen.

Zwischen Rechner A und Router B werden die IP-Pakete über Ethernet transportiert. Zwischen Router B und DSL-Modem werden sie jedoch nochmal zusätzlich in PPP- und in PPPoE-Rahmen eingepackt. Man läßt also genug Luft für dieses Protokoll-Tunneln, um Fragmentierung zu vermeiden.

Die meisten modernen Server erlauben keine Fragmentierung mehr und versuchen die Path-MTU (der kleinste MTU-Wert aller Schnittstellen auf dem Übertragungsweg) herauszufinden, auf die sie ihre Paketgröße anpassen.

Ferner wird über kurze ICMP-Nachrichten ausgehandelt, daß die Paketgröße passend verkleinert wird, wenn ein Paket aufgrund seiner Größe nicht am Stück verschickt werden konnte.

Wenn man eine Webseite aufruft, dann findet eine Verhandlung statt zwischen dem Mac und dem Webserver, der die Webseite bereithält, um den MTU-Wert festzulegen. Da der Standardwert 1500 Bytes auf Mac OS X (und anderen Betriebssystemen) ist, handelt der Webserver 1500 Bytes aus. Daher wird der Webserver ungeachtet der MTU-Größe, die auf dem DSL-Router eingestellt ist, Pakete der Größe 1500 schicken.

Der Grund, warum nun einige Seiten nicht vollständig laden, ist, daß der Router die IP-Pakete fragmentiert, also in passende kleinere Pakte zerlegt, wenn die Mac-MTU falsch eingestellt ist, und daher ein Paket größer als 1492 Bytes vom Mac zum Router geschickt wurde.

Es wird durch dieses Fragmentieren die Verbindung weniger effektiv genutzt, also die Nutzdaten langsamer übertragen.

Diese Fragmentierung, die sicherstellt, daß zu große Pakete trotzdem zugestellt werden, indem sie auf mehrere passende verteilt werden, findet auf dem Rückweg vom Webserver zum Router nicht statt. Wenn der DSL-Router nun ein Paket größer als 1492 Bytes vom Webserver bekommt, dann schickt er eine ICMP-Nachricht an den Webserver, die diesem mitteilt, er habe ein zu großes Paket geschickt und daß er das Paket noch einmal schicken soll mit einer kleineren MTU-Größe.

Hier wird durch solche ungenutzten Pakete und das erneute Schicken der Daten die Verbindung weniger effektiv genutzt, also die Nutzdaten langsamer beziehungsweise gar nicht übertragen.

Ein Problem tritt nun auf, weil viele Webserver ICMP-Nachrichten blocken, also auch die Nachricht, daß das Paket zu groß war, nicht erhalten, wodurch der Server weiterhin 1500-Byte-Pakete schickt. Diese Pakete werden vom Router nicht weitergeleitet (gedroppt) und als Folge daraus die angeforderte Webseite nicht geladen. Wenn der Webserver korrekt eingestellt ist und ICMP-Nachrichten nicht geblockt werden, dann würde der Server seine MTU anpassen (verringern) und die Daten solange erneut schicken, bis die Seite komplett lädt.

Eine nur teilweise geladene Seite tritt auf, wenn die ersten vom Webserver geschickten Daten-Pakete unterhalb des 1492-Byte Maximums liegen und dann ein Paket kommt, das dieses Maximum überschreitet. Der Webserver schickt dann wieder und wieder dieses übergroße Paket erneut, was sich in einer nur teilweise geladenen Seite und der "Warte auf Antwort …"-Nachricht in der Statuszeile des Webbrowsers bemerkbar macht.

Das automatische Umschalten auf die passende kleinere Paketgröße funktioniert in so einem Fall also nicht. Um dem vorzubeugen, kann man die maximale Paketgröße von Hand klein genug einstellen. Und im Fall, daß die Automatik doch funktionieren sollte mit dem einen oder anderen Webserver, vermeidet man dadurch zu große Pakete, die nicht ankommen würden und noch einmal verkleinert verschickt werden müssten.

Daher sollte man unter den Systemeinstellungen unter Netzwerk und Ethernet den MTU-Wert manuell auf 1492 setzen. Für Airport hingegen gibt es erst seit 10.6 eine so einfache Einstellbarkeit dieses Wertes im Betriebssystem. Hier mußte man sich vorher mit einem StartupItem behelfen, welches den Befehl ifconfig en1 mtu 1492 ausführt.

Hier repräsentiert en1 die Funkschnittstelle und en0 wäre die Ethernet-Schnittstelle.

Solch ein StartupItem kann man erstellen mit beispielsweise Hilfe von Apples Anleitung, wobei in einer Zeile die Auskommentierung aufgehoben werden muß und 1490 gegen 1492 getauscht werden sollte, so daß dann anstelle von # /sbin/ifconfig en1 mtu 1490 dort /sbin/ifconfig en1 mtu 1492 steht. Eventuell liefert ein noch geringerer Wert, beispielsweise 1484, bessere Ergebnisse. Am besten ein wenig ausprobieren.

Die einfachere Möglichkeit, so ein StartupItem zu erstellen ist, das oben genannte Werkzeug RMAC zu verwenden. Dabei sollte man die MTU-Werte von en0 und en1 auf 1492 setzen und auch gleich einige der Werte einstellen, die Broadband Optimizer (siehe oben) vergeben würde, falls Broadband Optimizer noch nicht installiert ist, also:

net.inet.tcp.sendspace: 65536
net.inet.tcp.recvspace: 65536
net.inet.udp.recvspace: 73728

Hier sind einige interessante Links zum Thema, die mir als Quelle dienten:

PMTU (Path MTU) Discovery

Cisco: Why the MTU Size Must Be Changed

macosxhints: How to create a MTU folder in Library

myNetWatchman: Optimal MTU configuration for PPPoE ADSL Connections

macosxhints: 10.3: MTU fixes for Ethernet and Airport connections

Firewall-Fehleinstellung

Die Firewall von Mac OS X hat die Möglichkeit, einen sogenannten Tarnmodus zu aktivieren, der technisch darin besteht, daß ein Teil (Typ 8 "Echo-Anfragen") der ICMP-Nachrichten auf diesem Rechner ignoriert (geblockt) werden. Damit bricht man den Internetstandard und macht seinen Rechner teilweise inkompatibel, denn laut Internetstandard muß jeder Rechner im Internet eine ICMP-Echo-Server-Funktion implementieren, die Echo-Anfragen akzeptiert und entsprechende Echo-Antworten zurückschickt.

Insbesondere kann ein Rechner, dessen Tarnmodus alle ICMP-Nachrichten blockt, keine Paketgrößen aushandeln und man muß daher damit rechnen, daß einige Verbindungen (Aufruf von Seiten und dergleichen) schlicht und ergreifend nicht funktionieren.

Der Tarnmodus wird gerne als Sicherheitsfunktion verkauft, was aber technisch nicht der Fall ist.

4.3 Safari Inhaltsverzeichnis

Man kann Safaris Debug-Menü mit defaults write com.apple.Safari IncludeDebugMenu 1 ein- und mit defaults write com.apple.Safari IncludeDebugMenu 0 wieder ausschalten, wobei die Änderung erst beim nächsten Starten von Safari wirksam wird. Mit dem Debug-Menü kann unter anderem eingestellt werden, als welcher Browser sich Safari zu Erkennen gibt.

Safari-Versionen vor Version 1.3 hatten eine Verzögerung, die dazu dient, eine Seite erst anzuzeigen, wenn alle Informationen geladen wurden. Pauschal geht Safari von einer festen Zeit dafür aus, egal wie lange es tatsächlich dauert. Bei einem schnellen Internetzugang werden daher eventuell Seiten nicht sofort dargestellt, obwohl sie schon vorliegen.

Man kann diese Verzögerung einstellen. Bringt man sie auf 0.0001 Sekunden, dann zeigt Safari sofort alles an, was er geladen hat. Der Terminal-Befehl defaults write com.apple.Safari WebKitInitialTimedLayoutDelay 0.0001 setzt die Verzögerung auf eine Zehntausendstelsekunde. Man kann mit dem Wert experimentieren, indem man die Zahl austauscht. Safari nutzt den neuen Wert erst beim nächsten Start von Safari. Ein Wert von 0.25 entspricht augenscheinlich dem normalen Verhalten von Safari in der Version 2.0. Wenn Teile der Seite fehlen, beispielsweise Layoutinformationen eines externen Stylesheets, dann ändert sich das Aussehen der Seite während des Ladens.

Mit defaults read com.apple.Safari WebKitInitialTimedLayoutDelay kann man sich den aktuellen Wert anzeigen lassen.

Mit defaults delete com.apple.Safari WebKitInitialTimedLayoutDelay kann man die Eigenschaft wieder Entfernen.

Safari ab Version 1.3 hat anscheinend eine dynamische Verzögerung, die dazu dient, jeweils zum frühesten sinnvollen Zeitpunkt, wenn ausreichend viel geladen wurde, die Seite darzustellen. Der oben beschriebene Wert wird daher von den neueren Versionen von Safari ignoriert.

Valid XHTML 1.0!

Besucherzähler


Latest Update: 11. September 2015 at 19:51h (german time)
Link: osx.macmark.de/osx_broadband.php