Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340 - презентация, доклад, проект скачать

Нажмите для полного просмотра!

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №1

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №2

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №3

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №4

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №5

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №6

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №7

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №8

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №9

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №10

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №11

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №12

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №13

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №14

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №15

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №16

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340, слайд №17

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340. Доклад-сообщение содержит 17 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340)

Слайд 2

Описание слайда:

До настоящего времени приложения использовали либо TCP, чья надежность и гарантия упорядочения доставки давалась за счет неопределенно большой задержки, или UDP и независимого механизма управления перегрузкой (или вообще с отсутствием подавления перегрузки). Протокол DCCP будет предоставлять стандартный способ управления перегрузкой и позволит использовать механизм ECN (Explicit Congestion Notification) Протокол DCCP предназначен для приложений, которые не требуют параметров SCTP [Stream Control Transmission Protocol, RFC 2960], таких как упорядоченная доставка при нескольких потоках. Протокол DCCP обеспечивает надежное согласование параметров при установлении соединения. В DCCP было решено не использовать менеджер управления перегрузкой [RFC 3124], который допускает несколько одновременных потоков между отправителем и получателем.

Слайд 3

Описание слайда:

Протокол DCCP предназначен для приложений, которые реализуют поточную схему TCP, но имеют приоритет для своевременной доставки данных с сохранением порядка кадров или требуют надежности, или которым нужен механизм подавления перегрузки, отличный от TCP До настоящего времени такие приложения использовали либо TCP, чья надежность и гарантия упорядочения доставки давалась за счет неопределенно большой задержки, или UDP и независимого механизма управления перегрузкой (или вообще с отсутствием подавления перегрузки).

Слайд 4

Описание слайда:

Одной из целей DCCP было максимальное облегчение для UDP приложений перехода на DCCP, когда он будет внедрен.

Слайд 5

Описание слайда:

Протокол DCCP имеет следующие характеристики: Реализует поток дейтограмм с подтверждением получения, но без повторной посылки. Ненадежный диалог установления и разрыва соединения. Надежное согласование параметров. Выбор механизмов подавления перегрузки, дружественных по отношению к TCP, включая TCP-подобное управление перегрузкой (CCID 2) и управление потоком, дружественное TCP [RFC 3448] (CCID 3). CCID 2 использует разновидность TCP-механизма управления перегрузкой, и приемлемо для потоков, которые стремятся воспользоваться преимуществами доступной полосы, CCID 3 пригодно для потоков, которые требуют более стабильной скорости передачи.

Слайд 6

Описание слайда:

Опции, которые говорят отправителю с высокой надежностью, какие пакеты достигли получателя, были ли эти пакеты помечены ECN [RFC 3168 и RFC 3540], повреждены, или отброшены во входном буфере получателя. Управление перегрузкой, снабженное встроенной индикацией явной перегрузки ECN (Explicit Congestion Notification). Механизмы, позволяющие серверу избежать поддержки состояний неподтвержденных попыток соединений. Выявление MTU пути [RFC 1191].

Слайд 7

Описание слайда:

Отличия DCCP от TCP Поток пакетов. DCCP является протоколом для потоков пакетов, а не потоков байт. Ненадежность. DCCP никогда не пересылает дейтограммы повторно. Порядковые номера пакетов. Порядковые номера относятся к пакетам, а не байтам. Каждому пакету, посылаемому DCCP, присваивается новый порядковый номер, это относится и к пакетам подтверждений. Это позволяет получателю пакетов DCCP детектировать потери подтверждений; смотри раздел “Sequence Number Validity” в [DCCP]. Обширное пространство для опций (до 1020 байт). Согласование параметров. Это является базовым механизмом, с помощью которого партнеры согласуют значения параметров или свойства соединения.

Слайд 8

Описание слайда:

Выбор управления перегрузкой. Партнеры могут использовать разные механизмы управления перегрузкой. В соединении AB, информационные пакеты, посланные от A->B могут использовать алгоритм CCID 2, а пакеты данных от B->A могут использовать CCID 3. Различные форматы подтверждений. CCID-соединения определяет то, какой объем данных должен быть передан в ack. В CCID 2 (TCP-подобном), посылается один ack на 2 пакета, а каждый ack должен оповещать, какие конкретно пакеты получены (опция Ack Vector); в CCID 3 (TFRC), посылается в среднем один ack за время RTT, а ack должны сообщать как минимум о длинах последних интервалов потерь. Отсутствие приемного окна. DCCP является протоколом управления перегрузкой, а не протоколом управления потоками. Разделение различных видов потерь. Опция потерянных данных (Data Dropped) позволяет одному из партнеров сообщить, что пакет был потерян из-за повреждения, переполнения входного буфера и т.д..

Слайд 9

Описание слайда:

Определение подтверждения. В TCP получение пакетов подтверждается, только когда они ставятся в очередь для передачи приложению. В протоколе DCCP это делается не так. Получение пакета подтверждается, когда обработаны поля его опций. Встроенная поддержка мобильности.

Слайд 10

Описание слайда:

Заголовок DCCP

Слайд 11

Описание слайда:

Базовый заголовок пакетов DCCP при Х=0

Слайд 12

Описание слайда:

Формат подзаголовка номера подтверждения

Слайд 13

Описание слайда:

Формат пакета DCCP-запроса

Слайд 14

Описание слайда:

Формат пакета DCCP-отклика

Слайд 15

Описание слайда:

Формат пакета DCCP-Data

Слайд 16

Описание слайда:

TFRC Протокол TFRC (TCP Friendly Rate Control; RFC-3448, -4342, -4828) предоставляет механизм управления перегрузкой для уникастных потоков в Интернет. Реализованный способ управления перегрузкой может быть использован, например, в транспортном протоколе RTP, в приложении с контролем перегрузки в виртуальном канале точка-точка. RFC-3448, -4342, -4828.