6. Leistungsüberlegungen

6. Leistungsüberlegungen

Stoßweiser Verkehr kann oft zu zeitlich korrelierten Paketverlusten führen; dies kann wiederum zu suboptimalen Antworten von Überlastungskontrollern in Protokollen führen, die über UDP laufen. Um dies zu vermeiden, SOLLTEN UDP-Proxys danach streben, eine Erhöhung der Stoßhaftigkeit von UDP-Verkehr zu vermeiden; sie SOLLTEN Pakete NICHT in die Warteschlange stellen, um das Batching zu erhöhen.

Wenn das über UDP laufende Protokoll, das geproxt wird, Überlastungskontrolle verwendet (z. B. [QUIC]), unterliegt der geproxte Verkehr mindestens zwei verschachtelten Überlastungskontrollern. Die zugrunde liegende HTTP-Verbindung DARF die Überlastungskontrolle NICHT deaktivieren, es sei denn, sie verfügt über eine Out-of-Band-Möglichkeit, mit absoluter Gewissheit zu wissen, dass der innere Verkehr überlastungskontrolliert ist.

Wenn ein Client oder UDP-Proxy mit einer Verbindung, die einen UDP-Proxying-Anfragestream enthält, die Überlastungskontrolle deaktiviert, DARF er auf dieser Verbindung KEINE Unterstützung für Explicit Congestion Notification (ECN) [ECN] signalisieren. Das heißt, er MUSS alle IP-Header mit dem Not-ECT-Codepoint markieren. Er KANN weiterhin ECN-Feedback über QUIC ACK_ECN-Frames oder das TCP ECE-Bit melden, da der Peer die Überlastungskontrolle möglicherweise nicht deaktiviert hat.

Wenn das über UDP laufende Protokoll, das geproxt wird, Verlustwiederherstellung verwendet (z. B. [QUIC]), und die zugrunde liegende HTTP-Verbindung über TCP läuft, unterliegt der geproxte Verkehr mindestens zwei verschachtelten Verlustwiederherstellungsmechanismen. Dies kann die Leistung verringern, da beide manchmal unabhängig voneinander dieselben Daten erneut übertragen können. Um dies zu vermeiden, SOLLTE UDP-Proxying über HTTP/3 durchgeführt werden, um die Nutzung des QUIC DATAGRAM-Frames zu ermöglichen.

6.1. MTU-Überlegungen

Bei Verwendung von HTTP/3 mit der QUIC-Datagramm-Erweiterung [QUIC-DGRAM] werden UDP-Nutzlasten in QUIC DATAGRAM-Frames übertragen. Da diese nicht fragmentiert werden können, können sie nur Nutzlasten bis zu einer bestimmten Länge tragen, die durch die QUIC-Verbindungskonfiguration und die Path MTU (PMTU) bestimmt wird. Wenn ein UDP-Proxy QUIC DATAGRAM-Frames verwendet und eine UDP-Nutzlast vom Ziel empfängt, die nicht in einen QUIC DATAGRAM-Frame passt, SOLLTE der UDP-Proxy die UDP-Nutzlast NICHT in einer DATAGRAM-Kapsel senden, da dies die Ende-zu-Ende-Unzuverlässigkeitseigenschaft zunichtemacht, von der Methoden wie Datagram Packetization Layer PMTU Discovery (DPLPMTUD) abhängen [DPLPMTUD]. In diesem Szenario SOLLTE der UDP-Proxy die UDP-Nutzlast verwerfen und eine ICMP Packet Too Big-Nachricht an das Ziel senden; siehe Abschnitt 3.2 von [ICMP6].

6.2. Tunneln von ECN-Markierungen

UDP-Proxying erstellt keinen IP-in-IP-Tunnel, daher gilt die Anleitung in [ECN-TUNNEL] zur Übertragung von ECN-Markierungen zwischen inneren und äußeren IP-Headern nicht. In UDP-Proxying-Tunneln gibt es keinen inneren IP-Header.

Beachten Sie in dieser Spezifikation, dass UDP-Proxying-Clients nicht die Fähigkeit haben, die ECN-Codepoints auf UDP-Paketen zu steuern, die der UDP-Proxy an das Ziel sendet, noch können UDP-Proxys die Markierungen jedes UDP-Pakets vom Ziel an den UDP-Proxy kommunizieren.

Ein UDP-Proxy MUSS ECN-Bits im IP-Header von UDP-Paketen ignorieren, die vom Ziel empfangen werden, und er MUSS die ECN-Bits auf Not-ECT auf UDP-Paketen setzen, die er an das Ziel sendet. Diese stehen in keiner Weise in Beziehung zu den ECN-Markierungen von Paketen, die zwischen Client und UDP-Proxy gesendet werden.