Curso: Engenharia Elétrica

Disciplina: Redes de Computadores

Professor: Flávio Alves Ferreira
e-mail: [email protected]
Aluno: Christian Caldas Neiva

ATIVIDADE PROPOSTA PARA A 12ª SEMANA:

19/10/2021 até 25/10/2021

Atividade: Resumo.

Obs.: Favor salvar o relatório em extensão .pdf.

Elaborar um resumo sobre o Capítulo 3, especificamente da Seção 3.1 até Seção
3.4, do livro: “KUROSE, J. F. e Ross, K. W.: Redes de Computadores e a Internet:
Uma Abordagem Top-Down. 5a edição, Editora: Addison Wesley, São Paulo, 2010”.

3.1 Introdução e serviços de camada de transporte

A camada de transporte é a camada responsável pela transferência de dados entre
duas máquinas, independente da aplicação usada e do tipo, topologia ou
configuração das redes físicas existentes entre elas. A camada de transporte reúne
protocolos de transporte end-to-end entre máquinas, isto é, uma entidade
(hardware/software) que utilize os protocolos desta camada só se comunica com a
sua entidade destino, sem comunicação com máquinas intermediárias na rede,
como pode ocorrer com as camadas inferiores.[1] Dois dos principais protocolos
desta camada são o UDP e o TCP.
A camada de transporte oferece para o nível de aplicação um conjunto de funções e
procedimentos para acesso ao sistema de comunicação de modo a permitir a
criação e a utilização de aplicações de forma independente da implementação da
rede. As interfaces dos sistemas operativos, como socket ou TLI (ambiente Unix) e
Winsock (ambiente Windows) fornecem um conjunto de funções-padrão para
permitir tal acesso.[1]
A camada de transporte fica entre as camadas de nível de aplicação (camadas 5 a
7) e as de nível físico (camadas de 1 a 3). As camadas de 1 a 3 estão preocupadas
com a maneira com que os dados serão transmitidos pela rede. Já as camadas de 5
a 7 estão preocupadas com os dados contidos nos pacotes de dados, enviando ou
entregando para a aplicação responsável por eles. A camada 4, Transporte, faz a
ligação entre esses dois grupos.[1]
A transferência de dados pode ser realizada usando o serviço com conexão como
com o serviço sem conexão (datagrama). Os protocolos desta camada podem ou
não oferecer confiabilidade, garantia de entrega, controle de fluxo, entre outros.[1]
A camada de transporte oferece serviços às camadas superiores, geralmente para a
camada de aplicação, usando os serviços das camadas inferiores. Acessada por um
endereço de transporte, a entidade de transporte é responsável pelo trabalho,
enviando as unidades de transporte/segmentos para a outra camada de transporte
da máquina receptora.
Existem dois tipos de serviços de transporte, orientado a conexões e não orientado
a conexões, ambos os serviços tem muitas semelhanças com os serviços de rede.
A principal diferença entre eles está na área onde atuam. A camada de rede atua
principalmente nos roteadores, já a camada de transporte atua inteiramente nas
máquinas dos usuários.
Como citado anteriormente, os serviços fornecidos pela camada de transporte
podem ser orientados ou não orientados a conexão dependendo do protocolo
utilizado, se o protocolo utilizado for TCP será uma rede orientada a conexão e se
for UDP não será uma rede orientada a conexão. Os principais fatores de cada
protocolo são:
● TCP: É um protocolo confiável pois faz controle de fluxo a fim de evitar
congestionamentos na transmissão dos dados, refaz a transmissão de
datagramas falhos e faz a ordenação dos pacotes que foram transmitidos
desordenadamente ao destino. Ou seja, este protocolo garante que todos
os dados transmitidos cheguem corretamente ao receptor; [2]
● UDP: É um protocolo não confiável pois diferentemente do TCP ele não
faz nenhum tipo de controle, não controla fluxo, não faz o reenvio de
segmentos que falharam na transmissão, também não realiza a
ordenação de pacotes que chegaram ao destino desordenados e não
retorna a confirmação de que os dados foram entregues. Ou seja, o UDP
não garante que os dados serão entregues de forma correta ao destino.

