A camada de transporte: UDP e TCP

Uma aplicação envia dados por um socket, a interface entre seu processo e a camada de transporte. A camada de transporte faz com que processos em diferentes hospedeiros pareçam se comunicar diretamente. Isso é comunicação lógica: os dados ainda atravessam enlaces e roteadores, mas a aplicação trabalha por meio de seu socket local.

Acompanhe os dados pelas camadas

No remetente, o protocolo de transporte recebe dados da aplicação, divide-os em partes quando necessário e acrescenta um cabeçalho de transporte. O segmento resultante vai para o IP. O IP acrescenta seu próprio cabeçalho, produzindo um datagrama IP para ser transportado pela rede. No destino, o IP entrega o segmento ao protocolo de transporte, que interpreta o cabeçalho de transporte e entrega os dados a um socket.

A lógica do protocolo é executada nos hospedeiros das extremidades. Roteadores comuns encaminham datagramas IP; eles não realizam reconhecimento e retransmissão TCP em nome das aplicações. Pense em um endereço IP como o endereço de um prédio e no socket de recepção como o destinatário dentro dele. Levar uma carta ao prédio e entregá-la à pessoa correta são tarefas distintas.

O IP oferece entrega de melhor esforço entre hospedeiros. Datagramas podem ser perdidos, duplicados, reordenados ou corrompidos. A camada de transporte estende a entrega aos processos e pode acrescentar mecanismos que corrigem essas falhas.

Compare os serviços

O UDP, Protocolo de Datagramas do Usuário, acrescenta portas e uma verificação de erros à entrega do IP. Um segmento pode chegar sem qualquer troca prévia de estabelecimento de conexão. O UDP não recupera um segmento perdido nem retém um segmento posterior até que um anterior chegue.

O TCP, Protocolo de Controle de Transmissão, estabelece o estado da conexão antes da transferência normal de dados. Ele numera bytes, verifica erros, obtém reconhecimentos e retransmite dados ausentes. A aplicação receptora recebe um fluxo de bytes confiável e em ordem. O controle de fluxo protege seu buffer; o controle de congestionamento responde à carga da rede.

A confiabilidade não torna confiável a rede subjacente. Se um datagrama IP desaparece, o TCP envia outra cópia dos dados ausentes. Se bytes posteriores chegam primeiro, o receptor pode retê-los até que a lacuna seja preenchida. A aplicação recebe os dados após a correção da entrega, mas pode esperar mais. Nem o TCP nem o UDP pode prometer um prazo de entrega ou reservar capacidade de rede apenas por operar sobre o IP de melhor esforço.

Escolha o serviço no socket

Um socket de fluxo normalmente seleciona TCP; um socket de datagrama seleciona UDP. HTTP/1.1 e HTTP/2, transferência de correio eletrônico por SMTP e acesso remoto por SSH usam TCP. Consultas DNS comuns frequentemente usam UDP. O HTTP/3 usa QUIC sobre UDP: o QUIC fornece fluxos confiáveis e segurança acima do serviço mínimo do UDP.

Uma conexão TCP por si só não mantém uma senha em sigilo. O TLS acrescenta cifragem e autenticação acima do TCP; o QUIC integra o TLS ao seu projeto. A confiabilidade responde se os bytes chegam à aplicação corretamente e em ordem. A confidencialidade responde se um observador pode lê-los.

Um hospedeiro frequentemente tem muitos sockets abertos. A multiplexação reúne dados de saída desses sockets e acrescenta cabeçalhos de transporte. A demultiplexação seleciona o socket de recepção para cada segmento que chega.

Leia as informações de endereçamento

Tanto o TCP quanto o UDP contêm uma porta de origem de 16 bits e uma porta de destino de 16 bits. Os valores vão de 0 a 65.535. A porta de destino identifica o serviço receptor; a porta de origem ajuda a outra extremidade a endereçar sua resposta. A IANA agrupa as portas em portas de sistema de 0 a 1023, portas de usuário de 1024 a 49151 e portas dinâmicas de 49152 a 65535.

Os servidores escutam em portas convencionadas: SSH usa 22, SMTP 25, DNS 53, HTTP 80 e HTTPS geralmente 443. Os clientes costumam receber uma porta efêmera temporária do sistema operacional. Sua faixa configurada não precisa ser igual à faixa dinâmica da IANA: um padrão comum do Linux é de 32768 a 60999, enquanto o Windows geralmente usa de 49152 a 65535.

Ao receber um datagrama IP, o hospedeiro primeiro identifica o protocolo de transporte. O valor 6 no campo de protocolo IPv4 significa TCP e 17 significa UDP; o IPv6 identifica o protocolo da camada superior por meio de sua cadeia de campos de próximo cabeçalho. A porta TCP 53 e a porta UDP 53 pertencem a espaços de nomes de transporte diferentes. O receptor então usa endereços e portas para selecionar um socket e coloca os dados em fila para a aplicação.

UDP: muitos clientes, um socket de recepção

No modelo básico de servidor UDP não conectado, o socket de recepção é selecionado pelo endereço IP de destino e pela porta de destino. Diferentes clientes podem enviar dados para esse mesmo socket.

Um servidor em 203.0.113.53 escuta na porta UDP 53. Requisições de 198.51.100.7:51000 e 192.0.2.44:62011 chegam a esse único socket do servidor. A primeira resposta vai de 203.0.113.53:53 para 198.51.100.7:51000. A aplicação obtém o endereço e a porta de origem de cada requisição para poder responder ao cliente correto. Um socket UDP conectado também pode restringir a extremidade da qual recebe dados; nenhuma negociação UDP é acrescentada.

TCP: distinga conexões por quatro valores

Um servidor TCP tem um socket de escuta e sockets de conexão separados. Uma conexão é identificada pela quádrupla de IP de origem, porta de origem, IP de destino e porta de destino.

Para um servidor em 203.0.113.10:80, estas são conexões diferentes:

• 198.51.100.7:50312 → 203.0.113.10:80
• 198.51.100.7:50313 → 203.0.113.10:80
• 192.0.2.44:50312 → 203.0.113.10:80

