Esta é uma resposta teórica , fornecendo informações para entender o problema:
Do que você escreve, presumo que você não queira ouvir a resposta "Consiga a conexão corrigida!", certo?
Então, vamos ver o que mais podemos fazer:
Uma grande fração dos pacotes é perdida. O objetivo do TCP / IP (Protocolo de Controle de Transmissão) é fornecer uma conexão que forneça dados que é exatamente o que foi enviado e na mesma ordem. Você ainda obtém isso da conexão em perfeita qualidade, desde que a conexão não seja descartada.
Mas, obviamente, há um compromisso - a conexão é lenta.
Porque é muito difícil simular uma conexão perfeita em uma conexão que perde cerca de 12% dos dados de forma irregular.
Não esperamos magia , por isso algum compromisso precisa ser aceito. Alguém poderia perguntar se é possível usar outra coisa que faça o que o TCP / IP faz, mas mais rápido. Para uma solução geral, podemos simplesmente supor que o TCP / IP é quase ideal, porque muitas pesquisas foram gastas com muito tempo. (Com uma solução especial para sua conexão, desenvolvida com base nas medições da conexão, ela pode ser mais rápida, com certeza, e ainda mais rápida se você usar hardware adaptado à sua conexão - mas essa direção não faz muito sentido aqui)
Agora, tudo o que podemos fazer é procurar um comprometimento diferente :
A outra extremidade da escala de compromissos é uma conexão muito rápida, com - 12% de perda de pacotes.
Isso é o que você tem se não usar TCP / IP, mas UDP / IP (Protocolo de Datagrama do Usuário) , que transfere pacotes separados para você e não dá garantia de que eles cheguem em ordem ou de forma alguma.
Em teoria, você poderia ter compromissos com menos perda de pacotes e, mais lentamente, no meio, construir em cima de UDP / IP. Mas, em muitos casos, apenas o TCP / IP faz sentido.
Assim, o anser prático é: "Obter a conexão corrigida!"
Algumas notas práticas:
Sobre o porquê da conexão ficar lenta : o TCP pode reconhecer quando envia muitos pacotes e diminuir a velocidade, mas não acho que seja o que está acontecendo aqui. A perda de pacotes é um problema muito diferente comparado ao envio de muitos pacotes.
Acho que o tempo gasto na retransmissão de pacotes perdidos e na espera de pacotes perdidos entre eles precisa ser entregue antes dos outros que já foram recebidos.
Como você não disse quais tipos de dados deseja transferir: há boas razões para preferir 12% de perda de pacotes em UDP / IP para alguns casos de uso:
Se você transferir vídeo em tempo real de uma câmera, você só se importa com os pacotes que chegam a tempo de serem exibidos na tela. Com o TCP, os dados chegariam completos e ordenados, mas inutilizáveis, porque tarde demais. Obter 88% de um fluxo de vídeo no tempo é muito melhor, pode até ser suficiente para uma boa transmissão.