¿Por qué SCTP no es tan usado / conocido?

190

Recientemente revisé el libro "UNIX Network Programming, Vol. 1" de Richards Stevens y descubrí que hay un tercer estándar de capa de transporte además de TCP y UDP: SCTP .

Resumen: SCTP es un protocolo de nivel de transporte que es impulsado por mensajes como UDP, pero confiable como TCP. Aquí hay una breve introducción de IBM DeveloperWorks .

Honestamente, nunca antes había oído hablar de SCTP. No recuerdo haber leído sobre eso en ningún libro de redes o haber escuchado sobre eso en las clases que había tomado. La lectura de otras preguntas de stackoverflow que mencionan SCTP sugiere que no estoy solo con esta falta de conocimiento.

¿Por qué es tan desconocido SCTP? ¿Por qué no se usa mucho?

networking tcp popularity sctp dmeister
fuente
44
+1 nunca he oído hablar de eso, gracias.
Robert Venables
1
A cualquiera le importa comparar SCTP con ZeroMQ (además de que uno es un protocolo, el otro una biblioteca; mírelos como una herramienta para resolver problemas).
Emil Ivanov
Solo tengo curiosidad: ¿Qué está mal / diferente el 3/1/2013? ¿Por qué tantos votos en este día?
dmeister el
8
@dmeister: Porque te puse en Reddit . Saludos desde Darmstadt.
Janus Troelsen
32
Por favor no escriba 3/1/2013. Es preferible cualquiera de "1 de marzo de 2013", "1 de marzo de 2013", "1 de marzo de 2013". Simplemente no escriba mes y día del mes de una manera que pueda ser malinterpretada.
Zecc

Respuestas:

94

De hecho, SCTP se utiliza principalmente en el área de telecomunicaciones. Tradicionalmente, los interruptores de telecomunicaciones usan SS7 ( Sistema de señalización No. 7 ) para interconectar diferentes entidades en la red de telecomunicaciones. Por ejemplo: la base de datos de suscriptor del proveedor de telecomunicaciones (HLR), con un conmutador (MSC), el suscriptor también está conectado (MSC).

El área de telecomunicaciones se está moviendo a velocidades más altas y a un entorno más accesible. Uno de estos cambios es reemplazar el protocolo SS7 por un protocolo basado en IP más elegante, rápido y flexible.

El área de telecomunicaciones es muy conservadora. La red SS7 se ha utilizado aquí durante décadas. Es una red muy confiable y cerrada. Esto significa que un usuario normal no tiene acceso a él.

La red IP, por el contrario, está abierta y no es confiable, y las telecomunicaciones no se convertirán si no maneja al menos la carga que maneja SS7. Por eso se desarrolló SCTP. Intenta:

  • para imitar todas las ventajas de la red SS7 acumuladas a lo largo de las décadas.
  • para crear un protocolo orientado a la conexión mejor que TCP en velocidad, seguridad y redundancia

Las últimas versiones de Linux ya tienen soporte SCTP.

dimba
fuente
específicamente, debe mirar la salida del grupo de trabajo "SIGTRAN" del IETF que redactó la asignación entre SS7 y SCTP.
Alnitak
22
Probablemente, la razón principal por la que SCTP no se usa mucho en Internet pública es que las puertas de enlace residenciales IPv4 / NAT deben ser conscientes de SCTP para admitir asociaciones de multiplexación entre múltiples puntos finales privados simultáneos y hosts externos. Busque que SCTP sea más útil una vez que la transición a IPv6 comience a tomar más fuerza.
james woodyatt
@jameswoodyatt hay implementaciones de biblioteca de SCTP sobre UDP. Resuelve algunos de los problemas con los enrutadores de nivel de consumidor.
user7610
1
Esto no responde a la pregunta en absoluto. La respuesta de James contiene más información que la respuesta en realidad.
Ken Sharp
@jameswoodyatt Los enrutadores de nivel de consumidor con los que me he metido tienen soporte, incluso algunos bastante antiguos. El problema es que no está expuesto a través de la interfaz de usuario normal, por lo que debe hacer algunas cosas horribles en el sistema para poder configurarlo. Algo de un descuido en mi opinión.
Perkins
70

