Ich bin ein Entwickler, der sich in der guten und schlechten Situation befindet, einen Netzwerkdienst zu entwickeln, der von iPhone-Clients stark beansprucht wird. Die iPhone-App wurde im vergangenen Jahr über 10 Millionen Mal heruntergeladen, und jetzt bringe ich die Benutzer online, damit sie miteinander interagieren können.
Ich möchte die TCP-Implementierung für die Server optimieren, die meinen TCP-basierten Netzwerkdienst hosten. Die gesendete Größe pro Anfrage wird „klein“ sein (sagen wir < 256 Bytes). OK, Sie haben es herausgefunden, es ist ein Spieleserver (Schock!).
Zu Ihrer Information: Ich bin für diesen speziellen Dienst nicht an UDP (oder einer zuverlässigen Schicht über UDP, wie sie beispielsweise in ENet und RakNet zu finden ist) interessiert, da die Spiele nicht Quake-ähnlich sind; alle Pakete müssen zuverlässig empfangen werden, und dafür wurde TCP entwickelt. Daher werden die Verbindungen zwischen dem iPhone-Client und dem Dienst „langlebig“ sein (so lange wie möglich – zum Teufel mit Tunneln und Aufzügen!).
Zu Ihrer Information: Ich führe den Dienst auf einem 100-Mbit/s-Uplink auf Servern aus, auf denen Linux 2.6.18-164.9.1.el5 läuft.
Meine Ziele sind, gleichzeitig:
- die Latenz so gering wie möglich zu halten; und
- Minimieren Sie die Speichermenge, die pro verbundenem Client verwendet wird.
Es gibt einegroßAnzahl der TCP-bezogenen Knöpfe zum Optimieren! Nach einigen grundlegenden Recherchen scheint es, dass die meisten Leute empfehlen, die Einstellungen so zu belassen, wie sie sind. Es gibt jedoch eine Reihe von Einstellungen, dieerscheinenals ob sie für bestimmte Fälle angepasst werden müssten. Ich weiß, das ist ein bisschen vage, und deshalb bitte ich um Hilfe.
Folgende Punkte sind bei der Optimierung kleiner Anfragen/Antworten in instabilen Netzwerken zu berücksichtigen, während der Speicherbedarf so weit wie möglich minimiert werden soll:
- verfügbarer Speicher für die TCP/IP-Implementierung
- Festlegen der Option „nodelay“ (Deaktivieren des Nagle-Algorithmus, da dies ein Semi-Echtzeit-Spieleserver ist)
- Algorithmen zur Überlastungskontrolle
- usw. (was sonst?)
Betrachten Sie TCPAlgorithmen zur Überlastungskontrolle:
- reno: Traditionelles TCP, das von fast allen anderen Betriebssystemen verwendet wird
- kubisch: CUBIC-TCP
- BIC: BIC-TCP
- htcp: Hamilton TCP
- vegas: TCP Vegas
- Westwood: optimiert für verlustbehaftete Netzwerke
Meine Server sind standardmäßigbicdessen „Ziel es ist, ein Protokoll zu entwickeln, das seine Leistung über Hochgeschwindigkeits-Fernnetze auf mehrere zehn Gigabit pro Sekunde skalieren kann und gleichzeitig ein hohes Maß an Fairness, Stabilität und TCP-Freundlichkeit beibehält.“
Allein aus der kurzen Beschreibung,Westwoodklingt passender, da es „dafür gedacht ist, Produktpfade mit großer Bandbreitenverzögerung (große Pipes), mit potenziellem Paketverlust aufgrund von Übertragungs- oder anderen Fehlern (undichte Pipes) und mit dynamischer Belastung (dynamische Pipes) besser handhaben zu können“.
Gehe ich hier zu sehr ins Detail oder ist das normal?
Für welche Dinge optimiert ihr TCP/IP im Allgemeinen? Wie? Welche Faustregeln muss man kennen?
Welche weisen Worte haben Sie für meinen speziellen Fall?
Vielen Dank!
Antwort1
Wie Sie herausgefunden haben, ist die TCP-Überlastungskontrolle ein ziemlich komplizierter Bereich.
In diesem speziellen Fall sollten Sie aufgrund der kleinen Anfragen versuchen, die Verbindungen so lange wie möglich offen zu halten, da für eine Verbindung pro Anfrage jeweils fünf Pakete benötigt werden, während Sie den Durchschnitt auf etwas mehr als zwei Pakete senken können, wenn Sie die Verbindungen aufrechterhalten.
NODELAY ist das Richtige für einen Spieleserver. Sie möchten Ihre 256 Bytes sofort geliefert bekommen und das ist kein ganzes Segment. Daher macht Nagle eine Pause, sofern Sie nicht NODELAY verwenden.
Wenn Ihre Server über jede Menge Arbeitsspeicher verfügen, sind die Speicheroptionen keine große Sache, neue Kernel haben sie richtig.
Was die Algorithmen zur Überlastungssteuerung betrifft, haben Sie Westwood entdeckt. Die andere Option ist CUBIC. Sie können einfach einen verwenden oder ein wenig recherchieren und vergleichen. Das könnte ziemlich viel Arbeit bedeuten, aber für 10 Millionen Kunden lohnt es sich. Ich würde also versuchen, eine Simulation mit einem Verkehrsgenerator auf einem oder drei Macs auszuführen (da sie dieselbe TCP-Implementierung wie das Telefon haben), einer Linux-Box dazwischen, die als Router fungiert (mehr dazu in Kürze) und einem Ihrer Server, um zu sehen, wie es läuft.
Nun sollte die mittlere Linux-Box laufenns-3So können Sie einen komplizierteren Pfad als nur einen Ethernet-Switch simulieren. Anschließend erfassen Sie einige Paketspuren am sendenden Ende der TCP-Verbindungen und analysieren diese mittcptraceoder die tcptrace-Grafikmodi von Wireshark. Die tcptrace-Dokumentation ist eine gute Einführung in die Analyse des TCP-Überlastungsverhaltens.