• Nenhum resultado encontrado

UNIVERSIDADE FEDERAL DE ALAGOAS-UFAL CAMPUS DE ARAPIRACA CIÊNCIA DA COMPUTAÇÃO ADRIANO ALVES DOS SANTOS

N/A
N/A
Protected

Academic year: 2021

Share "UNIVERSIDADE FEDERAL DE ALAGOAS-UFAL CAMPUS DE ARAPIRACA CIÊNCIA DA COMPUTAÇÃO ADRIANO ALVES DOS SANTOS"

Copied!
41
0
0

Texto

(1)

UNIVERSIDADE FEDERAL DE ALAGOAS-UFAL CAMPUS DE ARAPIRACA

CIÊNCIA DA COMPUTAÇÃO

ADRIANO ALVES DOS SANTOS

MÓDULO PLUGIN DO PROTOCOLO TCP PARA A ARQUITETURA DO SISTEMA OURNETSIM

ARAPIRACA 2019

(2)

Adriano Alves dos Santos

Módulo Plugin do Protocolo TCP para a Arquitetura do Sistema Ournetsim

Monografia apresentada como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação da Universidade Federal de Alagoas -UFAL, Campus de Arapiraca.

Orientador: Prof. Dr. Thiago Bruno Melo de Sales

Arapiraca 2019

(3)
(4)

Dedico este trabalho a Deus, minha família e a todas as pessoas que me auxiliaram a chegar até aqui.

(5)

AGRADECIMENTOS

Agradeço primeiramente a Deus por possibilitar que tudo isto seja possível. Agradeço aos meus pais por me darem a educação que tive. Agradeço a cada professor que fez parte dessa estrada. Agradeço a todos os meus amigos que me animaram nos momentos em que precisei e principalmente aos amigos do grupo RQL.

(6)

Tornar simples o complicado é fácil. Tornar o complicado simples, isto é criatividade.

(7)

RESUMO

O protocolo TCP é um dos protocolos usados na camada de transporte de redes, ele é responsável por garantir confiabilidade, entrega na sequência correta e realizar a verificação de erros nos pacotes de dados entre os diferentes nós da rede para a camada de aplicação. Entre as suas características estão o controle de fluxo e controle de congestionamento, onde são realizadas etapas que fazem com que a quantidade de dados enviada pelo remetente não inunde a rede enviando uma quantidade de segmentos maior que a suportada, causando perdas. Para auxiliar no entendimento do funcionamento do controle de congestionamento e de suas variantes, foi criada uma aplicação onde é possível simular em tempo real o comportamento de algumas das variantes do protocolo TCP, com a finalidade de ser um auxílio para o ensino sobre o protocolo TCP e o controle de congestionamento. Por fim foram validados os requisitos a partir dos cenários utilizados nos casos de uso.

Palavras-chave: Redes de computadores. Protocolo TCP. TCP Reno. TCP Tahoe. TCP Cubic. Simulador TCP.

(8)

ABSTRACT

The TCP protocol is one of the protocols used in the network transport layer, it is responsible for ensuring reliability, delivery in the correct sequence and performing error checking in the data packets between the different nodes of the network for the application layer. Among its features are flow control and congestion control, where steps are performed that cause the amount of data sent by the sender to not flood the network by sending a larger number of segments than the one supported, causing losses. In order to aid in the understanding of the operation of the congestion control and its variants, an application was created where it is possible to simulate in real time the behavior of some of the variants of the TCP protocol, in order to be an aid to the teaching on TCP protocol and the control of congestion. Finally, the requirements of the cases used in the use cases were validated.

Keywords: Computer Networking. TCP protocol. TCP Reno. TCP Tahoe. TCP Cubic. TCP Simulator.

(9)

LISTA DE FIGURAS

Figura 1 – Um protocolo humano e um protocolo de rede de computadores . . . 17

Figura 2 – A pilha de protocolos da Internet (a) e o modelo de referência OSI, da ISO (b) 18 Figura 3 – Buffers TCP de envio e de recepção . . . 20

Figura 4 – Estrutura do segmento TCP . . . 21

Figura 5 – Partida lenta . . . 23

Figura 6 – Retransmissão rápida . . . 24

Figura 7 – Controle de congestionamento . . . 25

Figura 8 – Gráfico TCP tahoe e TCP Reno . . . 27

Figura 9 – Gráfico TCP Reno e TCP Cubic . . . 29

Figura 10 – Diagrama de casos de uso . . . 32

Figura 11 – Diagrama de classes . . . 33

Figura 12 – Diagrama de sequência de sistema . . . 34

Figura 13 – Interruptores para seleção de variantes . . . 36

Figura 14 – Exemplo de uma simulação do TCP Tahoe no simulador . . . 37

(10)

LISTA DE QUADROS

Quadro 1 – Quadro de estados TCP Tahoe . . . 26 Quadro 2 – Quadro de estados TCP Reno . . . 27 Quadro 3 – Quadro de estados TCP Cubic . . . 30 Quadro 4 – Quadro comparativo entre o trabalho apresentado e o simulador Applet de

(11)

LISTA DE ABREVIATURAS E SIGLAS

ACK Acknowledgment(Pacote de confirmação de dados enviado pela parte recep-tora de uma comunicação TCP);

CWND Congestion Window(Janela de congestionamento);

FTP File Transfer Protocol(Protocolo de transferência de arquivos);

IMAP Internet Message Access Protocol (Protocolo de acesso a mensagem da internet);

HTTP Hypertext Transfer Protocol(Protocolo de transferência de hipertexto); HTTPS Hyper Text Transfer Protocol Secure(Protocolo de transferência de

hiper-texto seguro);

