Capítulo 3 [Resumo]

Prévia do material em texto

Capítulo 3 – Camada de Transporte 
 Técnicas utilizadas pelos protocolos para reverter os dados perdidos ou corrompidos 
e congestionamentos 
 
1. INTRODUÇÃO E SERVIÇOS DE CAMADA DE TRANSPORTE 
 
 Fornece serviços de comunicação lógica (para a aplicação é como se os hospedeiros 
estivessem conectados diretamente, quando podem estar distantes e com inúmeros 
roteadores e enlaces entre eles) entre processos de aplicação que rodam em 
hospedeiros diferentes; 
 Os protocolos da camada de transporte são implementados nos sistemas finais e 
não nos roteadores da rede; 
 Transforma as mensagens da camada de aplicação em pacotes – fragmentos 
adicionados de cabeçalhos – (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 cabeçalho adicionado pela camada de rede!) 
 
1.1 Relação entre as camadas de transporte e a de rede 
 
 Camada transporte: comunicação lógica entre processos 
(multiplexação/demultiplexação de camada de transporte) 
 Camada rede: comunicação lógica entre hospedeiros 
 
 Serviços que um protocolo de transporte pode oferecer são, geralmente, limitados 
pelos serviços oferecidos pelos protocolos de rede; entretanto, um protocolo de 
transporte pode oferecer certos serviços me 
smo que os protocolos de rede não tenham um serviço equivalente; 
 
1.2 Visão geral da camada de transporte na Internet 
 
 Protocolos da internet: TCP – Transmission Control Protocol – (orientado a conexão, 
confiável) e UDP – User Datagram Protocol – (não orientado a conexão, não confiável) 
 
 O criador de uma aplicação 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 IP, serviço de entrega de melhor esforço, não garante entrega, 
ordem, integridade, não confiável; hospedeiro tem pelo menos um end. da camada 
rede, end. IP); 
 
 TCP e UDP fornecem verificação de integridade (campos de detecção de erros nos 
cabeçalhos) 
 
 TCP: transferência de dados confiável – corretude e ordem (controle de fluxo, 
números de seqüência, reconhecimentos, temporizadores); controle de 
congestionamento (serviço dirigido a toda a Internet, não a aplicação solicitante)  
complexo 
 
2. MULTIPLEXAÇÃO E DEMULTIPLEXAÇÃO 
 
 Ampliação do serviço de entrega hospedeiro a hospedeiro (rede) para processo a 
processo para aplicação que roda nesse hospedeiro (transporte) 
 
 Receptor: a camada transporte precisará direcionar a aplicação a receber os dados 
vindos da camada de rede. Processos podem ter um ou mais sockets. 
 
 Demultiplexação: 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. 
 
 Multiplexação: no hospedeiro de origem, reunião de dados provenientes de 
diferentes portas e encapsulamento com informações de cabeçalho para criar 
segmentos. Portas precisam ter identificadores exclusivos (16 bits: 0-1023: números de 
porta bem conhecidos) e cada segmento campos especiais para indicar a porta que ele 
deve ser entregue (campo de número de porta da fonte e campo de número de porta do 
destino) 
 
 Multiplexação e demultiplexação não orientadas para conexão 
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. IP de destino e 
um número de porta de destino. O número da porta fonte é um endereço de retorno 
 
 Multiplexação e demultiplexação orientadas para conexão 
Socket TCP: identificado por uma tupla de quatro elementos: end. IP da fonte, n° de 
porta da fonte, end. IP destino e n° de porta de destino e estabelecimento de uma 
conexão TCP. 
 
Cliente TCP estabelecendo uma conexão com o servidor (cria um socket TCP para o 
processo cliente, através do qual os dados irão entrar e sair do processo cliente): 
 Socket clientSocket = new Socket (“serverHostName”, 6789); 
Servidor criando uma nova conexão: 
 Socket connectionSocket = welcomeSocket.accept(); 
O servidor olha para o tupla de quatro números e todos os próximos segmentos que 
chegarem com esses quatro valores serão demultiplexados para esta porta. O servidor 
pode suportar vários sockets TCP simultâneos 
 
 Servidores Web e TCP 
