Protocolo de controle de congestionamento de datagrama - Datagram Congestion Control Protocol
| Suíte de protocolo de Internet |
|---|
| Camada de aplicação |
| Camada de transporte |
| Camada de Internet |
| Camada de link |
Em redes de computadores , o Datagram Congestion Control Protocol ( DCCP ) é um protocolo de camada de transporte orientado a mensagens . O DCCP implementa configuração de conexão confiável, desmontagem, notificação explícita de congestionamento (ECN), controle de congestionamento e negociação de recursos. O IETF publicou o DCCP como RFC 4340 , um padrão proposto , em março de 2006. O RFC 4336 fornece uma introdução.
Operação
O DCCP fornece uma maneira de obter acesso aos mecanismos de controle de congestionamento sem ter que implementá-los na camada de aplicativo . Ele permite uma semântica baseada em fluxo, como no Transmission Control Protocol (TCP), mas não fornece uma entrega confiável no pedido. A entrega sequenciada em vários fluxos, como no protocolo de transmissão de controle de fluxo (SCTP), não está disponível no DCCP. Uma conexão DCCP contém tráfego de confirmação , bem como tráfego de dados. Os agradecimentos informam a um remetente se seus pacotes chegaram e se foram marcados por Notificação de Congestionamento Explícita (ECN). Os reconhecimentos são transmitidos de forma tão confiável quanto o mecanismo de controle de congestionamento em uso requer, possivelmente de forma totalmente confiável.
O DCCP tem a opção de números de sequência muito longos (48 bits) correspondentes a um ID de pacote, em vez de um ID de byte como no TCP. O comprimento longo dos números de sequência visa proteger contra "alguns ataques cegos, como a injeção de DCCP-Resets na conexão".
Formulários
O DCCP é útil para aplicativos com restrições de tempo na entrega de dados. Essas aplicações incluem streaming media , jogos multijogador online e telefonia pela Internet . Em tais aplicativos, as mensagens antigas tornam-se rapidamente inúteis, de modo que obter novas mensagens é preferível a reenviar as mensagens perdidas. A partir de 2017, esses aplicativos muitas vezes se conformaram com o TCP ou usaram o User Datagram Protocol (UDP) e implementaram seus próprios mecanismos de controle de congestionamento ou não têm nenhum controle de congestionamento. Embora seja útil para esses aplicativos, o DCCP também pode servir como um mecanismo geral de controle de congestionamento para aplicativos baseados em UDP, adicionando, conforme necessário, mecanismos para entrega confiável ou em ordem em cima do UDP / DCCP. Nesse contexto, o DCCP permite o uso de mecanismos de controle de congestionamento diferentes, mas geralmente amigáveis ao TCP .
Implementações
Os seguintes sistemas operacionais implementam DCCP:
Biblioteca do espaço de usuário:
- A implementação do DCCP-TP é otimizada para portabilidade, mas não sofreu alterações desde junho de 2008.
- O objetivo do GoDCCP desta implementação é fornecer uma estrutura compatível com NAT portátil e padronizada para comunicações ponto a ponto com controle de congestionamento flexível, dependendo da aplicação.
Estrutura do Pacote
O cabeçalho genérico DCCP assume diferentes formas dependendo do valor de X, o bit Extended Sequence Numbers. Se X for um, o campo Sequence Number tem 48 bits e o cabeçalho genérico leva 16 bytes, como segue.
| Offsets | Octeto | 0 | 1 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octeto | Pedaço | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 0 | 0 | Porta de origem | |||||||||||||||
| 2 | 16 | Porto de destino | |||||||||||||||
| 4 | 32 | Compensação de dados | CCVal | CsCov | |||||||||||||
| 6 | 48 | Checksum | |||||||||||||||
| 8 | 64 | Res | Modelo | X = 1 | Reservado | ||||||||||||
| 10 | 80 | Número de sequência (bits altos) | |||||||||||||||
| 12 | 96 | Número sequencial | |||||||||||||||
| 14 | 112 | Número de sequência (bits baixos) | |||||||||||||||
Se X for zero, apenas os 24 bits baixos do número de sequência são transmitidos e o cabeçalho genérico tem 12 bytes de comprimento.
| Offsets | Octeto | 0 | 1 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octeto | Pedaço | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 0 | 0 | Porta de origem | |||||||||||||||
| 2 | 16 | Porto de destino | |||||||||||||||
| 4 | 32 | Compensação de dados | CCVal | CsCov | |||||||||||||
| 6 | 48 | Checksum | |||||||||||||||
| 8 | 64 | Res | Modelo | X = 0 | Número de sequência (alto) | ||||||||||||
| 10 | 80 | Número de sequência (bits baixos) | |||||||||||||||
- Porta de origem (16 bits)
- Identifica a porta de envio
- Porta de destino (16 bits)
- Identifica a porta de recepção
- Compensação de dados
- (8 bits): O deslocamento do início do cabeçalho DCCP do pacote até o início da área de dados do aplicativo, em palavras de 32 bits.
- CCVal (4 bits)
- Usado pelo HC-Sender CCID
- Cobertura de soma de verificação (CsCov) (4 bits)
- O Checksum Coverage determina as partes do pacote que são cobertas pelo campo Checksum.
- Soma de verificação (16 bits)
- A soma de verificação da Internet do cabeçalho DCCP do pacote (incluindo opções), um pseudo-cabeçalho da camada de rede e, dependendo da cobertura da soma de verificação, todos, alguns ou nenhum dos dados do aplicativo
- Reservado (Res) (3 bits)
- Os remetentes DEVEM definir este campo com todos os zeros nos pacotes gerados e os destinatários DEVEM ignorar o seu valor
- Tipo (4 bits)
- O campo Tipo especifica o tipo do pacote
- Números de sequência estendida (X) (1 bit)
- Defina como um para indicar o uso de um cabeçalho genérico estendido com Sequência de 48 bits e Números de Confirmação
- Número de sequência (48 ou 24 bits)
- Identifica o pacote exclusivamente na sequência de todos os pacotes que a fonte enviou nesta conexão
Desenvolvimento atual
Similarmente à extensão do protocolo TCP pela capacidade de multipath ( MPTCP ) também para DCCP, o recurso de multipath está em discussão na IETF correspondentemente denotado como MP-DCCP . As primeiras implementações já foram desenvolvidas, testadas e apresentadas em uma abordagem colaborativa entre operadoras e academia e estão disponíveis como solução Open Source.
Veja também
- Protocolo de transmissão de controle de fluxo (SCTP)
- Camada de transporte § Comparação de protocolos da camada de transporte
Referências
links externos
Especificações de protocolo
- RFC 4340 - Protocolo de Controle de Congestionamento de Datagrama
- RFC 5595 - Códigos de serviço do protocolo de controle de congestionamento de datagrama (DCCP)
- RFC 5596 - Técnica de abertura simultânea DCCP para facilitar a passagem de NAT / caixa intermediária
- RFC 5762 - RTP e o DCCP
- RFC 5238 - Datagram Transport Layer Security (DTLS) sobre DCCP
- RFC 5634 - Início rápido para DCCP
- RFC 6773 - Um protocolo de controle de congestionamento de datagrama Encapsulamento UDP para NAT Traversal
IDs de controle de congestionamento
- RFC 4341 - Perfil para DCCP Congestion Control ID 2: TCP-like Congestion Control
- RFC 4342 - Perfil para DCCP Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
- RFC 5622 - Perfil para DCCP Congestion Control ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)
Outra informação
- RFC 4336 - Declaração de problema para o protocolo de controle de congestionamento de datagrama (DCCP)
- Página DCCP de um dos autores DCCP
- Suporte DCCP em Linux
- Protocolo de controle de congestionamento de datagrama (DCCP)