Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles Berger Sabbatel
On Fri, 10 Dec 2004 10:23:24 +0100, alex wrote:
Est-ce que la transmission tcp/ip sur ethernet est 100% fiable?
A 100% non, personne ne dira jamais cela. Elle est fiable à 99,(grand nombre de 9)%... Tout dépend donc du nombre de 9 qui vous voulez...
je crois savoir qu'il y a a CRC32 check sur ethernet et un checksum de 16 bit sur tcp, peut-on en conclure que les données transmises sont fiables ?
Les contrôles d'erreur effectués au nivau Ethernet et au niveau IP sont là pour vous garantir, avec une bonne probabilité (beaucoup de 9) que, si vous recevez un paquet, il est correct.
A la base, le taux d'altération des paquets sur un réseau Ethernet correctement monté est déjà très faible. Si, par exemple, un paquet sur 100000 est altéré (c qui est déjà pessismiste, à mon avis), encore faut-il qu'il soit altéré de façon telle que le CRC32 soit le même. Soit une chance sur 4 milliards - au pire, parce-que le CRC est prévu pour résister aux cas d'erreurs les plus probables (perte de quelques bits consécutifs), et on ne voit jamais un paquet erroné se transformer de manière totalement arbitraire. Sachant aussi que dans bon nombre de cas, une perturbation électrique du réseau entraîne tout simplement l'impossibilité pour le récepteur de recevoir le paquet (et non la réception d'un paquet erroné).
Si la réception d'un paquet erroné se produisait, le checksum tcp apporte un nouveau niveau de fiabilité, avec - toujours au pire - une chance sur 65536 pour qu'un paquet erroné arrive avec un bon checksum. En cumulant tout, disons en gros que vous pouvez transmettre à plein pot sur un réseau Gigabit pendant quelques milliers d'années sans risque notable que cela se produise...
Si un tel risque (que je laisse aux spécialistes le soin d'évaluer plus précisément) vous semble inacceptable, vous avec encore la possibilité de rajouter une couche de contrôle au niveau application.
Pensez quand même à vérifier les sommes MD5 et les signatures des logiciels que vous téléchargez sur le réseau. Le risque que ces logiciels aient été altérés sur le serveur est beaucoup moins négligeable...
On Fri, 10 Dec 2004 10:23:24 +0100, alex wrote:
Est-ce que la transmission tcp/ip sur ethernet est 100% fiable?
A 100% non, personne ne dira jamais cela. Elle est fiable à 99,(grand
nombre de 9)%... Tout dépend donc du nombre de 9 qui vous voulez...
je crois savoir qu'il y a a CRC32 check sur ethernet et un checksum de 16
bit sur tcp, peut-on en conclure que les données transmises sont fiables
?
Les contrôles d'erreur effectués au nivau Ethernet et au niveau IP sont
là pour vous garantir, avec une bonne probabilité (beaucoup de 9) que,
si vous recevez un paquet, il est correct.
A la base, le taux d'altération des paquets sur un réseau Ethernet
correctement monté est déjà très faible. Si, par exemple, un paquet
sur 100000 est altéré (c qui est déjà pessismiste, à mon avis), encore
faut-il qu'il soit altéré de façon telle que le CRC32 soit le même.
Soit une chance sur 4 milliards - au pire, parce-que le CRC est prévu
pour résister aux cas d'erreurs les plus probables (perte de quelques
bits consécutifs), et on ne voit jamais un paquet erroné se transformer
de manière totalement arbitraire. Sachant aussi que dans bon nombre de
cas, une perturbation électrique du réseau entraîne tout simplement
l'impossibilité pour le récepteur de recevoir le paquet (et non la
réception d'un paquet erroné).
Si la réception d'un paquet erroné se produisait, le checksum tcp
apporte un nouveau niveau de fiabilité, avec - toujours au pire - une
chance sur 65536 pour qu'un paquet erroné arrive avec un bon checksum.
En cumulant tout, disons en gros que vous pouvez transmettre à plein pot
sur un réseau Gigabit pendant quelques milliers d'années sans risque
notable que cela se produise...
Si un tel risque (que je laisse aux spécialistes le soin d'évaluer plus
précisément) vous semble inacceptable, vous avec encore la possibilité
de rajouter une couche de contrôle au niveau application.
Pensez quand même à vérifier les sommes MD5 et les signatures des
logiciels que vous téléchargez sur le réseau. Le risque que ces
logiciels aient été altérés sur le serveur est beaucoup moins
négligeable...
Est-ce que la transmission tcp/ip sur ethernet est 100% fiable?
A 100% non, personne ne dira jamais cela. Elle est fiable à 99,(grand nombre de 9)%... Tout dépend donc du nombre de 9 qui vous voulez...
je crois savoir qu'il y a a CRC32 check sur ethernet et un checksum de 16 bit sur tcp, peut-on en conclure que les données transmises sont fiables ?
Les contrôles d'erreur effectués au nivau Ethernet et au niveau IP sont là pour vous garantir, avec une bonne probabilité (beaucoup de 9) que, si vous recevez un paquet, il est correct.
A la base, le taux d'altération des paquets sur un réseau Ethernet correctement monté est déjà très faible. Si, par exemple, un paquet sur 100000 est altéré (c qui est déjà pessismiste, à mon avis), encore faut-il qu'il soit altéré de façon telle que le CRC32 soit le même. Soit une chance sur 4 milliards - au pire, parce-que le CRC est prévu pour résister aux cas d'erreurs les plus probables (perte de quelques bits consécutifs), et on ne voit jamais un paquet erroné se transformer de manière totalement arbitraire. Sachant aussi que dans bon nombre de cas, une perturbation électrique du réseau entraîne tout simplement l'impossibilité pour le récepteur de recevoir le paquet (et non la réception d'un paquet erroné).
Si la réception d'un paquet erroné se produisait, le checksum tcp apporte un nouveau niveau de fiabilité, avec - toujours au pire - une chance sur 65536 pour qu'un paquet erroné arrive avec un bon checksum. En cumulant tout, disons en gros que vous pouvez transmettre à plein pot sur un réseau Gigabit pendant quelques milliers d'années sans risque notable que cela se produise...
Si un tel risque (que je laisse aux spécialistes le soin d'évaluer plus précisément) vous semble inacceptable, vous avec encore la possibilité de rajouter une couche de contrôle au niveau application.
Pensez quand même à vérifier les sommes MD5 et les signatures des logiciels que vous téléchargez sur le réseau. Le risque que ces logiciels aient été altérés sur le serveur est beaucoup moins négligeable...
Les contrôles d'erreur effectués au nivau Ethernet et au niveau IP sont là pour vous garantir, avec une bonne probabilité (beaucoup de 9) que, si vous recevez un paquet, il est correct.
Au niveau ethernet oui, au niveau ip, le checksum ne prend en compte que l'en-tête. Il y a de nouveau un checksum pour UDP/TCP sur l'ensemble du paquet.
A la base, le taux d'altération des paquets sur un réseau Ethernet correctement monté est déjà très faible. Si, par exemple, un paquet sur 100000 est altéré (c qui est déjà pessismiste, à mon avis), encore faut-il qu'il soit altéré de façon telle que le CRC32 soit le même. Soit une chance sur 4 milliards - au pire, parce-que le CRC est prévu pour résister aux cas d'erreurs les plus probables (perte de quelques bits consécutifs), et on ne voit jamais un paquet erroné se transformer de manière totalement arbitraire. Sachant aussi que dans bon nombre de cas, une perturbation électrique du réseau entraîne tout simplement l'impossibilité pour le récepteur de recevoir le paquet (et non la réception d'un paquet erroné).
Mouaif, je me rappelle la lecture du TCP/IP illustré ou Mr Stevens avait fait des stats qui montraient: - que le nombre de trames éronnées était important au niveau ethernet - Qu'il y avait des datagrammes UDP erronés alors même que le checksum ethernet était correct, ce qui montrait que l'erreur se produisait après réception de la trame.
Bref, il y a plein de théorie, et plein de pratiques qui montrent que la théorie n'est pas respectée :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Gilles Berger Sabbatel" <Gilles.Berger@imag.fr> wrote in message
news:pan.2004.12.10.10.21.56.573145@imag.fr
Les contrôles d'erreur effectués au nivau Ethernet et au niveau IP sont
là pour vous garantir, avec une bonne probabilité (beaucoup de 9) que,
si vous recevez un paquet, il est correct.
Au niveau ethernet oui, au niveau ip, le checksum ne prend en compte
que l'en-tête. Il y a de nouveau un checksum pour UDP/TCP sur l'ensemble
du paquet.
A la base, le taux d'altération des paquets sur un réseau Ethernet
correctement monté est déjà très faible. Si, par exemple, un paquet
sur 100000 est altéré (c qui est déjà pessismiste, à mon avis), encore
faut-il qu'il soit altéré de façon telle que le CRC32 soit le même.
Soit une chance sur 4 milliards - au pire, parce-que le CRC est prévu
pour résister aux cas d'erreurs les plus probables (perte de quelques
bits consécutifs), et on ne voit jamais un paquet erroné se transformer
de manière totalement arbitraire. Sachant aussi que dans bon nombre de
cas, une perturbation électrique du réseau entraîne tout simplement
l'impossibilité pour le récepteur de recevoir le paquet (et non la
réception d'un paquet erroné).
Mouaif, je me rappelle la lecture du TCP/IP illustré ou Mr Stevens avait
fait des stats qui montraient:
- que le nombre de trames éronnées était important au niveau
ethernet
- Qu'il y avait des datagrammes UDP erronés alors même que le checksum
ethernet était correct, ce qui montrait que l'erreur se produisait
après réception de la trame.
Bref, il y a plein de théorie, et plein de pratiques qui montrent que
la théorie n'est pas respectée :-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Les contrôles d'erreur effectués au nivau Ethernet et au niveau IP sont là pour vous garantir, avec une bonne probabilité (beaucoup de 9) que, si vous recevez un paquet, il est correct.
Au niveau ethernet oui, au niveau ip, le checksum ne prend en compte que l'en-tête. Il y a de nouveau un checksum pour UDP/TCP sur l'ensemble du paquet.
A la base, le taux d'altération des paquets sur un réseau Ethernet correctement monté est déjà très faible. Si, par exemple, un paquet sur 100000 est altéré (c qui est déjà pessismiste, à mon avis), encore faut-il qu'il soit altéré de façon telle que le CRC32 soit le même. Soit une chance sur 4 milliards - au pire, parce-que le CRC est prévu pour résister aux cas d'erreurs les plus probables (perte de quelques bits consécutifs), et on ne voit jamais un paquet erroné se transformer de manière totalement arbitraire. Sachant aussi que dans bon nombre de cas, une perturbation électrique du réseau entraîne tout simplement l'impossibilité pour le récepteur de recevoir le paquet (et non la réception d'un paquet erroné).
Mouaif, je me rappelle la lecture du TCP/IP illustré ou Mr Stevens avait fait des stats qui montraient: - que le nombre de trames éronnées était important au niveau ethernet - Qu'il y avait des datagrammes UDP erronés alors même que le checksum ethernet était correct, ce qui montrait que l'erreur se produisait après réception de la trame.
Bref, il y a plein de théorie, et plein de pratiques qui montrent que la théorie n'est pas respectée :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