Servidores Web geram um novo processo (cada um com seu próprio socket) ou criam 
uma nova thread para cada conexão cliente (sem uma correspondência unívoca entre 
processo e socket, aumenta o desempenho). Obs.: HTTP persistente e não-persistente 
 
3. TRANSPORTE NÃO ORIENTADO PARA A CONEXÃO: UDP 
 Protocolo de transporte simples, serviço de multip./demultiplexação e verifica erros 
 A aplicação praticamente fala com o IP 
 Mensagens do processo aplicação + campos n° porta fonte e destino + 2 campos 
 Não há apresentação entre remetente e destinatário 
 DNS é um protocolo da camada de aplicação que utiliza UDP 
 Porque UDP: 
- não há controle de congestionamento, nem insistência no envio, assim logo que uma 
aplicação envia uma mensagem ela é encapsulada e colocada na rede, não tem que 
esperar, ideal para aplicações em tempo real, que podem admitir algumas perdas, mas 
não atrasos. 
- não há apresentação inicial (há no TCP), não induz atrasos para estabelecer conexão 
- não há estados (há no TCP) de conexão nos sistemas finais, não usa 
buffers/parâmetros 
- a sobrecarga nos pacotes é pequena: 8 bytes (no TCP são 20 bytes) 
 
Aplicação Protocolo de aplicação Protocolo de transporte 
Correio eletrônico SMTP TCP 
Acesso a terminal remoto Telnet TCP 
Web http TCP 
Transferência de arquivo FTP TCP 
Servidor remoto de arquivo NFS Tipicamente UDP 
Recepção de multimídia Tipicamente proprietária Tipicamente UDP 
Telefonia por Internet Tipicamente proprietária Tipicamente UDP 
Gerenciamento de rede SNMP Tipicamente UDP 
Protocolo de roteamento RIP Tipicamente UDP 
Tradução de nome DNS Tipicamente UDP 
 
 UDP não tem controle de congestionamento, se transferências fossem altas pode 
haver transbordamento com muitas perdas e acúmulo de sessões TCP??? 
 É possível que uma aplicação tenha transferência de dados confiável utilizando UDP: 
adiciona-se mecanismos de reconhecimento e retransmissão na própria aplicação 
(vantagem – não gasta o tempo do TCP e nem submete-se ao seu controle; 
desvantagem – tarefa não trivial). 
3.1 Estrutura do segmento UDP 
  Campo de dados (mensagem da aplicação) + cabeçalho (quatro campos com 2 
bytes cada: porta da fonte, porta destino, comprimento B , soma de verificação(receptor 
verifica se há erros)) 
3.2 Soma de verificação UDP 
 Remetente realiza complemento de 1 da soma de todas as palavras de 16 bits 
 Destinatário soma todas as palavras de 16 bits incluindo a soma de verificação: 
 - sem erros = tudo 1 
 Não faz nada para recuperar erros encontrados, repassa com aviso ou descarta 
 
4. PRINCÍPIOS DA TRASFERÊNCIA CONFIÁVEL DE DADOS 
 Um protocolo com esta característica implementa a abstração do serviço fornecido a 
camadas superiores é um canal de dados confiável (dados não são corrompidos, nem 
perdidos, nem entregues fora de ordem), quando a camada abaixo pode não ser 
confiável! Ex: TCP é confiável, mas é implementado sobre uma camada de rede fim-a-
fim não confiável (IP)! 
 Remetente: rdt_send()  utd_send() 
 Canal não confiável 
 Destinatário: rdt_rcv()  deliver_data 
 Além de pacotes com dados, há trocas de pacotes de controle 
4.1 Construindo um protocolo de transferência confiável de dados 
 Transferência confiável de dados sobre um canal perfeitamente confiável: rdt1.0 
Remetente: 
Aceita dados da camada superior = rdt_send(data) 
Cria um pacote comos dados = make_pkt(data) 
Envia-o para o canal = udt_send(data) 
Destinatário: 
Recebe um pacote do canal subjacente = rdt_rcv(packet) 
 Transferência confiável de dados por um canal com erros de bits: rdt2.0 
