TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581 ponto a ponto:

Apresentação em tema: "TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581 ponto a ponto:"— Transcrição da apresentação:

1 TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581 ponto a ponto:
1 remetente, 1 receptor fluxo de bytes, ordenados, confiável: não estruturado em msgs dutado: tam. da janela ajustado por controle de fluxo e congestionamento do TCP buffers de envio e recepção transmissão full duplex: fluxo de dados bi-direcional na mesma conexão MSS: tamanho máximo de segmento orientado a conexão: handshaking (troca de msgs de controle) inicia estado de remetente, receptor antes de trocar dados fluxo controlado: receptor não será afogado TCP comunicação TCP  Não é possível comunicação multicast. MSS  Tamanho máximo da sequência de bytes que se obtém da camada de aplicação para montar segmento TCP. MSS é configurável, normalmente 1500 bytes, 536 ou 512 bytes. Valores atribuídos para evitar fragmentação do datagrama IP. Os roteadores não tem mínimo conhecimento sobre a existência de conexão TCP. TCP considera fluxo de bytes e não leva em consideração a codificação utilizada. 3: Camada de Transporte

2 TCP: estrutura do segmento
no. porta origem no. porta dest 32 bits dados da aplicação (tam. variável) número de seqüência número de reconhecimento janela receptor ptr dados urg. checksum F S R P A U tam. cab. sem uso Opções (tam. variável) URG: dados urgentes (pouco usados) contagem de dados por bytes (não segmentos!) ACK: no. ACK válido PSH: envia dados já (pouco usado) no. bytes rcpt quer aceitar RST, SYN, FIN: gestão de conexão (comandos de estabelecimento, liberação) Cabeçalho 20 bytes caso não haja nenhuma opção. Janela do receptor  usada para controle de fluxo. Se bit urgent estiver setado, o valor do ponteiro de dados urgentes é adicionado ao número de seqência para se obter a posição do último byte que deve ser passado como dados urgentes. Possíveis opções: Negociação do MSS  deve refletir o tamanho máximo dos quadros utilizados em redes diferentes. Deve-se evitar fragmentação de um segmento pois a perda de um fragmento corrompe o pacote. MSS pequeno  baixa utilização da rede. Tamanho ideal  maior possível que evite fragmentação  difícil descobrir pois datagrama pode seguir caminhos diferentes. Fator de escola de tamanho de janela em redes de alta velocidade. Timestamp. Aplicações típicas que utilizam o dados urgentes são TELNET e RLOGIN. Exemplo: Notificar ao servidor a interrupção da transferência de um arquivo. Caso emissor envie mais de um segmento com dados urgentes o receptor irá considerar somente o último segmento urgente. Dados urgentes não significa sinalização out-of-band. Para se ter sinalização out-of-band deve se ter uma conexão extra. checksum Internet (como UDP) 3: Camada de Transporte

3 cenário simples de telnet
TCP: nos. de seq. e ACKs Nos. de seq.: “número”dentro do fluxo de bytes do primeiro byte de dados do segmento ACKs: no. de seq do próx. byte esperado do outro lado ACK cumulativo P: como receptor trata segmentos fora da ordem? R: espec do TCP omissa - deixado ao implementador Estação A Estação B Usuário tecla ‘C’ Seq=42, ACK=79, data = ‘C’ B reconhece chegada de ‘C’, ecoa ‘C’ de volta Seq=79, ACK=43, data = ‘C’ A reconhece chegada do ‘C’ ecoado Seq=43, ACK=80 tempo cenário simples de telnet 3: Camada de Transporte

4 TCP: transferência confiável de dados
event: data received from application above remetente simplificado, supondo: create, send segment fluxo de dados uni-direcional sem controle de fluxo, congestionamento wait for event wait for event event: timer timeout for segment with seq # y retransmit segment event: ACK received, with ACK # y ACK processing 3: Camada de Transporte

