CamadadeTransporte

Prévia do material em texto

Redes de Computadores
UNIDADE III - Camada de Transporte
Romualdo Monteiro de Resende Costa
romualdomrc@gmail.com
Camada de Transporte
• Serviços e princípios da camada de transporte
• Multiplexação e demultiplexação de aplicações
• Transporte não orientado à conexão: UDP
• Princípio da transferência confiável de dados
• Transporte orientado à conexão: TCP
• Controle de Congestionamento
Bibliografia:
KUROSE, James F. & ROSS, Keith W. Redes de
computadores e a Internet: uma abordagem top-
down. 3 ed. São Paulo: Addison Wesley, 2006.
Camada de Transporte
Recordando...
Pilha de Protocolos
Camada de Transporte
• A camada de rede não garante que um pacote chegue 
ao seu destino
– Pacotes podem ser perdidos ou ainda chegar fora da 
sequência original da transmissão
• Para fornecer uma comunicação confiável é necessário 
uma outra camada de abstração, que é a camada de 
transporte
– Comunicação fim-a-fim, a implementação é realizada nos 
clientes finais
– Na camada de rede a implementação é realizada nos 
computadores intermediários
Inter-rede
Arquitetura TCP/IP
Arquitetura TCP/IP
• O protocolo da camada de rede (inter-rede) é o 
Internet Protocol (IP)
– Comunicação computador-computador na inter-rede
• Modelo de serviço do tipo “melhor esforço”
– Não oferece nenhuma garantia da entrega dos pacotes, nem 
que eles sejam entregues em ordem, nem mesmo a 
integridade dos pacotes recebidos
• Dois protocolos na camada de transporte
– User Datagram Protocol – UDP
– Transmission Control Protocol - TCP
Camada de Transporte
• UDP:
– Serviço sem conexão 
– Transferência não confiável utilizando o IP
– Verificação da integridade dos dados
– Multiplexação de conexões em várias portas
• TCP
– Serviço com conexão, confiável (transferência garantida)
– Além da integridade e da multiplexação de conexões oferece 
também o controle do fluxo na rede.
Tipos de Aplicações
Fornecedores e Usuários de Serviços
• Um serviço representa um conjunto de funções 
oferecidas a um usuário por um provedor (fornecedor)
• O serviço oferecido por um provedor é acessado por 
um usuário através de um ponto de acesso ao serviço 
(Service Access Point SAP)
• O usuário é a camada N e o provedor a camada N-1
Fornecedores e Usuários de Serviços
Socket
• Na Arquitetura Internet, um socket é a interface entre 
a camada de aplicação e de transporte
– Porta (especificação do processo receptor)
– Protocolo de Transporte
– Parâmetros do transporte (buffer, segmentos etc.)
• Transferência de mensagens fim-a-fim (porta-a-porta) 
e entrega aos processos das aplicações
– API de Transporte
Socket
• Duas API’s mais conhecidas para Unix
– Berkeley Sockets
– TLI (System Transport Layer Interface)
– Estendidas para outros sistemas operacionais, como o Win 
Socket
• Interfaces desenvolvidas para C.
– Atualmente com interfaces de acesso em outras linguagens
– Vários exemplos Java no livro texto
Socket
Multiplexação e Demultiplexação
• Operações sempre presentes quando um protocolo de 
uma camada pode ser usado por vários processos em 
uma camada superior
– Compartilhamento do recurso (canal) 
• Demultiplexação
– Entrega dos dados contidos em um segmento da camada de 
transporte à porta correspondente
• Multiplexação
– Reunião de dados de diferentes portas, encapsulados em 
segmentos enviados através da camada de rede
Multiplexação e Demultiplexação
Quadro UDP
CheckSum
• Transmissor:
– Todas as palavras do segmento são somadas em partes de 16 
bits
– Inverte-se todos os bits dessa soma e esse é o valor do 
checksum
Receptor:
– Todas as palavras do segmento recebido são somadas em 
partes de 16 bits, incluindo o checksum
– O valor final deve ser constituído apenas por bits 1, caso 
contrário houve algum erro na transmissão
Portas
• Os números das portas variam de 0 a 65535, sendo 
que até a porta 1023 os números são reservados para 
aplicações específicas, como:
– HTTP: porta 80
– SMTP: porta 25
– SNMP: porta 161 e 162
– TELNET: porta 23
– SSH: porta 22
– FTP: porta 21
– ... 
Exemplo
• Clientes podem designar qualquer porta, ao contrário, 
as portas nos servidores normalmente devem ser bem 
conhecidas 
• DatagramSocket mySocket = new DatagramSocket();
– Instancia um socket com um número qualquer de porta entre 
1024 e 65535, que não esteja sendo usada no momento, para 
o protocolo UDP
• DatagramSocket mySocket = new 
DatagramSocket(19157);
– Instancia um socket com o número de porta específico 19157
Serviços orientados à conexão
• Dois processos devem negociar uma abertura de 
conexão:
– Conexão full-duplex (em ambos os sentidos e simultânea)
– Detecção e correção de erros fim-a-fim
– Conexão ponto-a-ponto
– TCP - Controle de fluxo (janela deslizante)
• Não são recebidos segmentos de outras conexões ou 
que não solicitaram conexão
Portas TCP
• Cada um dos processos da aplicação que o TCP está 
atendendo em um determinado momento é 
identificado por uma porta diferente
• Para obter um endereço que identifique univocamente 
um usuário TCP, o identificador da porta é 
concatenado ao endereço IP onde a entidade TCP está 
sendo executada, definindo um socket.
• Um socket identifica univocamente um usuário TCP em 
toda a inter-rede
TCP
TCP
• Cabeçalho de 20 bytes (12 a mais do que o UDP) + 
parte opcional
– 4 bytes para as portas de origem e destino (2 cada)
– 4 bytes para o número de sequência transmitido
– 4 bytes que especifica o byte aguardado (próximo)
– 4 bits para informar quantas palavras de 32 bits existem 
(Campo options é opcional)
– 6 bits reservados para uso posterior
– 6 bits para identificar a finalidade do segmento
– 16 bits para informar o tamanho da janela do receptor
– 16 bits para indicar a posição no segmento onde dados 
urgentes terminam
– Recursos extras com tamanho variável (Options)
Transferência Confiável
• Técnica conhecida como confirmação positiva:
– Utiliza os campos SEQUENCE e ACKNOWLEDGEMENT NUMBER
• Conteúdos das aplicações são transportados por 
segmentos
– Números de sequência indicam a quantidade de bytes que o 
TCP está transmitindo
– Por exemplo, se for transmitido um conteúdo de 1000 bytes e 
se cada segmento tiver 100 bytes, serão transmitidos 10 
segmentos, o primeiro com número de sequência zero, o 
segundo com 100, e assim, sucessivamente
• O campo de reconhecimento informa ao transmissor 
que todos os bytes anteriores foram corretamente 
recebidos 
Transferência Confiável
TCP – Informação do Transmissor
TCP – Informação do Receptor
Controle de Fluxo
• Se, após a transmissão de um segmento, uma estação 
permanecesse esperando a sua confirmação, o 
protocolo seria muito ineficiente
– Desperdício da banda disponível - > Baixa Vazão
• Por outro lado, é necessário conhecer quantos 
segmentos podem ser enviados sem sobrecarregar a 
estação destino
– Estouro do buffer de destino -> Retransmissão
• O transmissor precisa recebe o número de bytes que o 
receptor é capaz de processar
– Pode ser definida em escala - > Redes de Alta Velocidade 
(RAVEL)
Janelas Deslizantes
• Janela Deslizante (sliding-window protocol)
– A cada confirmação recebida, a janela posiciona o seu início 
após o último byte confirmado
• O tamanho da janela pode variar conforme os 
segmentos são enviados, armazenados e processados
• Envio do tamanho da janela
– Transmissor pode enviar periodicamente segmentos para 
testar o tamanho da janela (window probes)
Janelas Deslizantes
Controle de Fluxo
Controle de Fluxo (cont)
Controle de Fluxo
• Janela pode ficar nula em alguns momentos
• Silly Window Syndrome
– Receptor está com o buffer preenchido (janela nula)
– Informa pequenas alterações na janela
– Poucos segmentos são transmitidos e a janela volta a ser nula
– Consumo desnecessário de banda e de processamento
• Solução: limitar a transmissão a um tamanho mínimo 
– Transmissor
– Receptor
Silly Window Syndrome
• Transmissor: Algoritmo de Nagle
– Quando uma aplicação gera novos dados em uma conexãona 
qual dados anteriores foram transmitidos mas não 
reconhecidos, os novos dados são bufferizados, sendo 
transmitidos quando:
– For possível completar um segmento de tamanho máximo, ou
– Os dados anteriores forem reconhecidos
• Problema: transmissão de dados em tempo real
Silly Window Syndrome
• Receptor:
– Só enviar uma atualização da janela informando que Window 
> 0, posteriormente a uma atualização de janela informando 
Window = 0, quando o buffer de recepção estiver com espaço 
livre igual a:
– Pelo menos 50% do buffer, ou
– Com espaço correspondente a um segmento de tamanho 
máximo
Retransmissão
• Um temporizador associado aos segmentos 
transmitidos evita que o transmissor espere uma 
confirmação indefinidamente
– Qual deve ser o intervalo de espera?
• Intervalo pequeno -> retransmissões desnecessárias
– Sobrecarga na rede
– Perda de pacotes
• Intervalo grande -> demora na retransmissão de 
pacotes perdidos
– Desperdício da banda
– Baixa vazão
Algoritmo Adaptativo
• RTT: round-trip time
– Estimativa do tempo gasto para o segmento chegar ao destino 
adicionado do tempo de volta da confirmação para o 
transmissor
• Exemplo de fórmula para o cálculo do RTT
– RTT = a * OLD_RTT + (1-a) * NEW_RTT_SAMPLE
– RTT inicial é igual a 0
– OLD_RTT 
– NEW_RTT_SAMPLE é obtido para cada “nova janela”
– a = 0,125 (RFC 2988 – TCP Retransmission Timer)
Timeout
• Definido o RTT, deve-se escolher um timeout 
adequado e relacionado ao RTT
– Timeout = b * RTT
– Kurouse (RTT + 4 * Desvio RTT) 
– b pode ser estático (b = 2) ou definido por um outro algoritmo
• Algoritmo de Jacobson (melhor resposta a altas 
variações do RTT)
– b = variância de RTT
– Uma grande variação do RTT significa um valor alto para b e 
vice-versa 
Timeout (Outras considerações)
• Necessidade de alguns valores padronizados:
– Timeout inicial = 3 segundos
– Timeout máximo = 240 segundos
• Ao retransmitirmos segmentos, as confirmações 
recebidas não permitem concluir se elas são relativas à 
primeira transmissão ou às retransmissões
– Decisões erradas podem comprometer o valor do RTT
– Algoritmo de Karn: não realiza atualizações no RTT em 
qualquer segmento confirmado que tenha sido retransmitido
– O temporizador tem seu valor dobrado a cada falha até que 
segmentos sejam recebidos sem a necessidade de 
retransmissões
Cálculo do Timeout
SEQ=400
Algoritmo de Karn
Conexão
• O algoritmo de three-way handshake é utilizado na 
abertura de conexões
– É o momento de ajustar a conexão fim-a-fim (tamanho 
máximo dos segmentos, números de sequência etc.)
• Uma conexão é estabelecida através do envio de três 
segmentos:
– A estação origem envia um segmento com o campo SYN 
ativado (code bits)
– Se a conexão for aceita a estação destino envia um segmento 
com os campos SYN e ACK ativados
– A estação origem, como resposta, envia um segmento com o 
campo ACK ativado. 
Code Bits
• URG = indica que o campo Urgent Pointer é válido.
• ACK = indica que o campo Acknowledgement Number
é válido.
• PSH = indica que o receptor deve entregar os dados 
imediatamente para a aplicação, sem esperar 
completar o buffer.
• RST = reinicia ou rejeita uma conexão.
• SYN = solicita o início de uma conexão.
• FIN = utilizado para finalizar uma conexão.
Code Bits
TCP
• Uma vez estabelecida, a conexão é full-duplex
– Ambas as estações podem transmitir simultaneamente 
enquanto a conexão estiver ativa
Caso trivial da Conexão
• SEQ carrega o número de sequência inicial que cada 
módulo TCP vai utilizar para sequenciar segmentos 
TCP
Encerramento da Conexão
• Conexões full-duplex: fluxos são encerrados de modo 
independente
– Na prática o encerramento dos fluxos costuma ocorrer 
consecutivamente
Processamento Urgente
• Dados urgentes são, em geral, informações de controle 
transmitidas junto com os dados propriamente ditos
Opções
Opções TCP Principais
Controle do Congestionamento
• O controle de fluxo do TCP é fim-a-fim, mas podem 
ocorrer congestionamentos em qualquer roteador
– Janela Deslizante não garante o controle do congestionamento
• Colapso de Congestionamento:
– Roteadores na iminência de congestionamento
– Aumento do RTT
– Retransmissões devido a reconhecimentos atrasados
– Aumento da carga dos roteadores congestionados
– Descarte de pacotes nos roteadores congestionados
• Mensagens (dados e ACKs)
Controle do Congestionamento
• Solução simples:
– TCP assume que as perdas se devem, normalmente, a 
congestionamentos
• É associado ao transmissor uma janela de 
congestionamento, que limita a transmissão de 
segmentos
– Janela de congestionamento inicial: 1 segmento
– Vazão da conexão cresce com o aumento da janela de 
congestionamento que, me condições normais mantém o seu 
tamanho igual à janela de recepção
• Em caso de retransmissão, a janela de 
congestionamento é reduzida ao tamanho inicial
E a vazão?
• Algoritmo de Slow Start
– Para cada reconhecimento recebido (de um segmento não 
retransmitido), a janela de congestionamento é aumentada de 
um segmento (de tamanho máximo)
• Crescimento exponencial da janela de 
congestionamento
– Condições “ideais”
– Sobrecarga na rede pode reiniciar o congestionamento
– A redução da janela de congestionamento limita novamente a 
vazão da rede
– Quando a frequência dessa ocorrência diminui a vazão de uma 
conexão aumenta e vice-versa
Congestion Avoidance
• O crescimento exponencial do Slow Start aumenta a 
probalidade de perda de mensagens e diminuição da 
vazão
• Solução
– Quando a janela de congestionamento atinge metade de seu 
tamanho anterior à última retransmissão, o seu crescimento 
passa a ser linear
Slow Start + Congestion Avoidance
Decréscimo Multiplicativo
• O algoritmo de Slow Start reduz drasticamente a vazão 
de uma conexão TCP
• Solução: técnica de decréscimo multiplicativo
– Em caso de retransmissão, a janela de congestionamento é 
reduzida pela metade, até o mínimo de um segmento de 
tamanho máximo
• Importante
– O congestion avoidance deve ser utilizado quando o 
decréscimo multiplicativo é escolhido. 
Slow Start + Decréscimo Multiplicativo
Go-Back-N
• O TCP pode transmitir múltiplos segmentos sem 
esperar receber a confirmação
– A transmissão fica limitada ao tamanho da janela de 
transmissão ou de congestionamento
• Por outro lado, no receptor, todos os segmentos 
devem ser recebidos para que seja enviada uma 
confirmação
– Se um segmento anterior for perdida mas os posteriores forem 
recebidos, o transmissor vai precisar enviar novamente todos 
os segmentos a partir daquele que foi perdido
Fast Retransmit
• Segmentos fora de ordem não são permitidos
– Ao receber um segmento fora de ordem, o receptor deveria 
informar imediatamente ao transmissor, agilizando a 
retransmissão
– Isso pode ser feito através da emissão de uma confirmação 
duplicada ao transmissor
• Fast retransmit
– O recebimento de uma confirmação duplicada (dupacks) 
provoca o imediato reenvio dos segmentos sem esperar que o 
timeout seja alcançado
Fast Retransmit
• Normalmente empregado quando três confirmações 
duplicadas são recebidas (total de quatro 
confirmações)
– Assume que o segmento foi perdido
– Existência de congestionamento
– Diminuição da janela de congestionamento (metade do seu 
tamanho)
– Retransmissão do segmento considerado perdido
– A janela volta a crescer, normalmente conforme o slow start e 
o congestion avoidance 
Fast Recovery
• Diminuir o tamanho da janela no Fast Retransmit pode 
não ser uma boa estratégia.
– Heurística: se segmentos não esperados foram recebidos, a 
perda pode ter ocorrido por fatores diversos e pontuais
– Assim, ao contrário de reduzir o tamanho da janela, poderia 
ser necessário aumentar o seu tamanho para compensar as 
falhas ocorridas (inflar a janela)
• Utiliza o Fast Recovery para confirmações duplicadas e 
o Fast Retransmit para mais de duas confirmações 
duplicadas
• TCP Reno e TCP new Reno
Go-Back-N
• Problemas
– Descarte dos segmentos recebidosmas não esperadas pelo 
receptor
– Diversas retransmissões de segmentos que eram considerados 
perdidos pelo transmissor mas que na verdade foram 
recebidos
• Solução: Selective repeat
– Sem restrições sobre a ordem na qual os segmentos são 
recebidos
– Recebimento fora de ordem dentro do limite do receptor
Selective Repeat
• O receptor deve informar quais segmentos estão 
faltando
– Os campos do cabeçalho do TCP não possuem um campo com 
essa finalidade
– O Acknowledgement number informa a próximo segmento 
esperado
• Selective Acknowledgement – SACK
– Campo SACK-permitted: informado na solicitação da conexão. 
Informa que o selective repeat será utilizado nesta conexão (2 
bytes).
– Campo SACK: informa ao receptor quais segmentos foram 
recebidos (tamanho variável)