VL 2

Diese Anwendungen umfassen sowohl den eigentlichen Anwendungs„zweck“ bzw. -algorithmus als auch das Anwendungsprotokoll

Vor allem Anwendungen mit großem Datenverkehrsaufkommen verwenden gerne Peer-to-Peer-Architekturen

Dateiverteilung mit BitTorrent Internettelefonie mit Skype (früher. . . ) Filesharing, z. B. mit Gnutella oder LimeWire (ganz früher. . . ) ...

Aber auch die gängigen Kryptowährungen (Bitcoin, Ethereum,. . . ) Keine Server notwendig ⇒ Kostenvorteile

Die Vorteile erkauft man mit einem typischerweise sehr viel komplexeren Anwendungsdesign und Anwendungsprotokoll

Für die Kommunikation zwischen zwei Programminstanzen muss sich ein Anwendungsentwickler dann auch für ein Transportprotokoll entscheiden

Verschiedene Arten von Anwendungen können sehr unterschiedliche Anforderungen stellen Verschiedene Transportprotokolle bieten unterschiedliche Dienste an, z. B.

Zuverlässigkeit (Dateitransfer: gefordert, Multimedia: Aussetzer können toleriert werden)

Datenratensteuerung (Dateitransfer: beliebig, Multimedia: meist Mindestdatenrate gefordert)

Echtzeitfähigkeit: Paketlaufzeit oder Paketankunftsintervalle sind vorgeschrieben (Dateitransfer: egal, Multimedia: gefordert)

... Im Internet werden fast ausschließlich die Transportprotokolle TCP und UDP verwendet

Eine der ältesten Anwendungen im Internet: E-Mail

Zentrale Komponenten: E-Mail-Server (mit Postfächern für Benutzer) E-Mail-Anwendungen auf Anwender- rechnern

Server „sprechen“ SMTP miteinander

Prinzipieller Ablauf:

1. Alice verfasst ihre E-Mail auf Ihrem Rechner

2. Die E-Mail wird an Alices Mailserver übertragen

3. Dort wird sie in eine Warteschlange gestellt

5. Bobs Mailserver packt die Mail in Bobs Postfach 6. Von dort kann Bob sie (irgendwann später, über andere Protokolle) mit seinem E-Mail-Programm abholen

„Be conservative in what you do, be liberal in what you accept from others“

z.B. Email

MIME (RFCs 2045, 2046) nutzt die Erweiterbarkeit durch zusätzliche Header aus; die wichtigsten:

Content-Type: beschreibt die Art der enthaltenen Daten (z. B. image/jpeg)

Content-Transfer-Encoding: gibt an, wie diese dargestellt werden (z. B. base64) MIME-E-Mails können aus mehreren Teilen bestehen

Teile können selbst wieder (potentiell weiter verschachtelte) MIME-Nachrichten sein

SMTP deckt nur die Zustellung der E-Mail bis zum Mailserver des Empfängers ab

Für die Übertragung zwischen dem Postfach und dem E-Mail-Programm des Empfängers werden andere Protokolle verwendet

POP3 („Post Office Protocol v.3“, RFC 1939) ist ein einfaches Protokoll, zur Abholung einer E-Mail, wobei sie vom Server gelöscht wird

IMAP („Internet Mail Access Protocol“, RFC 3501) bietet sehr viel mehr Funktionen, kann z.B. die E-Mails auf dem Server belassen und sie so universeller zugreifbar machen

Wichtigste Aufgabe von HTTP: Webseiten von Webservern an Browser(http-client) übertragen

Eine Webseite besteht aus Objekten (HTML-Dateien, Bildern, Audio/Video-Dateien,. . . )

HTML (HyperText Markup Language) ist eine Spezifikationssprache für formatierte Dokumente mit Text, eingebetteten Bildern, Links,. . .

Die Aufgabe eines Browsers ist das Herunterladen von solchen Dokumenten und das Anzeigen von HTML-Dokumenten

Für das Herunterladen wird HTTP verwendet, das wir nun näher betrachten

In HTTP ist jedes Objekt über eine URL (Uniform Resource Locator) adressierbar, z. B. https://www.etit.tu-darmstadt.de/fachbereich/index.de.jsp

Eine HTTP-Anfrage (Request) beginnt mit einer Anfragezeile, die die verwendete Methode (GET, POST, HEAD, PUT, DELETE) enthält

GET /fachbereich/index.de.jsp HTTP/1.1

Außerdem: Dokument auf dem Server und welche HTTP-Protokollversion verwendet werden soll

Host: www.etit.tu-darmstadt.de

User-agent: Mozilla/5.0 (X11; Linux i686; rv:99.0)\Gecko/20100101 Firefox/99.0

Connection: keep-alive

Der Anfragezeile können noch HTTP-Header-Zeilen folgen:

