CoDel ( контролируемая задержка ; произносится « няня ») — алгоритм активного управления очередью (AQM) в сетевой маршрутизации , разработанный Ван Джейкобсоном и Кэтлин Николс и опубликованный как RFC8289. [1] Он предназначен для преодоления раздувания буфера в сетевом оборудовании , таком как маршрутизаторы , путем установки ограничений на задержку сетевых пакетов при их прохождении через буферы в этом оборудовании. CoDel стремится улучшить общую производительность алгоритма случайного раннего обнаружения (RED) за счет устранения некоторых его фундаментальных заблуждений, как считает Джейкобсон, и за счет упрощения управления.
В 2012 году Дэйв Тяхт и Эрик Дюмазет написали реализацию CoDel для ядра Linux и получили двойную лицензию: GNU General Public License и трехпунктовую лицензию BSD . Улучшение CoDel от Dumazet называется FQ-CoDel , что означает «Fair/Flow Queue CoDel»; Впервые он был принят в качестве стандартного решения AQM и планирования пакетов в 2014 году в выпуске OpenWrt 14.07 под названием «Barrier Breaker». Оттуда CoDel и FQ-CoDel мигрировали в различные последующие проекты, такие как Tomato , dd-wrt , OPNsense и функцию «Smart Queues»Ubiquiti .
CoDel основан на наблюдениях за поведением пакетов в сетях с коммутацией пакетов под воздействием буферов данных . Некоторые из этих наблюдений касаются фундаментальной природы организации очередей и причин раздувания буфера , другие относятся к слабостям альтернативных алгоритмов управления очередями. CoDel был разработан как попытка решить проблему раздувания буфера. [2]
Поток пакетов замедляется при прохождении через сетевое соединение между быстрой и медленной сетью, особенно в начале сеанса TCP , когда происходит внезапный всплеск пакетов и более медленная сеть может быть не в состоянии быстро принять этот пакет. достаточно. Существуют буферы, которые облегчают эту проблему, предоставляя быстрой сети место для хранения пакетов, которые будут читаться более медленной сетью в своем собственном темпе. [3] Другими словами, буферы действуют как амортизаторы, преобразуя скачкообразные поступления в плавные, устойчивые отклонения. Однако буфер имеет ограниченную емкость. Идеальный буфер имеет такой размер, чтобы он мог справиться с внезапным всплеском данных и сопоставить скорость этого всплеска со скоростью более медленной сети. В идеале амортизирующая ситуация характеризуется временной задержкой пакетов в буфере во время пакета передачи, после чего задержка быстро исчезает и сеть достигает баланса в предложении и обработке пакетов. [3]
Алгоритм управления перегрузкой TCP основан на отбрасывании пакетов для определения доступной пропускной способности между двумя взаимодействующими устройствами. Он ускоряет передачу данных до тех пор, пока пакеты не начнут теряться, а затем замедляет скорость передачи. В идеале он продолжает ускоряться и замедляться, пока находит равновесие на скорости соединения. Чтобы это работало, отбрасывание пакетов должно происходить своевременно, чтобы алгоритм мог оперативно выбрать подходящую скорость передачи. Пакеты, хранящиеся в слишком большом буфере, дойдут до пункта назначения, но с более высокой задержкой , но пакеты не будут отброшены, поэтому TCP не замедлится. В этих условиях TCP может даже решить, что путь соединения изменился, и повторить поиск нового равновесия. [4] [5]
Наличие большого и постоянно полного буфера, который приводит к увеличению задержек передачи и снижению интерактивности, особенно при просмотре двух или более одновременных передач по одному и тому же каналу, называется раздуванием буфера. Доступная полоса пропускания канала также может оказаться неиспользованной, поскольку некоторые быстрые пункты назначения могут быть недоступны из-за того, что буферы забиты данными, ожидающими доставки в медленные пункты назначения.