As duas primeiras diferem na porta de origem. A primeira e a terceira compartilham uma porta de origem, mas diferem no endereço de origem. As três usam a porta 80 do servidor. Uma porta de servidor separada para cada cliente é desnecessária porque a quádrupla completa distingue seus sockets de conexão. Um processo pode atender muitos desses sockets.

Quando nenhum socket corresponde

Um SYN enviado a uma porta TCP fechada normalmente recebe uma reinicialização, com o indicador RST ativado. Um segmento UDP enviado a uma porta sem receptor normalmente provoca uma mensagem ICMP de “porta inalcançável”. Firewalls, filtragem e limites de resposta podem afetar o que retorna. Em uma sondagem de porta, SYN-ACK é evidência de um serviço TCP em escuta; RST indica recusa. O silêncio, por si só, não permite distinguir filtragem de perda ou de um hospedeiro indisponível.

O UDP envia cada mensagem independentemente, sem negociação nem estado compartilhado de sequência da conexão. Seu cabeçalho fixo de 8 bytes contém quatro campos, cada um com 16 bits: porta de origem, porta de destino, comprimento e soma de verificação.

Conte os bytes corretos

O comprimento abrange o cabeçalho UDP e seus dados. Ele é de pelo menos 8 bytes. Uma mensagem com 40 bytes de dados tem comprimento UDP 48. Com um cabeçalho IPv4 de 20 bytes e sem opções IP, o datagrama IP completo tem 68 bytes. O cabeçalho IP está fora do comprimento UDP.

A soma de verificação detecta alguns erros de bits no cabeçalho UDP e nos dados. Ela também abrange um pseudocabeçalho construído com informações de endereçamento IP, o número do protocolo e o comprimento UDP. Esses valores ajudam a detectar um segmento entregue com informações de endereçamento incorretas. O pseudocabeçalho é uma entrada do cálculo; ele não é uma parte adicional transmitida do cabeçalho UDP.

Some com transporte circular de vai um

Trate os dados de entrada do cálculo como palavras de 16 bits. Defina o campo da soma de verificação como zero durante o cálculo. Some as palavras, trazendo qualquer vai um além do 16º bit de volta à extremidade menos significativa. Essa é a soma em complemento de um. Por fim, inverta todos os 16 bits da soma após o transporte circular para obter a soma de verificação. Se a contagem de bytes for ímpar, acrescente um byte zero apenas para o cálculo.

Para três palavras ilustrativas, use hexadecimal para tornar o vai um visível:

1. Some A35C e 69C3 para obter 10D1F. O 1 inicial é um vai um além dos 16 bits.
2. Traga-o de volta: 0D1F + 1 = 0D20.
3. Some 1234: 0D20 + 1234 = 1F54.
4. Complemente cada bit: FFFF − 1F54 = E0AB.

A soma de verificação é E0AB. Simplesmente descartar o vai um inicial produziria a soma errada. Em binário, a soma final é 0001 1111 0101 0100 e seu complemento é 1110 0000 1010 1011.

Confira no receptor

O receptor repete a soma com transporte circular sobre o pseudocabeçalho e o segmento recebido, agora incluindo o campo da soma de verificação. Um segmento inalterado produz apenas uns, FFFF. Aqui, 1F54 + E0AB = FFFF. Um resultado que contém um bit zero indica um erro. O UDP descarta silenciosamente um segmento cuja soma de verificação fornecida e diferente de zero falha; ele não envia uma substituição nem corrige os dados.

Um resultado composto apenas de uns significa que a verificação passou, não que todos os erros possíveis foram excluídos. Alterações compensatórias em palavras diferentes podem deixar a soma inalterada. A soma de verificação detecta erros; ela não localiza os bits incorretos nem os corrige.

Por que os hospedeiros das extremidades verificam novamente

Uma verificação de enlace protege um enlace específico. Alguns enlaces podem não ter essa verificação, e também pode ocorrer corrupção dentro dos equipamentos entre enlaces. Uma verificação fim a fim testa o que chegou ao hospedeiro de destino. Isso ilustra o princípio fim a fim: uma propriedade necessária em todo o caminho deve ser verificada nas extremidades.

Sobre IPv4, um campo de soma de verificação UDP igual a zero indica que o remetente omitiu a soma de verificação. Uma soma calculada igual a zero é transmitida com todos os bits iguais a um para preservar essa distinção. O IPv6 normalmente exige uma soma de verificação UDP, com exceções para túneis especificadas de forma restrita. O TCP também usa uma soma de verificação da internet com pseudocabeçalho e exige sua soma de verificação.

O serviço simples do UDP dá à aplicação controle sobre suas mensagens. Não há negociação de transporte antes da primeira mensagem, nem fila de retransmissão UDP ou mecanismo UDP que retenha dados posteriores por causa de uma mensagem anterior ausente. A aplicação decide o que enviar e quais perdas importam.

Ajuste a recuperação ao tempo útil de chegada

Considere áudio de voz enviado em partes de 20 ms: 50 mensagens por segundo. Uma parte ausente deve ser reproduzida em 60 ms, mas detectar a perda e obter outra cópia leva cerca de 150 ms. Essa parte recuperada chegaria tarde demais. Uma aplicação de voz pode reproduzir as partes posteriores no momento certo e ocultar o som ausente, por exemplo, suavizando a lacuna.

A quantidade decisiva é o tempo restante antes da reprodução, não a duração de 20 ms de uma parte. Se a recuperação puder terminar antes do prazo, a retransmissão pode ajudar. O TCP deve entregar bytes em ordem, portanto um byte anterior ausente também pode atrasar a entrega de bytes posteriores já recebidos. Essa espera costuma ser chamada de bloqueio de início de fila dentro do fluxo.

Uma transferência de arquivo tem outra prioridade: cada byte deve chegar corretamente, e esperar pela recuperação é aceitável. O TCP já fornece esse serviço. Usar UDP transferiria o trabalho de detectar perdas, solicitar dados de substituição e restaurar a ordem para a aplicação ou outro protocolo.

O que o cabeçalho pequeno oferece

O cabeçalho do UDP tem 8 bytes; o do TCP tem pelo menos 20. Um servidor UDP pode receber mensagens de muitos clientes sem estabelecer conexões de transporte individuais. Ainda existem buffers de socket e recursos de aplicação, portanto “não orientado a conexão” não significa que o hospedeiro não armazene nada.