Host: Von welchem Webserver wird etwas angefordert der Host-Header ist Pflicht seit der HTTP-Version HTTP/1.1

User-Agent: Welcher Browser wird in welcher Version verwendet erlaubt es dem Server, evtl. speziell angepasste Versionen der Objekte auszuliefern

Connection: keep-alive bedeutet, dass der Client gerne möchte, dass der Server nach dem Beantworten dieser Anfrage die TCP-Verbindung offen lässt (persistentes HTTP) Andernfalls würde der Server nach Beantworten der Anfrage die Verbindung schließen

->das war das Standardverhalten im ursprünglichen HTTP

Eine HTTP-Antwort beginnt mit einer Statuszeile (Protokollversion + Statuscode + Beschreibung) HTTP/1.1 200 OK

Es folgen wieder Headerzeilen

Content-Type: text/html; charset=UTF-8

Date: Thu, 24 Oct 2021 11:14:24 GMT

Connection: keep-alive ...

Dann eine Leerzeile Und schließlich das eigentliche angefragte Objekt

Nicht der HTTP-Server (im engeren Sinne) erkennt den Zusammenhang zwischen den Anfragen Aber andere Mechanismen (z. B. vom Webserver zum Erzeugen von dynamischen HTTP-Objekten aufgerufene Programme) „erkennen“ einen Zusammenhang zwischen mehreren HTTP-Anfragen

Die Kunst: Schlüssel für den Zugriff auf Zustandsinformationen über ein zustandsloses Protokoll transportieren

Ein HTTP-Server kann mit einer HTTP-Antwort einen Cookie „mitliefern“

Dafür wird ein spezieller HTTP-Header verwendet:

Set-Cookie: irgendeincookietext Der Browser sieht diesen Header und speichert den Cookie für diese Webseite

Jedesmal, wenn zukünftig eine Webseite von diesem Server angefordert wird, wird der Cookie mitgeschickt

Cookie: irgendeincookietext Der HTTP-Server kann den Cookie an die Webanwendung weitergeben; sie kann so den Benutzer

wiedererkennen

Client zu server und server zu client zurück: Erst nach Abschluss dieses „Handshakes“ können Daten über TCP übertragen werden Dieser Verbindungsaufbau kostet Zeit: Die Laufzeit für ein Paket einmal hin und zurück

diese (natürlich nicht konstante) Dauer nennt man die Round Trip Time (RTT) einer Verbindung

Interaktive Protokolle wie HTTP müssen die Zahl der notwendigen RTTs gering halten!

Jedes Objekt in einer separaten TCP-Verbindung

Verbindungsaufbau benötigt jeweils 1 RTT

Dann nochmals 1 RTT bis zum Eintreffen des angeforderten Objektes (für HTTP-Anfrage und -Antwort)

Also: 4 Objekte · 2 RTTs/Objekt = 8 RTTs

Idee hinter Persistentem HTTP: nicht für jeden Request eine neue TCP-Verbindung öffnen Erfordert entsprechende Funktionen im HTTP-Protokoll(⇒Connection: keepalive)

Ursprüngliches HTTP: Server schließt Verbindung nach Ende des Requests, Client schließt danach ebenfalls

Spätere Erweiterung: Client und Server können sich darauf einigen, die Verbindung offen zu halten

Mehrere parallele TCP-Verbindungen können genutzt werden, um mehrere Objekte gleichzeitig abzurufen

Aber: Diese Verbindungen müssen sich natürlich die Netzwerkkapazität teilen – Gewinne sind dadurch begrenzt

Zusätzliche Verbindungen erzeugen zusätzliche Last auf dem Server

IETF-Standards für HTTP/1.1 empfehlen: nicht mehr als zwei parallele Verbindungen (RFC 2616)

Browser halten sich allerdings nicht daran

Eventuell lässt sich die Zeit für eine Anfrage ja manchmal vollständig vermeiden?

Idee: HTTP-Clients können Objekte von Webservern in einem lokalen Cache zwischenspeichern

Wenn der Benutzer dann dieselbe Seite noch einmal besucht, müssen sie nicht erneut übertragen werden

Der Expires-Header gibt einen Zeitpunkt an, bis zu das Objektes sicher verwendet werden kann.

Problem: Das erfordert, dass der Server weiß, wann sich das Objekt zum nächsten Mal ändern wird. . .

Um dieses Problem zu vermeiden, gibt es noch einen zweiten Mechanismus in HTTP:

Bedingtes GET:

if-modified-since kann die übertragene Datenmenge (und damit Übertragungszeiten) reduzieren

Es verringert aber nicht die Zahl notwendiger RTTs!

Mit Schlüsselaustauschprotokollen können sich zwei Kommunikationspartnern über eine nicht abhörsichere Leitung auf einen gemeinsamen Schlüssel einigen

Bekanntestes Beispiel: Diffie-Hellman-Schlüsselaustausch

