Кратко

  • Удалённые отказы в основном обходили сами шлюзы. На хост ложилась особая задача: заметить смерть непосредственного шлюза, который уже не мог вернуть ICMP-сообщение.
  • Одиночная ошибка ICMP во время сходимости не была основанием немедленно завершить TCP. Повторные передачи и пользовательский тайм-аут показывали серьёзность, а сообщение давало вероятную причину.
  • Подтверждение TCP не доказывало завершение приложения. Ранний SMTP мог принять весь текст и не выдать финальный ответ, а неактивный Telnet — потерять путь без единой незавершённой передачи.

Шлюз, который не мог пожаловаться

В описании David D. Clark шлюзы обменивались свежими мнениями о состоянии соседних сетей и шлюзов. Сразу после отказа эти мнения могли расходиться. Затем система должна была восстановить согласованную топологию и выбрать другой путь.

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

Иначе вёл себя первый шлюз. Когда хост продолжал отдавать пакеты непосредственно машине, которая остановилась, от неё не приходили ни Redirect, ни Destination Unreachable. Остальная сеть могла уже знать исправный маршрут, однако пакеты до неё не доходили.

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

У сетевой ошибки был момент наблюдения

Redirect советовал более подходящий непосредственный шлюз. Destination Unreachable сообщал, что в состоянии, известном отправителю, путь сейчас отсутствует. RFC 816 не делал из этих сообщений вечных утверждений.

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

Сообщение сохраняло ценность. При открытии соединения оно могло указывать на неверный адрес. После тайм-аута — уточнять вероятную причину. Parameter Problem — выявлять дефект реализации. Вес зависел от типа, кода, источника, времени, стадии соединения и других подтверждений.

Наблюдение следовало передать выше, но передача не превращала его в право вынести окончательное решение за верхний уровень.

Неидеальное знание допускало обратимое действие

RFC 816 сравнивал уведомление от подключённой сети, постоянный опрос, опрос по событию и смену шлюза по событию. Непрерывный ICMP Echo позволял следить за шлюзом, но частота, нужная для быстрой реакции, перегружала хост, сеть и сам шлюз. Без отдельного анализа допустимой нагрузки способ запрещался.

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

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

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

RFC 1122 позже потребовал, чтобы IP обнаруживал отказ следующего перехода в кэше и выбирал замену. При этом он признал отсутствие полностью удовлетворительного универсального алгоритма, сохранил запрет постоянного ping и предпочёл положительные и отрицательные советы от TCP, ACK, канального уровня, ARP и ICMP.

TCP видел остановку, но не всегда её причину

TCP повторял неподтверждённый сегмент до получения ACK или окончания допустимого ожидания. Повторы могли передать IP отрицательную подсказку о пути. В обратном направлении IP поднимал ошибки ICMP и сообщения подключённой сети.

Эти факты отвечали на разные вопросы. Повторная передача означала отсутствие ожидаемого прогресса. Пользовательский тайм-аут определял, когда клиент TCP перестаёт ждать. Сетевая ошибка предлагала объяснение. RFC 816 хотел показать их клиенту, потому что человек в Telnet и автоматический отправитель почты принимают разные решения.

RFC 1122 закрепил правило мягких ошибок: определённые Destination Unreachable не должны обрывать установленное TCP-соединение, а сведения следует предоставить приложению. RFC 5461 описал компромисс. Терпение сохраняет сеанс при временной перестройке, но постоянно недоступный первый адрес задерживает переход к следующему. Описанные обходные решения при установлении оставались нестандартными.

RFC 9293 по-прежнему различает тайм-аут повторной передачи и пользовательский тайм-аут. Первый заново отправляет сегмент из очереди. Второй очищает очереди, сообщает об остановке, удаляет состояние и закрывает соединение. Общее слово не создаёт общего полномочия.

Подтверждение всех байтов не завершало почту

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

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

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

В тишине не было передачи, которая могла бы не состояться

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

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

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

Совет работал именно благодаря ограничению

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

ICMP мог быть правдивым, но не окончательным. Тайм-аут мог быть окончательным, но не диагностическим. ACK мог быть подлинным, но не деловым подтверждением. Разделение позволяло соединять сведения, не стирая остаточную неопределённость.

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

Источники