4. Maximale Geschwindigkeit mit Breitband-Internet Inhaltsverzeichnis

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

Stichwort-Liste

• 4.1 Speicherpuffer
• 4.2 Paketgrößen
• 4.3 Safari

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.

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

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.

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.

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.

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.

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:

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.

---