A camada de transporte junto com a camada de rede e de enlace são responsável

por um fator fundamental nas Redes de computadores, o desempenho. Porém
pouco sabemos sobre ele, pois a maior parte das teorias que possuímos ainda não
é aplicável praticamente. Por esses fatores, a análise de desempenho se torna mais
uma arte do que uma ciência.
Redes de computadores possuem interações, e sempre quando há um grande
número de usuários conectados à elas podem ocorrer as chamadas interações
complexas, as principais responsáveis pela depreciação do desempenho. A melhor
forma de se aprender a analisar o desempenho de uma rede, é através da
observação de casos em cenários reais e o conhecimento de alguns fatores que,
empiricamente, sabemos que fazem total diferença
3.2 Multiplexação e demultiplexação
Situada entre as camadas de aplicação e de rede, a camada de transporte provê
uma comunicação processo a processo. Para tal, a camada de transporte utiliza o
conceito de portas, que é, na verdade, um número que identifica qual processo
deverá se encarregar da informação trazida por aquele pacote. Na prática, o
aplicativo informa ao sistema operacional que estará escutando uma determinada
porta e então todos os pacotes daquele protocolo (UDP ou TCP) serão repassados
àquele processo. A Demultiplexação é a entrega dos dados de um segmento da
camada de transporte à porta correta. "O trabalho de reunir, no hospedeiro de
origem, porções de dados provenientes de diferentes portas, encapsular cada
porção de dados com informações do cabeçalho (que mais tarde serão usadas na
demultiplexação) para criar segmentos, e passar esses segmentos para a camada
de rede é denominado multiplexação".
Sabe-se que o serviço de multiplexação e o de demultiplexação é de extrema
importância para todas as redes de computadores. No entanto, aqui será enfatizado
seu uso na camada de transporte.
A camada de transporte, em um hospedeiro de destino, recebe segmentos da
camada de rede que fica abaixo dela (isso acontece, analisando uma abordagem
top-down), a qual tem o dever de entregar todos os dados desses segmentos ao
processo da camada de aplicação, que também roda nesse hospedeiro. Porém, o
que acontece na realidade é que a camada de transporte não entrega os segmentos
a um processo, mas sim em um socket (porta) intermediário. Onde cada socket tem
um identificador exclusivo, que depende de o Socket ser TCP ou UDP.
O direcionamento a uma porta correta de um segmento, é feito a partir da análise de
um conjunto de campos que se localiza no segmento. Nesse campo encontra-se a
porta destinatária, a qual o segmento será direcionado pela camada de transporte.
Esse direcionamento a porta correta é denominado de demultiplexação.
Define-se multiplexação como sendo a tarefa de reunir pedaços de dados, vindos de
diferentes portas (no hospedeiro de origem), encapsulando esses pedaços com o
conjunto de campos para criar segmentos e entregá-los a camada de rede. A
transferência de dados pode ser feita por: UDP (não orientada para conexão) ou
TCP (orientada para conexão). Caso seja feita por UDP, o socket UDP é identificado
por uma tupla com dois elementos: endereços IP de destino e um número de porta
de destino; por outro lado seja feita por TCP, o Socket TCP é identificado por uma
tupla com quatro elementos: endereço IP de origem, número da porta de origem,
endereço IP de destino e número da porta de destino.

3.3 Transporte não orientado para conexão: UDP

