Die Fortsetzung zum Oberthema Kryptographie mit Zertifikaten und Zertifizierungsstellen gibt es in der einhunderfünfundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Wiederholung: Für die elektronische Signatur und die Verschlüsselung von Daten werden Paare aus öffentlichen und privaten Schlüsseln benötigt.

Probleme

Wer garantiert dem Absender, dass ein öffentlicher Schlüssel auch wirklich dem angegebenen Empfänger gehört?

Wie kann sichergestellt werden, dass ein öffentlicher Schlüssel nicht von einem Angreifer durch seinen eigenen ausgetauscht wurde?

Zertifikat

Mit einem Zertifikat bestätigt eine unabhängige dritte Partei die Echtheit des öffentlichen Schlüssels des Empfängers. Diese dritte Partei wird Zertifizierungsstelle genannt.

Die Zertifizierungsstelle (englisch Certificate Authority, abgekürzt CA) bestätigt die Authentizität des Schlüssels des Empfängers, indem sie z.B. dessen Adresse und Identität prüft.

Das kostet meistens Geld, je nachdem wie intensiv diese Prüfung gemacht wird. Das geht von "muss eine E-Mail-Adresse mit dieser Domain abrufen können" bis hin zu "das Unternehmen existiert tatsächlich unter der postalischen Adresse".

Wenn Alice statt dem öffentlichen Schlüssel von Bob ein Zertifikat erhält, kann sie es wiederum mit dem Zertifikat der CA prüfen. Sie weiß nun sicher, dass sie den korrekten öffentlichen Schlüssel nutzt und nicht einen kompromittierten.

Alice muss dafür allerdings dem Zertifikat der Zertifizierungsstelle selbst vertrauen, da auch diese kompromittiert werden kann. Es entsteht also eine Vertrauenskette, die irgendwo in einem Root-Zertifikat endet. Und diesem Zertifikat muss manuell vertraut werden.

Das "Urvertrauen" in die verschiedenen CAs wird hergestellt, indem sie z.B. in Browser wie Firefox oder Chrome vom Hersteller fest "eingebaut" und als vertrauenswürdig gekennzeichnet werden.

Sollte ein Zertifikat kompromittiert werden, gibt es sog. Certificate Revocation Lists (CRL), in die die nicht mehr validen Zertifikate eingetragen werden können. Dafür müssen diese Listen aber natürlich bei jeder Prüfung eines Zertifikats kontrolliert werden, was sehr aufwändig ist.

Technische Umsetzung

Zertifikate sind (Plain-Text-)Dateien, die verschiedene technische Informationen enthalten wie z.B. den Namen des Ausstellers, den zertifizierten öffentlichen Schlüssel des Empfängers, ein Ablaufdatum, die elektronische Signatur der ausstellenden CA.

Vereinfacht (!) gesagt, ist das Zertifikat der mit dem privaten Schlüssel der CA signierte öffentliche Schlüssel des Empfängers. Nur mit dem öffentlichen Schlüssel der CA kann diese Signatur geprüft werden. Und dieser öffentliche Schlüssel ist für alle wichtigen CAs im Browser hinterlegt.

Genauer gesagt werden alle Inhalte des Zertifikats signiert und vom öffentlichen Schlüssel des Empfängers nur der Hash. Und im Browser sind auch nicht nur die öffentlichen Schlüssel der CAs hinterlegt, sondern wiederum Zertifikate, die wiederum zertifizert sind usw.

Die Root-Zertifikate am Ende dieser Kette werden dann von der CA selbst signiert und heißen selbstsignierte Zertifikate. Dabei garantiert quasi die CA selbst, dass sie wirklich diese CA ist.

Der Aufbau der Dateien ist standardisiert, z.B. im Format X.509.

Aussteller und Zertifikatinhaber werden durch eine Reihe von Attributen beschrieben, z.B. den sog. Common Name (CN), Land und Ort.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Public-Key-Zertifikat

X.509

Zertifikatsperrliste

Wir gehen ein komplettes Beispiel zur Normalisierung einer relationalen Datenbank durch in der einhundertvierundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Theoretische Grundlagen

Wir normalisieren Datenbanken um Redundanzen zu vermeiden, die zu Anomalien führen können. Mehr dazu in Podcast-Episode 18.

Grundlagen wie Schlüssel, Kardinalitäten usw. erkläre ich in Podcast-Episode 17.

Merksatz: "The key, the whole key, and nothing but the key."

Beispieldaten

Wir verwenden ein "klassisches" Beispiel, das so oder ähnlich in vielen IHK-Prüfungen genutzt wird.

Umfeld: Kunden bestellen Artikel aus verschiedenen Artikelgruppen.

Ein Kunde kann mehrere Bestellungen durchführen. Eine Bestellung wird immer von genau einem Kunden getätigt.

