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