Direita ou esquerda ???

3: Nível de Transporte 3a-1

Direita ou esquerda ???


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


Serviços de Transporte e Protocolos Ex: cartas entre

“primos” amarelos e azuis !!!

Sistemas Terminais = casasProcessos = “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 ?


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


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-extremo


Protocolos de Nível de TransporteServiç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


RedeLig. Lógica

Físico


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-extremo



Rede

M P2Aplicação

TransporteRede

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

segmentsegmento M


Rede

P1M

M MP3 P4

Cabeçalho do segmento

Dados do nível de aplicação


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


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


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 !!


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


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


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.


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


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 estado

2

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


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


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


rdt2.0: Especificação FSM

Emissor FSM Receptor FSM


rdt2.0: em acção (sem erros)



rdt2.0: em acção (com erros)



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


rdt2.1: emissor, trata ACK/NAKs corrompidos


rdt2.1: receiver, handles garbled ACK/NAKs


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


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

!


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)


rdt3.0: emissor


rdt3.0: em acção


rdt3.0: em acção


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 seg30.016 mseg

Fracçã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


Protocolos em pipelinePipeline: 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


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.


GBN em acção


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


Repetição selectiva: janela do emissor e receptor


Repetição selectiva: em acção


Repetição selectiva : dilemaExemplo: 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 ?


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 receptorsocketdoor

TCPBuffer de envio

TCPBuffer de recepção

socketdoor

AplicaçãoEscrita de dados

AplicaçãoLeitura de dados

segmento


TCP: estrutura do segmento

# porto origem# porto destino32 bits

applicationdata

(variable length)

Número sequênciaNúmero

acknowledgmentrcvr window sizeptr urgent datachecksum

FSRPAUheadlen

notused

Opções (dimensão variável)



# porto destino32 bits

applicationdata

(variable length)



FSRPAUheadlen

notused


# 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



# porto destino32 bits

applicationdata

(variable length)



FSRPAUheadlen

notused


# 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


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


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


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


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”


TCP: cenários de retransmissãoHost A

Seq=92, 8 bytes data

ACK=100

losstimeo

ut

tempo Perda de ACK

Host B

X


ACK=100

Host A


ACK=100

Seq=

92 ti

meo

uttempo Timeout antecipado,

ACKs acumulativo

Host B


ACK=120


Seq=

100

timeo

ut

ACK=120

Documents

Direita ou esquerda ???