Zu den Kunden werden Name und Adresse erfasst.

Jede Bestellung hat ein Bestelldatum.

In einer Bestellung können mehrere Artikel enthalten sein. Ein Artikel kann auch in mehreren Bestellungen auftauchen.

Artikel haben eine Bezeichnung und einen Preis.

Ein Artikel kann zu genau einer Artikelgruppe gehören. Eine Artikelgruppe kann mehrere Artikel enthalten.

Artikelgruppen haben eine Bezeichnung und einen Rabatt.

Ausgangssituation (nicht normalisiert)

Alle Bestellungen stehen in einer einzelnen Tabelle. Jede Bestellung steht komplett inkl. mehrerer Artikel in einer Zeile. Die Adresse steht komplett in einem einzigen Attribut.

Beispiele für Probleme: Viele Redundanzen (z.B. Adressen, Artikelbezeichnungen), Sortierung nach Ort ist nicht möglich, Selektion aller gekaufter Fernseher ist nicht möglich.

1. Normalform

Definition: Es gibt 1) nur atomare Attribute und 2) keine Wiederholungsgruppen.

"the key": Alle Datensätze sind eindeutig über einen Primärschlüssel identifizierbar.

Durch 2) werden Redundanzen zunächst eingeführt, da aus einer Zeile nun mehrere Zeilen mit redundanten Inhalten werden.

Vorgehen: Nicht-atomare Attribute auf mehrere Spalten aufteilen. Wiederholungsgruppen auf mehrere Zeilen aufteilen.

Ein Datensatz ist über einen zusammengesetzten Schlüssel aus drei Attributen identifizierbar.

Redundanzen: Kunden-, Bestell- und Artikeldaten sind jeweils mehrfach vorhanden.

Ursache: Tabelle enthält drei Konzepte (Kunde, Bestellung, Artikel), die alle nur von Teilen des Schlüssels abhängen und nicht vom gesamten.

2. Normalform

Definition: (1. Normalform erfüllt und) alle Attribute sind voll funktional vom Primärschlüssel abhängig.

"the whole key": Alle Attribute hängen vom gesamten Schlüssel ab (und nicht nur von seinen Teilen).

Vorgehen: Alle drei Konzepte auf einzelne Tabellen aufteilen. Fremdschlüssel für Referenzen einführen. Zuordnungstabelle Position mit zusammengesetztem Schlüssel aus Fremdschlüsseln einführen.

m:n-Beziehungen werden aufgelöst.

Menge gehört an die Kombination aus Bestellung und Artikel und weder an das eine noch das andere allein.

Redundanzen: Artikelgruppe und Rabatt gehören zusammen und sind mehrfach vorhanden.

Ursache: Rabatt hängt von Artikelgruppe ab und nicht von der Artikelnummer (=transitive Abhängigkeit).

3. Normalform

Definition: (2. Normalform erfüllt und) es gibt keine transitiven Abhängigkeiten.

"and nothing but the key": Kein Nicht-Schlüssel-Attribut hängt von einem anderen Nicht-Schlüssel-Attribut ab.

Vorgehen: Artikelgruppe in eigene Tabelle extrahieren und Fremdschlüssel für Referenz einführen.

1:n-Beziehungen werden aufgelöst.

Ergebnis

Jede Tabelle enthält genau ein Konzept.

Keine Daten sind mehr redundant.

In jeder Tabelle gibt es einen eindeutigen Primärschlüssel.

Fremdschlüssel werden für Referenzen auf Datensätze in anderen Tabellen verwendet.

Literaturempfehlungen

Zum Einstieg ins Thema Datenbanken inkl. Modellierung, Normalisierung und SQL empfehle ich Einstieg in SQL* von Michael Laube.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Relationale Datenbanken - Häufige Fragen im Fachgespräch

Normalisierung - Häufige Fragen im Fachgespräch

Normalisierung (Datenbank)

Um Möglichkeiten, Abhängigkeiten in Tests loszuwerden, geht es in der einhundertdreiundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Vorweg: Automatisierte Tests gibt es nicht nur für objektorientierte Software, sondern natürlich auch für funktionale, prozedurale usw. Die folgenden Inhalte beziehen sich aber ausschließlich auf die Objektorientierung. In anderen Paradigmen haben die genannten Begriffe evtl. andere Bedeutungen oder die vorgestellten Lösungen funktionieren etwas anders, da es z.B. keine Polymorphie gibt.

Grundlagen

Automatisierte Tests sollen das Verhalten unseres Systems prüfen und nur fehlschlagen, wenn ein Fehler im Code vorliegt. Sie sollen schnell und wiederholbar sein, damit sie so oft wie möglich ausgeführt werden. Sie sollen immer und überall (auf allen Rechnern/Umgebungen) ausführbar sein.

