Насколько медленнее TCP-сокеты по сравнению с именованными каналами в Windows для localhost IPC?

Я разрабатываю TCP-прокси, который будет размещен перед службой TCP, которая должна обрабатывать от 500 до 1000 активных подключений из Интернета.

Прокси-сервер работает на том же компьютере, что и служба, и в основном прозрачен. Служба по большей части не знает о прокси-сервере, единственным исключением является уведомление о реальном удаленном IP-адресе клиентов.

Это означает, что для каждого входящего открытого TCP-сокета на сервере есть еще два сокета: второй из пары на прокси-сервере и один на реальном сервисе за прокси-сервером.

Размеры окон отправки и получения на двух прокси-сокетах установлены на 1024 байта.

Как это повлияет на производительность? Насколько медленная эта конфигурация? Должен ли я приложить некоторые усилия для изменения службы для использования именованных каналов (или другого механизма IPC), или TCP-сокет localhost по большей части является эффективным IPC?

Объединение двух приложений невозможно. Прямо сейчас мы застряли с конфигурацией двух процессов.

РЕДАКТИРОВАТЬ: Причина наличия двух отдельных процессов на одном и том же оборудовании — стопроцентная экономия. У нас всего один сервер, больше брать не планируем (денег нет).

Служба TCP — это устаревшее программное обеспечение в Visual Basic 6, которое превзошло все наши ожидания. Прокси - С++.У нас нет ни времени, ни денег, ни рабочей силы, чтобы переписать и перенести код VB6 в современную среду программирования.

Прокси — это наша попытка смягчить определенную проблему с производительностью службы, DDoS-атаку, с которой мы сталкиваемся время от времени.

Прокси с открытым исходным кодом, а вот исходный код проекта.