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 TCP/IP seja 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 um desempenho ruim.
Aplicativos de conexão pesada.
Alguns aplicativos instanciam uma nova conexão TCP para cada transação. O estabelecimento de conexão TCP leva tempo, contribui com RTTs extras e está sujeito a 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 multiplexacionadas em várias conexões. Se essa abordagem for tomada, o número de conexões deverá ser limitado a duas, e o enquadramento de camada de aplicativo e o tratamento avançado de erros serão necessários.
Enviar buffers de comprimento zero e bloquear envios.
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 deSend-Receive de envio.
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 datagram. O MSS pode ser um valor muito grande (64K no IPv4 e ainda maior no 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