Você está na página 1de 7

SIN352 - Aula 15 - Camada de Transporte 5/5_A

#SIN352 #RedesDeComputadores #CamadaDeTransporte #ControleDeFluxo #AulaSincrona


#PER2

Assuntos que vão cair na prova 2

Visão geral e caracteristicas do TCP

Formato do segmento TCP

Gerenciamento de conexão TCP

Temporização e retransmissão

Transferência confiável

Protocolos de transferência confiáve de dados com paralelismos

Controle de fluxo

controle de congestionamento

Mecanismos de transferência confiáveis.

rdt3.0 é correto, mas possui desempenho ruim

Porque?

quando uma maquina a manda um grupo para a maquina b

ele manda um pacote e esse pacote chega depois e ele não


manda outro porque ele espera uma confirmação

para lidar com isso usa-se um paralelismo

pode-se mandar uma quantidade maior e só aí


aguardar a confirmação por exemplo

Introduzindo o paralelismo

o atraso de propragação (ida e volta) á velocidade da luz - RTT


é de cerca de 30ms por ex.

suponha que eles estejam conectados por um canal com


capacidade de transmissão - R - de qGbps

um tamanho de pacote - L - de mil bytes (8 mil bits)

Qual é o tempo de transmissão?

tamanho dividido pela taxa de transmissão:


8 mil bits/pacotes dividido por 10^9bits/s =
8Us

Ttrans = L/R

Se o remetente começar a enviar o pacote em t = 0, então t =


L/R = 8 μs (micro segundos)

Quando o ultimo bit entrará no canal do lado


remetente

Na ida o pacote faz sua jornada de 15 ms atravessando o país;

Quando o ultimo bit do pacote emertino no


destinatário em t = RTT/2 + L/R = 15,008 ms

Ignoramos aqui o tempo de transmissão dos pacotes ACK (para


simplificar).

Quando o destinatário receber o ultimo bit, o ACK emergirá de


volta no remetente em t = RTT + L/R = 30,008 ms

Aqui o remetente poderá transmitir a próxima


mensagem

Conclusão: em 30,008 ms o remetente esteve enviando por


apenas 0,008 ms.

Se definirmos a utilização do canal como a fração do tempo em que o


remetente está realmente ocupado, a ideia do pare espere tem a utilização assim:

𝑈𝑟𝑒𝑚𝑒𝑡 = (𝐿/𝑅)/(𝑅𝑇𝑇+𝐿/𝑅)= 0,008/30,008= 0,0027

O remetente ficou ocupado apenas 2,7 centésimos de 1% do tempo.

Em outras palavras: ele só foi capaz de enviar 1000 bytes em 30,008 ms.

Vazão efetiva de 267 Kbits/s

O enlace não era de 1 Gbps?

O pare e espere no tempo zero manda o pacote, quando o pirmeiro bit chega
ele manda a confirmação e só depois da confirmação ele envia o próximo em um tempo rtt +
transmissão

Ja no paralelismo, no tempo t zero ele manda os pacotes até um determinado


limite, nao espera a confirmação, na medida que os cates chegam ele envia o ACK, ele define
quantos pacotes vai mandar de uma vez, no exemplo são 4
Go-Bank-N (GBN) - algoritimo que determina até que ponto pode mandar multiplos
pacotes até ter a confirmação (precisa da confirmação pois é transferencia confiável)

É um protocolo que o remetente é autorizado a transmitir múltiplos pacotes


sem esperar por reconhecimento.

Temos variáveis, sendo:

base: número de sequencia mais antigo do pacote não


reconhecido;

nextseqnum: menor número de sequencia não utilizado


(próximo a ser enviado)

(slide 10 - aula 5/5A 23minutos) Ex: tem-se uma quantidade de


pacote, por exemplo, uma aplicação quer mandar uma foto então ele quebra essa foto em
vários pacotes, o azulzinho são os pacotes que enviaram, que saiu do sul e foi pro norte,
viajou, teve o rtt e foi confirmado. Ou seja, a variável base é o numero de sequencia do
comecinho da minha janela de transmissão, pro algoritmo tcp enviar o pacote ele envia o base,
mas a medida que ele vai enviando, ele manda o pacote e nao espera a confirmação e ja
manda o próximo até cehgar no fim da janela, de forma paralela.

Se o pacote nao chegar ele envia novamente o pacote e enquanto isso a janela
nao prospera

O problema é que se um pacote se perder a janela nao anda, para resolver usa-
se a repetição seletiva, deixando a janela andar e retransmitindo somente os pacotes com erro

O destinatario aceita receber os pacotes fora de ordem e depois


organiza, até o tamanho da janela

O GBN permite que o remetente “inunde” a rede com pacotes evitando


problemas de utilização de canal observados em protocolos do tipo pare e espera;

Mas ele possui um problema!

Quando o tamanho da janela e o produto entre o atraso e a largura de banda


são grandes pode haver muitos pacotes pendente na rede.

Um único erro de pacote fazo GBN retransmitir um número grande de


pacotes;

O protocolo de repetição seletiva (selective repeat – SR) evita retransmissão


