Resumo

  • O Multipath TCP oferece à aplicação um único fluxo confiável e ordenado, embora as pontas possam transportá-lo por um ou mais subfluxos TCP.
  • MP_CAPABLE negocia a conexão, MP_JOIN autentica um subfluxo adicional e a sequência comum permite retransmitir os mesmos dados por outro caminho depois de uma falha.
  • Duas interfaces não provam resiliência: os caminhos podem compartilhar um gargalo, um intermediário pode remover opções e a política da ponta decide se a segunda rota fica ativa, em reserva ou ausente.

Um socket que não precisa morrer com o Wi-Fi

A troca de acesso parece uma mudança de endereço. Um deixa de funcionar, outro aparece. Para a aplicação, porém, o objeto valioso é a conversa já iniciada: o estado acumulado e a sequência de bytes que deve chegar de forma confiável e na ordem certa.

O RFC 8684 separa conexão de caminho. Uma conexão MPTCP corresponde a um socket de aplicação, mas pode conter vários subfluxos. Cada subfluxo se comporta como TCP em sua própria rota. Acima deles, a conexão mantém a confiabilidade e a ordem esperadas. A perda de um subfluxo, portanto, não precisa encerrar o conjunto.

Essa possibilidade tem condições. As duas pontas precisam negociar MPTCP, ao menos um subfluxo utilizável deve permanecer ou ser criado, e o estado comum deve sobreviver. O protocolo fornece a mecânica da continuidade; não comprova cobertura, independência física ou qualidade da rota alternativa.

Um novo caminho precisa ser admitido

O primeiro subfluxo carrega MP_CAPABLE. As pontas confirmam suporte e trocam o material de chave da conexão. Se o outro host não suportar MPTCP, ou se um equipamento no caminho impedir a passagem das opções, a conexão pode voltar ao TCP comum.

Um endereço adicional não entra automaticamente. O novo handshake usa MP_JOIN: um token aponta para a conexão existente, enquanto números aleatórios e um HMAC derivado das chaves iniciais confirmam que o subfluxo pertence às mesmas pontas. A política local ainda pode recusá-lo. A segunda rota é uma decisão de admissão antes de ser uma alternativa de transporte.

ADD_ADDR anuncia outro endereço e REMOVE_ADDR o retira. IDs de endereço ajudam a lidar com a reescrita feita por NAT. Mesmo assim, o anúncio cria apenas um candidato. Não prova alcance, separação, preço ou desempenho.

O limite de controle fica evidente. A rede entrega alcance e influencia o encaminhamento. As pontas decidem se MPTCP foi negociado, quais candidatos viram subfluxos e quais são permitidos. Uma aplicação antiga pode enxergar apenas um socket normal e não perceber que a escolha de rota e custo ocorre abaixo dela.

Um livro-caixa para todos os bytes

Cada subfluxo conserva seus números de sequência TCP. O MPTCP acrescenta um número de sequência de dados de 64 bits para toda a conexão. O DSS associa os bytes de um subfluxo ao espaço comum e registra o avanço da recepção no nível da conexão.

Essa segunda contabilidade sustenta a recuperação. Se um subfluxo não entregar dados, os mesmos bytes podem ser retransmitidos por outro com novo mapeamento. A aplicação continua recebendo um fluxo único, confiável e ordenado; não precisa juntar duas conexões independentes.

A ordem também pode criar atraso. Um buraco no caminho lento segura dados posteriores que já chegaram pelo caminho rápido. O escalonador de pacotes, a reinjeção e o controle de congestionamento determinam se múltiplos caminhos ampliam a capacidade ou apenas acumulam espera. O RFC 8041 trata essa escolha como uma questão operacional real.

O caminho de reserva também tem preço

Um subfluxo pode ser normal ou de backup, e MP_PRIO pode solicitar mudança de prioridade. Atrás desse pequeno sinal há uma decisão econômica. A rede celular pode salvar a conexão, mas cobrar por volume. O satélite pode estar disponível com alta latência. Dois acessos fixos podem compartilhar duto ou trânsito.

O RFC 6182 adverte que pares de endereços diferentes não garantem caminhos disjuntos. A arquitetura busca mais vazão e resiliência, preserva o serviço do TCP e evita prejudicar injustamente outros usuários em gargalos compartilhados. São metas, não um laudo de qualquer implantação específica.

Por isso a evidência deve estar na conexão negociada: subfluxos efetivos, papéis ativo e reserva, domínios de falha, avanço dos reconhecimentos comuns e bytes enviados novamente por outro lugar. Contar interfaces mede possibilidades, não continuidade.

O recuo também faz parte do resultado

Equipamentos intermediários podem retirar opções TCP, reescrever endereços ou alterar dados de forma incompatível. O RFC 8684 define reações seguras: o primeiro subfluxo pode voltar ao TCP comum; um subfluxo adicional defeituoso pode ser encerrado; um caminho que perdeu mapeamentos válidos deve ser tratado como quebrado.

Assim, a aplicação pode funcionar sem que o recurso multipath exista. Uma monitoração que registra só o sucesso confunde duas situações: a conexão sobreviveu por outro subfluxo, ou MPTCP nunca operou e o TCP comum apenas continuou. Se a conexão ficou maior que um caminho, a prova operacional também precisa ficar.

Fontes