O UDP é um protocolo usado para o transporte rápido de dados entre hosts TCP/IP.
Porém o UDP não fornece garantia de entrega e nem verificação de dados. De uma
maneira simples, podemos dizer que o protocolo UDP manda os dados para o
destino sem a necessidade de apresentação entre as unidades remetentes e
destinatária antes de enviar o segmento, porem se vai chegar, e sem erros, é
impossível saber (o UDP fornece verificação de erro porém nada faz para corrigir o
erro, apenas informa a aplicação que determinado pacote é corrupto). O UDP não
garante a entrega ou verifica o seqüenciamento para qualquer pacote. Uma outra
solução bastante utilizada ultimamente é a inserção da confiabilidade na própria
aplicação (adicionando mecanismos de reconhecimento e de transmissão
embutidos na aplicação) permitindo assim que ela tire proveito de ambas as
alternativas, ou seja, os processos de aplicação se comunicam de maneira confiável
sem ter que se sujeitar as limitações da taxa de transmissão impostas pelo
mecanismo de controle de congestionamento impostas pelo TCP.
Alguns dos principais motivos pelo qual o UDP pode ser preferível são:
● Melhor controle no nível de aplicação sobre quais dados são enviados e
quando: como ele não possui controle de congestionamento (como ocorre
no TCP), não ocorre atraso no envio do pacote. Não possui o serviço de
confirmação de recebimento que pode atrasar a transmissão se alguns
pacotes forem perdidos, e é compatível com aplicações de tempo real
onde a velocidade é mais importante que a confiabilidade na entrega.
● Não há estabelecimento de conexão: O UDP apenas envia os dados sem
perder tempo tentando abrir conexões (como ocorre no TCP) esse é um
dos motivos pelo qual DNS roda sobre UDP.
● Não há estados de conexão: Usado pelo TCP para garantir a entrega
confiável de dados (esses estados inclui buffers de envio e recebimento,
parâmetros de controle de congestionamento e etc), por isso um servidor
com uma aplicação especifica pode suportar um numero muito maior de
clientes ativos quando a aplicação roda sobre UDP ao invés de TCP.
● Pequena Sobrecarga de Cabeçalho de Pacote: O TCP possui 20 bytes de
sobrecarga de cabeçalho enquanto o UDP so possui 8 bytes.
Algumas das aplicações mais importantes que utilizam o UDP são:
● Atualização de tabelas de roteamento com protocolo RIP.
● Transferir dados de gerenciamento de rede, que normalmente funcionam
quando a rede esta sobrecarregada e é difícil conseguir transferência
confiável devido ao controle de congestionamento.
● O DNS também roda sobre o UDP.
● É bastante utilizado em aplicações multimídia como telefone por internet,
vídeo conferência em tempo real e recepção de áudio e vídeo
armazenados.

3.4 Princípios da transferência confiável de dados

Dentre todos os problemas que existem para a implementação de redes de
computadores, podemos dizer que a transferência confiável de dados é um dos
principais. Essa tarefa ainda é mais complexa, pois a implementação do Protocolo
de transferência confiável de dados é feita em um canal confiável, porém possui a
camada de rede logo abaixo: um canal não confiável. Por exemplo: o TCP é um
protocolo de transferência de dados confiável implementado sobre uma camada de
rede fim-a-fim não confiável (IP).
O protocolo de transferência confiável de dados é implementado na camada de
transporte. rdt é a sigla para Reliable Data Transfer que significa transferência
confiável de dados. Passa dados para entregar à camada superior receptora.
udt_send()é chamada pela entidade de transporte, para transferir pacotes para o
receptor através do canal não confiável. rdt_rcv()é chamada pela entidade da
camada inferior quando o pacote chega ao lado receptor do canal e deliver_data()é
chamada pela entidade de transporte para entregar dados para camada superior.
Consideraremos apenas o caso de transferência unidirecional de dados, ou seja, do
lado do remetente para o lado do destinatário. Os diagramas utilizados para a
exemplificação dos protocolos utilizam máquinas de estados finitos (FSM) para
especificar o protocolo transmissor e o receptor. É definido que estado é quando
neste “estado” o próximo estado fica unicamente determinado pelo próximo evento.

rdt1.0: Transferência confiável de dados sobre canais perfeitamente confiáveis

Primeiro é considerado um caso mais simples, na qual nao há erro de bits na
transmissão e também não há perdas de pacotes. As FSMs são separadas para
transmissor e receptor na qual transmissor envia dados para o canal subjacente
receptor lê os dados do canal subjacente. Como não a erro de bits ou perdas de
pacotes o papel do remetente é simplesmente aguardar o pedido de envio da
camada superior e enviar o pacote, voltando ao seu estado de espera de nova
solicitação. O lado do destinatário fica em estado de espera de chegada de pacotes
da camada inferior, recebe os dados, extrai e os envia para a camada superior.

rdt2.0: Canal com erros de bit

