3 Transporte

Capítulo 3: Camada de Transporte Objectivos:

❒

Entender os princípios

❒

de transporte na

subjacentes ao serviço

Internet:

da camada de transporte:

❍

❍

❍

fiável

Controlo de fluxo

❍

Controlo de congestão

TCP:

transporte com

ligação

Transferência de dados

❍

UDP: transporte sem ligação

Multiplexagem/

desmultiplexagem

❍

Aprender os protocolos

❍

Controlo de congestão em TCP

Camada de Transporte

3-1

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

3.4 Princípios de

transmissão de dados fiável

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

❒

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-2

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

mensagem da aplicação em

❍

,- .$/)0 1  . 2. +( &' () * +

,-./)0 1 3 . 2. +( & ' ( ) * +

o m e r t x

camada de rede

e a

segmentos, que passa à

,-.$/ ) 0 1 .32. +( &' ( ) *+

o m e r t x

lado que envia: parte a

e

❍

,- .$/)0 1 3 . 2. +( &' ( ) * + o ic g ló

Terminais

,-.$/)0 1 3 . 2. +( &' ( ) *+

e t r o p s n a r T

❒


   

       !"!$#% &' () * +

lado que recebe: junta os

435$6 7 8439: ; < = 43>? 5 ; =<@ =@A$@ 6 7 B C A 4 A ;? D E ? 7 8;

segmentos em mensagens,

passa à camada de aplicação

❒

mais que um protocolo de

transporte disponível para as aplicações

❍

Internet: TCP e UDP

Camada de Transporte

3-3

Camada de Transporte vs. Rede

❒

Camada de Rede:

comunicação lógica entre Sistemas Terminais

❒

Camada de Transporte:

comunicação lógica entre processos

❍

baseia-se, e melhora, os serviços da camada de Rede

Camada de Transporte

3-4

Serviços de Transporte e Protocolos Ex: cartas entre

❒

“primos” de

Lisboa e Porto !!!

❒

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 = primos que tratam do correio

Protocolo de rede = serviço postal Camada de Transporte

3-5

Protocolos de Nível de Transporte na Internet

❒

entrega fiável, ordenada, unicast (TCP)

controlo de congestão

❍

controlo de fluxo

❍

estabelecimento da ligação

serviços não disponíveis:

❍

tempo real

❍

garantias de largura de

OR S$R H I T U S F S MQ VW QI J M

ORSR H I T U S F S MQ V W Q I J M

o m e r t x

❒

e a

multicast: UDP

ORS$R H I T U S F S MQ VW Q I JM

o m e r t x

não ordenada, unicast ou

OR S$R H I T U S F S MQ VW Q I J M

e

esforço, “best-effort”),

ORS$R H I T U S F S MQ VW Q I JM

o ic g ló