Usos comuns do UDP incluem consultas DNS comuns na porta 53, sincronização de tempo NTP na 123, gerenciamento SNMP na 161 e atribuição de endereços DHCP nas 67 e 68. Chamadas e jogos frequentemente escolhem UDP para que as mensagens cheguem no momento adequado. O vídeo sob demanda geralmente usa HTTP sobre TCP ou QUIC, portanto “vídeo usa UDP” é uma regra ampla demais.

O QUIC mostra quanto um protocolo pode acrescentar acima do UDP: fluxos confiáveis, controle de congestionamento e segurança TLS 1.3. Ele foi padronizado em 2021 e geralmente usa a porta UDP 443; o HTTP/3 é executado sobre QUIC. O próprio UDP não adquiriu esses serviços.

Mantenha as mensagens pequenas o suficiente

O UDP preserva os limites das mensagens. Uma operação de recebimento lê uma mensagem, não um fluxo de bytes montado a partir de vários envios. A aplicação deve fornecer um buffer de leitura grande o suficiente; um buffer menor pode truncar a mensagem.

Para IPv4 com um cabeçalho IP de 20 bytes, a carga útil máxima teórica é 65.535 − 20 − 8 = 65.507 bytes. Enviar perto desse limite pode exigir fragmentação IP. Em um caminho que suporta datagramas IPv4 de 1.500 bytes, cabem 1.500 − 20 − 8 = 1.472 bytes de dados sem fragmentação quando não há opções IP. Outros caminhos e cabeçalhos podem reduzir esse valor.

Considere os controles ausentes

O UDP não tem controle de fluxo integrado para proteger um receptor lento. Se seu buffer de socket ficar cheio, as mensagens recebidas poderão ser descartadas. Ele também não tem controle de congestionamento integrado. Aplicações UDP responsáveis fornecem controle de taxa adequado para não sobrecarregar um caminho compartilhado. Algumas redes filtram UDP, portanto as aplicações podem precisar de uma alternativa.

Omitir o estabelecimento de conexão e a recuperação pode reduzir o atraso, mas o UDP não aumenta a capacidade de um enlace nem evita perdas no IP. Avalie o protocolo completo da aplicação: o trabalho que ele acrescenta acima do UDP pode importar mais que o tamanho do cabeçalho.

Um protocolo de transferência confiável de dados fornece à aplicação receptora dados corretos, em ordem e sem duplicatas, mesmo quando o canal subjacente danifica pacotes. Construa o projeto perguntando o que pode dar errado em cada etapa. Nesses protocolos, os dados da aplicação trafegam em uma direção e as respostas de controle retornam na direção oposta.

Descreva o comportamento com estados

Uma máquina de estados finitos (FSM) registra o estado atual do remetente ou do receptor. Cada transição tem um evento que a dispara e as ações a executar. Um estado como “esperando por ACK 0” registra qual evidência o remetente precisa antes de prosseguir. Na notação de FSM, Λ indica ausência de evento ou de ação; uma seta tracejada de entrada marca o estado inicial.

Com um canal perfeitamente confiável, a versão 1.0 precisa apenas de envio e entrega. O remetente empacota os dados, o receptor os extrai e nenhum dos dois precisa de resposta. A inclusão de erros de bits muda o projeto.

Detecte um erro e solicite outra cópia

A versão 2.0 usa três mecanismos:

• Uma soma de verificação permite que o receptor verifique se um pacote foi corrompido.
• Um ACK informa o recebimento correto; um NAK informa que os dados foram danificados.
• A retransmissão envia outra cópia quando necessário.

Juntos, eles formam a solicitação automática de retransmissão (ARQ). O remetente envia um pacote e espera uma resposta antes de enviar o próximo: pare e espere. Ele mantém uma cópia do pacote atual porque pode precisar reenviá-lo.

Mas os pacotes de resposta atravessam o mesmo canal não confiável. Um ACK danificado deixa o remetente em dúvida: o receptor aceitou os dados ou é necessária outra cópia? Reenviar só é seguro se o receptor puder distinguir uma cópia de substituição de novos dados da aplicação. Uma soma de verificação sozinha não identifica duplicatas; duas cópias válidas têm o mesmo conteúdo válido.

Dê uma identidade a cada pacote pendente

A versão 2.1 acrescenta um número de sequência. Com apenas um pacote pendente, um número de um bit alternando 0, 1, 0, 1 é suficiente nesse modelo de canal com pare e espere. O receptor lembra qual número espera. Ele entrega uma vez um pacote válido com esse número e depois muda o número esperado. Um pacote com o número anterior é uma duplicata: reconheça-o novamente, mas não entregue seus dados outra vez.

O remetente mantém o número atual durante a retransmissão. Ele só passa ao outro número após receber o ACK correspondente e legível. Nesse projeto que trata apenas erros, uma resposta corrompida ou um NAK causa uma retransmissão.

Substitua NAKs por ACKs repetidos

A versão 2.2 elimina os NAKs. O receptor responde a um pacote danificado ou duplicado com um ACK para o último pacote que aceitou. Portanto, o ACK precisa de um número.

Suponha que o pacote 0 contenha “A” e chegue corretamente. O receptor entrega “A” e envia ACK 0. O pacote 1, contendo “B”, é corrompido, então o receptor repete ACK 0. O remetente está esperando por ACK 1; esse ACK duplicado sinaliza que ele deve reenviar o pacote 1. A cópia de substituição válida é entregue como “B” e reconhecida com ACK 1.

Descartar dados duplicados e reconhecer novamente o pacote duplicado são ações diferentes. Se o receptor ignorasse silenciosamente uma cópia de substituição cujo ACK anterior ficou ilegível, o remetente nunca saberia que a entrega foi bem-sucedida. O TCP também evita NAKs, embora sua numeração de bytes e suas regras de retransmissão rápida sejam diferentes das desse protocolo simples.

Uma resposta não ajuda se nunca chegar. Quando o canal pode perder um pacote de dados ou um ACK, o remetente precisa de uma forma de prosseguir sem receber uma mensagem. A versão 3.0 acrescenta um temporizador de contagem regressiva ao protocolo do bit alternante.

