Por que SCTP não muito usado / conhecido

StackOverflow https://stackoverflow.com/questions/1171555

Pergunta

Recentemente, verificamos o livro "Rede UNIX Programação, Vol. 1" por Richards Stevens e eu achei que há um terceiro padrão da camada de transporte, além de TCP e UDP: SCTP .

Resumo: SCTP é um protocolo de nível de transporte que é como UDP orientado por mensagem, mas confiável como o TCP. Aqui é um breve introdução do IBM DeveloperWorks .

Honestamente, eu nunca ouvi falar de SCTP antes. Não me lembro de ler sobre ela em todos os livros de rede ou ouvir sobre isso nas aulas que eu tinha tomado. Leitura perguntas outra stackoverflow que menciona SCTP sugere que eu não estou sozinho com essa falta de conhecimento.

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

Foi útil?

Solução

Na verdade, SCTP é usado principalmente na área de telecomunicações. Tradicionalmente, os interruptores de telecomunicações utilize SS7 ( sistema de sinalização No. 7 ) para interligar diferentes entidades na rede de telecomunicações . Por exemplo - base de dados de assinantes do provedor de telecom (HLR), com um switch (MSC), o assinante está ligado também (MSC)

.

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

A área de telecomunicações é muito conservador. A rede SS7 tem sido usado aqui há décadas. É muito uma rede confiável e fechado. Isso significa que um usuário regular não tem acesso a ele.

A rede IP, ao contrário, está aberto e não confiável, e telecomunicações não irá converter a ele se ele não vai lidar com, pelo menos, a carga que alças SS7. É por isso que SCTP foi desenvolvido. Tenta:

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

As versões mais recentes do Linux já tem o apoio SCTP.

Outras dicas

Estamos implantando SCTP em várias aplicações agora, e encontrou problema significativo com o apoio SCTP em vários roteadores domésticos. Eles simplesmente não lidar com SCTP corretamente. Eu acredito que este é essencialmente um problema de desempenho (a especificação do protocolo SCTP exigem somas de verificação para todo os pacotes de ser recalculado e não apenas para cabeçalhos).

Como muitos outros protocolos promissores SCTP é, infelizmente, morto na água até D-link e Netgear corrige suas caixas NAT quebrados.

SCTP requer mais projeto dentro do aplicativo para obter o melhor uso dele. Há mais opções do TCP, o API Sockets-like veio mais tarde, e ele é jovem. No entanto eu acho que a maioria das pessoas que tomam o tempo para compreendê-lo (e quem sabe as deficiências do TCP) apreciá-lo - é um protocolo bem concebido que se baseia em nossas ~ 30 anos de conhecimento de TCP e UDP

.

Um dos aspectos que requer algum pensamento é que de fluxos. Streams fornecer (normalmente, eu acho que você pode desligá-lo) uma garantia fim dentro deles (muito parecido com uma conexão TCP), mas pode haver múltiplos fluxos por conexão SCTP. Se os dados da sua aplicação podem ser enviados através de múltiplos fluxos, então você evitar cabeça-de-linha bloqueando onde os morre de fome receptor devido a um pacote extraviado. Efetivamente diferentes conversas pode ser tido sobre a mesma conexão sem afetar o outro.

Outra adição útil é a de apoio multi-homing - uma conexão pode ser através de múltiplas interfaces de em ambas as extremidades e que lida com falhas. Você pode emular isso em TCP, mas na camada de aplicação.

heartbeating ligação adequada, que é a primeira coisa que qualquer aplicativo usando TCP para conexões de implementos não-transitórios, é lá de graça.

O meu resumo pessoal do SCTP é que ele não faz nada que você não podia fazer outra maneira (em TCP ou UDP) com pedido apoio substancial. A coisa que ele fornece é a capacidade de não ter que implementar esse código (mal) você mesmo.

