Transporte, TCP e congestionamento
Portas, UDP, sequência TCP, ACK, temporizadores, janelas e controlo de congestionamento.
Dois clientes podem comunicar com a porta 80 do mesmo servidor, pois TCP distingue as ligações pelo conjunto IP e porta de origem, IP e porta de destino. As portas permitem entregar dados ao socket correspondente dentro do terminal e não identificam globalmente um programa.
UDP e TCP
UDP acrescenta um cabeçalho de 8 bytes com portas, comprimento e checksum. Não estabelece ligação, não garante entrega ou ordem, e preserva limites dos datagramas. A aplicação pode acrescentar os mecanismos de que precise.
TCP oferece fluxo de bytes fiável e ordenado enquanto a ligação funciona, recuperando perdas com retransmissões; uma falha persistente termina a ligação e é comunicada à aplicação. Não preserva fronteiras de send: dois envios podem chegar numa leitura e um envio pode exigir várias leituras, por isso delimita as tuas mensagens por comprimento ou outra regra.
Escolher UDP não garante baixa latência, tal como usar TCP não garante um débito fixo. DNS pode usar UDP ou TCP; HTTP/3 usa QUIC sobre UDP. A escolha deve considerar o protocolo concreto, os mecanismos acima do transporte e o modelo do exercício.
Sequência, ACK e abertura
TCP numera bytes, não segmentos. Se um segmento começa em 1000 com 300 bytes, o seguinte começa em 1300. Um ACK 1300 confirma tudo antes e pede o próximo. SYN e FIN consomem um cada; um ACK simples não consome.
A abertura normal tem SYN, SYN-ACK e ACK:
Depois deste exemplo, o primeiro byte do cliente tem número 101. Se enviar 200 bytes e depois 100, os segmentos começam em 101 e 301, e após ambos o servidor confirma 401; a numeração do servidor é independente.
Perda. Chegam bytes 1000–1299 e 1600–1899, mas faltam 1300–1599, por isso o ACK cumulativo continua em 1300. Quando chegam os bytes em falta, pode avançar para 1900. SACK, se negociado, permite indicar blocos recebidos fora de ordem sem alterar o significado do ACK cumulativo. Os intervalos incluem os dois extremos (1000–1299 contém 300 bytes); ACK 1300 refere-se ao próximo byte esperado, que ainda não foi recebido.
Não foi possível carregar a animação. Abre o vídeo ou acompanha a descrição abaixo.
O fecho usa FIN em cada direção e respetivas confirmações. Um lado pode terminar os seus envios sem que o outro já tenha terminado. TIME-WAIT ajuda a lidar com segmentos atrasados e com a confirmação final; não é uma retransmissão de dados em curso.
Timeout e estimativa de RTT
O tempo de ida e volta varia: um temporizador muito curto retransmite dados ainda em trânsito e um muito longo demora a recuperar perdas. Uma estimativa suavizada usa amostras de RTT e uma medida de variação. SRTT é a estimativa suavizada do RTT, RTTVAR mede a sua variação e RTO é o tempo até à retransmissão. Pela RFC6298, atualiza primeiro RTTVAR e depois SRTT, com pesos 1/4 e 1/8, e usa com mínimo recomendado de 1 s. Amostras de segmentos retransmitidos seguem o algoritmo de Karn: ignoram-se quando a ambiguidade permanece.
Sejam a SRTT anterior e a RTTVAR anterior. Com amostra nova , calcula primeiro a variação , usando a média anterior no desvio absoluto:
Só depois atualiza a média para :
Por exemplo, SRTT=100 ms, RTTVAR=20 ms e amostra 140 ms dão RTTVAR nova ms e SRTT nova ms. Com granularidade G=1 ms, a expressão dá RTO=205 ms; aplicando o mínimo recomendado, usa-se 1 s. Se o exercício indicar outro mínimo, aplica essa condição explicitamente.
Não uses indiscriminadamente uma amostra de uma transmissão repetida: pode ser impossível distinguir a que envio corresponde o ACK, problema tratado pelo algoritmo de Karn. Expirar o timeout aumenta a espera antes de tentar de novo. ACKs duplicados podem desencadear retransmissão rápida sem esperar pelo timeout, conforme a variante.
Fluxo e congestionamento
Com bytes de janela efetiva e RTT de segundos, o limite ideal por janela é bit/s. O débito também não excede o estrangulamento do caminho. Para W=64000 bytes e RTT=0,08 s, obténs 6,4 Mbit/s. Se a ligação limitar a 5 Mbit/s, o menor limite passa a 5 Mbit/s.
Repara na divisão de trabalho: o controlo de fluxo gere o espaço no recetor, anunciado em cada ACK pela janela rwnd; o controlo de congestionamento gere a capacidade da rede, estimada pelo emissor na janela cwnd. Um recetor ligado por uma ligação lenta não é um problema de fluxo, mas de congestionamento no router antes dessa ligação: o emissor tem de descobrir a capacidade do estrangulamento, não apenas respeitar o espaço anunciado.
Slow start, AIMD e perdas
MSS é o máximo de dados num segmento, sem cabeçalhos TCP ou IP. Uma janela de 8 MSS só corresponde a oito segmentos quando todos transportam MSS bytes; com segmentos menores, cabem mais segmentos na mesma janela em bytes. ssthresh é o limiar entre fases de crescimento.
No TCP clássico, slow start aumenta a janela por ACK, aproximadamente duplicando-a por RTT quando cada segmento é confirmado e há dados suficientes. Ao atingir ssthresh, congestion avoidance aumenta aproximadamente um MSS por RTT, crescimento aditivo.
Na variante Reno usada em muitos exercícios, três ACKs duplicados desencadeiam fast retransmit e fast recovery: define-se ssthresh=max(FlightSize/2,2 MSS), retransmite-se o segmento em falta e a janela passa por ssthresh+3 MSS antes de regressar a ssthresh em ACK novo. Um timeout volta a uma janela de perda pequena e reinicia slow start. Por exemplo, com 12 MSS em voo, o limiar cai para 6 MSS. Após três ACKs duplicados, cwnd passa temporariamente a 9 MSS e regressa a 6 MSS quando chega o ACK de recuperação. Num timeout, é a janela cwnd, não o limiar, que cai para 1 MSS no modelo clássico. Não reduzas a janela para o mesmo valor em qualquer tipo de perda.
Traço simplificado. Janela inicial 1 MSS, limiar 8 MSS, ACK por segmento, sem perdas: por rondas, 1, 2, 4, 8, 9, 10. Se o exercício definir outra janela inicial, delayed ACKs ou outra variante, usa essas condições. TCP atual não usa necessariamente este traço nem uma janela inicial de um segmento.
A combinação de aumento aditivo e redução multiplicativa é AIMD. Perdas podem resultar de congestionamento ou de erros do canal. A resposta à perda não identifica sempre a causa real; ECN permite sinalizar congestionamento sem depender só de descartar pacotes.
O vídeo seguinte associa cada mudança da janela TCP ao evento que a provoca; repara em que acontecimento (ACK novo, ACK duplicado ou timeout) faz a janela crescer, cair para metade ou recomeçar em baixo.
Ler uma captura
No Wireshark, segue um fluxo TCP e regista sequência, ACK, comprimento dos dados, flags e janela. A apresentação pode usar números relativos, distintos dos valores brutos; se dois segmentos se perderem, desenha os bytes em falta antes de prever confirmações. A aplicação só recebe uma sequência contínua, mesmo que a captura já mostre segmentos posteriores.
Para praticar, usa um traço de TCP disponibilizado para estudo ou uma captura tua autorizada e compara com o percurso das aplicações.
Exercícios
Classificar o serviço de UDP
Que serviço recebe UDP da camada de rede IPv4?
Pista
Separa garantia de entrega de existência de ligação.
Solução
Não fiável e não orientado a ligações.
- Não fiável e não orientado a ligações.. UDP não estabelece ligação nem garante entrega ou ordem.
- Fiável e não orientado a ligações.. Sem ligação não há confirmações nem sequência para garantir entrega.
- Fiável e orientado a ligações.. Essa é a combinação de TCP, não de UDP.
Distinguir fluxo de congestionamento
Para que serve o controlo de fluxo no TCP?
Pista
Pergunta quem fica protegido: o recetor ou a rede?
Solução
Evita sobrecarregar o buffer do recetor.
- Evitar a sobrecarga do buffer do recetor.. O controlo de fluxo gere o espaço no recetor através de rwnd.
- Evitar que as filas dos routers cresçam demasiado.. Proteger a rede é o papel do controlo de congestionamento.
- Garantir capacidade disponível em todo o percurso.. Nenhum mecanismo garante capacidade; o congestionamento adapta-se a ela.
Crescer em slow start
Em slow start, sem perdas e com dados sempre disponíveis, como cresce a janela de congestionamento?
Pista
Conta quantos ACKs chegam por janela enviada.
Solução
Exponencialmente, duplicando aproximadamente por RTT.
- Exponencial.. Cada ACK aumenta a janela; por RTT, aproximadamente duplica.
- Linear.. O crescimento linear é da fase de congestion avoidance.
- Logarítmico.. O crescimento é mais rápido do que logarítmico.
Contar bytes após SYN
Cliente envia SYN com sequência 500. A abertura termina; cliente envia 300 bytes contíguos. Qual ACK cumulativo do servidor após recebê-los?
Pista
SYN consome um número, por isso o primeiro byte vem a seguir.
Solução
ACK 801, próximo byte esperado. O ACK da abertura não consome outro número.
Erros frequentes
Responder 800 ou acrescentar um número por segmento.
Confirmar apesar de uma lacuna
O recetor esperava inicialmente o byte 1000. Recebeu 1000–1199 e 1400–1599, mas faltam 1200–1399. Qual ACK cumulativo?
Pista
O ACK não ultrapassa a primeira lacuna.
Solução
ACK 1200. SACK pode informar o bloco posterior se negociado, mas o ACK cumulativo continua 1200.
Converter janela em débito
Janela efetiva 100000 bytes, RTT 0,1 s, ligação 40 Mbit/s. Qual o menor limite ideal em Mbit/s?
Pista
A janela está em bytes.
Relacionar bytes em voo e segmentos
O recetor anuncia rwnd=10000 bytes, cwnd=40000 bytes e há 6000 bytes enviados ainda não confirmados. O MSS é 1000 bytes, mas os novos segmentos levarão apenas 500 bytes cada. Quantos bytes novos e quantos desses segmentos cabem? Se rwnd passar a 4000 sem chegarem ACKs novos, quantos bytes novos podem ser enviados no mesmo modelo?
Pista
Solução
O limite inicial é min(10000,40000)=10000 bytes. Restam 10000−6000=4000 bytes, ou oito segmentos de 500 bytes. MSS é o máximo, não o tamanho obrigatório de cada segmento.
Com rwnd=4000 e 6000 bytes em voo, o espaço calculado é max(0,4000−6000)=0. O emissor não envia dados novos nesse estado; os bytes já enviados não desaparecem por a janela ter diminuído.
Confere a tua resposta:
- Desconto os bytes pendentes da menor janela.
- Divido pelos 500 bytes reais, não pelo MSS.
- Limito a zero o espaço após diminuir rwnd.
Calcular duas respostas à perda em Reno
TCP Reno clássico tem 12 MSS em voo e cwnd=12 MSS. Compara dois cenários independentes: recebe três ACKs duplicados; expira o timeout sem essa informação. Indica ssthresh e cwnd imediatamente após cada evento, o valor de cwnd depois do ACK de recuperação no primeiro caso e a fase de crescimento seguinte. Usa janela de perda 1 MSS e ignora ACKs duplicados adicionais. A perda pode ser erro de canal.
Pista
Solução
Nos dois casos, ssthresh=max(12/2,2)=6 MSS. Com três ACKs duplicados, Reno inicia fast retransmit e fast recovery: retransmite o segmento em falta e cwnd passa temporariamente a 6+3=9 MSS. Quando chega o ACK que confirma a recuperação considerada, cwnd regressa a 6 MSS e segue congestion avoidance.
No timeout, retransmite e cwnd passa a 1 MSS, conservando ssthresh=6 MSS; recomeça slow start. O limiar e a janela são variáveis diferentes. A reação recupera uma falha de entrega, mas os eventos não provam por si só que a causa foi congestionamento.
Confere a tua resposta:
- Calculo ssthresh=6 MSS nos dois cenários.
- Distingo cwnd temporária de 9 MSS e retorno a 6 MSS.
- No timeout, reduzo cwnd a 1 MSS sem reduzir ssthresh a 1.
- Associo as fases ao evento correto.
