Capítulo 3: Camada de Transporte Metas do capítulo: r entender os princípios atrás dos serviços da camada de transporte: m multiplexação/ demultiplexação

Capítulo 3: Camada de TransporteMetas do capítulo: entender os

princípios atrás dos serviços da camada de transporte: multiplexação/

demultiplexação transferência

confiável de dados controle de fluxo controle de

congestionamento

aprender sobre os protocolos da camada de transporte da Internet: UDP: transporte não

orientado a conexões

TCP: transporte orientado a conexões

Controle de congestionamento do TCP 3: Camada de Transporte 1

Conteúdo do Capítulo 3

3.1 Introdução e serviços de camada de transporte

3.2 Multiplexação e demultiplexação 3.3 Transporte não orientado para conexão:

UDP 3.4 Princípios da transferência confiável de

dados

3.5 Transporte orientado para conexão: TCP 3.6 Princípios de controle de

congestionamento 3.7 Controle de congestionamento no TCP

3: Camada de Transporte 2

Serviços e protocolos de transporte

fornecem comunicação lógica entre processos de aplicação executando em diferentes hospedeiros

os protocolos de transporte são executados nos sistemas finais: lado transmissor: quebra

as mensagens da aplicação em segmentos, repassa-os para a camada de rede

lado receptor: remonta as mensagens a partir dos segmentos, repassa-as para a camada de aplicação

existe mais de um protocolo de transporte disponível para as aplicações

Internet: TCP e UDP

aplicaçãotransporte

redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

transporte lógico fim a fim


Camadas de Transporte x rede camada de rede: comunicação lógica entre

hospedeiros camada de transporte: comunicação lógica

entre os processos depende de, estende serviços da camada de rede

Analogia doméstica:12 crianças enviando cartas

para 12 crianças processos = crianças mensagens da apl. =

cartas nos envelopes hospedeiros = casas protocolo de transporte

= Anna e Bill protocolo da camada de

rede = serviço postal


Protocolos da camada de transporte Internet

entrega confiável, ordenada (TCP) controle de

congestionamento controle de fluxo estabelecimento de

conexão (“setup”) entrega não confiável, não

ordenada: UDP extensão sem “gorduras”

do “melhor esforço” do IP serviços não disponíveis:

garantias de atraso máximo

garantias de largura de banda mínima


redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

transporte lógico fim a fim






dados




Multiplexação/demultiplexação

Entrega dos segmentos recebidos ao socket correto

Demultiplexação no receptor:reúne dados de muitos sockets, envelopa os dados com o cabeçalho (usado posteriormente para a demultiplexação)

Multiplexação no transm.:

processo

socket

transporte

aplicação

física

enlace

rede

P2P1

transporte

aplicação

física

enlace

rede

P4transporte

aplicação

física

enlace

rede

P3


computador recebe os datagramas IP cada datagrama possui os endereços IP da origem e

do destino cada datagrama transporta 1 segmento da camada

de transporte cada segmento possui números das portas origem e

destino O hospedeiro usa os endereços IP e os números

das portas para direcionar o segmento ao socket apropriado

Como funciona a demultiplexação

porta origem porta destino

32 bits

dados daaplicação

(mensagem)

outros campos do cabeçalho

formato de segmento TCP/UDP


Demultiplexação não orientada a conexões Cria sockets com

números de porta:DatagramSocket mySocket1 =

new DatagramSocket(9911);DatagramSocket mySocket2 =

new DatagramSocket(9922);

socket UDP identificado pela dupla:

(end IP dest, no. da porta destino)

Quando o hospedeiro recebe segmento UDP: verifica no. da porta de

destino no segmento encaminha o segmento

UDP para o socket com aquele no. de porta

Datagramas IP com mesmo no. de porta destino diferentes endereços IP origem e/ou números de porta origem podem ser encaminhados para o mesmo socket


Demultiplexação não orientada a conexões: exemplo

DatagramSocket serverSocket = new DatagramSocket

(6428);

transport

application

physical

link

network

P3transport

application

physical

link

network

P1

transport

application

physical

link

network

P4

DatagramSocket mySocket1 = new DatagramSocket (5775);

DatagramSocket mySocket2 = new DatagramSocket (9157);

source port: 9157dest port: 6428

source port: 6428dest port: 9157