5 TCP: transfe-rência confiável de dados
00 sendbase = número de seqüência inicial 01 nextseqnum = número de seqüência inicial 02 loop (forever) { switch(event) event: dados recebidos da aplicação acima cria segmento TCP com número de seqüência nextseqnum inicia temporizador para segmento nextseqnum passa segmento para IP nextseqnum = nextseqnum + comprimento(dados) event: expirado temporizador de segmento c/ no. de seqüência y retransmite segmento com número de seqüência y calcula novo intervalo de temporização para segmento y reinicia temporizador para número de seqüência y event: ACK recebido, com valor de campo ACK de y se (y > sendbase) { /* ACK cumulativo de todos dados até y */ cancela temporizadores p/ segmentos c/ nos. de seqüência < y sendbase = y } senão { /* é ACK duplicado para segmento já reconhecido */ incrementa número de ACKs duplicados recebidos para y if (número de ACKs duplicados recebidos para y == 3) { /* TCP: retransmissão rápida */ reenvia segmento com número de seqüência y reinicia temporizador para número de seqüência y } } /* fim de loop forever */ TCP: transfe-rência confiável de dados Remetente TCP simplificado 3: Camada de Transporte

6 TCP geração de ACKs [RFCs 1122, 2581]
Evento chegada de segmento em ordem sem lacunas, anteriores já reconhecidos 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 p/ 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 Note que: Linha 09  o número de sequência é incrementado de um valor igual ao tamanho do segmento. Linha 12  o intervalo de temporização não é fixo, ele é sempre recalculado. Linha 16  reconhecimento é cumulativo, isto é, todos os temporizadores para segmentos < Y são desligados. 3: Camada de Transporte

7 TCP: cenários de retransmissão
Host A Estação A Estação B Host B Seq=92, 8 bytes de dados Seq=92, 8 bytes de dados Seq=100, 20 bytes de dados ACK=100 Temp.p/ Seq=92 temporização X ACK=100 Temp. p/ Seq=100 ACK=120 perda Seq=92, 8 bytes de dados Seq=92, 8 bytes de dados ACK=120 ACK=100 tempo tempo cenário do ACK perdido temporização prematura, ACKs cumulativos 3: Camada de Transporte

8 TCP: Controle de Fluxo controle de fluxo
receptor: explicitamente avisa o remetente da quantidade de espaço livre disponível (muda dinamicamente) campo RcvWindow no segmento TCP remetente: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, menor que o valor mais recente de RcvWindow remetente não esgotaria buffers do receptor por transmitir muito, ou muito rápidamente RcvBuffer = tamanho do Buffer de recepção RcvWindow = espaço vazio no Buffer Caso o receptor não tenha nenhum dado para enviar do emissor após anunciar que sua janela de recepção está cheia, o emissor fica bloqueado pois não sabe quanto espaço foi liberado no buffer do receptor. Solução : o emissor envia sempre um byte de dados mesmo que o receptor tenha anunciado que o buffer de recepção está cheio. O TCP retarda o anúncio de janelas pequenas após ter anunciado uma janela de tamanho zero. Espera ter no mínimo um MSS ou 50 % do buffer (dependente da implementação). buffering pelo receptor 3: Camada de Transporte

9 TCP: Tempo de Resposta (RTT) e Temporização
P: como escolher valor do temporizador TCP? maior que o RTT note: 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, segmentos com ACKs cumulativos RTTamostra vai variar, queremos “amaciador” de RTT estimado usa várias medições recentes, não apenas o valor corrente (RTTamostra) 3: Camada de Transporte

10 TCP: Tempo de Resposta (RTT) e Temporização
RTT_estimado = (1-x)* RTT_estimado + x*RTT_amostra média corrente exponencialmente ponderada influência de cada amostra diminui exponencialmente com o tempo valor típico de x: 0.1 Escolhendo o intervalo de temporização RTT_estimado mais uma “margem de segurança” variação grande em RTT_estimado -> margem de segurança maior Reconhecimentos de retransmissões não são utilizados para estimar o tempo de temporização. Tempo de temporização é multiplicado por um certo valor, usualmente 2 (dobrado) a cada nova retransmissão  algoritmo Backoff de Karn. Valor máximo para temporização pode ser atribuído usualmente 9 mim. Temporização = RTT_estimado + 4*Desvio Desvio = (1-x)* Desvio + x*|RTT_amostra - RTT_estimado| 3: Camada de Transporte

11 TCP: Gerenciamento de Conexões
Lembrete: Remetente, receptor TCP estabelecem “conexão” antes de trocar segmentos de dados inicializam variáveis TCP: nos. de seq. buffers, info s/ controle de fluxo (p.ex. RcvWindow) cliente: iniciador de conexão Socket clientSocket = new Socket("hostname","port number"); servidor: contactado por cliente Socket connectionSocket = welcomeSocket.accept(); Inicialização em 3 tempos: Passo 1: sistema cliente envia segmento de controle SYN do TCP ao servidor especifica no. inicial de seq Passo 2: sistema servidor recebe SYN, responde com segmento de controle SYNACK reconhece SYN recebido aloca buffers especifica no. inicial de seq. servidor-> receptor 3: Camada de Transporte

12 TCP: Gerenciamento de Conexões (cont.)
Encerrando uma conexão: cliente fecha soquete: clientSocket.close(); Passo 1: sistema cliente envia segmento de controle FIN ao servidor Passo 2: servidor recebe FIN, responde com ACK. Encerra a conexão, enviando FIN. cliente servidor fechar FIN ACK fechar FIN ACK espera temporizada fechada 3: Camada de Transporte

13 TCP: Gerenciamento de Conexões (cont.)
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. Note: com pequena modificação, consegue tratar de FINs simultâneos. cliente servidor fechando FIN ACK fechando FIN ACK espera temporizada fechada fechada 3: Camada de Transporte

14 TCP: Gerenciamento de Conexões (cont.)
Ciclo de vida de servidor TCP Ciclo de vida de cliente TCP 3: Camada de Transporte

15 Princípios de Controle de Congestionamento
informalmente: “muitas fontes enviando muitos dados muito rapidamente para a rede poder tratar” diferente de controle de fluxo! manifestações: perda de pacotes (esgotamento de buffers em roteadores) longos atrasos (enfileiramento nos buffers dos roteadores) um dos 10 problemas mais importantes em redes! Handshaking de três vias para estabelecimento de conexão  é necessário que ambas as partes conheçam os números de sequência para começar a transmissão. Algumas implementações permitem envio de dados com segmento SYN. No entanto, estes dados só são entregues aplicação depois de finalizado o three-way handshaking. Conexão TCP é full-duplex  uma das partes pode encerrar a comunicação. Neste caso a parte que encerrou não pode mais enviar dados mas tem que receber dados da outra parte. Para encerrar conexão em uma direção é enviado segmento FIM que deve ser reconhecido. Para encerrar conexão nos dois sentidos o procedimento é repetido. Caso uma das partes já tenha encerrado a conexão em uma direção e receba um FIM da outra parte encerrando a conexão, um reconhecimento é enviado e espera-se um tempo para encerrar conexão (estado TIME-WAIT). Este tempo é dito 2MSL e corresponde a duas vezes o “maximum segment life”. O 2MSL depende da implementação e pode ser 30 seg, 1 mim, 2 mim. Uma conexão pode ser abortada abruptamente pelo envio do segmento como bit de cabeçalho RST com valor 1. O TCP processa normalmente eventos nos quais duas partes solicitam simultaneamente o encerramento da conexão. Uma conexão TCP pode existir indefinidamente sem a troca de segmentos. Para evitar situações em que uma das partes reiniciou devido a um “power-off” ou uma das partes está inacessível, causando uma “conexão-metade”, ou seja, uma conexão que existe apenas um end-system, utiliza-se o temporizador keep-alive. O temporizador keep-alive não faz parte do padrão Após não receber segmentos por 2 horas, envia-se um segmento de “probe”. Temporiza-se por 75 segundos e caso não haja resposta, repete-se o procedimento mais 9 vezes a assume-se que a conexão não existe mais caso não se tenha obtido nenhum reconhecimento para o “probe”. Caso uma das partes receba um “probe”de keep-alive para conexão inexistente, envia uma resposta de RESET. O TCP acumula dados enviados pela aplicação para formar segmentos maiores, evitando assim o desperdício de banda passante com segmentos pequeneos O TCP acumula até receber o reconhecimento do segmento anterior  algoritmo de Nagle. O algoritmo de Nagle não reduz a vazão de aplicações com grande quantidade de dados, porém adapta a taxa de envio de pequenos segmentos à condição congestionamento da rede, ou seja, o recebimento de um reconhecimento em curto intervalo de tempo implica que a rede não está tão congestionada e não é tão drástico enviar segmentos pequenos. 3: Camada de Transporte

16 Causas/custos de congestionamento: cenário 1
dois remetentes, dois receptores um roteador, buffers infinitos sem retransmissão grandes retardos qdo. congestionada vazão máxima alcançável 3: Camada de Transporte

17 Causas/custos de congestionamento: cenário 2
Um roteador, buffers finitos retransmissão pelo remetente de pacote perdido 3: Camada de Transporte

18 Causas/custos de congestionamento: cenário 2
l in out = sempre: (“goodput”) retransmissão “perfeito” apenas quando perda: retransmissão de pacote atrasado (não perdido) faz maior (que o caso perfeito) para o mesmo l in out > l in l out “custos” de congestionamento: mais trabalho (retransmissão) para dado “goodput” retransmissões desnecessárias: enviadas múltiplas cópias do pacote 3: Camada de Transporte

19 Causas/custos de congestionamento: cenário 3
quatro remetentes caminhos com múltiplos enlaces temporização/retransmissão P: o que acontece à medida que e crescem ? l in l in 3: Camada de Transporte

20 Causas/custos de congestionamento: cenário 3
Outro “custo” de congestionamento: quando pacote é descartado, qq. capacidade de transmissão já usada (antes do descarte) para esse pacote foi desperdiçado! 3: Camada de Transporte

21 Abordagens de controle de congestionamento
Duas abordagens amplas para controle de congestionamento: Controle de congestionamento fim a fim : não tem realimentação explícita pela rede congestionamento inferido das perdas, retardo observados pelo sistema terminal abordagem usada pelo TCP Controle de congestionamento com apoio da rede: roteadores realimentam os sistemas terminais bit único indicando congestionamento (SNA, DECbit, TCP/IP ECN, ATM) taxa explícita p/ envio pelo remetente 3: Camada de Transporte

22 Estudo de caso: controle de congestionamento no ABR da ATM
ABR: available bit rate: “serviço elástico” se caminho do remetente “sub-carregado”: remetente deveria usar banda disponível se caminho do remetente congestionado: remetente reduzido à taxa mínima garantida células RM (resource management): enviadas pelo remetente, intercaladas com células de dados bits na célula RM iniciados por comutadores (“apoio da rede”) bit NI: não aumente a taxa (congestionamento moderado) bit CI: indicação de congestionamento células RM devolvidos ao remetente pelo receptor, sem alteração dos bits 3: Camada de Transporte

23 Estudo de caso: controle de congestionamento em ABR da ATM
Campo ER (explicit rate) de 2 bytes na célula RM comutador congestionado pode diminuir valor ER na célula taxa do remetente assim ajustada p/ menor valor possível entre os comutadores do caminho bit EFCI em células de dados ligado por comutador congestionado se EFCI ligado na célula de dados antes da célula RM, receptor liga bit CI na célula RM devolvida 3: Camada de Transporte

24 TCP: Controle de Congestionamento
controle fim a fim (sem apoio da rede) taxa de transmissão limitada pela tamanho da janela de congestionamento, Congwin: Congwin w segmentos, cada um c/ MSS bytes, enviados por RTT: throughput = w * MSS RTT Bytes/sec 3: Camada de Transporte

25 TCP: Controle de Congestionamento
“sondagem” para banda utilizável: idealmente: transmitir o mais rápido possível (Congwin o máximo possível) sem perder pacotes aumentar Congwin até perder pacotes (congestionamento) perdas: diminui Congwin, depois volta a à sondagem (aumento) novamente duas “fases” partida lenta evitar congestionamento variáveis importantes: Congwin threshold: define limiar entre fases de partida lenta, controle de congestionamento 3: Camada de Transporte

26 TCP: Partida lenta Algoritmo Partida Lenta inicializa: Congwin = 1
Estação A Estação B Algoritmo Partida Lenta um segmento inicializa: Congwin = 1 for (cada segmento c/ ACK) Congwin++ until (evento de perda OR CongWin > threshold) RTT dois segmentos quqtro segmentos aumento exponencial (por RTT) no tamanho da janela (não muito lenta!) evento de perda: temporizador (Tahoe TCP) e/ou três ACKs duplicados (Reno TCP) tempo 3: Camada de Transporte

27 TCP: Evitar Congestionamento
/* partida lenta acabou */ /* Congwin > threshold */ Until (event de perda) { cada w segmentos reconhecidos: Congwin++ } threshold = Congwin/2 Congwin = 1 faça partida lenta Por que a reação ao triple duplicate (redução da janela à metade) não é tão drástica quanto a reação ao timeout? Porque a triple duplicate indica que apesar de um pacote ter sido perdido os seguimentos contimuam fluindo para o receptor! 1 1: TCP Reno pula partida lenta (recuperação rápida) depois de três ACKs duplicados 3: Camada de Transporte

28 AADM Justeza do TCP TCP congestion avoidance:
AADM: aumento aditivo, decremento multiplicativo aumenta janela em 1 por cada RTT diminui janela por fator de 2 num evento de perda Meta de justeza: se N sessões TCP compartilham o mesmo enlace de gargalo, cada uma deve ganhar 1/N da capacidade do enlace TCP conexão 1 Roteador gargalo capacidade R TCP conexão 2 3: Camada de Transporte

29 Por quê TCP é justo? Duas sessões concorrentes:
Aumento aditivo dá gradiente de 1, enquanto vazão aumenta decrementa multiplicativa diminui vazão proporcionalmente R compartilhamento igual da banda perda: diminui janela por fator de 2 evitar congestionamento: aumento aditivo Vazão da conexão 2 perda: diminui janela por fator de 2 evitar congestionamento: aumento aditivo Vazão da conexão 1 R 3: Camada de Transporte

30 TCP: modelagem de latência
Notação, suposições: Supomos um enlace entre cliente e servidor de taxa R Supomos: janela de congestionamento fixo, W segmentos S: MSS (bits) O: tamanho do objeto (bits) sem retransmissões (sem perdas, sem erros) P: Quanto tempo custa para receber um objeto de um servidor WWW depois de enviar o pedido? Estabelecimento de conexão TCP retardo de transferência de dados Dois casos a considerar: WS/R > RTT + S/R: ACK do primeiro segmento na janela chega antes de enviar todos dados na janela WS/R < RTT + S/R: aguarda ACK depois de enviar todos os dados na janela 3: Camada de Transporte

31 TCP: modelagem de latência
K:= O/WS Caso 1: latência = 2RTT + O/R Caso 2: latência = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] 3: Camada de Transporte

32 TCP: modelagem de latência: partida lenta
Agora supomos que a janela cresce à la partida lenta. Mostramos que a latência de um objeto de tamanho O é: onde P é o número de vezes TCP para no servidor: - onde Q é o número de vezes que o servidor pararia se o objeto fosse de tamanho infinito. - e K é o número de janelas que cobrem o objeto. 3: Camada de Transporte

33 TCP: modelagem de latência: partida lenta (cont.)
Exemplo: O/S = 15 segmentos K = 4 janelas Q = 2 P = mín{K-1,Q} = 2 Servidor para P=2 vezes. 3: Camada de Transporte

34 TCP: modelagem de latência: partida lenta (cont.)
3: Camada de Transporte

35 Capítulo 3: Resumo Princípios atrás dos serviços da camada de transporte: multiplexação/ demultiplexação transferência confiável de dados controle de fluxo controle de congestionamento instanciação e implementação na Internet UDP TCP Próximo capítulo: saímos da “borda” da rede (camadas de aplicação e transporte) entramos no “núcleo”da rede 3: Camada de Transporte