Unit-Tests prüfen das Verhalten einer einzelnen Komponente, z.B. eine Methode, in Isolation.

Integrationstests prüfen das Verhalten mehrerer Komponenten, z.B. Objekte, im Zusammenspiel.

Integrationstests werden auch Tests genannt, die die Infrastruktur berühren, also z.B. eine Datenbank, das Netzwerk oder das Dateisystem.

Die Infrastruktur sollte in Tests nicht berührt werden, da diese schnell Fehler produziert: erwartete Datenbankinhalte können sich ändern, im Dateisystem fehlen Berechtigungen oder das Netzwerk ist nicht verfügbar.

Die Isolation von Komponenten ist schon in kleinen Systemen nicht immer einfach. Ein Objekt kann seine Aufgaben fast nie komplett allein erledigen, sondern braucht andere Objekte dafür. Ein Service braucht vielleicht ein Repository, um die zu verarbeitenden Daten aus der Datenquelle zu lesen. Ist kein Repository vorhanden, gibt es vielleicht eine NullPointerException beim Aufruf der zu testenden Methode.

Diese Abhängigkeiten machen die Tests schwierig, da das zu testende Objekt nicht korrekt funktioniert, wenn sie nicht vorhanden sind. Somit müssen alle für den konkreten Test benötigten Abhängigkeiten durch diesen bereitgestellt werden.

Somit enthält ein Test nicht nur die eigentlich zu testende Komponente, sondern auch noch ihre Abhängigkeiten. Damit klar ist, welche der verschiedenen Komponenten nun eigentlich getestet werden soll, bekommt sie die Bezeichnung System under test (abgekürzt SUT).

Beim Test können grundsätzlich die "echten" Komponenten verwendet werden, falls dies möglich und sinnvoll ist. Oder die Komponenten werden durch sog. Test Doubles ersetzt, wie ein Stuntdouble den eigentlichen Schauspieler ersetzt.

Test Doubles

Test Doubles sind der Oberbegriff für Komponenten, die in Tests verwendet werden, um die Abhängigkeiten des SUT zu ersetzen. Sie sollen vor allem für vorhersagbare Testergebnisse sorgen, indem z.B. immer die gleichen Werte aus dem Speicher zurückgegeben werden und nicht potentiell unterschiedliche Werte aus der Datenbank gelesen werden.

Damit das Ganze funktioniert, müssen die echten Komponenten durch die Test Doubles ersetzt werden können. In objektorientierter Software kommt dabei die Polymorphie zum Einsatz. Die Abhängigkeiten müssen also z.B. als Interface oder als (abstrakte) Basisklasse vorliegen, damit die Test Doubles anstelle der echten Komponenten genutzt werden können.

Außerdem ist es nötig, dass die Test Doubles dem SUT "untergejubelt" werden können. Es ist also irgendeine Form von Dependency Injection nötig, z.B. Konstruktorparameter oder Setter-Methoden. Sobald das SUT sich selbst seine Abhängigkeiten erzeugt (z.B. mit new), ist ein Test mit Test Doubles schwierig oder gar unmöglich.

Das alles hat auch eine Auswirkung auf den Produktivcode. Denn wenn das SUT eine Abhängigkeit als Konstruktorparameter übergeben bekommen muss, wird auch der Produktivcode die echte Komponente so hineingeben müssen.

Die Tests haben somit indirekt zur Folge, dass der Code insgesamt modularer wird, was die Softwarequalität erhöht.

Zum Erstellen von Test Doubles gibt es verschiedene Frameworks, z.B. Mockito in Java oder Moq für .NET.

Eine Einführung in die wichtigsten Begriffe rund um Programmierung und Objektorientierung gibt es in der einhundertzweiundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Compiler und IDE

Was ist ein Compiler?

Ein Compiler übersetzt Sourcecode (z.B. for (int i: numbers)), den ein Mensch schreibt, in Maschinencode (z.B: 00011010 00011010), den ein Computer ausführen kann.

Dafür muss der Sourcecode absolut fehlerfrei sein, sonst gibt es Compiler-Fehler.

Die einzuhaltenden Regeln werden durch die Syntax der Programmiersprache bestimmt. Zur Syntax gehören Rechtschreibung, Interpunktion und Grammatik.

Was ist eine IDE?

Eine Integrated Development Environment (integrierte Entwicklungsumgebung) ist eine Software, mit der andere Software entwickelt wird. Sie enthält meist einen Editor und den Compiler.

Objekte und Klassen

Was ist ein Objekt?

Ein Objekt ist ein Ding der realen Welt mit Eigenschaften und Funktionen, z.B. ein Auto mit Eigenschaft Farbe und Funktion fahren.

