Summary

  • RFC 5238 рекомендует не повторять запрос, который DCCP поставил в очередь, но ещё не передал. Если событие доступно, таймер DTLS следует запускать при передаче сообщения от DCCP к IP.
  • Приём в очередь, нижняя передача, отправка, получение, завершение DCCP, продвижение DTLS и готовность приложения — разные факты.

Потеря, которой ещё не было в сети

DTLS отдаёт запись; DCCP принимает её, но контроль перегрузки задерживает выпуск. Если верхние часы пошли при приёме, срок включает локальное ожидание и сетевой путь. Истечение выглядит как потеря запроса, который мог не покинуть узел.

Копия попадает в ту же очередь и отнимает возможность у оригинала. Ожидание оправдывает повтор, а повтор увеличивает ожидание.

RFC 5238 предлагает точную границу: когда интерфейс сообщает событие, DTLS ждёт передачи от DCCP к IP и только затем начинает отсчёт.

Две надёжные процедуры не образуют одну гарантию

DCCP и DTLS имеют собственные рукопожатия. Записи DTLS можно включать в DCCP-Request и Response, частично совмещая процедуры.

Но надёжность рукопожатия DCCP не гарантирует встроенные Application Data. Сервер вправе их отбросить, а повтор DCCP — не включить. Поэтому DTLS сохраняет собственное восстановление.

Встроенную запись нельзя снова отправить как обычные данные до завершения DCCP. Стандарт требует от верхнего таймера ждать этой границы, чтобы не накопить копии, которые всё равно не могут выйти.

Похожие часы усиливают друг друга

Оба уровня используют сроки и отступление, но защищают разные объекты. Тайм-аут DCCP не доказывает потерю записи DTLS, а молчание DTLS не локализует сетевую потерю.

Крупное рукопожатие может быть ограничено DCCP до срабатывания верхнего повтора. Новый трафик усугубляет задержку. Восстановление после подтверждённого выпуска отличается от спекулятивной копии, пока оригинал ждёт.

Последовательности не делятся полномочиями

RFC 5238 прямо отделяет номер пакета DCCP от номера записи DTLS, а синхронизацию DCCP — от защиты DTLS от повторов. Общее вложение не создаёт общей семантики.

Запись DTLS также должна целиком помещаться в один пакет DCCP и не превышать текущий максимум, который может меняться с состоянием перегрузки.

Рукопожатие оставляет состояние

Начальный обмен может оставить контроллер неподходящим для приложения. При CCID 2 большой обмен способен вызвать мультипликативное снижение, после которого поток ждёт аддитивного восстановления. RFC предлагает рассмотреть CCID 3 для более плавного изменения, но не объявляет универсального победителя.

Установленная защита и готовая пропускная способность — разные заключения.

Границы источников

Нет доказательств современного продукта, внедрения, трассы, сбоя, измерения или распространённости. IANA подтверждает регистрацию параметров, а новые RFC DTLS — развитие стандарта, не использование поверх DCCP.

Передача IP не доказывает физическую отправку, получение или готовую сессию. Это лишь более честная точка старта, чем локальный приём.

Каждому таймеру — событие и владелец

Храните подачу, очередь, решение о перегрузке, передачу IP, идентичность последовательности, наблюдаемую отправку, ответ, состояние DCCP, полёт DTLS и допуск приложения. Назначьте владельца начала, паузы и отмены каждого срока.

Подавляйте верхние копии, пока оригинал числится ожидающим. Сохраняйте поздние ответы и отмены вместо записи их как сетевых потерь.

Приоритет рабочей реальности Lu Heng здесь буквальный: приём работы API не является исполнением. Владелец таймера отвечает за границу, потому что часы создают трафик.

Sources

Дополнительный нормативный архив

  1. Текст RFC 5238
  2. Информация RFC 5238
  3. RFC 5238 в Datatracker
  4. История RFC 5238
  5. Исправления RFC 5238
  6. Ссылки на RFC 5238