Lide com o silêncio sem entregar duas vezes

O remetente inicia o temporizador sempre que envia o pacote atual, inclusive uma cópia de substituição. Um ACK correspondente e intacto para o temporizador e permite o envio do próximo pacote. Um ACK corrompido ou com número errado é ignorado. Se o tempo do temporizador expirar primeiro, o remetente reenvia o mesmo pacote e reinicia o temporizador.

Quando um pacote de dados é perdido, o receptor não tem nada a reconhecer; a expiração do tempo limite provoca o envio da cópia de substituição. Quando um ACK é perdido, o receptor já entregou os dados. Quando a cópia de substituição chega, o número de sequência identifica uma duplicata. O receptor descarta seus dados e envia o ACK novamente.

Uma expiração prematura do tempo limite ocorre quando o pacote original ou o ACK apenas demorou. A cópia de substituição desperdiça esforço de transmissão, mas a detecção de duplicatas preserva a entrega correta. Um tempo limite útil deve comportar o tempo de ida e volta esperado e o processamento do receptor. Curto demais, produz retransmissões desnecessárias; longo demais, atrasa a recuperação de uma perda real.

Separe o tempo de transmissão do tempo de espera

Considere o comprimento do pacote como $L$ bits e a taxa do enlace como $R$ bit/s. O remetente precisa de $L\mathrm{/}R$ segundos para colocar um pacote no enlace. Ignorando o tempo de transmissão e processamento do ACK, um ciclo de pare e espere leva $RTT+L\mathrm{/}R$. A fração do tempo dedicada ao envio é

Para pacotes de 1.500 bytes em um enlace de 1 Gbit/s, primeiro converta bytes em bits:

Então $L\mathrm{/}R=12\mu \text{s}=\mathrm{0,012}\text{ ms}$. Com um RTT de 40 ms,

O remetente fica ativo cerca de 0,03% do tempo. A vazão é de cerca de 12.000 bits a cada 0,040012 s, ou 300 kbit/s. Mesmo um enlace muito rápido transporta pouco tráfego útil porque o remetente passa quase todo o ciclo esperando.

Transmita os pacotes em pipeline

A transmissão em pipeline permite que vários pacotes não reconhecidos estejam em trânsito. Se até $N$ pacotes couberem na janela de envio, a utilização ideal passa a ser

No mesmo enlace, 1.000 pacotes resultam em uma utilização de cerca de 0,30. Para mantê-lo totalmente ocupado, são necessários pelo menos $\mathrm{40,012}\mathrm{/}\mathrm{0,012}\approx \mathrm{3.334,33}$ tempos de transmissão de pacote, portanto arredonde para cima para 3.335 pacotes. Arredondar para baixo deixa um pequeno intervalo ocioso antes do primeiro ACK.

Um pipeline maior precisa de números de sequência suficientes para distinguir seus pacotes e de espaço em buffer suficiente para reter dados não reconhecidos. O receptor também pode precisar de armazenamento em buffer, dependendo do protocolo. Go-back-N e repetição seletiva resolvem essas escolhas de projeto de maneiras diferentes.

Aumentar apenas a taxa do enlace reduz o já breve tempo de transmissão. Para um tamanho de pacote e RTT fixos, isso reduz a utilização do pare e espere. Mais dados em trânsito permitem que o remetente use a capacidade disponível.

O Go-back-N (GBN) permite até $N$ pacotes enviados, mas não reconhecidos. A janela deslizante do remetente avança quando os reconhecimentos confirmam a entrega. O receptor permanece simples: ele aceita apenas o próximo pacote em ordem.

Mantenha separadas as faixas do remetente

A variável base identifica o pacote não reconhecido mais antigo. nextseqnum identifica o próximo pacote novo a enviar. Antes do retorno cíclico dos números de sequência, as faixas são:

• Abaixo de base: já reconhecidos.
• De base até nextseqnum − 1: enviados, aguardando reconhecimento.
• De nextseqnum até base + N − 1: disponíveis para novos dados.
• Em base + N ou acima: bloqueados até a janela avançar.

Para base = 10, nextseqnum = 13 e $N=5$, os pacotes de 10 a 12 estão pendentes. Os pacotes 13 e 14 podem ser enviados. O pacote 15 não pode. Uma janela limita os dados pendentes, não o número total de pacotes de uma transferência.

Reconhecimentos cumulativos avançam a base

No GBN, ACK $n$ confirma todos os pacotes até $n$, inclusive. Ele move base para $n+1$. Portanto, um ACK cumulativo posterior pode cobrir ACKs anteriores que foram perdidos. Essa convenção de numeração identifica o último pacote aceito; a convenção de ACK do TCP identifica o próximo byte esperado.

O GBN mantém um temporizador para o pacote pendente mais antigo. O envio do primeiro pacote pendente o inicia. Um ACK que avança a base o reinicia se ainda houver dados pendentes; o reconhecimento de todos os dados o para. Quando o tempo do temporizador expira, o remetente retransmite todos os pacotes enviados que continuam não reconhecidos. Essa quantidade pode ser menor que a janela máxima $N$.

Acompanhe um pacote ausente

Use uma janela de quatro e envie os pacotes 0, 1, 2 e 3. O pacote 2 é perdido. O receptor entrega 0 e 1 e envia ACK 0 e ACK 1. O pacote 3 chega após a lacuna: o receptor o descarta e repete ACK 1.

Os dois primeiros ACKs abrem espaço para os pacotes 4 e 5. Eles também chegam após o pacote 2 ausente, portanto ambos são descartados e recebem ACK 1 como resposta. A base do remetente permanece em 2. Quando o tempo limite expira, ele retransmite 2, 3, 4 e 5. Agora eles chegam em ordem e todos podem ser entregues.

As cópias de 3, 4 e 5 estavam intactas na primeira vez. O GBN as reenvia porque seu receptor optou por não armazenar pacotes fora de ordem em buffer. Isso economiza estado no receptor ao custo de tráfego extra após uma perda.

Deixe um número de sequência fora da janela

Um campo de $k$ bits fornece $2^k$ números de pacote, reutilizados ciclicamente. O GBN exige