IP Internet Protocol(Protocolo da Internet);

MSS Maximum Segment Size(Tamanho maximo do segmento); POP3 Post Office Protocol(Protocolo dos correios);

RFC Request for Comments(Pedido de comentários);

RTT Round Trip Time(Tempo medido desde o envio de um pacote até a chegada da confirmação do recebimento do mesmo);

SMTP Simple Mail Transfer Protocol(Protocolo de transferência de correio sim-ples);

SSH Secure Shell;

SSTHRESH Slow Start Threshold(Limiar de partida lenta);

TCP Transmission control protocol(Protocolo de controle da transmissão); UDP User Datagram Protocol(Protocolo de Datagramas do Usuário);

Web Nome pelo qual a rede mundial de computadores internet se tornou conhe-cida a partir de 1991;

(12)

SUMÁRIO 1 INTRODUÇÃO . . . 14 1.1 MOTIVAÇÃO . . . 14 1.2 PROBLEMÁTICA . . . 14 1.3 OBJETIVOS . . . 15 1.3.1 Objetivo geral . . . 15 1.3.2 Objetivos específicos . . . 15 1.4 RELEVÂNCIA DO TRABALHO . . . 15

1.5 ESTRUTURA GERAL DO DOCUMENTO . . . 16

2 FUNDAMENTAÇÃO TEÓRICA . . . 17 2.1 PROTOCOLO . . . 17 2.2 PERDA DE PACOTES . . . 17 2.3 CAMADAS DE PROTOCOLO . . . 18 2.4 CAMADA DE TRANSPORTE . . . 18 2.5 PROTOCOLO TCP . . . 19 2.5.1 Estrutura do segmento TCP . . . 20 2.5.2 Controle de congestionamento . . . 21 2.5.2.1 Partida lenta . . . 22 2.5.2.2 Prevenção de congestionamento . . . 23 2.5.2.3 Retransmissão rápida . . . 23 2.5.2.4 Recuperação rápida . . . 24 2.5.3 Variantes do TCP . . . 25 2.5.3.1 TCP Tahoe . . . 25 2.5.3.2 TCP Reno . . . 26 2.5.3.3 TCP Cubic . . . 28 3 O SIMULADOR TCP . . . 31 3.1 REQUISITOS . . . 31 3.1.1 Requisitos funcionais . . . 31

3.1.2 Requisitos não funcionais . . . 31

3.1.3 Diagrama de casos de uso . . . 31

3.2 MODELAGEM . . . 32

3.2.1 Diagrama de classes . . . 32

(13)

3.3 TECNOLOGIAS UTILIZADAS . . . 34

3.4 ESCOLHA DAS VARIANTES UTILIZADAS . . . 34

4 ESTUDO DE CASOS . . . 36

4.1 USO DO SIMULADOR . . . 36

4.1.1 Escolhendo as variantes TCP . . . 36

4.1.2 Simulando o controle de congestionamento das variantes . . . 36

4.2 KUROSE APPLETS . . . 37

4.3 LIMITAÇÕES . . . 38

5 CONCLUSÕES E TRABALHOS FUTUROS . . . 40

(14)

14

1 INTRODUÇÃO

O controle de congestionamento do protocolo TCP possui uma variedade de algoritmos para controlar a velocidade de transmissão de dados através da internet, visando o gerenciamento da largura de banda e evitar o congestionamento de dados. Estes algoritmos possuem diferentes características e finalidades. Por ser algo de grande relevância para o funcionamento da Internet, torna-se um assunto importante no ensino para ser compreendido.

1.1 MOTIVAÇÃO

Embora o uso de tecnologias para auxílio no ensino não possa garantir uma maior qualidade no ensino, estas ajudam a enriquecer o ambiente de aprendizado quando utilizadas corretamente, possibilitando que o usuário possa ter um aprendizado de forma mais atrativa e interativa, incrementando o interesse dos alunos pelo assunto (TEIXEIRA; ARAUJO, 2007).

A Internet é uma das maiores criações tecnológicas já realizadas pela humanidade, com ela é possível que centenas de milhões de computadores possam trocar informações mesmo estando a vários quilômetros um do outro. A cada dia novos tipos de dispositivos eletrônicos são capazes de acessar a Internet, fazendo com que ela continue se expandindo rapidamente e tornando-se um meio cada vez mais importante e comum na vida das pessoas. Visto em como ela pode ser usada amplamente por vários aparelhos e para muitas finalidades, torna-se importante conhecer o que são e como funcionam as várias partes que formam a Internet.

Existe uma enorme quantidade de dados circulando através da Internet, porém nos canais onde eles circulam podem ocorrer problemas de perdas e congestionamento, para tratar isso, em uma das partes das camadas que compõem uma transmissão, existe o protocolo TCP, mecanismo de grande importância para que se possa ter um controle no envio de informação, gerenciando o fluxo de dados dos canais onde for utilizado. Este possui diferentes variantes que foram sendo desenvolvidas e aprimoradas ao passar do tempo, onde cada uma delas possui algoritmos para tratar estes problemas (KUROSE; ROSS, 2013).

1.2 PROBLEMÁTICA

Atualmente existem poucas ferramentas para o auxílio no ensino sobre as variantes do protocolo TCP. Muitas vezes os alunos não conseguem compreender o seu funcionamento somente visualizando a estrutura do algoritmo, mesmo com a explicação de exemplos dispo-níveis em textos e imagens nos livros. Para isso uma aplicação onde se possa demonstrar o

(15)

15

funcionamento dessas variantes seria um ótimo reforço no aprendizado desse conteúdo no ensino sobre redes de computadores. No momento existe o applet do Kurose (KUROSE; ROSS, 2006), ao qual possui a mesma finalidade, porém tem limitações na quantidade de variantes utilizadas e em quantidades de informações que são exibidas para o usuário. Além disso há também uma inexistência de soluções expansíveis, que permitam a adição de novas versões do TCP.

