Loading

Module 1: Transmissão e Programação

Nota de Estudos
Study Reminders
Support
Text Version

Controle De Fluxo TCP

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

TCP   Flow Control
Bem-vindo de volta ao curso sobre Rede de Computadores e Protocolo de Internet. Por isso, na última aula, analisamos os detalhes do estabelecimento de conexão TCP.Agora nesta classe em particular, olhamos para os maiores detalhes do TCP, o algoritmo de controle de fluxo, que é usado pelo TCP para gerenciar as taxas de taxas de remetente ao lado do remetente. Eos diferentes cronômetros associados a este algoritmo de controle de fluxo e como você configura um valor adequadopara aqueles cronômetros.(Consulte o Tempo do slide: 00:48)Bem, iniciando com o algoritmo de controle de fluxo. Assim, o TCP usa um algoritmo de controle de janela deslizantealgoritmo de controle com este go back N princípio go back N ARQ princípio. Onde, sehá um tempo fora, então você retransmite todos os dados que estão lá, dentro da sua janela do remetente.Então, a ideia é algo assim, em uma noção muito simplificada, que você diz começar para o seusubseqüente número 0. Por isso, lembre-se que 0 não é o número de sequência inicial e sim aquiapenas para explicação estamos utilizando esse número de sequência como 0. Mas, idealmente ele iniciaráa partir do número de sequência inicial que foi estabelecido durante a fase de tremer de mãodo estabelecimento de conexão.Então, aqui o número da sequência é como, se for o número de sequência então, a sequência inicialque está sendo estabelecida para durar o número de sequência que estamos falando aqui.Então, só pela simplicidade de explicação estamos começando com a sequência número 0. Então, deixe-nosiniciar com a sequência número 0 e neste estágio o aplicativo faça um 2 kB escreva no buffer da camada de transporte.Quando o aplicativo faz uma gravação de 2 kB no buffer da camada de transporte, assim, você envia 2 kB de dadose está enviando um 2 kB de dados com a sequência número 0. Então, inicialmente este é o buffer do receptor. Assim, o buffer do receptor pode segurar até 4 kB de dados. Então, uma vez que você estárecebendo isso então, o buffer do receptor diz você que bem, ele tem que receber 2 kB de dados.Então, ele tem apenas 2 kB de dados que ele pode aceitar. Então, ele envia de volta com um número de confirmaçãode 2048, 2kB é equivalente a 2048 bytes so, porque somosusando número de sequência de bytes. Então, ele envia uma confirmação para ele, 2048 e o tamanho da janelatem 2048 minutos então, ele pode segurar 2 kB de mais dados.Então, nessa fase, que então novamente aplicativo faz um 2 kB de gravação. Assim, quando o aplicativofaz um 2 kB de gravação, você está enviando 2 kB de dados, mais dados junto como número de sequência a partir de 2048. Então, ele é recebido pelo receptor. Assim, uma vez que érecebido pelo receptor. Então, aqui porque você já enviou 2 kB de dados e o tamanho da janela anunciada anterior doera de 2048, portanto, o remetente está bloqueado a partir deste ponto,porque o remetente já utilizou todo o espaço tampão que o receptor pode realizar,o remetente não pode enviar mais dados. Então, o remetente está bloqueado nesta fase. Assim, o buffer do receptorse torna cheio depois de receber este 2 kB de dados. Assim, o receptor envia uma confirmaçãodizendo que ele recebeu até 4096 bytes e o tamanho da janela é 0.Então, não é capaz de receber mais dados. Por isso, o remetente está bloqueado neste ponto.Agora, nesta fase, o aplicativo lê 2 kB de dados do buffer. Uma vez que o aplicativoleia 2 kB de dados do buffer, então, ele tem isso ele leu este primeiro 2 kB.Então, novamente este primeiro 2 kB se torna cheio. Assim, quando o primeiro 2 kB se torna cheio, o receptorenvia novamente um reconhecimento que bem o número de confirmação foi 4096aquele que estava lá mais cedo, mas o tamanho da janela agora muda de 0 para 2048. Então, elepode obter 2 kB de mais dados.Então, uma vez que o remetente emissor de volta sai da fase de bloqueio e uma vez que o remetenteestá saindo da fase de bloqueio, assim o remetente pode enviar até 2 kB de dados mais. Então, nesta fase diz que o remetente está enviando 1 kB de dados com a sequência número 4096.Então, que 1 kB é recebido pelo receptor ele colocou no tampão e ele tem 1 kB de graça. Então,se o receptor quiser enviar uma confirmação, nesse número de confirmação eleusará o número de confirmação como 4096 mais 1024 que ele recebeu.E a sequência e um tal tamanho de janela como tamanho da janela tem 1 kB so, tamanho da janela em1024 Então, que confirmação ele enviará de volta para o remetente.Então, dessa forma todo o procedimento vai em frente e sempre que o emissor estiver enviando alguns dados, quenesta fase o remetente este tem envio de alguns dados de 2 kB de dados. Em seguida, no buffer de remetenteque 2 kB dos dados ainda estão lá até receber esse reconhecimento. Se esta confirmaçãofor perdida, então com base naquele go back N princípio ele irá retransmitir esteinteiro 2 kB de dados que estava lá no buffer do remetente ok.(Consulte o Tempo do slide: 05:17)Então, o algoritmo é bem simples considerando este protocolo de janela deslizante com go backN princípio. Mas há certos truques nele. Vejamos esses truques. Em primeiro lugarconsidere um aplicativo chamado telnet, eu não tenho certeza de quantos de vocês utilizaram telnet.Então, telnet é um aplicativo para fazer uma conexão remota a um servidor. Então, com este aplicativo de telnetvocê pode fazer uma conexão remota de servidor remoto a um servidor e, em seguida, executaros comandos em cima disso.Então, sempre que estiver fazendo essa conexão remota a um servidor e executar os comandossobre isso, digamos que você acabou de escrever “ ls ”, o comando Linux ls para listar todas as diretivasque estão lá na pasta atual. Assim, que o comando ls precisa ser enviar parao lado do servidor sobre a rede porque, ou seja, conexão remota usando telnet que vocêfez.Então, essa conexão telnet ele reage em cada tal keystroke, no pior caso que ele podeacontecer que sempre que um caractere chega na entidade TCP enviando, o TCP ele cria um segmento de 21de TCP, onde 20 byte está lá no cabeçalho e 1 byte de dados. O cabeçalho do segmento TCPé de 20 byte de comprimento, mas telnet está enviando os dados para o byte do servidor porbyte. Por isso, aplicativo de telnet no lado do cliente acaba de receber 1 byte de dados e que 1byte de dados ele está tentando enviar com a ajuda de um segmento TCP.Então, nesse segmento TCP o que vai acontecer, que o lado do segmento TCP contará com 20byte do cabeçalho e apenas 1 byte de dados. Então, você pode simplesmente pensar nisso qual é a quantidadede sobrecaria que você tem. Então, com isso 21 byte de pacote, pacote ou melhor 1 byte desegmento, você está enviando apenas 1 byte de dados. E para este segmento, outra atualização de janela ACK eé enviada quando o aplicativo lê que 1 byte.Então, o aplicativo lê que 1 byte e aplicativo envia de volta uma confirmação.Então, isso resulta em uma enorme desperdício de largura de banda, apenas você não está enviando nenhum dado importantepara o lado do servidor, em vez disso você está enviando quantidade muito pequena de dados e a enorme quantidadede recursos utilizados por causa dos cabeçalhos.(Consulte o Tempo do slide: 07:28)Então, para resolver este problema, utilizamos o conceito chamado confirmação atrasada. Assim, emcaso de confirmação retardada, você retarda as atualizações de confirmação e janelapara até alguma duração 500 milissegundo na esperança de receber poucos pacotes de dadosdentro desse intervalo. Então, ele diz que bem sempre que você está recebendo um caractere do aplicativo de telnet, você não envia imediatamente. Em vez disso você espera por determinada quantidade deduração que é o 500 milissegundos por padrão no TCP. E sua esperança é que por esse tempovocê possa obter mais alguns dados e você poderá enviar um pacote onde com 20kilobyte de desculpe 20 byte de cabeçalho você terá mais de 1 byte de dados.No entanto, neste caso, o remetente ainda pode enviar vários segmentos de dados curtos porque, seo remetente quiser. Então, é exatamente assim sempre que sempre que você está enviando a confirmação de confirmação depara o remetente, você está você está enviando atrasando o reconhecimento. Você está atrasando a confirmação, isso significa, você não estáenviando qualquer confirmação imediata. E um remetente para lembrar que, um remetentea menos que receba uma confirmação com o espaço tampão disponível, o remetente não iráenviar mais dados. Assim, o receptor apenas se mantém esperando que, sempre que obterádados suficientes do remetente ele terá espaço suficiente no receptor, que então apenasele enviará de volta esse reconhecimento ao remetente. Assim, o receptor não iráenviar confirmação imediata ao remetente para evitar que o remetente envie mais dadospara o receptor.(Consulte o Slide Time: 09:01)Bem agora, temos outro algoritmo. Então, no caso anterior o que vimos que bemcom a confirmação atrasada, você está esperando que, a menos que esteja enviando um reconhecimentopara o remetente, o remetente não enviará mais dados. Mas o remetente énão restrito a esse remetente é que sempre que ele obterá dados do aplicativo de telnet eleenviará imediatamente os dados.Agora, para evitar que o remetente envie este tipo de pequenos pacotes ou pequenos segmentos, utilizamoso conceito de algoritmo de Nagle ’. O que é isso? O algoritmo de Nagle ’ conta que, quandoos dados entram no remetente em pequenos pedaços, basta enviar a primeira peça e tampão todo odescansar até o primeiro pedaço de confirmação. Então, é assim mesmo, você recebeu um pequeno segmento de dadosou bytes únicos você recebeu o byte A, você envia aquele byte A deo remetente diz que este é o remetente e este é o seu receptor.E você mantém em buffering todos os caracteres subsequentes A B C D até obter o reconhecimentodo remetente. Então, a esperança aqui é que sempre que você estiver enviandoalgum pacote curto na internet, você não está enviando vários pacotes curtos um apósoutro. Isso significa, você não está enviando um pacote A, packet B, B, pacote C como segmentoA, segmento B, segmento C sobre a rede em vez de apenas um pacote curto serápendente na rede em qualquer instância de tempo.Então, dessa forma até o momento você obterá a confirmação para este pacote A sua expectativaé que, você obterá vários outros caracteres no buffer do remetente. Sempre quevocê estiver obtendo vários outros caracteres de buffer no buffer do remetente, você pode combinareles juntos, construir um único segmento e enviá-lo sobre a rede.(Consulte o Tempo do slide: 10:57)A pergunta vem aqui que queremos usar o algoritmo de Nagle ’ todo o tempo? ComoNagle ’ s Nagle ’ s algoritmo aumentando intencionalmente o atraso na transferência. Assim, se você estiverapenas usando o aplicativo de telredes e aplicando o algoritmo de Nagle ’, o seu tempo de resposta para o aplicativoserá lento. Pois embora você esteja digitando alguma coisa, que o TCP éimpedindo que aquele byte único chegue ao lado do servidor, a menos que ele esteja obtendo um reconhecimentopara o pacote curto anterior.E é por isso que não deseja usar o algoritmo de Nagle ’ para delay application sensível.E há outra observação interessante aqui que, se você implementar o algoritmo de Nagle ’ se o reconhecimento atrasado por completo, o que pode acontecer? Que o algoritmo doNagle ’ o remetente está esperando o reconhecimento. O remetente enviouum pequeno pacote ou um pequeno segmento e o remetente está esperando a confirmação,mas o receptor está atrasando esse reconhecimento. Agora se o receptor está atrasando o reconhecimentoe o remetente está esperando por esse reconhecimento. Assim, o remetentepode ir para a fome e você pode ter uma quantidade significativa ou quantidade considerável deatraso na obtenção da resposta do aplicativo. Então, esse ’ s por que se você estiverimplementa o algoritmo de Nagle ’ e o reconhecimento atrasado por completo, ele pode resultarem um cenário, em que você pode experimentar tempo de resposta lenta da aplicaçãopor causa da inanição.Então, em sentido amplo, o reconhecimento atrasado o que você está fazendo? Você estáevitando que o receptor envie pequenas atualizações de janelas. E você está atrasando esta confirmaçãono lado do receptor com a expectativa de que o emissor iráacumular mais alguns dados no buffer do remetente. E será capaz de enviar o grande segmentoem vez de um pequeno segmento.Considerando que, em caso de algoritmo de Nagle ’ você está apenas aguardando a confirmação de um pequeno segmentocom a expectativa de que por esse tempo o aplicativo irá escrever poucos mais dadospara o buffer emissor e estes dois juntos podem custar uma inanição. Então, esse ’ s por que nósnão queremos implementar reconhecimento atrasado e o algoritmo de Nagle ’ s completamente.(Consulte o Tempo do slide: 13:14)Então, uma solução possível vem de, outro problema nessa mensagem de atualização de janela,que chamaremos como síndrome da janela boba. Então, vamos ver que o que é janela bobasíndrome? Então, é como se esses dados sejam transmitidos para a entidade TCP enviando em bloco grande, masum aplicativo interativo sob o lado do receptor lê dados apenas um byte de cada vez. Assim, éexatamente assim, se você olhar para o lado do receptor, o receptor este é o buffer receptor dizer,este é o buffer receptor.Então, o aplicativo de envio está enviando dados a uma taxa de 10 mbps digamos, o remetente tem muitos dados depara enviar, mas você está executando algum tipo de aplicativo interativo no lado do receptor.Então, ele está recebendo dados a uma taxa muito lenta como a uma taxa de 1 kB por vez ou 1 byte em um horário deo exemplo que é dado aqui em 1 byte de cada vez.Agora, se ele acontece, então, este é o tipo de problema. Inicialmente, digamos que o buffer do receptor esteja cheioquando o buffer do receptor estiver cheio, você está enviando uma confirmação para o remetentedizendo que a confirmação o número de confirmação correspondente seguiupelo valor da janela como 0. Então, o remetente está bloqueado aqui, agora o aplicativo lê 1byte de dados. O aplicativo de momento lê 1 byte de dados; você tem um espaço livre aqui emo buffer. Agora diga, o receptor está enviando outro reconhecimento para o remetentedizendo que o tamanho da janela é 1.Então, se ele enviar este tamanho de janela tamanho pequeno aviso de janela para o remetente, o que o sensorfará? O Sender enviará apenas 1 byte de dados. E uma vez que ele envia 1 byte de dadoscom isso 1 byte de dados novamente o buffer do receptor fica cheio. Então, isso se torna em um loope por causa dessa mensagem de atualização de janela de 1 byte, o remetente é tentado a enviar 1byte de segmento com cada mensagem de atualização de janelas. Então, isso novamente cria o mesmo problemaque estávamos discutindo anteriormente que você está enviando vários segmentos pequenosum atrás do outro.E nós não queremos enviar esses diversos segmentos pequenos, pois ele tem como talum excesso significativo da perspectiva de rede. Ele concebe uma enorme quantidade delargura de banda sem transferir nenhum dado significativo para a ingestão do receptor.(Consulte o Tempo do slide: 15:43)Então, para resolver esse problema, temos uma solução que é proposta por Clark, chamamos como uma solução deClark. Por isso, a solução Clark diz que não enviar atualização de janela para 1 byte,você espera por espaço suficiente está disponível no buffer do receptor. Uma vez que algum espaço suficienteesteja disponível no buffer do receptor então basta você enviar a mensagem de atualização da janela.Agora, a questão vem que o que é a definição do espaço suficiente. Isso depende dena implementação do TCP que se você estiver usando algum espaço de buffer, então você usa certa porcentagemdo espaço de buffer. Se isso se tornar disponível então apenas você envia a mensagem de atualização da janelapara o remetente.
TCP   Flow Control-Parte 2
Bem, aqui o fato interessante é que para dar manuseio de vidro os segmentos curtos noemissor e receptor por completo, que este algoritmo de Nagle ’ e a solução de Clark ’ s solução paraboba de janela boba-eles são complementares, assim como o algoritmo anterior como o algoritmo deNagle ’ e a confirmação atrasada pode criar uma starvation que não vaiacontecer aqui.Então, o algoritmo de Nagle ’ resolve o problema causado pelo aplicativo de envioentregando dados ao TCP 1 byte de uma vez. Então, o envio evita o aplicativo de enviopara enviar pequenos segmentos. Considerando que, a solução Clark, aqui ela impede o aplicativo de recebimentopara envio de atualização de janela de 1 byte por vez. Por isso, o receptor,recebendo aplicativo buscar os dados da camada TCP 1 byte por vez para que vocênão enviará mensagem de atualização de janela imediata.Há certa exceção a isso porque; sempre que estiver aplicando este algoritmo de Nagle ’ se a solução Clark. Novamente ele terá alguma quantidade de atraso na perspectiva do aplicativo. O tempo de resposta do aplicativo ainda será pouco lento, poisvocê está esperando dados suficientes para se acumularem e, em seguida, apenas criar um segmento.Da mesma forma, no lado do receptor você está aguardando dados suficientes para ler pelo aplicativoe então só você enviará a mensagem de atualização da janela, isso pode ainda teralgum tempo de resposta mais alto da perspectiva do aplicativo, pode não ser tão alto quanto como uma inaniçãoque estava lá para o algoritmo de Nagle ’ e confirmação atrasada. Mas, paradeterminados aplicativos dizem por algum aplicativo de tempo real, você quer que os dados sejamtransferidos imediatamente ignorando o algoritmo de Nagle ’ e a solução Clark; nesse casono cabeçalho TCP você pode configurar a sinalização PSH.Então, esta sinalização PSH ele irá ajudá-lo a enviar os dados imediatamente, ele ajudará a tornar informeo remetente a criar um segmento imediatamente, sem esperar por mais dados do lado do aplicativo. Assim, você pode reduzir o tempo de resposta utilizando a sinalização PSH.(Consulte o Tempo do slide: 18:43)Bem agora, a segunda coisa é que o manuseio fora de segmentos de pedidos no TCP. Então, o que o TCPfaz? O espaço de buffer TCP fora de segmentos de pedido e encaminhamento de duplicação. Então, esta é uma parte interessante do TCP este conceito de confirmação deduplicado. Então, o que o TCP faz que sempre que você está recebendo certo fora do segmento de pedidosdigamos por exemplo, eu estou apenas tentando desenhar um sim, então, eu estou tentando dizer que esteé o buffer receptor. No buffer do receptor, recebemos até dizer que este segmento eo receptor é dizer isto é dizer 1024. Ele recebeu até 1023 e está esperando a partir de1024 e você recebeu o segmento de dizer 2048 para outra coisa.Agora, neste caso, sempre que recebeu esse segmento anterior, ele enviou um reconhecimentocom número de sequência como 1024; isso significa, o receptor está esperandoe segmento a partir do byte 1024, mas recebeu este segmento fora de ordem. Então, elecolocará o segmento de fora de ordem no buffer, mas ele voltará a enviar uma confirmaçãocom este mesmo número de sequência, que ele ainda está esperando sequêncianúmero 1024.Então, este reconhecimento chamamos como confirmação duplicada. Então, isso chamou uma confirmação de duplicataou em formato curto DUPACK. Então, este DUPACK, vamos informar o aplicativo remetente que bem ah; ele tem este receptor específico não recebeuo byte a partir de 1024, mas ele recebeu certos outros bytes depois disso.Então, isso tem uma consequência importante no design do algoritmo de controle de congestionamento TCP.Então, olhamos para os detalhes desta consequência, quando discutimos sobre o algoritmo de controle de congestionamento TCPna próxima classe.(Consulte o Tempo do slide: 21:14)Então, aqui está um exemplo, digamos que o receptor recebeu os bytes 0 1 2 e ele nãorecebeu os bytes 3 e depois recebeu o recebimento bytes 4 5 6 7. Assim, o TCP envia um reconhecimento decumulativo com confirmação número 2 que reconhece tudo em cimaaté o byte 2.Então, uma vez que este quatro é recebido um ACK duplicado com confirmação número 3 que éo próximo byte esperado ele é encaminhado. Isso aciona um algoritmo de controle de congestionamento queolhamos para os detalhes na próxima classe, após o tempo fora o remetente retransmite o byte 3. Então,sempre que o remetente está retransmitindo o byte 3 então, você recebeu o byte 3 aqui.Então, o momento em que você recebeu o byte 3 aqui, você basicamente recebeu todos os bytesaté o byte 7. Assim, você pode enviar outra confirmação cumulativa comconfirmação número 8; isso significa que você recebeu tudo até 7 e agoravocê está esperando o byte 8 para receber ok.(Consulte o Slide Time: 22:15)TCP tem implementação de timers múltiplos. Então, vamos olhar para esses cronômeros em detalhes. Então,um cronômetro importante ele é tempo limite de retransmissão TCP ou TCP, chamamos de curto formato TCPRTO. Então, esse tempo limite de retransmissão ajuda no algoritmo de controle de fluxo. Assim, sempre que um segmentoé enviado, este cronômetro de retransmissão é iniciado se o segmento for reconhecido assim, seo segmento for reconhecido antes do temporizador expirar o cronômetro for interrompido e se o cronômetroexpirar antes da confirmação chegar, o segmento será retransmitido. Então, uma vez quevocê transmitiu um segmento do lado emissor você inicia o cronômetro, digamos dentro destetimeout se você receber a confirmação, então você recomeça o cronômetro senão uma veztimeout ocorre, então você retransmite esse segmento.Então, o tempo limite ocorre significa, algo ruim aconteceu na rede esimultaneamente ele também aciona o algoritmo de controle de congestionamento que discutiremosdurante a discussão do algoritmo de controle de congestionamento, mas também retransmite o segmento deperdido. Assim, se ele não receber a confirmação dentro do tempo limite, ele assumeque o segmento perdeu.(Consulte o Tempo do slide: 23:36)Agora, vem a questão de que o que pode ser um valor ideal para este tempo limite de retransmissão. Então,como você vai dizer esse tempo limite de retransmissão? Então, uma solução possível é que para estimar o tempo de viagem de volta doporque, você enviou um segmento e está esperando oreconhecimento correspondente. Assim, idealmente se tudo é bom na rede, entãoessa transmissão do segmento e a transmissão de confirmação ela levará um tempo de viagem de ida e volta.Então, é um tempo de viagem redondo que espera-se que consiga tudo, mas por causa da redeatraso e algo, você pode pensar nisso bem irei configurar o tempo limite de retransmissão paraalguns múltiplos positivos de RTT. Alguns n x RTT onde n pode chegar a 2, 3; algo assimbaseado em sua escolha de design. Mas então a pergunta vem de como você faz uma estimativado RTT? Porque sua rede é realmente dinâmica e esta estimativa do RTT é umdifícil para camada de transporte. Então, vamos ver que por que é difícil para a camada de transporte.(Consulte o Slide Time: 24:32)Então, se fazemos um enredo algo assim somos nós estamos tentando traçar o RTT, o tempo de viagem de volta doe a camada de link de dados e a camada de transporte. Então, a diferença é que emcaso de camada de link de dados, você tem dois nós diferentes, que são conectados diretamente via link. Então, se esses dois nós diferentes estiverem diretamente conectados via link. Então, quanto tempovai levar para enviar a mensagem e voltar a responder a resposta.Mas em caso de sua camada de rede, no entre os dois nós você tem toda essa internete depois e outro nó e então você está tentando estimar que, se você está enviando uma mensagempara este host end e receber de volta uma resposta qual é a média de tempo de ida que eleestá tomando.Agora, se nós apenas plotamos esse tempo de ida e volta, vamosver que a variação não é muito alta sempre que você estiver no link de dados aqui porque, ele éapenas o link único e nesse link único essa dinamicidade é muito menor porque, a dinamicidadeé muito menor para um único link você pode fazer uma boa estimação, se você pegar a média decom essa média nós lhe daremos uma boa estimativa desse tempo de viagem redondo.(Consulte o Tempo do slide: 25:37)Mas isso não é verdade para a camada de transporte, em caso de camada de transporte, pois há lotesde variabilidade em entre esta rede intermediária entre o emissor e o receptor.Então, seu tempo de viagem redondo varia significativamente para que a variância em tempo de viagem redonda seja muito.Então, se você apenas pegar uma média, a média nunca lhe dará uma estimativa correta podeacontecer isso bem, o valor real cai em algum lugar aqui e há um significativodesviado da média. E se você configurar tempo limite de retransmissão considerando queestimação RTT você obterá algum RTO ’ s. Então, a solução aqui é que você usa um algoritmo dinâmicoque constantemente adota o intervalo de tempo limite, com base em alguma medição contínua dedo desempenho da rede.(Consulte o tempo de deslizamento: 26:27)Então, como você fará isso? Por isso, para fazer isso temos algo chamado algoritmo Jacobsonproposto em 1988 que é usado no TCP. Assim, o algoritmo de Jacobson diz quepara cada conexão, o TCP mantém são variáveis chamadas SRTT a forma completa é SmoothedRound Trip Tempo que é a melhor estimativa atual do tempo de viagem redonda para o destino.Agora, sempre que seu segmento sempre que estiver enviando um segmento você inicia um timer. Então,este temporizador tem dois propósitos diferentes como pode você pode ser usado para acionar o tempo limitee ao mesmo tempo ele pode ser usado para descobrir que quanto tempo leva para receber a confirmação.(Consulte o Tempo do slide: 27:09)Então, sempre que você tiver enviado uma mensagem enviada uma mensagem diga que este é o emissor, este é o receptorque você envia o segmento e você tem início o cronômetro. Assim, o cronômetro o relógiovai se manter em tique-taque. Então, se você receber o reconhecimento aqui então neste estágio vocêpode pensar nisso bem isso o timer pára aqui e esta diferença vai dar uma estimativa dede tempo de viagem redondo. Mas se você não receber essa confirmação, então depois dealgum tempo limite esse cronômetro expirar digamos, aqui e uma vez que o timer expira, você retransmite o segmento.Então, ele pode ser usado para duas finalidades diferentes este o mesmo cronômetro. Então, ah, então, você medeo tempo se recebe de volta uma confirmação e atualiza o SRTT da seguinte forma.Então, o SRTT seria algum alfa vezes a estimação anterior de SRTT mais 1 menosalfa desse valor medido R. Então, este algoritmo este mecanismo chamamos comoexponencialmente ponderada em movimento médio ou EWMA. Agora alpha é um fator defumado quedetermina que quão rapidamente os valores antigos são esquecidos como que peso você está indopara dar nos valores antigos tipicamente em caso de TCP Jacobson configurar este alfa para um valor de 7por 8.(Consulte o Tempo do slide: 28:39)Agora, este algoritmo de EWMA tem um problema como; mesmo você dá um bom valor de SRTT,escolher um RTO adequado é não trivial. Como a implementação inicial do TCP usouRTO igual a dois tempos de SRTT, mas descobriu-se que ainda há uma quantidade significativa de variância digamos ah, a partir da experiência prática as pessoas viram que um valor constante de, este valor constante de RTO ele é muito inflexível porque, ele falha em resposta quandoa variância subiu.Então, se o seu RTT tiver um RTT medido tem excesso de desvio em relação ao RTT estimado,então você obterá o RTO espúrio. Então, caso sua flutuação RTT seja alta você podelevar a um problema. Então, ele acontece normalmente em alta carga então quando sua carga de rede émuito alta sua flutuação RTT vai se tornar alta.Então, nesse caso, a solução é que além da média um, você considera a variânciado RTT durante a estimação de RTO. Agora como consideramos a variância do RTT?Agora, outra pergunta vem que é como se você obterá a estimativa do RTT quando um segmentoé perdido e retransmitido novamente. Se um segmento perdeu e se retransmitiu novamente,então você não obterá a estimativa adequada do RTT porque esse segmento que você temtransmitiu o segmento. Então, o segmento perdeu você começou o temporizador aqui. Então,há um tempo limite você novamente após o tempo limite nós transmitimos o segmento e você obteve a confirmação.Então, há outros timers TCP como este timer TCP persistente, que evitam deadlock quandobuffer receptor é anunciado como 0. Assim, após o cronômetro sair do remetente encaminha um pacote de análisepara o receptor para obter o tamanho da janela atualizado, há algo chamado deKeepalive timer. Então, este timer Keepalive ele fecha a conexão quando uma conexão temficar ocioso por uma longa duração. Então, você configurou uma conexão em não enviar nenhum dado.Então, após este temporizador Keepalive ele irá para fora e então o estado de espera de tempo que temosvisto em caso de encerramento de conexão. Então, você espera antes de fechar uma conexão que está emgeral duas vezes o tempo de vida do pacote.Então, isso tudo é sobre o algoritmo de controle de fluxo e diferente conjunto de seus valoresdo temporizador TCP. Na próxima aula temos nós ’ ll ver como aplicamos esta perda ou duplicataconfirmação que vimos aqui para o gerenciamento de congestionamento de TCP.Obrigado a todos por assisti-los a esta classe.