Protocolo de control de congestión de datagramas (DCCP)
En redes informáticas, el Protocolo de control de congestión de datagramas o DCCP por sus siglas en inglés Datagram Congestion Control Protocol es un protocolo de capa de transporte orientado a mensajes. DCCP implementa una configuración de conexión confiable, interrupción, notificación de congestión explícita (ECN), control de congestión y negociación de características. El IETF publicó DCCP como RFC 4340, un estándar propuesto, en marzo de 2006. RFC 4336 proporciona una introducción.
Operación
DCCP proporciona una forma de obtener acceso a los mecanismos de control de congestión sin tener que implementarlos en la capa de aplicación. Permite una semántica basada en el flujo como en el Protocolo de control de transmisión (TCP), pero no proporciona una entrega en orden confiable. La entrega secuenciada dentro de múltiples flujos como en el Protocolo de transmisión de control de flujo (SCTP) no está disponible en DCCP. Una conexión DCCP contiene tráfico de reconocimiento así como tráfico de datos. Los acuses de recibo informan a un remitente si sus paquetes han llegado y si fueron marcados por Notificación de congestión explícita (ECN). Los acuses de recibo se transmiten de forma tan fiable como lo requiere el mecanismo de control de congestión en uso, posiblemente de forma totalmente fiable.
DCCP tiene la opción de números de secuencia muy largos (48 bits) correspondientes a una ID de paquete, en lugar de una ID de byte como en TCP. La larga longitud de los números de secuencia tiene como objetivo proteger contra "algunos ataques ciegos, como la inyección de DCCP-Resets en la conexión".
Aplicaciones
DCCP es útil para aplicaciones con limitaciones de tiempo en la entrega de datos. Dichas aplicaciones incluyen transmisión de medios, juegos en línea para múltiples jugadores y telefonía por Internet. En tales aplicaciones, los mensajes antiguos rápidamente se vuelven inútiles, por lo que es preferible recibir mensajes nuevos que reenviar mensajes perdidos. A partir de 2017, estas aplicaciones a menudo se conformaron con TCP o utilizaron el Protocolo de datagramas de usuario (UDP) e implementaron sus propios mecanismos de control de congestión, o no tienen ningún control de congestión. Si bien es útil para estas aplicaciones, DCCP también puede servir como un mecanismo general de control de congestión para aplicaciones basadas en UDP, agregando, según sea necesario, mecanismos para una entrega confiable o en orden además de UDP/DCCP. En este contexto, DCCP permite el uso de mecanismos de control de congestión diferentes, pero generalmente compatibles con TCP.
Implementaciones
Los siguientes sistemas operativos implementan DCCP:
- FreeBSD, versión 5.1 como parche
- Linux desde la versión 2.6.14
Biblioteca de espacio de usuario:
- La implementación de DCCP-TP está optimizada para la portabilidad, pero no ha tenido cambios desde junio de 2008.
- El objetivo de GoDCCP de esta implementación es proporcionar un marco compatible con NAT portátil y estandarizado para comunicaciones punto a punto con control de congestión flexible, según la aplicación.
Estructura del paquete
El encabezado genérico DCCP toma diferentes formas dependiendo del valor de X, el bit de Números de Secuencia Extendidos. Si X es uno, el campo Número de secuencia tiene una longitud de 48 bits y el encabezado genérico ocupa 16 bytes, como se indica a continuación.
Compensaciones | Octeto | 0 | 1 | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Octeto | Un poco | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
0 | 0 | Puerto de origen | |||||||||||||||
2 | dieciséis | Puerto de destino | |||||||||||||||
4 | 32 | Compensación de datos | CCVal | CsCov | |||||||||||||
6 | 48 | Suma de verificación | |||||||||||||||
8 | 64 | res | Escribe | X=1 | Reservado | ||||||||||||
10 | 80 | Número de secuencia (bits altos) | |||||||||||||||
12 | 96 | Secuencia de números | |||||||||||||||
14 | 112 | Número de secuencia (bits bajos) |
Si X es cero, solo se transmiten los 24 bits inferiores del número de secuencia y el encabezado genérico tiene una longitud de 12 bytes.
Compensaciones | Octeto | 0 | 1 | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Octeto | Un poco | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
0 | 0 | Puerto de origen | |||||||||||||||
2 | dieciséis | Puerto de destino | |||||||||||||||
4 | 32 | Compensación de datos | CCVal | CsCov | |||||||||||||
6 | 48 | Suma de verificación | |||||||||||||||
8 | 64 | res | Escribe | X=0 | Número de secuencia (alto) | ||||||||||||
10 | 80 | Número de secuencia (bits bajos) |
Puerto de origen (16 bits)Identifica el puerto de envíoPuerto de destino (16 bits)Identifica el puerto receptorCompensación de datos(8 bits): el desplazamiento desde el inicio del encabezado DCCP del paquete hasta el inicio de su área de datos de aplicación, en palabras de 32 bits.CCVal (4 bits)Usado por el HC-Sender CCIDCobertura de suma de comprobación (CsCov) (4 bits)La cobertura de suma de control determina las partes del paquete que están cubiertas por el campo de suma de control.Suma de comprobación (16 bits)La suma de verificación de Internet del encabezado DCCP del paquete (incluidas las opciones), un pseudoencabezado de capa de red y, según la cobertura de la suma de verificación, todos, algunos o ninguno de los datos de la aplicación.Reservado (Res) (3 bits)Los remitentes DEBEN establecer este campo en todos los ceros en los paquetes generados, y los receptores DEBEN ignorar su valorTipo (4 bits)El campo Tipo especifica el tipo de paquete.Números de secuencia extendida (X) (1 bit)Establézcalo en uno para indicar el uso de un encabezado genérico extendido con números de acuse de recibo y secuencia de 48 bitsNúmero de secuencia (48 o 24 bits)Identifica el paquete de forma única en la secuencia de todos los paquetes que la fuente envió en esta conexión
El desarrollo actual
De manera similar a la extensión del protocolo TCP por capacidad de rutas múltiples (MPTCP), también para DCCP, la función de rutas múltiples se está discutiendo en IETF, denotada correspondientemente como MP-DCCP. Las primeras implementaciones ya se han desarrollado, probado y presentado en un enfoque colaborativo entre operadores y académicos y están disponibles como una solución de código abierto.
Contenido relacionado
Capa de abstracción
Cable coaxial
Capa de Internet