1.3 OBJETIVOS 1.3.1 Objetivo geral

Construir um simulador onde possa ser mostrado de maneira dinâmica o comportamento dos algoritmos do controle de congestionamento de algumas das principais variantes do protocolo TCP.

1.3.2 Objetivos específicos

A aplicação anteriormente descrita foi elaborara seguindo os seguintes requisitos: • Mostrar graficamente o comportamento do controle de congestionamento das variantes

TCP;

• Simular os diferentes tipos eventos possíveis que ocorrem no controle de congestiona-mento;

• Exibir as informações das variantes conforme elas forem atualizadas; • Escolher qual das variantes disponíveis a aplicação deve exibir;

• Possa ser executada através de diferentes dispositivos, tais como navegadores WEB e aplicativos de smartphones.

• Validar os requisitos a partir de estudos de caso exercitando cenários dos casos de uso.

1.4 RELEVÂNCIA DO TRABALHO

O trabalho será de relevância para os alunos ou quaisquer interessados no assunto, pois se tornará uma ferramenta importante no auxílio do ensino de redes sobre o funcionamento dos algoritmos das variantes do protocolo TCP.

Com a construção e uso do trabalho haverá um ganho no interesse e na motivação dos alunos em relação ao conteúdo ao qual a ferramenta auxilia no ensino. Softwares educativos são

(16)

16

um tipo de material que geram situações onde o aluno possa interagir e fazer parte da simulação, tornando o aprendizado mais amigável e interessante.

"Softwares educativos (jogos e animações) podem ser utilizados na educação de maneira geral, pois é um material que consegue inserir o aluno em situa-ções que os façam refletir, interagir, fazer parte da alguma simulação do real, induzindo-os a buscar soluções ou hipóteses a serem testadas. Esse processo resultará no aumento dos mais variados saberes, além de proporcionar mo-mentos de interação/lazer, tornando o ato da aprendizagem mais interessante e motivador."(ARMSTRONG; CASEMENT, 2001 apud TEIXEIRA; ARAUJO, 2007)

Sem o uso do simulador, existe a dificuldade em compreender corretamente o funciona-mento e importância do gerenciafunciona-mento do fluxo de dados através dos algoritmos das variantes do protocolo TCP. Como consequência do maior engajamento discente devido ao uso do simulador, é possível que haja redução na taxa de retenção da disciplina.

1.5 ESTRUTURA GERAL DO DOCUMENTO

O trabalho foi dividido em capítulos da seguinte forma:

• Capítulo 1: Apresentou-se a introdução do trabalho, onde foi mostrada a motivação, problemática, objetivos, relevância e está sendo mostrada a estrutura geral do documento do mesmo;

• Capítulo 2: É descrito a fundamentação teórica, são apresentados os conteúdos seleciona-dos para a construção do trabalho;

• Capítulo 3: É descrito como foi criada e como se dá o funcionamento da aplicação; • Capítulo 4: São descritos os casos de uso;

(17)

17

2 FUNDAMENTAÇÃO TEÓRICA

2.1 PROTOCOLO

Um protocolo de rede é o conjunto de regras que vai organizar a troca de mensagens para que esta seja eficiente e eficaz. Ele é parecido com uma conversa entre pessoas, alterando somente os receptores e emissores humanos por componentes de hardware ou software de algum dispositivo eletrônico com acesso a Internet. Sempre que há alguma atividade entre dispositivos remotos na internet, estas são gerenciadas através de um protocolo. Em uma conversa entre humanos, como ilustrada na Figura 1, uma pessoa cumprimenta a outra, ou seja, transmite uma mensagem, que então é recebida por uma ou mais pessoas. Após isso estas podem responder a mensagem cumprimentando de volta, isto pode ser comparado à uma solicitação de conexão de dispositivos eletrônicos como ilustrada na Figura 1. Após isso se inicia então um dialogo entre as pessoas, que desta vez pode ser comparado a requisições e envios de dados (KUROSE; ROSS, 2013).

Figura 1 – Um protocolo humano e um protocolo de rede de computadores

Fonte: (KUROSE; ROSS, 2013).

2.2 PERDA DE PACOTES

Sempre que um pacote não chega ao seu destino dentro do tempo previsto temos uma indicação de uma possível perda de pacote. Dentre os motivos para que isto ocorra, temos o

(18)

18

congestionamento de pacotes. Para que um pacote chegue até o seu destino através da rede, ele passa por vários nós no caminho, os roteadores. Estes possuem um buffer onde existe uma fila de pacotes que será processada para que cada pacote seja enviado para o próximo nó do seu caminho. Porém, caso o roteador receba uma quantidade maior de pacotes do que consegue processar, quando este pacote for recebido o buffer estará cheio, e o pacote será descartado causando uma perda (KUROSE; ROSS, 2013).

2.3 CAMADAS DE PROTOCOLO

Os protocolos definem a forma de comunicação das camadas da internet, a qual é chamada de pilha de protocolos. A pilha de protocolos da Internet é formada por cinco camadas: física, de enlace, de rede, de transporte e de aplicação, como ilustradas abaixo na Figura 2.

Figura 2 – A pilha de protocolos da Internet (a) e o modelo de referência OSI, da ISO (b)

Fonte: (KUROSE; ROSS, 2013).

2.4 CAMADA DE TRANSPORTE