entrega não fiável (melhor

FGH I JFK L M N O FPQ GM ON R ORSR H I T U S F S MQ VW QI J M

e t r o p s n a r T

❒

❍

F3G$H I JF3KL M N O F3PQ G M ONR ORS$R H I T U S F S MQ V W Q I JM

banda

❍

multicast fiável Camada de Transporte

3-6

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

3.4 Princípios de

❒

transmissão de dados

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

fiável

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-7

Multiplexagem/Desmultiplexagem Multiplexagem no envio:

Demultiplexagem na recepção:

Recolher dados de diferentes

entregar os segmentos

sockets, delimitar dados com

recebidos ao socket correcto

cabeçalho (mais tarde usado para desmultiplexar)

= socket

aplicação

= processo

P3

transporte rede lig. de dados físico

máquina 1

P1 P1

aplicação transporte rede ligação de dados físico

máquina 2

P2

P4

aplicação transporte rede lig. de dados físico

máquina 3 Camada de Transporte

3-8

Como funciona a desmultiplexagem ❒

máquina recebe datagrama IP

❍

cada datagrama tem

endereço IP de origem,

endereço IP de destino

❍

32 bits #porto origem #porto destino

outros campos

cada datagrama leva 1

do

segmento da camada de

cabeçalho

transporte

❍

cada segmento tem números de porto de origem, destino

Dados da aplicação

(relembre: números de portos

(mensagem)

bem conhecidos para

aplicações específicas)

❒

máquina usa endereços IP e

números de porto para enviar o segmento para o socket

Formato do segmento TCP/UDP

apropriado

Camada de Transporte

3-9

Desmultiplexagem sem ligação

❒

Criam-se sockets com

❒

recebe um segmento

números de portos:

UDP:

DatagramSocket mySocket1 = new DatagramSocket(9157); DatagramSocket mySocket2 = new DatagramSocket(9158);

❒

❍

(endereço

IP destino, nº porto destino)

verifica o número do porto de destino no segmento

❍

envia o segmento UDP para o socket com esse número

socket UDP identificado por dois parâmetros:

Quando uma máquina

de porto

❒

datagramas IP com

diferentes endereços IP e/ou portos de origem

enviados para o mesmo socket

Camada de Transporte

3-10

Desmultiplexagem sem ligação (cont)

DatagramSocket serverSocket = new DatagramSocket(6428); P2

P1 P1

P3

PO: 6428

PO: 6428

PD: 9157

PD: 5775

PO: 9157

cliente

PD: 6428

IP: A

PO: 5775 PD: 6428

servidor

cliente IP: B

IP: C

PO: Porto Origem oferece “endereço de retorno”

Camada de Transporte

3-11

Desmultiplexagem com ligação

❒

socket TCP identificado

❒

por 4 parâmetros:

❍

endereço IP de origem

❍

número de porto de

A máquina servidora

pode suportar muitos

sockets TCP simultâneos:

❍

origem

❍

endereço IP de destino

❍

número de porto de destino

❒

máquina que recebe usa todos os quatro valores para enviar o segmento para o socket

cada socket identificado pelos seus próprios 4 parâmetros

❒

Servidores Web têm

sockets diferentes para cada cliente que se liga

❍

HTTP não persistente terá sockets diferentes para cada pedido

apropriado

Camada de Transporte

3-12

Desmultiplexagem com ligação (cont)

P2

P3

P1 P1

P4

PO: 80

PO: 80

PD: 9157

PD: 5775

PO: 9157

cliente

PD: 80

IP: A

PO: 5775 PD: 80

servidor

cliente IP: B

IP: C

Camada de Transporte

3-13

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

3.4 Princípios de

transmissão de dados fiável

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

❒

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-14

UDP: User Datagram Protocol [RFC 768] ❒

Protocolo de transporte da

Internet cru, sem ornamentos

❒

Serviço melhor esforço

❒

(“best effort”)

❒

❒

❍

perdidos

❍

entregues fora de ordem à

❒

cabeçalho pequeno do segmento

❒

sem handshaking entre o

emissor e o receptor UDP

❍

simples: não há estado da

ligação no emissor, receptor

Sem ligação

❍

sem estabelecimento de

ligação (que adiciona atraso)

Segmentos UDP podem ser:

aplicação

❒

Porque existe UDP ?

cada segmento UDP é

não há controlo de

congestão: UDP pode

transmitir tão depressa quanto se queira !!

processado

independentemente dos demais

Camada de Transporte

3-15

UDP: mais ❒

Usualmente utilizado para

32 bits

aplicações com fluxos multimédia que são:

❒

❍

tolerantes a perdas

❍

sensíveis ao ritmo

em bytes do

Outras utilizações do UDP (Porquê ?):

❒

❍

DNS

❍

SNMP

Dimensão, segmento

#porto origem #porto destino length

checksum

UDP,

incluindo

Cabeçalho

Dados da aplicação (mensagem)

Transferência fiável sobre

UDP: adicionar a fiabilidade ao nível da aplicação

❍

Recuperação de erros

Formato do segmento UDP

específica da aplicação! Camada de Transporte

3-16

checksum UDP Objectivo: detectar “erros” (e.g., bits trocados) no segmento transmitido

Emissor:

❒

Receptor:

Trata o conteúdo do

❒

sequência de inteiros de 16

❒

segmento como uma

segmentos recebidos

de checksum

checksum: soma do conteúdo do segmento (complemento para 1 da soma)

❒

Verifica se o checksum

calculado é igual ao do campo

bits

❒

Calcula o checksum dos

❍

NÃO – erro detectado

❍

SIM – não houve erro detectado

Emissor coloca o valor do checksum no campo de

❍

checksum do segmento UDP

Mas podem haver erros? Mais tarde ….. Camada de Transporte

3-17

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

3.4 Princípios de

transmissão de dados fiável

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

❒

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-18

Princípios da transmissão de dados fiável ❒

Importante nas aplicações, transporte, ligação de dados

❒

Faz parte da lista top-10 de assuntos de redes!

serviço fornecido

❒

implementação do serviço

As características do canal não fiável determinam a

complexidade do protocolo de transferência de dados fiável. Camada de Transporte

3-19

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

ao nível superior

lado do

emissor

udt_send(): chamado

deliver_data(): chamado por rdt para entregar dados

receptor

por rdt, para

transferir pacotes para o receptor através de um canal não fiável

rdt_rcv(): chamada

quando os

pacotes chegam ao canal no lado do receptor

Camada de Transporte

3-20

Transferência de dados fiável: início Vamos:

❒

Desenvolver incrementalmente os lados do emissor, receptor do protocolo de transferência de dados fiável (rdt)

❒

Considerar apenas transferência de dados unidireccional

❍

❒

Mas a informação de controlo flui nas duas direcções

Usar máquinas de estado finitas (FSM) emissor e o receptor

para especificar o

Evento que causa a transição de estado

estado: quando se

Acções a tomar na transição de estado

esperam eventos.

estado quando neste estado, o

1

próximo estado é

estado

eventos

2

acções

unicamente

determinado pelo próximo evento

Rdt1.0:

❒

❒

Camada de Transporte

3-21

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

Máquinas de estados separadas para o emissor e o receptor

❍

Emissor envia dados para o canal

❍

Receptor lê dados do canal

espera dados de cima

rdt_send(data) packet = make_pkt(data) udt_send(packet) emissor

espera dados de baixo

rdt_rcv(packet) extract (packet,data) deliver_data(data) receptor Camada de Transporte

3-22

Rdt2.0: canal introduz erros nos bits

❒

Canal que está por baixo pode trocar bits nos pacotes

❍

❒

Relembrar: o checksum UDP detecta erros em bits

Questão: como recuperar dos erros ?

❍

confirmações (acknowledgements, ACKs): •

❍

sem erros

confirmações negativas (negative acknowledgements, NAKs): •

❒

receptor diz, explicitamente, ao emissor que recebeu um pacote

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 Camada de Transporte

3-23

rdt2.0: Especificação da Máquina de Estados

rdt_send(data) sndpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) espera espera dados de ACK ou udt_send(sndpkt) cima NAK

rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ Emissor

predicado

Receptor

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)

espera dados de baixo rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Camada de Transporte

3-24

rdt2.0: funcionamento sem erros rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) espera espera dados de ACK ou udt_send(sndpkt) cima NAK

rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)

espera dados de baixo rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Camada de Transporte

3-25

rdt2.0: cenário de erros rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) espera espera dados de ACK ou udt_send(sndpkt) cima NAK

rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)

espera dados de baixo rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Camada de Transporte

3-26

rdt2.0 tem uma falha fatal! O que acontece se os ACKs ou os NAKs se

Tratamento de duplicados:

corromperem?

❒

O emissor não sabe o que

❒

A simples retransmissão pode

❒

corromper

❒

referentes aos ACK/NAK do receptor ?

❍

❒

Receptor descarta pacotes

duplicados (não os entrega ao nível superior).

O que acontece se os

parar e esperar

perderem ?

Emissor envia um pacote e

ACKs/NAKs do emissor se

stop and wait

espera pela resposta do

Retransmite-se!

❍

Emissor retransmite o pacote corrente se o ACK/NAK se

ocasionar pacotes duplicados

Emissor envia ACKs/NAKs

Emissor acrescenta número de sequência a cada pacote

aconteceu no receptor!

O que fazer?

❒

❒

Podem ser retransmitidos pacotes correctamente

receptor

Camada de Transporte

recebidos

3-27

rdt2.1: emissor, trata ACK/NAKs corrompidos

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && espera dados 0 de cima rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

Λ

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)

( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)

espera ACK ou NAK 0

espera ACK ou NAK 1

espera dados 1 de cima

Λ

rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)

Camada de Transporte

3-28

rdt2.1: receptor, trata ACK/NAKs corrompidos rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) espera dados 0 de baixo

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

espera dados 1 de baixo

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Camada de Transporte

3-29

rdt2.1: discussão Emissor:

❒

Nº de sequência adicionado a cada pacote

❒

Receptor:

❒

recebeu pacotes

