Кратко

  • RFC 792 назначил ICMP тип 4 шлюзам и получателям, которые больше не могли принимать трафик. Сообщение цитировало вызвавший его пакет и просило источник снизить скорость к назначению.
  • Приказ не удостоверял говорящего и не сообщал размер очереди, справедливую скорость или срок. Управляющие пакеты тратили ёмкость при перегрузке, а подделка могла снизить чужую пропускную способность.
  • Устойчивое управление перешло в сквозное состояние транспорта, затем ECN поместил явный сигнал в сам пакет. RFC 6633 потребовал игнорировать Source Quench, отбрасывать и журналировать его.

Приказ из заполненной очереди

RFC 792 1981 года разрешал шлюзу без места в выходной очереди отбросить датаграмму и вернуть ICMP тип 4, код 0. Перегруженный получатель мог сделать то же. Source Quench просил источник уменьшить темп к указанному назначению, а после прекращения предупреждений постепенно наращивать его.

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

Сообщение возвращало исходный IP-заголовок и первые 64 бита данных. Такая квитанция помогала найти разговор, но не показывала глубину очереди, конкурентов, размер отступления и длительность. Она не доказывала криптографически, что отправитель действительно видел цитируемый пакет.

RFC 1122 сохранил договор в 1989 году. Хост мог генерировать Source Quench при нехватке ресурсов, а IP должен был передать принятый сигнал транспорту. TCP полагалось замедлить соединение, обычно вернувшись в slow start. Узкое свидетельство вызывало широкое последствие.

Когда обратная связь добавляла нагрузку

RFC 896 описал коллапс перегрузки: очереди заполняются, хосты повторяют лишь задержавшиеся пакеты, сеть занята копиями, а полезная доставка падает. Дополнительная память откладывает проблему, не исправляя петлю.

Source Quench мог создавать управляющий пакет на каждый сброс. Даже с rate limit насыщенный путь должен был переносить сообщения о собственной насыщенности. Несколько маршрутизаторов могли командовать одним потоком без общего учёта, а послушные потоки уступали игнорирующим.

Поэтому RFC 1812 изменил правило в 1995 году: маршрутизатору НЕ СЛЕДОВАЛО создавать Source Quench, признанный неэффективным и несправедливым; остаточную генерацию требовалось ограничивать. Знание очереди отделили от власти над удалённым транспортом.

Источник учился по последствиям

TCP разместил реакцию там, где хранится состояние потока. RFC 5681 определяет congestion window, slow start, предотвращение и восстановление без Source Quench. ACK доказывает выход данных с пути; потери и timeout несовершенны, но относятся к последовательности, которую отслеживают конечные узлы.

Маршрутизатор сохранил узкую работу. RFC 2309 рекомендовал активное управление очередью до переполнения и разделил очередь, планирование и справедливость. Посредник действует над тем, что видит; транспорт меняет поток, который способен идентифицировать.

Метка внутри пакета

RFC 3168 сохранил явный сигнал через ECN, но привязал его к трафику. Конечные узлы объявляют ECN-возможность; маршрутизатор может поставить Congestion Experienced в пакете вместо сброса. Получатель возвращает метку в состоянии транспорта, отправитель отвечает почти как на потерю.

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

Требовалось отменить и послушание

Отказа от генерации было мало, пока хосты слушались. Старое устройство, ошибка или атакующий сохраняли рычаг. RFC 6633 закрыл путь в 2012 году: хосты не должны отправлять; TCP, UDP, другие транспорты и маршрутизаторы обязаны игнорировать; межсетевые экраны обязаны отбрасывать и должны записывать тип 4 как событие безопасности.

Подделка позволяла слепую атаку на снижение throughput без настоящего узкого места. Массовая фильтрация ICMP делала доставку непригодной основой. В ICMPv6 Source Quench вообще не определяли.

Восемь RFC доказывают постепенный нормативный отзыв, а не единый день всемирного отключения. Они не говорят, что каждый маршрутизатор отправлял, каждый хост слушался, каждая потеря означает перегрузку или ECN нельзя изменить. Они показывают: узнаваемый номер может полностью потерять операционную власть.