En redes de computadoras , el Protocolo de control de congestión de datagramas ( DCCP ) es un protocolo de capa de transporte orientado a mensajes . DCCP implementa una configuración de conexión confiable, desconexión, notificación explícita de congestión (ECN), control de congestión y negociación de funciones. El IETF publicó DCCP como RFC 4340 , un estándar propuesto , en marzo de 2006. RFC 4336 proporciona una introducción.
DCCP proporciona una forma de acceder a los mecanismos de control de la congestión sin tener que implementarlos en la capa de aplicación . Permite la semántica basada en 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 acuse de recibo y tráfico de datos. Los acuses de recibo informan al remitente si sus paquetes han llegado y si fueron marcados por una notificación de congestión explícita.(ECN). Los acuses de recibo se transmiten de forma tan fiable como lo requiera el mecanismo de control de congestión en uso, posiblemente de forma totalmente fiable.
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 multijugador y telefonía por Internet . En tales aplicaciones, los mensajes antiguos se vuelven rápidamente inútiles, por lo que es preferible recibir nuevos mensajes a reenviar los perdidos. A partir de 2017, [actualizar]estas aplicaciones a menudo se han conformado con TCP o han utilizado el Protocolo de datagramas de usuario (UDP) e implementado 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 .
DCCP tiene la opción de números de secuencia muy largos (48 bits) correspondientes a un ID de paquete, en lugar de un ID de byte como en TCP. La gran 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 ". [1]
Implementaciones
Los siguientes sistemas operativos implementan DCCP:
Biblioteca del espacio de usuario:
- La implementación de DCCP-TP está optimizada para la portabilidad, pero no ha tenido cambios desde junio de 2008. [4]
- El propósito de GoDCCP de esta implementación es proporcionar un marco estandarizado, portátil y compatible con NAT para comunicaciones de igual a igual 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 48 bits de longitud 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 comprobación | |||||||||||||||
8 | 64 | Res | Tipo | 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 comprobación | |||||||||||||||
8 | 64 | Res | Tipo | 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ío
- Puerto de destino (16 bits)
- Identifica el puerto de recepción
- Compensación de datos
- (8 bits): el desplazamiento desde el inicio del encabezado DCCP del paquete hasta el inicio del área de datos de la aplicación, en palabras de 32 bits.
- CCVal (4 bits)
- Utilizado por HC-Sender CCID
- Cobertura de suma de comprobación (CsCov) (4 bits)
- La cobertura de suma de comprobación determina las partes del paquete que están cubiertas por el campo Suma de comprobación.
- Suma de comprobación (16 bits)
- La suma de comprobación de Internet del encabezado DCCP del paquete (incluidas las opciones), un pseudoencabezado de la capa de red y, según la Cobertura de la suma de comprobació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 valor
- Tipo (4 bits)
- El campo Tipo especifica el tipo de paquete.
- Números de secuencia ampliados (X) (1 bit)
- Establézcalo en uno para indicar el uso de un encabezado genérico extendido con números de secuencia y reconocimiento de 48 bits
- Nú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 multitrayecto ( MPTCP ) también para DCCP, la característica multitrayecto está siendo discutida en IETF [5] correspondientemente denotada como MP-DCCP . Las primeras implementaciones ya se han desarrollado, probado y presentado en un enfoque colaborativo entre los operadores y el mundo académico [6] y están disponibles como solución de código abierto.
Ver también
Referencias
- ^ RFC 4340 sección 7.6
- ^ "[dccp] Implementación de FreeBSD" . www.ietf.org . Consultado el 18 de abril de 2018 .
- ^ "Linux obtiene DCCP [LWN.net]" . lwn.net . Consultado el 18 de abril de 2018 .
- ^ Cambio de registro de la wiki dccp-tp, consultado el 13 de junio de 2011
- ^ https://tools.ietf.org/html/draft-amend-tsvwg-multipath-dccp
- ^ https://multipath-dccp.org/
enlaces externos
- Carta del Protocolo de control de congestión de datagramas de IETF (dccp)
Especificaciones de protocolo
- RFC 4340 - Protocolo de control de congestión de datagramas
- RFC 5595 - Códigos de servicio del Protocolo de control de congestión de datagramas (DCCP)
- RFC 5596 - Técnica DCCP de apertura simultánea para facilitar NAT / Middlebox Traversal
- RFC 5762 - RTP y DCCP
- RFC 5238 - Seguridad de la capa de transporte de datagramas (DTLS) sobre DCCP
- RFC 5634 - Inicio rápido para DCCP
- RFC 6773 - Un protocolo de control de congestión de datagramas encapsulado UDP para NAT transversal
ID de control de congestión
- RFC 4341 - Perfil para DCCP Control de congestión ID 2: Control de congestión similar a TCP
- RFC 4342 - Perfil para DCCP Control de congestión ID 3: Control de velocidad compatible con TCP (TFRC)
- RFC 5622 - Perfil para DCCP Control de congestión ID 4: Control de velocidad compatible con TCP para paquetes pequeños (TFRC-SP)
Otra información
- RFC 4336 - Declaración de problemas para el Protocolo de control de congestión de datagramas (DCCP)
- Página de DCCP de uno de los autores de DCCP
- Soporte DCCP en Linux
- Protocolo de control de congestión de datagramas (DCCP)