Hemos estado implementando SCTP en varias aplicaciones ahora, y encontramos un problema significativo con el soporte de SCTP en varios enrutadores domésticos. Simplemente no manejan SCTP correctamente. Creo que esto es principalmente un problema de rendimiento (la especificación del protocolo SCTP requiere sumas de verificación para que todos los paquetes se vuelvan a calcular y no solo para los encabezados).

Al igual que muchos otros protocolos prometedores, SCTP está tristemente muerto en el agua hasta que D-link y Netgear arreglan sus cajas NAT rotas.

pehrs
fuente
77
Wow, no estaba al tanto de esta barrera de entrada. Tiene toda la razón: consulte tools.ietf.org/html/draft-ietf-behave-sctpnat-05 para ver una propuesta sobre esto. Esta es la tercera serie de borradores de Internet sobre el mismo tema ...
Bwooce
Suena bastante pesimista, al menos para los enrutadores domésticos. Suponiendo que los enrutadores utilizados en entornos de producción profesionales lo admitan, SCTP todavía se ve muy útil. Hay muchos casos de uso en los que las topologías de red no abandonan las instalaciones del centro de datos, en cuyo caso SCTP debería ser perfecto.
Eugene Beresovsky
44
@EugeneBeresovksy: Han pasado algunos años desde que publiqué esa respuesta. Mi impresión es que SCTP no ha avanzado significativamente desde entonces. Todavía se usa en algunas aplicaciones especializadas en entornos controlados, pero rara vez se ve en la naturaleza. Windows y Mac OS X aún carecen de soporte SCTP fuera de la caja. La falta de familiaridad y la fragilidad de un protocolo roto por la mayoría de los firewalls y las cajas NAT hacen que las personas sean reacias a usarlo.
pehrs
@pehrs Me gustaría usarlo dentro de un centro de datos, por lo que no hay NAT involucrados ni firewalls, excepto los que están integrados en el sistema operativo. En un entorno de servidor Linux, espero que simplemente funcione. Pero incluso usando Windows, hay bibliotecas SCTP, y creo que sin tener que jugar con el sistema operativo.
Eugene Beresovsky
SCTP generalmente no está habilitado en Linux debido a su falta de adopción, pero incluso en mi sistema Ubuntu Precise (antiguo) está disponible como un módulo cargable. Proporcionar una aplicación que desee utilizar SCTP pero que recurrirá a TCP (por ejemplo) es un problema similar al doble apilamiento, pero más doloroso.
Ken Sharp
55

SCTP requiere más diseño dentro de la aplicación para obtener el mejor uso de la misma. Hay más opciones que TCP, la API tipo Sockets llegó más tarde y es joven. Sin embargo, creo que la mayoría de las personas que se toman el tiempo para entenderlo (y que conocen las deficiencias de TCP) lo aprecian: es un protocolo bien diseñado que se basa en nuestros ~ 30 años de conocimiento de TCP y UDP.

Uno de los aspectos que requiere cierta reflexión es el de las corrientes. Los flujos proporcionan (generalmente, creo que puede desactivarlo) una garantía de pedido dentro de ellos (al igual que una conexión TCP), pero puede haber múltiples flujos por conexión SCTP. Si los datos de su aplicación pueden enviarse a través de múltiples transmisiones, entonces evite el bloqueo de la línea de cabecera donde el receptor muere de hambre debido a un paquete perdido. Efectivamente se pueden tener diferentes conversaciones sobre la misma conexión sin impactar entre sí.

Otra adición útil es la de soporte multi-homing: una conexión puede ser a través de múltiples interfaces en ambos extremos y hace frente a fallas. Puede emular esto en TCP, pero en la capa de aplicación.

El enlace adecuado, que es lo primero que implementa cualquier aplicación que use TCP para conexiones no transitorias, está allí de forma gratuita.