desnecessárias.

São retransmitidos apenas pacotes suspeitos de terem sido recebidos com erro
(perdidos ou corrompidos)
A repetição seletiva resolve o problema do Go-Bank-N

ganha em volume com transmissão confiável

porém tudo deve ser controlado

CONTROLE DE FLUXO

Buffers – Recepção

Hospedeiros de cada lado de uma conexão TCP reservam um buffer de recepção para a
conexão;

O processo de aplicação associado lerá os dados a partir desse buffer, mas não
necessariamente no momento em que são recebidos;

Se a aplicação for relativamente lenta na leitura dos dados, o remetente pode saturar
o buffer de recepção.

Solução para a saturação do buffer

TCP fornece um serviço de controle de fluxo às suas aplicações;

Tal controle elimina a possibilidade de o remetente estourar o buffer do destinatário;

Serviço de compatibilização de velocidades – taxa à qual o remetente está enviando


com a taxa que a aplicação receptora está lendo.

deixa a transmissão mais macia, sem muitas perdas e sem muitas retransmissões

TCP faz o controle do fluxo

Controle de fluxo

TCP oferece controle de fluxo fazendo com que o remetente mantenha uma variável
denominada janela de recepção;

O objetivo da janela de recepção é dar ao remetente uma ideia do espaço do buffer


livre disponível no destinatário;

Como o TCP é full-duplex, o remetente de cada lado da conexão mantém uma janela
de recepção distinta.

Suponha que o host A esteja enviando um arquivo grande ao host B por uma conexão
TCP. O hospedeiro B aloca um buffer de recepção – RcvBuffer.
De tempos em tempos, o processo de aplicação no host B faz a leitura do buffer. Duas
importantes variáveis são mantidas pelo TCP:

LastByteRead – número do último byte lido do buffer pelo processo de


aplicação;

LastByteRcvd – número do último byte que chegou da rede e foi colocado no


buffer de recepção.

Dados LastByteRead e LastByteRcvd é possível estimar um tamanho máximo para


RcvBuffer?

Sim, conforme o exemplo abaixo (slide 23 - 50 minutos aula)

Exemplo:

RcvBuffer = 65535 bytes

LastbyteRcvd = 80000 bytes

LastbyteRead = 10000 bytes

Isso poderia acontecer? Quantos dados estariam no buffer, nesse caso?

FALHA pois o pacote é maior que o RCVBuffer, aí tem um estouro do buffer

Neste caso, como o TCP não pode saturar o buffer de recepção, devemos ter:

LastByteRcvd – LastByteRead <= RcvBuffer

A janela de recepção, denominada rwnd, é ajustada para a quantidade de espaço disponível no


buffer:

Rwnd = RcvBuffer – [LastByteRcvd – LastByteRead] (quem manda precisa saber isso, o


que está livre, a janela de recepção é enviada por meios dos AKS para quem esta recebendo)

Controle de fluxo – Janela de recepção

O host B diz ao hospedeiro A quanto espaço disponível ele tem no buffer da conexão
colocando o valor atual de rwnd no campo da janela de recepção de cada segmento que envia
a A.

Inicialmente rwnd = RcvBuffer.

a cada ack ele conta o tamanho do buffer ainda disponível


Controle de fluxo – Janela de recepção - Rementente

O host A monitora duas variáveis:

LastByteSent – número do último byte enviado

LastByteAcked – número do último byte reconhecido

Suponha que LastByteSent = 90000 e LastByteAcked = 20000. O host A poderia


continuar a enviar dados?

Com base nisso, o que podemos dizer da relação entre LastByteSent, LastByteAcked e
rwnd?

LastByteSent – LastByteAcked <= rwnd

Ou seja, LastByteSent – LastByteAcked é a quantidade de dados não reconhecidos que


A enviou para B.

Mantendo a quantidade de dados não reconhecidos menor que o valor de rwnd, o


host A tem certeza de que não está fazendo transbordar o buffer de recepção em B.

Controle de fluxo – Janela de recepção - Problema

Suponha que rwnd = 0. Após anunciar ao host A que rwnd=0, imagine que B não tenha
nada para enviar ao host A.

O que vai acontecer?

Suponha que rwnd = 0. Após anunciar ao host A que rwnd=0, imagine


que B não tenha nada par enviar ao host A.

O que vai acontecer?

O processo de aplicação em B esvazia o buffer e o TCP não envia


segmentos com novos valores rwnd para o host A.

O host A nunca será informado de que foi aberto algum espaço no buffer de recepção
do host B!

Host A ficará bloqueado e não poderá transmitir dados...

Como resolver?

Controle de fluxo – Janela de recepção - Solução

A especificação do TCP requer que o host A continue a enviar


segmentos com um byte de dados quando a janela de recepção de B for zero!

Esses segmentos serão reconhecidos pelo receptor e na


medida que o buffer esvazia, novos segmentos enviados por B terão valores diferentes de zero
em rwnd.
Ou seja, A continua mandando nem que seja pelo
menos um lixo para verificar o estágio do buffer

Você também pode gostar