Ein Objekt ist immer nur ein Modell der Realität, das sich je nach Einsatzzweck unterscheiden kann. Beim Auto interessiert sich die Tankstellenanwendung vielleicht nur für das Kennzeichen und die Größe des Tanks, während eine Werkstatt sich für den Kilometerstand und den Hersteller interessiert.

Was ist eine Klasse?

Eine Klasse ist ein Bauplan für Objekte, in dem festgelegt wird, welche Eigenschaften und Funktionen alle (!) Objekte dieser Klasse haben müssen.

Aus einer Klasse können dann mehrere Objekte erzeugt werden, die alle die gleichen Eigenschaften und Funktionen haben, die sich jedoch in den Werten ihrer Eigenschaften unterscheiden können.

Beispiel: Die Klasse Auto definiert die Eigenschaft Farbe und die Funktion fahren. Aus dieser Klasse können zwei Objekte erstellt werden, von denen eins den Wert blau für die Farbe hat und das andere den Wert rot.

Außerdem kann noch ein weiteres Auto erstellt werden, das ebenfalls blau ist, mit dem anderen blauen Auto aber nichts zu tun hat. Genau wie in der Realität kann es "baugleiche" Autos geben, die trotzdem individuelle Einzelstücke sind.

Datentypen und Variablen

Was ist ein Datentyp?

Ein Datentyp legt fest (und der Compiler prüft):

Art der Daten (z.B. Zahlen, Zeichenfolgen, Wahrheitswerte)

Länge der Daten (z.B. 32 Bit für Zahlen)

Erlaubte Operationen auf den Daten (z.B. Addition für Zahlen oder Konkatenation für Zeichenketten)

Nicht erlaubt wären:

Ganzzahl a = "Hallo"; ("Hallo" ist keine Ganzzahl)

Byte b = 32321; (32321 ist zu groß für ein Byte)

true + false (Wahrheitswerte können nicht addiert werden)

Verbreitete Datentypen, die es in vielen Programmiersprachen gibt:

Integer: Ganzzahlen (meist 32 Bit lang)

Double: Gleitkommazahlen

String: alphanumerische Zeichenketten

Boolean: Wahrheitswerte (true und false)

Man kann auch eigene Datentypen definieren. Das wären dann die Klassen, die eine beliebige Kombination aus anderen Datentypen als Attribute enthalten können.

Was ist eine Variable?

Eine Variable ist ein benannter Speicherbereich, der in einem Programm für die Verarbeitung verwendet werden kann, damit man nicht mit kryptischen Speicheradressen wie 0xA042BC2 arbeiten muss.

Variablen haben einen Datentyp und einen Bezeichner, z.B. Integer alterDerPerson (in Java).

Der Wert einer Variablen kann während der Programmlaufzeit verändert werden.

Ausdrücke, Operationen und Anweisungen

Was ist ein Ausdruck (oder eine Expression)?

Ein Ausdruck führt bei der Auswertung zu einem Resultat.

Beispiele: 1 + 2 (-> 3), (43.2 + 2) * 3 (-> 135.6), "Hallo" + "Welt" (-> "HalloWelt")

Was sind Operatoren und Operanden?

Operanden sind die Werte, die verarbeitet werden sollen.

Operatoren verknüpfen die Operanden zu Ausdrücken. Sie bilden z.B. die arithmetischen Operationen (Addition, Multiplikation usw.) ab.

Je nach Typ hat ein Operator einen (unär), zwei (binär) oder drei (ternär) Operanden.

1 + 2 -> 1 und 2 sind die Operanden,

Um Ports und Netzwerkprotokolle geht es in der einhunderteinundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Mit dem Kommandozeilentool ping kann getestet werden, ob die Kommunikation zum Ziel über das Netzwerk grundsätzlich möglich ist. Wenn ja, kann man die Adresse dann z.B. auch im Browser aufrufen.

Ports

Die grundsätzliche Kommunikation steht nun also, aber woher weiß ein Server, welchen Dienst er einem Client anbieten soll (z.B. Mail oder WWW oder eben auf den "Ping" antworten)?

Die Lösung sind Ports. Für jeden bekannten Dienst gibt es einen einzelnen Port, der einfach an die IP-Adresse bzw. an den DNS-Namen angehängt werden kann, z.B. google.de:80.

Allgemein bekannte Dienste haben verbindlich festgelegte, so genannte well-known Ports bis 1024. Beispiele: HTTP 80, SMTP 25, SSH 22 oder Doom 666.

Übrigens: ping benutzt das Protokoll ICMP, das Bestandteil von IP ist und keinen eigenen Port verwendet.

Unter Windows gibt es in der Datei C:\Windows\System32\drivers\etc\services eine Liste dieser bekannten Ports.

# Copyright (c) 1993-2004 Microsoft Corp.

#