O papel básico da camada de transporte é o suporte para a comunicação ponta a ponta entre os dois hospedeiros na rede. É uma parte importante da hierarquia de protocolos que fornece serviços de transmissão de dados com boa relação custo-benefício da fonte ao destino. Os serviços fornecidos pela camada de transporte são: serviço orientado à conexão, entrega confiável, controle de fluxo e multiplexação (KUMAR; RAI, 2012).

(19)

19

Através da comunicação lógica oferecida camada de transporte, os processos da camada de aplicação podem se comunicar entre hospedeiros em diferentes locais. Uma aplicação em execução nos hospedeiros da rede não precisa se preocupar com a forma utilizada para o transporte dessa comunicação, sendo esta gerenciada através da camada de transporte (KUROSE; ROSS, 2013).

2.5 PROTOCOLO TCP

O TCP é um dos principais protocolos da camada de transporte. Ele é orientado a conexão e fornece um fluxo de bytes confiável para a camada superior, a camada de aplicação, como ilustrada na Figura 2. O TCP tem seu funcionamento baseado em confirmações positivas e também fornece um mecanismo de prevenção de congestionamento para reduzir a quantidade de dados enviados quando a rede fica sobrecarregada (RAHMANI et al., 2008).

Os navegadores Web usam o TCP quando se conectam a servidores através da internet, que é usado para enviar e-mail e realizar a transferência arquivos de um local para outro. HTTP, HTTPS, SMTP, POP3, IMAP, SSH, FTP, Telnet e uma variedade de outros protocolos são normalmente encapsulados no protocolo TCP (SINGH et al., 2014).

Uma informação enviada através do protocolo TCP é dividia em várias partes para então serem enviadas pela rede. Essas partes se chamam segmentos, onde cada um deles contêm campos com informações para o funcionamento do protocolo junto do campo onde ficam os dados que estão sendo enviados. Os segmentos saem do buffer TCP de envio percorrendo a rede até que este chegue ao buffer TCP de recepção como ilustrado na Fugira 3, onde serão novamente reunidos compondo a informação integra, este processo de dividir os dados em pedaços e depois reuni-las novamente se chama de demultiplexação e multiplexação respectivamente (KUROSE; ROSS, 2013).

(20)

20

Figura 3 – Buffers TCP de envio e de recepção

Fonte: (KUROSE; ROSS, 2013).

2.5.1 Estrutura do segmento TCP

Os segmentos TCP possuem vários campos em sua estrutura, aos quais são utilizados para que os mecanismos do protocolo possam identificar os detalhes e gerenciar o envio de dados através de uma conexão, a estrutura de um segmento TCP que é ilustrada na Figura 4 é formada por:

• Porta de origem: Possui 16 bits e representa o número da porta do servidor da camada superior.

• Porta de destino: Possui 16 bits e representa o número da porta do cliente da camada superior.

• Número de sequência: Possui 32 bits e representa o número de sequência pertencente ao segmento que foi enviado.

• Número de reconhecimento: Possui 32 bits e representa o número de sequência pertencente ao próximo segmento que deve ser enviado.

• Janela de recepção: Possui 16 bits e é usado para o controle de fluxo.

• Opções: é usado quando um remetente e um destinatário negociam o MSS, ou como um fator de aumento de escala da janela para utilização em redes de alta velocidade.

• Comprimento do cabeçalho: Possui 4 bits e especifica o comprimento do cabeçalho TCP em palavras de 32 bits.

(21)

21

• Não utilizado: Possui 6 bits e é reservado para usos futuros. Deve ser zero.

• Campo de flag: Possui 6 bits e é formado por ACK que é usado para indicar se o valor carregado no campo de reconhecimento é válido; RST que é usado para reiniciar uma conexão; SYN que é usado para sincronizar os números de sequencia; FIN que é usado para indicar que não há mais dados para serem enviados; PSH é usado para indicar que o destinatário deve passar os dados para a camada superior imediatamente; URG é usado para mostrar que há dados nesse segmento que a entidade da camada superior do lado remetente marcou como “urgentes”.

Figura 4 – Estrutura do segmento TCP

Fonte: (KUROSE; ROSS, 2013).

2.5.2 Controle de congestionamento

O controle de congestionamento do TCP funciona com base no recebimento de segmentos com reconhecimento positivo (Acknowledgement ou ACK) para cada pacote que foi enviado. Elas possuem também um número de reconhecimento, informado do cabeçalho do segmento TCP. Para isto o TCP possui um temporizador que quando o seu tempo é expirado há a indicação que ouve uma perda. A perda também pode ser detectada previamente caso haja a repetição de um mesmo número de reconhecimento (ACK’s duplicados) definido na RFC 2581 (ALLMAN et al., 2009).

(22)

22

O TCP controla a taxa de dados de uma conexão de modo que os remetentes possam aumentar a quantidade de segmentos enviados ao mesmo tempo em que evita com que a rede fique congestionada, para isso ele diminui a taxa de transmissão sempre que um segmento é perdido, aumenta a taxa sempre que um segmento é aceito e busca manter a taxa próxima da qual onde ocorreu a perda, de modo a usar melhor a largura de banda disponível, para isto o algoritmo tem como seus mecanismos principais a partida lenta, prevenção de congestionamento e recuperação rápida (KUROSE; ROSS, 2013).

2.5.2.1 Partida lenta