Dois nºs de sequência (0,1)

duplicados

são suficientes

❍

❒

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.

o estado indica se se

espera um pacote com o

Tem de verificar se os estão corrompidos

❒

❍

Porquê ?

ACKs/NAKs recebidos

Tem de verificar se

nº de sequência 0 ou 1.

❒

nota: receptor não

pode saber se o último ACK/NAK chegou

correctamente ao emissor

Camada de Transporte

3-30

rdt2.2: um protocolo livre de NAKs

❒

a mesma funcionalidade de rdt2.1, usando apenas ACKs

❒

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

Camada de Transporte

3-31

rdt2.2: fragmentos do emissor, receptor

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && espera dados 0 de cima

fragmento

do emissor

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt)

espera dados 0 de baixo

( corrupt(rcvpkt) || isACK(rcvpkt,1) ) udt_send(sndpkt)

espera ACK 0

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

fragmento

Λ

do receptor

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) Camada de Transporte udt_send(sndpkt)

3-32

rdt3.0: canais com erros e perdas Novos pressupostos:

canal que está por baixo

Aproximação: emissor espera uma quantidade de tempo “razoável” por um ACK

também pode perder

pacotes (dados ou ACKs)

❍

checksum, nºseq., ACKs, retransmissões ajudam,

❒

retransmite se o ACK não for

❒

Se o pacote de dados (ou o ACK)

mas não são suficientes

recebido nesse tempo

se tiver atrasado (mas não perdido):

Q: como lidar com as

❍

mas a utilização de nº de seq.

perdas?

❍

trata disso

Emissor espera até ter a

❍

certeza que os dados ou o retransmite

ser confirmado (ACKed)

❒

desvantagens?

Receptor tem de especificar o

nº de seq. do pacote que está a

ACK se perdeu, depois

❍

Retransmissão será duplicada,

Necessário um temporizador

descendente (countdown timer) Camada de Transporte

3-33

rdt3.0: emissor rdt_send(data)

rdt_rcv(rcvpkt)

Λ

espera dados 0 de cima

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)

espera ACK0

timeout udt_send(sndpkt) start_timer

espera dados 1 de cima

espera ACK1

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )

Λ

Λ

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer

stop_timer

timeout udt_send(sndpkt) start_timer

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )

sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer

rdt_rcv(rcvpkt)

Λ

rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer

Camada de Transporte

3-34

rdt3.0: em acção emissor

receptor

emissor

receptor

funcionamento sem perdas

pacote perdido

Camada de Transporte

3-35

rdt3.0: em acção emissor

receptor

ACK perdido

emissor

receptor

temporizador expira prematuramente Camada de Transporte

3-36

Desempenho de rdt3.0 ❒ ❒

rdt3.0 funciona, mas o desempenho…L exemplo:

❍

Ligação = 1 Gbps

❍

Tempo de propagação extremo-a-extremo = 15 ms

❍

Pacote = 1KB

T

L (tamanho pacote em bits)

=

transmissão

U

❍

U

R (ritmo de transmissão, bps)

=

emissor

L / R RTT + L / R

=

.

008

30.008

=

=

8Kb/pkt

10**9 bit/sec

= 8

µseg

0.00027 microsec onds

emissor

: utilização ou eficiência – fracção do tempo que o emissor

está ocupado a enviar

❍

1KB (pkt) cada 30 mseg -> débito de 33KB/seg numa ligação 1 Gbps

❍

o protocolo de comunicação limita o uso dos recursos físicos!

Camada de Transporte

3-37

rdt3.0: funcionamento do stop-and-wait emissor

receptor

primeiro bit do pacote transmitido, t = 0 último bit do pacote transmitido, t = L / R primeiro bit do pacote chega último bit chega, envia ACK

RTT

duração do ACK e tempo

ACK chega, enviar o próximo pacote, t = RTT + L / R

de processamento desprezados

U

=

emissor

L / R RTT + L / R

=

.

008

30.008

=

0.00027 microsec onds Camada de Transporte

3-38

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

um protocolo stop-and-wait em funcionamento

❒

um protocolo com pipeline em funcionamento

Duas formas genéricas de protocolos em pipeline:

❍

voltar atrás N, (go-Back-N)

❍

repetição selectiva, (selective repeat)

Camada de Transporte

3-39

Pipelining: utilização melhorada emissor

receptor

primeiro bit transmitido, t = 0 último bit transmitido, t = L / R primeiro bit do pacote chega último bit do pacote chega, envia ACK último bit do 2º pacote chega, envia ACK último bit do 3º pacote chega, envia ACK

RTT

ACK chega, enviar o próximo pacote, t = RTT + L / R Aumenta utilização por um factor de 3!

U

=

emissor

3 * L / R RTT + L / R

=

024

.

30.008

=

0.0008 microsecon ds Camada de Transporte

3-40

Voltar Atrás N (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): confirma todos os pacotes até o nº de seq. n

❍

ACK cumulativo

❍

podem ser recebidos ACKs duplicados (ver receptor)

❒

temporizador único para o pacote mais antigo por confirmar

❒

timeout(n): retransmite pacote n e todos os pacotes de nº de seq. superior na janela.

Camada de Transporte

3-41

GBN: máquina de estados estendida do emissor rdt_send(data)

Λ base=1 nextseqnum=1

if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data)

Espera rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Λ

assume-se que não há ACKs fora de ordem.

start_timer cancela e volta a armar.

timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1])

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer

Camada de Transporte

3-42

GBN: máquina de estados estendida do receptor

default udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum)

Λ expectedseqnum=1 sndpkt = make_pkt(0,ACK,chksum)

Wait

extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++

Receptor simples:

❒

ACK: envia sempre ACK com o nº de sequência mais elevado para os pacotes correcta e ordenadamente recebidos

❒

❍

pode gerar ACKs duplicados

❍

só tem de recordar o nº de seq. esperado:

expectedseqnum

Pacotes fora de ordem:

❍

descartar (não armazenar) -> não há armazenamento no receptor!

❍

reconfirma o último pacote que chegou na ordem Camada de Transporte

GBN em

emissor

3-43

receptor

acção

Camada de Transporte

3-44

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 ao nível superior

❒

Emissor apenas reenvia pacotes para os quais o ACK não tenha sido recebido.

❍

❒

temporizador no emissor para cada pacote por confirmar

Janela do emissor

❍

N números de sequência consecutivos

❍

novamente limita os números de sequência dos pacotes enviados, por confirmar

