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

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?

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.

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.

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.

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 ;-)

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.

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

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".

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

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 .

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

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.