LXF86:DCCP
|
|
|
Что за штука.... DCCP?
- Хорошие новости для тех, кто скачивает много информации, а также пользователей VoIP: Дэвид Кулсон расскажет о технологии, помогающей интернет-пакетам дойти до получателя.
- Хм, DCCP. Похоже на DCC из IRC. Это для обмена файлами?
На самом деле, из общего у DCC [Direct Client-Client, Прямое соединение клиент-клиент] и DCCP [Datagtam Congestion Control Protocol, Протокол управления прохождением датаграмм] только буквы D и С в названиях. DCCP – совсем другой зверь, он помогает приложениям, занимающимся рассылкой файлов, а не их обменом.
- Вы сказали «прохождение» – что, DCCP ускоряет Интернет?
Нет, но увеличивает надежность доставки данных. Сегодня большая часть интернет-трафика лежит на плечах TCP или UDP. TCP используется для долговременных соединений типа SSH, HTTP и FTP, которым присущи регулирование нагрузки и гарантия доставки данных (как часть протокола). UDP используется, в основном, для протоколов с коротким временем работы, включая DNS. А поскольку UDP – это протокол, не сильно озабоченный вопросом потери пакетов, он применятся для вещания аудио и видео, включая VoIP.
- Значит, UDP быстрее, чем TCP, но не гарантирует надежности передачи?
По-простому, да. Есть сервисы, требующие данные сразу же, причем данные должны быть свободны от ошибок. Однако ошибки бывают всегда, и DCCP призван добавить в UDP устойчивость к сбоям протокола TCP, без необходимости переписывать приложения, чтобы учесть новую специфику доставки данных.
- DCCP – отличная идея. Почему его не используют вместо TCP и UDP?
TCP и UDP появились раньше, чем сам Интернет, и для практических целей они будут работать еще долго. TCP идеально подходит для основательной и надежной передачи данных, прямо как во время сессии Telnet, когда код нажатой клавиши гарантировано передается через сеть. UDP, напротив, полезен как протокол типа «послал и забыл».
- Это не здорово.
Смотрите: когда мы делаем запрос DNS, то посылаем запрос на удаленный сервер и какое-то время ждем. Если ответ не получен, мы просто работаем дальше, а если получен несколькими секундами позже, мы его игнорируем – отсюда и название «послал и забыл». Использование протокола TCP для такого типа запросов неэффективно, так как перед передачей данных требуется всякий раз устанавливать соединение.
DCCP явно станет штатным протоколом вместо UDP, например, в RTP, где возможность реакции на потерю или затор пакетов, увеличивающий латентность, увеличит надежность протокола в целом.
- Латентность...?
Задержка передачи пакета данных.
- А, да. Как все сложно…
Вовсе нет.
- Так как же DCCP улучшит UDP?
Сессия UDP не имеет состояний. Клиент посылает пакет серверу, а сервер посылает пакет обратно. Не выполняется ни инициализация соединения, ни его завершение после передачи данных. В отличие от UDP, DCCP создает соединения – точнее, «полу-соединения» (half-connections), которые можно рассматривать как ненадежные однонаправленные каналы (pipes). Посылка данных по такому соединению похожа на посылку писем – нет гарантии, что они дойдут до адресата, а если и дойдут, то вряд ли будут получены в том же порядке, в каком отправлялись. Многие протоколы на основе DCCP будут использовать пару односторонних соединений для передачи данных между узлами сети, а заодно передавать подтверждения получения пакетов.
- Именно этого UDP не делает.
Верно. Как TCP, DCCP позволит клиенту повторять посылку пакетов, если сервер не подтвердил их получение. Один из результатов такого подхода – возможность ограничивать темп передачи данных и поднимать реальную скорость передачи до такой, которую позволяет пропускная способность, и при этом не терять пакеты.
- Почему посылка большого объема данных вызовет потерю пакетов?
Любой канал в Интернете имеет определенную ширину, и данные передаются надежно, только если их объем не превышает ширины канала. Когда канал загружен максимально, передадутся не все данные. Интернет-устройства, включая обычные персональные компьютеры, способны ставить данные в очередь, и если пропускной способности канала недостаточно для немедленной отсылки, то устройства подождут, а потом отошлют данные в том порядке, в котором они помещались в буфер. Но если и буфер полон, и канал полностью загружен, то пакеты будут теряться.
- Теперь понимаю.
TCP – довольно умный протокол, и когда сталкивается с подобной ситуацией, то просто уменьшает скорость передачи данных, чтобы гарантировать доставку пакетов.
- А как DCCP ограничивает трафик?
DCCP отличается от TCP тем, что управление нагрузкой инициируется из процесса, находящегося в пространстве пользователя, который и создал одностороннее соединение, а не находится «под колпаком» у ядра. На текущий момент существует два профиля для управления нагрузкой, известные как CCID2 и CCID3. CCID2 похож на TCP, он тоже быстро реагирует на флуктуации трафика в Интернете, позволяет соединению использовать всю доступную полосу пропускания и препятствует потере пакетов. CCID3 пытается поддерживать определенный уровень передачи данных и избегает быстрой адаптации, используя процесс, известный как дружественное к TCP управление скоростью, или TFRC.
- Какие интернет-сервисы будут использовать CCID2 или CCID3?
CCID2 подходит тем приложениям, где поток передаваемых данных не постоянен, например, интернетиграм или в качестве замены традиционного UDP,и позволяет устранить задержку, ускоряя доставку пакетов. CCID3 идеален для приложений, посылаю щих данные равномерно, например, VoIP или других медиа-потоков, потому что таким приложениям важнее поддерживать постоянное прохождение данных между узлами, чем максимально использовать полосу пропускания канала.
- Как убедить приложения перейти с UDP на DCCP?
Для конкретного приложения мгновенной выгоды может и не быть. Но протоколы используют пропускную способность канала все больше, и интернет-провайдерам придется задуматься над выбором между протоколами, сжирающими ресурсы каналов, и протоколами, помогающими уменьшить нагрузку. Многие провайдеры уже ограничивают использование протоколов на базе UDP, часто применяемых для совершения DoS-атак (Denial of Service, способ вывести сервер из строя, забросав его неподъемным количеством запросов) или других потенциально вредоносных процессов; в результате, страдают VoIP и другие современные медиа-технологии.
- UDP может вызвать DoS-атаки?
Именно что может. Из-за того, что не инициируется соединение, система может послать UDP пакет на удаленный узел с подставным адресом отправителя, а сервер отошлет пакет на подставной адрес отправителя в качестве ответа. Таким образом можно предпринять довольно эффективную распределенную DoS-атаку, особенно если сервер генерирует ответный пакет большего размера по сравнению с полученным запросом.
- Есть ли поддержка DCCP в Linux?
Начиная с Linux 2.6.14, поддержка DCCP включена в основное дерево исходного кода ядра. Как обычно, потребуется некоторое время, прежде чем производители популярных дистрибутивов включат в свои продукты необходимые патчи для других компонентов, включая Netfilter, для полной поддержки DCCP.
- И как вы думаете, когда приложения начнут поддерживать DCCP?
Уже доступно некоторое число тестовых приложений для оценки DCCP-протокола в Интернете и внутри локальной сети. Документация по DCCP находится на http://linux-net.osdl.org/index.php/DCCP. Ruby и Python поддерживают DCCP, библиотеки Perl уже могут использовать возможности DCCP, так что почти любая программа, скрипт или приложение могут использовать новый протокол.
Поддержка DCCP сейчас включается в репозитории Tcpdump и Etherape, что обеспечивает поддержку всех текущих IP-протоколов, которые используются в Интернете. Очевидно, необходимость в этом есть, так как для адекватного использования нового протокола необходимы инструменты для поиска неисправностей и отладки.
- Спасибо, вы меня очень просветили. А не посоветуете ли какой-нибудь сайт?
Не за что. Подробности вы получите на http://www.read.cs.ucla.edu/dccp. LXF
