Warum ist ein SSH-Socks5-Proxy besser als ein normaler Socks5-Proxy?

Ich habe im letzten Monat versucht, einen Proxy-Tunnel für Spiele einzurichten, und habe (für mich) ein sehr seltsames Problem festgestellt.

Derzeit verwende ich einen Socksifier, um den connect () -Befehl auf dem Socket eines Spiels umzuleiten / zu bearbeiten, damit er durch unsere Socks5-Proxyserver geleitet wird, um den Pfad mit der niedrigsten Latenz zwischen Client-> Spieleserver zu generieren. Dieses Verfahren führt jedoch zu hohen Latenzzeitspitzen, wenn mehrere Spielpakete in kurzer Zeit gesendet werden. Leider sendet / verwendet das Spiel TCP und ich habe mich entschieden, dasselbe mit unserem Proxy zu tun.

Wenn wir SSH (plink / putty mit dem Nodelay-Parameter Forced / Set) verwenden, um unter 127.0.0.1 (unter Verwendung von Dynamic Portforwarding) einen Socks-Proxy zu erstellen, und wir den Socksifier verwenden, um den Verkehr auf den lokalen Host umzuleiten, verschwindet das Problem mit der Latenzspitze und es läuft sehr viel viel reibungsloser. Es ist fast so, als gäbe es irgendwo ein Problem mit Engpässen oder Überlastungen, aber nicht nur die Server sind gleich, auch die Einstellungen für die Überlastungs- und Warteschlangendisziplin (versucht mit fq + bbr, noqueue und pfifo). Ich hatte ursprünglich gedacht, dass die Verwendung von SSH aufgrund von Verschlüsselungsaufwand zu einer schlechteren Leistung führen würde.

Kann jemand dieses Problem erklären, dem ich begegne? Es macht mich verrückt und ich habe jede Serveranwendung da draußen ausprobiert. Ich habe TCP_NODELAY bereits gesetzt (auf den Sockets) und habe versucht, mit TCP_QUICKACK und TCP_LOWLATENCY herumzuspielen.

Einige zusätzliche Informationen: Wir haben auch verschiedene kostenpflichtige und kostenlose Proxifier wie Proxifier und ProxyCap ausprobiert. Das Seltsame ist, dass Proxifier (und jede andere kostenlose Alternative) dieses Problem immer noch reproduziert, ProxyCap jedoch nicht. Ich habe ProxyCap eine E-Mail geschickt, und sie antworteten, indem sie mir sagten, sie setzten TCP_NODELAY auf die Sockets der Server, mit denen Sie sich verbinden (und möglicherweise auf den Windows-Socket, den ich annehmen würde). Das Spiel basiert auf Windows und die Proxy-Server werden auf Linux-VPS gehostet (versucht, jede "Common / Mainstream" -Distribution zu gleichen Ergebnissen zu bringen).

BEARBEITEN: Ich habe an beiden Enden unterschiedliche Werte für SO_SNDBUF und SO_RCVBUF getestet. Die Gesamtlatenz ändert sich mit niedrigeren / höheren Werten, das Problem mit den Spitzen bleibt jedoch bestehen. Auch versucht SO_DONTROUTE auf der Client-Seite zu keinem Erfolg.

EDIT2: Sieht aus, als hätten sie wahrscheinlich etwas mit Paketen zu tun, die zwischen dem Spielsockel und dem ausgehenden Netzwerk hängen. Plink + PCap verwenden Loopback, um einen Proxyserver zu erstellen, um den Datenverkehr an das ausgehende Netzwerk weiterzuleiten. Dies gilt jedoch nicht für unsere Methode. Auch wenn Sie nichts am Spiel bearbeiten (rein das Spiel und sonst nichts), bleibt dieses Problem bestehen. Verengung !!!

Ich danke Ihnen allen und ich bin dankbar für Ihre Gedanken, um den Täter zu identifizieren.