source port: ?dest port: ?

source port: ?dest port: ?


Demultiplexação Orientada a Conexões

Socket TCP identificado pela quádrupla: endereço IP origem número da porta

origem endereço IP destino número da porta

destino receptor usa todos os

quatro valores para direcionar o segmento para o socket apropriado

Servidor pode dar suporte a muitos sockets TCP simultâneos: cada socket é

identificado pela sua própria quádrupla

Servidores Web têm sockets diferentes para cada conexão cliente HTTP não persistente

terá sockets diferentes para cada pedido


Demultiplexação Orientada a Conexões: exemplo

transport

application

physical

link

network

P3transport

application

physical

link

P4

transport

application

physical

link

network

P2

source IP,port: A,9157dest IP, port: B,80

source IP,port: B,80dest IP,port: A,9157

host: IP address

A

host: IP address

C

network

P6P5P3

source IP,port: C,5775dest IP,port: B,80


três segmentos, todos destinados ao endereço IP: B, dest port: 80 são demultiplexados para sockets distintos

server: IP

address B


Demultiplexação Orientada a Conexões: Servidor Web com Threads

transport

application

physical

link

network

P3transport

application

physical

link

transport

application

physical

link

network

P2

source IP,port: A,9157dest IP, port: B,80

source IP,port: B,80dest IP,port: A,9157

host: IP address

A

host: IP address

C

server: IP

address B

network

P3



P4

threaded server






dados




UDP: User Datagram Protocol [RFC 768]

Protocolo de transporte da Internet mínimo, “sem gorduras”,

Serviço “melhor esforço”, segmentos UDP podem ser: perdidos entregues à aplicação

fora de ordem sem conexão:

não há “setup” UDP entre remetente, receptor

tratamento independente de cada segmento UDP

Uso do UDP: aplicações de

streaming multimídia (tolerante a perdas, sensível a taxas)

DNS SNMP

transferência confiável sobre UDP: adiciona

confiabilidade na camada de aplicação

recuperação de erros específica da aplicação


UDP: Cabeçalho do segmento

porta origem porta dest.

32 bits

Dados de aplicação

(mensagem)

Formato do segmento UDP

comprimento checksum

Comprimento em bytes do

segmento UDP,incluindo cabeçalho

Por quê existe um UDP?

elimina estabelecimento de conexão (o que pode causar retardo)

simples: não se mantém “estado” da conexão nem no remetente, nem no receptor

cabeçalho de segmento reduzido

Não há controle de congestionamento: UDP pode transmitir tão rápido quanto desejado (e possível)


Soma de Verificação (checksum) UDP

Transmissor: trata conteúdo do

segmento como seqüência de inteiros de 16-bits

campo checksum zerado

checksum: soma (adição usando complemento de 1) do conteúdo do segmento

transmissor coloca complemento do valor da soma no campo checksum de UDP

Receptor: calcula checksum do

segmento recebido verifica se checksum

computado é tudo um ‘FFFF’: NÃO - erro detectado SIM - nenhum erro

detectado. Mas ainda pode ter erros? Veja depois ….

Objetivo: detectar “erros” (ex.: bits trocados) no segmento transmitido


Exemplo do Checksum Internet Note que:

Ao adicionar números, o transbordo (vai um) do bit mais significativo deve ser adicionado ao resultado

Exemplo: adição de dois inteiros de 16-bits

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

transbordo

somasoma de

verificação3: Camada de Transporte 18





dados




Princípios de Transferência confiável de dados (rdt) importante nas

camadas de transporte, enlace

na lista dos 10 tópicos mais importantes em redes!

características do canal não confiável determinam a complexidade de um protocolo de transferência confiável de dados (rdt)


Transferência confiável: o ponto de partida

ladotransmissor

ladoreceptor

rdt_send(): chamada de cima, (ex.: pela apl.). Passa dados p/

serementregues à camada sup. do

receptor

udt_send(): chamada pela entidade de transporte, p/

transferir pacotes para o receptor sobre o canal não confiável

rdt_rcv(): chamada quando pacote chega no lado receptor

do canal

deliver_data(): chamada pela entidade de transporte p/ entregar dados p/ camada

superior


Transferência confiável: o ponto de partidaIremos: desenvolver incrementalmente os lados transmissor e

