Direita ou esquerda ???
3: Nível de Transporte
3a-1
Capítulo 3: Nível de transporte
Objectivos do capítulo:
 Entender os princípios
Sumário do capítulo:
 Serviços de nível de transporte
subjacentes ao serviço de  Multiplexagem/Desmultiplexag
em
nível de transporte:
 Transporte sem ligação: UDP
 Multiplexagem/desmulti
 Princípios da transmissão fiável
plexagem
 Transferência de dados
 Transporte orientado à ligação:
fiável
TCP


Controlo de fluxo
Controlo de congestão
 Instanciação e
implementação na
Internet



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-2
Serviços de Transporte e Protocolos
 Ex: cartas entre
“primos” amarelos
e azuis !!!





Sistemas Terminais ?
Processos ?
Mensagens de aplicação ?
Protocolo de transporte ?
Protocolo de rede ?
Sistemas Terminais = casas
Processos = “primos”
Mensagens de aplicação = cartas nos envelopes
Protocolo de transporte = amarelo e azul
Protocolo de rede = serviço postal
3: Nível de Transporte
3a-3
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

Aplicação
Transporte
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Aplicação
Transporte
Rede
Lig. Lógica
Físico
Confia e melhora, os serviços
do Nível de Rede
3: Nível de Transporte
3a-4
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 unicast ou multi-cast: UDP
 Serviços não disponíveis:



Aplicação
Transporte
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Rede
Lig. Lógica
Físico
Aplicação
Transporte
Rede
Lig. Lógica
Físico
Tempo real
Garantias de largura de
banda
Multicast fiável
3: Nível de Transporte
3a-5
Multiplexagem/Desmultiplexagem
Relembrar:
Desmultiplexagem: entrega dos
segmentos recebidos para o
processo de aplicação correcto
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
Dados do nível de
aplicação
Cabeçalho
do segmento
segmento
Ht M
Hn segment
P1
M
Aplicação
Transporte
Rede
P3
M
M
Aplicação
Transporte
Rede
P4
M
P2
Aplicação
Transporte
Rede
3: Nível de Transporte
3a-6
Multiplexagem/Desmultiplexagem
Multiplexagem:
Recolher dados de diferentes
processos de aplicação,
delimitar dados com cabeçalho
(mais tarde usado para
desmultiplexar)
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
32 bits
# porto origem # porto destino
Outros campos
do
cabeçalho
Dados da aplicação
(messagem)
Formato do segmento TCP/UDP
3: Nível de Transporte
3a-7
Multiplexagem/desmultiplexagem: exemplos
Sistema
Terminal A
source port: x
dest. port: 23
Servidor B
source port:23
dest. port: x
Utilização do porto: simples
aplicação de telnet !
Cliente Web
Sistema Terminal A
Source IP: A
Dest IP: B
source port: x
dest. port: 80
Cliente Web
Sistema Terminal C
Source IP: C
Dest IP: B
source port: y
dest. port: 80
Source IP: C
Dest IP: B
source port: x
dest. port: 80
Web
server B
Utilização do porto:
Servidor Web
3: Nível de Transporte
3a-8
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-9
UDP: mais
 Usualmente utilizado para
aplicações de streaming
(multimédia)
Dimensão, em
 Tolerante a perdas
bytes do
 Sensível ao ritmo
segmento UDP,
 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!

32 bits
source port #
dest port #
length
checksum
incluindo
Cabeçalho
Dados da aplicação
(message)
Formato do segmento UDP
3: Nível de Transporte 3a-10
checksum UDP
Objectivo: detectar “erros” (e.g., bits trocados) no
segmento transmitido
Emissor:
Receptor:
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
segmentos recebidos
 Verifica se o checksum calculado
é igual ao do campo de checksum
 NÃO – erro detectado
 SIM – não houve erro
detectado
 Trata o conteúdo do
 Calcula o

checksum dos
Mas podem haver erros ?
Mais tarde …..
3: Nível de Transporte 3a-11
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-12
Transferência de dados fiável: início
rdt_send(): chamado do nível de
cima, (e.g., aplicação.). Envia dados
para entrega no nível superior do
receptor
Lado do
Emissor
udt_send(): chamado por rdt, para
transferir pacotes para o receptor
através dum canal não fiável
deliver_data(): chamado
por rdt para entregar dados
ao nível superior
Lado do
Receptor
rdt_rcv(): chamada quando os
pacotes chegam ao canal no lado de
receptor rcv-side
3: Nível de Transporte 3a-13
Transferência de dados fiável: início
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
Evento que causa a transição de estado
Acções a tomar na transição de estado
estado: quando neste
estado, o próximo
estado é unicamente
determinado pelo
próximo evento
estado
1
eventos
acções
estado
2
3: Nível de Transporte 3a-14
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-15
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

acknowledgements (ACKs):
Questão: como recuperar dos erros ?
• 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-16
rdt2.0:
Especificação FSM
Emissor FSM
Receptor FSM
3: Nível de Transporte 3a-17
rdt2.0:
em acção (sem erros)
Emissor FSM
Receptor FSM
3: Nível de Transporte 3a-18
rdt2.0:
em acção (com erros)
Emissor FSM
Receptor FSM
3: Nível de Transporte 3a-19
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).
stop and wait
Emissor envia um pacote e
espera pela resposta do
receptor
3: Nível de Transporte 3a-20
rdt2.1:
emissor, trata ACK/NAKs corrompidos
3: Nível de Transporte 3a-21
rdt2.1:
receiver, handles garbled ACK/NAKs
3: Nível de Transporte 3a-22
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-23
rdt2.2:
um protocol livre de NAKs
Emissor
FSM
 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
