Interpretation einer DNS-Antwort (H)
Aufgabenstellung
Ein nützliches Diagnosewerkzeug für den DNS ist das Programm
dig
(1), das auf vielen Unix-Derivaten (z.B. GNU/Linux Installationen) vorhanden ist. Nachfolgend sehen Sie die aus einer Anfrage resultierenden Resource Records. Beziehen Sie sich beim Bearbeiten der Aufgabe auf die relevanten Zeilnummern!
(a) Zeichnen Sie eine Skizze, die den DNS-Verkehr zur Anfrage darstellt, mit mindestens:
Aufgabenstellung
- dem anfragenden Host
- dem für diesen Host zuständigen DNS-Server (lokaler DNS-Server)
- dem DNS-Server, der die richtige IP-Adresse für
mail.nm.ifi.lmu.de
liefert- eventuellen weiteren DNS-Servern, die Teile der Antwort liefern.
- den Nachrichten, die ausgetauscht wurden.
Geben Sie bei jedem Host in Ihrer Skizze, falls vorhanden, IP-Adresse und Hostname an.
b) Ist die Anfrage rekursiv oder iterativ?
dig
funktioniert normalerweise rekursiv, aber der +trace
Flag macht dig
iterativ
Erklärung
Die Anfrage ist iterativ.
Erklärung:
- Iterative Anfrage: Der anfragende DNS-Resolver fragt nacheinander mehrere DNS-Server. Jeder Server gibt einen Verweis auf den nächsten Server, den der Resolver selbst kontaktieren muss.
- Rekursive Anfrage: Der Resolver fragt nur einen DNS-Server, der dann die gesamte Arbeit der Auflösung übernimmt und die endgültige Antwort zurückgibt.
- In der
dig
-Ausgabe sehen wir, dass der Resolver schrittweise verschiedene Server kontaktiert und Verweise erhält, was typisch für eine iterative Anfrage ist.
(c) Die Ausgabe enthält eine Anfrage an einer der DNS-Root-Server. Wonach wird er gefragt?
Der DNS-Root-Server wird nach den zuständigen Nameservern für die Top-Level-Domain .de
gefragt
Ausschnitte aus dem
dig
In der Ausgabe der
dig
-Anfrage wird einer der DNS-Root-Server nach den zuständigen Nameservern für die Top-Level-Domain (TLD).de
gefragt.Details aus der Ausgabe:
Diese Zeilen zeigen die Nameserver, die für die Root-Zone zuständig sind. Der Root-Server gibt die zuständigen Nameserver für
.de
zurück:Diese Zeilen zeigen die Antwort des Root-Servers, der die Nameserver für die TLD
.de
zurückgibt. Der Root-Server wurde also nach den Nameservern für die TLD.de
gefragt.
d) Der gesuchte Rechnername mail.nm.ifi.lmu.de
ist ein Alias.
i. Wie heisst die Maschine wirklich?
Die Maschine heißt in Wirklichkeit pcheggo.nm.ifi.lmu.de
. mail.nm.ifi.lmu.de
ist nur ein CNAME. Das sehen wir hier: mail.nm.ifi.lmu.de. 86400 IN CNAME pcheggo.nm.ifi.lmu.de.
ii. Welche IP-Adresse hat sie?
Die IP-Adresse lautet: 141.84.218.30
(e) Anhand der Ausgabe können weitere Aussagen bezüglich der DNS-Server gemacht werden:
i. Wer betreibt die DNS-Server, die für Anfragen über die Domäne lmu.de zuständig sind?
Das Leibniz-Rechenzentrum das erkennt man hier:
ii. Welche DNS-Server können Anfragen für die Domäne der gesuchten Maschine liefern?
Für die Domäne nm.ifi.lmu.de
zeigen die folgenden Zeilen der dig
-Ausgabe die zuständigen DNS-Server:
Die DNS-Server, die Anfragen für die Domäne nm.ifi.lmu.de
beantworten können, sind:
acheron.ifi.lmu.de
dns3.lrz-muenchen.de
dns1.nm.ifi.lmu.de
dns2.lrz-muenchen.de
dns0.nm.ifi.lmu.de
Diese Server sind autoritativ für die Domäne nm.ifi.lmu.de
und können somit die Anfragen für die gesuchte Maschine mail.nm.ifi.lmu.de
beantworten.
Tiefgründige Erklärung
Erklärung der DNS-Server
📝 Erklärung der DNS-Server für die Domäne
nm.ifi.lmu.de
acheron.ifi.lmu.de, dns3.lrz-muenchen.de, dns1.nm.ifi.lmu.de, dns2.lrz-muenchen.de, dns0.nm.ifi.lmu.de
Diese DNS-Server sind autoritative Nameserver für die Domäne
nm.ifi.lmu.de
. Das bedeutet, dass sie die endgültige Autorität über die DNS-Einträge dieser Domäne haben. Hier ist eine Erklärung, warum sie existieren und wie sie funktionieren:
- acheron.ifi.lmu.de:
- Ein Nameserver, der speziell für die
ifi.lmu.de
Subdomäne konfiguriert ist.- Verantwortlich für die Verwaltung und Beantwortung von DNS-Anfragen für Hosts unter dieser Subdomäne.
- dns3.lrz-muenchen.de:
- Ein Nameserver, der vom Leibniz-Rechenzentrum (LRZ) betrieben wird.
- Zuständig für mehrere Domänen, einschließlich
lmu.de
und ihrer Subdomänen.- Bietet Redundanz und Lastverteilung für die DNS-Auflösung.
- dns1.nm.ifi.lmu.de:
- Ein primärer Nameserver für die Subdomäne
nm.ifi.lmu.de
.- Speichert die DNS-Einträge und beantwortet Anfragen für diese spezifische Subdomäne.
- dns2.lrz-muenchen.de:
- Ein weiterer Nameserver, der vom Leibniz-Rechenzentrum betrieben wird.
- Unterstützt die Lastverteilung und Redundanz, um die Verfügbarkeit und Zuverlässigkeit der DNS-Dienste zu erhöhen.
- dns0.nm.ifi.lmu.de:
- Ein zusätzlicher Nameserver für die Subdomäne
nm.ifi.lmu.de
.- Hilft bei der Lastverteilung und stellt sicher, dass DNS-Anfragen auch bei Ausfall eines Servers beantwortet werden können.
Warum existieren diese Server?
- Redundanz: Mehrere Nameserver stellen sicher, dass die DNS-Dienste auch dann verfügbar sind, wenn einer der Server ausfällt.
- Lastverteilung: Durch die Verteilung der Anfragen auf mehrere Server wird die Last gleichmäßig verteilt, was die Performance verbessert.
- Zuverlässigkeit und Verfügbarkeit: Durch die Nutzung mehrerer Server wird die Zuverlässigkeit und Verfügbarkeit der DNS-Dienste für die Domäne erhöht.
Wie funktionieren sie?
- DNS-Zonendateien: Jeder dieser Servers hat eine Kopie der DNS-Zonendateien für die Domäne
nm.ifi.lmu.de
, die die Informationen über die DNS-Einträge enthalten.- Autoritative Antworten: Sie geben autoritative Antworten auf DNS-Anfragen für die Domäne
nm.ifi.lmu.de
, was bedeutet, dass ihre Antworten als endgültig und zuverlässig gelten.- Synchronisierung: Die DNS-Zonendateien werden regelmäßig zwischen den Servers synchronisiert, um Konsistenz zu gewährleisten.
Diese DNS-Server spielen eine entscheidende Rolle bei der Sicherstellung der Erreichbarkeit und Zuverlässigkeit der Domäne
nm.ifi.lmu.de
.
iii. Wurde die gesuchte IP-Adresse von einem autoritativen Server geliefert?
Overview: Unterschiede zwischen DNS-Servertypen
🌐 Unterschiede zwischen DNS-Servertypen
1. Root-Nameserver:
- Funktion: Startpunkt für die DNS-Auflösung. Sie verweisen auf die zuständigen TLD-Nameserver.
- Beispiel:
d.root-servers.net
2. TLD-Nameserver (Top-Level-Domain-Nameserver):
- Funktion: Verwalten die DNS-Einträge für eine bestimmte Top-Level-Domain (z.B.
.com
,.de
). Sie verweisen auf die autoritativen Nameserver der Second-Level-Domänen.- Beispiel:
C.DE.NET
für.de
3. Autoritativer Nameserver:
- Funktion: Enthält die DNS-Einträge für eine spezifische Domäne und gibt autoritative Antworten auf Anfragen zu diesen Einträgen.
- Beispiel:
acheron.ifi.lmu.de
fürnm.ifi.lmu.de
4. Rekursiver Nameserver (Resolver):
- Funktion: Führt die DNS-Auflösung im Auftrag des anfragenden Clients durch, indem er andere Nameserver kontaktiert und die endgültige Antwort zurückgibt.
- Beispiel: Lokale DNS-Resolver, die von ISPs oder Unternehmen betrieben werden.
5. Weiterleitungs-Nameserver:
- Funktion: Leitet DNS-Anfragen an einen anderen DNS-Server weiter, anstatt die Auflösung selbst durchzuführen.
- Beispiel: Ein lokaler DNS-Server, der Anfragen an einen externen rekursiven Nameserver weiterleitet.
6. Caching-Nameserver:
- Funktion: Speichert Antworten auf DNS-Anfragen zwischen, um die Auflösung für zukünftige Anfragen derselben Domäne zu beschleunigen.
- Beispiel: DNS-Cache auf einem Router oder einem lokalen Server.
Zusammenfassung der Unterschiede:
- Root-Nameserver: Startpunkt der DNS-Auflösung, verweist auf TLD-Nameserver.
- TLD-Nameserver: Verwalten TLDs, verweisen auf autoritative Nameserver.
- Autoritativer Nameserver: Enthält und liefert die endgültigen DNS-Einträge für eine Domäne.
- Rekursiver Nameserver: Führt die vollständige DNS-Auflösung für Clients durch.
- Weiterleitungs-Nameserver: Leitet Anfragen an andere Nameserver weiter.
- Caching-Nameserver: Speichert Antworten zwischen, um die Auflösung zu beschleunigen.
Ja, die gesuchte IP-Adresse wurde von einem autoritativen Server geliefert.
Erklärung
📝 Erklärung:
In der Ausgabe des
dig
-Befehls sehen wir, dass die endgültige Antwort für die Anfragemail.nm.ifi.lmu.de
von einem autoritativen Server für die Domänenm.ifi.lmu.de
geliefert wurde.Die autoritativen Nameserver für
nm.ifi.lmu.de
sind:Diese Zeilen zeigen die autoritativen Nameserver für
nm.ifi.lmu.de
, darunterdns3.lrz-muenchen.de
.Die tatsächliche IP-Adresse für
mail.nm.ifi.lmu.de
wird in den folgenden Zeilen angezeigt:Dies zeigt, dass
mail.nm.ifi.lmu.de
ein CNAME (Canonical Name) fürpcheggo.nm.ifi.lmu.de
ist und die IP-Adresse141.84.218.30
fürpcheggo.nm.ifi.lmu.de
zurückgegeben wurde.Da die Antwort von
dns3.lrz-muenchen.de
kam, einem der autoritativen Nameserver fürnm.ifi.lmu.de
, wurde die IP-Adresse von einem autoritativen Server geliefert.Zusammenfassung:
- Die Anfrage nach
mail.nm.ifi.lmu.de
wurde andns3.lrz-muenchen.de
gesendet.dns3.lrz-muenchen.de
, ein autoritativer Server fürnm.ifi.lmu.de
, lieferte die IP-Adresse141.84.218.30
zurück.- Somit stammt die IP-Adresse von einem autoritativen Server.
(f) Angenommen Sie haben als Administrator Zugriff auf den DNS-Cache der lokalen DNS-Server im LRZ. Gibt es für Sie damit eine Möglichkeit, die von Nutzern meist besuchten Web-Server im Internet ausfindig zu machen? Fassen Sie sich kurz.
Ja, indem man die Einträge im DNS-Cache analysiert, kann man feststellen, welche Domains und IP-Adressen am häufigsten aufgelöst werden, was auf die meistbesuchten Web-Server hinweist.
Detaillierte Erklärung
📊 Detaillierte Erklärung:
- Analyse des DNS-Caches:
- DNS-Cache: Der DNS-Cache speichert die Ergebnisse vorheriger DNS-Abfragen, um die Auflösung zukünftiger Anfragen zu beschleunigen.
- Einträge: Jeder Eintrag im DNS-Cache enthält Informationen über eine zuvor durchgeführte DNS-Anfrage, einschließlich des angefragten Domain-Namens und der zugehörigen IP-Adresse.
- Erfassung der Anfragen:
- Frequenzanalyse: Durch das Zählen der Häufigkeit, mit der bestimmte Domains im DNS-Cache erscheinen, können Sie feststellen, welche Websites am häufigsten angefragt werden.
- Zeitraum: Es ist wichtig, die Anfragen über einen bestimmten Zeitraum zu analysieren, um ein genaues Bild des Nutzerverhaltens zu erhalten.
- Statistische Auswertung:
- Datenaggregation: Sammeln Sie die Daten aus dem DNS-Cache und aggregieren Sie die Anfragen nach Domain-Namen.
- Rangliste: Erstellen Sie eine Rangliste der Domains basierend auf der Anzahl der Anfragen, um die beliebtesten Websites zu identifizieren.
- Identifikation der meist besuchten Web-Server:
- Top-Domains: Die Domains mit den höchsten Anfragen in der Rangliste sind die meist besuchten Web-Server.
- Nutzerverhalten: Diese Analyse gibt Einblick in das allgemeine Nutzerverhalten und kann helfen, Trends und populäre Websites zu erkennen.
Zusammenfassung: Durch die systematische Analyse und Auswertung der Einträge im DNS-Cache können Administratoren die meist besuchten Web-Server identifizieren. Dies erfolgt durch die Erfassung der Häufigkeit von DNS-Anfragen für verschiedene Domains, was eine Rangliste der populärsten Websites ermöglicht und wertvolle Einblicke in das Nutzerverhalten bietet.
HTTP Requests und Response (H)
Die folgende ASCII-Zeichentabelle wurde mit Hilfe des Wireshark-Programms aufgezeichnet, als ein Web-Browser einen HTTP GET-Request sendete. Zu sehen ist also der komplette Request. Die Zeichen <cr><lf>
stehen dabei für Carriage Return und Line Feed, wie es im Nachrichtenformat in der Vorlesung gekennzeichnet war.
GET /gnu/gnu.html HTTP/1.1<cr><lf>Host: www.gnu.org<cr><lf>User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0<cr><lf>Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<cr><lf>Accept-Language: de-DE,en-US;q=0.7,en;q=0.3<cr><lf>Accept-Encoding: gzip, deflate, br<cr><lf>Connection: keep-alive<cr><lf><cr><lf>
Beantworten Sie die folgenden Fragen zum Mitschnitt des GET-Requests.
(a) Wie lautet die URL des Dokuments, das vom Browser angefragt wurde?
www.gnu.org/gnu/gnu.html
(b) Welche HTTP-Version nutzt der Browser?
HTTP/1.1
(c) Fragt der Browser eine persistente oder nicht-persistente Verbindung an?
Persistent, da Connection: keep-alive
(d) Welche IP hat der Host, auf dem der Browser ausgeführt wird?
Unbekannt
(e) Welcher Browser-Typ hat den Request abgeschickt? Wozu dient die Übermittlung des Typs und ist sie notwendig?
Der Server antwortet nun mit der folgenden HTTP-Response auf die oben gezeigte Anfrage.
HTTP/1.1 200 OK<cr><lf>Date: Thu, 23 May 2019 08:27:34 GMT<cr><lf>Server: Apache/2.4.7<cr><lf>Content-Location: gnu.html<cr><lf>Accept-Ranges: bytes<cr><lf>Content-Encoding: gzip<cr><lf>Content-Length: 5751<cr><lf>Keep-Alive: timeout=3, max=98<cr><lf>Connection: Keep-Alive<cr><lf>Content-Type: text/html<cr><lf>Content-Language: en<cr><lf><cr><lf><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><cr><lf><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><cr><lf><head><cr><lf><!-- start of server/head-include -1.html -->
<... weitere Zeichen der Antwort wurden entfernt ...>
Beantworten Sie die folgenden Fragen.
(f) Konnte der Server das Angefragte Dokument erfolgreich finden? Zu welcher Zeit wurde die Antwort generiert?
Ja konnte er, da Status 200 OK
, wurde um Date: Thu, 23 May 2019 08:27:34 GMT
behandelt
(g) In welcher Sprache ist die Antwort formuliert?
In Englisch.
lang="en"
Content-Language: en
(h) Wie viele Bytes enthält das zurück gegebende Dokument?
5751 Bytes Content-Length: 5751
(i) Wie lauten die ersten 5 Bytes des zurück gegebenen Dokuments? Hat der Server die Anfrage nach einer persistenten Verbindung bestätigt?
Die ersten 5 Bytes des zurückgegebenen Dokuments sind <!DOC
. Ja, der Server hat die Anfrage nach einer persistenten Verbindung bestätigt (Connection: Keep-Alive
)
Was ist es, was kann es? (H)
Aufgabenstellung
Sie finden in einem Büroschrank eine unbeschriftete Komponente mit 5 RJ45-Ports, von der Sie nur wissen, dass diese entweder ein Hub oder ein Switch ist. Sie haben außerdem drei Rechner mit je einer Netzschnittstelle und ausreichend Twisted-Pair-Kabel. Auf den Rechnern können Sie das Programm
ping
und/oder einen Protokoll-Analysator (z.B.wireshark
) einsetzen, mit dem Sie sich alle eingehenden und ausgehenden Rahmen vollständig anzeigen lassen können.Bei allen folgenden Untersuchungen soll das Ergebnis nur durch funktionale Tests und logisches Schlussfolgern bestimmt werden. Erstellen Sie eine Skizze Ihres Versuchsaufbaus und geben Sie die Sequenz der Aktionen (z.B. Programmaufrufe) an. Begründen Sie, warum Ihr Test das richtige Ergebnis liefert!
(a) Wie finden Sie heraus, ob das unbekannte Gerät ein Switch oder ein Hub ist?
Unterschied zwischen Switch und Hub
Hub:
- Ein Hub leitet alle empfangenen Pakete an alle Ports weiter, unabhängig vom Ziel.
- Alle angeschlossenen Geräte empfangen denselben Datenverkehr, was zu mehr Kollisionsdomänen führt.
Switch:
- Ein Switch leitet Pakete nur an den spezifischen Zielport weiter, basierend auf der MAC-Adresse.
- Reduziert unnötigen Datenverkehr und Kollisionsdomänen, wodurch die Netzwerkleistung verbessert wird.
Versuchsaufbau
- Die drei Rechner R1, R2 und R3 sind mit dem Gerät verbunden.
- Wireshark ist auf allen Rechnern gestartet, um den Netzwerkverkehr zu überwachen.
- Ein Ping wird von R1 zu R2 gesendet.
Aktionen
- R3 kann den Ping-Verkehr zwischen R1 und R2 sehen. Das Gerät ist ein Hub, da Hubs alle empfangenen Pakete an alle Ports weiterleiten.
- R3 kann den Ping-Verkehr zwischen R1 und R2 nicht sehen. Das Gerät ist ein Switch, da Switches Pakete gezielt an den entsprechenden Port weiterleiten.
Begründung
Ein Hub leitet alle eingehenden Pakete an alle Ports weiter, während ein Switch Pakete nur an den Zielport weiterleitet.
(b) Nehmen Sie an, es sei ein Switch. Wie bestimmen Sie möglichst genau und effizient die Zeit, nach der der Switch Einträge aus der Forwarding-Tabelle löscht?
Was ist eine Forwarding-Tabelle
Eine Forwarding-Tabelle, auch als MAC-Adresstabelle bezeichnet, ist eine Datenstruktur in einem Switch, die MAC-Adressen und die zugehörigen Ports speichert. Wenn ein Switch ein Paket empfängt, nutzt er diese Tabelle, um zu bestimmen, an welchen Port das Paket weitergeleitet werden soll. Dadurch kann der Switch Pakete gezielt und effizient an den richtigen Empfänger senden, anstatt sie an alle Ports zu übertragen, wie es ein Hub tun würde. Dies reduziert den Datenverkehr im Netzwerk und verbessert die Gesamtleistung.
Versuchsaufbau
- Die drei Rechner sind mit dem Switch verbunden (R1, R2, R3).
- Wireshark ist auf allen Rechnern gestartet.
- Pings werden zwischen R1 und R2 gesendet, und die Zeitpunkte werden notiert.
- Der Verkehr wird für eine bestimmte Zeit gestoppt, dann werden erneut Pings zwischen R1 und R2 gesendet.
Aktionen
- Die Zeitpunkte der letzten und der ersten Pings nach der Pause werden notiert.
- Der Test wird mit verschiedenen Pausenlängen wiederholt (z.B. 1 Minute, 5 Minuten, 10 Minuten).
Begründung
Die Zeitspanne, nach der der Switch die Einträge aus der Forwarding-Tabelle löscht, ist die längste Pause, nach der die Pings zwischen R1 und R2 zunächst keine Antwort erhalten und danach wieder erfolgreich sind. Dies zeigt, dass der Switch die MAC-Adressen neu lernen musste.
CRC (H)
(a) Gegeben sei das Generatorpolynom .
i. Durch wie viele Bits wird bei CRC repräsentiert?
Das Generatorpolynom wird durch 4 Bits repräsentiert (die Koeffizienten von , und ), also 1001
.
Erklärung
CRC und Generatorpolynome
Gegeben sei das Generatorpolynom .
In der Codierungstheorie wird ein Generatorpolynom verwendet, um zyklische Codes zu erzeugen. Ein Generatorpolynom ist ein Polynom mit binären Koeffizienten, das in der Form dargestellt wird.
Darstellung durch Bits
Um das Generatorpolynom in Bits zu repräsentieren, betrachten wir die Koeffizienten der Potenzen von . Das Polynom hat Koeffizienten für die Potenzen und . Diese Koeffizienten sind binär und können entweder 0 oder 1 sein.
Das Polynom kann wie folgt geschrieben werden:
Daher sind die Koeffizienten:
- hat den Koeffizienten 1
- hat den Koeffizienten 0
- hat den Koeffizienten 0
- hat den Koeffizienten 1
Diese Koeffizienten werden als Binärzahl geschrieben: 1001.
Antwort auf die Frage
i. Durch wie viele Bits wird bei CRC repräsentiert?
Das Generatorpolynom wird durch 4 Bits repräsentiert (die Koeffizienten von und ), also 1001.
Erklärung
Der Grad des Polynoms ist 3, und wir müssen auch den Koeffizienten für berücksichtigen, was zu insgesamt 4 Koeffizienten führt. Daher benötigen wir 4 Bits, um das Polynom vollständig zu repräsentieren.
ii. Es soll die Nachricht 11 00 11 CRC-geschützt übertragen werden. Berechnen Sie die zu übertragende Bitfolge (inkl. CRC-Prüfsumme) unter Verwendung des Generatorpolynoms .
Berechnung der CRC-Prüfsumme für die Nachricht (110011)
-
Nachricht vorbereiten:
- Nachricht:
110011
- Anhängen von 3 Nullen (Grad von minus 1):
110011000
- Nachricht:
-
Polynomdivision von
110011000
durch1001
:
110011000
1001
-----
01010
1001
-----
01110
1001
-----
0011
- Der Rest der Division ist
011
.
- CRC-Prüfsumme anhängen:
- CRC-Prüfsumme:
011
- Zu übertragende Bitfolge:
110011011
- CRC-Prüfsumme:
Zusammenfassung
Die zu übertragende Bitfolge (inkl. CRC-Prüfsumme) lautet:
Alternative Erklärung
Berechnung der CRC-Prüfsumme für die Nachricht (110011)
Um die zu übertragende Bitfolge (inkl. CRC-Prüfsumme) für die Nachricht (110011) unter Verwendung des Generatorpolynoms (G(x) = 1001) zu berechnen, gehen wir Schritt für Schritt vor:
Schritt 1: Nachricht vorbereiten
Die Nachricht lautet (110011). Wir hängen drei Nullen (entspricht dem Grad des Generatorpolynoms minus 1) an die Nachricht an:
Schritt 2: Polynomdivision durchführen
Wir führen die Polynomdivision des erweiterten Datenpolynoms durch das Generatorpolynom durch. Die Division wird im Binärmodus (ohne Überträge) durchgeführt.
Initiale Nachricht: (110011000)
Generatorpolynom: (1001)
- Dividiere den höchsten Grad des erweiterten Nachrichtenpolynoms durch den höchsten Grad des Generatorpolynoms:
Der Rest der Division ist (011).
Schritt 3: CRC-Prüfsumme anhängen
Die Prüfsumme wird an das ursprüngliche Datenwort angehängt, um die zu übertragende Bitfolge zu erhalten:
Zusammenfassung der zu übertragenden Bitfolge
Die zu übertragende Bitfolge (inkl. CRC-Prüfsumme) lautet:
Hier ist die vollständige Berechnung zusammengefasst:
Dies ist die berechnete zu übertragende Bitfolge, die sicherstellt, dass die Nachricht (110011) mit der Prüfsumme (011) geschützt ist.
iii. Nehmen Sie an, dass Sie die CRC-geschützte Bitfolge 10 01 10 01 empfangen haben. Zeigen Sie, dass die empfangene Bitfolge unter Verwendung des Generatorpolynoms korrekt ist (inkl. Rechnung). Markieren Sie in Ihrer Rechnung die Stelle, an der der Empfänger die Korrektheit ablesen kann.
iii. Überprüfung der empfangenen Bitfolge 10011001 unter Verwendung des Generatorpolynoms
Schritt 1: Empfangene Nachricht prüfen
Empfangene Bitfolge: 10011001
Schritt 2: Polynomdivision von 10011001 durch 1001
Hier ist die detaillierte Polynomdivision:
- Initiale Nachricht: 10011001
- Generatorpolynom: 1001
- Der Rest der Division ist 000.
Schritt 3: Korrektheit prüfen
Der Rest der Division ist 000, was bedeutet, dass die empfangene Bitfolge korrekt ist, da der Rest 0 ist.
Zusammenfassung der zu übertragenden und empfangenen Bitfolgen
- Zu übertragende Bitfolge (inkl. CRC-Prüfsumme) lautet:
- Empfangene Bitfolge: 10011001
Da der Rest der Polynomdivision 000 ist, zeigt dies an, dass die empfangene Bitfolge korrekt ist.
Schlussfolgerung
Die empfangene Bitfolge 10011001 ist korrekt, da der Rest der Polynomdivision durch das Generatorpolynom 0 ist. Die Stelle, an der der Empfänger die Korrektheit ablesen kann, ist das Endergebnis der Polynomdivision, das 000 ergibt.
Alternative Lösung???
Überprüfung der CRC-geschützten Bitfolge
Um zu überprüfen, ob die empfangene Bitfolge unter Verwendung des Generatorpolynoms korrekt ist, führen wir die Polynomdivision der empfangenen Bitfolge durch das Generatorpolynom durch. Der Rest dieser Division sollte null sein, wenn die empfangene Bitfolge korrekt ist.
Schritt 1: Nachricht und Generatorpolynom
- Empfangene Bitfolge:
- Generatorpolynom:
Schritt 2: Polynomdivision durchführen
Wir führen die Polynomdivision der empfangenen Bitfolge durch das Generatorpolynom im Binärmodus (ohne Überträge) durch.
10011001 ÷ 1001
- Dividiere den höchsten Grad des erweiterten Nachrichtenpolynoms durch den höchsten Grad des Generatorpolynoms:
- Weitere Divisionen:
Schritt 3: Rest überprüfen
Der Rest der Division ist . Dies zeigt, dass die empfangene Bitfolge korrekt ist.
Markierung der entscheidenden Stelle
Der Rest der Polynomdivision ist die entscheidende Stelle, an der der Empfänger die Korrektheit der Nachricht ablesen kann:
Zusammenfassung
Die empfangene Bitfolge ist korrekt, da der Rest der Division durch das Generatorpolynom null ist. Dies bestätigt, dass die empfangene Nachricht keine Fehler enthält.
Email (H)
graph LR
B[User Agent]
C[Mail Server des Senders]
D[Mail Server des Empfängers]
E[User Agent]
B -->|1.| C
C -->|2.| D
D -->|3.| E
(a) Die Abbildung skizziert den Weg einer Email vom Verfasser zum Adressaten. Welche Protokolle der Anwendungsschicht können auf den drei eingezeichneten Übertragungswegen eingesetzt werden?
-
User Agent zu Mail Server des Senders:
- SMTP
- IMAP
- POP3
-
Mail Server des Senders zu Mail Server des Empfängers:
- SMTP
-
Mail Server des Empfängers zu User Agent des Empfängers:
- IMAP
- POP3
(b) Nehmen Sie nun an, dass der Sender mit einem webbasierten E-Mail Account (bspw. GMail oder GMX) eine E-Mail an den Empfänger verschickt. Welche (zusätzlichen) Protokolle im Vergleich zu Teilaufgabe (a) sind involviert?
- HTTP
- HTTPS
(c) Welche dargestellten Systeme sind Teil des Message Transfer Systems?
- Mail Server des Senders
- Mail Server des Empfängers
(d) Internet E-Mail ist empfindlich gegen den Dienstgüteparameter “Datenverlust” des Transportnetzes. Gibt es allgemeine Dienstgüteparameter, gegen die E-Mail unempfindlich ist? Begründen Sie Ihre Antwort!
- Latenz (Verzögerung)
- Jitter (Schwankungen in der Verzögerung)
- Bandbreite
E-Mails sind unempfindlich gegenüber diesen Parametern, da sie asynchron sind und keine Echtzeitanforderungen haben.