Com três bits, os números vão de 0 a 7 e a maior janela do remetente é sete. Se todos os oito fossem permitidos, o receptor poderia aceitar de 0 a 7 e voltar a esperar 0. Se todos os ACKs fossem perdidos, um 0 antigo retransmitido pareceria novo. Com apenas os pacotes de 0 a 6 enviados, o receptor espera 7 e pode reconhecer o 0 retransmitido como antigo. A aritmética da janela perto do retorno cíclico segue a ordem cíclica, não o valor numérico comum.

A repetição seletiva (SR) guarda pacotes recebidos corretamente mesmo quando pacotes anteriores estão ausentes. Cada pacote válido recebe seu próprio ACK. O remetente pode então substituir apenas um pacote cujo tempo do temporizador expire.

Acompanhe cada pacote separadamente

A janela do remetente começa em send_base, o pacote não reconhecido mais antigo, e contém $N$ números de sequência permitidos. Cada pacote pendente tem um temporizador lógico. Um ACK marca esse pacote específico como recebido. Um ACK posterior à base não desloca a janela por si só: a base permanece na primeira lacuna. Quando essa lacuna é reconhecida, a base salta sobre quaisquer pacotes seguintes já reconhecidos.

A janela do receptor começa em rcv_base, o próximo pacote necessário para a entrega. Um pacote válido dentro da janela é reconhecido. Dados fora de ordem são armazenados em buffer. Quando o pacote da base chega, o receptor o entrega e também todos os pacotes consecutivos armazenados após ele, parando na próxima lacuna.

Um pacote na janela imediatamente anterior é uma duplicata antiga. O receptor o reconhece novamente sem entregá-lo. Essa regra é essencial quando o ACK original foi perdido: o remetente ainda pode estar esperando, mesmo que o receptor já tenha avançado.

Recupere uma perda

Use $N=4$ e suponha que o pacote 2 seja perdido depois que o remetente envia os pacotes de 0 a 3. O receptor entrega e reconhece 0 e 1, depois armazena 3 em buffer e o reconhece. Os dois primeiros ACKs permitem que o remetente transmita 4 e 5. Ambos são armazenados em buffer e reconhecidos individualmente, mas send_base permanece em 2.

Quando o tempo do temporizador do pacote 2 expira, apenas o 2 é reenviado. Sua chegada permite que o receptor entregue 2, 3, 4 e 5 juntos e mova rcv_base para 6. Quando ACK 2 chega ao remetente, sua base também avança para 6, passando pelos pacotes de 3 a 5, cujos ACKs ele já possui.

Por que a janela ocupa no máximo metade do espaço de números

O receptor pode estar à frente do remetente porque os ACKs são atrasados ou perdidos. Os novos números aceitáveis não devem se sobrepor a números que ainda possam ser retransmitidos como pacotes antigos.

Com números de dois bits de 0 a 3 e uma janela de três, suponha que o receptor aceite 0, 1 e 2. Sua nova janela é {3, 0, 1}. Se todos os ACKs desaparecerem, um 0 antigo retransmitido caberá nessa janela e parecerá novo. O receptor não consegue distingui-lo de um 0 realmente novo enviado após a perda de um 3.

Para janelas de remetente e receptor de mesmo tamanho, o limite seguro é

Portanto, uma numeração de três bits permite janelas SR de até quatro, enquanto o GBN permite sete.

Distinga uma cópia antiga após o retorno cíclico

Os limites de janela tratam das janelas atuais, mas uma rede real também pode manter uma cópia antiga em trânsito até que os números sejam reutilizados. Um tempo máximo de vida do pacote limita por quanto tempo essas cópias podem sobreviver. O TCP chama isso de tempo máximo de vida de um segmento (MSL). Em taxas altas, o TCP pode reutilizar rapidamente seu espaço de sequência de 32 bits, portanto a proteção contra a reutilização de números de sequência (PAWS) baseada em marcas de tempo ajuda a rejeitar dados antigos.

Uma conexão TCP é um estado mantido em dois hospedeiros das extremidades: buffers, contadores de bytes e outras variáveis criadas durante o estabelecimento. Ela é ponto a ponto, entre duas extremidades, e full-duplex, permitindo que ambas enviem dados ao mesmo tempo. Roteadores comuns encaminham seus datagramas IP sem manter o estado TCP das extremidades.

Bytes não têm limites de mensagem

O TCP preserva a ordem dos bytes, mas não os limites das escritas da aplicação. Três escritas de 100 bytes podem chegar à aplicação em uma única leitura de 300 bytes ou em leituras de 50 e 250 bytes. Uma aplicação que troca mensagens deve fornecer sua delimitação, por exemplo, com um campo de comprimento ou um delimitador. Uma leitura curta não estabelece que uma mensagem completa chegou.

As escritas da aplicação entram em um buffer de envio. O TCP escolhe partes para transmitir, retendo dados não reconhecidos para uma possível retransmissão. Os dados recebidos entram em um buffer de recepção até que a aplicação receptora os leia.

Dimensione os dados separadamente dos cabeçalhos

O tamanho máximo de segmento (MSS) limita os dados de aplicação em um segmento. Ele exclui os cabeçalhos TCP e IP. Para um caminho que suporta datagramas IP de 1.500 bytes com cabeçalhos IPv4 de 20 bytes e TCP de 20 bytes,

As opções ocupam mais espaço, portanto o remetente deve considerar os comprimentos reais dos cabeçalhos. Cada extremidade anuncia o MSS que pode receber durante a negociação; limites do caminho podem restringir ainda mais o que pode ser enviado. Sem uma opção MSS, os valores padrão presumidos são 536 bytes de dados para IPv4 e 1.220 para IPv6.

Leia os campos do cabeçalho

O cabeçalho mínimo tem cinco palavras de 32 bits, ou 20 bytes. Um deslocamento dos dados de 8 significa 32 bytes, incluindo 12 bytes além do cabeçalho fixo. O deslocamento máximo é 15: 60 bytes no total, permitindo até 40 bytes de opções.

Interprete indicadores e opções