# This file contains port numbers for well-known services defined by IANA

#

# Format:

#

# / [aliases...] [#]

#

echo 7/tcp

echo 7/udp

discard 9/tcp sink null

discard 9/udp sink null

systat 11/tcp users #Active users

systat 11/udp users #Active users

daytime 13/tcp

daytime 13/udp

qotd 17/tcp quote #Quote of the day

qotd 17/udp quote #Quote of the day

chargen 19/tcp ttytst source #Character generator

chargen 19/udp ttytst source #Character generator

ftp-data 20/tcp #FTP, data

ftp 21/tcp #FTP. control

ssh 22/tcp #SSH Remote Login Protocol

telnet 23/tcp

smtp 25/tcp mail #Simple Mail Transfer Protocol

...

Protokolle

Die Kommunikation steht also jetzt, aber was wird da nun konkret übertragen?

Protokoll: Eine Abfolge von definierten Befehlen an den Server und dessen passenden Antworten.

Leicht verständlich ist das Protokoll SMTP (Simple Mail Transfer Protocol) zum Versenden von E-Mails. Beispiel: HELO, MAIL FROM, RCPT TO, DATA, Subject: Test, .

Mit Hilfe des Kommandozeilenwerkzeugs telnet kann man sich gezielt mit einem Port des Zielservers verbinden und die passenden Befehle zum jeweiligen Dienst ausführen.

SMTP verwendet keinerlei Authentifizierung. Daher ist Spam so ein Problem.

HTTP (Hypertext Transfer Protocol) verwendet Port 80. Bei HTTP werden andere Befehle verwendet, wichtig ist insb. das GET, mit dem man Ressourcen abrufen kann (also insb. Websites).

Als Beispiel, wie wichtig dabei die Verschlüsselung (HTTPS anstatt HTTP) ist, kann man ein kleines Webformular erstellen, das einen Benutzernamen und ein "geschütztes" Passwort abfragt. Schneidet man den Netzwerkverkehr mit, kann man Benutzernamen und Passwort im Klartext mitlesen, auch wenn im Formular im Passwortfeld nur Sternchen zu sehen sind.

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Port (Protokoll)

Internet Control Message Protocol

Netzwerkprotokoll

Simple Mail Transfer Protocol

Hypertext Transfer Protocol

Um private IP-Adressbereiche und das Routing von Netzwerkpaketen geht es in der einhundertvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Private IP-Adressbereiche

Da es im aktuellen Standard IPv4 nicht genug IP-Adressen für alle Teilnehmer auf der Welt gibt, muss eine Möglichkeit geschaffen werden, IP-Adressen abgeschlossen vom Internet zu vergeben, um interne Netzwerke betreiben zu können.

Es gibt einige fest definierte IP-Adressbereiche, die im Internet nicht verfügbar sind: die privaten IP-Adressbereiche 10.0.0.0, 172.16.0.0 (bzw. genauer 172.16.0.0 bis 172.31.255.255) und 192.168.0.0.

Aber wenn sie im Internet nicht verfügbar sind, wie kommt man dann ins Netz?

Routing und NAT

Es wird ein Gerät benötigt, dass zwischen das private und das öffentliche Netz geschaltet wird: ein Router. Der "übersetzt" quasi zwischen Intra- und Internet.

Private IP-Adressen sind im Internet nicht auffindbar (sie werden nicht "geroutet"). Daher ersetzt der Router auf dem Hinweg die private Quell-IP-Adresse des Clients durch seine eigene öffentliche IP-Adresse des Internetanschlusses (z.B. per DSL oder Kabel). An diese kann der Webserver die Antwort auf die Anfrage dann zurückschicken.

Wenn dann später die Antwort des Webservers im Router eintrifft, muss dieser die Ziel-IP-Adresse des Pakets wieder auf die private IP-Adresse des Clients setzen und das Paket an diesen weiterleiten.

Dafür muss sich der Router "merken", welcher Client welche Anfrage an welchen Server gestellt hat, damit er die Antworten passend zuordnen kann.

Dieses Prinzip heißt NAT (Network Address Translation) und ermöglicht mehreren Clients mit verschiedenen privaten IP-Adressen über einem gemeinsamen Router mit einer einzigen öffentlichen IP-Adresse ins Internet zu gelangen.

Auch der Router hat meist keine direkte Verbindung zum Zielserver, sondern muss die Pakete auf eine "Reise" durch das Netzwerk schicken, bis es (ggfs. über mehrere weitere Router hinweg) beim Ziel ankommt. Aber woher weiß der Router, an welchen anderen Router er das Paket ggfs. schicken muss?

