Warum man TCP-Denken nicht auf UDP übertragen sollte

Tags:
Categories:
  • Warum man TCP-Denken nicht auf UDP übertragen sollte

Warum man TCP-Denken nicht auf UDP übertragen sollte?

Strukturunterschiede

TCP-Header
UDP-Header

TCP hat viele Konzepte: Verbindungsaufbau, Ressourcennutzung, Datenübertragung, zuverlässige Übertragung, Wiederholungs- und kumulative Bestätigungs-Wiedersendung, Zeitüberschreitungs-Wiedersendung, Prüfsumme, Flusskontrolle, Staukontrolle, maximale Segmentgröße, ausgewählte Bestätigung, TCP-Fenster-Skalierungsoption, TCP-Zeitstempel, erzwungene Datenübergabe, Verbindungsbeendigung.

All diese Fähigkeiten fehlen UDP weitgehend; es unterscheidet sich vom Link-Layer nur um die Fähigkeit, Anwendungsschicht-Ziele zu unterscheiden. UDP ist ausreichend einfach, was ausreichend Flexibilität bedeutet.

Wenn es passieren kann, wird es passieren

Murphys Gesetz:

Wenn es mehr als eine Möglichkeit gibt, etwas zu tun, und eine dieser Möglichkeiten zu einer Katastrophe führt, dann wird jemand genau diese Möglichkeit wählen.

Normalerweise wird UDP als geeignet für Spiele/Sprache/Video usw. dargestellt, wobei wenige fehlerhafte Pakete den Betrieb nicht beeinträchtigen. Warum ist UDP für diese Anwendungsfälle geeignet? Dass UDP in diesen Bereichen eingesetzt werden kann, bedeutet nicht, dass es die optimale Lösung ist. Es muss Probleme geben, die TCP nicht lösen kann, weshalb diese Dienste das funktionsarme UDP-Protokoll gewählt haben. Dass fehlerhafte Pakete den Betrieb nicht beeinträchtigen, bedeutet ausführlich, dass TCP auf fehlerhafte Pakete achtet und UDP nicht. UDP achtet mehr auf Echtzeitfähigkeit/Kontinuität. Die Besonderheit von UDP ist, dass es nicht auf die Faktoren achtet, auf die TCP achtet, und diese Faktoren beeinflussen die Echtzeitfähigkeit.

In der Code-Implementierung muss UDP nur einen Socket erstellen, an einen Port binden und kann dann mit dem Senden und Empfangen beginnen. Normalerweise ist, wenn der Socket benutzt ist, auch der Port verbraucht.

Daher kann ich UDP so verwenden:

  1. Zufällige Pakete an beliebige Ports beliebiger IPs senden, um zu sehen, welcher Port antwortet
  2. A sendet über Port A eine Anfrage an Port B von B; B antwortet über Port C an Port D von A
  3. A sendet über Port A eine Anfrage an Port B von B; B beauftragt C, die Antwort über Port C an Port D von A zu senden
  4. A sendet über Port A eine Anfrage an Port B von B, ändert jedoch die Quell-IP des gesendeten Pakets zu C; B wird die Antwort an C senden
  5. Beide Parteien vereinbaren jeweils 10 UDP-Ports zur gleichzeitigen Aufnahme und zum Senden

Diese Methoden funktionieren natürlich nicht in TCP, aber im UDP-Protokoll, solange es möglich ist, wird es jemand tun. Wenn man TCP-Denken auf UDP überträgt, ist das daher Idealismus; die Realität ist oft nicht vollständig von uns auflistbar.

Die UDP-Pakete sind sehr einfach und die Nutzung sehr flexibel. Ursprünglich gibt es kein Verbindungskonzept, das man selbst definieren muss. Einige Definitionsversuche konnten das Verbindungsrichtungsbeurteilungsziel nicht vollständig genau erreichen. Hier muss man etwas Fehlerakzeptanz zulassen, schließlich gibt es ursprünglich keine UDP-Verbindungsdefinition, und wenn die Definition von UDP-Verbindungen zwischen den Parteien nicht übereinstimmt, führt dies zwangsläufig zu einem Verhalten, das nicht den Erwartungen entspricht.

UDP aus Client-Sicht