SYN sincroniza números de sequência durante a abertura. FIN fecha uma direção de envio. RST aborta ou recusa uma conexão. ACK torna válido o campo de reconhecimento. PSH solicita a entrega imediata à aplicação; ele não cria um limite de mensagem. URG torna o ponteiro de dados urgentes válido, embora se recomende que novas aplicações evitem esse mecanismo. ECE e CWR transportam sinais de notificação explícita de congestionamento.

Opções comuns incluem MSS, fator de escala da janela, marcas de tempo e reconhecimento seletivo (SACK). O fator de escala amplia a faixa da janela de recepção. As marcas de tempo ajudam a medir o RTT e a rejeitar segmentos antigos. O SACK descreve blocos recebidos após uma lacuna.

Sem opções, TCP mais IPv4 acrescentam 40 bytes. Um segmento completo com 1.460 bytes de dados ocupa um datagrama IP de 1.500 bytes, com cerca de 97,3% de dados de aplicação. Um ACK puro não tem dados, mas ainda ocupa esses 40 bytes de cabeçalho.

Os números de sequência TCP contam bytes, não segmentos. O número de sequência de um segmento indica seu primeiro byte de dados. Seu número de reconhecimento descreve a direção oposta: o próximo byte que esse remetente espera receber.

Divida um fluxo em segmentos

Um número de sequência inicial (ISN) de 3.000 é usado pelo SYN. Portanto, o primeiro byte de dados é 3.001. Um arquivo de 10.000 bytes com MSS de 1.460 precisa de seis segmentos completos de dados e um segmento menor:

Cada próximo número de sequência soma o comprimento dos dados do segmento anterior. O byte final é 13.000, portanto o recebimento bem-sucedido de todo o arquivo produz o ACK cumulativo 13.001.

Reconheça um prefixo contínuo

ACK $n$ confirma todos os bytes até $n-1$, inclusive. Ele não confirma o byte $n$. Se o receptor possui os bytes até 4.460, ele espera 4.461. Um segmento que começa em 5.921 deixa uma lacuna. Um receptor que armazena esse segmento em buffer ainda envia ACK 4.461 porque seu prefixo contínuo não aumentou.

É por isso que o reconhecimento não pode ser simplesmente o maior número de sequência observado. Bytes posteriores mostram que algo chegou após a lacuna; eles não a preenchem. Quando a faixa ausente chega, um ACK cumulativo pode saltar sobre dados já armazenados em buffer.

Acompanhe as duas direções independentemente

Suponha que o próximo byte de um cliente seja 1.000 e o próximo byte de um servidor seja 5.000. O cliente envia 200 bytes de dados com sequência 1.000 e reconhecimento 5.000. A resposta do servidor contém 1.200 bytes com sequência 5.000 e reconhecimento 1.200. O próximo ACK puro do cliente tem sequência 1.200 e reconhecimento 6.200.

O servidor não derivou seu próprio número de sequência do comprimento da requisição. Cada direção tem sua própria numeração. Transportar um ACK com dados de saída é o reconhecimento incorporado aos dados. Um ACK puro não consome espaço de sequência; SYN e FIN consomem um número cada, mesmo sem dados.

Gerencie valores iniciais e retorno cíclico

As extremidades escolhem um ISN ao abrir uma conexão. Um relógio e uma função pseudoaleatória com chave dos endereços e das portas da conexão ajudam a separar uma nova conexão de segmentos antigos atrasados e dificultam que alguém de fora adivinhe números válidos. Começar toda conexão em zero enfraqueceria ambas as proteções.

Os campos têm 32 bits, portanto a numeração retorna ciclicamente módulo $2^{32}$, cerca de 4,3 bilhões de bytes. A 1 Gbit/s, percorrer esse espaço leva cerca de 34 s; a 10 Gbit/s, cerca de 3,4 s. O PAWS baseado em marcas de tempo fornece uma verificação adicional de segmentos antigos em caminhos rápidos.

Para aritmética comum longe do retorno cíclico, o próximo byte após um segmento de dados é seu número de sequência mais o comprimento dos dados. Quando SYN ou FIN está presente, inclua o número adicional que esse indicador de controle consome. Aplique o cálculo separadamente a cada direção.

O estabelecimento TCP permite que ambas as extremidades anunciem um número de sequência inicial e saibam que a outra extremidade o recebeu. O fechamento posterior libera cada direção separadamente. Essas trocas de controle usam o mesmo espaço de sequência dos dados.

Acompanhe o estabelecimento de conexão em três etapas

1. O cliente cria o estado da conexão, envia SYN com ISN 7.000 e entra em SYN_SENT.
2. O servidor responde com SYN-ACK, sequência 21.000 e reconhecimento 7.001. Ele fica em SYN_RCVD enquanto espera a confirmação.
3. O cliente registra o número do servidor e envia ACK com sequência 7.001 e reconhecimento 21.001. O cliente entra em ESTABLISHED; o servidor faz o mesmo quando esse ACK chega.

Cada SYN consome um número. O terceiro segmento já pode transportar dados de aplicação. A negociação comum custa uma ida e volta antes que o cliente possa enviar esses primeiros dados. Uma troca de duas mensagens não informaria ao servidor que o cliente recebeu seu ISN e poderia levá-lo a aceitar um SYN antigo atrasado como uma nova requisição.

Na interface de sockets, connect inicia uma abertura ativa. Um servidor escuta requisições, e accept retorna um novo socket de conexão após o estabelecimento. O socket de escuta permanece disponível para outros clientes.

Feche cada direção

Uma extremidade envia FIN quando não tem mais bytes a enviar. A outra extremidade reconhece esse FIN avançando seu ACK para uma unidade além dele. Ela ainda pode enviar seus próprios bytes restantes: isso é um fechamento parcial. Seu FIN posterior fecha a outra direção e também precisa de um ACK. O fechamento geralmente usa quatro segmentos, embora um FIN e um ACK possam ser combinados.

Para um cliente que fecha primeiro, a sequência usual de estados é ESTABLISHED → FIN_WAIT_1 após enviar FIN → FIN_WAIT_2 quando esse FIN é reconhecido → TIME_WAIT após receber e reconhecer o FIN da outra extremidade → CLOSED. A outra extremidade passa por CLOSE_WAIT enquanto sua aplicação termina, depois por LAST_ACK após enviar seu próprio FIN e, por fim, por CLOSED ao receber o ACK.

