Problemas específicos de TCP/IP
Determinadas técnicas de programação têm problemas de desempenho vinculados à implementação de TCP/IP. Esses problemas de desempenho não sugerem que o TCP/IP é ineficiente ou um gargalo de desempenho; em vez disso, esses problemas são vistos quando as operações TCP/IP não são compreendidas.
Os problemas a seguir identificam cenários comuns em que a combinação de opções de operação TCP/IP e desenvolvimento de aplicativos de rede resulta em baixo desempenho.
Aplicativos com uso intenso de conexão.
Alguns aplicativos criam uma instância de uma nova conexão TCP para cada transação. O estabelecimento da conexão TCP leva tempo, contribui com RTTs extras e está sujeito a um início lento. Além disso, as conexões fechadas estão sujeitas a TIME-WAIT, que consome recursos do sistema.
Aplicativos de conexão pesada são comuns em grande parte porque são fáceis de criar; O teste e o tratamento de erros são muito simples. Detectar falhas em uma conexão persistente pode levar um código e esforço consideráveis e, portanto, às vezes não é concluído.
Resolva essa situação reutilizando a conexão TCP. Isso pode causar serialização pela conexão TCP, a menos que as transações sejam multiplexadas em várias conexões. Se essa abordagem for adotada, o número de conexões deverá ser limitado a duas, e o enquadramento da camada de aplicativo e o tratamento avançado de erros serão necessários.
Envio de buffers de comprimento zero e envios de bloqueio.
Desativar o buffer usando a função setsockopt para definir o buffer de envio (SO_SNDBUF) como zero é semelhante a desativar o cache de disco. Ao definir o buffer de envio como zero e emitir envios de bloqueio, um aplicativo tem 50% de chance de atingir uma confirmação atrasada de 200 milissegundos.
Não desative o buffer de envio, a menos que você tenha considerado o impacto em todos os ambientes de rede. Uma exceção: transmitir dados usando E/S sobreposta deve definir o buffer de envio como zero.
Modelo de programação Send-Send-Receive.
Estruturar um aplicativo para executar send-send-receives aumenta suas chances de encontrar o Algoritmo Nagle, o que causa um atraso de RTT+200 ms. O Algoritmo Nagle poderá ser encontrado se o último envio for menor que o MSS (Tamanho Máximo do Segmento TCP, os dados máximos em um único datagrama). O MSS pode ser um valor muito grande (64K em IPv4 e ainda maior em IPv6), portanto, não conte com um MSS normalmente pequeno. Uma opção melhor é combinar os dois envios em um único envio usando a função WSASend ou memcpy .
Grande número de conexões simultâneas.
As conexões simultâneas não devem exceder duas, exceto em aplicativos de finalidade especial. Exceder duas conexões simultâneas resulta em recursos desperdiçados. Uma boa regra é ter até quatro conexões de curta duração ou duas conexões persistentes por destino.
Tópicos relacionados