Das Default Gateway ist der "nächste Knoten" im Netzwerk auf dem Weg zur Zieladresse. Dieser wird immer angesprungen, wenn der Zielknoten nicht direkt erreichbar ist. Diese Übersetzung kann man beliebig fortführen. Ein Client muss dazu nur die Adresse seines Routers kennen, der dann wiederum einen Router kennt, der dann das weitere Routing übernimmt usw. Irgendwann landet das Paket bei einem Knoten, der direkt mit dem Ziel kommunizieren kann, und es wird zugestellt.

In unserem Heimnetzwerk übernimmt die Fritzbox übrigens mehrere Rollen gleichzeitig: DHCP- und DNS-Server sowie Router und Default Gateway.

Gateways müssen nicht immer Router sein, aber de facto sind sie es heute so gut wie immer, da die historische Aufgabe, Netzwerke unterschiedlicher Technologien (z.B. IP und IPX/SPX) miteinander zu verbinden, durch den flächendeckenden Einsatz von IP nicht mehr benötigt wird.

Mit dem Kommandozeilentool tracert (oder traceroute unter Linux) kann man den Weg zum Ziel über alle Knoten dazwischen verfolgen. Dazu wird der TTL-Eintrag (Time to live) des IP-Pakets genutzt, den jeder Knoten automatisch herunterzählt. Bei 0 angekommen wird das Paket verworfen. Dabei wird aber eine Info an den Sender mit der Adresse des verwerfenden Knotens geschickt. tracert verschickt nun der Reihe nach Pakete mit TTL 1, 2, 3, 4 usw. und gibt die Adressen der verwerfenden Knoten aus.

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Private IP-Adresse

Router

Gateway (Informatik)

Netzwerkadressübersetzung

Time to Live

Meine Erkenntnisse (positiv wie negativ) aus der IHK-Sommerprüfung 2019 teile ich mit euch in der einhundertneununddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Projektdokumentation

Verwendung unnatürlicher Sprache ("bei dem" statt "beim", "Leerung der Datenbank" statt "Datenbank leeren")

Kapitel meiner Vorlage werden ausgefüllt, auch wenn die Inhalte überhaupt nicht sinnvoll sind

"Eine Nutzwertanalyse war nicht sinnvoll, deswegen habe ich darauf verzichtet."

Identische Inhalte werden gleich mehrfach wiederholt (u.a. aus dem Antrag übernommen), z.B. bei der Projektbegründung und Zieldefinition

Wichtige Inhalte fehlen

insgesamt viel zu wenig Text (8 Seiten statt 15)

Benutzer-/Entwickler-Dokumentation (gibt direkt >10% Abzug), und nein, ein PHP-Doc-Block ohne Inhalt reicht nicht aus

trotz explizitem Hinweis der Prüfer im Antrag wurden keine Diagramme erstellt, weil diese "nicht sinnvoll" waren

Qualitätssicherung fehlt häufig komplett (abgesehen vom scheinbar obligatorischen "Code-Review")

Qualitätssicherung

"Die Methoden wurden auf Komplexität geprüft" (sind im Anhang aber >70 Zeilen lang)

"Viel Wert auf Clean Code gelegt" (aber doppelter Code, Magic Numbers, harte Pfade, komplexe switches im Anhang)

"Die Übertragung muss verschlüsselt erfolgen" (aber alle URLs beginnen mit http)

"Code Coverage muss >90% sein" (aber nicht einen Test gezeigt)

Debugger/Konsole wird für "Tests" genutzt

Fehler in der Wirtschaftlichkeits-/Amortisationsrechnung

"Pauschale" für Ressourcennutzung angesetzt, wird aber nicht mit eingerechnet

laufende Kosten des Projekts gibt es nicht

Kosten des Unternehmens werden Einsparungen des Kunden gegenübergestellt

bei der Kostenplanung werden große Kostenverursacher "vergessen"

Vergleich mit fiktiven Kosten von einer Website, die Kosten für Apps schätzt

Fehler in Diagrammen

ERM enthält m:n-Tabellen

include vs. extends im Use-Case-Diagramm

Aktionen werden nicht in der Zeitplanung berücksichtigt (4h Schulung)

Uninteressante Inhalte werden viel zu detailliert dargestellt

langweiliger Sourcecode über mehrere Seiten im Anhang, 8 (!) Seiten Mockups und 6 Seiten Quelltext im Anhang

Hardware des Arbeitsplatzrechners bis runter auf die RAM-Art und Typ der Grafikkarte erklärt

Zeitplanung/Projektaufbau in drei verschiedenen Varianten dargestellt (Gantt, Tabelle, Projektstrukturplan)

lächerlich einfache Abläufe mit Diagrammen dargestellt (Sequenzdiagramm mit einmal hin und zurück, Aktivitätsdiagramm mit einer einzigen Verzweigung)

teils völlig sinnlose und nicht im Zusammenhang zum Inhalt stehende Komponenten (z.B. Auszug aus pom.xml ohne Erläuterung)

