데이터그램 폭주 제어 프로토콜

Datagram Congestion Control Protocol
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

컴퓨터 네트워킹에서 DCCP(Datagram congestion Control Protocol)는 메시지 지향 전송 계층 프로토콜입니다.DCCP는 신뢰성 높은 접속 셋업, 티어다운, Explicit Congestion Notification(ECN), congestion 제어 및 기능 네고시에이션을 실장합니다.IETF는 DCCP를 다음과 같이 공개했습니다. 2006년 3월에 제안된 표준 RFC4340.RFC 4336에서는 개요에 대해 설명합니다.

작동

DCCP를 사용하면 congestion 제어 메커니즘에 액세스 할 수 있습니다.어플리케이션레이어에 congestion 제어 메커니즘을 실장할 필요는 없습니다.Transmission Control Protocol(TCP)과 같은 흐름 기반의 시멘틱스를 사용할 수 있지만 신뢰할 수 있는 순서대로 전달하지는 않습니다.Stream Control Transmission Protocol(SCTP)과 같이 여러 스트림 내에서 시퀀싱된 전달은 DCCP에서는 사용할 수 없습니다.DCCP 접속에는 확인 응답 트래픽과 데이터 트래픽이 포함됩니다.확인 응답은, 패킷이 도착했는지 어떤지, 및 패킷이 Explicit Congestion Notification(ECN; 명시적 congestion 통지)에 의해서 마크 되어 있는지를 송신자에게 통지합니다.확인 응답은, 사용중의 congestion 제어 메카니즘이 필요로 하는 만큼, 완전하게 신뢰할 수 있는 방법으로 송신됩니다.

DCCP 에는, TCP 와 같이 바이트 ID 가 아니고, 패킷 ID 에 대응하는 매우 긴(48 비트) 시퀀스 번호의 옵션이 있습니다.시퀀스 번호의 긴 길이는 "접속으로의 DCCP-Reset 주입 등 일부 블라인드 공격"[1]을 방지하는 것을 목적으로 합니다.

적용들

DCCP 는, 데이터 전송의 타이밍 제약이 있는 애플리케이션에 도움이 됩니다.이러한 애플리케이션에는 스트리밍 미디어, 멀티플레이어 온라인 게임 및 인터넷 전화 등이 포함됩니다.이러한 응용 프로그램에서는 오래된 메시지는 금방 무용지물이 되기 때문에 잃어버린 메시지를 재발송하는 것보다 새로운 메시지를 받는 것이 더 좋습니다.2017년 현재 이러한 애플리케이션은 TCP에 안착하거나 UDP(User Datagram Protocol)를 사용하여 자체 congestion-control 메커니즘을 구현하거나 congestion 제어 기능이 전혀 없습니다.DCCP는 이러한 어플리케이션에서는 유용하지만 필요에 따라 UDP/DCCP 위에 신뢰성 높은 전달 또는 순서대로 전달하기 위한 메커니즘을 추가하여 UDP 기반 어플리케이션의 일반적인 congestion 제어 메커니즘으로도 사용할 수 있습니다.이 컨텍스트에서는, DCCP 를 사용하면, 다른, 그러나 일반적으로 TCP 친화적인 congestion 제어 메커니즘을 사용할 수 있습니다.

실장

다음의 operating system에서는, DCCP 를 실장하고 있습니다.

  • FreeBSD 버전 5.1을 패치로 사용
  • 버전 2.6.14 이후 Linux

사용자 공간 라이브러리:

  • Wayback Machine 구현에서의 DCCP-TP Archived 2008-07-23은 휴대성에 최적화되어 있으나 [4]2008년6월 이후 변경은 없습니다.
  • 이 실장의 목적은 애플리케이션에 따라 유연한 congestion 제어에 의해 피어 투 피어 통신용으로 표준화된 이식 가능한 NAT 프레임워크를 제공하는 것입니다.

패킷 구조

DCCP 범용 헤더는 X 값(확장 시퀀스 번호 비트)에 따라 다른 형식을 취합니다.X가 1인 경우 Sequence Number 필드의 길이는 48비트이며 일반 헤더는 다음과 같이 16바이트가 소요됩니다.