Já o rdt2.0 prevê envio de dados que podem chegar com erros ou corrompidos.
Para solucionar tal problema, é implementado o conceito de resposta pelo
destinatário ao remetente. Dessa forma o protocolo usa como resposta
reconhecimento positivo (ACK) e reconhecimento negativo (NAK). Nos
reconhecimentos (ACKs)o destinatário avisa explicitamente ao remetente que o
pacote foi recebido corretamente e nos reconhecimentos negativos (NAKs)o
destinatário avisa explicitamente ao remetente que o pacote tem erros. Quando o
remetente recebe um NAK ele faz o reenvio do pacote.

rdt2.1: Solução para ACKs/NAKs perdidos

O rdt2.1 é uma versão que soluciona um problema que pode acontecer no rdt2.0 e
na qual este nao soluciona. Trata-se do sequenciamento dos pacotes e dos
reconhecimentos positivos e negativos emitidos pelo destinatário. Dessa forma é
evitado a transferência desnecessária de arquivos (duplicidade) e confusões em
determinar para qual pacote foi enviado o reconhecimento.

rdt2.2: Uso somente de ACKs

O rdt2.2 possui a mesma funcionalidade do rdt2.1, porém usando somente ACKs.
Ao invés de enviar NAK, o destinatário envia um ACK para o último pacote recebido
sem erro incluindo explicitamente o número de seqüência do pacote sendo
reconhecido. O recebimento de ACKs duplicados no remetente resulta na mesma
ação do NAK, ou seja, a retransmissão do pacote corrente. Dessa forma nota-se
uma maior simplicidade no FSM com relação ao rdt2.1

Protocolo rdt3.0
O que vimos até agora foi:
● Rdt1.0: um protocolo sobre um canal perfeitamente confiável;
● Rdt2.2: um protocolo mais real, onde há erro de bits.
Porém, há uma outra situação que normalmente ocorre em uma transferência de
arquivos e que precisa ser tratada: a perda de pacotes. Implementaremos então um
mecanismo para detectar um pacote perdido e retransmiti-lo. Tal mecanismo
consiste da utilização de um temporizador de contagem regressiva que será
acionado ao enviar cada pacote do remetente ao destinatário.
Uma ilustração do mecanismo apresentado é a seguinte:
● um pacote pkt0 é enviado ao destinatário, e o temporizador relativo a esse
pacote é acionado.
● pkt0 chega ao destinatário e este envia o ACK0.
● se ACK0 chegar ao remetente, o temporizador de pkt0 é parado e será
enviado o pkt1. Porém, caso o temporizador chegue a 0 antes do ACK0
ser recebido, pkt0 é reenviado, e os passos anteriores são novamente
repetidos.

Utilizando o temporizador, nem o remetente nem o destinatário conseguem

identificar o que houve com o pacote enviado. Ele pode ter sido perdido, a resposta
ACK pode ter sido perdida, ou simplesmente houve lentidão na rede, o que fez com
que o temporizador zerasse antes do recebimento do pacote ou do ACK. A última
situação resulta em pacotes duplicados, porém o protocolo rdt2.2 já corrige tal
problema.

Transferência confiável de dados utilizando paralelismo

Com a utilização do protocolo rdt3.0 já são corrigidos os principais problemas que
ocorrem em uma transferência de dados. Resta-nos agora melhorarmos seu
desempenho.
Por ser do tipo pare-e-espere o protocolo rdt3.0 envia apenas um pacote por vez, e
só envia o próximo quando receber a confirmação de recebimento do mesmo.
Introduziremos então o conceito de paralelismo. Serão enviados vários pacotes
sequencialmente(apesar do nome indicar, os pacotes não são enviados ao mesmo
tempo), mesmo sem a recepção dos pacotes anteriores. Isso implica em maiores
números de seqüência e na utilização de buffers do lado remetente, e também do
lado destinatário no caso da repetição seletiva, para mais de um pacote.
Serão apresentados dois protocolos que utilizam a idéia de paralelismo,Go-Back-N
e Repetição Seletiva.

Protocolo Go-Back-N
Para solucionar os problemas causados pelo comportamento pare e espere dos
protocolos anteriores, foi desenvolvido o protocolo Go-Back-N. Este permite o envio
de um determinado número de pacotes sem que os anteriores tenham sido
reconhecidos

