REDES DE COMPUTADORES

Transcrição

1 unesp UNIVERSIDADE ESTADUAL PAULISTA REDES DE COMPUTADORES Anotações de Aula e Slides Capítulo 3 Camada de Transporte Adriano Mauro Cansian adriano@unesp.br São José do Rio Preto Bacharelado em Ciências da Computação MMIV

2 Prefácio 2004 Este é o material didático contendo a coleção de slides e notas de aula do Curso de Redes de Computadores para o primeiro semestre de 2004, na UNESP Universidade Estadual Paulista, Campus de São José do Rio Preto, sob responsabilidade do Professor Adriano Mauro Cansian. Este material NÃO substitui o livro texto adotado no curso, devendo ser usado de modo a complementa-lo, e em conjunto com outras referências recomendadas. As referências bibliográficas adotadas ou recomendadas para este curso podem ser consultadas em A principal função destas notas de aula é facilitar a realização das anotações dos tópicos mais importantes discutidos em sala de aula, agilizando assim o andamento do curso para os alunos. Estas notas de aula podem diferir ligeiramente do material usado pelo professor durante a aula em sala. Isso porque o professor muitas vezes acaba inserindo outros materiais de última hora, para melhorar a qualidade e atualizar o material, visand sempre a melhor expressão dos temas aos alunos. Portanto, é fortemente recomendável que os alunos tenham este material de aula em mãos durante a aula, de forma a fazer anotações, inserções e correções conforme necessário. A primeira versão foi utilizada no primeiro semestre de Esta é a sexta versão, a qual novamente está passando por correções, aprimoramentos de texto e de figuras, além de atualização e inserção de novos tópicos. Algumas imperfeições podem estar presentes nos textos. Sugestões e apontamentos de falhas podem ser enviadas diretamente ao autor. Este material tem finalidade meramente educacional e é totalmente GRATUITO. Estas notas de aula podem conter figuras ou textos extraídos de outras fontes, as quais, quando ocorrerem, serão devidamente citadas. Os direitos autorais dos textos citados são de propriedade de seus detentores. Esta não é uma obra comercial. A citação ou uso de material de outros autores, quando ocorrer, tem finalidade meramente didática. Nem o autor, nem a UNESP, se responsabilizam por quaisquer danos diretos ou indiretos que o uso deste material possa eventualmente causar. Este material pode ser copiado livremente, desde que citadas todas as fontes, e respeitados os detentores dos direitos autorais, e desde que o material seja distribuído por inteiro e não em partes, inclusive com os prefácios. A referência a qualquer produto comercial específico, marca, modelo, estabelecimento comercial, processo ou serviço, através de nome comercial, marca registrada, nome de fabricante, fornecedor, ou nome de empresa, necessariamente NÃO constitui ou insinua seu endosso, recomendação, ou favorecimento por parte da UNESP ou do autor. A UNESP ou o autor não endossam ou recomendam marcas, produtos, estabelecimentos comerciais, serviços ou fornecedores de quaisquer espécies, em nenhuma hipótese. As eventuais marcas e patentes mencionadas são de propriedade exclusiva dos detentores originais dos seus direitos e, quando citadas, aparecem meramente em caráter informativo, para auxiliar os participantes do curso, numa base de boa-fé pública. Os participantes ou outros interessados devem utilizar estas informações por sua conta e risco, e estarem cientes desta notificação. Este material didático não se trata de uma publicação oficial da UNESP. Seu conteúdo não foi examinado ou editado por esta instituição. As opiniões refletem a posição do autor. São José do Rio Preto, SP - 28 de março de Adriano Mauro Cansian ii

3 Créditos Estes slides para notas de aula são, em sua grande parte, baseadas nos livros textos adotados para o curso no ano de 2004: Computer Networking: A Top-Down Approach Featuring the Internet James F. Kurose & Keith W. Ross (ISBN: ), Editora Addison Wesley Longman, e Computer Networks, 3th Edition, de Andrew S. Tanenbaum Prentice-Hall (ISBN ) e em sua tradução Redes de Computadores Terceira Edição, da Editora Campus (ISBN ). Para informações mais detalhadas sobre a bibliografia do curso, bem como outras referências utilizadas, consulte Copyright (c) ADRIANO MAURO CANSIAN. É dada permissão para copiar, distribuir e/ou modificar este documento sob os termos da Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior publicada pela FREE SOFTWARE FOUNDATION em SEM Seções Invariantes, com os Textos da Capa da Frente sendo Curso de Redes de Computadores Prof. Adriano Mauro Cansian, e com os textos da quarta-capa sendo as páginas numeradas de ii até v deste documento. Contato: Adriano Mauro Cansian Professor Assistente Doutor adriano@acmesecurity.org / adriano@unesp.br / adriano@ieee.org UNESP - Universidade Estadual Paulista Campus de São José do Rio Preto Depto. de Ciência da Computação e Estatística Laboratório ACME! de Pesquisa em Segurança de Computadores e Redes Endereço: R. Cristóvão Colombo, Jd. Nazareth * São José do Rio Preto, SP. Tel. (17) (laboratório) / (secretaria) Chave PGP: Adriano Mauro Cansian <adriano@unesp.br> Key ID: 0x3893CD2B Key Type: DH/DSS Key Fingerprint: C499 85ED 355E 774E A B834 B CD2B iii