minified (!) CSS/JavaScript wird gezeigt

Overkill

Kostenkalkulation über 3 Seiten mit zig mathematischen Formeln mit Indizes (z.B. KKunde + Kfix) etc.

komplette Seite für typographische Konventionen

5 (!) Überschriftenebenen (z.B. "3.1.1.4. a)")

Diagramm der Amortisationsrechnung mit mathematischer Software geplottet

"wissenschaftliche" Erklärung von Vorgehensmodellen mit Quellennachweis und wörtlichen Zitaten über mehrere Zeilen, aber aus der Wikipedia

nervige Kleinigkeiten

Abkürzungsverzeichnis nicht sortiert

Seitennummerierung fehlerhaft

Quellennachweise, die lediglich Links enthalten ohne Bezug zu irgendeinem Inhalt

handwerkliche Fehler

Passwörter im Klartext in der Applikation speichern oder sogar übers Netzwerk schicken

Geschäftslogik im Controller

Projektpräsentation

viele Frameworks verwendet, aber nur die (nichtssagenden) Logos gezeigt

Codebeispiele enthalten TODOs und Hinweise der IDE

Rechtschreibfehler auf den Folien

winziger Text

Grafiken überlagern Textelemente

Cliparts verwendet

Unternehmen zu lang vorgestellt

eigenen Namen nicht genannt und nicht gezeigt

Tabelle mit Zeitplanung zeilenweise vorgelesen

Fachgespräch

GA1 hat viele gute Prüflinge stark runtergezogen

Wirtschaftsfragen gehen gar nicht (Stundensatz, Gehaltsabrechnung, brutto/netto, Einzel-/Gemeinkosten, BAB)

Um zwei zentrale Technologien der Netzwerkgrundlagen - DNS und DHCP - geht es in der einhundertachtunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

DNS

Theoretisch können wir auch im Internet surfen, indem wir die IP-Adressen der Websites eingeben, aber das kann sich kein Mensch merken.

Daher sind Websites über einen sprechenden Namen, die Domain, erreichbar. Dafür brauchen wir dann aber eine Übersetzung von Domainname in IP-Adresse, damit der Computer kommunizieren kann.

Einfachste Möglichkeit: Datei mit Übersetzung von IP in Domain (gibt es tatsächlich: hosts unter Windows z.B. unter C:\Windows\System32\drivers\etc, die Paare aus IP-Adressen und Hostnamen enthält). Dann müsste aber jeder Computer die gesamte Liste aller verfügbaren Domains kennen. Das ist nicht machbar.

# Copyright (c) 1993-2009 Microsoft Corp.

#

# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.

#

# This file contains the mappings of IP addresses to host names. Each

# entry should be kept on an individual line. The IP address should

# be placed in the first column followed by the corresponding host name.

# The IP address and the host name should be separated by at least one

# space.

#

# Additionally, comments (such as these) may be inserted on individual

# lines or following the machine name denoted by a '#' symbol.

#

# For example:

#

# 102.54.94.97 rhino.acme.com # source server

# 38.25.63.10 x.acme.com # x client host

# localhost name resolution is handled within DNS itself.

# 127.0.0.1 localhost

# ::1 localhost

136.243.146.110 macke.it

Die Lösung ist DNS (Domain Name System), ein "Telefonbuch" für Websites/IP-Adressen, das auf viele Server verteilt ist.

Mit dem Kommandozeilentool nslookup können DNS-Server abgefragt werden.

DNS kann kaskadiert werden. Wenn ein Server nicht weiter weiß, fragt er den übergeordneten Server und speichert (cacht) ggfs. das Resultat für die nächste Anfrage.

Die letzte Instanz der Kaskade sind die sog. Root-Server.

Die sogenannten Websperren gegen "verbotene" Websites funktionieren im Prinzip so, dass einzelne "Telefonbücher" (z.B. die der deutschen Internetprovider) gesäubert werden. Aber man kann sie einfach umgehen, indem man bewusst einen anderen DNS-Server verwendet, der z.B. in einem anderen Land steht.

DHCP

Zurück zu unserem Aufruf: Der Client ruft eine Adresse im Browser auf und der Server liefert ihm HTML zurück. Aber dazu braucht der Client auch eine IP-Adresse.

Die Zieladresse ist dank DNS bekannt, aber man braucht auch eine Quelladresse für den Client. Die kann man selbst vergeben, aber das wird bei mehreren PCs immer schwieriger, da sie eindeutig sein müssen (sonst weiß das Netzwerkpaket der Antwort nicht, wo es hin muss).