É definido um número de pacotes que podem ser enviados sem que seja necessário
aguardar pelo reconhecimento de cada um deles. Esta quantidade de pacotes pode
ser vista como uma "janela". Os pacotes azuis são pacotes que já foram enviados,
mas ainda não foram reconhecidos, e os pacotes verdes são os próximos pacotes a
serem enviados, já que ainda estão dentro dos limites da janela. Os pacotes
vermelhos estão fora do limite da janela, logo não podem ser enviados ainda.
Nextseqnum é o número de sequência do próximo pacote a ser enviado. O pacote
base é o pacote não reconhecido com número de sequência mais antigo. Quando
este pacote for reconhecido, a janela irá se deslocar para a direita no espaço de
números de sequência dos pacotes, permitindo o envio de outros pacotes. A janela
"desliza", e com isso o protocolo Go-Back-N é também denominado protocolo de
janela deslizante.
O lado remetente deve ser capaz de responder a 3 situações:
● Dados recebidos da camada de cima
Antes de criar e enviar um pacote, o protocolo deve verificar se há espaço na janela.
Se não houver, os dados serão devolvidos, podendo ser enviados apenas quando
um espaço for liberado;
● Recebimento de um ACK
Receber um ACK com número de sequência n indica ao remetente que todos os
pacotes com número de sequência até n (inclusive) foram recebidos corretamente
pelo destinatário, e assim a janela desliza. O pacote com número de sequência n+1
se torna a base;
● Esgotamento de temporização
É usado um temporizador para o pacote base. Se um ACK chegar antes do
temporizador se esgotar, ele é reiniciado para o pacote seguinte. Se ele se esgotar,
todos os pacotes que foram enviados mas que ainda não foram reconhecidos são
reenviados.
O lado destinatário, ao receber um pacote com número de sequência n, que está na
ordem esperada, envia um ACK correspondente e entrega os dados à camada
superior. Caso o pacote recebido não esteja na ordem, ele será descartado e será
reenviado um ACK para o último pacote recebido corretamente.
Esta característica garante que os pacotes sejam recebidos em ordem, mas
descarta pacotes recebidos corretamente. Se por um lado isto gera um prejuízo na
necessidade de retransmissão de dados (que ainda podem ser perdidos, gerando
mais retransmissões), existe uma vantagem importante nesta opção: a simplicidade
nos buffers do destinatário. Não será preciso armazenar pacotes fora de ordem,
mas apenas o número de sequência esperado para o próximo pacote.

Repetição Seletiva
O protocolo o Go-Back-N ou GBN resolveu um problema de vital importância para a
transferência de dados, que é a questão do aproveitamento e da utilização do canal.
Com o GBN há envio de mais de um pacote sem a obrigatoriedade de confirmação
de recebimento do pacote anterior, ou seja, ele enche o canal com pacotes, N
pacotes (um numero finito), tendo assim um melhor aproveitamento do canal, da
largura de faixa do canal. Porém a forma como foi feito o GBN existem ainda
algumas questões que prejudicam a transferência eficiente de dados. Estas
questões são: o tamanho da janela grande e/ou o produto entre atraso e largura de
faixa também grande. Pensemos sobre a janela, que é o mesmo conceito de janela
do GBN. Vamos supor uma janela de tamanho para 100 pacotes. Se houver
qualquer erro, pode ser perda do pacote enviado ou perda do ACK enviado pelo
destinatário, terá que ser reenviado o pacote. O problema surge do fato que todos
os pacotes posteriores ao que foi perdido terão de ser também reenviados. Se
houver erro no 10º pacote, todos os 90 restantes juntamente com o 10º terão de ser
reenviados, ou seja, haverá muitos reenvios desnecessários, tendo desta forma
uma utilização também ineficiente, apesar de já ter melhorado. Imagine agora uma
janela com 1000 pacotes! Quanto maior a janela, mais o problema se agrava. Se,
também, o canal contiver uma taxa de erros alta, implica em maiores repetições.
Como sabemos, os canais reais não transmitem sem erros. Por mais que o canal
seja confiável e com baixa taxa de erros, esses erros existirão!