Кратко

  • В ограниченной UDP-топологии RFC 5390 один клиентский запрос мог привести максимум к восемнадцати запросам и восемнадцати ответам из-за трёх перегруженных серверов, переключения прокси и повторных передач транзакций.
  • Базовый 503 не устанавливал однозначно перегруженный ресурс, допустимый остаток нагрузки и область действия для IP-адреса, хоста или URI. Поэтому он мог повторять работу, отключать здоровые узлы или раскачивать поток.
  • Последующие документы разделили мониторинг, управляющее решение, обратную связь и исполнительный механизм выше по потоку. Полученный сигнал не доказывает установленное ограничение, а ограничение не доказывает завершённый вызов.

Повторение началось не после отказа, а во время него

RFC 3261 предлагал разумное поведение для локальной неисправности. Сервер мог ответить 503 при временной недоступности, при необходимости указать Retry-After, а прокси — выбрать другой адрес. Если первая машина потеряла способность обслуживать трафик, а вторая располагала независимым запасом, такой переход сохранял работу.

RFC 5390 намеренно рассматривал другую реальность. S1, S2 и S3 уже находились в перегрузке. Балансирующий прокси отправлял запрос первому, после 503 переходил ко второму, затем к третьему. Каждому узлу приходилось принять пакет, разобрать его, поставить в планирование и сформировать отказ, хотя полезную транзакцию он завершить не мог.

При этом отказ не появлялся мгновенно. Пока исчерпавший ресурс сервер пытался ответить, клиентская SIP-транзакция по UDP могла повторно передавать запрос. В расчёте RFC участвовали четыре транзакции, включая участок клиент–прокси, и до семи повторов каждой UDP-транзакции до тайм-аута. При этих предпосылках исходный запрос создавал максимум восемнадцать запросов и восемнадцать ответов.

Число восемнадцать не описывает типичную производственную сеть и не является универсальным коэффициентом SIP. Оно относится к трём серверам, UDP, заданным таймерам, повторным попыткам и окончанию ожидания. Его нельзя отделять от условий. Но оно точно показывает, что цена отказа включает работу, возникшую до его доставки и после вызванного им переключения.

Надёжный транспорт убрал копии, но не убрал неверное решение

TCP менял масштаб, а не причинную структуру. В том же примере, без повторной передачи TCP-сегментов, единичный запрос всё равно создавал три запроса вниз по потоку и четыре ответа. Прокси по-прежнему переходил между адресами, не зная, что все они разделяют одну и ту же нехватку.

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

Нужна цепочка происхождения: исходный идентификатор, каждая повторная передача, выбранная ветвь, время ответа и окончательный исход. Только она позволяет отличить новый спрос от повторно оплаченной старой работы.

Та же граница действует для показателя ответов. Быстро выдать 503 — не то же самое, что восстановить способность. Система может стать эффективнее в производстве отрицательных ответов и хуже в полезных транзакциях. Зелёный индикатор «сервер отвечает» не сообщает, что он выполняет нужную работу.

Вторая ветвь прокси снова обошла те же три машины

RFC 5390 добавил прокси более высокого уровня. P1 уже посетил S1, S2 и S3 и узнал, что нижняя группа перегружена. Однако это знание не вернулось вверх как управляющее состояние с областью зависимости. Верхний узел попробовал P2, и P2 исследовал те же S1, S2 и S3 заново.

На схеме появлялась ещё одна ветвь. В наборе ресурсов ничего не прибавлялось. Ответ P1 мог описывать состояние самого P1 или общих серверов позади P1 и P2. Верхний прокси не мог восстановить происхождение причины. А запрет передавать 503 вверх, призванный избежать неверной атрибуции, лишал следующую ветвь сведений, необходимых для остановки повтора.

Резервирование нельзя измерять количеством меток. Два фронтенда с одной упавшей базой данных составляют одну область отказа для зависимой операции. Два маршрута, сходящиеся на одном исчерпанном PSTN-шлюзе, также не дают двух независимых возможностей.

