Кратко
- RFC 3479 нумеровала защищённые операции LDP, а накопительный ACK отмечал префикс, который получатель сделал устойчивым к отказу.
- После восстановления соединения неопределённый хвост отправлялся заново; checkpoint фиксировал границу, а три сообщения Cork останавливали оба направления.
Новый сеанс TCP не помнит, чем закончился старый. Последний Label Request мог остаться у отправителя, попасть к соседу, быть обработанным или сохраниться в памяти, переживающей переключение. RFC 3479 не скрыла эту неопределённость словом «восстановление». Она заставила два пира сравнить доказуемые части своих историй.
Объём истории задавал FT Session TLV. Бит S включал операции с последовательными номерами, A мог потребовать такую защиту для всех меток, C выбирал checkpoint и мог работать без S. Поэтому ACK имеет смысл только вместе с записью согласованных флагов: именно они определяют множество, к которому относится подтверждение.
Защищённое сообщение несло FT Protection TLV и номер внутри конкретного сеанса. Получатель обязан был сохранить само сообщение или полученное после обработки состояние и лишь затем вернуть FT ACK. Способ хранения оставался локальным. Общим требованием была устойчивость, а не единая внутренняя база данных.
ACK был накопительным. Четыре означало сохранённый префикс от одного до четырёх, но ничего не говорило о пяти. Подтверждения разрешалось объединять, задерживать и дублировать, но нельзя было выдавать вне порядка. Слишком большая задержка могла исчерпать пространство неподтверждённых номеров и остановить новые FT-операции. Экономия пакетов увеличивала видимый долг.
При новом соединении каждый пир сообщал последнюю сохранённую последовательность. Всё, что отправитель послал после этой границы, выдавалось заново, а сосед обрабатывал это как первое поступление. Старый поток байтов не воскрешался. Восстанавливался лишь хвост, исход которого не подтверждала устойчивая память другой стороны.
Допускались две пары net-zero: Label Request с Label Abort и Label Mapping с Label Withdraw. Но локальное наличие противоположных операций ещё не позволяло удалить обе. Первая половина могла пройти до обрыва. Только ACK соседа показывал, что он получил, и после этого свёртка становилась обоснованной.
Address и Address Withdraw также защищались. Иначе один пир мог считать адрес действующим, а другой — отозванным. Адрес, утративший силу, требовал явного Withdraw после восстановления. Если оба пира не заявляли сохранённое состояние, старый набор считался отозванным и строился заново.
Checkpoint менял размер подтверждаемого блока. Keepalive с FT Protection просил сохранить все предыдущие check-pointable сообщения и вернуть границу. При C без S обычные сообщения не имели собственных активных номеров и подтверждались набором. При S checkpoint охватывал нумерованные операции и адреса. Название не делало его снимком всей системы.
Для управляемой остановки одного направления было мало. Инициатор должен был подтвердить и то, что сам сохранил историю соседа. FT Cork TLV создавал три шага: запрос покоя, завершение обработки и остановку новых операций на другой стороне, затем обратное закрытие. Только третье сообщение ставило оба журнала на одну границу.
Если пир не мог сохранить или отложить операции, он обязан был сбросить FT Reconnect Flag. Сброс любой стороной означал отказ от старого FT-состояния. Изменение параметров, например границ пространства меток, тоже запрещало простое продолжение: прежняя операция могла получить иной смысл.
IESG Note не позволяет превратить документ в историю бесспорного успеха. В ней сказано, что указаний по таймерам и повторам недостаточно, возможен преждевременный failover, а механизм не должен служить образцом будущей отказоустойчивости TCP. RFC дала язык сверки, но не универсально безопасные настройки.
Граница с уже опубликованными материалами точна. Статья о RFC 3478 владеет устаревшим forwarding state и временными окнами. Статья о RFC 3612 — различием между сохранённым состоянием, ACK и истиной пересылки. Здесь остаются область защиты, последовательности, устойчивая граница, повторная выдача, net-zero, checkpoint и Cork.
По методу Heng Lu аудит начинается с идентификаторов старого и нового сеансов, флагов S/A/C/R и неизменных параметров. Для каждого пира отдельно строятся отправленные номера, сохранённое состояние и реально переданные ACK. На сбое фиксируются очереди; после него объясняется каждый повтор и каждая свёртка; при остановке сохраняются три Cork и момент прекращения новых операций.
ACK не охватывает будущий номер. Checkpoint не охватывает несогласованное множество. Один Cork не доказывает двусторонний покой. Эти квитанции не доказывают доставку приложению. Они отвечают на более ранний вопрос: какую часть истории операций оба пира могут признать общей.
Историческая ценность RFC 3479 в том, что она не назвала амнезию восстановлением. Номера ограничили спор, ACK нашли общее прошлое, повтор восстановил неопределённый хвост, Cork создал общую точку. Сеанс TCP оборвался, и журнал пришлось сверять заново.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
