Uma das principais vantagens do SCTP sobre o TCP é o suporte para Multihoming,
Do ponto de vista da aplicação, isso permite que um “soquete” seja compartilhado entre vários endereços IP, permitindo vários caminhos IP e NICs físicos.
Através do multihoming podemos proteger contra falhas no roteamento IP e nos links físicos, a partir de um protocolo da camada de transporte.
Então, vamos dar uma olhada em como isso realmente funciona,
Para começar, existem algumas maneiras pelas quais o multihoming pode ser implementado, idealmente temos vários IPs em ambas as extremidades (“cliente” e “servidor”), mas isso nem sempre é possível, então o SCTP suporta multi-homing parcial, onde, por exemplo, o cliente tem apenas um IP, mas pode contatar o servidor em vários endereços IP e vice-versa.
A imagem abaixo (Cortesia da Wikimedia) mostra o cenário ideal, onde tanto o cliente quanto o servidor possuem vários IPs pelos quais podem ser acessados.
Isso significaria uma falha de qualquer um dos endereços IP ou do roteamento entre eles, faria com que os outros endereços IP secundários fossem usados ​​para transporte e o aplicativo nem sequer necessariamente estaria ciente da interrupção no caminho IP primário.
Para começar, cada um de nosso cliente/servidor SCTP precisará estar ciente dos IPs que podem ser usados,
Isto é anunciado na mensagem INIT, enviada pelo “cliente” para um “servidor” quando a sessão SCTP é estabelecida.
Na imagem acima podemos ver os dois IPs para uso do SCTP, o IP primário é o primeiro (10.0.1.185) e também o IP de origem, e há apenas um IP adicional (10.0.1.187) embora possa haver mais .
Em um ambiente de produção, você deseja garantir que cada um dos seus IPs esteja em uma sub-rede diferente, com caminhos, hardware e rotas diferentes.
Assim, o INIT é então respondido pelo cliente com um INIT_ACK, e desta vez o servidor anuncia seus endereços IP, o IP primário é o endereço IP De (10.0.1.252) e há apenas um IP adicional de 10.0.1.99,
É importante notar que de acordo com RFC 4960 Multi-homing é opcional, assim como o cabeçalho do endereço IP, se não for anunciado, o remetente é single-homed.
Em seguida temos a troca de cookies, que é usada para proteção contra ataques de sincronização, e então nossa sessão SCTP é ativada.
Então, o que acontece neste momento? Como sabemos se um caminho está funcionando e funcionando?
Bem, a resposta são mensagens de batimentos cardíacos,
Enviado de cada um dos IPs do cliente para cada um dos IPs do servidor, para garantir que haja um caminho de cada IP para todos os outros IPs.
Isso significa que as pilhas SCTP sabem se um caminho falha, por exemplo, se a rota para IP 10.0.1.252 no servidor falhar, a pilha SCTP sabe que tem outra opção, 10.0.1.99, que está monitorando.
Portanto, esse é o SCTP multi-homed em ação – embora muito trabalho tenha sido feito historicamente com o LACP para agregar vários NICs e o VRRP para garantir que um host esteja ativo, o SCTP lida com isso de maneira limpa e eficiente.
Anexei um PCAP mostrando multi-homing em uma interface Diameter S6a (HSS) entre um MME e um HSS.