An´alise de desempenho do protocolo SCTP (Stream Control
Protocol Transmission)
Andrew Miranda da Silva1, Eduardo Maro ˜nas Monks1
1Curso Superior de Redes de Computadores – Faculdade de Tecnologia SENAC Pelotas (FATEC) Rua Gonc¸alves Chaves 602 – 96015560 – Pelotas – RS – Brazil
[email protected], [email protected]
Resumo. Este artigo apresenta uma an´alise comparativa sobre o desempenho dos protocolos da camada de transporte SCTP, TCP e UDP, por meio de testes em cen´arios com restric¸˜oes de recursos. O objetivo ´e comparar o desempenho dos protocolos em ambientes de rede com atraso, perdas de pacote e restric¸˜oes de largura de banda.
Palavras-Chave: SCTP, TCP, UDP, an´alise, desempenho.
Abstract. This article presents a comparative analysis on the performance of transport layer protocols SCTP transport, TCP and UDP, by testing in scenarios with resource constraints. The goal is to compare the performance of protocols in network environments with delay, packet loss and bandwidth restrictions. Keywords: SCTP, TCP, UDP, analysis, performance.
1. Introduc¸˜ao
Os protocolos da camada de transporte s˜ao um dos crit´erios mais importantes para comunicac¸˜ao entre os computadores de uma rede, pois proporcionam servic¸os de entrega confi´avel ou n˜ao confi´avel de dados para as aplicac¸˜oes. Segundo [Farrel 2005], os pro-tocolos mais importantes para o transporte de dados na Internet, s˜ao os mais conhecidos e utilizados, TCP (Transmission Control Protocol) [Postel 1981] e UDP (User Datagram Protocol) [Postel 1980]. Existem outras soluc¸˜oes que desempenham este papel, tal como o protocolo SCTP (Stream Control Transmission Protocol) [Stewart 2007], que prop˜oe ser uma alternativa vi´avel ao TCP e UDP na implementacao de sistemas distribu´ıdos.
Na Internet, o protocolo TCP ´e bem estabelecido, por´em houve uma necessi-dade da utilizac¸˜ao do protocolo SCTP em conex˜oes PSTN (Packet Switched Telephone Network), devido ao protocolo possuir caracter´ısticas e recursos adicionais comparado aos protocolos TCP e UDP[Daniel 2005]. O SCTP possui algumas vantagens e diferenc¸as em relac¸˜ao ao TCP e UDP, como a entrega sequencial de dados de usu´ario em m´ultiplos fluxos e tolerˆancia a falhas de rede, atrav´es do suporte a m´ultiplos caminhos, al´em de ser orientado a conex˜ao, o protocolo ´e Rate adaptative, ou seja, adapta-se dinamicamente a variac¸˜ao do estado de rede, com isto nota-se que o SCTP veio para ser uma alternativa mais robusta para transferˆencia de fluxos de dados na rede [Daniel 2007].
Portanto este trabalho tem como objetivo analisar o desempenho e o comporta-mento do protocolo SCTP em cen´arios de rede com restric¸˜oes de recursos, utilizando fer-ramentas de an´alise de tr´afego para coletar e verificar os resultados obtidos, comparando aspectos de desempenho em relac¸˜ao aos protocolos TCP, SCTP e UDP.
2. Protocolos da Camada de Transporte
Para que dois n´os possam se comunicar, ambos devem especificar o mesmo protocolo [Tanenbaum 2003]. Os protocolos podem ser classificados como orientados a conex˜ao (connection-oriented services) ou n˜ao orientados a conex˜ao (connectionless). Os orien-tados a conex˜ao, estabelecem uma sess˜ao antes de transmitir qualquer informac¸˜ao, assim oferecendo garantia de entrega, melhor controle de fluxo e evitando congestionamento na transmiss˜ao de dados, tal como o TCP [KUROSE 2010].
O protocolo UDP, classifica-se como n˜ao orientado a conex˜ao, pois pode enviar dados sem a necessidade de primeiramente estabelecer uma conex˜ao entre emissor e re-ceptor. Possibilitando que a entrega seja mais r´apida, por´em sem garantia de entrega [Postel 1980].
2.1. Protocolo TCP (Transmission Control Protocol)
O TCP possui diversos servic¸os e algoritimos respons´aveis pela garantia de envio dos da-dos durante a transmiss˜ao, como a retransmiss˜ao de segmentos perdida-dos at´e controle de congestionamento da conex˜ao [Allman et al. 1999]. Devido a sua complexidade e quan-tidade de operac¸˜oes envolvidas no servic¸o de transmiss˜ao, mais de uma RFC (Request for Comments) foi escrita para especificar e melhorar o seu desenvolvimento e funcio-namento, desde a RFC 793 [Postel 1981]. O TCP utiliza somente m´etodos de conex˜ao fim a fim, onde n˜ao h´a possibilidade de utilizac¸˜ao do protocolo em sistemas multicast. Enquanto a comunicac¸˜ao entre os dois hosts for mantida, o tratamento ser´a da forma full-duplex, o que permite que ambos os envolvidos na troca de dados enviem e recebam informac¸˜oes ao mesmo tempo [Farrel 2005].
Ap´os o in´ıcio de conex˜ao, com o mecanismo de Three Way Handshake, a trans-ferˆencia de dados ´e tratada em sequˆencia de octetos junto aos cabec¸alhos de controle, ou seja, os dados s˜ao segmentados para ser enviados na rede. O tamanho de um segmento es-tabelecido pela origem, ´e determinado pela MTU Maximum Transmission Unit do enlace local, a responsabilidade de remontar os dados fica a cargo da pilha TCP/IP de destino [Farrel 2005].
2.2. Protocolo UDP (User Datagram Protocol)
O protocolo UDP ´e utilizado para fornecer uma comunicac¸˜ao simples, por´em r´apida e eficiente, por padr˜ao n˜ao possui um gerenciamento de controle preciso de erro ou fluxo [Daniel 2007]. O principal objetivo do protocolo ´e realizar multiplexac¸˜ao entre v´arias comunicac¸˜oes. O protocolo at´e possui uma verificac¸˜ao opcional de erros dos dados, por´em esta verificac¸˜ao serve apenas para descartar dados corrompidos durante a trans-miss˜ao na rede [Postel 1980]. Este protocolo ´e bastante utilizado em redes multim´ıdia para servic¸os de rede em tempo real, ou at´e mesmo em comunicac¸˜oes de sistemas multi-cast[Daniel 2007].
O UDP n˜ao realiza nenhum tipo de estabelecimento de conex˜ao para transfe-rir as mensagens de dados, ´e encapsulado em datagramas para ser transferido na rede [Postel 1980]. No ano de 2004 , foi lanc¸ado a extens˜ao do protocolo UDP, denominada de UDP-Lite [Larzon et al. 2004]. O diferencial desta extens˜ao, foi que o prop´osito de criac¸˜ao aplicava-se para atuar em redes com altas taxas de erros, para beneficiar aplicac¸˜oes que utilizam classes de codecs de v´ıdeos e ´audio [Daniel 2007].
3. Protocolo SCTP (Stream Control Transport Protocol)
O protocolo SCTP (Stream Control Transport Protocol), foi desenvolvido para fins de troca de mensagens telefˆonicas na Internet, rede denominada PSTN (Packet Switched Telephone Network). No ano 2000 foi lanc¸ada a primeira RFC 2960 [IETF 2001], por um grupo de engenheiros de rede do SIGTRAN, que submeteram ao IETF Internet En-gineering Task Force [IETF 2016]. Dois anos ap´os a criac¸˜ao do protocolo, foi lanc¸ado uma nova RFC 3308 [IETF 2003] descrevendo as alterac¸˜oes no algoritimo de soma de verificac¸˜ao. Atualmente, o protocolo encontra-se na RFC 4960 [Stewart 2007].
Segundo a RFC 2930 [IETF 2001], o protocolo ´e apresentado como de transporte confi´avel e orientado a conex˜ao, utiliza recursos adicionais para melhorar o desempe-nho em rede, mas tamb´em possui funcionalidades do TCP e UDP embutidas. O SCTP opera em cima do protocolo IP, por´em uma conex˜ao s´o pode ser estabelecida se ambos os lados possuem o mesmo protocolo SCTP na camada de transporte. Em relac¸˜ao `as por-tas de comunicac¸˜ao, o IANA [IANA 2016] definiu que as porpor-tas de comunicac¸˜ao TCP, automaticamente estariam reservadas para SCTP, permitindo o uso concorrente de TCP e SCTP para o mesmo servic¸o no mesmo n´umero de porta [Pfutzenreuter E 2004]. Segundo [Daniel 2007], o protocolo SCTP pode ser atrativo para aplicac¸˜oes comuns na internet, principalmente, tratando-se de aplicac¸˜oes de multim´ıdia.
3.1. Cabec¸alho SCTP
Um pacote SCTP ´e composto por um header comum, e chunks. Um chunk no cabec¸alho SCTP ´e um campo que pode conter informac¸˜oes de controle ou dados de usu´ario [Stewart 2007]. V´arios chunks podem ser multiplexados dentro de um pacote IP at´e que seja atingido o MTU. O header comum do SCTP ´e formado por 12 bytes, coontendo as portas de destinos e origem. A Tag de verificac¸˜ao indica o tamanho do chunk e o campo do cheksum [Stewart 2007]. A Figura 1 Cabec¸alho SCTP, mostra os campos que comp˜oe o cabec¸alho do protocolo.
Figura 1. Estrutura do cabec¸alho SCTP com v ´arios chunks [UFRGS 2008]
3.2. Orientado a Mensagens
O protocolo trata os dados como blocos de mensagens independentes, ou seja, como sequˆencia de dados fragmentados, dividindo os dados em partes e indentificando cada
parte para ser transmitida na rede, diferentimente do TCP, que trata os dados como sequˆencia de octetos. O SCTP proporciona facilidade para aplicac¸˜oes que necessitam de confiabilidade na camada de trasnporte [Daniel 2005] . Tanto SCTP quanto TCP possuem o conceito de mensagem urgente, na transmiss˜ao de pacotes.
3.3. Associac¸˜ao
Uma comunicac¸˜ao estabelecida entre dois hosts que utilizam SCTP, ´e feita atrav´es de uma associac¸˜ao, ou v´arias associac¸˜oes, negociada entre os participantes, diferente das co-nex˜oes TCP/IP, que realizam apenas uma sess˜ao full-duplex [Stewart 2007]. Conforme a descric¸˜ao da RFC [Stewart 2007], justificam que o canal de comunicac¸˜ao SCTP ´e unidi-recional, podendo haver um n´umero desigual de fluxos, em cada direc¸˜ao. Nas associac¸˜oes SCTP, n˜ao existe um estado meio fechado half-closed isto serve tanto para associac¸˜oes e fluxos [Stewart 2007].
3.4. Multihoming
Uma das caracter´ısticas mais interessantes do protocolo, ´e o suporte a multi-caminhos, denominado tamb´em como multi-homed. O objetivo deste mecanismo ´e criar mais de uma comunicac¸˜ao entre redes, com v´arios enderec¸os IP, sem necessariamente ser um roteador [Stewart 2007]. Este recurso proporciona dois ou mais caminhos entre a origem e o destino. Segundo [Stewart 2007], este recurso tem uma grande importˆancia, devido a tolerˆancia `a falhas de uma das conex˜oes IP de um dos enlaces. O SCTP permite que cada hostinforme uma lista de IPs. O enderec¸o IP utilizado durante a criac¸˜ao da associac¸˜ao ´e classificado como IP prim´ario, isto significa que esta conex˜ao ´e o principal canal de comunicac¸˜ao com o host de destino remoto. Os demais IPs informados s˜ao secund´arios, que podem ser utilizados caso falhe a comunicac¸˜ao com o IP prim´ario [Stewart 2007].
O SCTP controla o estado dos diversos IPs relacionado ao terminal remoto, de modo a sempre conhecer a situac¸˜ao de cada caminho alternativo realizando verificac¸˜oes, se todos os caminhos aparentemente falharem, a probabilidade ´e que o pr´oprio destino remoto tenha falhado, e n˜ao as associac¸˜oes [Stewart 2007].
4. Ferramentas
Nesta sec¸˜ao, s˜ao abordadas as ferramentas utilizadas nos testes comparativos entre os protocolo TCP, UDP e SCTP.
4.1. D-ITG
A ferramenta D-ITG (Distributed Internet Traffic Generator) [D-ITG 2013] ´e uma fer-ramenta capaz de produzir tr´afego IPv4 e IPv6. Seu objetivo ´e medir as m´etricas de desempenho mais comuns, como taxa de transferˆencia, atraso, jitter e perdas de pacotes. Atualmente a ferramenta suporta TCP, UDP, SCTP e DCCP na camada de transporte, possui quatro utilit´arios importantes para a realizac¸˜ao dos testes, o ITGSend que ´e res-pons´avel por enviar o tr´afego de rede, o ITGRecev que faz o papel do servidor e recebe o trafego, ITGLog ´e capaz de gerar logs de estat´ıticas do desempenho da conex˜ao. O ITG-Dec realiza interpretac¸˜ao dos logs gerados [Botta et al. 2012] mostrando as estat´ısticas gerais das conex˜oes. A vers˜ao da ferramenta utilizada nos testes foi a 2.8.
4.2. Iperf
A ferramenta Iperf tem como funcionalidade principal o estresse da rede, realizando testes de performance entre hosts. O cliente gera um determinado fluxo de dados para o servi-dor Iperf em escuta, como em uma comunicac¸˜ao cliente e serviservi-dor, a ferramenta testa a capacidade m´axima do meio de transmiss˜ao [Iperf 2016]. A vers˜ao utilizada nos testes ´e a 3.1, possui o m´odulo de suporte ao protocolo SCTP. A vers˜ao utilizada nos testes ´e para plataforma Linux, eo suporte para SCTP est´a apenas na vers˜ao beta da ferramenta [Iperf 2016].
4.3. Tcpdump
O Tcpdump ´e uma ferramenta de an´alise de tr´afego em modo texto, tamb´em conhecida como sniffers de rede, onde seu objetivo ´e capturar e mostrar as conex˜oes e transmiss˜oes de dados que trafegam pela interface de rede. Analisa o tr´afego entrante e sainte de um host, possui diversos mecanismos e variac¸˜oes de filtros para as capturas de rede. Tanto Tcpdump quanto o Wireshark utilizam a biblioteca Libcap [Tcpdump 2016]. Esta ferra-menta ser´a utilizada para capturar o tr´afego das interfaces de cada um dos hosts partici-pantes da conex˜ao.
4.4. Wireshark
O Wireshark ´e uma aplicac¸˜ao de an´alise de tr´afego de rede semelhante ao Tcpdump. Possui uma interface gr´afica GUI (Graphical User Interface), onde ´e poss´ıvel analisar as estat´ısticas de desempenho de uma determinada conex˜ao. A vers˜ao utilizada para an´alise das capturas dos protocolos ´e a 2.0, que possui mecanismos de an´alise do protocolo SCTP [Wireshark 2016].
4.5. WANem
O WANem Wide Area Network Emulator [Wanem 2014], ´e uma distribuic¸˜ao Linux que pode emular um roteador de rede com restric¸˜oes de recursos, como atraso de rede, restric¸˜ao da largura de banda, perdas de pacotes.
5. Cen´arios de Testes
Pare realizac¸˜ao dos testes utilizou-se duas m´aquinas reais com trˆes servidores virtuali-zados no VMware Workstation. Em duas m´aquinas virtuais foi utilizado a distribuic¸˜ao Debian 8, com as ferramentas D-ITG e Iperf. A terceira m´aquina virtual instalada no hospedeiro, ´e o roteador WANem, que ser´a respons´avel por realizar as restric¸˜oes de re-cursos na rede. Os hospedeiros est˜ao conectados em uma rede ethernet, em um switch de 100Mbit/s.
5.1. Cen´arios sem Restric¸˜oes
O primeiro cen´ario de teste, ´e baseado no ambiente de rede local 100 Mbit/s. Neste cen´ario, n˜ao foi necess´ario a utilizac¸˜ao do roteador WANem, apenas duas m´aquinas vir-tuais, com o sistema operacional Debian 8. Uma das m´aquinas virtuais est´a em modo cliente e a outra como servidor. A Figura 2 mostra a organizac¸˜ao do cen´ario.
Figura 2. Estrutura do cen ´ario sem restric¸ ˜oes de recursos
5.2. Cen´arios com Restric¸˜oes
Na criac¸˜ao dos cen´arios com restric¸˜oes de recursos de rede, acrescentou-se uma m´aquina virtual com a distribuic¸˜ao WANem vers˜ao 2.3, que efetuar´a o papel de um roteador para realizar as restric¸˜oes de largura de banda, atraso e perdas de pacotes. Para estabelecer a comunicac¸˜ao do cliente com servidor na rede com restric¸˜oes, foi necess´ario adicionar uma rota est´atica nos dois sentidos, passando pelo roteador WANem. A Figura 3 mostra a estrutura dos cen´arios com restric¸˜oes de recurso.
Figura 3. Estrutura dos cen ´arios com restric¸ ˜oes de recursos
5.2.1. Restric¸˜oes de recursos
As restric¸˜oes de recursos de rede foram baseadas em estat´ıstica de dois cen´arios reais da Internet, e dois ambientes de simulac¸˜ao com grande quantidade atraso e perdas. Um dos ambientes de rede, baseado em restric¸˜oes reais foi um estudo feito por [Chen et al. 2012] sobre o desempenho de redes WIFI, 3G e 4G em universidades americanas. O segundo cen´ario baseado em restric¸˜oes de redes reais, foi um levantamento de planos de Inter-net oferecido pelos principais provedores de InterInter-net da regi˜ao Sul do Brasil, baseado na publicac¸˜ao do site G1 [g1.com 2015]. O site mostra o mapa formulado com base nos dados fornecidos pela Anatel, indicando que a internet banda larga mais utilizada especi-ficamente na cidade de Pelotas, possui a m´edia de 6 MBit/s.
No cen´ario trˆes, foi utilizado uma porcentagem razo´avel de perdas de pacote, para analisar a performance e o comportamento dos protocolos em ambientes com per-das maiores. As restric¸˜oes do cen´ario quatro, foram baseaper-das na simulac¸˜ao de uma rede
de sat´elite, com taxas de atraso bem elevadas. A Tabela 1 mostra as restric¸˜oes de rede aplicadas em cada cen´ario.
Tabela 1. Tabela de restric¸ ˜oes
Restric¸˜oes Cen´ario 1 (Wifi 3G/4G) Cen´ario 2 (Pelotas) Cen´ario 3 (Perdas) Cen´ario 4 (Sat´elite) Largura de Banda (Mbit/s) 4,95 Mbit/s 6 Mbit/s 5,9 Mbit/s 1,5 Mbit/s
Atraso (ms) 30 ms – 20 ms 450 ms
Perdas pacotes (%) 1 % – 10 % –
Jitter (ms) – – – 15 ms
6. Testes
Os testes de desempenho, foram realizados com as ferramentas Iperf e D-ITG, para anali-sar o comportamento dos protocolos em rede, avaliando a capacidade de carga e o tempo de transferˆencia das conex˜oes. As ferramentas geram um fluxo de dados, utilizando a capacidade m´axima da rede, no sentido cliente para o servidor, tanto em cen´arios com restric¸˜oes quanto em cen´arios sem restric¸˜oes. Para estabelecer uma padronizac¸˜ao e de-vido a dificuldade de analisar um grande volume de dados nas ferramentas Wireshark e Tcpdump, foi definido um tamanho fixo dos fluxos de dados de 100 Megabytes, 50 Megabytese 10 Megabytes para os testes.
No cen´ario quatro, foram realizados testes com streaming em paralelo. Neste cen´ario, o tempo de transferˆencia dos dados foi de 60 segundos, com variac¸˜oes de duas a quatro conex˜oes paralelas, sendo a quantidade de dados transferida na rede estabelecida pela vaz˜ao dos protocolos TCP, UDP e SCTP.
6.1. Testes com Iperf
A ferramenta Iperf 3.1 foi compilada tanto no cliente quanto no servidor. O servidor ficou em modo escuta, e o cliente gerou tr´afego no sentido ao servidor. Os testes foram realizados utilizandos os trˆes protocolos da camada de transporte, TCP, UDP e SCTP. No tr´afego de rede gerado pelo cliente, utilizou-se o tamanho fixo do fluxo de dados, enderec¸o IP do servidor e o protocolo da camada de transporte. Nos testes efetuados com UDP, foi necess´ario apontar a largura de banda utilizada no cen´ario, pois o padr˜ao da ferramenta ´e utilizar 1 Mbit/s.
6.2. Testes com D-ITG
A ferramenta D-ITG 2.8 foi instalada no cliente e no servidor. Aplicou-se as mesmas metodologias de testes realizadas com o Iperf 3.1, por´em alguns parˆametros para gerar o tr´afego de rede foram acrescentados no cliente. O cliente Iperf 3.1, por padr˜ao gera o trafego de rede com o tamanho dos pacotes de aproximadamente 1500 Bytes, para n˜ao haver influˆencia nos resultados de vaz˜ao e tempo das conex˜oes, foi adicionado no cliente D-ITG o parˆametro para utilizar pacotes de 1500 Bytes.
7. Resultados
Os resultados de vaz˜ao e tempo nos testes de estresse realizados com a ferramenta Iperf e D-ITG, nos cen´arios de rede com e sem restric¸˜oes. Os cen´arios de rede, utilizados nos testes com a ferramenta Iperf 3.1, foram mantidas nos testes realizados com o D-ITG. Os
resultados de vaz˜ao e tempo, tiveram pequenas diferenc¸as entre as ferramentas, por´em os protocolos apresentaram o mesmo comportamento em ambos os testes.
O gr´afico na Figura 4 mostra a m´edia de vaz˜ao dos testes realizados em rede local. Na figura 5, o gr´afico mostra os resultados de vaz˜ao dos cen´arios com restric¸˜oes de recursos.
Figura 4. Gr ´afico da m ´edia de vaz ˜ao, nos testes realizados em rede Local
Figura 5. Gr ´afico da m ´edia de vaz ˜ao, nos testes realizados em cen ´arios com restric¸ ˜oes
7.1. Teste de Streaming Paralelo
Para os testes de streaming em paralelo, foi utilizado a ferramenta Iperf 3.1, pois comportou-se melhor na gerac¸˜ao de tr´afego dos clientes para o servidor, devido a ferra-menta possuir alternativas para testes em paralelo. Os testes foram realizados com tempo de transmiss˜ao pr´e-definido de 60 segundos com variac¸˜oes de 2 a 4 streaming nas trans-miss˜oes de dados. Os cen´arios utilizados nos testes foram o de Rede Local e o cen´ario 3, simulac¸˜ao Sat´elite. Na Figura 6, mostra o gr´afico com os resultados de vaz˜ao no tempo de transferˆencia de 60 segundos.
8. An´alise dos Resultados
Os resultados indicam algumas diferenc¸as entre os trˆes protocolos da camada de trans-porte. Dependendo do cen´ario aplicado, ambos apresentam diferentes caracter´ısticas de desempenho, devida a pequenas particularidades, na maioria dos casos, foram resultados esperados.
Figura 6. Gr ´afico dos resultados de vaz ˜ao, nos testes de streaming em paralelo, nos cen ´arios de rede local e Sat ´elite.
8.1. TCP
O protocolo TCP, teve o desempenho em rede igual ou superior ao protocolo SCTP em cen´arios sem restric¸˜oes e cen´arios com restric¸˜oes de largura de banda. A similaridade entre o protocolo SCTP e TCP ´e justificada por ambos serem confi´aveis, orientado a conex˜ao e possuirem recursos de controle de congestionamento de fluxo [Stewart 2007]. Nos testes de fluxo paralelo, o TCP enviou uma pequena quantidade a mais de bytes do que o procolo SCTP. Na transferˆencia dos dados, o protocolo cumpriu com seus objetivos. 8.2. UDP
Na avaliac¸˜ao do protocolo UDP, entre os trˆes, foi o que melhor obteve vaz˜ao e menor tempo nas transmiss˜oes de dados, por´em nos testes realizados em cen´arios com restric¸˜oes de recursos, especificamente os que possuem caracter´ısticas de atraso e perdas de pacotes, o protocolo teve a m´edia de 18 % de perdas nos dados transferidos e aproximadamente 46 %de perda nos dados no cen´ario 3. Os resultados com o protocolo foram esperados, pois a grande caracter´ıstica do UDP ´e realizar transmiss˜oes de dados sem verificar o recebimento no destino [Postel 1980].
8.3. SCTP
Na an´alise do protocolo SCTP, observa-se que o desempenho em rede foi muito similar ao TCP, principalmente em cen´arios sem restric¸˜oes de recurso. Nos cen´arios com restric¸˜oes de largura de banda e atraso, n˜ao apresentou nenhuma grande superioridade em relac¸˜ao aos demais protocolos, tanto nos testes realizados com D-ITG e Iperf. O grande diferen-cial do SCTP, foi especificamente em cen´arios com perdas de pacotes, pois transferiu o fluxo integro de dados, com menor tempo de conex˜ao comparado ao TCP, e com mais integridade que o UDP. Este aproveitamento do protocolo SCTP, pode ser justificado pelo controle de congestionamento e de perdas de pacotes tratados pelas mensagens SACKs, o tratamento dos dados retransmitidos obteve maior eficiˆencia e foi mais r´apido que o do TCP, portanto o SCTP obteve melhor aproveitamento do que o TCP e UDP [Daniel 2005]. Uma das caracter´ıstica analisada nas conex˜oes SCTP, ´e que o protocolo gera uma taxa de controle consider´avel na rede overheads.
9. Considerac¸˜oes Finais
Em uma an´alise geral das estat´ısticas dos resultados, o SCTP manteve-se com m´edias pro-porcionais entre os protocolos TCP e UDP, n˜ao apresentando nenhuma superioridade , a n˜ao ser em cen´arios com perdas de pacotes, onde obteve uma vantagem consider´avel. Nos testes realizados nota-se uma grande similaridade e caracter´ısticas do SCTP com TCP. O
protocolo SCTP possui atributos interessantes, como o uso de Multihoming e Multistrea-ming, por´em n˜ao estavam dispon´ıveis por completo nas ferramentas e aplicac¸˜oes de teste. Conclui-se que o protocolo SCTP ´e t˜ao bom quanto o TCP, e devido aos recursos adi-cionais, poderia obter melhor desempenho. Os protocolos TCP e UDP s˜ao muito bem estabelecidos, pois a maioria dos sistemas operacionais e aplicac¸˜oes n˜ao possuem suporte ao SCTP, as vantagens de utilizac¸˜ao sobre o TCP, ser˜ao bem maiores quando houver maior disponibilidade deste protocolo em sistemas operacionais e aplicac¸˜oes.
9.1. Ferramentas de testes
Alguns fatores influˆenciaram na realizac¸˜ao dos testes, as ferramentas Iperf 3.1 e D-ITG apresentaram algumas particularidades na implementac¸˜ao do protocolo SCTP. Com o Iperf 3.1 n˜ao foi poss´ıvel realizar os testes de Multihoming, pois a aplicac¸˜ao parece ter limitac¸˜oes no suporte ao socket das conex˜oes do SCTP, o protocolo indifica os IPs do host de destino, por´em, caso uma interface ´e desligada, o protocolo manda apenas mensagens HEARTBEAT para o destino, mas a transferˆencia de dados ´e interrompida at´e a conex˜ao ser abortada, esta limitac¸˜ao pode ser ocasionada pela ferramenta ser recente, e n˜ao est´a to-talmente desenvolvida. Os m´odulos ITGLog e ITGDec, da ferramenta D-ITG auxiliaram muito para capturar as estat´ısticas da conex˜ao.
9.2. Dificuldades encontradas
Uma das grandes dificuldades, foi encontrar ferramentas ou sistemas operacionais, que tenham suporte ao protocolo SCTP, apesar do protocolo estar em funcionamento, as aplicac¸˜oes D-ITG e Iperf n˜ao acompanham plenamente suas caracter´ısticas adicionais. Na realizac¸˜ao dos testes e para comparac¸˜ao dos resultados, foi necess´ario uma quantidade consideravelmente alta de testes por protocolo, repetindo v´arias vezes o mesmo processo, para n˜ao haver nenhum tipo de influˆencia nos resultados finais.
9.3. Trabalhos Futuros
O protocolo SCTP, motrou-se eficiente, por´em n˜ao foi poss´ıvel analisar seus recursos adicionais, como o Multihoming, devido algumas limitac¸˜oes das ferramentas de teste, se-ria de suma importˆancia a investigac¸˜ao de disponibilidade do recurso Multihoming em cen´arios de rede com m´ultiplos caminhos, utilizando aplicac¸˜oes que prorcionem mais recursos ao protocolo SCTP. Outro segmento de pesquisa bastante interessante, seria ana-lisar m´etodos de seguranc¸a do protocolo SCTP.
Referˆencias
Allman, M., Paxson, V., and Stevens, W. (1999). Tcp congestion control. RFC 2581, RFC Editor.
Botta, A., Dainotti, A., and Pescap`e, A. (2012). A tool for the generation of rea-listic network workload for emerging networking scenarios. Computer Networks, 56(15):3531–3547.
Chen, Y.-C., Towsley, D., Nahum, E. M., Gibbens, R. J., and Lim, Y.-s. (2012). Charac-terizing 4g and 3g networks: Supporting mobility with multi-path tcp. University of Massachusetts Amherst, Tech. Rep.
D-ITG (2013). Distributed internet traffic generator. http://traffic.comics. unina.it/software/IT/. Acessado em: 2016-09-30.
Daniel, G. (2005). SCTP uma alternativa aos tradicionais protocolos de transporte da internet. Editora Ciˆencia Moderna, Rio de Janeiro.
Daniel, G. (2007). Comunicac¸˜oes multimidia na internet. pages 219–252. Editora Ciˆencia Moderna, Rio de Janeiro.
Farrel, A. (2005). A internet e seus protocolos. pages 219–252. Editora Campus, Rio de Janeiro.
IANA (2016). Iana. https://www.iana.org/. IETF (2016). Ietf. https://www.ietf.org/.
Iperf (2016). Iperf. https://iperf.fr/. Acessado em: 2016-03-30.
KUROSE (2010). REDES DE COMPUTADORES E A INTERNET uma abordagem top-down. Pearson Education - Br, Rio de Janeiro.
Larzon, L.-A., Degermark, M., Pink, S., Jonsson, L.-E., and Fairhurst, G. (2004). The lightweight user datagram protocol (udp-lite). RFC 3828, RFC Editor.
Postel, J. (1980). User datagram protocol. STD 6, RFC Editor. http://www. rfc-editor.org/rfc/rfc768.txt.
Postel, J. (1981). Transmission control protocol. STD 7, RFC Editor. http://www. rfc-editor.org/rfc/rfc793.txt.
Stewart, R. (2007). Stream control transmission protocol. RFC 4960, RFC Editor. http: //www.rfc-editor.org/rfc/rfc4960.txt.
Tanenbaum, A. (2003). Redes de computadores. Editora Campus, S˜ao Paulo. Tcpdump (2016). Tcpdump. https://www.tcpdump.org.
UFRGS (2008). Protocolo sctp stream control transmission protocol. http://www.inf.ufrgs.br/ cechin/Net/sctp/sctp.html.
Wanem (2014). Wanem. http://wanem.sourceforge.net/. Acessado em: 2016-09-30.
Wireshark (2016). Wireshark. https://www.wireshark.org/. Acessado em: 2016-09-30.
