|
|
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Есть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2014, 21:46 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dymytry, HTTP,FTP - работают поверх TCP. SSH - обертка для обеспечения безопасности. Я бы выбирал между TCP и FTP. Как оно в деталях - тебе сюда . Хинт - при ошибке в checksum пакета протокол запрашивает его повторно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 01:33 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Лучше слать в архиве, тогда архиватор проверит при распаковке. И трафика будет поменьше. Недавно столкнулся с тем что по FTP с помощью wput иногда доходят битые файлы. Еще не разбирался, думаю проблема в отправителе, т.к. наблюдается на двух разных FTP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 07:50 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Забыл двоичный режим передачи включить?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 14:59 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovЗабыл двоичный режим передачи включить?.. хз, передается многотомный rar-архив, 10-20 файлов, битый всегда последний файл (есть копия отправленного), причем валиться так что размер совпадает, а содержимое левое, но структура rar-a соблюдена. Мистика какая-то. Может винда как-то помогает. Иногда нормально доходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 15:21 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovЗабыл двоичный режим передачи включить?.. Не было, добавил -B, понаблюдаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 15:29 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryЕсть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? все эти протоколы выстроены на базе TCP, который гарантирует целостность передачи, т.е. ты либо получишь целостную передачу, либо тебе выдадут ошибку. поэтому чексумма не нужна. Но она может быть нужна для устранения других проблем -- подмены сайта передачи, программных ошибок при передаче и т.п. 1) каким способом передать файл наиболее надежно по критерию целостности файла Любым. 2) каким способом передать файл наиболее быстро Почти всё равно. Шифрованные протоколы немного медленнее. 3) нужно ли проверять md5/checksum своим кодом Не нужно. НО можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 16:32 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TDimitry SibiryakovЗабыл двоичный режим передачи включить?.. хз, передается многотомный rar-архив, 10-20 файлов, битый всегда последний файл (есть копия отправленного), причем валиться так что размер совпадает, а содержимое левое, но структура rar-a соблюдена. Мистика какая-то. Может винда как-то помогает. Иногда нормально доходит. Это реально мистика, видимо, у тебя битый эталон. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 16:34 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dymytry3) нужно ли проверять md5/checksum своим кодом Несмотря на то что TCP и нижележащие протоколы имеют контрольные суммы, эти суммы не гарантируют что данные не битые. Там простая 16-битная сумма, даже не CRC. Повреждения в виде двух битых байтов компенсирующих друг друга не определяются. Поэтому если стоит задача гарантировать целостность переданных данных, то используйте дополнительно MD5/SHA-1 и подобные суммы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 16:46 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
И как часто кто-либо видел искажание текста хоть на этом сайте, хоть где-то ещё? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:08 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто реально мистика, видимо, у тебя битый эталон. Это бэкап бэкапа на самый черный день. Несколько больших файлов ежедневно бэкапится, копия сливается на ftp. Т.к. размер большой, то пакуется томами по 50 Мб. Вот кусок батника который копирует Код: sql 1. 2. 3. 4. 5. Т.е. копируется в два места: локальная папка COPY и на FTP Руками скачиваю с FTP и сверяю. Не сходится всегда последний. Например сегодняПравильный локально: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Было подозрение что это возможно вчерашний не затерся, нет, у вчерашнего другой размер и содержимое. Тут размер одинаковый. Содержимое чуть-чуть совпадает в первых байтах, дальше все разное. Мистика. -B сегодня добавил, может поможет, но сомневаюсь. Причем таких многотомных архивов несколько, и в каждом валится только последний том. Иногда не валится, но редко. Есть подозрение что может виндовс как-то "помогает", т.к. перед отправкой запаковка, но опять же локальная копия нормальная. В общем мистика. PS Проверяйте бэкапы. Я так два года бэкапил, недавно решил проверить распаковку. Я в шоке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:26 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ как часто кто-либо видел искажание текста хоть на этом сайте, хоть где-то ещё? Я видел. HTTP/GET скачивание файла. Некоторые прокси могут портить файлы. Редко, но бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:35 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TНекоторые прокси могут портить файлы. Редко, но бывает.Ну и каким боком кривой софт к надёжности протокола? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:38 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovDima TНекоторые прокси могут портить файлы. Редко, но бывает.Ну и каким боком кривой софт к надёжности протокола? А где гарантия что кривой софт не будет участвовать? В паре случаев был виноват кэш NGINX`а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
И? От необходимости тестовых восстановлений это всё равно не освобождает, т.к. причин, по которым это восстановление не пройдёт - много и дефекты софта и железа будут явно не на первом месте. P.S. Лично мне приходилось более-менее регулярно выкладывать архивы на пару-тройку гигабайт. После того, как осознали, что 7-zip пишет в первый кусок нужную ему информацию после создания всего набора - проблем не было. Даже после того, как отказались от дробления архивов на части. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:56 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ? От необходимости тестовых восстановлений это всё равно не освобождает, т.к. причин, по которым это восстановление не пройдёт - много и дефекты софта и железа будут явно не на первом месте. Освобождает иногда. Если данные не являются куском чего-то более глобального (например репликации БД). В некоторых случаях достаточно чтобы получатель оперативно понял что не дошло, т.е. битого файла достаточно. Дальше сами свяжутся с отправителем и попросят повторить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 18:56 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ как часто кто-либо видел искажание текста хоть на этом сайте, хоть где-то ещё? Какая разница как часто обнаруживали? Главное что вероятность несрабатывания контроля довольно высока - 1/65536 от всех поврежденных пакетов. Что например в сетях с высоким уровнем коллизий (сотовые/вайфай) на больших файлах дает ощутимую вероятность повреждения данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:18 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyГлавное что вероятность несрабатывания контроля довольно высока - 1/65536 от всех поврежденных пакетов. Что например в сетях с высоким уровнем коллизий (сотовые/вайфай) на больших файлах дает ощутимую вероятность повреждения данных.Вероятность намного (на порядки) ниже. Существует еще проверка на канальном уровне (Ethernet-фрейм и т.п.) во всех современных средствах связи. Без таковой проверки последнее, что я видел, была модемная связь со скоростями порядка 7200-9600 (точные протоколы уже не помню). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:23 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryЕсть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? Я вспоминаю разные случаи из практики обмена бэкапами БД (нехилые кусочки по несколько терабайт) когда вобщем-то протокол не имел значения (чаще всего это был SSH!). Попробую перечислить эпик-фейлы. 1) Слали на старую Linux/RHEL32 bit машинку в которой нельзя было создавать файлы больше 2 Гб. Epic fail. Долго искали хвост проблемы. Она каким-то образом сигнализировлась как ошибка другого рода. 2) Неграмотный админ очень резко закрывал сеанс Far/SCP копирования. Zip-плагин отпускал управление очень быстро. Но в фоновом режиме FAR дописывал zip архив. Админ этого не знал. Получали по башке все включая админа. Epic fail. 3) Слали многотомный архив RAR (опция Solid включена). Где-то запоролся 1 битик в среднем томе. Пришлось перезаливать всё заново. RAR не мог восстановить трафик в середине после сбойного бита. Оригинальные архивы не сохранялись по причине нехватки места на сервере БД. 4) Zip коцал кириллицу в именах файлов, gzip/tar по неизвестным причинам вдруг отказывались распаковываться на винде. FTP сервер стоял в текстовом режиме. Были попытки протолкнуть много гигабайтный файл через корпоративную почту. Вобщем во многих этих случаях протокол связи не имел значения. Он вобщем-то свою задачу делал. Но некорректным было обращение с файлами большого размера, незнание и неумение работать с сеткой в highload, эникейство и раздолбайство многих ответственных лиц которые передавали файл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:39 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
miksoftВероятность намного (на порядки) ниже. Существует еще проверка на канальном уровне (Ethernet-фрейм и т.п.) во всех современных средствах связи. А, ну если там другая к.сумма, тогда да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
нужно ли проверять md5/checksum своим кодом Да. Нужно. Если вы - являетесь заинтересованным лицом, то перед отправкой файла почтой, протоколом, вебом, диском или флешкой делаете openssl md5 <filename> формируйте контрольную сумму md5 и прикрепляйте ее рядом в виде текстового файла или в почтовом сообщении. Обяжите получателя сделать проверку файла при получении так-же. Такая практика распространения файлов существует например у Apache Software Foundation при публикации дистрибутивов и у многих других поставщиков опенсорца. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:58 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyГлавное что вероятность несрабатывания контроля довольно высока - 1/65536 от всех поврежденных пакетов. Добавь еще такую же вероятность из IP (там также сумма считается), в который оборачивается TCP-пакет. Будет 1/2^32 и умнож на вероятность сбоя в канале передачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:08 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonDymytryЕсть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? Я вспоминаю разные случаи из практики обмена бэкапами БД (нехилые кусочки по несколько терабайт) когда вобщем-то протокол не имел значения (чаще всего это был SSH!). Попробую перечислить эпик-фейлы. 1) Слали на старую Linux/RHEL32 bit машинку в которой нельзя было создавать файлы больше 2 Гб. Epic fail. Долго искали хвост проблемы. Она каким-то образом сигнализировлась как ошибка другого рода. 2) Неграмотный админ очень резко закрывал сеанс Far/SCP копирования. Zip-плагин отпускал управление очень быстро. Но в фоновом режиме FAR дописывал zip архив. Админ этого не знал. Получали по башке все включая админа. Epic fail. 3) Слали многотомный архив RAR (опция Solid включена). Где-то запоролся 1 битик в среднем томе. Пришлось перезаливать всё заново. RAR не мог восстановить трафик в середине после сбойного бита. Оригинальные архивы не сохранялись по причине нехватки места на сервере БД. 4) Zip коцал кириллицу в именах файлов, gzip/tar по неизвестным причинам вдруг отказывались распаковываться на винде. FTP сервер стоял в текстовом режиме. Были попытки протолкнуть много гигабайтный файл через корпоративную почту. Вобщем во многих этих случаях протокол связи не имел значения. Он вобщем-то свою задачу делал. Но некорректным было обращение с файлами большого размера, незнание и неумение работать с сеткой в highload, эникейство и раздолбайство многих ответственных лиц которые передавали файл. не знаю, мы очень большие файлы перекидывали rsync ом, никогда проблем не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:12 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyвероятность 1/65536 Так тоже утверждать нельзя. Надо учитывать особенность канала передачи и алгоритм проверки. Наиболее вероятная ошибка канала - неправильный прием одного бита, т.е. 0 буде принят как 1 или наоборот. Алгоритм проверки это выявит. Вероятность двухбитовой ошибки = вероятность однобитовой в квадрате, трехбитовой - в кубе и т.д. Сколько бит должно быть искажено чтобы контрольная сумма совпала? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:15 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
MasterZivне знаю, мы очень большие файлы перекидывали rsync ом, никогда проблем не было. У заказчика чаще всего не было rsync. Да и разговор не вёлся в этом ключе. Нас просто ставили перед фактом что будет так или эдак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:26 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=38754752&tid=1341200]: |
0ms |
get settings: |
5ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
28ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 315ms |

| 0 / 0 |
