Dissertação de Mestrado
Dissertação de Mestrado
Os seguintes computadores foram utilizados nos testes:
A versão do kernel do Linux utilizada foi o kernel 2.6.10rc1. A distribuição usada foi a Conectiva Linux versão 10. O compilador C desta distribuição é o GCC 3.3.3.
Os aplicativos para teste de performance bruta foram construídos pelo autor. Os aplicativos com protocolos reais são de autoria de terceiros; apenas as respectivas adaptações para SCTP foram feitas pelo autor.
As ferramentas de simulação de rede utilizadas foram: disciplina de tráfego netem, e firewall iptables. À época dos testes (novembro/2004) o netem ainda tinha bugs e limitações importantes que exigiram o uso de iptables para suprir as faltas. Também foi utilizado o comando tc filter (presente no controle de tráfego do Linux) para simular diversas larguras de banda.
A simulação de largura de banda foi feita descartando-se pacotes na recepção. Esta técnica foi adotada em lugar do traffic shaping na saída do transmissor, pois o pacote perdido ocupa banda da rede, e isto simula melhor uma rede onde roteadores perdem pacotes por congestionamento.
Os testes brutos são basicamente vazão e latência.
Vazão é o volume de dados por unidade de tempo. O teste de vazão consiste de transmitir um volume fixo de bytes (por default, 100MBytes) em ambas as direções. Os resultados informados são para uma direção. (exemplo: se o resultado foi de 200Kbps, na verdade o total trafegado em ambas as direções foi de 400Kbps.) Escolhemos expressar o valor para uma direção, pois a maioria das tecnologias de rede é full-duplex (ninguém alega, por exemplo, que Fast Ethernet é 200Mbps).
Latência é o tempo médio decorrido entre a requisição do cliente e a resposta do servidor, como numa transação cliente/servidor (em alguns gráficos ela é chamada de "latência de transação", para distinguí-la da latência de rede, que refere-se apenas ao tempo de chegada de um datagrama.
Nos testes, aparecem os protocolos "TCPM" e "UnixM". São protocolos de aplicação que fazem a separação de mensagens, coisa que o SCTP faz por conta própria, porém TCP e soquetes UNIX não fazem. A separação de mensagens feita pelo TCPM/UnixM é a mais simples possível, apenas para atender às necessidades do teste. Qualquer protocolo de aplicação real usaria um esquema mais robusto e mais complexo.
O TCPM/UnixM foi criado principalmente para assegurar uma "justiça" maior nas comparações entre TCP e SCTP, já que SCTP sempre separa mensagens. Além disso, nos testes de latência, é necessário que o servidor tenha meios de determinar onde termina a mensagem do cliente, para que possa respondê-la.
Os programas de teste SCTP foram criados em três versões: API estilo TCP, API estilo UDP, e API estilo UDP versão 2 (usando C++ e STL para suportar vários clientes simultâneos, e algumas diferenças de lógica interna).
Nenhum ajuste dos parâmetros "sysctl" (/proc/sys/net) do TCP e SCTP foi feito, exceto onde explicitamente afirmado o contrário.
Exceto nos testes com RTP, todos os testes SCTP utilizam entrega de mensagens garantida e ordenada. É possível extrair mais performance usando confiabilidade parcial, mas isto seria desleal com TCP, e inutilizável para a maioria dos protocolos de aplicação atuais, que demandam um transporte perfeitamente confirmado e ordenado.
Outra técnica que entrega mais performance em canais com perda de pacotes, é usar diversos fluxos para evitar "HOL blocking". Pode ser demonstrado que isso equivale a permitir entrega desordenada de mensagens, e novamente a maioria dos protocolos de aplicação não poderiam lidar com isso. Usaremos esta técnica apenas com HTTP, que pode usar um fluxo por arquivo sem mudar o protocolo de aplicação em si.