DCCP 범용 헤더
오프셋 옥텟 0 1
옥텟 조금 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 0 송신원포트
2 16 수신처 포트
4 32 데이터 오프셋 CCVal CsCov
6 48 체크섬
8 64 리즈 유형 X=1 예약필
10 80 시퀀스 번호(하이 비트)
12 96 시퀀스 번호
14 112 시퀀스 번호(저비트)

X가 0인 경우 시퀀스 번호의 하위 24비트만 전송되며 범용 헤더의 길이는 12바이트입니다.

오프셋 옥텟 0 1
옥텟 조금 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 0 송신원포트
2 16 수신처 포트
4 32 데이터 오프셋 CCVal CsCov
6 48 체크섬
8 64 리즈 유형 X=0 시퀀스 번호(높음)
10 80 시퀀스 번호(저비트)
송신원포트(16비트)
송신측 포토를 식별합니다.
수신처 포트(16비트)
수신 포트를 식별합니다.
데이터 오프셋
(8비트):패킷의 DCCP 헤더의 시작에서 애플리케이션 데이터 영역의 시작까지의 오프셋(32비트).
CCVal(4비트)
HC-Sender CCID에서 사용
체크섬 커버리지(CsCov)(4비트)
Checksum Coverage는 Checksum 필드에서 커버되는 패킷 부분을 결정합니다.
체크섬(16비트)
패킷의 DCCP 헤더(옵션 포함), 네트워크 레이어 의사 헤더 및 체크섬 커버리지에 따라 응용 프로그램 데이터의 전부 또는 없음
예약 완료(Res)(3비트)
송신자는 생성된 패킷에 대해 이 필드를 모두 0으로 설정해야 하며 수신자는 이 값을 무시해야 합니다.
유형(4비트)
[Type] 필드는 패킷의 유형을 지정합니다.
확장 시퀀스 번호(X)(1비트)
48비트 시퀀스 번호 및 확인 응답 번호를 가진 확장 범용 헤더의 사용을 나타내려면 1로 설정합니다.
시퀀스 번호(48비트 또는 24비트)
이 접속으로 송신원이 송신한 모든 패킷의 순서로 패킷을 일의로 식별합니다.

현재의 개발

멀티패스 기능에 의한 TCP 프로토콜의 확장(MPTCP)과 마찬가지로 멀티패스 기능은 MP-DCCP로 대응하는 IETF에서[5] 논의되고 있습니다.첫 번째 구현은 운영자와 학계 간의 협업 접근 방식으로 이미 개발, 테스트 및 제시되었으며 오픈 소스 솔루션으로 사용할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ RFC 4340 섹션 7.6
  2. ^ "[dccp] FreeBSD implementation". www.ietf.org. Retrieved 18 April 2018.
  3. ^ "Linux gets DCCP [LWN.net]". lwn.net. Retrieved 18 April 2018.
  4. ^ dccp-tp wiki 변경 로그(2011년 6월 13일 취득)
  5. ^ Amend, Markus; Brunstrom, Anna; Kassler, Aneas; Rakocevic, Veselin; Johnson, Stephen (9 November 2021). "DCCP Extensions for Multipath Operation with Multiple Addresses".
  6. ^ "Multipath extension for DCCP".

외부 링크

프로토콜 사양

  • RFC 4340 - 데이터그램 폭주 제어 프로토콜
  • RFC 5595: Datagram Congestion Control Protocol(DCCP) 서비스 코드
  • RFC 5596 - NAT/미들박스 트래버설을 용이하게 하기 위한 DCCP 동시 오픈 기술
  • RFC 5762 - RTP 및 DCCP
  • RFC 5238 - DCCP를 통한 데이터그램 트랜스포트층 보안(DTLS)
  • RFC 5634 - DCCP의 Quick-Start
  • RFC 6773: NAT 트래버설을 위한 Datagram congestion 제어 프로토콜 UDP 캡슐화

폭주 제어 ID

  • RFC 4341: DCCP 폭주 제어 ID 2: TCP 유사 폭주 제어 프로파일
  • RFC 4342: DCCP 폭주 제어 ID 3: TCP 친화적 환율 제어(TFRC) 프로파일
  • RFC 5622: DCCP 폭주 제어 ID 4: TCP 친화적 스몰패킷 레이트 제어(TFRC-SP) 프로파일

다른 정보