Por que o SCTP não é muito usado / conhecido

Recentemente, verifiquei o livro "UNIX Network Programming, Vol. 1", de Richards Stevens, e descobri que há um terceiro padrão de camada de transporte além do TCP e UDP: SCTP .

Resumo: O SCTP é um protocolo em nível de transporte controlado por mensagens como UDP, mas confiável como TCP. Aqui está uma breve introdução do IBM DeveloperWorks .

Sinceramente, nunca ouvi falar do SCTP antes. Não me lembro de ler sobre isso em nenhum livro sobre redes ou ouvir sobre isso nas aulas que eu havia frequentado. A leitura de outras perguntas sobre o stackoverflow que menciona o SCTP sugere que eu não estou sozinho com essa falta de conhecimento.

Por que o SCTP é tão desconhecido? Por que não é muito usado?

De fato, o SCTP é usado principalmente na área de telecomunicações. Tradicionalmente, os comutadores de telecomunicações usam o SS7 ( Sistema de sinalização nº 7 ) para interconectar diferentes entidades na rede de telecomunicações. Por exemplo - a base de dados de assinante (HLR) do provedor de telecomunicações, com um switch (MSC), o assinante também está conectado (MSC).

A área de telecomunicações está mudando para velocidades mais altas e ambiente mais acessível. Uma dessas mudanças é substituir o protocolo SS7 por um protocolo baseado em IP mais elegante, rápido e flexível.

A área de telecomunicações é muito conservadora. A rede SS7 é usada aqui há décadas. É uma rede muito confiável e fechada. Isso significa que um usuário comum não tem acesso a ele.

A rede IP, ao contrário, é aberta e não é confiável, e as telecomunicações não serão convertidas para ela se não suportar pelo menos a carga que o SS7 lida. É por isso que o SCTP foi desenvolvido. Tenta:

• imitar todas as vantagens da rede SS7 acumulada ao longo das décadas.
• criar um protocolo orientado a conexão melhor que o TCP em velocidade, segurança e redundância

Os últimos lançamentos do Linux já têm suporte a SCTP.

Temos implantado o SCTP em vários aplicativos agora e encontramos um problema significativo com o suporte ao SCTP em vários roteadores domésticos. Eles simplesmente não lidam com o SCTP corretamente. Acredito que este seja principalmente um problema de desempenho (a especificação do protocolo SCTP exige que somas de verificação para que todos os pacotes sejam recalculados e não apenas para cabeçalhos).

Como muitos outros protocolos promissores, o SCTP está tristemente morto na água até o D-link e o Netgear consertarem suas caixas NAT quebradas.

O SCTP requer mais design dentro do aplicativo para obter o melhor uso dele. Existem mais opções do que o TCP, a API do tipo Sockets veio mais tarde e é jovem. No entanto, acho que a maioria das pessoas que toma um tempo para entendê-lo (e que conhecem as deficiências do TCP) o aprecia - é um protocolo bem projetado que se baseia em nossos ~ 30 anos de conhecimento sobre TCP e UDP.

Um dos aspectos que requer reflexão é o dos fluxos. Os fluxos fornecem (normalmente, acho que você pode desativá-lo) uma garantia de pedido dentro deles (como uma conexão TCP), mas pode haver vários fluxos por conexão SCTP. Se os dados do seu aplicativo puderem ser enviados por vários fluxos, evite o bloqueio do cabeçalho de linha onde o receptor passará fome devido a um pacote incorreto. Conversas efetivamente diferentes podem ser realizadas na mesma conexão sem impactar uma à outra.

Outra adição útil é a do suporte à hospedagem múltipla - uma conexão pode estar em várias interfaces nas duas extremidades e lida com falhas. Você pode emular isso no TCP, mas na camada de aplicação.

A pulsação adequada do link, que é a primeira coisa que qualquer aplicativo que usa TCP para implementações de conexões não transitórias, existe gratuitamente.

Meu resumo pessoal do SCTP é que ele não faz nada que você não poderia fazer de outra maneira (em TCP ou UDP) com suporte substancial a aplicativos. O que ele fornece é a capacidade de não ter que implementar esse código (mal) você mesmo.

Para sua informação, o SCTP é obrigatório como suportado para o Diâmetro (cf. RADIUS next gen). veja RFC 3588

   Os clientes de diâmetro DEVEM suportar TCP ou SCTP, enquanto os agentes e
   os servidores DEVEM suportar ambos. Versões futuras desta especificação PODEM
   mandato que os clientes suportam SCTP.

O SCTP não é muito conhecido e não é muito utilizado / implantado porque:

