Quão lentos são os soquetes TCP comparados aos pipes nomeados no Windows para o IPC do host local?

Eu estou desenvolvendo um Proxy TCP para ser colocado na frente de um serviço TCP que deve manipular entre 500 e 1000 conexões ativas da Internet selvagem.

O proxy está sendo executado na mesma máquina que o serviço e é na maior parte transparente. Na maioria dos casos, o serviço não tem conhecimento do proxy, sendo a única exceção a notificação do endereço IP remoto real dos clientes.

Isso significa que, para cada soquete TCP aberto de entrada, há dois soquetes adicionais no servidor: o segundo do par no Proxy e o outro no serviço real por trás do proxy.

Os tamanhos de janela de envio e recv nos dois sockets de proxy estão definidos para 1024 bytes.

Quais são as implicações de desempenho nisso? Quão lento é essa configuração? Devo colocar algum esforço em mudar o serviço para usar Named Pipes (ou outro mecanismo IPC), ou um socket TCP localhost é na maior parte um eficiente IPC?

A mesclagem dos dois aplicativos não é uma opção. Agora estamos presos com a configuração de dois processos.

EDITAR: O motivo de ter dois processos separados no mesmo hardware é 100% de economia. Temos apenas um servidor e não estamos planejando obter mais (sem dinheiro).

O serviço TCP é um software legado no Visual Basic 6 que cresceu além de nossas expectativas. O proxy é o C ++. Não temos tempo, dinheiro nem mão de obra para reescrever e migrar o código VB6 para um ambiente de programação moderno.

O proxy é nossa tentativa de mitigar um problema de desempenho específico no serviço,Ataque DDoS estamos recebendo de vez em quando.

O proxy é open source,e aqui está o código fonte do projeto.

questionAnswers(6)

yourAnswerToTheQuestion