Camada de Transporte

3-45

Repetição selectiva: janela do emissor e receptor

visão dos números de sequência no emissor

visão dos números de sequência no receptor Camada de Transporte

3-46

Repetição selectiva Emissor

Receptor

Dados para enviar :

Pacote n

❒

❒

envia ACK(n)

❒

fora de ordem: armazena

❒

Por ordem:

se o próximo nº de seq.

disponível cabe na janela, envia o pacote

Temporizador(n) expirou:

❒

❍

reenvia pacote n, reinicia o

∈

entrega (também entrega os tenha na ordem)

[sendbase,sendbase+N]:

❍

avança a janela para o

próximo pacote ainda não

❒

marca pacote n como

❒

se n é o pacote mais antigo

Pacote n

base da janela para o

❒

confirmado

por confirmar, avança a próximo pacote por confirmar

[rcvbase, rcvbase+N-1]

pacotes armazenados que

temporizador

ACK(n)

∈

recebido

∈

[rcvbase-N, rcvbase-1]

ACK(n)

Doutro modo:

❒

ignora

Camada de Transporte

3-47

Camada de Transporte

3-48

Repetição selectiva : em acção

Repetição selectiva: dilema

Exemplo:

❒

Nºs seq : 0, 1, 2, 3

❒

Dimensão da janela =3

❒

o receptor não 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úmero de nºs de seq. disponíveis e a

dimensão da janela ?

Camada de Transporte

3-49

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

3.4 Princípios de

transmissão de dados fiável

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

❒

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-50

TCP: Visão geral

RFCs: 793, 1122, 1323, 2018, 2581

Ponto-a-ponto:

❒

❍

Transmissão “full duplex”:

❒

um emissor, um receptor

❍

bidireccional na mesma ligação

Fluxo de bytes ordenado e fiável:

❒

❍

não há

delimitação de

❍

❍

pipelined:

❒

❍

handshaking (transferência de

mensagens de controlo) inicia o estado do emissor e do

dimensão da janela definida

receptor antes de transferir

pelo controlo de congestão e de fluxo do TCP

Buffers no emissor e receptor

❒

MSS: maximum segment size

Orientado à ligação:

❒

mensagens

Transmissão de dados

dados

Controlo de fluxo:

❒

❍

Emissor não sobrecarrega o receptor

interface socket

Aplicação Escrita de dados

Aplicação Leitura de dados

TCP Buffer de envio

TCP Buffer de recepção

interface socket Camada de Transporte

segmento

3-51

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 bits

❍

❒

Dimensão sem extensões 20 Bytes

RCVR Window Size:

❍

Nº de Bytes que o receptor espera receber

❒

Opções:

❍

Negociação de parâmetros •

MSS (usual 1500; 536; 512 Bytes)

•

Factor de escala p/ janela em ligações de alto débito

# porto origem # porto destino Número sequência

head len

Número acknowledgment not

used

UA P R S F

checksum

rcvr window size ptr urgent data

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

dados da

aplicação

(dimensão variável)

Camada de Transporte

3-52

TCP: estrutura do segmento 32 bits

❒

Flags de

urgente:

❍

Número sequência

U – URG: dados que o nível superior do emissor sinalizou como urgentes

❍

# porto origem # porto destino

sinalização de informação

P – PSH: O receptor deve passar os

head len

dados para o nível superior imediata/

❒

Flags de

controlo

❍

A – ACK: valor válido no campo ACK

❍

R- RST; S- SYN; F – FIN:

Número acknowledgment not

used

UA P R S F

rcvr window size

checksum

ptr urgent data

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

estabelecimento e terminação da ligação

❒

dados da

Ptr Urgent data

❍

aplicação

Apontador para o último byte de dados

(dimensão variável)

que contém dados urgentes

Camada de Transporte

3-53

TCP: nº de sequência e ACK Números de Sequência:

❍

de dados no segmento ACKs:

❍

máquina A

Nº do primeiro byte

Nº de seq. do próximo

Utilizador digita ‘C’

byte esperado do

ACK cumulativo:

confirma a recepção correcta dos bytes anteriores

Q: Como é que o receptor

Seq=4 2, AC K=79, data

= ‘C’

C ta = ‘ 3, da 4 = K C 79, A Seq=

outro lado

❍

máquina B

’

máquina

recebe ‘C’ e

e ecoa de volta o ‘C’

máquina

confirma (ACK) o eco de ‘C’

Seq=4 3, ACK =80

processa segmentos fora de ordem ?

❍

R: A especificação TCP não é clara,

deixando esta questão para a implementação

Cenário simples de Telnet

Camada de Transporte

tempo

3-54

TCP: Round Trip Time e Timeout Q: como definir a duração do

temporizador do

Q: como estimar o RTT?

❒ SampleRTT:

a transmissão de um segmento até à recepção do seu ACK

TCP?

❒

❍

❒

❍

maior que o RTT

demasiado curto: expira prematuramente

❍

retransmissões desnecessárias

❒

não considera retransmissões

❒ SampleRTT

mas o RTT varia

tempo medido desde

demasiado longo:

vai variar, quer-se

uma estimativa do RTT com variações “suaves”

❍

fazer a média de várias

medidas recentes, não apenas o

SampleRTT actual

reacção lenta a perdas de segmentos

Camada de Transporte

3-55

TCP: Round Trip Time e Timeout

EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT ❒

média móvel de peso exponencial (exponential weighted moving average)

❒

influência de uma amostra passada decresce com rapidez exponencial

❒

valor típico:

α = 0.125

Camada de Transporte

3-56

Exemplo de estimativa do RTT: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350

RTT (milliseconds)

300

250

200

150

100 1

8

15

22

29

36

43

50

57

64

71

78

85

92

99

106

time (seconnds) SampleRTT

Estimated RTT Camada de Transporte

3-57

TCP: Round Trip Time e Timeout Definir a duração do temporizador ( timeout)

❒ EstimatedRTT ❍

❒

mais “margem de segurança”

grande variação no

EstimatedRTT -> maior

margem de segurança

primeiro estimar quanto é que as amostras SampleRTT se desviam do EstimatedRTT:

DevRTT = (1-β β)*DevRTT + β*|SampleRTT-EstimatedRTT| (tipicamente, β = 0.25) Definir a duração do temporizador como:

TimeoutInterval = EstimatedRTT + 4*DevRTT Camada de Transporte

3-58

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

3.4 Princípios de

transmissão de dados fiável

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

❒

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-59

TCP: transferência de dados fiável

❒

O TCP cria um serviço

❒

de transmissão de

Retransmissões

desencadeadas por:

dados fiável (rdt) por

❍

cima do serviço não

expirar

fiável do IP

❒

Transmissão de segmentos com pipeline

eventos de temporizador

❍

❒

ACKs duplicados

Considere-se inicialmente um emissor TCP simplificado:

❒

ACKs cumulativos

❍

ignora ACKs duplicados

❒

O TCP usa um único

❍

ignora controlo de fluxo,

temporizador de

controlo de congestão

retransmissão

Camada de Transporte

3-60

TCP: eventos do emissor dados recebidos da aplicação:

❒

temporizador expira:

Cria segmento com nº de

❒

Nº seq. é o nº do primeiro

❒

sequência

❒

byte de dados no segmento

❒

Arma o temporizador, se não estiver já armado (o

temporizador é para o mais

retransmitir o segmento cujo tempo expirou

rearmar o temporizador

ACK recebido:

❒

Se confirma segmentos por confirmar

antigo segmento por confirmar)

❒

duração do temporizador:

TimeOutInterval

❍

actualizar o que foi confirmado

❍

armar temporizador se houver segmentos por confirmar

Camada de Transporte

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum

emissor

loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data)

TCP

(simplificado)

Comentário:

• SendBase-1: último byte

event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer

confirmado

cumulativamente Exemplo:

• SendBase-1 = 71;

event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */

3-61

y= 73, pelo que o

receptor quer 73+ ; y > SendBase, pelo que houve

confirmação de alguns dados

Camada de Transporte

3-62

TCP: cenários de retransmissão Máquina A

Máquina A

Máquina B

Seq=92 timeout

=100 ACK

X

perda

Seq=9 2, 8 b ytes d ata

Sendbase = 100

SendBase = 120

=100 ACK SendBase

SendBase

= 100

Seq=92 timeout

timeout

Seq=9 2, 8 b ytes d ata

= 120

tempo

tempo

cenário de ACK perdido

Máquina B

Seq=9 2, 8 b ytes d ata Seq= 100, 20 by tes d ata

00 =1 K 120 AC ACK= Seq=9 2, 8 b ytes d ata 20 K=1 AC

timeout prematuro

Camada de Transporte

3-63

TCP: cenários de retransmissão (mais) Máquina A

Máquina B

Seq=9 2, 8 b ytes d ata timeout

=100 Seq=1 ACK 00, 20 bytes data

X

perda

=120 ACK

SendBase = 120

tempo cenário de ACK cumulativo

Camada de Transporte

3-64

TCP: geração de ACKs

[RFC 1122, RFC 2581]

Evento

Acção no receptor TCP

Chegada de segmento na ordem, com nº sequência esperado. Tudo para trás já confirmado

ACK atrasado. Espera máxima de 500 ms pelo próximo segmento. Se não chega o próximo segmento, envia ACK

Chegada de segmento na ordem, com nº sequência esperado. Um segmento por confirmar.

Envia imediatamente um único ACK cumulativo, referente a todos os segmentos que chegaram na ordem

Chegada de segmento fora de ordem com nº de seq. superior ao esperado. Buraco detectado

Envia ACK duplicado, indicando o nº de seq. do próximo byte esperado

Chegada de segmento que preenche completa ou incompletamente o buraco

Envia ACK imediato se o segmento começa no limite inferior do “buraco” Camada de Transporte

Retransmissão Rápida (Fast

❒

Duração do temporizador (timeout) normalmente longa:

❍

atraso longo antes de

reenviar o pacote perdido

❒

Detectar segmentos perdidos via ACKs duplicados.

❍

Emissor frequentemente

❒

3-65

Retransmit)

Se o emissor recebe 3 ACKs para os mesmos dados, supõe que o

segmento depois dos

dados confirmados foi perdido:

❍

fast retransmit: reenvia o segmento antes que o temporizador expire

envia muitos segmentos seguidos

❍

Se um segmento é perdido, provavelmente haverá

muitos ACKs duplicados.

Camada de Transporte

3-66

Algoritmo Fast Retransmit

event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } um ACK duplicado para

um segmento já confirmado

fast retransmit

Camada de Transporte

3-67

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

3.4 Princípios de

transmissão de dados fiável

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

❒

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-68

TCP: Controlo de fluxo Controlo de fluxo

❒

o lado receptor da

ligação TCP tem um

emissor não

sobrecarrega o receptor por transmitir

buffer de recepção:

demasiado depressa

❒

serviço de adaptação

de velocidade: adapta

o ritmo de envio à taxa de processamento de

❒

dados da aplicação

o processo de aplicação pode ser lento a ler dados do buffer

Camada de Transporte

3-69

Controlo de fluxo: como funciona

❒

O receptor anuncia o

espaço livre incluindo o valor de

RcvWindow

nos segmentos (Suponha que o receptor TCP

❒

dados por confirmar a

descarta segmentos fora

RcvWindow

de ordem)

❒ espaço livre no buffer = RcvWindow = RcvBuffer-[LastByteRcvd LastByteRead]

O emissor limita os

❍

garante que o buffer de

recepção não transborda

❒

Quando

RcvWindow = 0,

o emissor envia segmentos de 1 byte para obrigar o receptor a responder

Camada de Transporte

3-70

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

3.4 Princípios de

❒

transmissão de dados

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

fiável

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-71

TCP: Gestão das ligações

Recordar: O emissor TCP estabelece uma ligação

antes de iniciar a troca de segmentos de dados

❒

Iniciação das variáveis

❒

Cliente: Inicia a ligação

socket_fd=socket(Domínio, Tipo, 0) connect(socket_fd,estr_ender,dim_estr_ender) Domínio =PF_INET(comunicação entre STs IPv4) Tipo = SOCK_STREAM (TCP) ou SOCK_DGRAM (UDP) estr_ender = domínio; porto; end IP destino

TCP:

❍

Nº de sequência

❍

Buffers

❍

Informação de janela de controlo de fluxo (

RcvWindow)

❒

Servidor: contactado pelo cliente

socket_fd=socket(Domínio, Tipo, 0) bind(socket_fd,estr_endereços,dim_estr_ender) listen (socket_fd, num_lig_em_espera) new_fd=accept(socket_fd, estr_endereços, dim) estr_endereços = domínio; porto; end IP origem

Camada de Transporte

3-72

Gestão das ligações: Estabelecimento Passo 1:

❒

Ligação pedida

Passo 2:

cliente envia segmento SYN =1 para o servidor

❍

Define o nº de seq. original •

❍

client_isn

❒

servidor recebe o segmento de controlo SYN, responde

com o segmento de controlo SYNACK

Não tem campo de dados

Passo 3:

❒

Ligação confirmada

cliente recebe SYNACK,

responde com segmento ACK,

❍

Não tem campo de dados

❍

Servidor reserva buffers

❍

❍

Confirma a recepção do seg. •

❍

Ack = client_isn+1

Define o nº de seq. inicial do servidor

que pode conter dados

❍

Ligação concedida

•

Reserva buffers e variáveis

Server_isn

Confirma a recepção do seg. •

Ack = server_isn+1

Camada de Transporte

3-73

Gestão das ligações: Estabelecimento

cliente

pedido

servidor

Lig (SYN= ação pedid a 1, seq =clien t_

isn)

Reserva

buffers e variáveis

Reserva

buffers e

estabelecimento

variáveis

dida once r_isn, c o ã e Ligaç seq=serv 1) , =1 isn+ (SYN k_client_ ac

Liga (SYN= ção confirm ada 0, se ack=s q=client_isn erver_ + isn+1) 1,

tempo

Camada de Transporte

3-74

Gestão das ligações: Fecho Fechando uma ligação: o cliente fecha o socket:

cliente

close

FIN

close(socket); Passo 1: cliente envia

ACK

segmento de controlo TCP

Fecha ligação, envia FIN.

timed wait

FIN, responde com ACK.

close

FIN

FIN para o servidor

Passo 2: servidor recebe

servidor

ACK

fechado

Camada de Transporte

3-75

Gestão das ligações: Fecho Passo 3: cliente recebe FIN, responde com ACK.

❍

cliente

closing

Entra em “timed wait” -

servidor

FIN

responderá com ACK a FINs recebidos

ACK

Passo 4: servidor, recebe

FIN

Ligação fechada.

Nota: com pequenas

modificações, pode tratar FINs simultâneos.

timed wait

ACK.

closing

ACK fechado

fechado

Camada de Transporte

3-76

TCP Gestão das ligações: ciclo de vida

Ciclo de vida do servidor TCP

Ciclo de vida do cliente TCP

Camada de Transporte

3-77

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

3.4 Princípios de

transmissão de dados fiável

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

❒

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-78

Princípios de Controlo de Congestão Congestão:

❒

Informalmente: “demasiadas fontes enviam

demasiada informação a um ritmo muito superior ao que a rede é capaz de processar”

❒

Diferente do controlo de fluxo!

❒

Sintomas:

❍

Perda de pacotes ( buffer overflow nos routers)

❍

Atrasos elevados (espera em fila nos buffers dos routers)

❒

Problema da lista dos TOP 10!

Camada de Transporte

3-79

Causas e custos do controlo de congestão: cenário 1

❒

Emissor A

dois emissores,

dois receptores

❒

um router, buffers

Emissor B

λin : dados originais

λout

buffers partilhados na linha de saída infinitos

infinitos

❒

sem retransmissões

❒

atraso elevado

em situação de congestão

❒

débito máximo atingível

Camada de Transporte

3-80

Causas e custos do controlo de congestão: cenário 2

❒

um router, buffers finitos

❒

emissor retransmite pacotes perdidos

Emissor A

λout

λin : dados originais λ'in : dados originais, mais dados retransmitidos

Emissor B

buffers partilhados na linha de saída finitos

Camada de Transporte

3-81

Causas e custos do controlo de congestão: cenário 2

λ

λout

❒

1 - Situação ideal :

❒

2 - Retransmissões ocorrem quando há perdas:

❒

3 - Retransmissões de pacotes atrasados (não perdidos) faz

= in

(goodput)

λ > λout in

λout

maior para o mesmo

λ

in

1

1

2

3

“custos” da congestão:

❒

Mais trabalho (retransmissões) para um dado “goodput”

❒

Retransmissões desnecessárias: linha transporta múltiplas cópias do pacote

Camada de Transporte

3-82

Causas e custos do controlo de congestão: cenário 3

❒

4 emissores

❒

caminho com vários nós

❒

Q: O que acontece quando

timeout/retransmissões

Emissor A

λ

in

e

aumentam ?

λ

in

λout

λin : dados originais λ'in : dados originais, mais dados retransmitidos

buffers partilhados na linha de saída finitos

Emissor B

Camada de Transporte

3-83

Causas e custos do controlo de congestão: cenário 3

λ

H o s t A

o u t

H o s t B

Outro “custo” da congestão:

❒

Quando um pacote se perde, qualquer capacidade de transmissão que já tenha sido usada para o transmitir é perdida!

Camada de Transporte

3-84

Abordagens ao controlo de congestão Dois tipos de abordagens ao controlo de congestão: Controlo de congestão

extremo a extremo:

❒

não há feedback explícito

Controlo de congestão assistido pela rede:

❒

aos sistemas terminais

da rede

❒

routers fornecem feedback

congestão inferida pelas

❍

congestão

perdas e atrasos

(SNA,

DECbit, TCP/IP ECN,

observadas pelos sistemas

ATM)

terminais

❒

um único bit indica a

aproximação do TCP

❍

envio explícito do ritmo a que o emissor pode enviar

Camada de Transporte

3-85

Estudo de um caso: Controlo de congestão ATM ABR ABR: available bit rate:

❒

“Serviço elástico”

❒

Se o caminho do emissor

não está sobrecarregado:

❍

management):

❒

disponível

dados

❒

Bits nas células RM activadas

pelos switches (“assistido pela

Se o caminho do emissor

rede”)

está congestionado :

❍

Enviadas pelo emissor,

intercaladas com as células de

emissor deve usar a largura de banda

❒

células/pacotes RM ( resource

❍

NI bit: No Increase - não

aumentar o ritmo (congestão

emissor envia apenas

moderada)

ao ritmo mínimo garantido

❍

CI bit: Congestion Indication indicador de congestão

❒

Células RM devolvidas ao emissor

pelo receptor com os bits intactos Camada de Transporte

3-86

Estudo de um caso: Controlo de congestão ATM ABR

❒

❒

❒

campo ER (explicit rate) de 2 bytes numa célula RM

❍

comutador (switch) congestionado pode diminuir o valor de ER da célula

❍

emissor envia ao ritmo mínimo suportado pelo caminho

bit EFCI nas células de dados:

❍

EFCI = 1 indica congestão no switch

❍

se uma célula de dados que precede a célula RM tem o EFCI activo, o receptor activa o bit CI na célula RM devolvida

Bits CI e NI

❍

Um switch pode activar o bit NI/CI, o qual deverá ser devolvido ao emissor na próxima célula RM

Camada de Transporte

3-87

Capítulo 3: Sumário

❒

3.1 Serviços da camada

❒

de transporte

❒

ligação: TCP

3.2 Multiplexagem e desmultiplexagem

❒

3.4 Princípios de

transmissão de dados fiável

❍

estrutura dos segmentos

❍

transferência de dados fiável

3.3 Transporte sem ligação: UDP

❒

3.5 Transporte com

❒

❍

controlo de fluxo

❍

gestão de ligações

3.6 Princípios de

controlo de congestão

❒

3.7 Controlo de

congestão em TCP

Camada de Transporte

3-88

Controlo de Congestão no TCP

❒

Controlo extremo-a-extremo

Como o emissor detecta a

emissor limita a transmissão:

❒

congestão?

(não assistido pela rede)

❒

timeout ou 3 ACKs

LastByteSent-LastByteAcked ≤ CongWin ❒

Resumidamente, ritmo =

RTT

❒ CongWin

duplicados

❒

CongWin

evento de perda =

emissor TCP reduz ritmo (

Bytes/seg

é dinâmico, função

da congestão da rede detectada

CongWin) após evento

de perda

três mecanismos:

❍

AIMD

❍

arranque lento (slow start)

❍

conservativo após eventos de timeout

Camada de Transporte

AIMD:

Additive-Increase, Multiplicative Decrease

decrescimento multiplicativo: dividir

3-89

CongWin a meio após

evento de perda

janela de congestão

aumento aditivo: aumenta

CongWin de 1 MSS cada RTT na ausência de eventos de perda: sondagem

24 Kbytes

16 Kbytes

8 Kbytes

tempo ligação TCP de longa duração Camada de Transporte

3-90

TCP: Arranque lento (Slow Start)

❒

Quando a ligação começa,

CongWin = 1 MSS ❍

❒

Quando a ligação

começa, aumenta o ritmo

Exemplo: MSS = 500 bytes

com rapidez exponencial

ritmo inicial = 20 kbps

de perda

e RTT = 200 mseg

❍

❒

até ao primeiro evento

o ritmo possível pode ser >> MSS/RTT

❍

vantajoso aumentar

rapidamente o ritmo para um valor respeitável

Camada de Transporte

3-91

TCP: Arranque lento (mais)

❒

Quando a ligação

Máquina A

ritmo exponencialmente até ao primeiro evento de perda:

❍

duplica RTT

❍

RTT

começa, aumenta o

Máquina B

um segme nto

dois segm entos

CongWin a cada

feito incrementando

quatro seg mentos

CongWin por cada ACK recebido

❒

Sumário: o ritmo inicial é lento, cresce

tempo

exponencialmente Camada de Transporte

3-92

Refinamento

❒

Filosofia:

Após 3 ACKs duplicados:

❍

• 3 ACKs

CongWin é reduzida a

que a rede é capaz de

metade

❍

entregar alguns segmentos

a janela passa a crescer

• timeout antes de 3 ACKs

linearmente

duplicados é “mais

Mas após timeout:

❍

agora

alarmante”

CongWin colocado

a 1 MSS;

❍

a janela passa a crescer exponencialmente

❍

até um limiar (threshold), depois cresce linearmente

Camada de Transporte

3-93

Refinamento (mais) Q: Quando deve o crescimento

exponencial mudar para linear? R: Quando

CongWin

chegar a 1/2 do

seu valor antes do timeout.

Implementação:

❒

Limiar variável

❒

Num evento de perda, o

tamanho da janela de congestão (segmentos)

❒

duplicados indica

14

TCP Reno

12 10 8 6

limiar

4

TCP Tahoe

2 0 1

2 3

4 5

6 7

8 9 10 11 12 13 14 15

ronda de transmissão

limiar é colocado a 1/2 de CongWin antes do evento de perda

❒

TCP Tahoe (antigo): recomeça de 1 após qualquer evento de perda

Camada de Transporte

3-94

Sumário: Controlo de Congestão TCP

❒

Quando

CongWin está abaixo do Threshold (limiar), o emissor está na fase slow-start, a janela cresce exponencialmente.

❒

Quando

CongWin está acima do Threshold, o

emissor está na fase congestion-avoidance, a janela cresce linearmente.

❒

Quando ocorre um triplo ACK duplicado , o

Threshold é colocado a CongWin/2 e CongWin é colocado a Threshold. ❒

Quando ocorre um timeout, o colocado a MSS.

CongWin/2 e

Threshold é CongWin é colocado a 1 Camada de Transporte

3-95

TCP: Justiça Objectivo de justiça: se K sessões TCP partilham um estrangulamento por uma mesma linha de ritmo R, cada uma deve obter um ritmo médio de R/K

ligação 1 TCP

TCP

ligação 2

estrangulamento router

capacidade R

Camada de Transporte

3-96

Porque é que o TCP é justo ? Duas sessões em competição:

❒

aumento aditivo origina um declive de 1, quando o débito aumenta

❒

decréscimo multiplicativo decresce débito proporcionalmente divisão igual de largura de banda

Débito da ligação 2

R

perda: decresce janela por um factor de 2 evitar a congestão: aumento aditivo

perda: decresce janela por um factor de 2 evitar a congestão: aumento aditivo

Débito da ligação 1

R Camada de Transporte

3-97

TCP: Justiça (mais) Justiça e UDP

❒

As aplicações multimédia normalmente não usam o

Justiça e ligações TCP paralelas

❒

de abrir ligações paralelas

TCP

❍

de congestão

❒

Usam UDP:

❍

enviam áudio/vídeo a um

ritmo constante, toleram perdas de pacotes

❒

para o mesmo destino.

não querem o ritmo

estrangulado pelo controlo

Área de investigação: amigo do TCP

nada impede as aplicações

❒

browsers Web fazem isto

❒

Exemplo: linha de ritmo R suportando 9 ligações;

❍

nova aplicação pede 1 ligação TCP, obtém ritmo R/10

❍

nova aplicação pede 11

ligações TCP, obtém mais de R/2 !

Camada de Transporte

3-98

Modelo da latência do TCP Q: Quanto tempo demora a

receber um objecto de um servidor Web

Notação, pressupostos:

❒

cliente e o servidor de ritmo R

depois de

enviar um pedido?

Ignorando a congestão, a latência depende de:

❒

estabelecimento de ligação TCP

❒

tempo de transmissão de dados

❒

arranque lento

Assumindo uma linha entre o [bit/seg]

❒

S: MSS tamanho máximo do segmento [bits]

❒

O: tamanho do objecto [bits]

❒

cabeçalhos desprezáveis

❒

sem retransmissões (sem perdas, sem corrupção)

Dimensão da janela:

❒

1º assumir: janela de

congestão fixa, W segmentos

❒

Depois janela dinâmica,

modelando o arranque lento Camada de Transporte

3-99

Janela de congestão fixa (1)

1º caso: WS/R > RTT + S/R: ACK do 1º segmento da janela recebido antes de se esgotar a janela

latência = 2RTT + O/R

W = 4 Camada de Transporte

3-100

Janela de congestão fixa (2)

2º caso:

❒

WS/R < RTT + S/R:

espera pelo ACK depois de esgotar a janela

latência = 2RTT + O/R

+ (K-1)[S/R + RTT - WS/R]

❒

K = nº de janelas de dados (cada com W

segmentos) que cobrem o objecto completo

W = 2 Camada de Transporte

3-101

Modelo de latência TCP: Arranque Lento (1)

❒

Supondo que a janela cresce de acordo com o Slow-Start.

❒

A latência de um objecto de dimensão O é:

Latência = 2 RTT +

O S S  + P  RTT +  − (2 P − 1) R R R 

em que P é o nº de vezes que o TCP no servidor pára:

P = min{Q, K − 1} -em que Q é o nº de vezes que o servidor pára se o objecto tivesse uma dimensão infinita

-Ké

o nº de janelas que cobrem o objecto

Camada de Transporte

3-102

Modelo de latência TCP: Arranque Lento (2) Componentes:

• 2 RTT para ligar e

inicia ligação TCP

pedido

pede objecto

• O/R para transmitir

primeira janela = S/R

objecto

• tempo que o servidor

RTT

segunda janela = 2S/R

pára devido ao arranque lento

terceira janela = 4S/R

Servidor pára:

P = min{K-1,Q} vezes

Exemplo: • O/S

quarta janela = 8S/R

= 15 segmentos

• K = 4 janelas • Q = 2

• P = min{K-1,Q} = 2

transmissão completa

objecto entregue

Servidor pára P=2 vezes

tempo no servidor

tempo no cliente

Camada de Transporte

3-103

Modelo de latência TCP: Arranque Lento (3)

S + RTT = Tempo desde que o servidor inicia a transmiss ão do objecto até que recebe o ACK R inicia ligação TCP

2 k −1

S = Tempo para transmitir a janela K R +

pede objecto

RTT

S k −1 S   R + RTT − 2 R  = Tempo de espera após a transmissão da janela K

primeira janela = S/R segunda janela = 2S/R terceira janela = 4S/R

quarta janela = 8S/R

P O Latência = + 2 RTT + ∑ TempoParagem p R p =1 P O S S = + 2 RTT + ∑ [ + RTT − 2 k −1 ] objecto R R entregue k =1 R O S S tempo no = + 2 RTT + P[ RTT + ] − (2 P − 1) cliente R R R

transmissão completa tempo no servidor Camada de Transporte

3-104

Modelo de latência TCP (4) Relembre que

K = número de janelas que cobrem o objecto

Como se calcula K ?

K = min{k : 2 0 S + 21 S + L + 2 k −1 S ≥ O} = min{k : 2 0 + 21 + L + 2 k −1 ≥ O / S } O = min{k : 2 k − 1 ≥ } S O = min{k : k ≥ log 2 ( + 1)} S O   = log 2 ( + 1) S   O cálculo de Q, número de paragens para um objecto de tamanho infinito, é similar (veja Problemas TPC).

Camada de Transporte

3-105

Modelo do HTTP ❒

❒

❒

❒

Assuma que uma página Web consiste de:

❍

1 página base HTML (de tamanho O bits)

❍

M imagens (cada de tamanho O bits)

HTTP não persistente:

❍

M+1 ligações TCP em série

❍

Tempo de resposta = (M+1)O/R + (M+1)2RTT + soma das paragens

HTTP persistente (com pipelining):

❍

2 RTT para pedir e receber o ficheiro base HTML

❍

1 RTT para pedir e receber M imagens

❍

Tempo de resposta

= (M+1)O/R + 3RTT + soma das paragens

HTTP não persistente com X ligações paralelas

❍

Suponha M/X inteiro.

❍

1 ligação TCP para o ficheiro base

❍

M/X conjuntos de ligações paralelas para imagens.

❍

Tempo de resposta

= (M+1)O/R +

(M/X + 1)2RTT + soma das

paragens Camada de Transporte

3-106

Tempos de resposta HTTP (em segundos) RTT = 100 mseg, O = 5 Kbytes, M=10 e X=5 20

15

non-persistent

10 persistent 5

10 Mbps

100 Kbps

1 Mbps

parallel non28 Kbps

0

persistent

Para ritmos baixos, o tempo da ligação e o tempo de resposta são dominados pelo tempo de transmissão

Ligações persistentes dão apenas uma ligeira melhoria relativamente ao caso de ligações paralelas.

Camada de Transporte

3-107

Tempos de resposta HTTP (em segundos) RTT =1 seg, O = 5 Kbytes, M=10 e X=5 70 60 50

non-persistent

40 30

persistent

20 10 10 Mbps

100 Kbps

1 Mbps

parallel non28 Kbps

0

persistent

Para RTTs elevados, o tempo de resposta é dominado pelos atrasos no estabelecimento de ligação e arranque lento de TCP.

As ligações persistentes agora dão uma melhoria importante: especialmente em redes com elevado atraso ritmo.

•

Camada de Transporte

3-108

Capítulo 3: Sumário

❒

Princípios do serviço da camada de transporte:

❍

multiplexagem,

desmultiplexagem

❍

❒

transferência de dados fiável

A seguir:

❍

controlo de fluxo

❒

❍

controlo de congestão

❍

UDP

❍

TCP

da rede (aplicações, camada de

Instanciação e implementação na Internet

Deixar a “periferia”

transporte)

❒

Entrar no “núcleo” da rede

Camada de Transporte

3-109