MD5 CheckSum est largement utilisé pour la vérification de l'intégrité pour le téléchargement HTTP. Ma question est que, puisque TCP lui-même fournit un mécanisme fiable (c'est-à-dire une somme de contrôle pour chaque package TCP pour assurer son intégrité). Donc, en court TCP est fiable. HTTP est basé sur TCP (SO HTTP devrait donc être fiable), alors pourquoi nous avons besoin d'un autre mécanisme de vérification de l'intégrité (c'est-à-dire un checksum MD5)?
Merci d'avance, George
4 Réponses :
La réponse est simple. Le fichier source peut déjà être corrompu avant même de commencer à télécharger. TCP vérifie seulement que le fichier que vous téléchargez est identique à la source. MD5 garantit que vous pouvez savoir s'il est corrompu si la cause est un problème dans le transfert ou le fichier initial lui-même.
"La cause est un problème de transfert" - confus à propos de ce point. Je pense que le transfert pendant TCP est fiable. Pourquoi pensez-vous qu'il y a un problème dans le transfert, exemple?
TCP est aussi fiable qu'une connexion pouvait être une connexion, il reste encore des problèmes potentiels dans le transfert à l'aide de TCP. Si la connexion meurt (débranchez-vous sur votre ordinateur du réseau par exemple), TCP fait son mieux pour rétablir une connexion et continuer là où il s'est arrêté, mais après un certain nombre de tentatives qu'elle s'arrête. Le fichier inachevé est laissé sur le disque. Certes, il se produit rarement car la plupart des connexions échouées sont rétablies dans quelques essais.
Le plus souvent, vous utilisez la somme de hachage pour une bande hors bande (imprimée sur le webiste par exemple) Cochez la case de l'intégrité de téléchargement, non programmatique.
Cela empêche la manipulation de l'artefact de téléchargement.
"Manipulation de l'artefact de téléchargement" - Que voulez-vous dire manipulation de l'artefact de téléchargement, pourriez-vous me montrer un échantillon s'il vous plaît?
Ce que je veux dire, c'est simplement une attaque où le téléchargement est remplacé - en brisant au serveur, faisant une redirection créative ... vous téléchargez simplement un autre fichier manipulé. Mais si vous comparez avec la somme de contrôle fournie par d'autres moyens, vous devez peut-être prendre conscience de la triche. Cet autre moyen est souvent appelé «hors bande» - l'attaquant doit briser deux mécanismes.
Si le pirate informatique pourrait manipuler le fichier sur le serveur, pourquoi le piratage ne peut pas pirater la somme de contrôle?
Il peut peut-être, mais il doit casser dans la zone de téléchargement et le système de gestion de contenu (souvent un dB) où la page est contenant la somme de contrôle
Merci. Mais je suis confus. Normalement, URL Link pour téléchargement et checksum figure sur la même page. Si le pirate informatique pourrait pirater la page pour télécharger URL, le pirate informatique doit être facilement pour pirater la somme de contrôle sur la même page, et la checksum n'est qu'une chaîne / numéro de la page. Pourquoi pensez-vous que les pirater les deux est difficile? Toute autre des descriptions?
Regardez une page de téléchargement typique comme hc.apache.org/downloads.cgi . La somme de contrôle est toujours hébergée avec Apache. Le téléchargement est sur un miroir. Si vous avez une base sécurisée, vous pouvez utiliser des délégués moins sûrs. Mais vous avez raison - si quelqu'un se casse dans le serveur Apache, cela ne vous aidera pas beaucoup. Si vous avez des besoins de sécurité plus élevés, vous devez utiliser d'autres oob (quelqu'un vous envoie un courrier après un téléchargement, vous appelle sur le téléphone, ...) ou d'autres techniques (les signatures fournissent une sécurité supérieure, vous les trouvez sur la page Apache, aussi ).
Merci mTraut. Votre description fait vraiment des sens. Outre la prévention du piratage, pensez-vous que MD5 Checksum empêche également la question de transfert de données pendant TCP / http (par exemple, certains bits ne sont pas transférés correctement d'une extrémité à l'autre)?
Je n'apporterais pas une fonctionnalité de hachage à un protocole basé sur TCP uni, comme un scénario de requête / réponse HTTP. Peut-être (aucune expérience pratique) Ceci est utile si vous montez un protocole plus complexe (un téléchargeur pouvant reprendre, par exemple) en plus de cela, où des erreurs subtiles (les deux parties sortent de la synchronisation avec le pointeur de fichier lors du téléchargement, le contenu du fichier a changé. En téléchargeant, ...) pourrait se produire
Bonne réponse. Puis-je ajouter une autre raison: le gestionnaire de téléchargement peut avoir un bug. Le TCP garantit uniquement: 1. Une fois le colis reçu, il est exempt d'erreur 2.L'arrête des packages reçus est identique à la commande envoyée. Que faire ce que ces paquets sont le travail du gestionnaire de téléchargement.
Il y a une chance dans TCP / IP que les erreurs sont non détectées: Noahdavids.org/Self_Publied/crc_and_checksum.htmlled a>
Plus de 3 fois dans ma vie, j'ai téléchargé une ISO ou EXE cassé et quand je l'ai téléchargée à nouveau, cela a fonctionné. Cela me prouve que le mécanisme TCP ne suffit pas pour assurer l'intégrité.
Est arrivé à moi aussi, pourrait avoir viennent du navigateur cependant
En ce qui concerne le 35G du corpus Ted-Lium ou le 400 g encore plus grand d'images minuscules, il semble presque quelque chose d'erreur à chaque fois dans le fichier téléchargé. Pour le 35G Ted-Lium Corpus, j'ai fait le téléchargement depuis au moins 20 fois et totalement 700 g de la transmission du réseau pendant plusieurs mois. CRC est juste un cauchemar.
La somme de contrôle est juste pour ce paquet. Cela ne signifie pas que ces petits morceaux de données qui sont tous vérifiés pour l'intégrité produiront un grand fichier qui a la même intégrité.
Salut thai, je suis confus. Je pense que si la petite intégrité du paquet est correcte, tout le fichier (composé de petits paquets) devrait également être correct. Des commentaires?