Mensagens de controle: reconhecimentos positivo – ACK – e negativo –NAK – provoca 
retransmissão  protocolos ARQ (Automatic Repeat reQuest) exigem: detecção de 
erros, realimentação do destinatário (com um ACK ou com um NAK) e retransmissão. 
 Protocolo pare-e-espere (stop-and-wait) 
 ACKs ou NAKs comrrompidos? 
 - ficar pedidndo confirmações (loop infinito) 
 - bits suficientes p q a soma de verificação além de detectar, consiga recuperar 
os erros 
 - ACK ou NAK truncados reenvia o pacotepacotes duplicados, mas o 
destinatário não sabe se um pacote que chegou é um novo pacote ou se é 
retransmissão!  adiciona-se um novo campo (contendo o número de seqüência) 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 destinatário não recebeu corretamente o 
pacote seguinte equivalente aos AKCs 
 Transferência confiável 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 verificação, números de seqüência, pacotes ACKs e retransmissões 
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, difícil cálculo, a 
escolha é ponderada de um valor provável, se um ACK não chegar nesse intervalo o 
remetente retransmite 
 Possibilidade de pacotes duplicados (os números de seqüência lidam com isso) 
 Retransmissão baseada no tempo: temporizador de contagem regressiva que 
interrompa o processo remetente após ter decorrido determinado tempo 
 - aciona-se o temporizador cada vez que um pacote é enviado 
 - responde-se a uma interrupção feita pelo temporizador 
 - parar o temporizador 
 Como o número de seqüência varia entre 0 e 1  protocolo bit alternante 
4.2 Protocolos de transferência confiável de dados com paralelismo 
 O protocolo para-e-espere tem baixíssimo desempenho (estimativa = 30 
milissegundos) 
A fração de tempo em que o remetente realmente envia dados para o canal = 
(L/R)/(RTT + L/R) 
 Tempo real = capacidade de transmissão R (1 gigabit/seg) 
 Tamanho de pacote L (1 kbyte/pacote) 
Tempo de tranmissao = L/R = 8 microssegundos 
O remetente pode enviar vários pacotes sem esperar reconhecimentos  
pipelining/paralelismo 
 Paralelismo: -faixa de números de seqüência ampliada 
 -os lados remetente e destinatário precisarão reservar buffers para mais 
de um 
 -1 e 2 dependerão da maneira como um protocolo de transferência 
(pode ser GO-BAck-N ou repetição seletiva) responde a pacotes perdidos, corrompidos 
e atrasados 
4.3 Go-Back-N (GBN) 
 Remetente pode transmitir múltiplos pacotes, limitado por um n° máximo (N) de 
pacotes não reconhecidos 
 Base: n° de seqüência do mais antigo pacote não reconhecido 
 Nextseqnum: menor n° de seqüência não utilizado 
 Intervalos: [0, base-1]  pacotes já transmitidos e já reconhecidos 
 [base, nextseqnum-1]  pacotes já enviados, mas não reconhecidos 
 [nextseqnum, base+N-1]  podem ser enviados quando estiverem 
disponíveis 
 >= base+N  não 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 razões, controle de congestionamento 
também 
 O n° de seqüência é carregado num campo fixo do cabeçalho, de k bits, assim o 
intervalo de valores é [0, 2k -1] 
 O GBN responde a três tipos de eventos: 
 Chamada vinda de cima (verifica se a janela está cheia (nextseqnum<base+N), 
se não estiver, cria pacote (ajustas variáveis, tiver, nextseqnum), se estiver 
devolve p camada superior) 
 Recebimento de um ACK (o recebimento é cumulativo, até o n° de seqüência 
daquele AKC recebeu todos os pacotes corretamente) 
 Esgotamento de temporização (envia todos os pacotes que já tinham sido 
enviados, mas não tinham recebido a confirmação) (temporizador para o mais 
antigo) 
 O destinatário: enviará um ACK se todos os pacotes anteriores ao pacote 