FYI, SCTP é obrigatória como suporte para Diâmetro (cf RADIUS próxima gen). veja RFC 3588 

   Diameter clients MUST support either TCP or SCTP, while agents and
   servers MUST support both.  Future versions of this specification MAY
   mandate that clients support SCTP.

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

  • generalizada: Não amplamente integrado em pilhas TCP / IP (em 2013: ainda está faltando nativamente no mais recente Mac OSX e Windows)
  • Bibliotecas: Poucas ligações de alto nível em fácil de usar línguas (Disclaimer: Eu sou mantenedor do pysctp , apoio pilha fácil SCTP para Python)
  • NAT: não atravessa NAT muito bem / em todos (menos de 1% de internet domésticos e corporativos routers fazer NAT em SCTP)
    • .
  • popularidade: Não uso geral aplicativo público it
  • Programação de paradigma: ela mudou um pouco: ainda é uma tomada, mas você pode conectar muitos anfitriões de muitos anfitriões (multihoming), datagrama é ordenada e confiável, erc ...
  • Complexidade: pilha SCTP é complexo de implementar (devido ao acima)
  • Concorrência: Multipath TCP está chegando e deve abordar multihoming necessidades / capacidades para que as pessoas se abstenham de implementação SCTP, se possível, à espera de MTCP
  • Nicho: Necessidades preenchimentos SCTP são muito peculiares (datagramas encomendados confiáveis, multistream) e não necessários para tanto aplicações
  • Segurança: evade SCTP controles de segurança (alguns firewalls, a maioria dos IDSs, todos DLPs, não aparece no netstat exceto CentOS / Red Hat / Fedora ...)
  • Audit-capacidade: Algo como 3 empresas no mundo fazem rotineiramente auditorias de segurança SCTP (Disclaimer: trabalho eu em um deles)
  • curva de aprendizado: Não muito toolchain para jogo com SCTP (verifique o excelente withsctp que combina muito bem com netcat ou o uso socat)
  • Sob o capô: Usado principalmente em telecomunicações e toda vez que você enviar SMS, começar a navegar na net em suas chamadas de telefone móvel ou fazer, você está sempre provocando mensagens que fluem ao longo SCTP (SIGTRAN / SS7 com GSM / UMTS, diâmetro, com LTE / IMS / RCS, S1AP / X2AP com LTE), para que você realmente usá-lo muito, mas você nunca sabe sobre ele; -)

p1. SCTP mapeados diretamente sobre IPv4 requer suporte em gateways NAT, que nunca foi amplamente implantado em qualquer lugar, e sem ele o gateway típica NAT só irá permitir um host privado per endereço público para ser usando SCTP de cada vez.

p2. SCTP mapeado sobre UDP / IPv4 permite que os hosts mais particulares por endereço público, mas mapeamentos UDP em IPv4 / gateways NAT são notoriamente difíceis de estabelecer e manter mantida, devido ao fato de que o UDP é um transporte sem conexão, sem qualquer estado explícito para um NAT para a faixa .

P3. SCTP mapeados diretamente sobre IPv6 exige ... bem ... IPv6. Você já tentou implantar IPv6? Se assim for, você já tentou comprar um firewall IPv6? Ele suporta SCTP? Como cerca de um balanceador de carga? Um acelerador de SSL?

P4. Finalmente, um monte da Internet está praticamente restrito ao que pode caber através da porta TCP 80 e 443, de modo SCTP de qualquer sabor tende a perder lá. Assim, você vê os esforços como o href="http://tools.ietf.org/wg/mptcp/"> MPTCP grupo de trabalho no IETF.

A leitura do href="http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol" rel="nofollow noreferrer"> SCTP Wikipedia página eu diria que a principal razão é que SCTP é um protocolo muito jovem (proposto em 2000), que é atualmente suportado pelo mainstream OSs ( Windows , oS X , Linux ).

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

SCTP é amplamente utilizado na rede 4G LTE onde diâmetro é usado para AAA.

Pode não ser bem conhecido, mas não é utilizada. Muito recentemente houve uma projecto publicada no < a href = "http://www.ietf.org/" rel = "nofollow noreferrer"> IETF sobre Usando SCTP como uma camada de transporte protocolo para HTTP .

No que se refere a todos os comentários sobre roteadores comerciais sendo quebrado ou faltando apoio SCTP, a questão é que SCTP com NAT ainda está em fase de projecto com o IETF. Portanto, não há especificação RFC para eles para implementá-lo.

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

SCTP é nascido tarde demais, e para muitos situação TCP é suficiente.

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

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top