Sprach-/Video-Anwendungen erzeugen häufig Paketverluste, aber unterschiedliche Arten von Paketverlusten beeinflussen den Betrieb unterschiedlich. Zum Beispiel, ob 30% der Paketverluste gleichmäßig verteilt sind oder alle in einem bestimmten Zeitraum auftreten, hat deutliche Unterschiede für das Erlebnis. Offensichtlich erwarten wir gleichmäßigere Paketverluste. Aber UDP hat keine Flusskontrollverhinderungsmethoden, und wie man Paketverluste erzeugt, gibt es einige Methoden. Obwohl UDP-Kommunikation oft als “bestmögliche Anstrengung” beschrieben wird, führen unterschiedliche Arten der “bestmöglichen Anstrengung” zu unterschiedlichen Ergebnissen.

UDP aus Sicht des Dienstanbieters

Bei einem TCP-Angriff muss der Client bestimmte Kosten tragen, Verbindungen erstellen und pflegen, d.h. der Angreifer muss bestimmte Kosten tragen. Aber bei einem UDP-Angriff sind die Kosten für den Angreifer viel geringer. Wenn der Angreifer die Bandbreite des Dienstanbieters verbrauchen will, ist UDP eine gute Methode. Zum Beispiel, wenn ein Dienst 100 GB unlimitierte Bandbreite kauft, mit einer Verarbeitungskapazität von nur 10 MB pro Sekunde, aber einer Empfangsgeschwindigkeit von 1 GB pro Sekunde, dann sind 90% des Anfrageverkehrs ungültig, aber dieser Verkehr ist nicht kostenlos. Der Dienstanbieter sollte solche Situationen vermeiden.

UDP aus Sicht des Betreibers

Eine erfolgreiche Kommunikation erfordert mehrere Endgeräte und Kommunikationskanäle. Immer im Fokus stehen der Server und der Client, aber die Perspektive des Betreibers ist ebenso wichtig. Bei DDoS-Angriffen interessieren wir uns oft für den Ressourcenverbrauch des Servers, tatsächlich sind jedoch auch die Ressourcen des Betreibers begrenzt. Der Server kann einfach nicht auf Anfragen antworten, aber der empfangene Datenverkehr hat bereits Bandbreite verbraucht, nur dass diese Ressource normalerweise dem Betreiber gehört. Wir verwenden im Lasttest oft den “Paketverlustrate”-Indikator, der den Paketverlust in der gesamten Kommunikationskette ausdrückt, nicht nur den Verlust auf Serverseite. Der Betreiber verliert auch Pakete. Aus Sicht des Betreibers hat der Dienstleister nur 1 MB/s Bandbreite gekauft, aber der Client sendet mit 1 GB/s Geschwindigkeit. Beide müssen nicht für die verschwendete Bandbreite bezahlen, der Betreiber trägt diese Kosten. Daher wird der Betreiber zwangsläufig versuchen, diesen Datenverkehr zu blockieren, d.h. das QoS von UDP. In TCP gibt es Staukontrolle, aber in UDP kann der Betreiber durch Paketverlust den Datenverkehr kontrollieren. In der Praxis ist der Betreiber noch einfacher und direkter, blockiert einfach den Datenverkehr von lang genutzten Ports, d.h. die UDP-Portblockade. Bei praktischen Tests von WeChat-Gesprächen wurde festgestellt, dass jeder Anruf vom Client mehrere Ports verwendet, wobei ein UDP-Port mit 6 UDP-Ports desselben Servers kommuniziert, was vermutlich der Portblockade des Betreibers entgegenwirken soll.

Zusammenfassung

Die Flexibilität von UDP zeigt sich darin, dass es für die Erreichung eines Ziels mehrere Implementierungswege gibt, die alle legal sind, solange am Ende eine stabile Kommunikation erreicht wird, unabhängig davon, wie sehr sie sich von TCP unterscheiden. Deshalb können wir TCP-Konzepte nicht vollständig auf UDP übertragen. Selbst wenn wir für das Produktdesign eine neue UDP-Verbindungsdefinition erschaffen, sollten wir Fehler vorhersehen und zulassen können, schließlich ist “Fehler zulassen” die Kernfunktion von UDP, kein Nachteil, sondern ein von Diensten bewusst gewähltes Protokoll-Kernmerkmal, nicht ein unvermeidlicher Nachteil.

Weitere Lektüre