4 ACME! STANDARD DISCLAIMER Please, read carefully. This ACME! product is meant for educational purposes only. Any resemblance to real persons, living or dead is purely coincidental. Void where prohibited. Some assembly required. List each check separately by bank number. Batteries not included. Contents may settle during shipment. Use only as directed. No other warranty expressed or implied. Do not use ACME! while operating a motor vehicle or heavy equipment. Postage will be paid by addressee. Subject to CAB approval. This is not an offer to sell securities. Apply only to affected area. ACME! may be too intense for some viewers. Do not stamp. Use other side for additional listings. For recreational use only. Do not disturb. All models over 18 years of age. If condition persists, consult your physician. No user-serviceable parts inside. Freshest if eaten before date on carton. Subject to change without notice. Times approximate. Simulated picture. No postage necessary if mailed in the United States. Breaking seal constitutes acceptance of agreement. For off-road use only. As seen on TV. One size fits all. Many suitcases look alike. Contains a substantial amount of non-tobacco ingredients. Colors may, in time, fade. We have sent the forms which seem right for you. Slippery when wet. For office use only. ACME! Research is not affiliated with the American Red Cross. Drop in any mailbox. Edited for television. Keep cool; process promptly. Post office will not deliver without postage. List was current at time of printing. Return to sender, no forwarding order on file, unable to forward. ACME! is not responsible for direct, indirect, incidental or consequential damages resulting from any defect, error or failure to perform. At participating locations only. Not the Beatles. Penalty for private use. See label for sequence. Substantial penalty for early withdrawal. Do not write below this line. Falling rock. Lost ticket pays maximum rate. Your canceled check is your receipt. Add toner. Place stamp here. Avoid contact with skin. Sanitized for your protection. Be sure each item is properly endorsed. Sign here without admitting guilt. Slightly higher west of the Mississippi. Employees and their families are not eligible. Beware of dog. Contestants have been briefed on some questions before the show. Limited time offer, call now to ensure prompt delivery. You must be present to win. No passes accepted for this engagement. No purchase ecessary. Processed at location stamped in code at top of carton. Shading within a garment may occur. Use only in a well-ventilated are. Keep ACME! away from fire or flames. Replace with same type. Approved for veterans. Booths for two or more. Check here if tax deductible. Some equipment shown is optional. Price does not include taxes. No Canadian coins. Not recommended for children. Prerecorded for this time zone. Reproduction strictly prohibited. No solicitors. No alcohol, dogs or horses. No anchovies unless otherwise specified. Restaurant package, not for resale. List at least two alternate dates. First pull up, then pull down. Call ACME! toll free before digging. Driver does not carry cash. Some of the trademarks mentioned in this product appear for identification purposes only. Record additional transactions on back of previous stub. Unix is a registered trademark of AT&T. Do not fold, spindle or mutilate. No transfers issued until the bus comes to a complete stop. Package sold by weight, not volume. Your mileage may vary. This article does not reflect the thoughts or opinions of either myself, my company, my friends, or my cat. Don't quote me on that. Don't quote me on anything. All rights reserved. You may distribute this article freely but you may not take a profit from it. Terms are subject to change without notice. Illustrations are slightly enlarged to show detail. Any resemblance to actual persons, living or dead, is unintentional and purely coincidental. Do not remove this disclaimer under penalty of law. Hand wash only, tumble dry on low heat. Do not bend, fold, mutilate, or spindle. No substitutions allowed. For a limited time only. This ACME! article is void where prohibited, taxed, or otherwise restricted. Caveat emptor. Article is provided "as is" without any warranties. Reader assumes full responsibility. An equal opportunity article. No shoes, no shirt, no articles. Quantities are limited while supplies last. If any defects are discovered, do not attempt to read them yourself, but return to an authorized service center. Read at your own risk. Parental advisory - explicit lyrics. Text may contain explicit materials some readers may find objectionable, parental guidance is advised. Keep away from sunlight. Keep away from pets and small children. Limit one-per-family please. No money down. No purchase necessary. You need not be present to win. Some assembly required. Batteries not included. Instructions are included. Action figures sold separately. No preservatives added. Slippery when wet. Safety goggles may be required during use. Sealed for your protection, do not read if safety seal is broken. Call before you dig. Not liable for damages arising from use or misuse. For external use only. If rash, irritation, redness, or swelling develops, discontinue reading. Read only with proper ventilation. Avoid extreme temperatures and store in a cool dry place. Keep away from open flames. Avoid contact with eyes and skin and avoid inhaling fumes. Do not puncture, incinerate, or store above 120 degrees Fahrenheit. Do not place near a flammable or magnetic source. Smoking this article could be hazardous to your health. The best safeguard, second only to abstinence, is the use of a condom. No salt, MSG, artificial color or flavoring added. If ingested, do not induce vomiting, and if symptoms persist,consult a physician. Warning: Pregnant women, the elderly, and children should avoid prolonged exposure to ACME! Caution: ACME! may suddenly accelerate to dangerous speeds. ACME! contains a liquid core, which if exposed due to rupture should not be touched, inhaled, or looked at. Do not use ACME! on concrete. Discontinute use of ACME! if any of the following occurs: Itching, Vertigo, Dizziness, Tingling in extremities, Loss of balance or coordination, Slurred speech, Temporary blindness, Profuse Sweating, or Heart palpitations. If ACME! begins to smoke, get away immediately, seek shelter and cover head. ACME! may stick to certain types of skin. When not in use, ACME! should be returned to its special container and kept under refrigeration. Failure to do so relieves the makers of ACME!, ACME! Products Incorporated, and it's parent company, ACME! Chemical Unlimited, of any and all liability. Ingredients of ACME! include an unknown glowing substance which fell to Earth, presumably from outer space. ACME! has been shipped to troops in Saudi Arabia and is also being dropped by warplanes on Iraq. Do not taunt ACME! May cause any of the aforementioned effects and/or death. Articles are ribbed for your pleasure. Possible penalties for early withdrawal. Offer valid only at participating sites. Slightly higher west of the Rockies. Allow four to six weeks for delivery. Must be 18 to read. Disclaimer does not cover misuse, accident, lightning, flood, tornado, tsunami, volcanic eruption, earthquake, hurricanes and other Acts of God, neglect, damage from improper reading, incorrect line voltage, improper or unauthorized reading, broken antenna or marred cabinet, missing or altered serial numbers, electromagnetic radiation from nuclear blasts, sonic boom vibrations, customer adjustments that are not covered in this list, and incidents owing to an airplane crash, ship sinking or taking on water, motor vehicle crashing, dropping the item, falling rocks, leaky roof, broken glass, mud slides, forest fire, or projectile (which can include, put not be limited to, arrows, bullets, shot, BB's, shrapnel, lasers, napalm, torpedoes, or emissions of X-rays, Alpha, Beta and Gamma rays, knives, stones, etc.). Other restrictions may apply. This supersedes all previous notices. The ACME! Computer Security Research. iv

5 So you run and you run to catch up with the sun but it's sinking Racing around to come up behind you again. The sun is the same in a relative way but you're older, Shorter of breath and one day closer to death. Time Pink Floyd, in Dark Side of the Moon album v