receptor de um protocolo confiável de transferência de dados (rdt)

considerar apenas fluxo unidirecional de dados mas info de controle flui em ambos os sentidos!

Usar máquinas de estados finitos (FSM) p/ especificar os protocolos transmissor e receptor

estado1

estado2

evento causador da transição de estadoações executadas na transição de estado

estado: neste “estado” o próximo

estado é determinado

unicamente pelo próximo evento

eventoações


rdt1.0: transferência confiável sobre canais confiáveis

canal de transmissão perfeitamente confiável não há erros de bits não há perda de

pacotes FSMs separadas para

transmissor e receptor: transmissor envia

dados pelo canal subjacente

receptor lê os dados do canal subjacente


rdt2.0: canal com erros de bits

canal subjacente pode trocar valores dos bits num pacote lembre-se: checksum UDP pode detectar erros de bits

a questão: como recuperar esses erros?

Como as pessoas recuperam “erros”durante uma conversa?


rdt2.0: canal com erros de bits

canal subjacente pode trocar valores dos bits num pacote lembre-se: checksum UDP pode detectar erros de bits

a questão: como recuperar esses erros? reconhecimentos (ACKs): receptor avisa explicitamente ao

transmissor que o pacote foi recebido corretamente reconhecimentos negativos (NAKs): receptor avisa

explicitamente ao transmissor que o pacote tinha erros transmissor reenvia o pacote ao receber um NAK

novos mecanismos no rdt2.0 (em relação ao rdt1.0): detecção de erros retorno ao transmissor: mensagens de controle (ACK,NAK)

receptor->transmissor


rdt2.0: especificação da FSM


rdt2.0: operação com ausência de erros

Wait for call from above

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Wait for ACK or

NAK

Wait for call from

below

rdt_send(data)

L


rdt2.0: cenário de erro

Wait for call from above

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Wait for ACK or

NAK

Wait for call from

below

rdt_send(data)

L


rdt2.0 tem uma falha fatal!O que acontece se o

ACK/NAK for corrompido?

Transmissor não sabe o que se passou no receptor!

não pode apenas retransmitir: possibilidade de pacotes duplicados

Lidando c/ duplicatas: transmissor retransmite

o último pacote se ACK/NAK chegar com erro

transmissor inclui número de seqüência em cada pacote

receptor descarta (não entrega a aplicação) pacotes duplicados

Transmissor envia um pacote,e então aguarda resposta do receptor

pare e espera


rdt2.1: transmissor, trata ACK/NAKs corrompidos


rdt2.1: receptor, trata ACK/NAKs corrompidos

Esperar 0 de baixo

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

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)

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

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

Esperar 1 de baixo


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

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

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

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

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

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


rdt2.1: discussão

Transmissor: no. de seq no pacote bastam dois nos. de seq. (0,1). Por quê? deve verificar se ACK/NAK recebidos estão

corrompidos duplicou o no. de estados

estado deve “lembrar” se pacote “esperado” deve ter no. de seq. 0 ou 1

Receptor: deve verificar se o pacote recebido é uma

duplicata estado indica se no. de seq. esperado é 0 ou 1

nota: receptor não tem como saber se último ACK/NAK foi recebido bem pelo transmissor


rdt2.2: um protocolo sem NAKs

mesma funcionalidade do rdt2.1, usando apenas ACKs

ao invés de NAK, receptor envia ACK para último pacote recebido sem erro receptor deve incluir explicitamente no. de

seq do pacote reconhecido ACKs duplicados no transmissor

resultam na mesma ação do NAK: retransmissão do pacote corrente


rdt2.2: fragmentos do transmissor e receptor

aguarda chamada 0

de cima

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

rdt_send(data)

udt_send(sndpkt)

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

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

aguarda ACK

0

fragmento FSMdo transmissor

aguarda0 de baixo


extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)

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

udt_send(sndpkt)

fragmento FSMdo receptor

L


rdt3.0: canais com erros e perdas

Nova hipótese: canal de transmissão também pode perder pacotes (dados ou ACKs) checksum, no. de seq.,

ACKs, retransmissões podem ajudar, mas não serão suficientes

P: como lidar com perdas? transmissor espera até

ter certeza que se perdeu pacote ou ACK, e então retransmite