3: Nível de Transporte 3a-24
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-25
rdt3.0:
emissor
3: Nível de Transporte 3a-26
rdt3.0:
em acção
3: Nível de Transporte 3a-27
rdt3.0: em acção
3: Nível de Transporte 3a-28
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/pkt
10**9 b/sec
= 8 seg
8 seg
Fracção de tempo que o
=
= 0.00015
Utilização = Uemissor
=
está ocupado a enviar 30.016 mseg


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-29
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


go-Back-N,
selective repeat
pipeline:
3: Nível de Transporte 3a-30
Go-Back-N
Emissor:
 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-31
GBN
em acção
3: Nível de Transporte 3a-34
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-35
Repetição selectiva:
janela do emissor e receptor
3: Nível de Transporte 3a-36
Repetição selectiva: em acção
3: Nível de Transporte 3a-38
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-39
TCP: Visão geral
RFCs: 793, 1122, 1323, 2018, 2581
 Transmissão de dados bi-
 Ponto-a-ponto:
Um emissor, um receptor
 Cadeia de bytes ordenada e
fiável:
 Não há “fronteiras nas
mensagens”
direccional:

 pipelined:


Transmissão de dados bidireccional na mesma
ligação
MSS: maximum segment
size
 Orientado-à-ligação:

handshaking (transferência
de mensagens de controlo)
TCP dimensão das janelas de
• Inicia o estado do emissor
controlo de congestão e de
e do receptor antes de
transferir os dados
fluxo ajustável
 Buffers no emissor e receptor  Fluxo controlado:

socket
door
Aplicação
Escrita de dados
Aplicação
Leitura de dados
TCP
Buffer de envio
TCP
Buffer de recepção
segmento

socket
door
Emissor não sobrecarrega o
receptor
3: Nível de Transporte 3a-40
TCP: estrutura do segmento
32 bits
# porto origem # porto destino
Número sequência
Número acknowledgment
head not
UA P R S F
len used
checksum
rcvr window size
ptr urgent data
Opções (dimensão variável)
application
data
(variable length)
3: Nível de Transporte 3a-41
TCP: estrutura do segmento
32 bits
 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
# porto origem # porto destino
Número sequência
Número acknowledgment
head not
UA P R S F
len used
checksum
rcvr window size
ptr urgent data
Opções (dimensão variável)
application
data
(variable length)
3: Nível de Transporte 3a-42
TCP: estrutura do segmento
32 bits

Flags de sinalização de informação
urgente:



Flags de controlo



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/
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
# porto origem # porto destino
Número sequência
Número acknowledgment
head not
UA P R S F
len used
checksum
rcvr window size
ptr urgent data
Opções (dimensão variável)
application
data
(variable length)
3: Nível de Transporte 3a-43
TCP nº de sequência e ACK
Seq. #’s:
Host B
Host A
 Nº da cadeia de
bytes do primeiro
Utilizador
byte do segmento de
digita
dados
‘C’
ACKs:
Sistema Terminal
 Nº de seq. do
recebe ‘C’ e
próximo byte
e ecoa de volta
esperado do outro
o ‘C’
lado
 ACK acumulativo
Sistema Terminal
Q: Como é que o receptor
confirma (ACK)
processa segmentos for a
e ecoa o ‘C’
de ordem ?
 A: A especificação
TCP não é clara,
tempo
deixando esta
questão para a
Cenário simples de Telnet
implementação
3: Nível de Transporte 3a-44
TCP: transferência de dados fiável
evento: dados recebidos
das aplicações dos
níveis superiores
criação, envio do segmento
wait
wait
for
for
event
event
Emissor simplificado, assume:
•Transferência de dados
uni-direcccional
•Sem controlo de fluxo
•Sem controlo de congestão
evento: temporizador expira para
o segmento com o nº de seq. y
Retransmisssão do segmento y
evento: ACK recebido
com ACK y
ACK processado
3: Nível de Transporte 3a-45
TCP:
transferência
de dados
fiável
Emissor TCP
simplificado
00 sendbase = initial_sequence number
01 nextseqnum = initial_sequence number
02
03 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 */
3: Nível de Transporte 3a-46
TCP geração de ACKs
[RFC 1122, RFC 2581]
Evento
TCP Acção no receptor
Chegada ordenada de segmentos,
Sem “buracos”,
tudo o mais já ACKed
ACK atrasado. Espera máxima de 500 ms
pelo próximo segmento. Se não chega
segmento, envia ACK
Chegada ordenada de segmentos,
Sem “buracos”,
Um ACK pendente por atraso
Envia imediatamente um único ACK
Acumulativo, referente a todos os segmentos
que chegaram ordenadamente
Chegada de segmentos desordenada
Nº de seq. superior ao esperado
“Buraco(s)” detectados
Envia ACK duplicado, indicando o nº de seq.
do próximo byte esperado
Chegada de segmento que preenche
completa ou incompletamente o buraco
ACK imediato se o segmento começa no
limite inferior do “buraco”
3: Nível de Transporte 3a-47
TCP: cenários de retransmissão
tempo
Host A
Host B
X
loss
Perda de ACK
Host B
Seq=100 timeout
Seq=92 timeout
timeout
Host A
tempo
Timeout antecipado,
ACKs acumulativo
3: Nível de Transporte 3a-48