Permita a recuperação do último ACK

No percurso usual de fechamento ativo, TIME_WAIT dura o dobro do tempo máximo de vida de um segmento. Se o ACK final desaparecer, a outra extremidade poderá reenviar seu FIN e receber outro ACK. A espera também dá tempo para que segmentos antigos expirem antes da reutilização da quádrupla da conexão. O valor de MSL de dois minutos do padrão resulta em quatro minutos; as implementações podem usar durações diferentes, sendo 60 segundos um valor conhecido no Linux.

Um RST é diferente de FIN: ele aborta a conexão ou recusa uma requisição. Um SYN para uma porta fechada normalmente recebe RST. SYN-ACK indica que há um serviço em escuta; o silêncio pode resultar de filtragem, perda ou destino indisponível.

Proteja negociações incompletas

Uma inundação de SYN envia muitas requisições de abertura sem concluí-las. Um servidor que reserva recursos para cada conexão semiaberta pode esgotar seu estado disponível. Cookies SYN adiam a alocação desse estado por conexão. O servidor codifica informações verificáveis da conexão no ISN escolhido usando um segredo e uma entrada dependente do tempo. Um ACK final válido retorna o cookie em seu número de reconhecimento, permitindo que o servidor o verifique e crie o estado. O servidor ainda tem um socket de escuta e recursos compartilhados; ele evita armazenar uma conexão incompleta individual para cada SYN.

O TCP precisa de um tempo limite de retransmissão longo o suficiente para permitir tempos normais de ida e volta, mas curto o suficiente para recuperar-se prontamente de perdas. O RTT varia conforme as filas e os caminhos mudam, portanto o tempo limite acompanha tanto uma estimativa suavizada quanto o tamanho dos desvios recentes.

Obtenha uma amostra sem ambiguidade

O SampleRTT mede o intervalo entre o envio de dados e o recebimento de um ACK que os abrange. Em uma implementação básica, o TCP temporiza um segmento elegível por vez. O algoritmo de Karn exclui dados retransmitidos da amostragem comum de RTT: um ACK pode se referir à cópia original ou à substituta. Marcas de tempo negociadas podem eliminar essa ambiguidade.

A primeira amostra válida $R$ inicializa EstimatedRTT com $R$ e DevRTT com $R\mathrm{/}2$. Antes de existir uma amostra, o tempo limite inicial recomendado é 1 s.

Atualize a variação antes da média

Para uma nova amostra, use o EstimatedRTT anterior para medir o desvio:

Depois atualize a média móvel exponencialmente ponderada:

Os pesos recomendados são $\beta =1\mathrm{/}4$ e $\alpha =1\mathrm{/}8$. Amostras mais antigas mantêm menos influência após cada atualização. Atualizar a média primeiro mudaria o desvio usado na primeira equação.

Acompanhe uma atualização

Comece com EstimatedRTT = 100 ms e DevRTT = 10 ms; obtenha uma amostra de 120 ms.

1. Desvio absoluto: $\mathrm{\mid }120-100\mathrm{\mid }=20\text{ ms}$.
2. Novo DevRTT: $\mathrm{0,75}(10)+\mathrm{0,25}(20)=\mathrm{12,5}\text{ ms}$.
3. Novo EstimatedRTT: $\mathrm{0,875}(100)+\mathrm{0,125}(120)=\mathrm{102,5}\text{ ms}$.
4. Tempo limite básico: $\mathrm{102,5}+4(\mathrm{12,5})=\mathrm{152,5}\text{ ms}$.

A regra básica é

O padrão completo usa EstimatedRTT + max(G, 4 DevRTT), em que $G$ é a granularidade do relógio. Quando a margem de quatro desvios excede o intervalo do relógio, a regra básica fornece o mesmo resultado.

O padrão recomenda elevar um valor calculado abaixo de 1 s para 1 s. Implementações reais podem usar um mínimo menor; um mínimo comum no Linux é 200 ms. Os 152,5 ms calculados são, portanto, uma estimativa bruta, não necessariamente o tempo definido no temporizador do hospedeiro. Um limite superior opcional deve ser de pelo menos 60 s.

Aumente o intervalo após a expiração do tempo limite

Quando o tempo do temporizador expira, o TCP reenvia os dados não reconhecidos mais antigos e duplica o tempo limite. Um valor atual de 0,75 s passa a 1,5 s, depois a 3 s após outra expiração. Tentativas imediatas repetidas acrescentariam tráfego a um caminho que já está falhando em entregar respostas.

Um ACK recém-chegado não necessariamente reduz esse tempo limite aumentado. O TCP precisa de uma nova medição válida de RTT para recalcular a estimativa. Sem marcas de tempo, a ambiguidade da retransmissão impede que um ACK dos dados reenviados seja usado como essa nova amostra. Quando novos dados elegíveis forem enviados e reconhecidos, uma nova amostra poderá reduzir o tempo limite calculado.

O TCP combina soma de verificação, números de sequência de bytes, ACKs cumulativos e retransmissão para entregar um fluxo confiável. O remetente deve distinguir um ACK que avança a entrega de um que repete o limite atual.

Acompanhe os eventos do remetente

SendBase é o primeiro byte não reconhecido; NextSeqNum é o próximo número de byte não utilizado. Novos dados da aplicação são enviados com sequência NextSeqNum, que então avança pelo comprimento dos dados. Se nenhum temporizador de retransmissão estiver em execução, o envio de dados pendentes o inicia.

O algoritmo básico recomendado usa um temporizador de retransmissão para o segmento não reconhecido mais antigo. A expiração do tempo limite retransmite esse segmento pendente mais antigo, duplica o intervalo e reinicia o temporizador. Um ACK maior que SendBase avança a base e reinicia o temporizador se ainda houver dados pendentes. Se tudo for reconhecido, o temporizador para. Um ACK duplicado não avança a base.

ACKs perdidos podem deixar de ser um problema

A envia 500 bytes começando em 501. B os recebe e envia ACK 1.001, que é perdido. Se nada mais confirmar esses bytes, o tempo limite de A expira e A os reenvia. B reconhece a duplicata, não entrega dados adicionais e envia ACK 1.001 novamente.