Partida Lenta (Slow Start) é um mecanismo do protocolo TCP que é usado no inicio ou quando é feita a reinicialização da taxa de envio de segmentos. Ele usa uma variável cwnd (congestion window - janela de congestionamento) para enumerar a quantidade de segmentos enviados. É geralmente iniciada em 1 MSS (Maximum Segment Size - variável que indica o tamanho maximo de cada segmento TCP) de acordo com a RFC 3390 (ALLMAN et al., 2002) para então ser aumentada buscando a largura de banda disponível. Esse crescimento se dá a medida em que a confirmação dos segmentos enviados é recebida. Para cada ACK recebido a janela de congestionamento é incrementada em um segmento, ou seja, quando o ACK do primeiro segmento é recebido, a janela aumenta para dois segmentos. Quando os ACK’s destes dois segmentos são recebidos, a janela aumenta para quatro segmentos como ilustrado na Figura 5, fazendo com que embora o mecanismo se chame partida lenta a janela tenha um crescimento exponencial. Esse comportamento se mantém até que haja uma perda fazendo com a janela reinicie para o valor de 1 MSS e ssthresh caia para metade do atual valor de cwnd. Ssthresh é outra variável adicional utilizada pra definir um limite para a partida lenta. Ela tem o valor inicial 64KB e quando a janela deixa de ser menor que ela o algoritmo passa para o estado de prevenção de congestionamento conforme ilustrado na figura 7.

(23)

23

Figura 5 – Partida lenta

Fonte: (KUROSE; ROSS, 2013).

2.5.2.2 Prevenção de congestionamento

A prevenção de congestionamento (Congestion Control) busca incrementar a quantidade de segmentos enviados de forma menos agressiva que a partida lenta. Esse estado é acionado quando cwnd atinge metade do valor de onde houve uma perda anterior, através do ssthresh que cai para metade a cada evento de perda, ou seja, a prevenção de congestionamento é acionada quando cwnd >= ssthresh. Para que o crescimento seja menos agressivo foi definido na RFC 5681 (ALLMAN et al., 2009) o incremento de apenas 1 MSS para cada RTT (Round Trip Time -tempo gasto para o recebimento do reconhecimento de um pacote enviado) . Em caso de perda na prevenção de congestionamento, o estado partida lenta é retomado e mantém-se o mesmo comportamento reiniciando a cwnd para 1 MSS e ssthresh para metade de seu valor conforme ilustrado na figura 7.

2.5.2.3 Retransmissão rápida

A retransmissão rápida (Fast Retransmit) é um mecanismo do controle de congestiona-mento que entra em ação quando se recebem segcongestiona-mentos com o mesmo número de reconhecicongestiona-mento (ACK’s duplicados), como ilustrado na Figura 6. Foi definido na RFC 2581 (ALLMAN et al., 2009) a indicação de perda pra três ACK’s duplicados, quando isto ocorre dentro da tempori-zação (intervalo de tempo para que o mecanismo considere que houve uma perda) será feita

(24)

24

uma redução na cwnd e a retransmissão deste segmento, evitando que ocorra um estouro do temporizador (timeout - evento onde um reconhecimento de um pacote demora um tempo maior que o do temporizador para retornar).

Figura 6 – Retransmissão rápida

Fonte: (KUROSE; ROSS, 2013).

2.5.2.4 Recuperação rápida

A Recuperação rápida (Fast Recovery) é uma alteração no decremento da cwnd quando ocorre a contagem de três ACK’s duplicados, ao invés de acionar a retransmissão rápida e aplicar o reinicio na cwnd para 1 MSS, a janela cai para metade do valor mais a adição dos três ACK’s duplicados, permanecendo em prevenção de congestionamento como ilustrado na Figura 7, desta forma o estado partida lenta somente será retomado e a janela reiniciada caso haja um estouro no temporizador (KUROSE; ROSS, 2013).

(25)

25

Figura 7 – Controle de congestionamento

Fonte: (KUROSE; ROSS, 2013).

2.5.3 Variantes do TCP

Ao longo do tempo o algoritmo do controle de congestionamento TCP foi ganhando alterações, com várias versões, cada uma delas possui diferenças em como e quando alterar a janela de congestionamento, e também na forma de reação, sendo uma reação a perda (Loss feedback) ou uma reação ao tempo entre o envio de segmentos (Delay feedback), onde cada um busca ter vantagem em cenários específicos, como maior uso de banda disponível ou menores taxas de perda.

2.5.3.1 TCP Tahoe

A implementação do TCP Tahoe adicionou mecanismos para o controle de congestio-namento e com o passar do tempo foram criadas modificações a partir da sua implementação criando novas versões. Os algoritmos presentes no Tahoe incluem partida lenta, prevenção de congestionamento e recuperação rápida, algoritmo que apareceu pela primeira vez nessa versão de implementação do TCP (STEVENS, 1997).

(26)

26

O algoritmo do Tahoe em resumo funciona conforme apresentado no quadro 1. Quadro 1 – Quadro de estados TCP Tahoe

Estado Evento Ação

Partida lenta ACK

cwnd <ssthresh

cwnd = cwnd + 1(para cada ACK) estado = Partida lenta Partida lenta Timeout

cwnd = 1 ssthresh = cwnd/2 estado = Partida lenta Partida lenta 3 ACK’s duplicados

cwnd = 1 ssthresh = cwnd/2 estado = Partida lenta

Partida lenta ACK

cwnd >= ssthresh cwnd = cwnd + 1(para cada RTT) estado = Prevenção de congestionamento Prevenção de congestionamento ACK cwnd = cwnd + 1(para cada RTT) estado = Prevenção de congestionamento Prevenção de congestionamento Timeout cwnd = 1 ssthresh = cwnd/2 estado = Partida lenta Prevenção de

congestionamento 3 ACK’s duplicados

cwnd = 1 ssthresh = cwnd/2 estado = Partida lenta Fonte: Autor do trabalho (2019).

2.5.3.2 TCP Reno

