Post on 18-Apr-2015
3: Nível de Transporte 3a-1
Direita ou esquerda ???
3: Nível de Transporte 3a-2
Capítulo 3: Nível de transporteObjectivos do
capítulo: Entender os princípios
subjacentes ao serviço de nível de transporte: Multiplexagem/
desmultiplexagem Transferência de
dados fiável Controlo de fluxo Controlo de congestão
Instanciação e implementação na Internet
Sumário do capítulo: Serviços de nível de transporte Multiplexagem/
Desmultiplexagem Transporte sem ligação: UDP Princípios da transmissão fiável Transporte orientado à ligação:
TCP Transferência fiável Controlo de fluxo Gestão de ligação
Princípios de controlo de congestão
Controlo de congestão em TCP
3: Nível de Transporte 3a-3
Serviços de Transporte e Protocolos
Ex: cartas entre “primos” amarelos e azuis !!!
Sistemas Terminais = casas
Processos = “primos”
Mensagens de aplicação = cartas nos envelopes
Protocolo de transporte = amarelo e azul
Protocolo de rede = serviço postal
Sistemas Terminais ? Processos ? Mensagens de aplicação ? Protocolo de transporte ? Protocolo de rede ?
3: Nível de Transporte 3a-4
Serviços de Transporte e Protocolos
Fornece comunicação lógica entre processos de aplicação a funcionar em Sistemas Terminais diferentes
Os Protocolos de Transporte são executados nos Sistemas Terminais
Serviços de Transporte vs. Serviços de Rede:
Nível de Rede: Transferência de dados entre Sistemas Terminais
Nível de Transporte: Transferência de dados entre processos Confia e melhora, os
serviços do Nível de Rede
AplicaçãoTransporte
RedeLig. Lógica
Físico
AplicaçãoTransporte
RedeLig. Lógica
Físico
RedeLig.
LógicaFísico
RedeLig.
LógicaFísico
RedeLig.
LógicaFísico
RedeLig.
LógicaFísicoRede
Lig. LógicaFísico
Transporte lógico extremo-a-extrem
o
3: Nível de Transporte 3a-5
Protocolos de Nível de Transporte
Serviços de Transporte Internet:
fiável, entrega ordenada uni-cast (TCP) congestão
Controlo de fluxo
Estabelecimento da ligação
Não fiável (“best-effort”), entrega não ordenada uni-cast ou multi-cast: UDP
Serviços não disponíveis: Tempo real
Garantias de largura de banda
Multicast fiável
AplicaçãoTransporte
RedeLig. Lógica
Físico
AplicaçãoTransporte
RedeLig. Lógica
Físico
RedeLig.
LógicaFísico
RedeLig.
LógicaFísico
RedeLig.
LógicaFísico
RedeLig.
LógicaFísicoRede
Lig. LógicaFísico
Transporte lógico extremo-a-extrem
o
3: Nível de Transporte 3a-6
AplicaçãoTransporte
Rede
MP2
AplicaçãoTransporte
Rede
Multiplexagem/Desmultiplexagem
Relembrar: segmento – unidade de dados transferido entre entidades de nível de transporte
aka TPDU: Unidade de Dados do Protocolo de Transporte (transport protocol data unit) Receptor
HtHn
Desmultiplexagem: entrega dos segmentos recebidos para o processo de aplicação correcto
segment
segmento MAplicação
TransporteRede
P1M
M MP3 P4
Cabeçalho do segmento
Dados do nível de aplicação
3: Nível de Transporte 3a-7
multiplexagem/desmultiplexagem: Baseado no emissor/receptor: nº
do porto, endereço IP Nº do porto de origem/
destino para cada segmento Relembrar: nº dos portos é
bem conhecido para aplicações específicas
Recolher dados de diferentes processos de aplicação, delimitar dados com cabeçalho (mais tarde usado para desmultiplexar)
Dados da aplicação(messagem)
Outros campos do
cabeçalho
Formato do segmento TCP/UDP
Multiplexagem:
Multiplexagem/Desmultiplexagem
# porto origem# porto destino
32 bits
3: Nível de Transporte 3a-8
Multiplexagem/desmultiplexagem: exemplos
SistemaTerminal A Servidor B
source port: xdest. port: 23
source port:23dest. port: x
Utilização do porto: simples aplicação de telnet !
Cliente WebSistema Terminal A
Webserver B
Cliente Web Sistema Terminal C
Source IP: CDest IP: B
source port: x
dest. port: 80
Source IP: CDest IP: B
source port: y
dest. port: 80
Utilização do porto: Servidor Web
Source IP: ADest IP: B
source port: x
dest. port: 80
3: Nível de Transporte 3a-9
UDP: User Datagram Protocol [RFC 768]
Protocolo de transporte da Internet
Serviço “best effort” Segmentos UDP podem
ser: perdidos Entregues fora de
ordem à aplicação Sem ligação
Sem handshaking entre o emissor e o receptor UDP
Cada segmento UDP é processado independentemente dos demais
Porquê UDP ? Sem estabelecimento de
ligação (que adiciona atraso)
simples: não há estado da ligação no emissor, receptor
Cabeçalho pequeno do segmento
Não há controlo de congestão: UDP pode estoirar tão depressa quanto se queira !!
3: Nível de Transporte 3a-10
UDP: mais
Usualmente utilizado para aplicações de streaming (multimédia) Tolerante a perdas Sensível ao ritmo
Outras utilizações do UDP (Porquê ?): DNS SNMP
Transferência fiável sobre UDP: adiciona a fiabilidade ao nível da aplicação Recuperação de erros
específica da aplicação!
source port # dest port #
32 bits
Dados da aplicação(message)
Formato do segmento UDP
length checksumDimensão, em
bytes do segmento UDP,
incluindoCabeçalho
3: Nível de Transporte 3a-11
checksum UDP
Emissor: Trata o conteúdo do
segmento como uma sequência de inteiros de 16 bits
checksum: adiciona ao conteúdo do segmento (complemento para 1 da soma)
Emissor coloca o valor do checksum no campo de checksum do segmento UDP
Receptor: Calcula o checksum dos
segmentos recebidos Verifica se o checksum
calculado é igual ao do campo de checksum NÃO – erro detectado SIM – não houve erro
detectado Mas podem haver erros ?
Mais tarde …..
Objectivo: detectar “erros” (e.g., bits trocados) no segmento transmitido
3: Nível de Transporte 3a-12
Princípios da transmissão fiável Importante nas aplicações, transporte, ligação lógica Faz parte da lista top-10 de assuntos de rede!
As características do canal não fiável determinam a complexidade do protocolo de transferência de dados fiável.
3: Nível de Transporte 3a-13
Transferência de dados fiável: início
Lado doEmissor
Lado doReceptor
rdt_send(): chamado do nível de cima, (e.g., aplicação.). Envia
dados para entrega no nível superior do receptor
udt_send(): chamado por rdt, para transferir pacotes para o
receptor através dum canal não fiável
rdt_rcv(): chamada quando os pacotes chegam ao canal no
lado de receptor rcv-side
deliver_data(): chamado por rdt para entregar dados ao nível
superior
3: Nível de Transporte 3a-14
Então: Desenvolvimento do emissor incremental, Lado do receptor do protocolo de transferência de dados fiável
(rdt) Considerar apenas transferência de dados uni-direccional
Mas a informação de controlo flui nas duas direcções Uso de máquinas de estado finitas (FSM) para especificar o
emissor e o receptor
estado1
estado2
Evento que causa a transição de estadoAcções a tomar na transição de estado
estado: quando neste estado, o próximo
estado é unicamente determinado pelo
próximo evento
eventosacções
Transferência de dados fiável: início
3: Nível de Transporte 3a-15
Rdt1.0: transferência de dados fiável sobre um canal fiável
Canal que está por baixo é perfeitamente fiável Não há erros nos bits Não há perda de pacotes
FSM separadas para o emissor e o receptor Emissor envia dados para o canal Receptor lê dados do canal
3: Nível de Transporte 3a-16
rdt2.0: canal introduz erros nos bits
Canal que está por baixo pode trocar bits nos pacotes Relembrar: o checksum UDP checksum detecta erros em bits
Questão: como recuperar dos erros ? acknowledgements (ACKs):
• receptor diz, explicitamente, ao emissor que recebeu um pacote sem erros.
negative acknowledgements (NAKs): • receptor diz, explicitamente, ao emissor que recebeu um pacote
com erros • emissor retransmite o pacote quando recebe o NAK
Exemplos humanos de utilização de ACKs e NAKs? Novos mecanismos em rdt2.0 (para além de rdt1.0):
detecção de erros resposta (feed-back) do receptor: mensagens de controlo (ACK,NAK) receptor emissor
3: Nível de Transporte 3a-17
rdt2.0: Especificação FSM
Emissor FSM Receptor FSM
3: Nível de Transporte 3a-18
rdt2.0: em acção (sem erros)
Emissor FSM Receptor FSM
3: Nível de Transporte 3a-19
rdt2.0: em acção (com erros)
Emissor FSM Receptor FSM
3: Nível de Transporte 3a-20
rdt2.0 tem uma deficiência fatal!O que acontece se os ACKs e
os NAKs se corromperem? O emissor não sabe o que
acontece ao receptor! Retransmissões pode ocasionar
pacotes duplicados
O que fazer? Emissor envia ACKs/NAKs
referentes aos ACK/NAK do receptor ? O que acontece se os
ACKs/NAKs do emissor se perderem ?
Retransmite-se! Podem ser retransmitidos
pacotes correctamente recebidos
Tratamento de duplicações: Emissor acrescenta número
de sequência a cada pacote Emissor retransmite pacote
corrente se o ACK/NAK se corromper
Receptor descarta pacotes duplicados (não os entrega aos níveis superiores).
Emissor envia um pacote e espera pela resposta do receptor
stop and wait
3: Nível de Transporte 3a-21
rdt2.1: emissor, trata ACK/NAKs corrompidos
3: Nível de Transporte 3a-22
rdt2.1: receiver, handles garbled ACK/NAKs
3: Nível de Transporte 3a-23
rdt2.1: discussão
Emissor: Nº de sequência
adicionado a cada pacote Dois nºs de sequência
(0,1) são suficientes Porquê ?
Tem de verificar se os ACKs/NAKs recebidos estão corrompidos
O dobro do nº de estados O estado tem de se
“lembrar” se o pacote “corrente” tem o nº de sequência 0 ou 1.
Receptor: Tem de verificar se
recebeu pacotes duplicados o estado indicad sed se
espera um pacote com o nº de sequência 0 ou 1.
nota: receptor não pode saber se o último ACK/NAK chegou correctamente ao emissor
3: Nível de Transporte 3a-24
rdt2.2: um protocol livre de NAKs
a mesma funcionalidade de rdt2.1, usando ACKs apenas
em vez de NAK, receptor envia ACK referente ao último pacote correctamente recebido
receptor tem de incluir, explicitamente, o nº de sequência do pacote a ser confirmado, isto é, ACKed
ACKs duplicados no emissor resultam na mesma acção que um NAK: retransmissão do pacote corrente
EmissorFSM
!
3: Nível de Transporte 3a-25
rdt3.0: canais com erros e perdas
Novos pressupostos: canal que está por baixo também pode perder pacotes (dados ou ACKs) checksum, nºseq., ACKs,
retransmissões ajudam, mas não são suficientes
Q: como lidar com as perdas? Emissor espera até que
certos dados ou ACKs se percam, depois retransmite
desvantagens?
Aproximação: emissor espera uma quantidade de tempo “razoável” por um ACK
retransmite se o ACK não for recebido nesse tempo
Se o pacote de dados (ou o ACK) se tiver atrasado (mas não perdido): Retransmissão será
duplicada, mas a utilização de nº de seq. trata disso
Receptor tem de especificar o nº de seq. do pacote que está a ser confirmado (ACKed)
Necessário um temporizador descendente (countdown timer)
3: Nível de Transporte 3a-26
rdt3.0: emissor
3: Nível de Transporte 3a-27
rdt3.0: em acção
3: Nível de Transporte 3a-28
rdt3.0: em acção
3: Nível de Transporte 3a-29
Desempenho de rdt3.0 rdt3.0 funciona, mas o desempenho…. exemplo:
Ligação = 1 Gbps Tempo de propagação extremo-a-extremo = 15 ms Pacote = 1KB
Ttransmissão=8Kb/pkt10**9 b/sec
= 8 seg
Utilização = U = =8 seg
30.016 msegFracção de tempo que o
emissor está ocupado a enviar = 0.00015
1KB pkt cada 30 mseg -> débito de 33KB/seg numa ligação 1 Gbps Protocolos de rede limitam o uso dos recursos físicos
3: Nível de Transporte 3a-30
Protocolos em pipeline
Pipeline: o emissor permite múltiplos, pacotes ainda não confirmados “a-caminho” Intervalo dos números de sequência tem de
aumentar Armazenamento no emissor e/ou receptor
Duas formas genéricas de protocolos em pipeline: go-Back-N, selective repeat
3: Nível de Transporte 3a-31
Go-Back-NEmissor: Cabeçalho do pacote com k bits para o nº de seq. “janela” de até N, pacotes consecutivos ainda não confirmados.
ACK(n): ACKs todos os pacotes até o nº de seq. n ACK acumulativo podem ser recebidos ACKs duplicados (ver receptor)
temporizador para cada pacote a caminho timeout(n): retransmite pacote n e todos os pacotes de nº de seq. superior na janela.
3: Nível de Transporte 3a-34
GBN em acção
3: Nível de Transporte 3a-35
Repetição selectiva
Receptor faz o ACK individual de todos os pacotes correctamente recebidos armazena pacotes, quando necessário, para os
poder entregar por ordem aos níveis superiores Emissor apenas re-envia pacotes para os
quais o ACK não tenha sido recebido. Temporizador no emissor para cada pacote não
confirmado (unACKed) Janela do emissor
N nº de seq. consecutivos Novamente há limite para o nº de pacotes com
novo nº de seq. a serem enviados, em função dos pacotes não confirmados
3: Nível de Transporte 3a-36
Repetição selectiva: janela do emissor e receptor
3: Nível de Transporte 3a-38
Repetição selectiva: em acção
3: Nível de Transporte 3a-39
Repetição selectiva : dilema
Exemplo: Nºs seq : 0, 1, 2, 3 Dimensão da janela
=3
o receptor vê diferenças nos dois cenários!
Dados duplicados são passados incorrectamente como novos em (a)
Q: qual a relação entre o nº de seq. e a dimensão da janela ?
3: Nível de Transporte 3a-40
TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581
Transmissão de dados bi-direccional: Transmissão de dados bi-
direccional na mesma ligação
MSS: maximum segment size
Orientado-à-ligação: handshaking
(transferência de mensagens de controlo)
• Inicia o estado do emissor e do receptor antes de transferir os dados
Fluxo controlado: Emissor não sobrecarrega
o receptor
Ponto-a-ponto: Um emissor, um receptor
Cadeia de bytes ordenada e fiável: Não há “fronteiras nas
mensagens” pipelined:
TCP dimensão das janelas de controlo de congestão e de fluxo ajustável
Buffers no emissor e receptor
socketdoor
TCPBuffer de envio
TCPBuffer de recepção
socketdoor
AplicaçãoEscrita de dados
AplicaçãoLeitura de dados
segmento
3: Nível de Transporte 3a-41
TCP: estrutura do segmento
# porto origem# porto destino
32 bits
applicationdata
(variable length)
Número sequênciaNúmero
acknowledgmentrcvr window size
ptr urgent datachecksum
FSRPAUheadlen
notused
Opções (dimensão variável)
3: Nível de Transporte 3a-42
TCP: estrutura do segmento
# porto destino
32 bits
applicationdata
(variable length)
Número sequênciaNúmero
acknowledgmentrcvr window size
ptr urgent datachecksum
FSRPAUheadlen
notused
Opções (dimensão variável)
# porto origem Nº de sequência e Nº de ACKS: Contagem por bytes de dados Não segmentos !
Head Length em palavras de 32 b Dimensão sem extensões 20 B
RCVR Window Size: Nº de Bytes que o receptor espera
receber
Opções: Negociação de parâmetros
• MSS (usual 1500; 536; 512 B)• Factor de escala p/ janela em
ligações de alto débito
3: Nível de Transporte 3a-43
TCP: estrutura do segmento
# porto destino
32 bits
applicationdata
(variable length)
Número sequênciaNúmero
acknowledgmentrcvr window size
ptr urgent datachecksum
FSRPAUheadlen
notused
Opções (dimensão variável)
# porto origem Flags de sinalização de informação urgente:
U – URG: dados que o nível superior do emissor sinalizou como urgentes
P – PSH: O receptor deve passar os dados para o nível superior imediata/
Flags de controlo A – ACK: valor válido no campo ACK R- RST; S- SYN; F – FIN:
estabelecimento e terminação da ligação
Ptr Urgent data Apontador para o último byte de
dados que contém dados urgentes
3: Nível de Transporte 3a-44
TCP nº de sequência e ACKSeq. #’s:
Nº da cadeia de bytes do primeiro byte do segmento de dados
ACKs: Nº de seq. do
próximo byte esperado do outro lado
ACK acumulativoQ: Como é que o receptor
processa segmentos for a de ordem ? A: A especificação
TCP não é clara, deixando esta questão para a implementação
Host A Host B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Utilizadordigita
‘C’
Sistema Terminal confirma (ACK)
e ecoa o ‘C’
Sistema Terminal recebe ‘C’ e
e ecoa de volta o ‘C’
tempoCenário simples de Telnet
3: Nível de Transporte 3a-45
TCP: transferência de dados fiável
Emissor simplificado, assume:
waitfor
event
waitfor
event
evento: dados recebidosdas aplicações dos
níveis superiores
evento: temporizador expira para o segmento com o nº de seq. y
evento: ACK recebido com ACK y
criação, envio do segmento
Retransmisssão do segmento y
ACK processado
•Transferência de dados uni-direcccional•Sem controlo de fluxo•Sem controlo de congestão
3: Nível de Transporte 3a-46
TCP: transferência de dados fiável
00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 0203 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compute new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */
Emissor TCP simplificado
3: Nível de Transporte 3a-47
TCP geração de ACKs [RFC 1122, RFC 2581]
Evento
Chegada ordenada de segmentos, Sem “buracos”,tudo o mais já ACKed
Chegada ordenada de segmentos, Sem “buracos”, Um ACK pendente por atraso
Chegada de segmentos desordenadaNº de seq. superior ao esperado“Buraco(s)” detectados
Chegada de segmento que preenche completa ou incompletamente o buraco
TCP Acção no receptor
ACK atrasado. Espera máxima de 500 mspelo próximo segmento. Se não chega segmento, envia ACK
Envia imediatamente um único ACKAcumulativo, referente a todos os segmentosque chegaram ordenadamente
Envia ACK duplicado, indicando o nº de seq.do próximo byte esperado
ACK imediato se o segmento começa no limite inferior do “buraco”
3: Nível de Transporte 3a-48
TCP: cenários de retransmissão
Host A
Seq=92, 8 bytes data
ACK=100
loss
tim
eout
tempo Perda de ACK
Host B
X
Seq=92, 8 bytes data
ACK=100
Host A
Seq=100, 20 bytes data
ACK=100
Seq=
92
tim
eout
tempo Timeout antecipado,ACKs acumulativo
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=
10
0 t
imeou
t
ACK=120