desvantagens?

Abordagem: transmissor aguarda um tempo “razoável” pelo ACK

retransmite se nenhum ACK for recebido neste intervalo

se pacote (ou ACK) apenas atrasado (e não perdido): retransmissão será

duplicata, mas uso de no. de seq. já cuida disto

receptor deve especificar no. de seq do pacote sendo reconhecido

requer temporizador3: Camada de Transporte 35

Transmissor rdt3.0


rdt3.0 em ação


rdt3.0 em ação

rcv pkt1send ack1

(detect duplicate)

pkt1

Remetente Destinatário

rcv pkt1

send ack0rcv ack0

send pkt1

send pkt0rcv pkt0

pkt0

ack0

(d) retransmissão prematura

pkt1timeout

resend pkt1

ack1

send ack1

ignorarcv ack1

ack1send pkt0rcv ack1 pkt0

rcv pkt0send ack0ack0


Desempenho do rdt3.0

rdt3.0 funciona, porém seu desempenho é sofrível

Exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms, pacote de 1KB:

pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace de 1 Gbps

protocolo limita uso dos recursos físicos!

U sender

= 0.0088 30.008

= 0.00027 microseconds

L / R

RTT + L / R =

dosmicrosegun8bps10

bits80009

R

Ldtrans


rdt3.0: operação pare e espere

00027,0008,30

008,0

/RTT

/tx

RL

RLU


Protocolos com paralelismo (pipelining)

Paralelismo (pipelining): transmissor envia vários pacotes em sequência, todos esperando para serem reconhecidos faixa de números de sequência deve ser

aumentada Armazenamento no transmissor e/ou no receptor

Duas formas genéricas de protocolos com paralelismo: Go-back-N, retransmissão seletiva

(a) operação do protocolo pare e espere (a) operação do protocolo com paralelismo


Paralelismo: aumento da utilização

0008,0008,30

024,0

/RTT

/3tx

RL

RLU

Aumenta a utilizaçãopor um fator de 3!


Protocolos com Paralelismo

Go-back-N: O transmissor pode ter

até N pacotes não reconhecidos no “tubo”

Receptor envia apenas acks cumulativos Não reconhece pacote

se houver falha de seq. Transmissor possui um

temporizador para o pacote mais antigo ainda não reconhecido Se o temporizador

estourar, retransmite todos os pacotes ainda não reconhecidos.

Retransmissão seletiva:

O transmissor pode ter até N pacotes não reconhecidos no “tubo”

Receptor envia acks individuais para cada pacote

Transmissor possui um temporizador para cada pacote ainda não reconhecido Se o temporizador

estourar, retransmite apenas o pacote correspondente.3: Camada de Transporte 43

Go-back-N (GBN)Transmissor: no. de seq. de k-bits no cabeçalho do pacote admite “janela” de até N pacotes consecutivos não

reconhecidos

ACK(n): reconhece todos pacotes, até e inclusive no. de seq n - “ACK/reconhecimento cumulativo” pode receber ACKs duplicados (veja receptor)

temporizador para o pacote mais antigo ainda não confirmado

Estouro do temporizador: retransmite todos os pacotes pendentes. 3: Camada de Transporte 44

GBN: FSM estendida para o transmissor

If getacknum(rcvpkt)>=base


GBN: FSM estendida para o receptor

receptor simples: usa apenas ACK: sempre

envia ACK para pacote recebido corretamente com o maior no. de seq. em-ordem pode gerar ACKs duplicados só precisa se lembrar do

expectedseqnum pacotes fora de ordem:

descarta (não armazena) -> receptor não usa buffers!

reconhece pacote com o mais alto número de seqüência em-ordem


send pkt0send pkt1send pkt2send pkt3

(wait)

sender receiver

receive pkt0, send ack0receive pkt1, send ack1 receive pkt3, discard, (re)send ack1rcv ack0, send pkt4

rcv ack1, send pkt5

timeoutsend pkt2send pkt3send pkt4send pkt5

Xloss

receive pkt4, discard, (re)send ack1receive pkt5, discard, (re)send ack1

rcv pkt2, deliver, send ack2rcv pkt3, deliver, send ack3rcv pkt4, deliver, send ack4rcv pkt5, deliver, send ack5

ignore duplicate ACK