6 Curso de Redes de Computadores Adriano Mauro Cansian ieee.org Capítulo 3 Camada de Transporte 1 Capítulo 3: Camada de Transporte Metas do capítulo: Compreender os princípios por trás dos serviços da camada de transporte: Multiplexação/ desmultiplexação. Transferência confiável de dados. Controle de fluxo. Controle de congestionamento. Instanciação e implementação na Internet. O que veremos: Serviços da camada de transporte. Multiplexação/desmultiplexação. Transporte sem conexão: UDP. Princípios de transferência confiável de dados. Transporte orientado a conexão: TCP Transferência confiável Controle de fluxo Gerenciamento de conexões Princípios de controle de congestionamento. Controle de congestionamento em TCP. 2 Comparação entre as camadas Camada de transporte repousa exatamente a camada de. Protocolo da Camada de Transporte fornece comunicação lógica entre processos, rodando em hosts diferentes. Protocolo da Camada de Rede fornece comunicação lógica entre hosts. Esta distinção é sutil, mas MUITO importante! Camada de Transporte X Camada de Rede (1) Considere 12 irmãos numa casa em São Paulo. E outros 12 irmãos em outra casa em Boa Vista no Acre. Os de SP são primos daqueles em Boa Vista, e escrevem uns para os outros semanalmente. Em São Paulo, João recolhe as cartas dos irmãos e as entrega ao correio. No Acre, Maria recolhe as cartas dos irmãos, e as entrega ao correio. Ambos também fazem a distribuição local do que chega. 3 4 Camada de Transporte X Camada de Rede (2) Serviços e protocolos de TRANSPORTE (1) Hosts (end systems) = Casas. Processos = os primos que trocam mensagens. Mensagens da = cartas em envelopes. Protocolo da camada de = serviço postal (correio). Protocolo da Camada de Transporte = João e Maria. Provê comunicação lógica entre processos de executando em hospedeiros diferentes. Protocolos de transporte executam em sistemas finais. Serviços das camadas de transporte versus : Camada de : dados transferidos entre sistemas. Camada de transporte: dados transferidos entre processos. transporte transporte lógico fim a fim transporte 5 6 Prof. Dr. Adriano Mauro Cansian 1

7 Serviços e protocolos de TRANSPORTE (2) Protocolos da camada de transporte (1) Do ponto de vista da APLICAÇÃO a camada de transporte permite enxergar os sistemas como se eles estivessem fisicamente conectados. Mesmo que existam vários roteadores, links e outros equipamentos no caminho. A Camada de Aplicação não tem que se preocupar com os detalhes físicos da infra-estrutura de interligação, usada para carregar as mensagens. Como já foi dito: Protocolos de transporte são implementados nos sistemas de extremidade (end systems) ) e não nos roteadores intermediários. TRANSPORTE: Camada 4, superior à camada de. transporte transporte lógico fim a fim transporte 7 8 Protocolos da camada de transporte (2) Serviços de transporte na Internet: Entrega confiável,, ordenada, ponto a ponto (TCP) Congestionamento. Controle de fluxo. Estabelecimento de conexão (setup). Entrega não confiável, ( melhor esforço ), não ordenada, ponto a ponto ou multiponto: : UDP. Serviços não disponíveis: Tempo-real. Garantias de banda. Multiponto confiável. transporte transporte lógico fim a fim transporte 9 Multiplexação/desmultiplexação (1) MULTIPLEXAÇÃO: Juntar dados de múltiplos processos de aplicações, envelopando dados com cabeçalho (usado depois para desmultiplexação). DESMULTIPLEXAÇÃO: entrega de segmentos recebidos para os processos da camada de corretos. receptor P3 P4 dados da camada de cabeçalho P1 de segmento M segmento Ht M transporte Hn segmento M M transporte M transporte 10 P2 Multiplexação/desmultiplexação (2) Multiplexação/desmultiplexação (3) Segmento - Unidade de dados trocada entre entidades da camada de transporte. Chamado de TPDU: (Transport( protocol Data Unit) ou 4-PDU (PDU da camada 4) dados da camada de cabeçalho P1 de segmento M segmento Ht M transporte Hn segmento P3 receptor M M transporte P4 M P2 transporte Multiplexação/desmultiplexação: Baseadas em números de porta e endereços IP de remetente e receptor: Números de porta de remetente/receptor são enviados em cada segmento. Número de porta são bem conhecido para aplicações específicas (WKS): na porta 25, telnet na porta 23, http na porta 80, e assim por diante. porta remetente 32 bits outros campos do cabeçalho dados da (mensagem) porta receptor formato de segmento TCP/UDP Prof. Dr. Adriano Mauro Cansian 2

8 Multiplexação/desmultiplexação: exemplos UDP: User Datagram Protocol [RFC 768] estação A porta orig.: x porta dest: 23 porta orig:23 porta dest: x uso de portas: apl. simples de telnet Cliente WWW estação A servidor B IP orig: A IP dest: B porta orig: x porta dest: 80 IP orig : C IP dest: B porta orig: y porta dest: 80 Web client host C IP orig: C IP dest: B porta orig: x porta dest: 80 servidor WWW B Uso de portas : servidor WWW Protocolo de transporte da Internet mínimo, sem frescura :-) Serviço melhor esforço, resulta que segmentos UDP podem ser: Perdidos. Entregues à fora de ordem de envio. Sem conexão: Não há setup setup UDP entre remetente e receptor. Tratamento independente de cada segmento UDP. 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 no remetente/receptor. Pequeno cabeçalho de segmento. Mais simples. Sem controle de congestionamento: : UDP pode transmitir o mais rápido possível Mais sobre UDP Muito utilizado para aplicações de meios contínuos (voz, vídeo) São tolerantes a perdas. São sensíveis à taxa de transmissão. Outros usos de UDP (?): DNS (servidor de nomes). SNMP (gerenciamento). Transferência confiável com UDP: deve incluir confiabilidade na camada de. Recuperação de erro específica à! Comprimento em bytes do segmento UDP, incluindo cabeçalho porta origem comprimento 32 bits Dados de (mensagem) porta dest. checksum Formato de um sgmento UDP 15 Checksum UDP Remetente: 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. Remetente coloca complemento do valor da soma no campo checksum de UDP. Meta: detectar erro (e.g., bits invertidos) no segmento transmitido. Receptor: Computa checksum do segmento recebido Verifica se checksum computado é zero: NÃO - erro detectado. SIM - nenhum erro detectado. Mas ainda pode ter erros? (Veremos mais adiante.) 16 Exemplo de cálculo do checksum (1) Considere 3 palavras de 16 bits sendo transmitidas: A soma das duas primeiras palavras é: Adicionando a terceira palavra, a soma acima fica: Ver RFC-1071! Os complementos de 1 são obtidos convertendo todos os 0 s para 1 s, e todos os 1 s para 0 s. 17 Exemplo de cálculo do checksum (2) Assim o complemento de 1's da soma é Este valor se torna o checksum. No receptor, todas as palavras de 16 bits são somadas, incluindo o checksum. Se não foram introduzidos erros no pacote, a soma no receptor certamente deverá resultar em Se um dos bits for zero, então algum erro foi introduzido no pacote. Pergunta para casa: Por que o UDP usa checksum, se a maioria dos protocolos data-link (inferiores), incluindo o popular Ethernet, também fornece verificação de erro?? 18 Prof. Dr. Adriano Mauro Cansian 3