A implementação do TCP Reno é uma modificação da versão do TCP Tahoe onde é incrementada mais um mecanismo, a recuperação rápida aparecendo pela primeira vez nessa implementação (STEVENS, 1997), onde passa a tratar o recebimento de três ACK’s duplicados de maneira diferente, aqui ao invés de reiniciar cwnd para 1 MSS, o valor passa a ser de cwnd/2 + 3 e o estado de prevenção de congestionamento é mantido. A diferença do comportamento do

TCP Tahoe e TCP Reno é ilustrada na Figura 8.

(27)

27

Quadro 2 – Quadro de estados TCP Reno

Estado Evento Ação

Partida lenta ACK

cwnd <ssthresh

cwnd = cwnd + 1(para cada ACK) estado = Partida lenta Partida lenta Timeout

cwnd = 1 ssthresh = cwnd/2 estado = Partida lenta

Partida lenta 3 ACK’s duplicados

ssthresh = cwnd/2 cwnd = (cwnd/2)+3 estado = Prevenção de

congestionamento

Partida lenta ACK

cwnd >= ssthresh cwnd = cwnd + 1(para cada RTT) estado = Prevenção de congestionamento Prevenção de congestionamento ACK cwnd = cwnd + 1(para cada RTT) estado = Prevenção de congestionamento Prevenção de congestionamento Timeout cwnd = 1 ssthresh = cwnd/2 estado = Partida lenta Prevenção de

congestionamento 3 ACK’s duplicados

ssthresh = cwnd/2 cwnd = (cwnd/2)+3 estado = Prevenção de

congestionamento Fonte: Autor do trabalho (2019).

Figura 8 – Gráfico TCP tahoe e TCP Reno

(28)

28

2.5.3.3 TCP Cubic

O TCP Cubic tem seu algoritmo de congestionamento baseado no seu antecessor TCP BIC (Binary Increase Congestion Control), de forma a simplificar a sua janela de congestionamento. O algoritmo usa uma função cúbica para controlar o incremento de cwnd, e por isso recebe esse nome. Ele foi criado com o intuito de melhorar a eficiência de redes de longa distância e que possuem alta taxa de transmissão (HA et al., 2008).

O TCP cubic acrescenta as seguintes variáveis em seu algoritmo: • C: Costante escalar

• t: Tempo desde a última perda

• B: Multiplicador de redução para os evento de perdas • Wmax: Tamanho da janela antes da última perda

Equação 1 TCP Cubic W (t) = C(t − k)3+ W max Equação 2 TCP Cubic k = 3 r (W max ∗ B) C

O Cubic inicia sua janela por padrão TCP de partida lenta, quando acontece um evento de perda, o cubic grava o tamanho de cwnd deste evento de perda atribuindo-o para Wmax e de-crementa a janela em razão de um multiplicador B e realiza a recuperação e retransmissão rápida por padrão do TCP, após isto na prevenção de congestionamento o cubic passa a incrementar a janela utilizando uma função cúbica das Equações 1 e 2, que tem uma taxa de crescimento alta e vai sendo reduzida conforme cwnd se aproxima do valor de Wmax como ilustrado na Figura 9 até que o valor seja ultrapassado e a taxa de incremento comece a crescer novamente até que haja novamente uma perda.

(29)

29

Figura 9 – Gráfico TCP Reno e TCP Cubic

Fonte: (HUSTON, 2018)

(30)

30

Quadro 3 – Quadro de estados TCP Cubic

Estado Evento Ação

Partida lenta ACK

cwnd = cwnd + 1(para cada ACK) estado = Partida lenta

Partida lenta Timeout

Wmax = cwnd cwnd = 1

t = 0

ssthreshold = Wmax estado = Partida lenta

Partida lenta 3 ACK’s duplicados

k = raiz cubica(Wmax*((B)/C)) t = 0 Wmax = cwnd ssthreshold = Wmax cwnd = C * raiz cubica(t -k)+ Wmax estado = Prevenção de congestionamento Prevenção de congestionamento ACK k = raiz cubica(Wmax*((B)/C)) cwnd = cwnd + C * raiz cubica (t - k) + Wmax

Wmax = Wmax * B t++ Prevenção de congestionamento Timeout Wmax = cwnd cwnd = 1 t = 0 ssthreshold = Wmax; estado = Partida lenta

Prevenção de

congestionamento 3 ACK’s duplicados

k = raiz cubica(Wmax*((B)/C)) t = 0 Wmax = cwnd ssthreshold = Wmax cwnd = C * raiz cubica (t -k)+ Wmax; estado = Prevenção de congestionamento Fonte: Autor do trabalho (2019).

(31)

31

3 O SIMULADOR TCP

Neste capítulo são apresentados a aplicação que foi desenvolvida, os requisitos do sistema, a modelagem e aspectos da implementação do simulador.

3.1 REQUISITOS

Os requisitos são especificações do que será criado em um sistema. Os requisitos funcio-nais descrevem as funcionalidades que um sistema deve atender. Os requisitos não funciofuncio-nais descrevem requisitos chamados de qualidade, sendo relacionados ao uso da aplicação (PRESS-MAN; MAXIM, 2016).

3.1.1 Requisitos funcionais

• Exibir graficamente o comportamento do controle de congestionamento de variantes TCP; • Comparar comportamento através do gráfico e dos estados exibidos das variantes em

tempo real;

• Escolher qual das variantes disponíveis a aplicação deve exibir; • Controlar os possíveis eventos através de botões;

• Exibir as informações das variantes conforme elas forem atualizadas.

3.1.2 Requisitos não funcionais

• Possa ser executada em diferentes dispositivos, tais como navegadores WEB e aplicativos de smartphones.

• Dar suporte a outras variantes TCP.

3.1.3 Diagrama de casos de uso