Agora suponha que A também tenha enviado os 500 bytes seguintes, começando em 1.001. Se ACK 1.501 chegar antes da expiração do tempo limite, ele confirma os dois segmentos. A perda de ACK 1.001 não exige retransmissão. Um ACK é cumulativo, portanto o remetente não precisa de um ACK separado que chegue para cada segmento.

Em uma expiração prematura do tempo limite, A reenvia apenas o segmento mais antigo. Se ACKs atrasados confirmarem depois os dois segmentos originais, A não precisará reenviar o segundo. A expiração de um tempo limite é evidência de que a resposta não chegou a tempo, não prova de que todos os segmentos pendentes desapareceram.

Use o momento dos ACKs para informar lacunas

Para dados em ordem sem ACK pendente, o receptor pode atrasar brevemente um ACK, por menos de 0,5 s, para combinar reconhecimentos. Ele deve reconhecer pelo menos um a cada dois segmentos de tamanho completo. Uma segunda chegada em ordem enquanto há um ACK pendente aciona um ACK cumulativo. A chegada fora de ordem após uma lacuna aciona um ACK duplicado imediato; o preenchimento de toda ou parte de uma lacuna também aciona um ACK imediato.

Corrija uma lacuna antes da expiração do tempo limite

Suponha que A envie cinco segmentos de 1.000 bytes começando em 1.001, 2.001, 3.001, 4.001 e 5.001. O segundo é perdido. O ACK de B após o primeiro é 2.001. Cada uma das três chegadas posteriores produz outro ACK 2.001.

Após três ACKs duplicados, A usa a retransmissão rápida para reenviar o segmento que começa em 2.001 sem esperar a expiração do tempo limite. Com os dados posteriores armazenados em buffer, preencher essa lacuna permite que B reconheça 6.001. O primeiro ACK 2.001 é o ACK original; os três seguintes são duplicatas. Uma ou duas duplicatas podem resultar de reordenação comum, o que explica a espera por mais evidências.

O TCP combina ideias dos dois protocolos de janela. Seus ACKs cumulativos e seu temporizador único básico se assemelham ao GBN, mas seu armazenamento em buffer e sua retransmissão direcionada se assemelham à SR. O SACK negociado informa blocos de bytes mantidos após o limite cumulativo para que o remetente possa identificar várias lacunas com mais precisão. O TCP não envia NAK quando uma soma de verificação falha; a lacuna resultante é revelada por ACKs posteriores ou pela expiração do tempo limite.

O controle de fluxo impede que um remetente TCP cause o transbordamento do buffer do receptor. Ele responde à velocidade com que a aplicação receptora lê os dados. O controle de congestionamento responde à carga na rede; os dois controles protegem recursos diferentes.

Calcule o espaço disponível

Considere RcvBuffer como a capacidade do buffer, LastByteRcvd como o último byte em ordem armazenado e LastByteRead como o último byte lido pela aplicação. Nesse modelo de dados contíguos, o espaço ocupado é LastByteRcvd − LastByteRead. A janela de recepção é

O receptor anuncia o espaço disponível no campo de janela dos segmentos que envia de volta. O remetente mantém sua contagem de bytes não reconhecidos dentro desse limite:

Para RcvBuffer = 40.000 bytes, LastByteRcvd = 30.000 e LastByteRead = 18.000, a ocupação é 12.000 e rwnd é 28.000 bytes. ACK 30.001 com essa janela permite bytes não reconhecidos até 58.000. Se o remetente já enviou até 34.000, ele tem 4.000 bytes pendentes e pode enviar mais 24.000. A janela é um limite para todos os bytes pendentes, não uma permissão extra além deles.

Retome após uma janela zero

Quando não resta espaço, o receptor anuncia rwnd = 0 e o remetente interrompe a transmissão normal de novos dados. Quando a aplicação lê, o receptor anuncia o espaço recém-disponível em uma atualização de janela.

Essa atualização pode ser um ACK puro, que não é entregue de forma confiável por si só. Se ele for perdido, o remetente poderá continuar esperando mesmo que haja espaço. Sondagens de janela zero, que geralmente transportam um byte, levam o receptor a retornar sua janela atual. As sondagens são espaçadas em intervalos crescentes; elas não são envios normais em grande volume por uma janela fechada.

Relacione a janela à vazão

Com janela e RTT fixos, a vazão ideal limitada pela janela satisfaz

Use bytes e segundos para obter bytes/s. Uma janela de 65.535 bytes com RTT de 0,1 s permite cerca de 655.350 bytes/s, ou 5,2 Mbit/s. Uma taxa de enlace maior não consegue eliminar esse limite da janela.

Para preencher um caminho, a janela deve cobrir seu produto largura de banda-atraso. A 1 Gbit/s e 0,1 s, os dados necessários em trânsito são 100 milhões de bits, ou 12,5 MB. Esse é um tamanho de janela necessário para essa taxa ideal, não uma garantia de que ela será alcançada.

Aplique escala ao campo e evite atualizações minúsculas

O campo de 16 bits sozinho não consegue representar uma janela tão grande. Uma opção de fator de escala da janela negociada nos SYNs multiplica os valores de janela posteriores por $2^s$, com $s\le 14$. A maior escala resulta em um pouco menos de 1 GiB. Um deslocamento de 7 permite no máximo 8.388.480 bytes; um deslocamento de 8 permite 16.776.960, suficiente para o exemplo de 12,5 MB. O fator de escala permanece fixo para sua direção, enquanto o espaço anunciado muda. Os próprios campos de janela dos SYNs não são escalados.

Anunciar cada pequeno espaço de alguns bytes recém-liberados pode causar a síndrome da janela boba: muitos segmentos minúsculos com grande sobrecarga de cabeçalho. Para evitá-la, o receptor espera que haja uma quantidade útil de espaço livre, geralmente um MSS ou metade do buffer, o que for menor. O algoritmo de Nagle trata pequenas escritas do remetente retendo-as enquanto dados anteriores permanecem não reconhecidos ou até que haja dados suficientes para formar um segmento completo.