• Generalizada: não amplamente integrada nas pilhas de TCP / IP (em 2013: ainda está faltando nativamente nos últimos Mac OSX e Windows)
• Bibliotecas: poucas ligações de alto nível em idiomas fáceis de usar (Isenção de responsabilidade: sou mantenedor do pysctp , suporte a pilha fácil SCTP para Python)
• NAT: não cruza muito bem o NAT (nada menos que 1% dos roteadores domésticos e empresariais da Internet fazem NAT no SCTP).
• Popularidade: Nenhum aplicativo público em geral usa
• Paradigma de programação: mudou um pouco: ainda é um soquete, mas você pode conectar muitos hosts a muitos hosts (multihoming), o datagrama é ordenado e confiável, erc ...
• Complexidade: a pilha SCTP é complexa de implementar (devido a acima)
• Concorrência: o TCP de caminhos múltiplos está chegando e deve atender às necessidades / capacidades de hospedagem múltipla, para que as pessoas evitem implementar o SCTP, se possível, aguardando o MTCP
• Nicho: precisa que os preenchimentos de SCTP sejam muito peculiares (datagramas confiáveis ​​solicitados, multitransmissões) e não são necessários para muitas aplicações
• Segurança: O SCTP evita os controles de segurança (alguns firewalls, a maioria dos IDSs, todos os DLPs, não aparecem no netstat, exceto o CentOS / Redhat / Fedora ...)
• Capacidade de auditoria: algo como três empresas no mundo fazem rotineiramente auditorias de segurança SCTP (Isenção de responsabilidade: trabalho em uma delas)
• Curva de aprendizado: Não há muito conjunto de ferramentas para jogar com o SCTP (verifique o excelente withsctp que combina muito bem com o netcat ou use socat)
• Sob o capô: usado principalmente em telecomunicações e sempre que você envia SMS, começa a navegar na Internet em seu celular ou faz chamadas telefônicas, muitas vezes aciona mensagens que fluem sobre SCTP (SIGTRAN / SS7 com GSM / UMTS, diâmetro com LTE / IMS / RCS, S1AP / X2AP com LTE), então você realmente usa muito, mas nunca sabe sobre isso ;-)

p1. O SCTP mapeado diretamente pelo IPv4 requer suporte nos gateways NAT, que nunca foram amplamente implantados em nenhum lugar, e sem ele o gateway NAT típico permitirá apenas que um host privado por endereço público use o SCTP por vez.

p2. O SCTP mapeado no UDP / IPv4 permite mais hosts privados por endereço público, mas os mapeamentos UDP nos gateways IPv4 / NAT são notoriamente difíceis de estabelecer e manter mantidos, devido ao fato de o UDP ser um transporte sem conexão sem nenhum estado explícito para o NAT rastrear .

p3 O SCTP mapeado diretamente sobre IPv6 requer ... bem ... IPv6. Você já tentou implantar o IPv6? Em caso afirmativo, você já tentou comprar um firewall IPv6? Ele suporta SCTP? Que tal um balanceador de carga? Um acelerador SSL?

p4 Por fim, grande parte da Internet está praticamente restrita ao que pode caber nas portas TCP 80 e 443, de modo que SCTP de qualquer tipo tende a perder por lá. Portanto, você vê esforços como o grupo de trabalho MPTCP na IETF.

Muitos de nós usaremos o SCTP em breve, pois ele é usado pelos canais de dados WebRTC para criar uma camada confiável do tipo TCP sobre o UDP - SCTP sobre DTLS sobre UDP: https://tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13 # section-6

Lendo a página da Wikipedia sobre SCTP, eu diria que o principal motivo é que o SCTP é um protocolo muito jovem (proposto em 2000) que atualmente não é suportado pelos sistemas operacionais convencionais ( Windows , OS X , Linux ).

Se "muito jovem" lhe parece inapropriado, pense no IPV6 : "em dezembro de 2008, apesar de marcar seu 10º aniversário como um protocolo Standards Track, o IPv6 estava apenas em sua infância em termos de implantação geral em todo o mundo".

O SCTP é amplamente utilizado na rede 4G LTE, em que o diâmetro é usado para AAA.

Pode não ser bem conhecido, mas não é usado. Recentemente, houve um rascunho publicado no IETF sobre o uso do SCTP como um protocolo de camada de transporte para HTTP .

Em referência a todos os comentários sobre roteadores comerciais quebrados ou sem suporte a SCTP, o problema é que o SCTP com NAT ainda está em forma de rascunho com a IETF. Portanto, não há especificação RFC para eles implementá-lo.

https://tools.ietf.org/html/draft-ietf-behave-sctpnat-09

O Sctp nasce tarde demais e, para muitas situações, o TCP é suficiente.

Além disso, como eu sei, a maior parte do seu uso é na área de telecomunicações.