Interconexão e Transporte em Redes Prof. Ricardo S. Casado.
Transcript of Interconexão e Transporte em Redes Prof. Ricardo S. Casado.
Interconexão e Transporte em Redes
Prof. Ricardo S. Casado
Transferência Confiável de Dados
• É um processo que ocorre não só na camada de transporte mas também na camada de enlace (Swithes e Roteadores consequentemente);
• Com um canal confiável nenhum dos dados é corrompido e nem perdido e todos são entregues na ordem em que foram enviados;
• Porém a transferência confiável de dados é um problema de redes de computadores que se não for está entre os primeiros da lista.
Camadas Modelo OSI
Transferência Confiável
Transferência confiável de Dados
• É responsabilidade de um protocolo de transferência confiável de dados implementar essa abstração de serviço;
• A tarefa é dificultada pelo fato de que a camada a baixo do protocolo de transferência pode não ser confiável;
• Ex: O TCP é um protocolo de transferência confiável de dados que é implementado sobre uma camada de rede fim-a-fim não confiável (IP);
Pacote perdido
ACK Perdido
Protocolos de transferência confiável de dados com paralelismo
• Vamos considerar um caso ideal de dois hospedeiros, um localizado na costa oeste e outro na costa leste do brasil.
• O atraso de propagação de ida e volta à velocidade da luz, Tprop, entre esses dois sistemas finais é de aproximadamente 30 milissegundos.
• Suponha que eles estejam conectados por um canal com capacidade de transmissão (R), de 1 gigabit (10^9 bits) por segundo. Para um tamanho de pacote (L) de 1 Kbyte (8 mil bits) por pacote, incluindo o campo de cabeçalho e também de dados.
Protocolos de transferência confiável de dados com paralelismo
• O tempo necessário para realmente transmitir o pacote para o enlace de 1Gbps é:
• Tprop = Velocidade da luz (fibra)
• L = Tamanho do pacote• R = Capacidade de transmissão do canal
Paralelismo
Pare e espere
Paralelismo
Pare e espere
• A figura 1 mostra que, com nosso protocolo pare e espere, se o remetente começar a enviar o pacote em t = 0, então em t = L/R = 8 microssegundos, o último bit entrará no canal do lado remetente.
• O pacote então faz sua jornada de 15 milissegundos atravessando o país, com o último bit do pacote emergindo no destinatário em t = RTT/2 + L/R = 15,008 milissegundos.
Pare e espere
• Supondo, para simplificar, que pacotes ACK sejam extremamente pequenos (para ignorarmos seu tempo de transmissão) e que o destinatário pode enviar um ACK logo que receber o último bit de um pacote de dados, o ACK emergirá de volta no remetente em t = RTT + L/R = 30,008 milissegundos, o remetente esteve enviando por apenas 0,008 milissegundos.
Pare e espere
• Se definirmos a utilização do remetente (ou do canal) como a fração de tempo em que o remetente está realmente ocupado enviando bits para dentro do canal, analisando a 1 figura mostra que o protocolo pare e espere tem uma utilização do remetente Uremet bastante desanimadora.
Pare e espere
• Portanto o remetente ficou ocupado apenas 2,7 centésimos de 1% do tempo. Visto de outra maneira ele só foi capaz de enviar 1.000 bytes em 30,008 milissegundos, uma vazão efetiva de apenas 267Kbps, mesmo estando disponível para envio um enlace de 1Gbps.
• Imagine o desperdício e isso que desconsideramos o tempo de processamento das camadas inferiores nos sistemas finais e também o atraso de processamento e fila do roteadores.
Paralelismo
• A solução para este problema de desempenho em particular é simples: em vez de operar em modo pare e espere, o remetente é autorizado a enviar vários pacotes sem esperar por reconhecimentos, como mostra a figura 2 (pipelining).
Pipelining
Retransmissão
Cenário com perdado ACK
Temporização prematura,ACKs cumulativos
Controle de Fluxo
lado receptor da conexão TCP possui um buffer de recepção:
Processos de aplicação podem ser lentos para ler o buffer
Serviço de speed-matching: encontra a taxa de envio adequada à taxa de vazão da aplicação receptora
Controle de fluxoTransmissor não deve esgotar os buffers de recepção enviando dados rápido demais
Controle de Fluxo
(suponha que o receptor TCP descarte segmentos fora de ordem)
Espaço disponível no buffer= RcvWindow= RcvBuffer-[LastByteRcvd - LastByteRead]
Receptor informa a área disponível incluindo valor RcvWindow nos segmentos
· Transmissor limita os dados não confimados ao RcvWindow Garantia contra overflow no buffer do receptor
Gerenciamento de Conexão TCP TCP transmissor estabelece conexão com o receptor antes de trocar segmentos de dados
Inicializar variáveis: Números de seqüência Buffers, controle de fluxo (ex. RcvWindow)
Cliente: iniciador da conexão Socket clientSocket = new Socket(“hostname","port number"); Servidor: chamado pelo cliente Socket connectionSocket = welcomeSocket.accept();Three way handshake:Passo 1: sistema final cliente envia TCP SYN ao servidor Especifica número de seqüência inicial
Passo 2: sistema final servidor que recebe o SYN, responde com segmento SYNACK Reconhece o SYN recebido Aloca buffers Especifica o número de seqüência inicial do servidor
Passo 3: o sistema final cliente reconhece o SYNACK
Gerenciamento de Conexão TCP
Fechando uma conexão:
cliente fecha o socket: clientSocket.close();
Passo 1: o cliente envia o segmento TCP FIN ao servidor
Passo 2: servidor recebe FIN, responde com ACK. Fecha a conexão, envia FIN
Gerenciamento da Conexão TCP
Passo 3: cliente recebe FIN, responde com ACK.
Entra “espera temporizada” - vai responder com ACK
a FINs recebidos
Passo 4: servidor, recebe ACK. Conexão fechada
Nota: com uma pequena modificação, pode-se manipular FINs simultâneos
Gerenciamento da Conexão TCP
Estados do cliente Estados do servidor