Comment puis-je vérifier qu'un fichier de 1 a été transféré correctement?
Je transfère fréquemment VM images d'hyperviseurs vers un serveur d'archives pour un stockage à long terme.
Je transfère en utilisant netcat car il est plus rapide que scp, rsync, ect ..
hypervisor$ cat foo.box | nc <archive IP> 1234
archive$ nc -l -p 1234 > foo.box
Une fois le fichier transféré, je vérifie qu'il n'y a pas eu de corruption en exécutant md5sum à la fois sur la cible et sur la source.
Malheureusement, exécuter un md5 sur un fichier volumineux peut prendre beaucoup de temps. Comment comparer plus rapidement l'intégrité de deux gros fichiers?
Mise à jour:
- Ma transmission étant rarement interrompue, la capacité de redémarrage n'est pas un problème.
- Il faut généralement 3-4 heures pour transférer via NC et ensuite 40 minutes pour obtenir le md5sum.
- La sécurité du hachage n'est pas un problème dans ce cas.
Vous pouvez utiliser tee pour faire la somme à la volée avec quelque chose comme ceci (adaptez les commandes netcat à vos besoins):
Serveur:
netcat -l -w 2 1111 | tee >( md5sum > /dev/stderr )
Client:
tee >( md5sum > /dev/stderr ) | netcat 127.0.0.1 1111
La réponse de Nerdwaller à propos de l'utilisation de tee pour transférer et calculer simultanément une somme de contrôle est une bonne approche si vous êtes principalement préoccupé par la corruption sur le réseau. Cela ne vous protégera pas contre la corruption sur le chemin du disque, etc., car cela prend la somme de contrôle avant qu'il ne frappe le disque.
Mais j'aimerais ajouter quelque chose:
1 TiB/40 minutes ≈ 437 Mio/s1.
C'est assez rapide, en fait. Rappelez-vous que sauf si vous avez beaucoup de RAM, il faut que celui-ci revienne du stockage. La première chose à vérifier est donc de regarder iostat -kx 10 pendant que vous exécutez vos sommes de contrôle; en particulier, vous voulez faire attention à la colonne %util. Si vous arrimez les disques (près de 100%), la solution consiste à acheter un stockage plus rapide.
Sinon, comme d'autres affiches l'ont mentionné, vous pouvez essayer différents algorithmes de somme de contrôle. MD4, MD5 et SHA-1 sont tous conçus pour être des hachages cryptographiques (même si aucun d'entre eux ne devrait plus être utilisé à cette fin; ils sont tous considérés comme trop faibles). En ce qui concerne la vitesse, vous pouvez les comparer avec openssl speed md4 md5 sha1 sha256. J'ai jeté dans SHA256 d'avoir au moins un hachage encore assez fort.
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md4 61716.74k 195224.79k 455472.73k 695089.49k 820035.58k
md5 46317.99k 140508.39k 320853.42k 473215.66k 539563.35k
sha1 43397.21k 126598.91k 283775.15k 392279.04k 473153.54k
sha256 33677.99k 75638.81k 128904.87k 155874.91k 167774.89k
De ce qui précède, vous pouvez voir que MD4 est le plus rapide et SHA256 le plus lent. Ce résultat est typique des matériels de type PC, du moins.
Si vous voulez encore plus de performances (au prix d'être triviales à altérer, et également moins susceptibles de détecter une corruption), vous voulez examiner un hachage CRC ou Adler. Des deux, Adler est généralement plus rapide, mais plus faible. Malheureusement, je ne connais aucune implémentation en ligne de commande très rapide. les programmes de mon système sont tous plus lents que ceux de OpenSSL md4.
Donc, votre meilleur pari en termes de vitesse est openssl md4 -r (le -r lui donne l’impression de sortie md5sum).
Si vous souhaitez effectuer une compilation et/ou une programmation minimale, consultez le code de Mark Adler à propos du dépassement de capacité de la pile et également xxhash . Si vous avez SSE 4.2, vous ne pourrez pas battre la vitesse de l'instruction CRC matérielle.
1 1 TiB = 1024⁴ octets; 1 Mio = 1024² octets. Vient à 17417Mo/sec avec des puissances de 1000 unités.
La commande openssl prend en charge plusieurs résumés de messages. Parmi ceux que j'ai pu essayer, md4 semble fonctionner environ 65% du temps de md5 et environ 54% du temps de sha1 (pour le fichier avec lequel j'ai testé).
Il existe également un md2 dans la documentation, mais il semble donner les mêmes résultats que md5.
En gros, la vitesse semble être inversement liée à la qualité, mais puisque vous n'êtes (probablement) pas préoccupé par le fait qu'un adversaire crée une collision délibérée, cela ne devrait pas poser trop de problème.
Vous pouvez rechercher des résumés de messages plus anciens et plus simples (y a-t-il eu un md1, par exemple)?
Un point mineur: vous avez une utilisation inutile de cat . Plutôt que:
cat foo.box | nc <archive IP> 1234
vous pouvez utiliser:
nc <archive IP> 1234 < foo.box
ou même:
< foo.box nc <archive IP> 1234
Cela enregistre un processus, mais n'aura probablement aucun effet significatif sur les performances.
Deux options:
Utilisez sha1sum
sha1sum foo.box
Dans certaines circonstances , sha1sum est plus rapide .
Utilisez rsync
Le transfert prendra plus de temps, mais rsync vérifie que le fichier est arrivé intact.
À partir de la page de manuel rsync
Notez que rsync vérifie toujours que chaque fichier transféré a été correctement reconstruit du côté de la réception en vérifiant la somme de contrôle de l'ensemble du fichier générée lors du transfert du fichier ...
La science progresse. Il semble que la nouvelle fonction de hachage de BLAKE2 soit plus rapide que MD5 (et beaucoup plus difficile à démarrer sur le plan cryptographique).
Référence: https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html
À partir des diapositives de Zooko:
cycles par octet sur Intel Core i5-3210M (Ivy Bridge)
cycles de fonction par octet
long msg 4096 B 64 B MD5 5,0 5,2 13,1 SHA1 4,7 4,8 13,7 SHA256 12,8 13,0 30,0 Keccak 8,2 8,5 26,0 BLAKE1 5,8 6,0 14,9 BLAKE2 3.5 3.5 9.3
Vous ne pouvez probablement pas faire mieux qu’un bon hasch. Vous voudrez peut-être vérifier d'autres fonctions de hachage/somme de contrôle pour voir si certaines sont nettement plus rapides que md5sum. Notez que vous n’avez peut-être pas besoin de quelque chose d'aussi puissant que MD5. MD5 (et des éléments comme SHA1) sont conçus pour être cryptographiquement robustes. Il est donc impossible pour un attaquant/imposteur de créer un nouveau fichier ayant la même valeur de hachage qu’une valeur existante (c.-à-d. -mails et autres documents). Si vous n'êtes pas préoccupé par une attaque de vos communications mais uniquement par une erreur de communication banale, un contrôle de redondance cyclique (CRC) pourrait suffire. (Mais je ne sais pas si ce serait plus rapide.)
Une autre approche consiste à essayer de faire le hachage en parallèle avec le transfert. Cela pourrait réduire le temps total et certainement réduire le facteur d'irritation du besoin d'attendre la fin du transfert, puis d'attendre à nouveau que le MD5 se termine. Je n’ai pas testé cela, mais il devrait être possible de faire quelque chose comme ceci:
Sur la machine source:
mkfifo myfifo tee myfifo < fichier source | Caroline du Nord dest_hostnuméro de port & md5sum myfifo
Sur la machine de destination:
mkfifo myfifo nc -l -p numéro de port | tee myfifo> dest_file & md5sum myfifo
Bien sûr, vérifier la taille des fichiers est un moyen rapide et efficace de détecter si des octets ont été supprimés.
Envoyer de gros fichiers est une douleur. Pourquoi ne pas essayer de découper les fichiers en générant un hachage pour chaque morceau, puis de l'envoyer à la destination, puis de vérifier le hachage et de joindre les morceaux.
Vous pouvez également configurer un réseau personnel BitTorrent. Cela ferait en sorte que le tout atteigne la sécurité.