Каждая повторная попытка должна отвечать на проверяемый вопрос: какой новый независимый ресурс она добавляет? Если ответа нет, полный обход списка свидетельствует о выполнении алгоритма, а не о разумном восстановлении.

Один 503 мог остановить исправных соседей

Неопределённая область действия приводила и к противоположной ошибке. RFC 5390 отметил, что RFC 3261 недостаточно ясно различал применение 503 к IP-адресу, имени хоста или URI. Некоторые реализации выбирали имя хоста. Если DNS SRV раскрывал это имя в кластер, отказ одного участника мог исключить весь набор.

Тогда нагрузка не умножалась на неисправных целях, а доступная мощность оставалась без работы. Узкое наблюдение становилось широким запретом. Обход общей неисправности и отключение здорового кластера выглядят противоположно, но возникают из одной потери: принимающая сторона не знает точный объект сигнала.

REQ 18 потребовал однозначно указывать, относится ли перегрузка к IP, хосту или URI. Область действия — это предел делегированного решения. Сервер вправе сообщить о собственном процессоре. Один код не даёт ему права устанавливать состояние всех соседей, общей базы или имени службы.

Управляющий журнал должен сохранять объект наблюдения, время, длительность, получившего сигнал соседа и фактический набор, который исполнитель ограничил. Итоговое число 503 не позволяет позже выяснить, защищался ли больной узел или простаивала здоровая ёмкость.

Двоичный таймер перемещал перегрузку туда и обратно

Retry-After давал серверу время разгрузить очередь, но базовое действие было двоичным. В примере RFC 5390 два сервера работали на пределе. Когда S1 просил паузу, прокси переносил весь поток на S2. Тот получал примерно двойную нагрузку, выдавал собственный отказ, а после окончания первого таймера трафик возвращался на S1.

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

Документ ограничивает этот пример. При большом числе независимых клиентов, каждый из которых посылает малую долю общего потока, выборочный 503 некоторым источникам может приблизить плавное уменьшение. Поэтому Retry-After не обязан колебаться в любой архитектуре. Но базовый механизм не гарантировал устойчивое ступенчатое управление в нужных RFC 5390 топологиях.

REQ 7 потребовал учитывать степень перегрузки. REQ 21 потребовал, чтобы производительность стабилизировалась, когда предложение возвращается ниже мощности. Это требования к замкнутому контуру во времени, а не к формату сообщения об ошибке.

Одинаковый ответ мог требовать противоположной реакции

503 применяли и к причинам, не связанным с исчерпанием SIP-процессора. У шлюза могла оставаться сигнальная мощность, но отсутствовать нужная PSTN-линия. Фронтенды могли быть работоспособны, а общая база данных — недоступна. В первом случае иной маршрут способен помочь; во втором другой фронтенд приведёт к той же неисправности.

Видимый символ одинаков, а причинные миры различны. Повторение может спасти запрос или умножить бесполезную работу. Остановка может защитить систему или отбросить здоровую альтернативу. Поэтому REQ 6 потребовал явного признака именно перегрузки, а не другого сбоя. REQ 8 и REQ 9 удержали обе стороны: не посылать в известную или неизвестную перегрузку и не лишать работы заведомо здоровую цель.

REQ 14 добавил ясные инструкции о повторе, особенно для установления соединений и регистрации после перезапуска. Причина, область, величина и срок — разные поля. Если общий код заменяет их все, принимающая сторона вынуждена придумывать отсутствующую политику.

Минимальная общая спецификация не должна управлять всей эксплуатацией. Её задача — передать узкий совместимый факт. Нижний узел сообщает локальное состояние; верхний сохраняет полномочие и ответственность за свой исходящий поток. Совместимость не отменяет эту границу власти.

Последующие RFC разделили четыре звена управления

RFC 6357 явно выделил защищаемый SIP-процессор, monitor, control function, feedback и actuator на стороне отправителя. Монитор измеряет. Управляющая функция формирует обратную связь. Исполнитель выше по потоку уменьшает, задерживает, отклоняет или перенаправляет лишнюю работу до того, как она достигнет редкого ресурса.

