В компьютерных сетях, Протокол управления перегрузкой дейтаграмм (DCCP ) - это ориентированный на сообщения протокол транспортного уровня . DCCP реализует надежную установку соединения, разрыв, явное уведомление о перегрузке (ECN), контроль перегрузки и согласование функций. IETF опубликовал DCCP как RFC 4340, предлагаемый стандарт, в марте 2006 г. RFC 4336 представляет собой введение.
DCCP предоставляет способ получить доступ к механизмам управления перегрузкой без необходимости их реализации на прикладном уровне. Он позволяет использовать семантику на основе потоков, как в Протокол управления передачей (TCP), но не обеспечивает надежную доставку по порядку. Последовательная доставка в нескольких потоках, как в Протокол передачи управления потоком (SCTP), недоступна в DCCP. Соединение DCCP содержит трафик подтверждения, а также трафик данных. Подтверждения информируют отправителя о том, прибыли ли его пакеты и помечены ли они явным уведомлением о перегрузке (ECN). Подтверждения передаются настолько надежно, насколько этого требует используемый механизм управления перегрузкой, возможно, полностью надежно.
DCCP полезен для приложений с ограничениями по времени доставки данных. К таким приложениям относятся потоковое мультимедиа, многопользовательские онлайн-игры и Интернет-телефония. В таких приложениях старые сообщения быстро становятся бесполезными, поэтому получение новых сообщений предпочтительнее повторной отправки потерянных сообщений. По состоянию на 2017 год такие приложения часто либо соглашались на TCP, либо использовали протокол дейтаграмм пользователя (UDP) и реализовывали свои собственные механизмы контроля перегрузки, либо вообще не имели контроля перегрузки. Будучи полезным для этих приложений, DCCP может также служить в качестве общего механизма управления перегрузкой для приложений на основе UDP, добавляя, при необходимости, механизмы для надежной или упорядоченной доставки поверх UDP / DCCP. В этом контексте DCCP позволяет использовать различные, но обычно дружественные к TCP механизмы контроля перегрузки.
DCCP имеет возможность использовать очень длинные (48-битные) порядковые номера, соответствующие идентификатору пакета, а не байтовому идентификатору, как в TCP. Большая длина порядковых номеров предназначена для защиты от «некоторых слепых атак, таких как внедрение DCCP-Reset в соединение».
Следующие операционные системы реализуют DCCP:
Библиотека пользовательского пространства:
Общий заголовок DCCP принимает разные формы в зависимости от значения X, бита расширенных порядковых номеров. Если X равен единице, поле порядкового номера имеет длину 48 бит, а общий заголовок занимает 16 байтов, как показано ниже.
Смещения | Октет | 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 | Res | Тип | X = 1 | Зарезервировано | ||||||||||||
10 | 80 | Порядковый номер (старшие биты) | |||||||||||||||
12 | 96 | Порядковый номер | |||||||||||||||
14 | 112 | Порядковый номер (младшие биты) |
Если X равен нулю, передаются только младшие 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 | Res | Тип | X = 0 | Порядковый номер (старший) | ||||||||||||
10 | 80 | Порядковый номер (младшие биты) |