From ef73a23bc6a80caea760ba6c41152cf16528f8a1 Mon Sep 17 00:00:00 2001 From: AnkiTUM-Bot Date: Thu, 25 Jul 2024 22:57:28 +0000 Subject: [PATCH] AnkiBot: Automatically added missing IDs --- ...tzungs_darstellungs_anwendungsschicht.yaml | 70 +++++++++++- IN0010_GRNVS/transportschischt.yaml | 103 ++++++++++++++++-- IN0010_GRNVS/vermittlungsschicht.yaml | 66 ++++++++++- 3 files changed, 220 insertions(+), 19 deletions(-) diff --git a/IN0010_GRNVS/sitzungs_darstellungs_anwendungsschicht.yaml b/IN0010_GRNVS/sitzungs_darstellungs_anwendungsschicht.yaml index 726d8bc..a660afa 100644 --- a/IN0010_GRNVS/sitzungs_darstellungs_anwendungsschicht.yaml +++ b/IN0010_GRNVS/sitzungs_darstellungs_anwendungsschicht.yaml @@ -3,12 +3,15 @@ author: Hugo Melder id: 3473949327 cards: - type: markdown + id: 0 # (generated) front: Was ist eine Session? back: | **Kommunikation** zwischen mindestens zwei Teilnehmern mit **definiertem Anfang und Ende**, sowie sich darauf ergebender Dauer. - type: markdown - front: Welche verschiedenen Dienste werden üblicherweise im verbindungsorientierten Modus angeboten? + id: 1 # (generated) + front: Welche verschiedenen Dienste werden üblicherweise im verbindungsorientierten + Modus angeboten? back: | - **Aufbau** und **Abbau** von Sessions - **Prioritisierung** @@ -16,37 +19,45 @@ cards: - **Fehlermeldungen** - **Wiederherstellung** nach Verbindungsabbruch - type: markdown + id: 2 # (generated) front: Wozu werden Cookies bei HTTP gebraucht? back: | - Um Informationen über mehrere Anfragen und Antworten zu erhalten. + Um Informationen über mehrere Anfragen und Antworten zu erhalten. - type: markdown + id: 3 # (generated) front: Welchen Schichten kann HTTP zugeordnet werden? back: | Anwendungsschicht (7), beinhaltet aber auch Funktionen der Darstellungs- und Sitzungsschicht (Schichten 6/5). - type: markdown + id: 4 # (generated) front: Was versteht man unter einem sicheren Kanal? back: | Der sichere Kanal abstrahiert vom eigentlichen Anwendungsprotokoll, sichert die Schutzziele (CIA) aber den höheren Protokollschichten zu. - type: markdown + id: 5 # (generated) front: Was ist TLS? back: | Ein Protokoll um einen sicheren Kanal über einen verbindungsorientierten Transportdienst zu gewährleisten. - type: markdown + id: 6 # (generated) front: Wie können TLS Sitzungen über mehrere TCP-Verbindungen hinweg erhalten bleiben? back: | - type: markdown + id: 7 # (generated) front: Welchen Schichten kann TLS zugeordnet werden? back: | - Verwaltung und Wiederaufnahme von Sessions: **Sitzungsschicht** - Verschlüsselungsfunktionen: **Darstellungsschicht** - type: markdown + id: 8 # (generated) front: Was passiert im Verbindungsaufbau bei TLS? back: | Es werden **Verfahren für Authentifizierung und Verschlüsselung, sowie Zertifikate** ausgetauscht - type: markdown + id: 9 # (generated) front: Erläutere die Aufgaben der **Darstellungsschicht**! back: | - **Kodierung** der Daten @@ -55,68 +66,85 @@ cards: - Verschlüsselung - **Strukturierte Darstellung** von Daten - type: markdown + id: 10 # (generated) front: Was ist ein Zeichensatz? back: | Eine Menge von Zeichen, bei der jedes **Zeichen** mit einem **Codepoint*** verknüpft ist. - type: markdown + id: 11 # (generated) front: Nenne Beispiele für Zeichensätze? back: | - ASCII - Unicode - type: markdown + id: 12 # (generated) front: Was ist ein Codepoint? back: | Ein Codepoint ist eine eindeutige "Kennzahl" für höchstens ein Textzeichen. - type: markdown - front: Was ist der Unterschied zwischen **Fixed-Length** und **Variable-Length** Codes? + id: 13 # (generated) + front: Was ist der Unterschied zwischen **Fixed-Length** und **Variable-Length** + Codes? back: | - **Fixed-Length**: Alle Zeichen werden mit Codewörtern derselben Länge kodiert - **Variable-Length**: Zeichen können mit Codewörtern unterschiedlicher Länge kodiert werden - type: markdown + id: 14 # (generated) front: Wofür steht UTF in UTF-8? back: | **U**nicode **T**ransformation **F**ormat - type: markdown + id: 15 # (generated) front: Was ist der Unterschied zwischen einem Codepoint und einer UTF Kodierung? back: | Ein Codepoint identifiziert höchstens ein Zeichen, während UTF die Kodierung eines Codepoints spezifiziert. - type: markdown + id: 16 # (generated) front: Warum wird UTF-8 in der Praxis am häufigsten eingesetzt? back: | UTF-8 ist **rückwärts-kompatibel** zu ASCII - type: markdown + id: 17 # (generated) front: Warum ist es wichtig, dass UTF-8 prefixfrei und selbstsynchronisierend ist? back: | Ermöglicht effizientes Parsen und fehlerfreies Erkennen von Zeichenanfängen in Datenströmen - type: markdown - front: Welchen Möglichkeiten gibt es für die strukturierte Austausch und Darstellung von Anwendungsdaten? + id: 18 # (generated) + front: Welchen Möglichkeiten gibt es für die strukturierte Austausch und Darstellung + von Anwendungsdaten? back: | - **(gepackte) structs**/**serialisierte Speicherbereiche**: Daten werden so wie sie im Speicher vorliegen übertragen - **Struktureierte Serialisierungsformate**: XML oder JSON - type: markdown + id: 19 # (generated) front: Warum ist es problematisch gepackte Structs für den Datenaustausch zu verwenden? back: | - **Platform-abhängig**e Kodierung (Endianes, etc.) - Gleiche Datenstrukturen (und Compiler) müssen verwendet werden. - type: markdown + id: 20 # (generated) front: Wie werden Kompressionsverfahren unterschieden? back: | - **Verlustfreie Komprimierung** (engl. lossless compression) - **Verlustbehaftete Komprimierung** (engl. lossy compression) - type: markdown + id: 21 # (generated) front: Was versteht man unter Quellenkodierung? back: | Komprimieren von Daten vor dem Senden. - type: markdown + id: 22 # (generated) front: Was ist die grundlegende idee der Huffman-Kodierung? back: | Variable Codewortlänge basierend auf Auftrittswahrscheinlichkeit. - type: markdown + id: 23 # (generated) front: Beschreibe wie man einen Huffman-Baum konstruiert. back: | - type: markdown + id: 24 # (generated) front: Was ist ein optimaler Präfixcode? back: | Gültige Codewörter sind niemals Präfix eines anderen Codeworts. Minimiert mittlere Codewortlänge: @@ -124,40 +152,49 @@ cards: [$$]\sum_{i \in \mathcal{A}} p(i) \cdot |c(i)|[/$$] # Domain Name System (DNS) - type: markdown + id: 25 # (generated) front: Aus welchen *drei* wesentlichen Kompontenten besteht DNS? back: | 1. **Domain Namespace** 2. **Nameserver** 3. **Resolver** - type: markdown + id: 26 # (generated) front: Was ist ein FQDN? back: | Ein **F**ully **Q**ualified **D**omain **N**ame besteht aus einer Sequenz von Labels vom Knoten und endet an der Wurzel mit einem Punkt: `tum.de.` - type: markdown + id: 27 # (generated) front: Erläutere den Unterschied zwischen *Resolver* und *Nameserver*? back: | - type: markdown + id: 28 # (generated) front: Welche Funktionen erfüllen `d.root-servers.net` und `a.gtld-servers.net`? back: | - type: markdown + id: 29 # (generated) front: Was macht ein DNS **Resolver**? back: | Dienst der durch **Anfragen an Nameserver** Informationen aus dem Namespace extrahiert, **zwischenspeichert** und Clients zu Verfügung stellt. - type: markdown + id: 30 # (generated) front: Was macht ein DNS **Nameserver**? back: | - speichern Informationen über den Namensraum - jeder Server kennt nur kleine Ausschnitte des Namensraums (**Zonen**) - type: markdown + id: 31 # (generated) front: Was ist der Well-Known Port für DNS? back: | 53 - type: markdown + id: 32 # (generated) front: Finden Zone Transfers über UDP oder TCP statt? back: | TCP - type: markdown + id: 33 # (generated) front: Nenne Beispiele für DNS **Resource Records** back: | - SOA @@ -169,29 +206,36 @@ cards: - TXT - PTR - type: markdown + id: 34 # (generated) front: Was machen der A und AAAA DNS **Resource Record** back: | Assoziieren einen FQDN mit einer IPv4 bzw. IPv6-Adresse - type: markdown + id: 35 # (generated) front: Was sind **MX** Resource Records? back: | Geben den FQDN eines Mailservers an - type: markdown + id: 36 # (generated) front: Was sind **SOA** Resource Records? back: | **S**tart **o**f **A**uthority Records geben den Wurzel der Zone an, für die ein Nameserver autoritär ist. - type: markdown + id: 37 # (generated) front: Was sind **NS** Resource Records? back: | Geben den FQDN eines Nameservers an - type: markdown - front: Was passiert, wenn der autoritativer Nameserver für `example.org` `ns.example.org` ist? + id: 38 # (generated) + front: Was passiert, wenn der autoritativer Nameserver für `example.org` `ns.example.org` + ist? back: | Um `ns.example.org` aufzulösen muss eine Anfrage an den autoritativen Nameserver für `example.org` abgeschickt werden. Es tritt eine **zirkuläre Abhängigkeit** auf. Eine **Lösung** sind **Glue-Records** in der DNS Zone der Eltern-Domäne (Hier `.org`). - type: markdown + id: 39 # (generated) front: | Beschreibe den folgenden **SOA** Record von `grnvs.net`: @@ -204,10 +248,12 @@ cards: - **Expire** Feld: Lebensdauer einer Kopie - **NXDomain** Feld: Cache Lebensdauer für Resolver - type: markdown + id: 40 # (generated) front: Woher weiß ein Resolver, wo er anfangen soll? back: | Statische Liste der Root Server, die für die Root-Zone autoritativ sind. - type: markdown + id: 41 # (generated) front: Was versteht man unter **Reverse DNS**? back: | Im DNS können über **PTR Records** auch FQDNs für IP-Adressen hinterlegt werden. @@ -215,48 +261,57 @@ cards: - `in-addr.arpa.` für IPv4 - `ip6.arpa.` für IPv6 - type: markdown + id: 42 # (generated) front: Welche Einschränkungen ergeben sich für den Namespace unterhalb von `in-addr.arpa.`? back: | - Da jede Ebene einem ganzen Oktett entspricht, gibt es **maximal vier Ebenen** - Subnetze, deren Präfixlänge nicht 8, 16, 24, oder 32 ist, können nicht in getrennten Zonen gespeichert werden - type: markdown + id: 43 # (generated) front: Was sind getrennte Zonen im Namespace unterhalb von `in-addr.arpa.`? back: | Getrennte Zonen entsprechen einzelne IP-Adressen. - type: markdown + id: 44 # (generated) front: Erläutere, wie der IPv4-Adressbereich in den DNS Namespace eingebettet wird. back: | IPv4-Adressen werden oktett-weise in umgekehrter Reihenfolge als Labels interpretiert und unterhalb des FQDNs `in-addr.arpa.` gespeichert. - type: markdown + id: 45 # (generated) front: Was ist der FQDN für `8.8.4.4` im Reverse DNS? back: | `4.4.8.8.in-addr.arpa.` Dieser zeigt wiederum auf `dns.google.` - type: markdown + id: 46 # (generated) front: Wofür steht URL? back: | **U**niform **R**esource **L**ocator - type: markdown + id: 47 # (generated) front: Was enthält eine HTTP **Request**? back: | - Methode (z.B. `GET`, `HEAD`, `PUT`, `POST`, etc.) - URL - Weitere Header (`Host`, `User-Agent`, etc.) - type: markdown + id: 48 # (generated) front: Was enthält eine HTTP **Response**? back: | - Status-Line (z.B. `200 OK`) - Response Header - (Abhängig von der Methode) Body - type: markdown + id: 49 # (generated) front: Was ist der Unterschied zwischen HTTP `PUT` und `POST`? back: | - **PUT**: Objekt überschreibt ggf. ein bereits existierendes Objekt - **POST**: Objekt wird ggf. an ein bereits existierendes Objekt angehängt - type: markdown + id: 50 # (generated) front: Wie ist FTP aufgebaut? back: | - Nutzt **zwei** getrennte TCP-Verbindungen @@ -264,14 +319,17 @@ cards: 2. Datenkanal - Kontrollkanal bleibt über *mehrere* Datentransfers hinweg bestehen - type: markdown + id: 51 # (generated) front: Ist FTP stateful? back: | Ja! Der Kontrollkanal bleibt über *mehrere* Datentransfers hinweg bestehen. - type: markdown + id: 52 # (generated) front: Was ist der Unterschied zwischen FTP *active mode* und *passive mode*? back: | - **Active Mode**: Client teilt mittels des `PORT`-Kommandos dem Server eine zufällige Portnummer mit - **Passive Mode**: Client teilt mittels `PASV`- - type: markdown + id: 53 # (generated) front: Was ist das Problem mit FTP active mode und NAT? - back: | \ No newline at end of file + back: | diff --git a/IN0010_GRNVS/transportschischt.yaml b/IN0010_GRNVS/transportschischt.yaml index 85f9120..7ff07f2 100644 --- a/IN0010_GRNVS/transportschischt.yaml +++ b/IN0010_GRNVS/transportschischt.yaml @@ -3,17 +3,20 @@ author: Hugo Melder id: 247835429 cards: - type: markdown + id: 0 # (generated) front: Was ist sind die wesentlichen Aufgaben der Transportschicht? back: | - **Multiplexing** von Datenströmen unterschiedlicher Anwendungen. - Bereitstellung **verbundsloser** und **verbindungsorientierter** Transportmechanismen - **Stau-** und **Flusskontrolle** - type: markdown + id: 1 # (generated) front: Welche Art von Transportdiensten haben wir kennengelernt? back: | - **Verbindungslos** - **Verbindungsorientiert** - type: markdown + id: 2 # (generated) front: Was zeichnet einen *verbindungslosen* Transportdienst aus? back: | - **Segmente** sind aus Sicht der Transportschicht voneinander **unabhängig** @@ -21,45 +24,55 @@ cards: - Keine Übertragungswiederholung - Kein Reordering von Segmenten - type: markdown + id: 3 # (generated) front: Was zeichnet einen *verbindungsorientierten* Transportdienst aus? back: | - Übertragungswiederholung bei Fehlern - Garantie der richtigen Reihenfolge einzelner Segmente - type: markdown + id: 4 # (generated) front: Unterscheide Stau- und Flusskontrolle back: | - **Staukontrolle** (Congestion Control): *Reaktion* auf drohende Überlast **im Netz** - **Flusskontrolle** (Flow Control): Laststeuerung durch den Empfänger - type: markdown + id: 5 # (generated) front: Warum werden `sendto()` und `recvfrom()` für verbindungslose Sockets benötigt? back: | Es werden Adressangaben benötigt. - type: markdown - front: Was sind die Mindestanforderungen an den Header eines *verbindungslosen* Transportprotokols? + id: 6 # (generated) + front: Was sind die Mindestanforderungen an den Header eines *verbindungslosen* + Transportprotokols? back: | - Quell- und Zielport - Längenangabe der Nutzdaten - type: markdown + id: 7 # (generated) front: Mit welchem Präprozessormakro werden verbindungslose POSIX-Sockets identifiziert? back: | `SOCK_DGRAM`, wobei `DGRAM` für **Datagram* steht. - type: markdown + id: 8 # (generated) front: Was sind Vorteile von UDP? back: | - Geringer Overhead - Keine Verzögerung durch Verbindungsaufbau, Retransmits und ReorderingVorteile - Keine Beeinflussung der Datenrate durch Fluss- und Staukontrollmechanismen - type: markdown + id: 9 # (generated) front: Was sind Nachteile von UDP? back: | - Kein Zusicherung von Dienstqualität - Out-of-Order Delivery - Keine Fluss- oder Staukontrolle - type: markdown + id: 10 # (generated) front: Was ist die grundlegende Idee einer verbindungsorientierten Übertragung? back: | Linear durchnummerierte Segemnete mittels **Sequenznummern** im Protokolheader. - type: markdown + id: 11 # (generated) front: Was ermöglichen Sequenznummern? back: | - **Bestätigung** erfolgreich übertragener Segmente @@ -67,96 +80,120 @@ cards: - **erneutes Anfordern** fehlender Segmente - **Zusammensetzen** der Segmente in **richtiger Reihenfolge** - type: markdown + id: 12 # (generated) front: Was ist die Voraussetzung für die Verwendung von Sequenznummern? back: | Sender und Empfänger müssen sich **synchronisieren** und **Zustand halten**. - type: markdown + id: 13 # (generated) front: Welchen Einfluss können Fenstergrößen beim Sliding-Window-Verfahren haben? back: | - Empfänger kann die Datenrate steuern (Flusskontrolle) - Anpassung an die verfügbare Datenrate auf dem Übertragungspfad (Staukontrolle) - type: markdown - front: Welche zwei Möglichkeiten gibt es beim Sliding-Window-Verfahren, um mit Segmentverlusten umzugehen? + id: 14 # (generated) + front: Welche zwei Möglichkeiten gibt es beim Sliding-Window-Verfahren, um mit Segmentverlusten + umzugehen? back: | - **Go-Back-N**: - **Selective-Repeat**: - type: markdown + id: 15 # (generated) front: Wie funktioniert **Go-Back-N**? back: | - Akzeptiert stets nur die nächste erwartete Sequenznummer - Alle anderen Segmente werden verworfen - type: markdown + id: 16 # (generated) front: Wie funktioniert **Selective-Repeat**? back: | - Akzeptiert alle Sequenznummern, die in das aktuelle Empfangsfenster fallen - Diese müssen gepuffert werden, bis fehlende Segmente erneut übertragen wurden - type: markdown + id: 17 # (generated) front: Was muss für das Sendefenster bei **Go-Back-N** stets gelten? back: | [$$]w_s \leq N - 1[/$$] - type: markdown + id: 18 # (generated) front: Was muss für das Empfangsfenster bei **Go-Back-N** gelten? back: | Da nur das nächste erwartete Segment akzeptiert wird, reicht ein Empfangsfenster der Größe [$]w_r = 1[/$] aus. - type: markdown + id: 19 # (generated) front: Was muss für das Sendefenster bei **Selective-Repeat** stets gelten? back: | [$$]w_s \leq \left\lfloor \frac{N}{2} \right\rfloor[/$$] - type: markdown + id: 20 # (generated) front: Was muss für das Empfangsfenster bei **Selective-Repeat** stets gelten? back: | [$$]w_s \leq w_r \leq \left\lfloor \frac{N}{2} \right\rfloor[/$$] - type: markdown # Transport Control Protocol (TCP) + id: 21 # (generated) front: Wie wird der TCP Handshake auch bezeichnet? back: 3-Way-Handshake - type: markdown + id: 22 # (generated) front: Wofür ist das `Offset` Feld im TCP Header da? back: | Gibt Länge des *Headers* in Vielfachen von 4B an. - type: markdown + id: 23 # (generated) front: Wofür wird das `ACK`-Flag verwendet? back: | Ist das Flag gesetzt, handelt es sich um eine **Empfangsbestätigung**. - type: markdown - front: Kann eine Empfangsbestätigung in TCP auch mit weiteren Nutzdaten kombiniert werden? + id: 24 # (generated) + front: Kann eine Empfangsbestätigung in TCP auch mit weiteren Nutzdaten kombiniert + werden? back: | Ja. Dabei wird `ACK` und die Acknowledgement Number entsprechend gesetzt. - type: markdown + id: 25 # (generated) front: Was gibt die Acknowledgement-Number bei TCP an? back: | Das **nächste erwartete** Byte. - type: markdown + id: 26 # (generated) front: Wann ist das `PSH`-Flag sinnvoll? back: | Für interaktive Anwendungen. - type: markdown + id: 27 # (generated) front: Welche Bedeutung hat ein gesetztes `PSH` flag? back: | Sende- und empfangsseitige Puffer des TCP-Stacks werden umgangen. - type: markdown + id: 28 # (generated) front: Wann wird das `RST`-Flag gesetzt? back: | Bei Abbruch einer TCP-Verbindung ohne ordnungsgemäßen Verbindungsabbau. - type: markdown + id: 29 # (generated) front: Welche Besonderheit haben das `SYN` und `FIN`flag? back: | Ein gesetztes `SYN`/`FIN`-Flag inkrementiert Sequenz- und Bestätigungsnummern um 1, obwohl keien Nutzdaten transportiert werden. - type: markdown + id: 30 # (generated) front: Was ist das `Receive Window` Feld bei TCP? back: | Größe des aktuellen Empfangsfenster in Byte - type: markdown - front: Was gibt die **MSS** an? + id: 31 # (generated) + front: Was gibt die **MSS** an? back: | Maximale Größe eines TCP-Segments (Nutzdaten ohne TCP-Header) an. - type: markdown + id: 32 # (generated) front: Wie sollte die MSS gewählt werden? back: | MSS sollte so gewählt werden, dass **keine IP-Fragmentierung beim Senden** stattfindet. - type: markdown + id: 33 # (generated) front: | Was ist die maximale MSS bei folgender Konfiguration, sodass keine Fragmentierung auftritt? - MTU: 1500B @@ -165,6 +202,7 @@ cards: back: | 1500B - 20B - 20B = 1460B - type: markdown + id: 34 # (generated) front: | Was ist die maximale MSS bei folgender Konfiguration, sodass keine Fragmentierung auftritt? - MTU: 1500B @@ -174,41 +212,51 @@ cards: back: | 1500B - 8B - 20B - 20B = 1452B - type: markdown + id: 35 # (generated) front: Wie wird die **Flusskontrolle** bei TCP realisiert? back: | - Empfänger teilt dem Sender über das `Receive Window` Feld die *aktuelle* Größe des Empfangsfensters mit - Sender interpretiert dies als die **maximale Anzahl an Bytes**, die ohne ein ACK übertragen werden dürfen - type: markdown + id: 36 # (generated) front: Wie kann bei TCP die Übertragungsrate des Senders gedrosselt werden? back: | Indem der Empfänger das `Receive Window` (im nächsten `ACK`) herabsetzt. - type: markdown + id: 37 # (generated) front: Ist das **Staukontrollfenster** im TCP Header zu finden? back: | Nein. Das Staukontrollfenster wird intern von Sender verwaltet. - type: markdown + id: 38 # (generated) front: Wann wird das Staukontrollfenster vergrößert? back: | Solange Daten verlustfrei übertragen werden. - type: markdown + id: 39 # (generated) front: Wann wird das Staukontrollfenster verkleinert? back: | Wenn Verluste bei der Übertragung auftreten. - type: markdown + id: 40 # (generated) front: Was gilt für das tatsächliche Sendefenster? back: | [$]w_s = \min\{ w_c, w_r\}[/$] - type: markdown - front: Zwischen welchen zwei Phasen der Staukontrolle wird bei TCP grundsätzlich unterschieden? + id: 41 # (generated) + front: Zwischen welchen zwei Phasen der Staukontrolle wird bei TCP grundsätzlich + unterschieden? back: | 1. **Slow-Start** 2. **Congestion Avoidance** - type: markdown + id: 42 # (generated) front: Was passiert in der **Slow-Start** Phase bei der TCP Staukontrolle? back: | - Für **jedes** bestätigte **Segment** wird das **Congestion Window um eine MSS vergrößert**. - Bis **Congestion Threshold** erreicht ist. - type: markdown + id: 43 # (generated) front: Warum wächst das Congestion Window in der Slow-Start Phase expoentiell? back: | Wenn wir das Congestion Window (cwnd) als k * MSS betrachten und **für jedes bestätigte @@ -216,12 +264,14 @@ cards: [$$]W_c = 2^n * W_c0[/$$], wobei [$]n[/$] die Anzahl an RTs ist. - type: markdown + id: 44 # (generated) front: Wer setzt den initialen Slow-Start Threshold (sstresh)? back: | Der sstresh ist Abhängig von der TCP Implementierung, wird aber meistens zu einem großen vorgegebenen Wert, oder dem `receive window` des Empfängers gesetzt. - type: markdown + id: 45 # (generated) front: Beschreibe die **Congestion Avoidance** Phase bei TCP! back: | Für jedes bestätigte Segment wird das cwnd jediglich um (1/cwnd) MSS vergrößert. @@ -229,11 +279,13 @@ cards: Damit ein **lineares Wachstum**. - type: markdown + id: 46 # (generated) front: Welche zusätzlichen Funktionen hat **TCP Reno**? back: | - 3 duplizierte Bestätigungen (Duplicate ACKs) - Timeout - type: markdown + id: 47 # (generated) front: Was versteht man unter "3 duplizierte Bestätigungen" bei TCP Reno back: | Wenn drei duplizierte Bestätigungen vom Empfänger gesendet werden: @@ -241,6 +293,7 @@ cards: 2. Reduziere `cwnd` auf `sstresh` 3. Beginne mit Congestion Avoidance Phase - type: markdown + id: 48 # (generated) front: Was versteht man unter der "Timeout" bei TCP Reno back: | Wenn ein Timeout beim Senden auftritt: @@ -248,6 +301,7 @@ cards: 2. Setze `cwnd` = 1 MSS 3. Beginne mit neuem Slow Start - type: markdown + id: 49 # (generated) front: | Wie groß muss das Sendefenster (gemessen in Byte) gewählt werden, damit *kontinuierlich* gesendet werden kann? @@ -257,26 +311,33 @@ cards: [$$]w_s \geq \text{RTT} \cdot r[/$$], wobei r die Bitrate. # Network Address Translation (NAT) 4-36 - type: markdown + id: 50 # (generated) front: Müssen IP-Adressen immer **eindeutig** sein? back: | Nein. z.B. wenn - Kommunikation zum Internet nicht bestehen muss (isoliertes Internet) oder - die nicht eindeutigen **privaten IP-Adressen** auf geeignete Weise **in öffentliche Adressen übersetzt werden** - type: markdown + id: 51 # (generated) front: Definiere NAT. back: | **N**etwork **A**ddress **T**ranslation sind Techniken zur Übersetzung von [$]N \geq 1[/$] auf [$]M \geq 1[/$] andere IP-Adressen. - type: markdown - front: Wie funktioniert die Übersetzung von N **privaten** und M **öffentlichen** IP-Adressen bei [$]N \leq M[/$]? + id: 52 # (generated) + front: Wie funktioniert die Übersetzung von N **privaten** und M **öffentlichen** + IP-Adressen bei [$]N \leq M[/$]? back: | Jeder privaten IP-Adresse wird mind. eine öffentliche IP-Adresse zugeordnet. - type: markdown - front: Wie funktioniert die Übersetzung von N **privaten** und M **öffentlichen** IP-Adressen bei [$]N > M[/$]? + id: 53 # (generated) + front: Wie funktioniert die Übersetzung von N **privaten** und M **öffentlichen** + IP-Adressen bei [$]N > M[/$]? back: | **Port-Multiplexing**. Wir assoziieren öffentliche Ports mit einer privaten IP-Adresse und einem privaten Port (muss nicht gleich sein). - type: markdown + id: 54 # (generated) front: Was sind die vier privaten Adressbereiche bei IPv4? back: | - `10.0.0.0/8` @@ -284,26 +345,31 @@ cards: - `169.254.0.0/16` - `192.168.0.0/16` - type: markdown + id: 55 # (generated) front: Wie viele Einträge kann eine NAT-Tabelle fassen? back: | 2^16 pro Transportprotokoll (TCP und UDP) und pro globaler IP-Adresse. - type: markdown + id: 56 # (generated) front: | Was ist, wenn das Transportprotokoll keine Portnummern hat oder IP-Pakete ohne TCP-/UDP-Header verschickt werden, z. B. ICMP? back: | Die ICMP-ID kann anstelle der Portnummern genutzt werden. - type: markdown + id: 57 # (generated) front: Was repräsentiert `struct in_addr`? back: | Eine IPv4-Adresse in Network Byte Order. - type: markdown + id: 58 # (generated) front: | Wie kann eine `struct sock_addr_in local;` Instanz konfiguriert werden, damit von allen lokal konfigurierten Interfaces empfangen werden kann? back: | `local.sin_addr.s_addr = htonl(INADDR_ANY);` - type: markdown + id: 59 # (generated) front: Was macht `socket(AF_INET ,SOCK_DGRAM ,IPPROTO_UDP)`? back: | Es wird ein neuer Socket vom Typ: @@ -311,20 +377,24 @@ cards: - `SOCK_DGRAM`: Datagram-oriented Socket - `IPPROTO_UDP`: UDP - type: markdown + id: 60 # (generated) front: Was macht `bind()`? back: | Assoziiert einen File Descriptor mit den zugehörigen Adressinformationen (Meistens Adresse und Port). - type: markdown + id: 61 # (generated) front: Welche Möglichkeiten gibt es bei Linux, einen Socket zu überwachen? back: | - `read()` auf dem Socket - `select()` oder `pselect()` - `epoll()` - type: markdown + id: 62 # (generated) front: Was ist das Problem von `read()`? back: | `read()` blockiert, solange bis etwas kommt. - type: markdown + id: 63 # (generated) front: Wie funktioniert `select()`? back: | 1. Alle zu überwachenden File Descriptors kommen in `fd_set`s @@ -332,46 +402,57 @@ cards: 3. Passiert etwas, **modifiziert** `select()` die `fd_set`s, so dass es genau die FDs enthält, die bereit sind 4. Rückgabewert ist die Anzahl bereitgewordener FDs oder -1 und `errno` gesetzt. - type: markdown + id: 64 # (generated) front: Warum gibt es `epoll()`? back: | Bei einer großen Anzahl von FDs wird `select()` ggf. ineffizient. - type: markdown + id: 65 # (generated) front: Gegeben `fd_set rfds, rfd;` wie kann `rfds` mit 0 intialisiert werden? back: | `FD_ZERO(&rfds` - type: markdown + id: 66 # (generated) front: Gegeben `fd_set rfds, rfd;` wie kann ein FD zu `rfds` hinzugefügt werden? back: | `FD_SET(fd, &rfds);` - type: markdown + id: 67 # (generated) front: Wie werden FD sets typischerweise Implementierung? back: | Als Bitvektoren. - type: markdown + id: 68 # (generated) front: | Wie muss das erste Argument `nfds` bei `select()` gesetzt werden, wenn wir zwei FDs (4 und 17) in einem FD set haben? back: | `nfds = max(4, 17) + 1`, da `select()` alle FDs von 0 bis `nfds - 1` inspiziert. - type: markdown - front: Welches Problem entsteht, wenn wir `read()`oder `recv()` auf verbindungslosen Sockets verwenden? + id: 69 # (generated) + front: Welches Problem entsteht, wenn wir `read()`oder `recv()` auf verbindungslosen + Sockets verwenden? back: | Wir werden so nie erfahren, wer uns etwas geschickt hat. Dafür gibt es `sendto()` und `recvfrom()`. - type: markdown + id: 70 # (generated) front: Wie unterscheiden sich `recvfrom()` und `recv()`? back: | Wir können `recvfrom()` einen Pointer zu einem Speicherbereich der Größe `sizeof(struct sockaddr_in)` übergeben, um Information über den Sender zu bekommen (hier IPv4). - type: markdown + id: 71 # (generated) front: Wofür wird `connect()` bei einem verbindungsorientierten Socket benutzt? back: | Verbinden mit einem entfernten Host. - type: markdown - front: Was macht ein Aufruf zu `listen()` bei einem verbindungsorientierten Socket? + id: 72 # (generated) + front: Was macht ein Aufruf zu `listen()` bei einem verbindungsorientierten Socket? back: | Markiert den Socket als **passiv**. Socket versendet **keine** Daten, sondern erwartet eingehende Verbindungen. - type: markdown + id: 73 # (generated) front: | Warum sind bei verbindungsorientierten Sockets `recv()` und `send()` `read()` und `write()` zu bevorzugen? @@ -379,13 +460,15 @@ cards: Hier werden bestimmte Ausnahmen wie eine abgebrochene Verbindung *sinnvoll* signalisiert. # Codedemos - type: markdown + id: 74 # (generated) front: Was sind Einschränkungen der vorgestellten UDP-Chat Codedemo? back: | - Nur 1:1 Chats - Fremde können einem der beiden Chatpartner ebenfalls Nachrichten senden (antworten aber nicht möglich) - type: markdown + id: 75 # (generated) front: Was ist bei dem UDP-basierten IRC möglich? back: | - N:N chats - Zusammenarbeit mit den unmodifizierten UDP-Chat Clients. -# TODO: Vorteile und Nachteile \ No newline at end of file +# TODO: Vorteile und Nachteile diff --git a/IN0010_GRNVS/vermittlungsschicht.yaml b/IN0010_GRNVS/vermittlungsschicht.yaml index 397c09d..cbd8796 100644 --- a/IN0010_GRNVS/vermittlungsschicht.yaml +++ b/IN0010_GRNVS/vermittlungsschicht.yaml @@ -3,98 +3,119 @@ author: Hugo Melder id: 6645562923 cards: - type: markdown + id: 12 # (generated) front: Was sind die *drei* grundlegenden **Vermittlungsarten**? back: | 1. **Leitungsvermittlung** 2. **Nachrichtenvermittlung** 3. **Paketvermittlung** - type: markdown + id: 14 # (generated) front: Was versteht man unter **Leitungsvermittlung**? back: | Reserviere eine **dedizierte Leitung** zwischen Sender und Empfänger - type: markdown + id: 15 # (generated) front: Was versteht man unter **Nachrichtenvermittlung**? back: | Wähle für jede Nachricht individuell einen Weg und leite die Nachricht als Ganzes weiter. - type: markdown + id: 16 # (generated) front: Was versteht man unter **Paketvermittlung**? back: | Teile eine Nachricht in mehrere kleinere Pakete auf und versende jedes Paket unabhängig von den anderen. - type: markdown + id: 17 # (generated) front: Wie funktioniert Multiplexing auf Paketebene? back: | Jedes Paket wird **unabhängig** voneinander vermittelt. Adressierung im Paketheader. [[image: paket_multiplexing.png]] - type: markdown + id: 18 # (generated) front: Nenne Vorteile von Multiplexing auf Paketebene. back: | - Flexibles Zeitmultiplex einzelner Pakete - Pufferung kleiner Pakete statt ganzer Nachrichten - type: markdown + id: 19 # (generated) front: Nenne Nachteile von Multiplexing auf Paketebene. back: | - Verlust von Paketen durch begrenzten Puffer möglich - Jedes Paket benötigt seinen eigenen Header (Overhead) - Empfänger muss Pakete wieder zusammensetzen - type: markdown + id: 20 # (generated) front: In welche drei Phasen unterteilt man eine Übertragung bei Leitungsvermittlung? back: | 1. **Verbindungsaufbau**: u.A. Wegwahl 2. **Datenaustausch**: Exklusive Nutzung des Kanals 3. **Verbinungsabbau** - type: markdown + id: 21 # (generated) front: Was sind Vorteile der Leitungsvermittlung? back: | - Gleichbleibende Güte - Schnelle Datenübertragung ohne Vermittlungsentscheidungen - type: markdown + id: 22 # (generated) front: Was sind Nachteile der Leitungsvermittlung? back: | - Resourcenverschwendung - Verbindungsaufbau kann komplex sein - type: markdown - front: Was ist der wesentliche Unterschied zwischen Adressierung auf Schicht 2 und Schicht 3? + id: 23 # (generated) + front: Was ist der wesentliche Unterschied zwischen Adressierung auf Schicht 2 und + Schicht 3? back: | Schicht 3 bietet eine global-eindeutige, logische Adressierung über mehrere Direktverbindungsnetze hinweg. # IPv4 - type: markdown + id: 24 # (generated) front: Was ist das IHL Feld im IPv4 Header? back: | **I**nternet **H**eader **L**ength Feld gibt die Länge des IP Headers inkl. Optionen in Vielfachen von 4B an. - type: markdown + id: 25 # (generated) front: Was gibt das **Total Length** Feld im IPv4 Header an? back: | Gesamtlänge des IP-Pakets (Header + Payload) in Bytes. - type: markdown + id: 26 # (generated) front: Was ist die **MTU**? back: | Die **M**aximum **T**ransmission **U**nit ist die *maximale* Paketlänge, so dass keine Fragmentierung notwendig ist. - type: markdown + id: 27 # (generated) front: Wofür wird das Identification Feld im IPv4 Header verwendet? back: | Dient der Identifikation zusammengehörender Fragmente. Es wird zufällig gewählt. - type: markdown + id: 28 # (generated) front: Was sagt ein gesetztes **Don't Fragment (DF)** Flag im IPv4 Header aus? back: | IP-Paket darf nicht fragmentiert werden. - type: markdown + id: 29 # (generated) front: Was sagt das **More Fragments** Flag im IPv4 Header aus? back: | - Weitere Fragmente folgen (1) - Dieses Paket ist das letzte Fragment (0) - type: markdown + id: 30 # (generated) front: Was ist das **Fragment Offset** Feld im IPv4 Header? back: | Gibt die **absolute Position** der Daten in diesem Fragment an. Vielfaches von 8B. - type: markdown + id: 31 # (generated) front: Wie behandelt ein Router das TTL Feld eines IPv4 Pakets? back: | - Er dekrementiert das TTL-Feld um 1 - Verwirft das Paket wenn TTL = 0 und sendet ICMP Time Exceeded an Absender # Address Resolution Protocol (ARP) - type: markdown + id: 32 # (generated) front: | Problem: Ein Host will eine Nachricht an einen anderen Host (im gleichen Subnetz) senden, kennt aber nur die IP-Adresse. Wie kann die zugehörige @@ -102,16 +123,19 @@ cards: back: | Der Host kann eine ARP Request schicken. - type: markdown + id: 33 # (generated) front: An welche MAC-Adresse wird eine ARP-Request geschickt? back: | Der MAC-Broadcast-Adresse `ff:ff:ff:ff:ff:ff` # Dynamic Host Configuration Protocol (DHCP) - type: markdown + id: 34 # (generated) front: Woher bekommen Hosts ihre IP-Adresse? back: | - Statische Konfiguration von Hand - Dynamisch von einem **DHCP-Server** zugewiesene IP-Adresse - type: markdown + id: 35 # (generated) front: Wie bekommt ein Client eine IP-Adresse von einem DHCP Server? back: | 1. Client sendet DHCP-Discover (L2 Broadcast) @@ -120,6 +144,7 @@ cards: 4. DHCP-Server antwortet mit **DHCP-ACK** oder **DHCP-NACK** # CIDR - type: markdown + id: 36 # (generated) front: Wie funktioniert **CIDR** für IPv4? back: | - Zusätzlich zur IP-Adresse gibt es eine 32-bit lange **Subnetzmaske** @@ -127,10 +152,12 @@ cards: - Logische 1: Netzanteil - Logische 0: Hostanteil - type: markdown + id: 37 # (generated) front: Was resultiert aus einer UND-Verknüpfung von IP-Adresse und Subnetzmaske? back: | Netzadresse - type: markdown + id: 38 # (generated) front: | `192.168.0.128` mit 25-bit Netzanteil und 7-bit Hostanteil. @@ -140,11 +167,13 @@ cards: 192.168.0.255 ist die Broadcast-Adresse - type: markdown + id: 39 # (generated) front: Was ist die IPv4 Global Broadcast Adresse? back: | `255.255.255.255/32` # IPv6 - type: markdown + id: 40 # (generated) front: Gebe die vier Schritte an, wie man korrekt eine IPv6 Adresse kürzt. back: | - Führende Nullen in jedem 16-bit Feld werden unterdrückt `2001:0db8::0001:0000` => `2001:db8::1:0`) @@ -152,15 +181,18 @@ cards: ausgetauscht. Wenn mehrere Felder gleicher Größe vorliegen, wird das erste (von Links) gekürzt. (`2001:db8:0:0:1:0:0:1` => `2001:db8::1:0:0:1`) - type: markdown + id: 41 # (generated) front: Wofür ist das **Payload Length** Feld im IPv6 Header da? back: | Länge des Headers und Payload. In Vielfachen von 1B. - type: markdown + id: 42 # (generated) front: Wofür ist das **Next Header** Feld im IPv6 Header da? back: | - Gibt den Typ des nächsten Headers an, der am Ende des IPv6-Headers folgt - **L4-Header** oder **IPv6 Extension Header** - type: markdown + id: 43 # (generated) front: | Angenommen wir haben einen Routing Header, Fragment Header und TCP Payload unter dem IPv6 Header. Wie sehen die jeweiligen **Next Header** Felder aus? @@ -169,19 +201,23 @@ cards: - Routing Header, Next Header: Fragment - Fragment Header, Next Header: TCP - type: markdown + id: 44 # (generated) front: Was ist das **Fragment Offset** Feld im IPv6 Fragment (Extension) Header? back: | - Offset der fragmentierten L3-SDU in Vielfachen von 8B - type: markdown + id: 45 # (generated) front: Wo erfolgt bei IPv6 die Fragmentierung? back: | - *Ausschließlich* am Sender + *Ausschließlich* am Sender - type: markdown + id: 46 # (generated) front: Wo erfolgt bei IPv4 die Fragmentierung? back: | Falls nicht explizit über das DF-Bit untersagt, können Pakete bei Bedarf auch von Routern fragmentiert werden. - type: markdown + id: 47 # (generated) front: Welche vier Adressierungsarten gibt es auf Schicht 3 und 2? back: | - Unicast @@ -189,56 +225,67 @@ cards: - Multicast - Anycast - type: markdown + id: 48 # (generated) front: Wie funktioniert eine **Unicast** Adressierung? back: | **Unicast** identifiziert *genau* ein Network Interface - type: markdown + id: 49 # (generated) front: Wie funktioniert eine **Anycast** Adressierung? back: | **Anycast** identifiziert eine *Gruppe* von Network Interfaces. Packet wird zum nächsten (abhängig vom Routing Protokoll) Host geschickt. Können nicht einfach erkannt werden. - type: markdown + id: 50 # (generated) front: Wie funktioniert eine **Multicast** Adressierung bei IPv6? back: | Packet wird an eine Multicast-Gruppe adressiert - type: markdown + id: 51 # (generated) front: Wie funktioniert eine **Broadcast** Adressierung bei IPv6? back: | Nicht implementiert! Kann mittel *all-nodes* link-local multicast group `ff02::1` nachgeahnt werden, wird aber nicht empfohlen. - type: markdown + id: 52 # (generated) front: Wofür werden Solicited-Node Multicast Adressen bei IPv6 verwendet? back: | Wird u.A. benutzt, um effizient das Neighbor Discovery Protocol (NDP) in IPv6 zu implementieren. Statt L2 Broadcast wird die eine MAC Adresse konstruiert. - type: markdown + id: 53 # (generated) front: Wie wird eine Multicast IPv6 Adresse auf eine MAC-Adresse gemapped? back: | IPv6-Pakete aus Präfix `ff00::/8` werden mit folgener MAC Adresse gesendet: - Ersten 2 Oktette der MAC Adresse werden auf `33:33` gesetzt (Multicast, Locally Administered) - Die letzten 4 Oktette sind die letzten 4 Oktette der IPv6 Multicastadresse - type: markdown + id: 54 # (generated) front: Wie ist eine Solicited-Multicast IPv6 Adresse aufgebaut? back: | Die Adresse wird konstruiert, in dem die letzten 24-bit der IPv6 Adresse an den Prefix `ff02::1:ff00:0/104` angehangen werden. # Stateless Adress Autoconfiguration - type: markdown + id: 55 # (generated) front: Wofür steht SLAAC? back: | **S**tateless **A**ddress **A**uto**c**onfiguration - type: markdown + id: 56 # (generated) front: Welchen Präfix hat eine Link-Local IPv6 Adresse? back: | `fe80::/10` - type: markdown + id: 57 # (generated) front: Wie ist eine LL IPv6 Adresse aufgebaut? back: | - **Präfix**: `fe80::/10` - **Subnet Identifier**: Auf 0 gesetzt - **Interface Identifier**: Modifizierter EUI-64 Indentifier - type: markdown + id: 58 # (generated) front: Wie wird der modifizierte EUI-64 Identifier konstruiert? back: | - Ersten 24-bit sind der OUI der MAC-Adresse @@ -246,42 +293,51 @@ cards: - Nachfolgenden 16-bit werden mit `ff:fe` gestopft - Restlichen 24-bit werden mit dem Device Identifier der MAC-Adresse aufgefüllt. - type: markdown + id: 59 # (generated) front: Warum heißt SLAAC **stateless**? back: | Da die Adressen nicht von einem Server vergeben werden. - type: markdown + id: 60 # (generated) front: Was sind Funktion von IPv6 Neighbor Discovery? back: | - Adressauflösung und Duplicate Address Detection: **Neighbor Solicititations** und **Advertisements** - **Router Discovery** und **Router Advertisements** - **Redirects** - type: markdown + id: 61 # (generated) front: Welche Bedeutung hat das **Router-Flag** (R) bei ICMPv6? back: | Wird gesetzt, wenn der antwortende Knoten ein Router ist. - type: markdown + id: 62 # (generated) front: Welche Bedeutung hat das **Solicited-Flag** (S) bei ICMPv6? back: | Gibt an, ob das Advertisement infolge einer Solicitation geschickt wird. - type: markdown + id: 63 # (generated) front: Welche Bedeutung hat das **Override-Flag** (O) bei ICMPv6? back: | Wird gesetzt, wenn das Advertisement eine möglicherweise gecached Link-Layer Adresse beim Empfänger aktualisieren soll. # Byte Orders - type: markdown + id: 64 # (generated) front: Welche zwei verschiedenen Byte-orders gibt es? back: | - Big Endian - Little Endian - type: markdown + id: 65 # (generated) front: Wie sind Bytes bei Big Endian geordnet? back: | Niederwertigstes Byte steht an höchstwertigster Adresse - type: markdown + id: 66 # (generated) front: Wie sind Bytes bei Little Endian geordnet? back: | Niederwertigstes Byte steht an niederwertigster Adresse - type: markdown + id: 67 # (generated) front: Ist die Network Byte Order Big- oder Little-Endian? back: | Big-Endian @@ -369,16 +425,20 @@ cards: - Path Vector # Autonome Systeme - type: markdown + id: 68 # (generated) front: Was ist ein Autonomes System? back: | Eine Menge von Netzwerken die unter einhaltlicher administrativer Kontrolle stehe. - type: markdown + id: 69 # (generated) front: Wie werden Routen zwischen Autonomen Systemen ausgetauscht? back: | Mit einem **Exterior Gateway Protocol** (EGP). In der Praxis ist es das **Border Gateway Protocol** (BGP). - type: markdown + id: 70 # (generated) front: back: | - type: markdown + id: 71 # (generated) front: - back: | \ No newline at end of file + back: |