Mi resumen personal de SCTP es que no hace nada que no podría hacer de otra manera (en TCP o UDP) con un importante soporte de aplicaciones. Lo que proporciona es la capacidad de no tener que implementar ese código (mal) usted mismo.

FYI, SCTP es obligatorio como compatible con Diameter (cf RADIUS next gen). ver RFC 3588

   Los clientes de diámetro DEBEN soportar TCP o SCTP, mientras que los agentes y
   Los servidores DEBEN soportar ambos. Las versiones futuras de esta especificación PUEDEN
   ordenan que los clientes admitan SCTP.
Bwooce
fuente
43

SCTP no es muy conocido y no se usa / implementa mucho porque:

  • Extendido: no está ampliamente integrado en las pilas TCP / IP (en 2013: todavía falta de forma nativa en los últimos Mac OSX y Windows)
  • Bibliotecas: pocos enlaces de alto nivel en lenguajes fáciles de usar (Descargo de responsabilidad: soy el encargado de mantener pysctp , el soporte de pila fácil SCTP para Python)
  • NAT: no cruza NAT muy bien / en absoluto (menos del 1% de los enrutadores domésticos y empresariales de Internet hacen NAT en SCTP).
  • Popularidad: ninguna aplicación pública general lo usa
  • Paradigma de programación: cambió un poco: sigue siendo un socket, pero puede conectar muchos hosts a muchos hosts (multihoming), el datagrama es ordenado y confiable, erc ...
  • Complejidad: la pila SCTP es compleja de implementar (debido a lo anterior)
  • Competencia: el TCP de múltiples rutas se acerca y debería abordar las necesidades / capacidades de múltiples sistemas para que las personas se abstengan de implementar SCTP si es posible, esperando el MTCP
  • Nicho: los rellenos SCTP necesarios son muy peculiares (datagramas confiables ordenados, multitransmisión) y muchas aplicaciones no los necesitan.
  • Seguridad: SCTP evade los controles de seguridad (algunos firewalls, la mayoría de los IDS, todos los DLP, no aparecen en netstat excepto CentOS / Redhat / Fedora ...)
  • Capacidad de auditoría: Algo así como 3 empresas en el mundo realizan auditorías de seguridad SCTP de forma rutinaria (Descargo de responsabilidad: trabajo en una de ellas)
  • Curva de aprendizaje: no hay mucha cadena de herramientas para jugar con SCTP (verifique el excelente withsctp que combina muy bien con netcat o use socat)
  • Bajo el capó: Utilizado principalmente en telecomunicaciones y cada vez que envía SMS, comienza a navegar por la red en su teléfono móvil o realiza llamadas telefónicas, a menudo está activando mensajes que fluyen a través de SCTP (SIGTRAN / SS7 con GSM / UMTS, Diámetro con LTE / IMS / RCS, S1AP / X2AP con LTE), por lo que en realidad lo usas mucho pero nunca lo sabes ;-)
Phil L.
fuente
14
Re: "Nicho / no es necesario para muchas aplicaciones". Los navegadores web se beneficiarían de ello, vea HTTP2 y sus intentos de implementar, además de TCP, algo de lo que SCTP regala de forma gratuita. La mayoría de las técnicas de optimización HTTP (spriting, sharding, inlining, concatenation) se harían (casi por completo, los encabezados derrochadores de HTTP1 siguen sin resolverse) redundantes por SCTP. Lo mismo es cierto para las aplicaciones que tienen un grupo de conexiones para permitir el acceso concurrente a un DB o cualquier otro servicio. En otras palabras: existe una gran necesidad de muchas aplicaciones para algunas de las funciones de SCTP.
Eugene Beresovsky
44
"Ninguna aplicación pública general lo usa": ya no es cierto, ya que WebTP utiliza SCTP. "Seguridad: SCTP evade los controles de seguridad", eso es más un problema de los controles de 'seguridad'. Si evita esas comprobaciones, sería un protocolo maravilloso para que el malware permanezca fuera del radar.
Maciej Piechotka
14

