Кратко

  • Аргумент end-to-end 1984 года не запрещал функциям находиться внутри сети; он предлагал проверить, достаточно ли у подсистемы знаний, чтобы реализовать функцию полностью и правильно.
  • Проверки и повторные передачи на нижних уровнях экономят время и уменьшают число сбоев, но при осторожной передаче файла только настоящие прикладные концы могут сопоставить исходный объект с тем, что в итоге записано и прочитано.

Сначала определить, что значит «закончено»

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

В статье 1984 года Jerome H. Saltzer, David P. Reed и David D. Clark разобрали эту проблему на примере осторожной передачи файла. Источник вычисляет значение по содержимому, получатель записывает файл, заново читает его и независимо вычисляет своё значение. Сравнение на концах охватывает именно тот объект, сохранность которого нужна приложению.

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

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

Как выбирать место для функции

Поздний лозунг об «умных концах и глупой сети» делает аргумент жёстче и беднее оригинала. Исходная логика начинается с функции. Если для её полной и правильной реализации требуется информация, доступная только прикладным концам, то одной реализации на нижнем уровне недостаточно. Концы всё равно должны выполнить окончательную проверку.

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

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

Чек не действует за пределами кассы

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

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

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

Когда середина сети перестала быть простой

Последующие работы Clark показывают, что граница не была задумана как вечный запрет. В анализе философии протоколов DARPA Internet он связывал технические решения с приоритетами вроде живучести, разнообразия сервисов и распределённого управления. В более позднем переосмыслении дизайна Интернета на первый план вышли доверие, контроль, подотчётность и разные интересы участников.

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

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

Карта доказательств вместо одного процента

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

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

Источники