Почему подтверждение не становится последним
Представим двух командиров, которым нужно атаковать одновременно. Если один выступит, а второй не получит приказ, первый рискует остаться без поддержки. Поэтому получатель посылает подтверждение: «приказ дошёл». Но отправитель не может отличить два случая — подтверждение пришло или потерялось. Он отправляет квитанцию о получении квитанции, и та же неопределённость возникает снова.
Это не просто неудобство связи. Пока канал может терять сообщения, ни одна конечная последовательность сообщений не даёт обеим сторонам полной уверенности в согласованном решении. Последний отправитель всегда не знает, получил ли другой его последнее сообщение.
Дело в общем знании
Для совместного действия недостаточно, чтобы оба знали план. Нужно, чтобы каждый знал, что второй тоже его знает, — и чтобы каждый знал, что второй знает об этом знании, и так далее. Такое бесконечно наращиваемое взаимное знание называют общим знанием.
Подтверждения создают всё более сильную уверенность, но не завершают эту цепочку. Если командир получил квитанцию, он знает, что приказ дошёл; однако не знает, знает ли другой, что квитанция дошла. В условии, где сообщение может потеряться, эту последнюю неопределённость нельзя устранить ещё одной конечной отправкой.
Что задача говорит о реальных протоколах
Задача двух генералов — мысленный пример о предельной гарантии, а не утверждение, что по ненадёжной сети вообще нельзя координироваться. Практические системы обычно задают допустимый риск, повторяют сообщения, используют тайм-ауты или полагаются на канал с более сильными гарантиями. Это повышает надёжность, но не превращает ненадёжную связь в абсолютно безошибочную.
Поэтому инженерный вопрос обычно звучит не «как получить последнюю, гарантированную квитанцию?», а «какая вероятность сбоя приемлема и что делать, если подтверждение не пришло?». Именно этот выбор — между уровнем уверенности и ценой дополнительных мер — задача делает видимым.