recebido já estiverem OK, se não 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 destinatário 
 Só mantém o n° de seq do próximo pacote esperado = 
expectedseqnum 
Obs.: o GBN incorpora quase todas as técnicas da transferência de dados confiável (n° 
de seqüência, reconhecimentos cumulativos, somas de verificação, operação de 
esgotamento de temporização/retransmissão) 
4.4 Repetição seletiva (Selective Repeat - SR) 
 O GNB pode sofrer com problemas de desempenho (tamanho da janela e produto – 
atraso e largura da banda – são grandes  retransmissões desnecessárias) 
 SR faz o remetente retransmitir apenas os pacotes suspeitos de terem erros ou se 
perdido, o destinatário 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 próximo n° de seq. está na janela, 
envia/devolve 
 - Esgotamento de temporização: cada pacote tem o seu temporizador 
 - ACK recebido: marca aquele pacote, se ele for o send_base arrasta a janela 
até o menos pacote não reconhecido 
 Destinatário: 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 destinatário, 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 necessário porque a janela do remetente poderia 
ficar fixa 
 - Qualquer outro: é ignorado 
 A falta de sincronização entre as janelas do remetente e destinatário tem 
conseqüências para faixa finita de números de seqüência (o tamanho da janela pode 
ser <= tamanho do espaço de numeração seqüencial/2) 
 Os pacotes tem tempo de vida máximos (3 min) para não ressurgirem e ficar no lugar 
de outro por causa do n° de seqüência. 
 
5. TRANSPORTE ORIENTADO PARA CONEXÃO: TCP 
O TCP inclui detecção de erro, retransmissão, reconhecimento cumulativo, 
temporizadores, campos de cabeçalho para n° de seqüência e de reconhecimento. 
5.1 A conexão TCP 
 Orientado para conexão porque há apresentação! Iniciam variáveis de estado nessa 
conexão 
 O protocolo roda apenas nos sistemas finais, assim os elementos intermediários não 
armazenam estados de conexão TCP 
 Prove um serviço full-duplex (numa mesma conexão ambos os sentidos, envia e 
recebe) 
 É sempre ponto-a-ponto (um único remetente e um único destinatário) x multicast 
 Processo que inicia a conexão é o processo cliente, o outro é processo servidor. A 
aplicação informa a camada transporte que deseja estabelecer a conexão (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 aplicação) = apresentação de três vias! 
 Estabelecida a conexão TCP, dados passam pelo socket e estão nas mãos do TCP, 
que os direciona para o buffer de envio, a quantidade máxima a ser retira é limitada pelo 
tamanho máximo do segmento // não é o tamanho máximo do segmento TCP, mas dos 
dados // (MSS – estabelecido pelo tamanho domaior quadro de camada de enlace que 
pode ser enviado - MTU) 
 O TCP combina: dados fornecidos do cliente com um cabeçalho TCP  segmentos 
TCP e extrai: os dados do segmento armazenando-os no buffer de recepção (a 
aplicação lê) 
 TCP consiste em: buffers, variáveis e um socket de conexão em cada hospedeiro 
5.2 Estrutura do segmento TCP 
 Campo de dados: vêm da aplicação, tamanho limitado pelo MSS (o TCP pode 
fragmentar os dados em vários MSSs) 
 Campo decabeçalho: geralmente 20 bytes, inclui: n° de porta de fonte e de destino, 
campo de soma de verificação, campo de n° de seqüência (32 bits, serv. conf.), n° de 
reconhecimento (32 bits, serv. conf.), janela de recepção (16 bits, cont, fluxo), 
comprimento de cabeçalho (4 bits, quantas palavras de 32 bits),campo opções do TCP 
(pode variar, mas normalmente é vazio, negociação do MSS, tempo ou janela), campo 
flag (6 bits, ACK, RST, SYN, FIN, PSH, URG) 
 Números de seqüência e números de reconhecimento 
 Fundamentais para o serviço de transferência confiável de dados do TCP 
 TCP vê os dados como uma cadeia de dados não estruturada, mas ordenada 