As possíveis ações do usuário do sistema são exibidas no diagrama de casos de uso da Figura 10. O usuário tem controle do sistema através dos botões na interface da aplicação, podendo selecionar quais variantes a aplicação exibirá, simular o evento onde ocorre uma retransmissão devido a três ACK’s duplicados, simular o evento do estouro do temporizador (Timeout), iniciar ou pausar a simulação e reiniciar a aplicação:

(32)

32

Figura 10 – Diagrama de casos de uso

Fonte: Autor do trabalho (2019).

3.2 MODELAGEM

3.2.1 Diagrama de classes

A Figura 11 apresenta um resumo das classes utilizadas na criação do simulador, o sistema apresentado possui as três classes do funcionamento do TCP presentes no diagrama, mais duas classes responsáveis pela parte gráfica, das quais todas herdam métodos por padrão da classe MonoBehaviour, classe base do motor gráfico Unity. A classe Características_Graficas é responsável por ter os atributos e métodos referentes às características gráficas das outras classes, como a cor dos pontos e linhas que compõem o gráfico que representa os protocolos. A classe Grafico é responsável por desenhar o gráfico que representa a variação do tamanho das janelas de congestionamento de cada variante e controlar as funcionalidades das ações de cada botão da interface. A classe Tcp possui os atributos e métodos padrões de uma variante TCP, possui um método abstrato que será implementado de maneira diferente para cada classe das variantes e possui herança da classe Caracteristicas_Graficas. As Classe Tcp_Tahoe, Tcp_Reno

(33)

33

e Tcp_Cubic herdam os atributos e métodos da classe Tcp onde cada um usa uma sobrescrita na função Calcular() para usar o seu próprio algoritmo.

Figura 11 – Diagrama de classes

Fonte: Autor do trabalho (2019).

3.2.2 Diagrama de sequência de sistema

A sequência de acontecimentos entre o usuário e o sistema é exibida na Figura 12. Para o uso da simulação o usuário seleciona as variantes que serão exibidas e inicia a simulação através dos botões da interface. Após isto o algoritmo é acionado e realizará o cálculo da nova janela de cada variante selecionada, onde serão atualizadas as informações das variáveis do algoritmo de cada variante e será criado o gráfico onde a interface o exibirá.

(34)

34

Figura 12 – Diagrama de sequência de sistema

Fonte: Autor do trabalho (2019).

3.3 TECNOLOGIAS UTILIZADAS

Para a implementação da ferramenta, foram utilizados o motor gráfico Unity 3d para criar a interface juntamente com a linguagem de programação C# para a criação dos algoritmos necessários para simular o comportamento das variantes.

3.4 ESCOLHA DAS VARIANTES UTILIZADAS

Para a criação do sitema, foram selecionadas três das principais variantes do protocolo TCP, são elas:

• TCP Tahoe; • TCP Reno; • TCP Cubic.

A escolha do TCP Tahoe foi dada em vista de ser a primeira versão a usar os mecanismos de controle de congestionamento. O TCP Reno foi utilizado por ser uma atualização do TCP Tahoe, sendo de relevância mostrar suas diferenças de funcionamento com a adição do mecanismo

(35)

35

de recuperação rápida. O TCP Cubic foi utilizado por ser um dos mais populares algoritmos do TCP sendo a versão padrão usada no sistema operacional Linux (HA et al., 2008).

(36)

36

4 ESTUDO DE CASOS

Neste capítulo descreve-se os passos para o uso das funções do simulador e ilustra-se quais os passos para realizar o incremento de novas variantes ao sistema.

4.1 USO DO SIMULADOR

4.1.1 Escolhendo as variantes TCP

Para a escolha das variantes do sistema, o usuário deve selecionar quais das três variantes ele deseja acompanhar na simulação, isto é feito através dos três interruptores na interface indicados na Figura 13. À direita de cada um deles é indicado o nome da variante e à esquerda as cores das linhas e pontos que representam a variante. Quando estes são ativados, o gráfico e as informações da variante correspondente passam a ser exibidos. As três variantes disponíveis vêm ativadas por padrão.

Figura 13 – Interruptores para seleção de variantes

Fonte: Autor do trabalho (2019).

4.1.2 Simulando o controle de congestionamento das variantes

Para realizar a simulação das variantes do sistema, o usuário deve clicar nos três botões localizados na parte inferior da interface, abaixo dos interruptores indicados na Figura 13, onde cada um deles possui o nome da função do mesmo. O botão Start/Pause serve para iniciar a

(37)

37

simulação ou para pausa-la, caso a simulação esteja pausada, o botão continuará a simulação deste ponto. O botão TIMEOUT simula um evento de estouro de temporizador e pausa a atividade para a observação do resultado em cada variante. O botão Triple ACK simula um evento de três ACK’s duplicados e pausa a atividade para a observação do resultado em cada variante.

Com o uso de cada botão é possível realizar a simulação e observar o comportamento das variantes selecionadas através do gráfico e informações que são gerados pelo simulador, como ilustrado na Figura 14.

Figura 14 – Exemplo de uma simulação do TCP Tahoe no simulador

Fonte: Autor do trabalho (2019).

4.2 KUROSE APPLETS

Existe um conjunto de applets de redes (KUROSE; ROSS, 2006) onde possui um si-mulador de controle de congestionamento com a mesma finalidade do trabalho, simulando o comportamento de duas das variantes TCP de forma dinâmica, como ilustrado na Figura 15.

(38)

38

Figura 15 – Kurose Applet

Fonte: (KUROSE; ROSS, 2006)

Porém esta simulação possui limitações em quantidades de informações exibidas ao usuário, onde não é possível saber a quantidade de segmentos e o estado de cada variante no momento em que um evento de perda ocorre, além disso, também não é possível realizar a adição de outras variantes.