p1. El SCTP mapeado directamente sobre IPv4 requiere soporte en las puertas de enlace NAT, que nunca se ha implementado ampliamente en ningún lugar, y sin ella, la puerta de enlace NAT típica solo permitirá que un host privado por dirección pública use SCTP a la vez.

p2. El SCTP asignado a través de UDP / IPv4 permite más hosts privados por dirección pública, pero las asignaciones UDP en las puertas de enlace IPv4 / NAT son muy difíciles de establecer y mantener, debido al hecho de que UDP es un transporte sin conexión sin un estado explícito para que un NAT lo rastree .

p3. SCTP mapeado directamente sobre IPv6 requiere ... bueno ... IPv6. ¿Has intentado implementar IPv6? Si es así, ¿ha intentado comprar un firewall IPv6? ¿Es compatible con SCTP? ¿Qué tal un balanceador de carga? ¿Un acelerador SSL?

p4. Finalmente, gran parte de Internet está bastante restringido a lo que cabe a través del puerto TCP 80 y el puerto 443, por lo que el SCTP de cualquier sabor tiende a perderse allí. Por lo tanto, ve esfuerzos como el grupo de trabajo MPTCP en IETF.

James Woodyatt
fuente
"¿ha intentado comprar un cortafuegos IPv6? ¿Es compatible con SCTP"? El habitual distribuido libremente los iptables admite perfectamente . Sin embargo, no soy un chico de la red, así que no puedo decir lo demás.
Hola Ángel
12

Muchos de nosotros usaremos SCTP pronto, ya que es utilizado por los canales de datos WebRTC para crear una capa confiable similar a TCP sobre UDP - SCTP sobre DTLS sobre UDP: https://tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13 # section-6

cjb
fuente
Olvidé mencionar que el enfoque principal de WebRTC es la transmisión combinada de video y audio. No está destinado a ser utilizado como retransmisión de mensajes. Los servicios de giro / hielo / aturdimiento son otra parte de la tecnología en la que se ejecuta WebRTC. Pero estas son tecnologías que utiliza WebRTC. Esas tecnologías no son WebRTC.
TamusJRoyce
6

Al leer la página de Wikipedia SCTP , diría que la razón principal es que SCTP es un protocolo muy joven (propuesto en 2000) que actualmente no es compatible con los sistemas operativos principales ( Windows , OS X , Linux ).

Si "muy joven" le parece inapropiado, piense en IPV6 : "en diciembre de 2008, a pesar de celebrar su décimo aniversario como un protocolo de Standard Track, IPv6 solo estaba en su infancia en términos de despliegue mundial en general".

IlDan
fuente
3
Según el artículo de Wikipedia al que se vinculó, SCTP se implementa en Linux, Solaris, FreeBSD, HP-UX y otros.
drrlvn
El artículo vinculado ahora también dice que se ejecuta en OS X y Windows.
dmeister
3

SCTP se usa ampliamente en la red 4G LTE donde se usa Diameter para AAA.

Lynne Patterson
fuente
2

Puede que no sea bien conocido, pero no está sin usar. Recientemente, se publicó un borrador en el IETF sobre el uso de SCTP como protocolo de capa de transporte para HTTP .

mkoeller
fuente
2
Cuando dijiste "no usado", pensé en el uso real del protocolo. Pero luego solo dio un ejemplo de un borrador de documento , que puede conducir a un uso real en el futuro.
Kissaki
2

En referencia a todos los comentarios acerca de que los enrutadores comerciales están rotos o no tienen soporte SCTP, el problema es que SCTP con NAT todavía está en forma de borrador con el IETF. Por lo tanto, no hay una especificación RFC para que puedan implementarlo.

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

Terry Bowling
fuente
-1

Sctp nace demasiado tarde, y para muchas situaciones TCP es suficiente.

Además, como sé, la mayor parte de su uso es en el área de telecomunicaciones.

Sam Liao
fuente