Cloud Storage включила сквозные контрольные суммы в новых SDK
Клиентские библиотеки Google проверяют данные между приложением и хранилищем. Это закрывает промежуток до серверного вычисления контрольной суммы.
Что изменилось на стороне клиента
Google описала включённое по умолчанию сквозное вычисление контрольных сумм в актуальных SDK Cloud Storage. В журнале изменений функция датирована 30 сентября, а подробный технический материал вышел 1 октября. Раньше сервер уже проверял собственное хранение, но клиент не всегда передавал контрольную сумму исходных данных. Ошибка могла произойти в пути до первого серверного расчёта и затем закрепиться как будто корректное содержимое. Новые библиотеки рассчитывают сумму при загрузке и передают её серверу, если приложение не предоставило значение самостоятельно. При скачивании выполняется соответствующая проверка. Для использования этих изменений нужно обновить клиентскую библиотеку; существующий старый бинарный файл не получает новый алгоритм автоматически.
Проверка записи и её результат
Документация рекомендует CRC32C для контроля целостности. Клиент рассчитывает значение исходного файла, сервер — полученного содержимого, затем сравнивает их. При несовпадении запись отклоняется с ошибкой 400, а не сохраняется с предупреждением. Это поведение отличает проверку от простого наличия метаданных с контрольной суммой уже принятого объекта. MD5 поддерживается не для всех способов создания: в частности, его нельзя считать универсальным вариантом для составных объектов и multipart-загрузок XML API. У возобновляемой загрузки итоговая сумма относится ко всему объекту, а не только к последнему отправленному куску. Поэтому способ вычисления должен соответствовать операции, которую фактически выполняет клиент.
Частичное чтение требует другого охвата
Если приложение скачивает весь объект, можно сравнить общую сумму. При чтении небольшого диапазона такой проверки недостаточно: у клиента нет остальных байтов. В технической статье Google описывает использование встроенного контроля диапазона в gRPC при соответствующем чтении через SDK. Это важное условие: нельзя приписать одинаковое поведение любому сырому HTTP-запросу Range только потому, что он обращается к тому же бакету. Внутри хранилища данные проходят разбиение и объединение на нескольких уровнях, поэтому контроль целостности должен сопровождать преобразования. Серверная защита и клиентская проверка дополняют друг друга, контролируя разные участки пути от исходного буфера до прочитанного файла.
От чего контрольная сумма не защищает
Совпадение суммы подтверждает передачу выбранных байтов, но не правильность исходного файла по смыслу. Если приложение передало не тот документ, корректная CRC не обнаружит ошибку выбора. Также это не механизм разграничения доступа и не самостоятельное доказательство авторства. Для повторной отправки после ошибки нужны подходящие условия операции, чтобы не перезаписать чужое более новое изменение. Документация по проверке данных описывает транспортную целостность; жизненный цикл объекта и контроль версий остаются отдельными вопросами. При обновлении SDK полезно проверить обработку новой ошибки в приложении: скрытый сбой теперь может проявиться явным отказом записи. Это желательное обнаружение проблемы, но пользовательский процесс должен корректно показать неудачу и не сообщить об успешной загрузке до её подтверждения сервером.
