Captulo 3 Camada de Transporte

Tcnicas utilizadas pelos protocolos para reverter os dados perdidos ou corrompidos e

congestionamentos
1. NTRODUO E SERVOS DE CAMADA DE TRANSPORTE
Fornece servios de comunicao lgica (para a aplicao como se os hospedeiros
estivessem conectados diretamente, quando podem estar distantes e com inmeros roteadores
e enlaces entre eles) entre processos de aplicao que rodam em hospedeiros diferentes;
Os protocolos da camada de transporte so implementados nos sistemas finais e no nos
roteadores da rede;
Transforma as mensagens da camada de aplicao em pacotes fragmentos adicionados de
cabealhos (segmento) da camada de transporte; e repassa para a camada de rede do
sistema final (que transformar os segmentos e datagramas: roteadores s olham p o cabealho
adicionado pela camada de rede!)
1.1 Relao entre as camadas de transporte e a de rede
Camada transporte: comunicao lgica entre processos (multiplexao/demultiplexao de
camada de transporte)
Camada rede: comunicao lgica entre hospedeiros
Servios que um protocolo de transporte pode oferecer so, geralmente, limitados pelos
servios oferecidos pelos protocolos de rede; entretanto, um protocolo de transporte pode
oferecer certos servios mesmo que os protocolos de rede no tenham um servio equivalente;
1.2 Viso geral da camada de transporte na Internet
Protocolos da internet: TCP Transmission Control Protocol (orientado a conexo,
confivel) e UDP User Datagram Protocol (no orientado a conexo, no confivel)
O criador de uma aplicao de rede deve escolher entre um desses dois protocolos ao criar
os sockets (portas em que dados passam da rede p o processo e do processo p rede);
(REDE protocolo P, servio de entrega de melhor esforo, no garante entrega, ordem,
integridade, no confivel; hospedeiro tem pelo menos um end. da camada rede, end. P);
TCP e UDP fornecem verificao de integridade (campos de deteco de erros nos
cabealhos)
TCP: transferncia de dados confivel corretude e ordem (controle de fluxo, nmeros de
seqncia, reconhecimentos, temporizadores); controle de congestionamento (servio dirigido a
toda a nternet, no a aplicao solicitante) complexo
2. MULTPLEXAO E DEMULTPLEXAO
Ampliao do servio de entrega hospedeiro a hospedeiro (rede) para processo a processo
para aplicao que roda nesse hospedeiro (transporte)
Receptor: a camada transporte precisar direcionar a aplicao a receber os dados vindos da
camada de rede. Processos podem ter um ou mais sockets.
Demultiplexao: na extremidade receptora, a camada de transporte examina os campos, que
direcionam a porta correta de um segmento que chega a camada de transporte, identifica a porta
e direciona o segmento a este socket.
Multiplexao: no hospedeiro de origem, reunio de dados provenientes de diferentes portas
e encapsulamento com informaes de cabealho para criar segmentos. Portas precisam ter
identificadores exclusivos (16 bits: 0-1023: nmeros de porta bem conhecidos) e cada segmento
campos especiais para indicar a porta que ele deve ser entregue (campo de nmero de porta da
fonte e campo de nmero de porta do destino)
Multiplexao e demultiplexao no orientadas para conexo
Hospedeiro criando uma porta UDP:
DatagramSocket mySocket = new DatagramSocket(); ou
DatagramSocket mySocket = new DatagramSocket(19157);
Socket UDP: identificado por um tupla com dois elementos: um end. P de destino e um
nmero de porta de destino. O nmero da porta fonte um endereo de retorno
Multiplexao e demultiplexao orientadas para conexo
Socket TCP: identificado por uma tupla de quatro elementos: end. P da fonte, n de porta da
fonte, end. P destino e n de porta de destino e estabelecimento de uma conexo TCP.
Cliente TCP estabelecendo uma conexo com o servidor (cria um socket TCP para o processo
cliente, atravs do qual os dados iro entrar e sair do processo cliente):
Socket clientSocket = new Socket ("serverHostName, 6789);
Servidor criando uma nova conexo:
Socket connectionSocket = welcomeSocket.accept();
O servidor olha para o tupla de quatro nmeros e todos os prximos segmentos que chegarem
com esses quatro valores sero demultiplexados para esta porta. O servidor pode suportar
vrios sockets TCP simultneos
Servidores Web e TCP
Servidores Web geram um novo processo (cada um com seu prprio socket) ou criam uma nova
thread para cada conexo cliente (sem uma correspondncia unvoca entre processo e socket,
aumenta o desempenho). Obs.: HTTP persistente e no-persistente
3. TRANSPORTE NO ORENTADO PARA A CONEXO: UDP
Protocolo de transporte simples, servio de multip./demultiplexao e verifica erros
A aplicao praticamente fala com o P
Mensagens do processo aplicao + campos n porta fonte e destino + 2 campos
No h apresentao entre remetente e destinatrio
DNS um protocolo da camada de aplicao que utiliza UDP
Porque UDP:
- no h controle de congestionamento, nem insistncia no envio, assim logo que uma aplicao
envia uma mensagem ela encapsulada e colocada na rede, no tem que esperar, ideal para
aplicaes em tempo real, que podem admitir algumas perdas, mas no atrasos.
- no h apresentao inicial (h no TCP), no induz atrasos para estabelecer conexo
- no h estados (h no TCP) de conexo nos sistemas finais, no usa buffers/parmetros
- a sobrecarga nos pacotes pequena: 8 bytes (no TCP so 20 bytes)

Aplicao Protocolo de aplicao Protocolo de transporte
Correio eletrnico SMTP TCP
Acesso a terminal remoto Telnet TCP
Web http TCP
Transferncia de arquivo FTP TCP
Servidor remoto de arquivo NFS Tipicamente UDP
Recepo de multimdia Tipicamente proprietria Tipicamente UDP
Telefonia por nternet Tipicamente proprietria Tipicamente UDP
Gerenciamento de rede SNMP Tipicamente UDP
Protocolo de roteamento RP Tipicamente UDP
Traduo de nome DNS Tipicamente UDP
UDP no tem controle de congestionamento, se transferncias fossem altas pode haver
transbordamento com muitas perdas e acmulo de sesses TCP???
possvel que uma aplicao tenha transferncia de dados confivel utilizando UDP:
adiciona-se mecanismos de reconhecimento e retransmisso na prpria aplicao (vantagem
no gasta o tempo do TCP e nem submete-se ao seu controle; desvantagem tarefa no trivial).
3.1 Estrutura do segmento UDP
Campo de dados (mensagem da aplicao) + cabealho (quatro campos com 2 bytes cada:
porta da fonte, porta destino, comprimento B , soma de verificao(receptor verifica se h erros))
3.2 Soma de veriicao UDP
Remetente realiza complemento de 1 da soma de todas as palavras de 16 bits
Destinatrio soma todas as palavras de 16 bits incluindo a soma de verificao:
- sem erros = tudo 1
No faz nada para recuperar erros encontrados, repassa com aviso ou descarta
4. PRNCPOS DA TRASFERNCA CONFVEL DE DADOS
Um protocolo com esta caracterstica implementa a abstrao do servio fornecido a camadas
superiores um canal de dados confivel (dados no so corrompidos, nem perdidos, nem
entregues fora de ordem), quando a camada abaixo pode no ser confivel! Ex: TCP confivel,
mas implementado sobre uma camada de rede fim-a-fim no confivel (P)!
Remetente: rdt_send() utd_send()
Canal no confivel
Destinatrio: rdt_rcv() deliver_data
Alm de pacotes com dados, h trocas de pacotes de controle
!.1 "onstruindo um protocolo de transer#ncia coni$vel de dados
Transferncia confivel de dados sobre um canal perfeitamente confivel: rdt1.0
Remetente:
Aceita dados da camada superior = rdt_send(data)
Cria um pacote com os dados = make_pkt(data)
Envia-o para o canal = udt_send(data)
Destinatrio:
Recebe um pacote do canal subjacente = rdt_rcv(packet)
Transferncia confivel de dados por um canal com erros de bits: rdt2.0
Mensagens de controle: reconhecimentos positivo ACK e negativo NAK provoca
retransmisso protocolos ARQ (Automatic Repeat reQuest) exigem: deteco de erros,
realimentao do destinatrio (com um ACK ou com um NAK) e retransmisso.
Protocolo pare-e-espere (stop-and-wait)
ACKs ou NAKs comrrompidos?
- ficar pedidndo confirmaes (loop infinito)
- bits suficientes p q a soma de verificao alm de detectar, consiga recuperar os erros
- ACK ou NAK truncados reenvia o pacotepacotes duplicados, mas o destinatrio no
sabe se um pacote que chegou um novo pacote ou se retransmisso! adiciona-se um
novo campo (contendo o nmero de seqncia) ao pacote de dados para que o remetente
enumere seus pacotes. Obs.: neste protocolo pare-e-espere um bit sufucuente! rdt2.1
Eliminando o NAK, no lugar envia-se um ACK do ltimo pacote recebido corretamente: ACKs
duplicados indicam que o destinatrio no recebeu corretamente o pacote seguinte equivalente
aos AKCs
Transferncia confivel de dados por um canal com perdas e com erros de bits: rdt3.0
Como detectar a perda de pacote e o que fazer quando isso ocorre
Soma de verificao, nmeros de seqncia, pacotes ACKs e retransmisses resolvem o 2
Perda: o remetente detectar e se recuperar da perda, esperar algum tempo
Tempo: o ideal o quanto mais cedo detectar a perda reenviar, difcil clculo, a escolha
ponderada de um valor provvel, se um ACK no chegar nesse intervalo o remetente retransmite
Possibilidade de pacotes duplicados (os nmeros de seqncia lidam com isso)
Retransmisso baseada no tempo: temporizador de contagem regressiva que interrompa o
processo remetente aps ter decorrido determinado tempo
- aciona-se o temporizador cada vez que um pacote enviado
- responde-se a uma interrupo feita pelo temporizador
- parar o temporizador
Como o nmero de seqncia varia entre 0 e 1 protocolo bit alternante
!.2 Protocolos de transer#ncia coni$vel de dados com paralelismo
O protocolo para-e-espere tem baixssimo desempenho (estimativa = 30 milissegundos)
A frao de tempo em que o remetente realmente envia dados para o canal = (L/R)/(RTT + L/R)
Tempo real = capacidade de transmisso R (1 gigabit/seg)
Tamanho de pacote L (1 kbyte/pacote)
Tempo de tranmissao = L/R = 8 microssegundos
O remetente pode enviar vrios pacotes sem esperar reconhecimentos pipelining/paralelismo
Paralelismo: -faixa de nmeros de seqncia ampliada
-os lados remetente e destinatrio precisaro reservar buffers para mais de um
-1 e 2 dependero da maneira como um protocolo de transferncia (pode ser
GO-BAck-N ou repetio seletiva) responde a pacotes perdidos, corrompidos e atrasados
!.3 %o&'ac(&) *%')+
Remetente pode transmitir mltiplos pacotes, limitado por um n mximo (N) de pacotes no
reconhecidos
Base: n de seqncia do mais antigo pacote no reconhecido
Nextseqnum: menor n de seqncia no utilizado
ntervalos: [0, base-1] pacotes j transmitidos e j reconhecidos
[base, nextseqnum-1] pacotes j enviados, mas no reconhecidos
[nextseqnum, base+N-1] podem ser enviados quando estiverem disponveis
>= base+N no podem ser usados at que base seja reconhecido
Janela de tamanho N (Protocolo da janela deslizante)
O limite N: o controle de fluxo uma das razes, controle de congestionamento tambm
O n de seqncia carregado num campo fixo do cabealho, de k bits, assim o intervalo de
valores [0, 2
k
-1]
O GBN responde a trs tipos de eventos:
Chamada vinda de cima (verifica se a janela est cheia (nextseqnum<base+N), se no
estiver, cria pacote (ajustas variveis, tiver, nextseqnum), se estiver devolve p camada
superior)
Recebimento de um ACK (o recebimento cumulativo, at o n de seqncia daquele
AKC recebeu todos os pacotes corretamente)
Esgotamento de temporizao (envia todos os pacotes que j tinham sido enviados, mas
no tinham recebido a confirmao) (temporizador para o mais antigo)
O destinatrio: enviar um ACK se todos os pacotes anteriores ao pacote recebido j
estiverem OK, se no descarta e reenvia um ACK para o ultimo pacote OK o reconhecimento
cumulativo natural para o GBN
Poderia armazenar em um buffer os que chegassem fora de ordem, mas
o remetente reenviaria de todo jeito, por isso descarta simplicidade de buffers no destinatrio
S mantm o n de seq do prximo pacote esperado = expectedseqnum
Obs.: o GBN incorpora quase todas as tcnicas da transferncia de dados confivel (n de
seqncia, reconhecimentos cumulativos, somas de verificao, operao de esgotamento de
temporizao/retransmisso)
!.! Repetio seletiva *Selective Repeat & SR+
O GNB pode sofrer com problemas de desempenho (tamanho da janela e produto atraso e
largura da banda so grandes retransmisses desnecessrias)
SR faz o remetente retransmitir apenas os pacotes suspeitos de terem erros ou se perdido, o
destinatrio deve reconhecer individualmente os pacotes recebidos corretamente
Janela de tamanho N, mas pode j haver recebido ACKs de pacotes internos a janela
Remetente:
- Dados recebidos de cima: verifica se o prximo n de seq. est na janela, envia/devolve
- Esgotamento de temporizao: cada pacote tem o seu temporizador
- ACK recebido: marca aquele pacote, se ele for o send_base arrasta a janela at o
menos pacote no reconhecido
Destinatrio: Pacotes fora de ordem ficam no buffer, at que os flutuantes sejam recebidos
- Pacote com o n de seq. no intervalo [rcv_base, rcv_base+N-1] foi corretamente
recebido: est dentro da janela do destinatrio, um ACK devolvido, vai p o buffer, se for a
rcv_base a janela deslocada (de acordo com o n de pacotes que puderam ser entregues)
- Pacote com o n de seq. no intervalo [rcv_base - N, rcv_base - 1] recebido: envia ACK,
reconhecimento duplo necessrio porque a janela do remetente poderia ficar fixa
- Qualquer outro: ignorado
A falta de sincronizao entre as janelas do remetente e destinatrio tem conseqncias para
faixa finita de nmeros de seqncia (o tamanho da janela pode ser <= tamanho do espao de
numerao seqencial/2)
Os pacotes tem tempo de vida mximos (3 min) para no ressurgirem e ficar no lugar de outro
por causa do n de seqncia.
5. TRANSPORTE ORENTADO PARA CONEXO: TCP
O TCP inclui deteco de erro, retransmisso, reconhecimento cumulativo, temporizadores,
campos de cabealho para n de seqncia e de reconhecimento.
,.1 - cone.o /"P
Orientado para conexo porque h apresentao! niciam variveis de estado nessa conexo
O protocolo roda apenas nos sistemas finais, assim os elementos intermedirios no
armazenam estados de conexo TCP
Prove um servio full-duplex (numa mesma conexo ambos os sentidos, envia e recebe)
sempre ponto-a-ponto (um nico remetente e um nico destinatrio) x multicast
Processo que inicia a conexo o processo cliente, o outro processo servidor. A aplicao
informa a camada transporte que deseja estabelecer a conexo (Socket clienteSocket = new
Socket("hostname, portNumber)), o cliente envia um segmento especial TCP, o servidor
responde com outro e o cliente envia outro (j pode conter dados da camada aplicao) =
apresentao de trs vias!
Estabelecida a conexo TCP, dados passam pelo socket e esto nas mos do TCP, que os
direciona para o buffer de envio, a quantidade mxima a ser retira limitada pelo tamanho
mximo do segmento // no o tamanho mximo do segmento TCP, mas dos dados // (MSS
estabelecido pelo tamanho do maior quadro de camada de enlace que pode ser enviado - MTU)
O TCP combina: dados fornecidos do cliente com um cabealho TCP segmentos TCP e
extrai: os dados do segmento armazenando-os no buffer de recepo (a aplicao l)
TCP consiste em: buffers, variveis e um socket de conexo em cada hospedeiro
,.2 Estrutura do segmento /"P
Campo de dados: vm da aplicao, tamanho limitado pelo MSS (o TCP pode fragmentar os
dados em vrios MSSs)
Campo decabealho: geralmente 20 bytes, inclui: n de porta de fonte e de destino, campo de
soma de verificao, campo de n de seqncia (32 bits, serv. conf.), n de reconhecimento (32
bits, serv. conf.), janela de recepo (16 bits, cont, fluxo), comprimento de cabealho (4 bits,
quantas palavras de 32 bits),campo opes do TCP (pode variar, mas normalmente vazio,
negociao do MSS, tempo ou janela), campo flag (6 bits, ACK, RST, SYN, FN, PSH, URG)
Nmeros de seqncia e nmeros de reconhecimento
Fundamentais para o servio de transferncia confivel de dados do TCP
TCP v os dados como uma cadeia de dados no estruturada, mas ordenada (numera cada
byte da cedia de dados)
N de seqncia = n do primeiro byte do segmento
N de reconhecimento = o n de reconhecimento que o hospedeiro A atribui a seu segmento
o n de seqncia do prximo byte que ele estiver aguardando do hospedeiro B.
TCP s reconhece bytes at o primeiro que estiver faltando reconhecimentos cumulativos
Adecisao do que fazer com pacotes que chegam fora de ordem de quem programar a
implementao TCP, porque no h nada definido (na pratica, armazena-se)
Telnet: um estudo de caso para nmeros de seqncia e nmeros de reconhecimento
Hoje, prefere-se ssh, porque o telnet no utiliza criptografia
TCP usa piggypack (carona) uma confirmao feita junta de um segmento de dados
,.3 Estimativas do tempo de viagem de ida e volta e de esgotamento de tempori0ao
O TCP usa um mecanismo de controle de temporizao/retransmisso para recuperar
segmentos perdidos
Durao dos intervalos: maior que o RTT (qual o RTT, quanto maior)
Estimativa do tempo de ida e volta
RTT (SampleRTT) = quantidade de tempo transcorrido entre o momento que o segmento
enviado (passado ao P) (s/ retransmisso)e o momento em que recebido um reconhecimento.
O TCP fica calculando, variaes ocorrem, calcula uma mdia (mvel exponencial) ponderada
EstimatedRTT = (1-alfa)*EstimadedRTT + alfa*SampleRTT (alfa = 0,125 = 1/8)
DevRTT (variao RTT) = (1 - beta)*DevRTT + beta*|SampleRTTEstimatedRTT| (beta=0,25)
Obs.: TCP usa NAK implcito = trs ACKs duplicados e paralelismo (o n mximo de segmentos
no reconhecidos determinado pelos mecanismos de controle de fluxo e de congestionamento)
Estabelecimento e gerenciamento da temporizao e retransmisso
EstimatedRTT + margem (proporcional ao DevRTT)
Timeoutnterval = EstimatedRTT + 4*DevRTT
,.! /ranser#ncia coni$vel de dados
Com o servio P os datagramas podem ser perdidos, chegar fora de ordem, ser corrompidos
O TCP cria um servio de transferncia confivel de dados sobre este servio de melhor
esforo do P, e garante que a cadeia de dados que a aplicao l a partir do seu buffer de
recebimento TCP no est corrompida, no tem lacuna, no tem duplicao e est em ordem!
Temporizador para cada segmento pode exigir sobrecarga, usa-se um nico temporizador de
retransmisso!
1) Usa apenas temporizadores para retransmisso
2) Usa temporizadores e reconhecimentos duplicados
Eventos no remetente:
- dados recebidos da aplicao acima (se o temporizador no estiver ativado, ativado)
- esgotamento do temporizador (reenvio do menor n de seq. e inicializa o temporizador)
- recebimento de ACK (atualiza a send_base para y e reinicia o temporizador)
Alguns cenrios interessantes
1) ACK perdido, haver reenvio (quando o temporizador esgotar), o destinatrio receber
dado duplicado, descartar e reenviar o ACK
2) Remetente envia dois segmentos seguidos, o destinatrio recebe e envia dois ACKs
separados, mas eles atrasam. O primeiro segmento ser retransmitido quando o
temporizador esgotar, se os ACKs chegarem antes do temporizador esgotar de novo o
segundo segmento no ser retransmitido!
3) Remetente envia dois segmentos seguidos, o destinatrio recebe e envia dois ACKs, o
primeiro perdido, se o segundo chegar antes do tempo esgotar no haver reenvio!
Duplicao do tempo de expirao
Quando o tempo esgotado o TCP reenvia o pacote com menos n de seqncia e ajusta o
tempo de expirao para o dobro de tempo do anterior. O tempo aumenta exponencialmente a
cada expirao. A causa mais provvel da expirao o congestionamento o TCP demorar
mais para retransmitir
Mas quando o temporizador iniciado por ter recebido dados da aplicao ou ACK o
Timeoutnterval derivado dos valores de EstimatedRTT e DevRTT
Retransmisso rpida
O remetente pode detectar a perda de um pacote antes do timeout (pode demorar muito)
analisando os ACKs duplicados
Evento Ao do TCP destinatrio
Chegada de um segmento esperado, na
ordem, mas todos anteriores j reconhecidos
ACK retardado (espera 500 milisseg. e envia)
Chegada de um segmento esperado, mas
outro segmento esperando p enviar ACK
Envio imediato de um ACK acumulativo
Chegada de um segmento fora de ordem, n
de seq. maior que o esperado
Envio imediato de um ACK duplicado com o n
de seq. esperado
Chegada de um segmento que preenche parte
da lacuna
Envio de um ACK se este segmento comear
na extremidade mais baixa
Se o remetente receber trs ACKs duplicados indicao que o segmento posterior ao
segmento reconhecido trs vezes foi perdido e o TCP remetente realiza uma retransmisso
rpida, antes que o temporizador expire
GBN ou repetio seletiva?
Semelhanas c GNB: reconhecimento cumulativo e segmentos fora de ordem corretamente
recebidos no so reconhecidos individualmente, s precisa lembrar o menor n de seqncia
no reconhecido e o n de seqncia do byte a ser enviado
Diferenas c GNB: TCP pode armazenar segmentos fora de ordem, o GNB pode ter que
retrasmitir grande quantidade de dados se um ACK se perder, enquanto que o TCP pode nem
precisar retransmitir se um ACK de um segmento posterior retornar antes do timeout!
Semelhana c SR: o reconhecimento seletivo permite que o TCP reconhea seletivamente
segmentos fora de ordem
O mecanismo de recuperao de erros do TCP hibrido dos protocolos GNB e SR
,., "ontrole de lu.o
Hospedeiros de cada lado de uma conexo TCP reservam um buffer de recepo, quando os
bytes esto corretos e na seqncia so colocados neste buffer e a aplicao ler da, isso pode
demorar e, assim, o buffer pode ser saturado, para evitar isso o TCP tem o controle de fluxo
um servio de compatibilizao de velocidades (taxas de envio e q aplicao receptora l)
Controles de fluxo e de congestionamento regulam o remetente, mas tm propsitos distintos
Remetente mantm uma varivel, janela de recepo (RcvWindow), que d uma idia do
espao de buffer disponvel no destinatrio
O receptor aloca um buffer de recepo com o tamanho RcvBuffer
Variveis no destinatrio:
- LastByteRead = n do ltimo byte lido do buffer pela aplicao do receptor
- LastByteRcvd = n do ltimo byte que chegou no buffer do receptor
Variveis no remetente:
- LastByteSent
- LastByteAcked
Deve-se ter: LastByteRcvd LastByteRead <= RcvBuffer
RcvWindow = RcvBuffer (LastByteRcvd LastByteRead)
LastByteSent LastByteAcked <= RcvWindow
Processo: remetente diz ao destinatrio qual o espao do seu buffer colocando RcvWindow
no campo de janela de recepo, inicialmente o destinatrio estabelece RcvWindow = RcvBuffer
Problema: quando a RcvWindow for igual a 0 mesmo que o processo com aplicao
esvazie o buffer o remetente no saber disso porque o TCP no envia novos segmentos com o
novo valor de RcvWindow para o remetente, para resolver o remetente deve continuar enviando
segmentos com um byte de dados quando a janela de recepo for 0!
,.1 %erenciamento da cone.o /"P
O estabelecimento da conexo tem pesa nos atrasos. O estabelecimento: o processo cliente
informa ao TCP cliente que quer estabelecer uma conexo com um processo servidor, o TCP faz
- lado cliente do TCP envia um segmento especial (sem dados da aplicao, o bit SYN
ativado) ao lado servidor do TCP e escolhe um n de seq. inicial (client_isn) j indicando no
cabealho deste segmento, chamado SYN
- o servidor, quando receber o SYN, alocar buffers e variveis TCP para esta conexo e
envia segmento de aceitao (sem dados, SYN ativado, campo de reconhecimento = client_isn +
1, server_isn), este segmento chamado de SYNACK
- o cliente reserva buffers e variveis e envia mais um segmento (campo de
reconhecimento = server_isn + 1, SYN desativado, pode conter dados)
Essa a apresentao de trs vias
Qualquer um do hospedeiros podem encerrar a conexo, que quando acaba libera as
variveis e os buffers
- o processo que deseja encerrar envia um segmento (FN ativado)
- o outro hospedeiro emite uma confirmao ACK
- esse mesmo hospedeiro envia outro segmento com FN ativado
- o outro hospedeiro (que iniciou o fechamento da conexo) envia um ACK
Estados do TCP
Cliente = CLOSED (inicia uma nova conexo criando um socket) envia SYN
SYN_SENT recebe SYNACK e envia ACK ESTABLISHED pode enviar e
receber segmentos TCP de dados, se quiser fechar a conexo envia segmento FN
IN_!AIT_" recebe ACK IN_!AIT_2 recebe segmento FN e envia ACK
TI#E_!AIT reenvia o ACK final se tiver sido perdido (tempo 30, 60 ou 120 seg)
Servidor = CLOSED aplicao cria uma porta de escuta LISTEN recebe SYN e
envia SYNACK SYN_$C%D (recebe ACK, no envia nada) ESTABILISHED
recebe FN, envia ACK CLOSE_!AIT envia FN LAST_AC& recebe ACK
6. PRNCCPOS DE CONTROLE DE CONGESTONAMENTO
Causa: demasiadas fontes tentando enviar dados a uma taxa muito alta, mecanismos para
regular os remetentes
1.1 -s causas e os custos do congestionamento
Cenrio 1: dois remetentes, um roteador com buffers infinitos
Remetentes A e B compartilham um nico trecho de rede entre a fonte e o destino, A envia dados
a uma taxa mdia de /in bytes/seg.. O protocolo de transporte no tem recuperao de perdas,
controle de fluxo, nem de congestionamento. Desprezando-se sobrecargas a taxa que A oferece
ao roteador os seus dados /in bytes/seg. B igual. Os pacotes passam por um roteador e um
enlace de sada compartilhado de capacidade R. A vazo por conexo igual a /in desde que /in
seja <= R/2, quando maior a vazo igual a R/2, entretanto quando se trabalha com taxas
prximas a capacidade mxima da rede, o atraso mdio fica cada vez maior e tende ao infinito
(bom para vazo, pssimo para o atraso).
Custo da rede congestionada: h grandes atrasos de fila quando a taxa de chegada dos
pacotes se aproxima da capacidade do enlace.
Cenrio 2: dois remetentes, um roteador com buffers finitos
H descarte de pacotes quando o buffer j est cheio, mas h retransmisso dessas perdas,
assim a taxa de envio da aplicao ao socket /in, mas a taxa que a camada de transporte envia
os segmentos (carga oferecida a rede) /in`
Se /in = /in` (s envia c roteadores livres) caso 1, mas sem ultrapassar R/2 (haveria perda)
Com retransmisses, se /in` = R/2 /out = R/3
Custo da rede congestionada: remetente deve realizar retransmisses para compensar os
pacotes perdidos devido ao esgotamento do buffer
Caso em que no houve perda, apenas atraso, mas h retransmisso: trabalho desperdiado
Custo da rede congestionada: retransmisses desnecessrias
Cenrio 3: quatro remetentes, roteadores c buffers finitos, trajetos c mltiplos roteadores
Para valores pequenos de /in os valores de /out acompanham
Situao em que um roteador deve dividir entre uma conexo direta com alta taxa e outra
conexo que j passou por outro roteador e tem valores limitados ser reduzida mais pode
ir a zero se houver esgotamento do buffer! O trabalho do roteador j passado descartado se
houver perda num roteador seguinte
Custo da rede congestionada: descarte de pacotes e desperdcio da transmisso j utilizada
1.2 2ecanismos de controle de congestionamento
Distino: a camada de rede oferece ou no assistncia ao controle explicita de transporte
- controle de congestionamento fim-a-fim: no h assistncia (nem indica se h) da camada de
rede (P), a perda de segmentos TCP (temporizao, 3 ACKs duplicados) indicam o
congestionamento (usa tambm o aumento dos atrasos de ida e volta), reduz-se a janela
- controle de congestionamento assistido pela rede: os roteadores fornecem informaes ao
remetente sobre o estado de congestionamento da rede (pode ser simples). Realimentao
direta: pacote de congestionamento ou marcao em um pacote que est fluindo para o
destinatrio leva pelo menos uma viagem de ida e volta.
7. CONTROLE DE CONGESTONAMENTO TCP
Usa controle de congestionamento fim-a-fim
Obriga cada remetente a limitar a sua taxa de envio como uma funo do congestionamento
de rede percebido (Como o remetente limita? Como percebe? Qual o algoritmo dessa funo?)
Contexto do algoritmo Reno
Varivel adicional nos hospedeiros: janela de congestionamento (CongWin), limitao a taxa
de envio de um remetente, deve-se ter:
LastByteSent LastByteAcked <= min (CongWin, RcvWindow)
Anlise desprezando a limitao da janela de recepo
A taxa de envio do remetente de CongWin/RTT (ajusta CongWin ajusta a taxa)
Detecta congestionamento: perdas de pacotes
Quando o TCP percebe que os pacotes esto chegando corretamente (atravs dos
reconhecimentos) aumenta o CongWin TCP auto-regulado
Algoritmo de controle do congestionamento do TCP (tem trs componentes):
Aumento aditivo, diminuio multiplicativa
dia bsica: remetente reduzir taxa de envio (reduzindo CongWin) se h perda
Reduz metade o valor de CongWin aps um evento de perda (valor mnimo = 1 MSS)
O aumento da janela gradativo, cada vez que recebe um reconhecimento aumenta 1MSS a
cada tempo de viagem de ida e volta, fase de aumento linear preveno de congestionamento
Partida lenta
No inicio de uma conexo TCP, CongWin = 1 MSS, taxa inicial de envio = MSS/RTT
Esperar um crescimento considervel de CongWin demoraria muito, assim, na fase inicial ao
invs de aumentar a taxa linearmente, o valor de CongWin duplicado a cada RTT
(exponencialmente) at uma perda cort-la ao meio e a partir da crescer linearmente
Reao a eventos de esgotamento de temporizao
TCP reage diferente a eventos de perda detectados por ACKs ou pela temporizao esgotada
Com ACKs reage como j descrito (corta no meio e cresce linearmente)
Com esgotamento o TCP entra numa fase de partida lenta (CongWin = 1 MSS, cresce
exponencialmente at alcanar metade do valor que tinha antes do evento de esgotamento e
passa a crescer linearmente)
Para isso o TCP mantm a varivel Threshold indica onde a partida lenta terminar (no tem
efeito inicial, ajustada com alto valor) recebe metade do valor de quando ocorreu o esgotamento
Obs.: o Tahoe (verso antiga) cortava sempre para 1 MSS. Reno considera que se h ACK
algum segmento chegou! (eliminao da partida lenta aps trs ACKs = recuperao rpida)
Descrio macroscpica da dinmica do TCP
Tamanho da janela = w bytes
Tempo de viagem de ida e volta = RTT
Taxa de transmisso ~= w/RTT
W = w quando ocorre uma perda
Taxa de transmisso ~= W/2*RTT, W/RTT
Vazo mdia de uma conexo = 0,75*W/RTT
TCPs futuros
L = taxa de perda
Vazo mdia de uma conexo = 1,22*MSS/ (RTT * raiz(L))
3.1 4ustia
Um mecanismo de controle de congestionamento justo se a taxa mdia de trasmissao de cada
conexo for = taxa de transmisso do enlace/n de conexes TCP
TCP resulta em igual compartilhamento da largura de banda, as sesses cujos RTTs so
menores conseguem obter largura da banda disponvel mais rapidamente
Justia e UDP
UDP usa uma taxa constante e ocasionalmente perde pacotes
Busca-se desenvolver mecanismos que impeam que segmentos UDPs dominem o trfego
Justia e conexes TCP paralelas
Mesmo controlando o UDP, nada impede que uma aplicao rode sobre TCPs paralelos
3.2 2odelagem do atraso /"P
Tempo para o TCP enviar um objeto (consideramos uma rede n congestionada e c 1 enlace)
Latncia: tempo que o cliente inicia uma conexo e recebe o objeto completo (componentes
fundamentais: apresentao inicial do TCP, a partida lenta e o tempo de transmisso do objeto)
Consideraes:
- quantidade de dados a serem transmitidos limitada s pela janela de cong. remetente
- pacotes no perdido, nem corrompidos, no h retransmisso
- sobrecargas de cabealhos desprezadas
- o tamanho do objeto (O bits) um mltiplo do MSS (S bits)
- pacotes sem tempo de transmisso n desprezveis: segmentos TCP tamanho mximo
- taxa de transmisso do enlace R bps
Sem janela latncia = 2 RTT + O/R
Janela de congestionamento esttica
TCP usa dinmica
Tamanho da janela = W (servidor no pode ter mais que W segmentos no reconhecidos)
1) WS/R > RTT + S/R servidor recebe reconhecimento antes de completar o envio da janela;
latncia = 2RTT + O/R
2) WS/R > RTT + S/R envia a janela toda antes de receber um reconhecimento
K = O/WS
Durao de cada perodo de suspenso = RTT (W 1)S/R
Latncia = 2RTT + O/R + (K - 1) [S/R + RTT WS/R]
Janela de congestionamento dinmica
A cada reconhecimento o servidor duplica o tamanho da janela
A k-sima janela contm: 2
k-1
segmentos
K (nmero de janelas que abrangem o objeto) = teto (log2((O/S) + 1))
Tempo de suspenso = min ([S/R + RTT - 2
k-1
(S/R)], 0 )
Latncia = 2 RTT + O/R + Somatrio[k=1, k-1] (S/R + RTT - 2
k-1
S/R)
+
N de vezes que entra em suspenso //Q = cho (log2(1 + RTT/(S/R))) + 1// (P) = min (Q, K-1)
Latncia = 2 RTT + O/R + P[S/R + RTT] (2
p
1) S/R
Obs.: a partida lenta no aumentara de maneira significativa a latncia se RTT << O/R; para RTT
maiores o efeito da partida lenta torna-se significativo para objetos pequenos para velocidades
de transmisses menores