Разделение делает неисправности наблюдаемыми. Измерение может быть верным, а обратная связь — устаревшей. Сигнал может прийти, но исполнитель не установит ограничение. Он может выполнить общий лимит, выбрав для отбрасывания неверные классы. Предложение может снизиться, а полезная производительность не вернуться из-за скрытой зависимости.

RFC 6357 также объяснил, почему локального отказа недостаточно: само отклонение расходует ресурсы сервера. Оно остаётся последним рубежом, но не предотвращает congestion collapse без более раннего действия. Избыточную работу нужно останавливать прежде, чем узкое место заплатит за её разбор и отказ.

RFC 7339 позднее передавал перегрузочные сведения hop-by-hop в верхнем Via. Поскольку этот Via потребляет соседний клиент, информация относилась к одной соседской связи. oc задавал снижение в базовой loss-based схеме, oc-validity — срок, oc-seq — порядок, oc-algo — класс алгоритма. Публикация полей не доказывала исполнение и не означала защиты всей цепочки вызова.

Процент потерь и предел скорости задавали разные обязательства

RFC 7339 требовал поддержку loss-based алгоритма. Сервер мог попросить верхнего клиента сократить долю пересылаемых запросов. Такой контракт относительно лёгок, но абсолютный пропущенный объём зависит от предложения: при росте входа разрешённая доля тоже может дать больше сообщений.

RFC 7415 добавил необязательный rate-based вариант. Сервер сообщал клиенту максимальную скорость запросов, постоянную до следующего обновления. Между обновлениями появлялась верхняя граница, но требовалось больше состояния и контроля на каждого источника.

Ни одно число не было обещанием результата. Максимум 150 запросов в секунду не гарантирует 150 завершённых транзакций и тем более 150 успешных вызовов. Типы сообщений стоят по-разному, а верхний узел локально выбирает, какие из них займут квоту.

Цепочка квитанций поэтому разделяет полученное значение, последовательность и срок, установленный лимит, предложение, пересылку, выбранные классы, завершённые транзакции и пользовательский исход. Можно точно выполнить скорость, защитить CPU и при этом отбрасывать BYE, которые освободили бы особенно много состояния.

Полезная производительность строже количества ответов

Первое требование RFC 5390 направлено на useful throughput, когда предложенная нагрузка намного выше мощности. Оно не оптимизирует число ответов. Система способна быстро отвергнуть каждую заявку и при этом не вернуть пользователям ни одного результата.

Полезная производительность соединяет допуск, завершение и освобождение состояния. BYE существующего диалога способен вернуть ресурсы, новый INVITE — занять их. Обновление регистрации имеет другую цену и последствие. Сырая сумма сообщений не выражает этих различий.

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

В терминах слоёв реальности Lu Heng стандартное поле, реальное состояние процессора, действие прокси и исход для человека — разные факты. Только running code превращает возможность спецификации в работающий контроль. Согласованный Via-параметр не создаёт CPU, не разделяет общую базу и не переносит ответственность за ошибочный приоритет.

Граница доказательств

Замороженный набор подтверждает текст и Informational-статус RFC 5390, описанные там проблемы развёртывания и последующую архитектуру RFC 6357, RFC 7339 и RFC 7415. Он не подтверждает современное внедрение конкретным оператором, поставщиком или продуктом и не связывает реальную аварию с моделью восемнадцати запросов.

Число восемнадцать остаётся привязанным к трём серверам, UDP-транзакциям, повторам и тайм-ауту. Пример колебания двух серверов относится к небольшому числу крупных источников, а не ко всякому распределению. Отдельный производственный 503 тоже не устанавливает причину перегрузки.

Переносимая граница уже: отказ не равен снижению. Достоверное утверждение об управлении должно показать измеренный ресурс, причинную область, действующую обратную связь, действие отправителя, локальный выбор и полезный результат. Без каждого звена доказана только корректная ошибка, но не восстановление.