9 Princípios de Transferência confiável de dados Reliable Data Transfer (RDT) Importante nas camadas de transporte, No topo da lista dos 10 tópicos mais importantes em s! Transferência confiável de dados (RDT): como começar rdt_send(): chamada de cima, (pela apl.). Dados recebidos para entregar à camada sup. do receptor. deliver_data(): chamada por rdt para entregar dados para camada superior. send side receive side Características do canal não confiável determinam a complexidade de um protocolo de transferência confiável de dados (RDT). 19 udt_send(): chamada por ambos os lados para troca de pacotes de controle. UDT representa um unreliable data transfer. rdt_rcv(): chamada quando pacote chega no lado receptor do canal. 20 Transferência confiável de dados (rdt( rdt): como começar Iremos: Desenvolver incrementalmente os lados remetente e receptor do protocolo confiável RDT. Considerar apenas fluxo unidirecional de dados Mas a informação de controle flui em ambos sentidos! Usar máquinas de estados finitos (FSM - Finite State Machine) ) para especificar remetente e receptor. Rdt1.0: transferência confiável usando um canal confiável Suposição: Canal subjacente perfeitamente confiável. Não apresenta erros de bits. Não apresenta perda de pacotes. FSMs separadas, para remetente e receptor: Remetente envia dados pelo canal subjacente. Receptor recebe dados do canal subjacente. ESTADO: neste estado, o próximo estado é determinado unicamente pelo próximo evento. state 1 event causing state transition actions taken on state transition event actions state rdt2.0 - Modelo um pouco mais realista: Bits num pacote podem ser corrompidos. Danos podem ocorrer nos componentes físicos da, quando um pacote é transmitido, propagado ou buferizado. Entretanto, continuamos supondo que todos os pacotes transmitidos são recebidos na ordem em que são enviados (ainda que seus bits possam estar corrompidos). Rdt2.0: canal com erros de bits Canal subjacente pode inverter bits no pacote Lembre-se: checksum UDP pode detectar erros de bits. A questão é: como recuperar dos erros? Confirmação (ACKs( ACKs): receptor avisa explicitamente ao remetente que pacote chegou bem Confirmação negativos (NAKs( NAKs): receptor avisa explicitamente ao remetente que pacote tinha erros. Remetente retransmite pacote ao receber um NAK ( > Cenários humanos usando ACKs, NAKs? < ) Prof. Dr. Adriano Mauro Cansian 4

10 Mensagens de controle Novas capacidades em rdt2.0 Permitem o receptor informar ao emissor o que foi recebido corretamente e o que foi recebido com erro, exigindo repetição. Em s de computadores, protocolo RDT baseados em retransmissão são chamados de Protocolos ARQ (Automatic Repeat request). Três capacidades adicionais são exigidas em protocolos de ARQ para lidar com a presença de erros de bits: Detecção de erros: mecanismo para permitir que o receptor identifique quando erros de bit ocorreram. Realimentação (feedback( feedback) ) pelo receptor: mensagens de controle (ACK, NAK) trocadas entre receptor remetente. Retransmissão: : para corrigir os erros detectados. Estes novos mecanismos estão presentes em rdt2.0 (além do rdt1.0) rdt2.0: especificação da FSM - Emissor Aguarda dados da Possui 2 estados: Em um estado aguarda dados da camada superior. Em outro estado, aguarda ACK ou NACK do receptor Aguarda ACK ou NACK do receptor Se recebe um NACK, re-envia o último pacote atual, e retorna a aguardar um ACK ou NACK. Não pode aceitar dados da camada superior (stop-and-wait) rdt2.0: especificação da FSM - Receptor Possui apenas 1 estado: ao receber um pacote, responde com ACK ou NACK, dependendo se o pacote está ou não corrompido. Pacote recebido apresenta erro. Emite um NACK, e retorna ao estado de aguardar. Pacote recebido está íntegro. Emite um ACK, confirmando e retorna ao estado de aguardar. Se recebe um ACK confirmando que o dado atual foi recebido, retorna ao estado de aguardar um pacote da camada superior rdt2.0: em ação (sem erros) rdt2.0: em ação (cenário de erro) FSM do remetente FSM do receptor FSM do remetente FSM do receptor Prof. Dr. Adriano Mauro Cansian 5

11 rdt2.0 tem uma falha fatal! O que acontece se ACK/NAK com erro? Remetente não sabe o que aconteceu no receptor! Não se pode apenas retransmitir: possibilidade de pacotes duplicados. O que fazer? Remetente usa ACKs/NAKs p/ ACK/NAK do receptor? E se perder ACK/NAK do remetente? Retransmitir, mas pode causar retransmissão de pacote recebido certo! Lidando c/ duplicação: Emissor inclui número de sequência p/ cada pacote. Remetente retransmite pacote atual se ACK/NAK recebido com erro. Receptor descarta (não entrega) pacote duplicado. Stop and wait Remetente envia um pacote, e então aguarda resposta do receptor. rdt2.1: EMISSOR,, trata ACK/NAKs com erro Insere No. de seqüência no pacote Deve verificar se ACK/NAK recebido tinha erro rdt2.1: receptor,, trata ACK/NAKs com erro Deve checar se pacote recebido é duplicado. Estado indica se No. de seqüência esperado é 0 ou 1 rdt2.1: discussão (1) Emissor: Insere No. de seqüência no pacote. Bastam dois Nos. de seqüência (0,1). Deve verificar se ACK/NAK recebido tinha erro. Duplicou o No. de estados Estado deve lembrar se o pacote corrente tem No. de seqüência 0 ou rdt2.1: discussão (2) Receptor: Deve checar se pacote recebido é duplicado Estado indica se No. de seqüência esperado é 0 ou 1. Receptor não tem como saber se último ACK/NAK foi recebido bem pelo emissor. rdt2.2: um protocolo sem NAKs Mesma funcionalidade que rdt2.1, apenas com ACKs. Ao invés de NAK, receptor envia ACK para o último pacote recebido bem. Receptor deve incluir explicitamente o No. de seqüência do pacote reconhecido. ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual.! FSM do remetente Prof. Dr. Adriano Mauro Cansian 6

12 rdt3.0: canais com erros e perdas (1) Nova suposição: além de corromper, o canal subjacente também pode perder pacotes (sejam dados ou ACKs). Como lidar com perdas? Principalmente: Como detectar perda de pacotes? O que fazer quando pacotes são perdidos? Checksum,, No. de seqüência, ACKs,, ou retransmissões podem ajudar, mas não serão suficientes. 37 rdt3.0: canais com erros e perdas (2) Abordagem: remetente aguarda um tempo razoável pelo ACK. Retransmite se nenhum ACK recebido neste intervalo Se pacote (ou ACK) apenas atrasado (e não perdido): A retransmissão será duplicada,, mas uso de número de seqüência já cuida disto. Receptor deve especificar número de seqüência do pacote sendo reconhecido (confirmado( confirmado). Exige uso de temporizadores. 38 rdt3.0: remetente rdt3.0 em ação rdt3.0 em ação Desempenho de rdt3.0 rdt3.0 funciona, porém seu desempenho é muito ruim Exemplo: de 1 Gbps,, retardo fim a fim de 15 ms, pacote de 1KB: T transmitir = 8kb/pacote 10**9 b/seg = 8 microseg fração do tempo Utilização = U = = 8 microseg remetente ocupado mseg = 0,00015 Pacote de 1KB a cada 30 mseg vazão de 33kB/seg num de 1 Gbps! Protocolo limita uso dos recursos físicos! Prof. Dr. Adriano Mauro Cansian 7

13 Protocolos dutados dutados (pipelined( pipelined) Dutagem (pipelining): remetente admite múltiplos pacotes em trânsito, ainda não reconhecidos. Faixa de números de seqüência deve ser aumentada. Buffers no remetente e/ou no receptor. GBN - Go Back N (1) Emissor: pode enviar múltiplos pacotes sem aguardar ACK do receptor. Entretanto, restringe-se a ter não mais do que um valor máximo N de pacotes não confirmados no duto. Duas formas genéricas de protocolos dutados dutados : volta-n, retransmissão seletiva GBN - Go Back N (2) send_base = Seq. # do pacote mais velho não confirmado no duto. nextseqnum = Menor Seq. # não usado (Seq.# do próximo a enviar). GBN - Go Back N (3) Emissor: O intervalo de números de seqüência para pacotes transmitidos mas ainda não confirmados poder ser visto como uma janela (window)) de tamanho N sobre o intervalo de números de seqüência. À medida que o protocolo opera, a janela se desloca sobre o espaço de números de seqüência: sliding-window protocol [0, send_base - 1] = Pacotes transmitidos e confirmados [send_base, nextseqnum -1] = Pacotes enviados mas não confirmados [nextseqn, send_base + N - 1] = Disponíveis para serem usados imediatamente, assim que dados chegarem da camada superior. Pergunta: por que limitar o número de pacotes não confirmados? Sequence number (base + N) : não n o podem ser usados até que um pacote não n o confirmado que esteja atualmente no duto tenha sido confirmado GBN: : FSM estendida do emissor GBN: : FSM estendida do receptor Recibo de um pacote. ACK(n): confirma que todos pacotes, até - e inclusive - o No. de seqüência n foram recebidos no receptor: ACK cumulativo pode receber ACKs duplicados. Chamada superior: verifica se a janela está cheia. Se não está, forma o pacote e envia. Se está cheia, recusa. Existe um temporizador para cada pacote em trânsito. Timeout(n): retransmite pacote n e todos os pacotes com No. de seqüência maiores na janela. 47 Receptor é muito simples: Usa apenas ACK: sempre envia ACK para pacote recebido o.k. com o maior No. de seq. em ordem Pode gerar ACKs duplicados Só precisa se lembrar do expectedseqnum Pacote fora de ordem: Descarta (não armazena) receptor não usa buffers! Manda ACK de pacote com maior No. de seqüência em ordem. 48 Prof. Dr. Adriano Mauro Cansian 8

14 GBN em ação Janela = 4. Envia de 0 a 3 e o 2 se perde Pacote 2 se perdeu. Descarta o 3 e pede o 2 (confirma o 1). Descarta o 4 e o 5, e continua pedindo o 2. Timeout do ack de 2. Retransmite o 2. Confirma os pacotes 0 e 1 49 GBN não é o TCP GBN incorpora quase todas as técnicas que serão encontradas nos componentes do TCP (visto mais adiante): Número de seqüência; Checksum; ACK cumulativos; Timeouts; Operação de retransmissão Entretanto existem diferenças entre o TCP e o GBN. Por exemplo: muitas implementações TCP fazem buffering de segmentos recebidos corretamente, mas fora de ordem. TCP é um híbrido de GBN e Repetição Seletiva (a seguir). 50 Problemas do GBN Repetição seletiva GBN tem problemas de performance. Se o tamanho da janela é grande e o atraso da também é grande, muitos pacotes podem estar no duto. Um único erro em um segmento resulta na retransmissão de um grande número de segmentos,, a maioria desnecessários. À medida em que a probabilidade de erro do canal cresce, o duto fica lotado de retransmissões desnecessárias. 51 Evita retransmissões desnecessárias. O emissor retransmite apenas os pacotes que ele suspeita terem sido recebidos com erro pelo receptor. Receptor confirma individualmente todos os pacotes recebidos corretamente. Armazena pacotes no buffer,, conforme necessário, para posterior entrega em ordem à camada superior. Emissor apenas re-envia pacotes para os quais o ACK não foi recebido. Temporizador de remetente para cada pacote sem ACK. Janela do emissor N números de seqüência consecutivos. Outra vez limita nos. de seqüência de pacotes enviados, mas ainda não reconhecidos. 52 Repetição seletiva: janelas de remetente e receptor Repetição seletiva no emissor O emissor já terá recebido confirmação para alguns pacotes da janela. Dados recebidos de acima. O emissor verifica o próximo número de seqüência disponível para o pacote. Se o número de seqüência estiver dentro da janela do emissor, os dados são empacotados e enviados; caso contrário são bufferizados ou devolvidos à camada superior para transmissão posterior. Timeout. Temporizadores são usados para proteger contra perda de pacotes. Somente um único pacote será transmitido no caso de timeout. ACK recebido. Se um ACK for recebido, o emissor marca o pacote como recebido. Se o número de seqüência do pacote for igual à send-base, então a base da janela avança até o pacote com o menor número de seqüência não-confirmado. Se houver pacotes não transmitidos, com números de seqüência que caem agora dentro da janela, estes pacotes são transmitidos Prof. Dr. Adriano Mauro Cansian 9

15 Repetição seletiva no receptor (1) Pacote com número de seqüência no intervalo [ rcv_base, rcv_base+n-1] é recebido corretamente: Neste caso, o pacote recebido cai dentro da janela do receptor e um pacote seletivo de ACK é retornado ao remetente. Se o pacote não foi recebido previamente, ele é armazenado. Se este pacote tiver um número de seqüência igual à base da janela da recepção (rcv_base), então este pacote, e os quaisquer pacotes previamente armazenados e numerados em seqüência (começando com o rcv_base) são entregues à camada superior. A janela de recepção é movida então para a frente pelo número total dos pacotes entregues à camada superior. Pacote com número de seqüência é recebido dentro de [ rcv_base-n, rcv_base-1 ]: Neste caso, um ACK deve ser gerado, mesmo que este seja um pacote que o receptor já tenha confirmado previamente. Se não: Ignora o pacote. Repetição seletiva no receptor (2) Pacote com número de seqüência é recebido dentro de [ rcv_base-n, rcv_base-1 ]: Neste caso, um ACK deve ser gerado, mesmo que este seja um pacote que o receptor já tenha confirmado previamente. [ rcv_base-n, rcv_base-1 ]: pacotes já confirmados anteriormente Intervalo dentro da janela [ rcv_base, rcv_base+n-1] Repetição seletiva - resumo emissor Dados de cima: Se próximo No. de seqüência na janela, envia pacote. Timeout(n): Reenvia pacote n, reiniciar temporizador 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óximo No. de seqüência não reconhecido receptor Pacote n dentro de [rcvbase, rcvbase+n-1] Envia ACK(n) Fora de ordem: buffer Em ordem: entrega (tb. entrega pacotes em ordem do buffer), avança janela p/ próximo pacote ainda não recebido. Pacote n em [rcvbase-n,rcvbase-1] ACK(n), mesmo que já tenha enviado antes. Senão: Ignora. 57 Retransmissão seletiva em ação 58 Retransmissão seletiva em ação Quando um pacote com um número de seqüência de rcv_base=2 é recebido, então ele e os pacotes rcv_base+1 e rcv_base+2 podem ser entregues à camada superior. Repetição seletiva: dilema Exemplo: Nos. de seqüência : 0, 1, 2, 3 Tamanho de janela =3 Receptor não vê diferença entre os dois cenários (a) e (b)! Incorretamente passa dados duplicados como novos em (a) Q: Qual a relação entre tamanho de No. de seqüência e tamanho de janela? Prof. Dr. Adriano Mauro Cansian 10

16 TCP: Visão geral (1) RFCs: : 793, 1122, 1323, 2018, 2581 TCP: Visão geral (2) RFCs: : 793, 1122, 1323, 2018, 2581 Peet-to- -to-peer (P2P): Único emissor transmite para um único receptor. Fluxo de bytes, ordenados, confiável: Não estruturado em mensagens. Dutado (pipelined): Tamanho da janela ajustado por controle de fluxo e congestionamento do TCP. Buffers de envio e recepção, e variáveis de estado para cada conexão. socket door application writes data TCP send buffer segment application reads data TCP receive buffer socket door bytes, 536 bytes ou 512 bytes Transmissão Full Duplex: Fluxo de dados bi-direcional na mesma conexão. MSS: tamanho máximo de segmento de dados. Orientado a conexão: Handshaking de 3 vias (troca de MSGs de controle) inicia estado de remetente, receptor antes de trocar dados. Fluxo controlado: Receptor não será afogado. 62 TCP: estrutura do segmento URG: dados urgentes (pouco usado) Tamanho do header em palavras de 32 bits ACK: No. ACK é válido RST, SYN, FIN: gestão de conexão (comandos de estabelecimento, liberação) checksum Internet (como UDP) No. porta origem 32 bits No. porta dest número de seqüência número de confirmação (ACK) tam. sem UA P cab. uso R S F janela receptor checksum ptr dados urg. Opções (tamanho variável) dados da (tamanho variável) PSH = push: envia dados já (pouco usado) Contagem de dados por bytes (não segmentos!) No. bytes receptor quer aceitar: Controle de Fluxo. 20 bytes fixos no header Numeração de segmentos Transmissão de um arquivo de bytes, com MSS = bytes 1o. segmento último segmento TCP: Números de seqüência e ACKs Nos. de seqüência: número dentro do fluxo de bytes do primeiro byte de dados do segmento. ACKs: No. de seqüência do próximo byte esperado do outro lado. ACK cumulativo. P: Como receptor trata segmentos fora da ordem? R: especificação do TCP é omissa - deixado ao implementador. Usuário tecla C A reconhece chegada do C ecoado Estação A Estação B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 cenário simples de telnet B reconhece chegada de C, ecoa C de volta 65 tempo TCP: transferência confiável de dados event: data received from application above create, send segment wait for event event: ACK received, with ACK # y ACK processing event: timer timeout for segment with seq # y retransmit segment Passagem dos dados da ao TCP e o subseqüente enquadramento e transmissão de um segmento. Cada vez que o TCP entrega um segmento ao IP, ele inicia um temporizador para aquele segmento. Se este temporizador expirar, um evento de interrupção é gerado no host. O TCP responde ao evento de timeout, re-enviando o segmento que causou o timeout. Chegada de um segmento de reconhecimento (ACK) vindo do receptor. 66 Prof. Dr. Adriano Mauro Cansian 11

17 TCP: transferência confiável de dados event: data received from application above create, send segment wait for event event: ACK received, with ACK # y ACK processing event: timer timeout for segment with seq # y retransmit segment Chegada de um segmento de reconhecimento (ACK) do receptor (mais especificamente, um segmento que contem um valor válido do campo do ACK). Aqui, o remetente TCP deve determinar se o ACK é um first-time ACK para um segmento o qual o remetente ainda está para receber um reconhecimento, ou uma duplicata de ACK que re-reconheça um segmento para qual o remetente já tenha recebido um reconhecimento anteriormente. No exemplo da chegada de um ACK first-time, o emissor sabe agora que todos os dados até o byte que está sendo reconhecido foram recebidos corretamente no receptor. O emissor pode assim atualizar sua variável do estado do TCP que segue o número de seqüência do último byte que tenha sido recebido corretamente, e em ordem, no receptor. 67 Emissor TCP simplificado 00 sendbase = número de seqüência inicial 01 nextseqnum = número de seqüência inicial loop (forever) { 04 switch(event) 05 event: dados recebidos da acima 06 cria segmento TCP com número de seqüência nextseqnum 07 inicia temporizador para segmento nextseqnum 08 passa segmento para IP 09 nextseqnum = nextseqnum + comprimento(dados) 10 event: expirado temporizador de segmento c/ No. de seqüência y 11 retransmite segmento com número de seqüência y 12 calcula novo intervalo de temporização para segmento y 13 reinicia temporizador para número de seqüência y 14 event: ACK recebido, com valor de campo ACK de y 15 se (y > sendbase) { /* ACK cumulativo de todos dados até y */ 16 cancela temporizadores p/ segmentos c/ Nos. de seqüência < y 17 sendbase = y 18 } 19 senão { /* é ACK duplicado para segmento já reconhecido */ 20 incrementa número de ACKs duplicados recebidos para y 21 if (número de ACKs duplicados recebidos para y == 3) { 22 /* TCP: retransmissão rápida */ 23 reenvia segmento com número de seqüência y 24 reinicia temporizador para número de seqüência y 25 } 26 } /* fim de loop forever */ 68 Retransmissão rápida Geração de ACKs no TCP [RFCs RFCs 1122, 2581] Quando um receptor TCP recebe um segmento com um número de seqüência que seja maior do que próximo número de seqüência em-ordem esperado, ele detecta uma falha no fluxo de dados - isto é, um segmento faltante. Uma vez que o TCP não usa reconhecimentos negativos, o receptor não pode emitir uma negativa de ACK explícita de volta ao emissor. Ao invés disso, re-reconhece simplesmente (isto é, gera um ACK em duplicata para) o último byte em-ordem dos dados que ele recebeu. Se o emissor receber três ACKs duplicados para o mesmo dado (segmento), ele assume como uma indicação que foi perdido o segmento que vem em seguida ao segmento que foi confirmado ("ACKado ) três vezes. Neste caso, o TCP executa uma retransmissão rápida [ RFC 2581 ], re-enviando o segmento faltante antes que o temporizador do segmento expire. 69 Evento Chegada de segmento em ordem sem lacunas, todos anteriores já reconhecidos. Chegada de segmento em ordem sem lacunas, um ACK retardado pendente. Chegada de segmento fora de ordem, com No. de seq. maior que esperado lacuna. Chegada de segmento que preenche a lacuna parcial ou completamente. Ação do receptor TCP ACK retardado. Espera até 500ms pelo próx. segmento. Se não chegar segmento, envia ACK Envia imediatamente um único ACK cumulativo. Envia ACK duplicado, indicando No. de seq. do próximo byte esperado. ACK imediato se segmento no início da lacuna. 70 Geração de ACKs no TCP [RFCs RFCs 1122, 2581] TCP: cenários de retransmissão (1) Evento Chegada do segmento em ordem, com número de seqüência previsto. Todos os dados até o núm. de seq. previsto já reconhecidos. Nenhum gap nos dados recebidos. Ação do receptor TCP ACK atrasado. Espera até 500ms pela chegada de um outro segmento em ordem. Se o próximo segmento não chegar em ordem neste intervalo, emita um ACK do anterior. Chegada de um segmento em ordem Emita imediatamente a único ACK cumulativo. com número de seqüência previsto. Um Confirmando ambos os segmentos emordem. outro segmento em ordem aguardando transmissão de ACK. Nenhum gap nos dados recebidos. Chegada do segmento fora de ordem com número de seqüência mais alto do que esperado. Detectado gap. Chegada de segmento que completa parcial ou completamente um gap nos dados recebidos. Emita imediatamente o ACK duplicado, indicando o número de seqüência do próximo byte esperado. Emita imediatamente o ACK, contanto que o segmento comece no fim mais baixo da gap. temporização tempo Estação A Seq=92, 8 bytes de dados X perda Estação B ACK=100 Seq=92, 8 bytes de dados ACK=100 cenário do ACK perdido Prof. Dr. Adriano Mauro Cansian 12

18 TCP: cenários de retransmissão (2) TCP: cenários de retransmissão (3) Timeout antes da chegada do ack do primeiro segmento. Reenvia O ACK do segundo segmento chega on-time Envia dois segmentos de uma vez e aguarda O ACK do primeiro segmento se perde Recebe o ACK do primeiro e host A acha que é do re-enviado Este ACK do reenvio do 1o. Segmento é desconsiderado (ii) Recebe a indicação que B recebeu tudo certo, até o 100 e não re-envia nada (i) Indica que B recebeu tudo certo, até o 100 (aguarda o 120) TCP: Controle de Fluxo (1) TCP: Controle de Fluxo (2) Para emissor não esgotar os buffers do receptor por transmitir demais, ou muito rapidamente. RcvBuffer = tamanho do Buffer de recepção. RcvWindow = informa ao emissor quantidade de espaço vazio no buffer. Este valor é mantido como variável em cada emissor (Lembrar Full Duplex). RECEPTOR: explicitamente avisa o emissor da quantidade de espaço livre disponível (muda dinamicamente). Campo RcvWindow no segmento TCP. EMISSOR: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, MENOR que o valor mais recente de RcvWindow. (para cada lado da conexão) buffering pelo receptor Troca de informações sobre controle de fluxo TCP TCP: Tempo de Resposta (RTT) e temporização (1) Aplicação envia 2 Kb (3) Aplicação envia 3 Kb, mas emissor TCP só pode enviar 2 Kb (...) Emissor aguarda... (6) Receptor agora pode enviar até 2 Kb; envia o 1 Kb que falta. (0) 4 Kb = Tamanho do buffer do receptor. (2) Receptor confirma e avisa que pode enviar mais 2 Kb. (4) Receptor confirma e pede para aguardar (buffer cheio) win=0 (5) Aplicação lê 2 Kb do TCP ; Receptor TCP avisa que pode enviar mais 2 Kb (reconfirma o último recebido e envia janela de 2048) P: Como escolher valor do temporizador TCP? Deve ser maior que o RTT. Note que o RTT pode variar. Muito curto: temporização prematura. Retransmissões são desnecessárias. Muito longo: reação demorada à perda de segmentos. P: Como estimar RTT? RTTamostra: tempo medido entre a transmissão do segmento e o recebimento do ACK correspondente. Ignora retransmissões, e segmentos com ACKs cumulativos RTTamostra vai variar, queremos ponderador de RTT estimado. Usa várias medições recentes, não apenas o valor corrente (RTTamostra) Prof. Dr. Adriano Mauro Cansian 13

19 TCP: Tempo de Resposta (RTT) e Temporização (1) RTT_estimado = (1-x)* RTT_estimado + x*rtt_amostra Trata-se de uma Média corrente exponencialmente ponderada. Influência de cada amostra diminui exponencialmente com o tempo Valor típico de x = (1/8) RTT_estimado = RTT_estimado RTT_amostra amostra. TCP: Tempo de Resposta (RTT) e Temporização (2) Escolhendo o intervalo de temporização: RTT_estimado mais uma margem de segurança Se há variação grande em RTT_estimado, exige margem de segurança maior Temporização = RTT_estimado + 4*Desvio Desvio = (1-x)* Desvio + x * RTT_amostra - RTT_estimado Exemplos interativos: TCP: Gerenciamento de Conexões (1) Lembrete: Remetente e receptor TCP estabelecem conexão antes de trocar segmentos de dados. Fluxo de dados vai nos dois sentidos. Inicializam variáveis TCP: Números de seqüência. Buffers,, informações de controle de fluxo (por( exemplo RcvWindow). Cliente: é aquele que inicia a conexão Socket clientsocket = newsocket(" ("hostname","port number"); Servidor: é aquele contatado pelo cliente Socket connectionsocket = welcomesocket.accept accept(); TCP: Iniciando Conexão (1) Inicialização em 3 passos (3-( 3-way handshake): (1): Clienteliente envia segmento de controle SYN do TCP ao servidor. Bit SYN do TCP é ajustado como 1. (SYN=1( SYN=1; ACK=0) Cliente especifica No. de Seqüência inicial. (2): Servidorervidor recebe SYN,, responde com segmento de controle SYN- ACK Ajusta SYN=1 E ACK=1 (SYN=1; ACK=1) Confirma SYN recebido. Aloca buffers,, especifica No. seq.. inicial de servidor para o receptor. (3): Cliente recebe SYN=1; ACK=1,, e responde com segmento de controle ACK e começa a enviar dados. (SYN=0; ACK=1) TCP: Iniciando Conexão (2) TCP: Fechando uma Conexão (1) (SYN=1; ACK=0) Encerrando uma conexão: cliente servidor (SYN=1; ACK=1) Servidor confirma o No. seq. do cliente, e envia seu próprio No. de seq. cliente fecha soquete: clientsocket.close close(); Passo 1: cliente envia segmento de controle FIN ao servidor. fechar FIN ACK FIN fechar (SYN=0; ACK=1) Cliente confirma o No. seq. do server, e começa a enviar dados seguindo seu No. de seq. 83 Passo 2: servidor recebe FIN, responde com ACK.. Encerra a conexão, enviando FIN. ( Segue... ) espera temporizada fechada ACK 84 Prof. Dr. Adriano Mauro Cansian 14

20 TCP: Fechando uma Conexão (2) Passo 3: cliente recebe FIN, responde com ACK. Entre em espera temporizada - responderá com ACK a FINs recebidos Step 4: servidor,, recebe ACK. Conexão encerrada. fechando espera temporizada Note: com pequena modificação, consegue tratar FINs simultâneos. fechada cliente FIN ACK FIN ACK servidor fechando fechada TCP: Ciclo de vida (1) Ciclo de vida do servidor TCP TCP: Ciclo de vida (2) Ciclo de vida do cliente TCP Princípios de Controle de Congestionamento (1) Congestionamento: Informalmente: trata-se de muitas fontes enviando muitos dados mais rapidamente do que a REDE pode tratar. Diferente de controle de fluxo! Retransmissão de pacotes trata o sintoma do congestionamento da (perda de segmentos da camada de transporte) mas não trata a causa do congestionamento: muitas origens tentando enviar dados numa taxa muito alta Princípios de Controle de Congestionamento (2) Como se manifesta: Perda (drop( drop) ) de pacotes (esgotamento de buffers em roteadores). Retransmissão de pacotes (devido aos drops). Longos atrasos (grande enfileiramento nos buffers dos roteadores). Um dos 10 problemas mais importantes em s! Causas e custos de congestionamento: cenário 1 Dois emissores A e B e dois receptores. Um roteador, com buffers infinitos. Sem nenhum tipo retransmissão (sem controle de erros). Aplicação entrega dados para a camada de transporte a uma taxa λ in. Capacidade do link é R bps Prof. Dr. Adriano Mauro Cansian 15

21 Causas e custos de congestionamento: cenário 1 (1) Causas e custos de congestionamento: cenário 1 (2) Tudo que é enviado pelo emissor é recebido no receptor a uma taxa finita. Quando a taxa de emissão é ACIMA de R/2, a recepção é sempre R/2. throughput por conexão (número de bytes/seg no receptor) em função da taxa de emissão da conexão À medida que a taxa de emissão se aproxima de R/2 o atraso em para cada emissor se aproxima de infinito O link não consegue enviar pacotes a uma taxa estacionária que ultrapasse R/2. Não importa quão alta seja a taxa que A e B ajustem para emissão, eles nunca obterão um throughput superior a R/2 Existem grandes retardos quando a está congestionada. Mesmo neste cenário irreal, existe uma vazão máxima atingível Causas e custos de congestionamento: cenário 2 Causas e custos de congestionamento: cenário 2 Um roteador, com buffers finitos. Conexão confiável: retransmissão pelo emissor de pacotes perdidos. Carga disponível (a) Considere que o host A só envia quando buffer do router está livre. Neste caso λ in = λ in = throughput da conexão. (b) Considere agora que λ in = 0,5 R e que apenas 0,333 R chega ao receptor. Isso significa que 0,333 R bytes/seg seg é a carga original e 0,266 R bytes/seg seg são retransmissões. A taxa de transmissão nunca poderá ultrapassar R/2 93 Imagine que cada pacote tem de ser enviado 2 vezes devido a atrasos 94 Causas e custos de congestionamento: cenário 2 Sempre: λ = λ (Denominado de carga disponível ou goodput goodput ) in out Retransmissão perfeito apenas quando perda: λ > λ in out Causas e custos de congestionamento: cenário 2 Outros Custos de congestionamento: Mais trabalho (retransmissão) para determinado goodput goodput. Retransmissões desnecessárias: São enviadas múltiplas cópias do pacote Prof. Dr. Adriano Mauro Cansian 16