Die Lösung heißt DHCP (Dynamic Host Configuration Protocol). Das ist ein Dienst, den ein Server (zuhause z.B. die FRITZ!Box*) bereitstellt, der sich dann z.B. die Liste der bereits verwendeten IP-Adressen merkt und keine doppelt vergibt. Außerdem kann man viele weitere Einstellungen (wie z.B. den zu nutzenden DNS-Server) per DHCP an die Clients verteilen.

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen auch DNS und DHCP erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Für die Prüfungsvorbereitung musst du aber dein Wissen noch vertiefen! Literaturempfehlungen zur Netzwerktechnik evaluiere ich aktuell und reiche sie später nach.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Domain Name System

Root-Nameserver

Dynamic Host Configuration Protocol

Um den Aufbau und die Darstellung von IP-Adressen geht es in der einhundertsiebenunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

IP-Adresse

URLs sind für Menschen einigermaßen gut zu verstehen und zu merken, aber Computer kommunizieren leider nicht über URLs, sondern über IP-Adressen.

Eine IP-Adresse ist eine 32 Stellen lange Folge von Nullen und Einsen. Das Bit ist die kleinste Informationseinheit der Informatik und kann genau diese beiden Werte annehmen. Also ist eine IP-Adresse 32 Bit lang.

Da sich wenige Menschen 32 Stellen lange Zahlen merken können, gibt es eine bessere Schreibweise für IP-Adressen: man spaltet die 32 Bit in 4 x 8 Bit auf und wandelt diese Teile jeweils um in eine Dezimalzahl.

Das funktioniert ganz einfach: Jede Stelle einer Binär- bzw. Dualzahl steht von rechts ausgehend für ein Vielfaches von 2. Die Summe der entsprechenden Stellen der Binärzahl malgenommen mit dem Wert der ihnen zugeordneten Zweierpotenzen ergibt die Dezimalzahl.

Die minimale Dezimalzahl für eine Stelle der IP-Adresse ist 0. Die maximale Dezimalzahl für eine Stelle der IP-Adresse ist 255.

10101000 (Basis 2) = 168 (Basis 10)

10101000 = 1 * 2^8 + 0 * 2^7 + 1 * 2^6 + 0 * 2^5 + 1 * 2^4 + 0 * 2^3 + 0 * 2^2 + 0 * 2^1 = 128 + 32 + 8 = 168

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

IP-Adresse

IPv6

Um den Aufbau von URLs geht es in der einhundertsechsunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Use Case

Was passiert technisch, wenn der Browser eine Website anzeigt?

Übrigens: Unterschied Website/Homepage: Eine Website ist die Gesamtheit an Inhalten des Anbieters, während die Homepage lediglich die Startseite des Angebots bezeichnet.

Der Client ruft eine Adresse im Browser auf und der Server liefert HTML zurück, das der Browser rendert (in eine grafische Darstellung umwandelt) und auf dem Client darstellt.

Übrigens: Intranet vs. Internet: Der grundsätzliche Vorgang ist derselbe, nur der Webserver steht im internen Netz bzw. ist nur aus dem internen Netz heraus erreichbar.

URLs

Woher wissen Client und Server, wohin sie ihre Daten schicken müssen?

Der Client muss zunächst die Zieladresse kennen. Dies ist meistens ein URL wie z.B. www.google.com

URL steht für Uniform Resource Locator.

Wie sind URLs aufgebaut?

Beispiel: http://blog.macke.it/posts/post.php?id=123#comments

Der erste Teil ist das sogenannte Schema oder Protokoll. Davon gibt es mehrere, nicht nur http, sondern z.B. auch noch ftp oder mailto (Pseudo-Protokoll).

Die Domain ist hierarchisch von rechts nach links absteigend aufgebaut. Die Top Level Domain ist z.B. de oder com. Danach kommt die eigentliche Domain mit ggfs. Subdomain und Hostname. Das www ist übrigens der Hostname (übliche Bezeichnung des Webservers) und nicht verpflichtend in einem URL!

Danach kommt der Pfad, der vergleichbar mit einem Pfad und einer Datei auf einer Festplatte ist. Das php steht für die Programmiersprache PHP, mit der Websites entwickelt werden können.

Nach dem Dateinamen können Parameter als Schlüssel/Wert-Paare angegeben werden, um z.B. mit einer physikalischen Datei unterschiedliche Artikel in einem Warenkorb anhand ihrer ID anzeigen zu können.

Zuletzt ist noch ein Abschnitt möglich, über den man z.B. direkt auf eine Überschrift mitten auf der aktuellen Seite springen kann. Das Zeichen # heißt übrigens "Hash" und nicht "Hashtag".

Benutzername und Passwort zum Zugriff auf die Ressourcen können ebenfalls angegeben werden. Sie werden vor die Domain geschrieben: http://benutzer:[email protected].

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Website

Homepage

Uniform Resource Locator

Domain (Internet)