Verschlüsseln bringt nichts, wenn man nicht sicher sein kann, den richtigen Schlüssel zu benutzen!

Zentrales Problem daher: Vertrauenswürdige Abbildung einer Identität auf den dazugehörigen öffentlichen Schlüssel

Lösungsansatz: Zertifikate – vertrauenswürdige Dritte unterschreiben (digital), dass ein bestimmter öffentlicher Schlüssel zu einer bestimmten Person(/Organisation/...) gehört

Die Regeln, nach denen Zertifikate ausgestellt werden, und die dafür notwendige Infrastruktur nennt man Public Key Infrastructure (PKI):

Häufig, unter anderem im WWW: oligopolistisch und hierarchisch (X.509/PKIX) Alternative: anarchisch (Web of Trust)

Zentrale Frage: Wem vertraue ich?

SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security)

Protokoll(e) zum Authentifizieren und Verschlüsseln von TCP-Verbindungen

Hierzu: Verwendung von Public-Key-Infrastrukturen (PKI) zum Ausstellen, Verteilen und Überprüfen von digitalen Zertifikaten

Prinzip:

zusätzliche Protokollschicht zwischen Transport- und Anwendungsprotokoll sieht nach „oben“ aus wie TCP, nach „unten“ wie ein TCP-basiertes Anwendungsprotokoll nutzt eine darunterliegende TCP-Verbindung verlässt sich insbes. auf Zuverlässigkeit und Reihenfolgeerhaltung durch TCP

Variante für UDP-basierte Anwendungsprotokolle: DTLS

->Durch diese Struktur unterstützt SSL/TLS prinzipiell jedes (TCP-basierte) Anwendungsprotokoll

HTTPS ist tatsächlich ganz „normales“ HTTP, mit der zusätzlichen SSL/TLS-Zwischenschicht Ebenso wird SSL/TLS aber auch mit anderen Protokollen genutzt, z. B. mit SMTP, POP3, IMAP,. . .

Die SSL/TLS-Zwischenschicht nutzt X.509-Zertifikate für die Überprüfung von Identitäten

Wichtig: SSL/TLS ist nicht unfehlbar – und höchstens so vertrauenswürdig wie das verwendete Zertifikat!

Zentrale Ziele:

Beschleunigung des Seitenaufbaus

Reduktion der Zahl paralleler TCP-Verbindungen

möglichst gute Kompatibilität zu existierenden Anwendungen

Bevor z. B. eine TCP-Verbindung aufgebaut werden kann, müssen Namen wie google.com in die zugehörige IP-Adresse "‘übersetzt"’ werden

Dafür wird das Domain Name System (DNS) verwendet:

DNS ist eine hierarchische, verteilte Datenbank mit einem zugehörigen Abfrageprotokoll

Wenn dieser Server nicht funktioniert, wäre das Internet effektiv lahmgelegt – ein Single Point of Failure

Der Server müsste alle Namensanfragen auflösen – das wäre sehr, sehr viel Last (⇒ eine solche Architektur für DNS wäre nicht skalierbar)!

Der Server könnte in der "‘Nähe"’ mancher Internetbenutzer stehen, aber für viele wäre er "‘weit weg"’ – lange Antwortzeiten!

Es gibt damit drei wesentliche Klassen von DNS-Servern:

1. Root-Server

2. TLD-Server

3. AutoritativeDNS-Server, die für einen Teilbereich des Namensraumes(eineDomain)"‘zuständig"’sind, auf denen also dauerhafte Einträge für Zuordnungen hinterlegt sind.

Außerdem betreiben ISPs, Firmen, Universitäten usw. häufig lokale Nameserver sind nicht (zwangsläufig) autoritative Server für eine Domain

können aber von anderen Rechnern verwendet werden, um Hostnamen aufzulösen

einer der Vorteile: aufgelöste Namen können dort zwischengespeichert werden, um erneute Anfragen schneller zu beantworten (DNS Caching)

Spezifiziert für UDP und für TCP (jeweils auf Port 53)

Verwendet wird in der Praxis hauptsächlich UDP

Warum? DNS-Nachrichten passen fast immer in ein UDP-Paket Zeit für den Verbindungsaufbau entfällt – schneller!

DNS Nachrichten sollen möglichst klein sein, um in ein einzelnes Paket zu passen! -> nicht als text codiert.

Format sich genauer angucken!

Bei einer iterativen Anfrage führt der Client jeden Schritt der Anfrage selbst durch – wie vorhin

im Beispiel

Alle Anfragenachrichten gehen also vom Client aus, alle Antworten gehen direkt an ihn

Bei einer rekursiven Anfrage bittet der Client einen DNS-Server, die Auflösung vollständig für ihn zu erledigen

Theoretisch kann die Anfrage so eine "‘Kette"’ von DNS-Servern entlanggereicht werden, die Antworten kommen auf demselben Weg zurück

In der Praxis oft: