Análise de desempenho do protocolo SCTP (Stream Control Protocol Transmission)

Transcrição

1 Análise de desempenho do protocolo SCTP (Stream Control Protocol Transmission) Andrew Miranda da Silva 1, Eduardo Maroñas Monks 1 1 Curso Superior de Redes de Computadores Faculdade de Tecnologia SENAC Pelotas (FATEC) Rua Gonçalves Chaves Pelotas RS Brazil andrew.mirandadasilva@hotmail.com.br, emmonks@gmail.com Resumo. Este artigo apresenta uma análise comparativa sobre o desempenho dos protocolos da camada de transporte SCTP, TCP e UDP, por meio de testes em cenários com restrições de recursos. O objetivo é comparar o desempenho dos protocolos em ambientes de rede com atraso, perdas de pacote e restrições de largura de banda. Palavras-Chave: SCTP, TCP, UDP, análise, 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. Introdução Os protocolos da camada de transporte são um dos critérios mais importantes para comunicação entre os computadores de uma rede, pois proporcionam serviços de entrega confiável ou não confiável de dados para as aplicações. Segundo [Farrel 2005], os protocolos mais importantes para o transporte de dados na Internet, são os mais conhecidos e utilizados, TCP (Transmission Control Protocol) [Postel 1981] e UDP (User Datagram Protocol) [Postel 1980]. Existem outras soluções que desempenham este papel, tal como o protocolo SCTP (Stream Control Transmission Protocol) [Stewart 2007], que propõe ser uma alternativa viável ao TCP e UDP na implementacao de sistemas distribuídos. Na Internet, o protocolo TCP é bem estabelecido, porém houve uma necessidade da utilização do protocolo SCTP em conexões 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 diferenças em relação ao TCP e UDP, como a entrega sequencial de dados de usuário em múltiplos fluxos e tolerância a falhas de rede, através do suporte a múltiplos caminhos, além de ser orientado a conexão, o protocolo é Rate adaptative, ou seja, adapta-se dinamicamente a variação do estado de rede, com isto nota-se que o SCTP veio para ser uma alternativa mais robusta para transferência de fluxos de dados na rede [Daniel 2007]. Portanto este trabalho tem como objetivo analisar o desempenho e o comportamento do protocolo SCTP em cenários de rede com restrições de recursos, utilizando ferramentas de análise de tráfego para coletar e verificar os resultados obtidos, comparando aspectos de desempenho em relação aos protocolos TCP, SCTP e UDP.

2 2. Protocolos da Camada de Transporte Para que dois nós possam se comunicar, ambos devem especificar o mesmo protocolo [Tanenbaum 2003]. Os protocolos podem ser classificados como orientados a conexão (connection-oriented services) ou não orientados a conexão (connectionless). Os orientados a conexão, estabelecem uma sessão antes de transmitir qualquer informação, assim oferecendo garantia de entrega, melhor controle de fluxo e evitando congestionamento na transmissão de dados, tal como o TCP [KUROSE 2010]. O protocolo UDP, classifica-se como não orientado a conexão, pois pode enviar dados sem a necessidade de primeiramente estabelecer uma conexão entre emissor e receptor. Possibilitando que a entrega seja mais rápida, porém sem garantia de entrega [Postel 1980] Protocolo TCP (Transmission Control Protocol) O TCP possui diversos serviços e algoritimos responsáveis pela garantia de envio dos dados durante a transmissão, como a retransmissão de segmentos perdidos até controle de congestionamento da conexão [Allman et al. 1999]. Devido a sua complexidade e quantidade de operações envolvidas no serviço de transmissão, mais de uma RFC (Request for Comments) foi escrita para especificar e melhorar o seu desenvolvimento e funcionamento, desde a RFC 793 [Postel 1981]. O TCP utiliza somente métodos de conexão fim a fim, onde não há possibilidade de utilização do protocolo em sistemas multicast. Enquanto a comunicação entre os dois hosts for mantida, o tratamento será da forma full-duplex, o que permite que ambos os envolvidos na troca de dados enviem e recebam informações ao mesmo tempo [Farrel 2005]. Após o início de conexão, com o mecanismo de Three Way Handshake, a transferência de dados é tratada em sequência de octetos junto aos cabeçalhos de controle, ou seja, os dados são segmentados para ser enviados na rede. O tamanho de um segmento estabelecido pela origem, é 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] Protocolo UDP (User Datagram Protocol) O protocolo UDP é utilizado para fornecer uma comunicação simples, porém rápida e eficiente, por padrão não possui um gerenciamento de controle preciso de erro ou fluxo [Daniel 2007]. O principal objetivo do protocolo é realizar multiplexação entre várias comunicações. O protocolo até possui uma verificação opcional de erros dos dados, porém esta verificação serve apenas para descartar dados corrompidos durante a transmissão na rede [Postel 1980]. Este protocolo é bastante utilizado em redes multimídia para serviços de rede em tempo real, ou até mesmo em comunicações de sistemas multicast [Daniel 2007]. O UDP não realiza nenhum tipo de estabelecimento de conexão para transferir as mensagens de dados, é encapsulado em datagramas para ser transferido na rede [Postel 1980]. No ano de 2004, foi lançado a extensão do protocolo UDP, denominada de UDP-Lite [Larzon et al. 2004]. O diferencial desta extensão, foi que o propósito de criação aplicava-se para atuar em redes com altas taxas de erros, para beneficiar aplicações que utilizam classes de codecs de vídeos e áudio [Daniel 2007].

3 3. Protocolo SCTP (Stream Control Transport Protocol) O protocolo SCTP (Stream Control Transport Protocol), foi desenvolvido para fins de troca de mensagens telefônicas na Internet, rede denominada PSTN (Packet Switched Telephone Network). No ano 2000 foi lançada a primeira RFC 2960 [IETF 2001], por um grupo de engenheiros de rede do SIGTRAN, que submeteram ao IETF Internet Engineering Task Force [IETF 2016]. Dois anos após a criação do protocolo, foi lançado uma nova RFC 3308 [IETF 2003] descrevendo as alterações no algoritimo de soma de verificação. Atualmente, o protocolo encontra-se na RFC 4960 [Stewart 2007]. Segundo a RFC 2930 [IETF 2001], o protocolo é apresentado como de transporte confiável e orientado a conexão, utiliza recursos adicionais para melhorar o desempenho em rede, mas também possui funcionalidades do TCP e UDP embutidas. O SCTP opera em cima do protocolo IP, porém uma conexão só pode ser estabelecida se ambos os lados possuem o mesmo protocolo SCTP na camada de transporte. Em relação às portas de comunicação, o IANA [IANA 2016] definiu que as portas de comunicação TCP, automaticamente estariam reservadas para SCTP, permitindo o uso concorrente de TCP e SCTP para o mesmo serviço no mesmo número de porta [Pfutzenreuter E 2004]. Segundo [Daniel 2007], o protocolo SCTP pode ser atrativo para aplicações comuns na internet, principalmente, tratando-se de aplicações de multimídia Cabeçalho SCTP Um pacote SCTP é composto por um header comum, e chunks. Um chunk no cabeçalho SCTP é um campo que pode conter informações de controle ou dados de usuário [Stewart 2007]. Vários chunks podem ser multiplexados dentro de um pacote IP até que seja atingido o MTU. O header comum do SCTP é formado por 12 bytes, coontendo as portas de destinos e origem. A Tag de verificação indica o tamanho do chunk e o campo do cheksum [Stewart 2007]. A Figura 1 Cabeçalho SCTP, mostra os campos que compõe o cabeçalho do protocolo. Figura 1. Estrutura do cabeçalho SCTP com vários chunks [UFRGS 2008] 3.2. Orientado a Mensagens O protocolo trata os dados como blocos de mensagens independentes, ou seja, como sequência de dados fragmentados, dividindo os dados em partes e indentificando cada

4 parte para ser transmitida na rede, diferentimente do TCP, que trata os dados como sequência de octetos. O SCTP proporciona facilidade para aplicações que necessitam de confiabilidade na camada de trasnporte [Daniel 2005]. Tanto SCTP quanto TCP possuem o conceito de mensagem urgente, na transmissão de pacotes Associação Uma comunicação estabelecida entre dois hosts que utilizam SCTP, é feita através de uma associação, ou várias associações, negociada entre os participantes, diferente das conexões TCP/IP, que realizam apenas uma sessão full-duplex [Stewart 2007]. Conforme a descrição da RFC [Stewart 2007], justificam que o canal de comunicação SCTP é unidirecional, podendo haver um número desigual de fluxos, em cada direção. Nas associações SCTP, não existe um estado meio fechado half-closed isto serve tanto para associações e fluxos [Stewart 2007] Multihoming Uma das características mais interessantes do protocolo, é o suporte a multi-caminhos, denominado também como multi-homed. O objetivo deste mecanismo é criar mais de uma comunicação entre redes, com vários endereç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ância, devido a tolerância à falhas de uma das conexões IP de um dos enlaces. O SCTP permite que cada host informe uma lista de IPs. O endereço IP utilizado durante a criação da associação é classificado como IP primário, isto significa que esta conexão é o principal canal de comunicação com o host de destino remoto. Os demais IPs informados são secundários, que podem ser utilizados caso falhe a comunicação com o IP primário [Stewart 2007]. O SCTP controla o estado dos diversos IPs relacionado ao terminal remoto, de modo a sempre conhecer a situação de cada caminho alternativo realizando verificações, se todos os caminhos aparentemente falharem, a probabilidade é que o próprio destino remoto tenha falhado, e não as associações [Stewart 2007]. 4. Ferramentas Nesta seção, são abordadas as ferramentas utilizadas nos testes comparativos entre os protocolo TCP, UDP e SCTP D-ITG A ferramenta D-ITG (Distributed Internet Traffic Generator) [D-ITG 2013] é uma ferramenta capaz de produzir tráfego IPv4 e IPv6. Seu objetivo é medir as métricas de desempenho mais comuns, como taxa de transferência, atraso, jitter e perdas de pacotes. Atualmente a ferramenta suporta TCP, UDP, SCTP e DCCP na camada de transporte, possui quatro utilitários importantes para a realização dos testes, o ITGSend que é responsável por enviar o tráfego de rede, o ITGRecev que faz o papel do servidor e recebe o trafego, ITGLog é capaz de gerar logs de estatíticas do desempenho da conexão. O ITG- Dec realiza interpretação dos logs gerados [Botta et al. 2012] mostrando as estatísticas gerais das conexões. A versão da ferramenta utilizada nos testes foi a 2.8.

5 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 servidor Iperf em escuta, como em uma comunicação cliente e servidor, a ferramenta testa a capacidade máxima do meio de transmissão [Iperf 2016]. A versão utilizada nos testes é a 3.1, possui o módulo de suporte ao protocolo SCTP. A versão utilizada nos testes é para plataforma Linux, eo suporte para SCTP está apenas na versão beta da ferramenta [Iperf 2016] Tcpdump O Tcpdump é uma ferramenta de análise de tráfego em modo texto, também conhecida como sniffers de rede, onde seu objetivo é capturar e mostrar as conexões e transmissões de dados que trafegam pela interface de rede. Analisa o tráfego entrante e sainte de um host, possui diversos mecanismos e variações de filtros para as capturas de rede. Tanto Tcpdump quanto o Wireshark utilizam a biblioteca Libcap [Tcpdump 2016]. Esta ferramenta será utilizada para capturar o tráfego das interfaces de cada um dos hosts participantes da conexão Wireshark O Wireshark é uma aplicação de análise de tráfego de rede semelhante ao Tcpdump. Possui uma interface gráfica GUI (Graphical User Interface), onde é possível analisar as estatísticas de desempenho de uma determinada conexão. A versão utilizada para análise das capturas dos protocolos é a 2.0, que possui mecanismos de análise do protocolo SCTP [Wireshark 2016] WANem O WANem Wide Area Network Emulator [Wanem 2014], é uma distribuição Linux que pode emular um roteador de rede com restrições de recursos, como atraso de rede, restrição da largura de banda, perdas de pacotes. 5. Cenários de Testes Pare realização dos testes utilizou-se duas máquinas reais com três servidores virtualizados no VMware Workstation. Em duas máquinas virtuais foi utilizado a distribuição Debian 8, com as ferramentas D-ITG e Iperf. A terceira máquina virtual instalada no hospedeiro, é o roteador WANem, que será responsável por realizar as restrições de recursos na rede. Os hospedeiros estão conectados em uma rede ethernet, em um switch de 100Mbit/s Cenários sem Restrições O primeiro cenário de teste, é baseado no ambiente de rede local 100 Mbit/s. Neste cenário, não foi necessário a utilização do roteador WANem, apenas duas máquinas virtuais, com o sistema operacional Debian 8. Uma das máquinas virtuais está em modo cliente e a outra como servidor. A Figura 2 mostra a organização do cenário.

6 Figura 2. Estrutura do cenário sem restrições de recursos 5.2. Cenários com Restrições Na criação dos cenários com restrições de recursos de rede, acrescentou-se uma máquina virtual com a distribuição WANem versão 2.3, que efetuará o papel de um roteador para realizar as restrições de largura de banda, atraso e perdas de pacotes. Para estabelecer a comunicação do cliente com servidor na rede com restrições, foi necessário adicionar uma rota estática nos dois sentidos, passando pelo roteador WANem. A Figura 3 mostra a estrutura dos cenários com restrições de recurso. Figura 3. Estrutura dos cenários com restrições de recursos Restrições de recursos As restrições de recursos de rede foram baseadas em estatística de dois cenários reais da Internet, e dois ambientes de simulação com grande quantidade atraso e perdas. Um dos ambientes de rede, baseado em restrições 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ário baseado em restrições de redes reais, foi um levantamento de planos de Internet oferecido pelos principais provedores de Internet da região Sul do Brasil, baseado na publicação 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 especificamente na cidade de Pelotas, possui a média de 6 MBit/s. No cenário três, foi utilizado uma porcentagem razoável de perdas de pacote, para analisar a performance e o comportamento dos protocolos em ambientes com perdas maiores. As restrições do cenário quatro, foram baseadas na simulação de uma rede

7 de satélite, com taxas de atraso bem elevadas. A Tabela 1 mostra as restrições de rede aplicadas em cada cenário. Tabela 1. Tabela de restrições Restrições Cenário 1 (Wifi 3G/4G) Cenário 2 (Pelotas) Cenário 3 (Perdas) Cenário 4 (Satélite) 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 analisar o comportamento dos protocolos em rede, avaliando a capacidade de carga e o tempo de transferência das conexões. As ferramentas geram um fluxo de dados, utilizando a capacidade máxima da rede, no sentido cliente para o servidor, tanto em cenários com restrições quanto em cenários sem restrições. Para estabelecer uma padronização e devido 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 Megabytes e 10 Megabytes para os testes. No cenário quatro, foram realizados testes com streaming em paralelo. Neste cenário, o tempo de transferência dos dados foi de 60 segundos, com variações de duas a quatro conexões paralelas, sendo a quantidade de dados transferida na rede estabelecida pela vazão dos protocolos TCP, UDP e SCTP 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áfego no sentido ao servidor. Os testes foram realizados utilizandos os três protocolos da camada de transporte, TCP, UDP e SCTP. No tráfego de rede gerado pelo cliente, utilizou-se o tamanho fixo do fluxo de dados, endereço IP do servidor e o protocolo da camada de transporte. Nos testes efetuados com UDP, foi necessário apontar a largura de banda utilizada no cenário, pois o padrão da ferramenta é utilizar 1 Mbit/s 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ém alguns parâmetros para gerar o tráfego de rede foram acrescentados no cliente. O cliente Iperf 3.1, por padrão gera o trafego de rede com o tamanho dos pacotes de aproximadamente 1500 Bytes, para não haver influência nos resultados de vazão e tempo das conexões, foi adicionado no cliente D-ITG o parâmetro para utilizar pacotes de 1500 Bytes. 7. Resultados Os resultados de vazão e tempo nos testes de estresse realizados com a ferramenta Iperf e D-ITG, nos cenários de rede com e sem restrições. Os cenários de rede, utilizados nos testes com a ferramenta Iperf 3.1, foram mantidas nos testes realizados com o D-ITG. Os

8 resultados de vazão e tempo, tiveram pequenas diferenças entre as ferramentas, porém os protocolos apresentaram o mesmo comportamento em ambos os testes. O gráfico na Figura 4 mostra a média de vazão dos testes realizados em rede local. Na figura 5, o gráfico mostra os resultados de vazão dos cenários com restrições de recursos. Figura 4. Gráfico da média de vazão, nos testes realizados em rede Local Figura 5. Gráfico da média de vazão, nos testes realizados em cenários com restrições 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 geração de tráfego dos clientes para o servidor, devido a ferramenta possuir alternativas para testes em paralelo. Os testes foram realizados com tempo de transmissão pré-definido de 60 segundos com variações de 2 a 4 streaming nas transmissões de dados. Os cenários utilizados nos testes foram o de Rede Local e o cenário 3, simulação Satélite. Na Figura 6, mostra o gráfico com os resultados de vazão no tempo de transferência de 60 segundos. 8. Análise dos Resultados Os resultados indicam algumas diferenças entre os três protocolos da camada de transporte. Dependendo do cenário aplicado, ambos apresentam diferentes características de desempenho, devida a pequenas particularidades, na maioria dos casos, foram resultados esperados.

9 Figura 6. Gráfico dos resultados de vazão, nos testes de streaming em paralelo, nos cenários de rede local e Satélite TCP O protocolo TCP, teve o desempenho em rede igual ou superior ao protocolo SCTP em cenários sem restrições e cenários com restrições de largura de banda. A similaridade entre o protocolo SCTP e TCP é justificada por ambos serem confiáveis, orientado a conexão 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ência dos dados, o protocolo cumpriu com seus objetivos UDP Na avaliação do protocolo UDP, entre os três, foi o que melhor obteve vazão e menor tempo nas transmissões de dados, porém nos testes realizados em cenários com restrições de recursos, especificamente os que possuem características de atraso e perdas de pacotes, o protocolo teve a média de 18 % de perdas nos dados transferidos e aproximadamente 46 % de perda nos dados no cenário 3. Os resultados com o protocolo foram esperados, pois a grande característica do UDP é realizar transmissões de dados sem verificar o recebimento no destino [Postel 1980] SCTP Na análise do protocolo SCTP, observa-se que o desempenho em rede foi muito similar ao TCP, principalmente em cenários sem restrições de recurso. Nos cenários com restrições de largura de banda e atraso, não apresentou nenhuma grande superioridade em relação aos demais protocolos, tanto nos testes realizados com D-ITG e Iperf. O grande diferencial do SCTP, foi especificamente em cenários com perdas de pacotes, pois transferiu o fluxo integro de dados, com menor tempo de conexão 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ência e foi mais rápido 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ões SCTP, é que o protocolo gera uma taxa de controle considerável na rede overheads. 9. Considerações Finais Em uma análise geral das estatísticas dos resultados, o SCTP manteve-se com médias proporcionais entre os protocolos TCP e UDP, não apresentando nenhuma superioridade, a não ser em cenários com perdas de pacotes, onde obteve uma vantagem considerável. Nos testes realizados nota-se uma grande similaridade e características do SCTP com TCP. O

