EMZETT.Footer
Kurz: Ein optionaler Datenblock am Ende eines Datenpakets, meist für Prüfsummen oder Markierungen, dass das Paket zu Ende ist.
Genauer: Nicht jedes Protokoll nutzt einen Footer — viele begnügen sich mit Längenangaben im Header. Wo er vorkommt (z. B. bei Ethernet-Frames als “Frame Check Sequence”), dient er meist der Fehlererkennung: Der Empfänger prüft, ob die empfangenen Daten mit der im Footer angegebenen Prüfsumme übereinstimmen.
Im Detail
Frame Check Sequence bei Ethernet
Beim Ethernet-Frame heißt der Footer “Frame Check Sequence” (FCS) und besteht aus einer 4-Byte-CRC32-Prüfsumme (Cyclic Redundancy Check), die über den gesamten Rahmeninhalt berechnet wird. Der Sender berechnet die Prüfsumme vor dem Versand mathematisch aus den zu übertragenden Bits und hängt das Ergebnis an; der Empfänger führt exakt dieselbe Berechnung nach dem Empfang erneut über dieselben Daten durch und vergleicht sein Ergebnis mit dem mitgeschickten Wert:
Empfangener Frame → CRC neu berechnen → stimmt mit Footer überein? → ja: weiterverarbeiten
→ nein: Frame verwerfen
CRC32 erkennt zuverlässig praktisch alle zufälligen Bitfehler in typischer Größenordnung, ist aber KEIN kryptografischer Schutz — ein gezielter Angreifer könnte theoretisch Daten so manipulieren, dass die Prüfsumme trotzdem passt. Für echte Integritäts- und Authentizitätssicherung gegen böswillige Manipulation sind kryptografische Verfahren wie Hash-Funktionen oder digitale Signaturen nötig, nicht ein einfacher CRC.
Stiller Verlust statt Fehlermeldung
Stimmen beide Werte nicht überein, wurde der Frame auf dem Übertragungsweg verändert — meist durch physikalische Ursachen wie elektromagnetische Störungen, ein defektes Kabel oder Signaldämpfung. Der Empfänger verwirft den beschädigten Frame in diesem Fall einfach sofort und stillschweigend, OHNE eine Fehlermeldung an den Sender zurückzuschicken — auf Schicht 2 gibt es dafür schlicht keinen vorgesehenen Mechanismus. Es liegt vollständig an höheren Schichten wie TCP, den fehlenden Frame indirekt zu bemerken (über ein ausbleibendes ACK innerhalb der erwarteten Zeit) und eine Neuübertragung anzustoßen — die eigentliche Fehlerbehandlung passiert also nicht dort, wo der Fehler entdeckt wurde, sondern mehrere Schichten höher.
Warum manche Protokolle auf Footer verzichten
Viele modernere Protokolle verzichten bewusst auf einen separaten Footer am Ende und packen stattdessen alle nötigen Metadaten (inklusive Längenangabe und Prüfsumme) direkt in den Header am Anfang der Nachricht. Das hat einen praktischen Vorteil bei der Verarbeitung: Ein Empfänger weiß dadurch sofort beim Lesen des Headers, wie lang das gesamte Paket insgesamt wird, und kann entsprechend Speicher reservieren bzw. erkennen, wann die Nachricht vollständig empfangen wurde — statt erst bis zum tatsächlichen Ende warten zu müssen, um überhaupt einen Footer zu finden. Das ist besonders relevant bei Streaming-artiger Verarbeitung, bei der Daten idealerweise schon verarbeitet werden können, bevor die komplette Nachricht überhaupt vollständig angekommen ist.