0 1 2 3 4 5 6 7 8

sender window (N=4)

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8


Retransmissão seletiva

receptor reconhece individualmente todos os pacotes recebidos corretamente armazena pacotes no buffer, conforme necessário,

para posterior entrega em-ordem à camada superior

transmissor apenas re-envia pacotes para os quais um ACK não foi recebido temporizador de remetente para cada pacote sem

ACK janela do transmissão

N números de sequência consecutivos outra vez limita números de sequência de pacotes

enviados, mas ainda não reconhecidos


Retransmissão seletiva: janelas do transmissor e do receptor

reconhecido


Retransmissão seletiva

dados de cima: se próx. no. de seq (n) disponível está na janela, envia o

pacote e liga temporizador(n)estouro do temporizador(n): reenvia pacote n, reinicia temporizador(n)ACK(n) em [sendbase,sendbase+N]: marca pacote n “recebido” se n for menor pacote não reconhecido, avança base da

janela ao próx. no. de seq não reconhecido

pacote n em [rcvbase, rcvbase+N-1]

envia ACK(n) fora de ordem: armazena em ordem: entrega (tb.

entrega pacotes armazenados em ordem), avança janela p/ próxima pacote ainda não recebido

pacote n em [rcvbase-N,rcvbase-1]

ACK(n)

senão: ignora

receptortransmissor


Retransmissão seletiva em ação


Retransmissão seletiva: dilema

Exemplo: nos. de seq : 0, 1, 2, 3 tam. de janela =3

receptor não vê diferença entre os dois cenários!

incorretamente passa dados duplicados como novos em (a)

P: qual a relação entre tamanho de no. de seq e tamanho de janela?






dados

3.5 Transporte orientado para conexão: TCP estrutura do segmento transferência confiável de dados controle de fluxo gerenciamento da conexão

3.6 Princípios de controle de congestionamento

3.7 Controle de congestionamento no TCP


TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581

transmissão full duplex: fluxo de dados bi-direcional

na mesma conexão MSS: tamanho máximo de

segmento orientado a conexão:

handshaking (troca de msgs de controle) inicia estado do transmissor e do receptor antes da troca de dados

fluxo controlado: receptor não será afogado

pelo transmissor

ponto a ponto: 1 transmissor, 1 receptor

fluxo de bytes, ordenados, confiável:

não estruturado em msgs com paralelismo (pipelined):

tam. da janela ajustado por controle de fluxo e congestionamento do TCP

buffers de transmissão e recepção


Estrutura do segmento TCP

URG: dados urgentes (pouco usado)

ACK: campo de ACKé válido

PSH: produz envio dedados (pouco usado)

RST, SYN, FIN:estabelec. de conexão

(comandos de criação e término)

Internetchecksum

(como no UDP)

número de bytes receptor estápronto para aceitar

contagem porbytes de dados(não segmentos!)


TCP: nos. de seq. e ACKs

Nos. de seq.: “número”dentro do

fluxo de bytes do primeiro byte de dados do segmento

ACKs: no. de seq do próx.

byte esperado do outro lado

ACK cumulativoP: como receptor trata

segmentos fora da ordem? R: espec do TCP

omissa - deixado ao implementador

source port # dest port #

sequence number

acknowledgement number

checksum

rwnd

urg pointer

segmento que chega ao “transmissor”

A

sent ACKed

sent, not-yet ACKed(“in-flight”)

usablebut not yet sent

not usable

window size N

sender sequence number space

source port # dest port #

sequence number

acknowledgement number

checksum

rwnd

urg pointer

segmento de saída do “transmissor”


TCP: nos. de seq. e ACKs

cenário telnet simples


TCP: cenários de retransmissão

Cenário com perdado ACK

Temporização prematura,ACKs cumulativos

Religatemporização


Desligatemporização




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

Cenário de ACK cumulativo



Retransmissão rápida

O intervalo do temporizador é frequentemente bastante longo: longo atraso antes de retransmitir um pacote perdido

Detecta segmentos perdidos através de ACKs duplicados. O transmissor normalmente envia diversos segmentos Se um segmento se perder, provavelmente haverá muitos

ACKs duplicados.

Se o transmissor receber 3 ACKs duplicados para os mesmos dados, ele supõe que o segmento após os dados reconhecidos se perdeu: Retransmissão rápida:

retransmite o segmento antes que estoure o temporizador


Retransmissão de um segmento após três ACKs duplicados

X

Host BHost A

Seq=92, 8 bytes of data

ACK=100

ACK=100

ACK=100

ACK=100



tim

eout






dados





Controle de Fluxo do TCP

o receptor controla o transmissor, de modo que este não inunde o buffer do receptor transmitindo muito e rapidamente

Controle de fluxo

processode aplicação

Buffers de recepção do socket TCP

TCPcode

IPcode

aplicação

SO

pilha de protocolos no receptor

a aplicação pode remover dados dos buffers do socket

TCP ….

… mais devagar do que o receptor

TCP está entregando

(transmissor está enviando)

do transmissor


Controle de Fluxo do TCP: como funciona

O receptor “anuncia” o espaço livre do buffer incluindo o valor da rwnd nos cabeçalhos TCP dos segmentos que saem do receptor para o transmissor

Tamanho do RcvBuffer é configurado através das opções do socket (o valor default é de 4096 bytes)

muitos sistemas operacionais ajustam RcvBuffer automaticamente.

O transmissor limita a quantidade os dados não reconhecidos ao tamanho do rwnd recebido.

Garante que o buffer do receptor não transbordará

dados armazenados

espaço livrerwnd

RcvBuffer

carga dos segmentos TCP

para processo de aplicação

armazenamento no lado do receptor






dados





TCP: Gerenciamento de Conexõesantes de trocar dados, transmissor e receptor TCP

dialogam: concordam em estabelecer uma conexão (cada um

sabendo que o outro quer estabelecer a conexão) concordam com os parâmetros da conexão.

estado conexão: ESTABvariáveis conexão:No.seq cliente-p/-servidor servidor-p/-cliente

tamanho rcvBuffer no servidor,cliente

aplicação

network

estado conexão: ESTABvariáveis conexão:No.seq cliente-p/-servidor servidor-p/-cliente

tamanho rcvBuffer no servidor,cliente

aplicação

network