10 protocolo SCTP possui atributos interessantes, como o uso de Multihoming e Multistreaming, porém não estavam disponíveis por completo nas ferramentas e aplicações de teste. Conclui-se que o protocolo SCTP é tão bom quanto o TCP, e devido aos recursos adicionais, poderia obter melhor desempenho. Os protocolos TCP e UDP são muito bem estabelecidos, pois a maioria dos sistemas operacionais e aplicações não possuem suporte ao SCTP, as vantagens de utilização sobre o TCP, serão bem maiores quando houver maior disponibilidade deste protocolo em sistemas operacionais e aplicações Ferramentas de testes Alguns fatores influênciaram na realização dos testes, as ferramentas Iperf 3.1 e D-ITG apresentaram algumas particularidades na implementação do protocolo SCTP. Com o Iperf 3.1 não foi possível realizar os testes de Multihoming, pois a aplicação parece ter limitações no suporte ao socket das conexões do SCTP, o protocolo indifica os IPs do host de destino, porém, caso uma interface é desligada, o protocolo manda apenas mensagens HEARTBEAT para o destino, mas a transferência de dados é interrompida até a conexão ser abortada, esta limitação pode ser ocasionada pela ferramenta ser recente, e não está totalmente desenvolvida. Os módulos ITGLog e ITGDec, da ferramenta D-ITG auxiliaram muito para capturar as estatísticas da conexão 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 aplicações D-ITG e Iperf não acompanham plenamente suas características adicionais. Na realização dos testes e para comparação dos resultados, foi necessário uma quantidade consideravelmente alta de testes por protocolo, repetindo várias vezes o mesmo processo, para não haver nenhum tipo de influência nos resultados finais Trabalhos Futuros O protocolo SCTP, motrou-se eficiente, porém não foi possível analisar seus recursos adicionais, como o Multihoming, devido algumas limitações das ferramentas de teste, seria de suma importância a investigação de disponibilidade do recurso Multihoming em cenários de rede com múltiplos caminhos, utilizando aplicações que prorcionem mais recursos ao protocolo SCTP. Outro segmento de pesquisa bastante interessante, seria analisar métodos de segurança do protocolo SCTP. Referências Allman, M., Paxson, V., and Stevens, W. (1999). Tcp congestion control. RFC 2581, RFC Editor. Botta, A., Dainotti, A., and Pescapè, A. (2012). A tool for the generation of realistic network workload for emerging networking scenarios. Computer Networks, 56(15): Chen, Y.-C., Towsley, D., Nahum, E. M., Gibbens, R. J., and Lim, Y.-s. (2012). Characterizing 4g and 3g networks: Supporting mobility with multi-path tcp. University of Massachusetts Amherst, Tech. Rep.

11 D-ITG (2013). Distributed internet traffic generator. unina.it/software/it/. Acessado em: Daniel, G. (2005). SCTP uma alternativa aos tradicionais protocolos de transporte da internet. Editora Ciência Moderna, Rio de Janeiro. Daniel, G. (2007). Comunicações multimidia na internet. pages Editora Ciência Moderna, Rio de Janeiro. Farrel, A. (2005). A internet e seus protocolos. pages Editora Campus, Rio de Janeiro. IANA (2016). Iana. IETF (2016). Ietf. Iperf (2016). Iperf. Acessado em: 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. rfc-editor.org/rfc/rfc768.txt. Postel, J. (1981). Transmission control protocol. STD 7, RFC Editor. rfc-editor.org/rfc/rfc793.txt. Stewart, R. (2007). Stream control transmission protocol. RFC 4960, RFC Editor. http: // Tanenbaum, A. (2003). Redes de computadores. Editora Campus, São Paulo. Tcpdump (2016). Tcpdump. UFRGS (2008). Protocolo sctp stream control transmission protocol. cechin/net/sctp/sctp.html. Wanem (2014). Wanem. Acessado em: Wireshark (2016). Wireshark. Acessado em: