Praktische (gegenüber theoretischer) maximaler Grenze der TCP-Paketgröße

465
MBak

Ich bin ein Webentwickler, der in der Branche ziemlich neu ist. Ich wurde mit einer Kodierungsherausforderung für ein Vorstellungsgespräch konfrontiert, bei der ich ein Nachrichtensystem entwerfen und ein System für den Umgang mit Nachrichten, fehlerhaften Nachrichten, verschiedenen Nachrichtentypen, Statusprotokollierung usw. entwerfen muss.

Meine Frage bezieht sich auf die Paketgröße über TCP.

Eingehende Nachrichten haben eine Rate von 10.000 Nachrichten pro Sekunde und eine Größe von 2 KB pro Nachricht. Ich habe versucht, die maximale, maximal sichere oder maximal praktikable Paketgrößenbegrenzung zu finden. Ich habe an mehreren ungeprüften Stellen (dh nicht in der technischen Dokumentation) gesehen, dass die maximale theoretische Größe 64 KB beträgt. Ist das korrekt? In diesem Fall würde mein Beispiel für das Senden von 2-KB-Nachrichten leicht in ein einzelnes Paket passen und die Komplexität dieses Systems reduzieren.

Wenn 64 KB eine falsche Zahl ist, welche wäre die richtige Zahl? Außerdem versuche ich nicht nur, die maximale theoretische Größe zu verstehen, sondern die maximale praktische Größe. Ich möchte Randfälle behandeln, in denen Nachrichten etwas größer als die angestrebten 2 KB sein können, und Raum für die verschiedenen Kopfzeilen lassen, die TCP benötigt.

0

1 Antwort auf die Frage

3
Spiff

Bei TCP / IP-Paketgrößen war Ethernet schon immer einflussreich. Ethernet hat eine Standard-MTU von 1500 Bytes, die nach einem typischen IPv4-Header-Overhead von 20 Bytes und einem typischen modernen TCP-Header-Overhead von 32 Bytes (früher 20 Bytes, aber wir fügen heute eine 12-Byte-Zeitstempeloption hinzu) zu einem TCP Maximale Segmentgröße von 1448 Byte .

PPPoE, das bei DSL-basierten ISPs beliebt ist, fügt weitere 8 Byte Overhead hinzu. TCP-Verbindungen, die eine PPPoE-Verbindung durchlaufen, enden mit einem TCP-MSS von 1440 Byte . Andere Technologien können zusätzlichen Aufwand verursachen.

Die meisten modernen TCP / IP-Stacks führen "Path MTU Discovery" (PMTUD) aus, sodass sie sich niemals auf die IP-Fragmentierung verlassen müssen. Leider blockieren einige Sites die ICMP-Meldungen, die für PMTUD erforderlich sind, und erzeugen versehentlich "PMTUD-Schwarze Löcher", bei denen PMTUD nicht funktioniert. Damit sich Personen, die sich hinter schwarzen Löchern von PMTUD befinden, immer noch eine Verbindung zu ihren Diensten herstellen lassen, entscheiden sich Google-Websites für einen sehr konservativen TCP-MSS von 1380 Bytes (das letzte Mal, als ich das überprüft habe).

Ich würde also sagen, man könnte ein ziemlich gutes Argument vorbringen: Wenn Sie die Schreibweise Ihrer Anwendung anpassen möchten, stellen Sie sicher, dass sie meist nur ein einzelnes Paket füllen und Ihre Schreibvorgänge nicht größer als 1448 Bytes und vielleicht auch nicht sind größer als 1380 Bytes.

IPv4-Datagramme können bis zu 64 KibiBytes groß sein, aber zu wenige Pfade im Internet verfügen über eine 64-KB-MTU, so dass diese Anzahl für die meisten Paketgrößenplanungen irrelevant ist. Ihr theoretischer Messaging-Protokoll-Server ist wahrscheinlich an ein Ethernet-ähnliches Netzwerk angeschlossen, das wahrscheinlich standardmäßige 1500-Byte-Frames verwendet, sodass der IP-Stack Ihres eigenen Servers diesen 64-KB-Schreibvorgang in 46 oder so separate Pakete fragmentieren muss, bevor er überhaupt mit der Übertragung beginnen könnte am ersten Sprung. Selbst Ethernet-Netzwerke, die für die Verwendung von nicht standardmäßigen "Jumbo-Frames" eingerichtet sind, werden normalerweise mit 9000 Byte großen MTUs ausgeliefert. Ich kann nicht einmal eine physikalische / Datenverbindung (Layer 1/2) -Netzwerktechnologie nennen, die 64-KB-MTUs zulässt. Vielleicht IP über Thunderbolt.

Sie sagen also, während TCP theoretisch bis zu 64 KB Daten enthalten kann, kann kein Netzwerk diese Größe übertragen, richtig? MBak vor 5 Jahren 0
@MBaka Ein einzelnes IP-Datagramm kann 64 KB groß sein, aber die große Mehrheit der Netzwerke würde die IP-Schicht benötigen, um dieses Datagramm in viele kleinere Pakete zu fragmentieren und auf diese Weise zu übertragen, wobei die IP-Layer-Netzwerksoftware auf dem Zielhost sie wieder zusammenbaut Das 64-KB-Datagramm wird vor dem Weiterleiten des Stapels weitergeleitet. Spiff vor 5 Jahren 0
Ich habs! Wenn dies der Fall ist, warum wurde das IP-Datagramm sogar so konzipiert, wenn Netzwerke dies nicht unterstützen können, ohne es weiter zu fragmentieren? MBak vor 5 Jahren 0
@MBaka Vor Jahrzehnten, als IPv4 entwickelt wurde, dachten die Designer, MTUs würden wachsen und ließen Raum für dieses Wachstum. Es ist irgendwie überraschend, dass die 1500-Byte-MTU von Ethernet so lange geblieben und einflussreich ist. Spiff vor 5 Jahren 0
Das macht Sinn. Danke für die Antwort und das Wissen! MBak vor 5 Jahren 0