(numera cada byte da cedia de dados) 
 N° de seqüência = n° do primeiro byte do segmento 
 N° de reconhecimento = o n° de reconhecimento que o hospedeiro A atribui a seu 
segmento é o n° de seqüência do próximo 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 implementação TCP, porque não há nada definido (na pratica, armazena-
se) 
 Telnet: um estudo de caso para números de seqüência e números de 
reconhecimento 
 Hoje, prefere-se ssh, porque o telnet não utiliza criptografia 
 TCP usa piggypack (carona) uma confirmação é feita junta de um segmento de 
dados 
5.3 Estimativas do tempo de viagem de ida e volta e de esgotamento de temporização 
 O TCP usa um mecanismo de controle de temporização/retransmissão para 
recuperar segmentos perdidos 
 Duração 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 IP) (s/ retransmissão)e o momento em que é recebido 
um reconhecimento. O TCP fica calculando, variações ocorrem, calcula uma média 
(móvel exponencial) ponderada 
 EstimatedRTT = (1-alfa)*EstimadedRTT + alfa*SampleRTT (alfa = 0,125 = 1/8) 
 DevRTT (variação RTT) = (1 - beta)*DevRTT + beta*|SampleRTT–EstimatedRTT| 
(beta=0,25) 
Obs.: TCP usa NAK implícito = três ACKs duplicados e paralelismo (o n° máximo de 
segmentos não reconhecidos é determinado pelos mecanismos de controle de fluxo e 
de congestionamento) 
 Estabelecimento e gerenciamento da temporização e retransmissão 
 EstimatedRTT + margem (proporcional ao DevRTT) 
 TimeoutInterval = EstimatedRTT + 4*DevRTT 
5.4 Transferência confiável de dados 
 Com o serviço IP os datagramas podem ser perdidos, chegar fora de ordem, ser 
corrompidos 
 O TCP cria um serviço de transferência confiável de dados sobre este serviço de 
melhor esforço do IP, e garante que a cadeia de dados que a aplicação lê a partir do 
seu buffer de recebimento TCP não está corrompida, não tem lacuna, não tem 
duplicação e está em ordem! 
 Temporizador para cada segmento pode exigir sobrecarga, usa-se um único 
temporizador de retransmissão! 
1) Usa apenas temporizadores para retransmissão 
2) Usa temporizadores e reconhecimentos duplicados 
 Eventos no remetente: 
 - dados recebidos da aplicação acima (se o temporizador não 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 cenários interessantes 
1) ACK perdido, haverá reenvio (quando o temporizador esgotar), o destinatário 
receberá dado duplicado, descartará e reenviará o ACK 
2) Remetente envia dois segmentos seguidos, o destinatário 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 não será retransmitido! 
3) Remetente envia dois segmentos seguidos, o destinatário recebe e envia dois 
ACKs, o primeiro é perdido, se o segundo chegar antes do tempo esgotar não 
haverá reenvio! 
 Duplicação do tempo de expiração 
 Quando o tempo é esgotado o TCP reenvia o pacote com menos n° de seqüência e 
ajusta o tempo de expiração para o dobro de tempo do anterior. O tempo aumenta 
exponencialmente a cada expiração. A causa mais provável da expiração é o 
congestionamento  o TCP demorará mais para retransmitir 
 Mas quando o temporizador é iniciado por ter recebido dados da aplicação ou ACK o 
TimeoutInterval é derivado dos valores de EstimatedRTT e DevRTT 
 Retransmissão rápida 
 O remetente pode detectar a perda de um pacote antes do timeout (pode demorar 
muito) analisando os ACKs duplicados 
Evento Ação do TCP destinatário 
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 
começar na extremidade mais baixa 
 Se o remetente receber três ACKs duplicados é indicação que o segmento posterior 
ao segmento reconhecido três vezes foi perdido e o TCP remetente realiza uma 
retransmissão rápida, antes que o temporizador expire 
 GBN ou repetição seletiva? 
 Semelhanças c GNB: reconhecimento cumulativo e segmentos fora de ordem 