No Quadro 4 são apresentadas as diferenças entre os dois simuladores.

Quadro 4 – Quadro comparativo entre o trabalho apresentado e o simulador Applet de Kurose Característica do simulador Aplicação do trabalho Kurose Applet

Desenhar gráfico da janela sim sim

Seleção de variantes sim sim

Simular eventos sim sim

Exibir informação dos estados da variantes sim não

Exibir informação tamanho da janela sim não

Adicionar outras variantes sim não

Funcionamento multiplataforma sim não

Fonte: Autor do trabalho (2019).

4.3 LIMITAÇÕES

A aplicação desenvolvida possui algumas limitações ao uso das variantes as quais podem ser utilizadas. Embora possam ser adicionadas novas variantes ao sistema, essas devem possuir o algoritmo com reação a perda, visto que o simulador interpreta o recebimento de cada janela

(39)

39

inteira e não simula a variação do tempo de cada segmento, somente o recebimento, não recebimento ou duplicação do mesmo.

(40)

40

5 CONCLUSÕES E TRABALHOS FUTUROS

Este trabalho apresentou a aplicação módulo plugin do protocolo tcp para a arquitetura do sistema. Acredita-se que o trabalho servirá como um bom auxílio para o aprendizado de redes sobre o controle de congestionamento do protocolo TCP.

Embora a ferramenta já possa ser utilizada, há funcionalidades que podem ser adicionadas futuramente. Assim sendo, para incrementos de trabalhos futuros, seria interessante a adição de novas variantes, suporte a variantes com reação a latência, compartilhamento de largura de banda entre as variantes da simulação e a personalização de velocidade e da simulação. Além disto a realização de uma avaliação sobre o impacto educacional do simulador.

O simulador foi criado para auxiliar os alunos no ensino de maneira prática e dinâmica. A aplicação auxilia no entendimento do funcionamento do controle de congestionamento do protocolo TCP e algumas de suas principais variantes.

A aplicação possui código aberto, há facilidade em ser modificada e melhorada por outras pessoas ao passar do tempo. Espera-se que a aplicação tenha um auxílio positivo no aprendizado nestas características do protocolo TCP.

(41)

41

REFERÊNCIAS

ALLMAN, M.; FLOYD, S.; PARTRIDGE, C. Increasing TCP’s initial window. [S.l.], 2002. ALLMAN, M.; PAXSON, V.; BLANTON, E. TCP congestion control. [S.l.], 2009.

ARMSTRONG, A.; CASEMENT, C. A criança ea máquina. [S.l.]: Artmed, 2001.

HA, S.; RHEE, I.; XU, L. Cubic: a new tcp-friendly high-speed tcp variant. ACM SIGOPS operating systems review, ACM, v. 42, n. 5, p. 64–74, 2008.

HUSTON, G. Bbr, the new kid on the tcp block. Visited on, v. 9, p. 19, 2018.

KUMAR, S.; RAI, S. Survey on transport layer protocols: Tcp & udp. International Journal of Computer Applications, Citeseer, v. 46, n. 7, p. 20–25, 2012.

KUROSE, J.; ROSS, K. Student Resource Java applet web site. 2006. Disponível em: https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations /tcp-congestion/index.html. Acesso em: 04 abr 2019.

KUROSE, J. F.; ROSS, K. W. Computer networking: a top-down approach: international edition. [S.l.]: Pearson Higher Ed, 2013.

PRESSMAN, R.; MAXIM, B. Engenharia de Software-8aEdição. [S.l.]: McGraw Hill Brasil, 2016.

RAHMANI, M.; PETTITI, A.; BIERSACK, E.; STEINBACH, E.; HILLEBRAND, J. A comparative study of network transport protocols for in-vehicle media streaming. In: IEEE. 2008 IEEE International Conference on Multimedia and Expo. [S.l.], 2008. p. 441–444. SINGH, R.; TRIPATHI, P.; SINGH, R. A survey on tcp (transmission control protocol) and udp (user datagram protocol) over aodv routing protocol. International Journal of Research, Citeseer, v. 1, n. 7, p. 26–33, 2014.

STEVENS, W. R. Tcp slow start, congestion avoidance, fast retransmit, and fast recovery algorithms. 1997.

TEIXEIRA, N. P. C.; ARAUJO, A. d. Informática e educação: uma reflexão sobre novas metodologias. Revista Hipertextus, Garanhuns, v. 1, 2007.

Referências

Documentos relacionados

Para analisar as Componentes de Gestão foram utilizadas questões referentes à forma como o visitante considera as condições da ilha no momento da realização do

Os dados referentes aos sentimentos dos acadêmicos de enfermagem durante a realização do banho de leito, a preparação destes para a realização, a atribuição

dois gestores, pelo fato deles serem os mais indicados para avaliarem administrativamente a articulação entre o ensino médio e a educação profissional, bem como a estruturação

A Vector Network Analyser is used to generate the transmitted signal and to collect the received signals, being both in the frequency range of 100 MHz to 3 GHz.. Figure 3.4:

Dessa forma, diante das questões apontadas no segundo capítulo, com os entraves enfrentados pela Gerência de Pós-compra da UFJF, como a falta de aplicação de

Falta número de profissionais, isso atrapalha muito o nosso trabalho, então fica quase tudo a desejar, assistência ao paciente fica prejudicado porque teria que

Para Azevedo (2013), o planejamento dos gastos das entidades públicas é de suma importância para que se obtenha a implantação das políticas públicas, mas apenas

O gráfico nº11 relativo às agências e à escola representa qual a percentagem que as agências tiveram no envio de alunos para a escola Camino Barcelona e ainda, qual a percentagem de