Socket clientSocket = newSocket("hostname","port

number");

Socket connectionSocket = welcomeSocket.accept();


Concordando em estabelecer uma conexão

P: a apresentação em duas vias sempre funciona em redes?

atrasos variáveis mensagens retransmitidas

(ex: req_conn(x)) devido à perda de mensagem

reordenação de mensagens

não consegue ver o outro lado

Apresentação de duas vias(2-way handshake):

Let’s talk

OKESTAB

ESTAB

choose xreq_conn(x)

ESTAB

ESTABacc_conn(x)


Concordando em estabelecer uma conexão

cenários de falha da apresentação de duas vias:

retransmite

req_conn(x)

ESTAB

req_conn(x)

conexão aberta pela metade!(sem cliente!)

cliente termina

servidoresquece x

término daconexão x

retransmite

req_conn(x)

ESTAB

req_conn(x)

data(x+1)

retransmite

dados(x+1)

aceitadados(x+1)

escolhe xreq_conn(x)

ESTAB

ESTAB

acc_conn(x)

cliente termina

ESTAB

escolhe xreq_conn(x)

ESTAB

acc_conn(x)

data(x+1) aceitadados(x+1)

término daconexão x servidor

esquece x


Apresentação de três vias do TCP

SYNbit=1, Seq=x

choose init seq num, xsend TCP SYN msg

ESTAB

SYNbit=1, Seq=yACKbit=1; ACKnum=x+1

choose init seq num, ysend TCP SYNACKmsg, acking SYN

ACKbit=1, ACKnum=y+1

received SYNACK(x) indicates server is live;send ACK for SYNACK;

this segment may contain client-to-server data

received ACK(y) indicates client is live

SYNSENT

ESTAB

SYN RCVD

estado do cliente

LISTEN

estado do servidor

LISTEN


TCP: Encerrando uma conexão seja o cliente que o servidor fecham

cada um o seu lado da conexão enviam segmento TCP com bit FIN = 1

respondem ao FIN recebido com um ACK ao receber um FIN, ACK pode ser combinado

com o próprio FIN lida com trocas de FIN simultâneos


TCP: Encerrando uma conexão

FIN_WAIT_2

CLOSE_WAIT

FINbit=1, seq=y

ACKbit=1; ACKnum=y+1

ACKbit=1; ACKnum=x+1 espera o término

pelo servidor

ainda pode enviar dados

não pode maisenviar dados

LAST_ACK

CLOSED

TIMED_WAIT

espera temporizadapor 2*tempo máximo de vida do segmento

CLOSED

FIN_WAIT_1 FINbit=1, seq=xnão pode mais enviar, mas

pode receber dados

clientSocket.close()

estado do cliente estado do servidor

ESTABESTAB






dados




Princípios de Controle de Congestionamento

Congestionamento: informalmente: “muitas fontes enviando dados

acima da capacidade da rede de tratá-los” diferente de controle de fluxo! Sintomas:

perda de pacotes (saturação de buffers nos roteadores)

longos atrasos (enfileiramento nos buffers dos roteadores)

um dos 10 problemas mais importantes em redes!


Abordagens de controle de congestionamento

Controle de congestionamento fim a fim :

não usa realimentação explícita da rede

congestionamento é inferido a partir das perdas, e dos atrasos observados nos sistemas finais

abordagem usada pelo TCP

Controle de congestionamento assistido pela rede:

roteadores enviam informações para os sistemas finais bit indicando

congestionamento (SNA, DECbit, TCP/IP ECN, ATM)

taxa explícita para envio pelo transmissor

Duas abordagens gerais para controle de congestionamento:






dados




Controle de Congestionamento do TCP: aumento aditivo, diminuição multiplicativa Abordagem: aumentar a taxa de transmissão

(tamanho da janela), testando a largura de banda utilizável, até que ocorra uma perda aumento aditivo: incrementa cwnd de 1 MSS a cada

RTT até detectar uma perda diminuição multiplicativa: corta cwnd pela metade

após evento de perda

Comportamento de dente de serra: testando a largura

de banda

76

Controle de Congestionamento do TCP: detalhes

transmissor limita a transmissão:

LastByteSent-LastByteAcked cwnd Aproximadamente,

cwnd é dinâmica, em função do congestionamento detectado na rede

Como o transmissor detecta o congestionamento?

evento de perda = estouro do temporizador ou 3 acks duplicados

transmissor TCP reduz a taxa (cwnd) após evento de perda

três mecanismos: AIMD partida lenta conservador após

eventos de estouro de temporização (prevenção de congestionamento)

taxa = cwnd RTT

Bytes/seg


No início da conexão, aumenta a taxa exponencialmente até o primeiro evento de perda: inicialmente cwnd = 1

MSS duplica cwnd a cada RTT através do incremento

da cwnd para cada ACK recebido

Resumo: taxa inicial é baixa mas cresce rapidamente de forma exponencial

TCP: Partida lenta

A

um segmento

RTT

B

tempo

dois segmentos

quatro segmentos


TCP: detectando, reagindo a perdas perda indicada pelo estouro de temporizador:

cwnd é reduzida a 1 MSS; janela cresce exponencialmente (como na

partida lenta) até um limiar, depois cresce linearmente

perda indicada por ACKs duplicados: TCP RENO ACKs duplicados indica que a rede é capaz de

entregar alguns segmentos corta cwnd pela metade depois cresce

linearmente O TCP Tahoe sempre reduz a cwnd para 1 (seja

por estouro de temporizador que ACKS duplicados) 3: Camada de Transporte 79

TCP: mudando da partida lenta para a CAP: Quando o

crescimento exponencial deve mudar para linear?

R: Quando cwnd atingir 1/2 do seu valor antes da detecção de perda.

Implementação: Limiar (Threshold) variável

(ssthresh) Com uma perda o limiar

(ssthresh) é ajustado para 1/2 da cwnd imediatamente antes do evento de perda.


Capítulo 3: Resumo

Princípios por trás dos serviços da camada de transporte: multiplexação/

demultiplexação transferência confiável de

dados controle de fluxo controle de

congestionamento instanciação e implementação

na Internet UDP TCP

Próximo capítulo: saímos da “borda” da

rede (camadas de aplicação e transporte)

entramos no “núcleo”da rede


Documents

Capítulo 3: Camada de Transporte Metas do capítulo: r entender os princípios atrás dos serviços da camada de transporte: m multiplexação/ demultiplexação