Nagy számok közelről · 3 perc olvasás
Két elrontott szám, jó ellenőrzőösszeg: hogyan maradhat rejtve a hiba?
Megváltozhat két adat úgy, hogy az ellenőrzőösszeg pontosan ugyanaz marad. Ha az egyik szám egyet nő, a másik egyet csökken, egy összegzésre épülő ellenőrzés akár hibátlannak is láthatja az üzenetet. A rövid ellenőrző érték erős segítség lehet, de a jelentése a konkrét algoritmustól és a hibák típusától függ.
Ebben a cikkben
A fogadó egy rövid értéket újraszámol
Egy ellenőrzőösszeg az üzenet tartalmából számított, rövid kísérő érték. A fogadó ugyanazzal az eljárással ellenőriz, és eltérés esetén sérülést jelez. A klasszikus 16 bites internetes ellenőrzőösszeg az RFC 1071 leírása szerint a szomszédos bájtokat 16 bites számokká párosítja, majd egyes komplemens összeadást használ. Az eredmény bitjeinek megfordításából lesz az ellenőrző mező.
A 16 bites határon túli átvitel ennél az összeadásnál visszakerül az alacsony helyiértékekhez. Az alábbi két számos példában túlcsordulás nem történik, ezért közönséges összeadással is végigszámolható. Egy valódi csomag további mezőket is tartalmazhat; a feladatban az összes többi ellenőrzött adatot változatlanul hagyjuk.
4368 és 8739 helyett 4369 és 8738 érkezik
Az eredeti két 16 bites érték legyen 4368 és 8739. Összegük 13 107. Az összeg bitenkénti megfordítása ebben a tartományban 65 535 − 13 107 = 52 428 ellenőrző értéket ad. Az adatok és az ellenőrző érték együttes összege 65 535, amelynek mind a tizenhat bitje 1; az ellenőrzés sikeres.
Most az első szám egyet nő, a második egyet csökken: 4369 + 8738 ismét 13 107. A régi 52 428-as ellenőrző érték továbbra is megfelel, miközben mindkét adat megváltozott. A példában mindkét változás egyetlen bit átfordulásával előállhat. Ez konkrét, újraszámolható ellenpélda arra az állításra, hogy egy helyes ellenőrzőösszeg minden sérülést kizár.
Több üzenethez jut ugyanaz az ellenőrző érték
Tizenhat bit legfeljebb 2¹⁶ = 65 536 különböző mintát ad. Már a két 16 bites adatszóhoz is 2³² különböző bemenet tartozhat. Ennyi bemenetet 65 536 kimenetbe besorolva szükségszerűen lesznek közös ellenőrző értékű üzenetek. Hosszabb üzeneteknél a lehetséges bemenetek száma tovább nő.
Ez a számossági érv az ütközések létezését bizonyítja, a gyakoriságukat egy adott hibafolyamatban nem határozza meg. Az előző szakasz konkrét algoritmusának egy konkrét vakfoltját is megmutatta. Az RFC 3819 külön tárgyalja, hogy az egyszerű internetes összegzésnél észrevétlen hibák előfordulhatnak, és a hibafelismerés erősségét a kód tulajdonságaihoz kell kötni.
A hibás csomagok száma kerüljön a nevezőbe
Egy külön, idealizált modellben tegyük fel, hogy minden már megsérült üzenetnél 1/65 536 eséllyel marad rejtve a hiba. Ez a véletlen hibákhoz választott feltételezés, a fenti konkrét ellenőrzőösszegre minden helyzetben érvényes tételnek nem tekinthető. Egymillió sérült üzenetből ekkor 1 000 000 / 65 536 ≈ 15,26 észrevétlen hibás üzenet várható.
Ha egymilliárd elküldött üzenetből csak ezer sérült, ugyanebben a modellben az észrevétlen hibák várható száma 1000 / 65 536 ≈ 0,01526. A teljes átküldött forgalmat közvetlenül a felismerési hibaaránnyal szorozni egészen más állítást adna. Előbb a sérülés gyakoriságát, majd a sérülés feltételével számolt elnézési esélyt kell tisztázni.
A jelzés, a javítás és az eredet igazolása külön feladat
Az ellenőrzés hibajelzése önmagában nem mondja meg, melyik bit volt eredetileg más. A fogadó kérhet újraküldést, vagy a rendszer külön hibajavító kódot használhat. Több ellenőrzési réteg javíthatja a megbízhatóságot, de a saját hatásukat és egymáshoz való viszonyukat is modellezni kell.
Egy egyszerű összegzésből az üzenet küldője és jogosultsága sem állapítható meg. Ha az eredetet vagy szándékos módosítás elleni védelmet kell ellenőrizni, arra tervezett hitelesítési megoldás szükséges. A gyakorlati kérdés mindig az legyen, milyen hibát akarunk észrevenni, mekkora forgalmon, és mi történik a sikertelen ellenőrzés után.
A példák és a források
A számpéldák saját, szemléltető feladatok; a megadott feltételezésekből és képletekből újraszámolhatók. Valós vállalkozásra, országos statisztikára vagy jövőbeli eredményre nem vonatkoznak.
- IETF RFC 1071: Computing the Internet Checksum, az egyes komplemens összegzés leírása ↗
- IETF RFC 3819, 8.3: CRCs, Checksums and Error Detection ↗
Forrásellenőrzés: 2026-11-09. A hivatkozások a fogalmakat és a módszert támasztják alá; a példaszámítások a cikk részei.
Négy kérdés a cikkhez
A válaszokból kiderül, melyik összefüggést érted már, és melyik részt érdemes újraolvasnod. A válaszokat és a pontszámot nem mentjük.
