Ich entwickle einen TCP-Proxy, der vor einen TCP-Dienst gestellt werden soll, der zwischen 500 und 1000 aktive Verbindungen aus dem wilden Internet handhaben soll.

Der Proxy wird auf demselben Computer wie der Dienst ausgeführt und ist größtenteils transparent. Der Dienst kennt den Proxy zum größten Teil nicht, die einzige Ausnahme ist die Benachrichtigung über die reale Remote-IP-Adresse der Clients.

Dies bedeutet, dass für jeden eingehenden offenen TCP-Socket zwei weitere Sockets auf dem Server vorhanden sind: der zweite des Paares im Proxy und derjenige des realen Dienstes hinter dem Proxy.

Die Sende- und Empfangsfenstergrößen für die beiden Proxy-Sockets sind auf 1024 Byte festgelegt.

Welche Auswirkungen auf die Leistung hat dies? Wie langsam ist diese Konfiguration? Sollte ich mich bemühen, den Dienst so zu ändern, dass Named Pipes (oder ein anderer IPC-Mechanismus) verwendet werden, oder ist ein localhost-TCP-Socket größtenteils ein effizienter IPC?

Das Zusammenführen der beiden Apps ist keine Option. Im Moment stecken wir bei der Konfiguration mit zwei Prozessen fest.

BEARBEITEN: Der Grund dafür, dass zwei separate Prozesse auf derselben Hardware ausgeführt werden, ist eine 100% ige Wirtschaftlichkeit. Wir haben nur einen Server und planen nicht, mehr zu bekommen (kein Geld).

Der TCP-Dienst ist eine Legacy-Software in Visual Basic 6, die unsere Erwartungen übertroffen hat. Der Proxy ist C ++. Wir haben weder Zeit noch Geld noch Personal, um den VB6-Code neu zu schreiben und in eine moderne Programmierumgebung zu migrieren.

Der Proxy ist unser Versuch, ein bestimmtes Leistungsproblem des Dienstes zu mindernDDoS-Angriff wir bekommen von Zeit zu Zeit.

Der Proxy ist Open Source,und hier ist der Quellcode des Projekts.