corretamente recebidos não são reconhecidos individualmente, só precisa lembrar o 
menor n° de seqüência não reconhecido e o n° de seqüência do byte a ser enviado 
 Diferenças 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! 
 Semelhança c SR: o reconhecimento seletivo permite que o TCP reconheça 
seletivamente segmentos fora de ordem 
 O mecanismo de recuperação de erros do TCP é hibrido dos protocolos GNB e SR 
5.5 Controle de fluxo 
 Hospedeiros de cada lado de uma conexão TCP reservam um buffer de recepção, 
quando os bytes estão corretos e na seqüência são colocados neste buffer e a 
aplicação lerá daí, isso pode demorar e, assim, o buffer pode ser saturado, para evitar 
isso o TCP tem o controle de fluxo 
 É um serviço de compatibilização de velocidades (taxas de envio e q aplicação 
receptora lê) 
 Controles de fluxo e de congestionamento regulam o remetente, mas têm propósitos 
distintos 
 Remetente mantém uma variável, janela de recepção (RcvWindow), que dá uma 
idéia do espaço de buffer disponível no destinatário 
 O receptor aloca um buffer de recepção com o tamanho RcvBuffer 
 Variáveis no destinatário: 
 - LastByteRead = n° do último byte lido do buffer pela aplicação do receptor 
 - LastByteRcvd = n° do último byte que chegou no buffer do receptor 
 Variáveis no remetente: 
- LastByteSent 
- LastByteAcked 
 Deve-se ter: LastByteRcvd – LastByteRead <= RcvBuffer 
 RcvWindow = RcvBuffer – (LastByteRcvd – LastByteRead) 
 LastByteSent – LastByteAcked <= RcvWindow 
 Processo: remetente diz ao destinatário qual o espaço do seu buffer colocando 
RcvWindow no campo de janela de recepção, inicialmente o destinatário estabeleceRcvWindow = RcvBuffer 
 Problema: quando a RcvWindow for igual a 0  mesmo que o processo com 
aplicação esvazie o buffer o remetente não saberá disso porque o TCP não 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 recepção for 0! 
5.6 Gerenciamento da conexão TCP 
 O estabelecimento da conexão tem pesa nos atrasos. O estabelecimento: o processo 
cliente informa ao TCP cliente que quer estabelecer uma conexão com um processo 
servidor, o TCP faz 
 - lado cliente do TCP envia um segmento especial (sem dados da aplicação, o 
bit SYN é ativado) ao lado servidor do TCP e escolhe um n° de seq. inicial (client_isn) já 
indicando no cabeçalho deste segmento, chamado SYN 
 - o servidor, quando receber o SYN, alocará buffers e variáveis TCP para esta 
conexão e envia segmento de aceitação (sem dados, SYN ativado, campo de 
reconhecimento = client_isn + 1, server_isn), este segmento é chamado de SYNACK 
 - o cliente reserva buffers e variáveis e envia mais um segmento (campo de 
reconhecimento = server_isn + 1, SYN desativado, pode conter dados) 
 Essa é a apresentação de três vias 
 Qualquer um do hospedeiros podem encerrar a conexão, que quando acaba libera 
as variáveis e os buffers 
 - o processo que deseja encerrar envia um segmento (FIN ativado) 
 - o outro hospedeiro emite uma confirmação ACK 
 - esse mesmo hospedeiro envia outro segmento com FIN ativado 
 - o outro hospedeiro (que iniciou o fechamento da conexão) envia um ACK 
 Estados do TCP 
 Cliente = CLOSED  (inicia uma nova conexão 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 conexão  envia 
segmento FIN  FIN_WAIT_1  recebe ACK  FIN_WAIT_2  recebe 
segmento FIN e envia ACK  TIME_WAIT  reenvia o ACK final se tiver sido 
perdido (tempo 30, 60 ou 120 seg) 
 Servidor = CLOSED  aplicação cria uma porta de escuta  LISTEN  recebe 
SYN e envia SYNACK  SYN_RCVD (recebe ACK, não envia nada)  
ESTABILISHED  recebe FIN, envia ACK  CLOSE_WAIT  envia FIN  
LAST_ACK  recebe ACK 
 
6. PRINCÍCPIOS DE CONTROLE DE CONGESTIONAMENTO 
 Causa: demasiadas fontes tentando enviar dados a uma taxa muito alta, 
mecanismos para regular os remetentes 
6.1 As causas e os custos do congestionamento 
 Cenário 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 média de λin bytes/seg.. O protocolo de transporte não tem 
recuperação 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 saída compartilhado de 
capacidade R. A vazão por conexão é igual a λin desde que λin seja <= R/2, quando 
maior a vazão é igual a R/2, entretanto quando se trabalha com taxas próximas a 
capacidade máxima da rede, o atraso médio fica cada vez maior e tende ao infinito 
(bom para vazão, péssimo 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. 
 Cenário 2: dois remetentes, um roteador com buffers finitos 
 Há descarte de pacotes quando o buffer já está cheio, mas há retransmissão dessas 
perdas, assim a taxa de envio da aplicação 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 retransmissões, se λin` = R/2  λout = R/3 
 Custo da rede congestionada: remetente deve realizar retransmissões para 
compensar os pacotes perdidos devido ao esgotamento do buffer 
 Caso em que não houve perda, apenas atraso, mas há retransmissão: trabalho 
desperdiçado 
 Custo da rede congestionada: retransmissões desnecessárias 
 Cenário 3: quatro remetentes, roteadores c buffers finitos, trajetos c múltiplos 
roteadores 
 Para valores pequenos de λin os valores de λout acompanham 
 Situação em que um roteador deve dividir entre uma conexão direta – com alta taxa 
– e outra conexão 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 desperdício da transmissão já 
utilizada 
6.2 Mecanismos de controle de congestionamento 
 Distinção: a camada de rede oferece ou não assistência ao controle explicita à de 
transporte 
- controle de congestionamento fim-a-fim: não há assistência (nem indica se há) da 
camada de rede (IP), a perda de segmentos TCP (temporização, 3 ACKs duplicados) 
indicam o congestionamento (usa também o aumento dos atrasos de ida e volta), reduz-
se a janela 
- controle de congestionamento assistido pela rede: os roteadores fornecem 
informações ao remetente sobre o estado de congestionamento da rede (pode ser 
simples). Realimentação direta: pacote de congestionamento ou marcação em um 
pacote que está fluindo para o destinatário leva pelo menos uma viagem de ida e volta. 
 
7. CONTROLE DE CONGESTIONAMENTO TCP 
 Usa controle de congestionamento fim-a-fim 
 Obriga cada remetente a limitar a sua taxa de envio como uma função do 
congestionamento de rede percebido (Como o remetente limita? Como percebe? Qual o 
algoritmo dessa função?) 
 Contexto do algoritmo Reno 
 Variável adicional nos hospedeiros: janela de congestionamento (CongWin), 
limitação a taxa de envio de um remetente, deve-se ter: 
 LastByteSent – LastByteAcked <= min (CongWin, RcvWindow) 
 Análise desprezando a limitação da janela de recepção 
 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 estão chegando corretamente (através dos 
reconhecimentos) aumenta o CongWin  TCP é auto-regulado 
 Algoritmo de controle do congestionamento do TCP (tem três componentes): 
 Aumento aditivo, diminuição multiplicativa 
 Idéia básica: remetente reduzir taxa de envio (reduzindo CongWin) se há perda 
 Reduz à metade o valor de CongWin após um evento de perda (valor mínimo = 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 é prevenção de 
congestionamento 
 Partida lenta 
 No inicio de uma conexão TCP, CongWin = 1 MSS, taxa inicial de envio = MSS/RTT 
 Esperar um crescimento considerável de CongWin demoraria muito, assim, na fase 
inicial ao invés 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 
 Reação a eventos de esgotamento de temporização 
 TCP reage diferente a eventos de perda detectados por ACKs ou pela temporização 
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é alcançar metade do valor que tinha antes do evento de 
esgotamento e passa a crescer linearmente) 
 Para isso o TCP mantém a variável Threshold indica onde a partida lenta terminará 
(não tem efeito inicial, ajustada com alto valor) recebe metade do valor de quando 
ocorreu o esgotamento 
Obs.: o Tahoe (versão antiga) cortava sempre para 1 MSS. Reno considera que se há 
ACK algum segmento chegou! (eliminaçãoda partida lenta após três ACKs = 
recuperação rápida) 
 Descrição macroscópica da dinâmica do TCP 
Tamanho da janela = w bytes 
Tempo de viagem de ida e volta = RTT 
Taxa de transmissão ~= w/RTT 
W = w quando ocorre uma perda 
Taxa de transmissão ~= W/2*RTT, W/RTT 
Vazão média de uma conexão = 0,75*W/RTT 
 TCPs futuros 
L = taxa de perda 
Vazão média de uma conexão = 1,22*MSS/ (RTT * raiz(L)) 
7.1 Justiça 
Um mecanismo de controle de congestionamento é justo se a taxa média de trasmissao 
de cada conexão for = taxa de transmissão do enlace/n° de conexões TCP 
 TCP resulta em igual compartilhamento da largura de banda, as sessões cujos RTTs 
são menores conseguem obter largura da banda disponível mais rapidamente 
 Justiça e UDP 
 UDP usa uma taxa constante e ocasionalmente perde pacotes 
 Busca-se desenvolver mecanismos que impeçam que segmentos UDPs dominem o 
tráfego 
 Justiça e conexões TCP paralelas 
 Mesmo controlando o UDP, nada impede que uma aplicação rode sobre TCPs 
paralelos 
7.2 Modelagem do atraso TCP 
 Tempo para o TCP enviar um objeto (consideramos uma rede n congestionada e c 1 
enlace) 
 Latência: tempo que o cliente inicia uma conexão e recebe o objeto completo 
(componentes fundamentais: apresentação inicial do TCP, a partida lenta e o tempo de 
transmissão do objeto) 
 Considerações: 
 - quantidade de dados a serem transmitidos limitada só pela janela de cong. 
remetente 
 - pacotes não perdido, nem corrompidos, não há retransmissão 
 - sobrecargas de cabeçalhos desprezadas 
 - o tamanho do objeto (O bits) é um múltiplo do MSS (S bits) 
 - pacotes sem tempo de transmissão n desprezíveis: segmentos TCP tamanho 
máximo 
 - taxa de transmissão do enlace R bps 
 Sem janela  latência = 2 RTT + O/R 
 Janela de congestionamento estática 
 TCP usa dinâmica 
 Tamanho da janela = W (servidor não pode ter mais que W segmentos não 
reconhecidos) 
1) WS/R > RTT + S/R  servidor recebe reconhecimento antes de completar o envio da 
janela; latência = 2RTT + O/R 
2) WS/R > RTT + S/R  envia a janela toda antes de receber um reconhecimento 
K = O/WS 
Duração de cada período de suspensão = RTT – (W – 1)S/R 
Latência = 2RTT + O/R + (K - 1) [S/R + RTT – WS/R] 
 Janela de congestionamento dinâmica 
 A cada reconhecimento o servidor duplica o tamanho da janela 
 A k-ésima janela contém: 2k-1segmentos 
 K (número de janelas que abrangem o objeto) = teto (log2((O/S) + 1)) 
 Tempo de suspensão = min ([S/R + RTT - 2k-1 (S/R)], 0 ) 
 Latência = 2 RTT + O/R + Somatório[k=1, k-1] (S/R + RTT - 2k-1S/R)+ 
 N° de vezes que entra em suspensão //Q = chão (log2(1 + RTT/(S/R))) + 1// (P) = 
min (Q, K-1) 
 Latência = 2 RTT + O/R + P[S/R + RTT] – (2p –1) S/R 
Obs.: a partida lenta não aumentara de maneira significativa a latência se RTT << O/R; 
para RTT maiores o efeito da partida lenta torna-se significativo para objetos pequenos 
para velocidades de transmissões menores