Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 9te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät.

Ähnliche Präsentationen


Präsentation zum Thema: "Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 9te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät."—  Präsentation transkript:

1 Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 9te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät Universität Freiburg 2009

2 Lehrstuhl für Kommunikationssysteme - Systeme II2 Letzte Vorlesung World Wide Web und HTTP TCP-basierter Dienst, der Anfang der 90er Jahre definiert wurde Applikationsschicht – Server und Browser Interaktion mit dem Benutzer Spezielle Seitenbeschreibungs- sprache (X)-HTML, die in der Client- Applikation auf Benutzerseite gerendert wird Früher einfache Datei auf Server, heute vielfach dynamisch generiert

3 Lehrstuhl für Kommunikationssysteme - Systeme II3 Letzte Vorlesung HTTP-Datenaustausch Request / Response mit e infache, zeilenorientierten Sequenzen vonZeichen Reihe verschiedener Request-Kommandos Responses mit bestimmten Statuscodes

4 Lehrstuhl für Kommunikationssysteme - Systeme II4 Electronic Mail eine der ältesten Anwendungen des Internets überhaupt, erste Spezifikation Anfang der 80er Jahre Einer der populärsten Dienste überhaupt Im Laufe der Zeit immer wieder erweitert worden von 7bit Textnachrichten zu Multi-Megabyte Anhängen beliebigen Formats Etliche Probleme (SPAM) resultieren aus altem Design An sind mehrere Protokolle beteiligt Stark mit DNS verknüpft Eigenen DNS Resource Record – MX (Mail Exchange)

5 Lehrstuhl für Kommunikationssysteme - Systeme II5 Electronic Mail Anwender sieht typischerweise nur eine Anwendung, die jedoch mehrere Protokolle mit evtl. unterschiedlichen Servern spricht Simple Mail Transfer Protocol (SMTP) Post Office Protocol (POP) Internet Message Access Protocol (IMAP)

6 Lehrstuhl für Kommunikationssysteme - Systeme II6 – Komponenten Begriffe (unterschiedlich stark verwendet) MUA Mail User Agent – Nachrichten lesen / schreiben MTA Mail Transfer Agent – Sicherstellung von Weiterleitung MDA Mail Delivery Agent – in Mailbox schreiben (lokal); zum nachsten MTA weiterleiten MRA Mail Retrieval Agent – aus der Mailbox lesen Die Applikation wird typischerweise als Mailreader oder als Mail User Agents (MUA) bezeichnet Verfassen von s Versenden von über einen Mailserver Abrufen eingehender s von einem Mailserver Verwalten der Mailbox auf einem Mailserver

7 Lehrstuhl für Kommunikationssysteme - Systeme II7 – Komponenten Mailreader (MUA) Verfassen von s Versenden von über einen Mailserver Abrufen eingehender s von einem Mailserver Verwalten der Mailbox auf einem Mailserver

8 Lehrstuhl für Kommunikationssysteme - Systeme II8 – Komponenten

9 Lehrstuhl für Kommunikationssysteme - Systeme II9 – Komponenten Mailserver (MTA – Mail Transfer Agents) Legen eingehende s der Nutzer in deren Mailboxes ab Nehmen von Nutzern gesendete s entgegen und leiten sie an andere Mailserver weiter Sprechen dazu mindestens eines der genannten Protokolle SMTP, POP3, IMAP Inzwischen oft um weitere Komponenten erweitert (die wiederum auf separate Maschinen ausgelagert sein können) -SPAM-Abwehr -Virenschutz

10 Lehrstuhl für Kommunikationssysteme - Systeme II10 – Komponenten Hierzu: -Ermittlung des korrekten Mailserver des Empfängers der E- Mails - s müssen gespeichert werden, falls Mailserver des Empfängers nicht erreichbar ist

11 Lehrstuhl für Kommunikationssysteme - Systeme II11 Aufbau einer Generelle Spezifikation [Briefkopf] (Header) From: Bob Mailman To: Chef, Mitarbeiter Cc: Mama Subject: Die elektronische Post [Textkorper] (Body) Hallo, so funktioniert Tschau!.

12 Lehrstuhl für Kommunikationssysteme - Systeme II12 Aufbau einer Zusatzinfos beim dem Senden Bevor die abgeschickt wird, wird die mit weiteren Angaben versehen: Envelope Sender- und Empfangeradressen ohne Beschreibungstext z.B.: Date Zeit der Erstellung des Dokuments (notwendig) Massage-ID (eine Art Briefmarke) MIME-Version und Content-Type falls Nachricht diesen Strukturen folgt Reply-To Adresse des Verfassers

13 Lehrstuhl für Kommunikationssysteme - Systeme II13 SMTP Simple Mail Transfer Protocol, Ursprünge sind ziemlich alt Aufgabe: Transfer von s zwischen Mailservern Transfer von s von Mailreader an Mailserver Spezifikation, verschiedene RFCs RFCs 821,2 (August 1982) und 1870 (November 1995) bilden Standard No. 10, abgelöst durch 2822 in 2001 Festlegung auf Text (Probleme ab 64KB), Internet war noch relativ sicher, da weitgehend beschränkter akademischer Nutzerkreis Daher keine Authentifikation notwendig Ziel: Protokoll so einfach wie moglich

14 Lehrstuhl für Kommunikationssysteme - Systeme II14 SMTP SMTP Spezifikation durch verschiedene RFCs Ab November 1995 zum STD 10 erklart mit RFC1869 (SMTP Service Extensions) und RFC1870 (SMTP Service Extension for Message Size Declaration) J. Klensin (Ed.) - Simple Mail Transfer Protocol. RFC 2821, April 2001 SMTP setzt zuverlässiges Transportprotokoll (TCP) voraus Kontroll- und Nutzinformationen werden über einen Kanal (Port 25) übertragen Mailserver tauschen gegenseitig s aus – jeder Mailserver ist Client und Server

15 Lehrstuhl für Kommunikationssysteme - Systeme II15 SMTP Problem: Daten werden generell unverschlüsselt übertragen Sämtliche s müssen in 7-Bit US-ASCII codiert werden können! Verbindungsauf- und -abbau (Handshake, Greeting), Datenübertragung Syntax der Kommandos ähnlich zu FTP Prinzip der Kommunikation – Interaktion zwischen Server und Client folgendermassen: Client sendet definierte Kommandos mit Parametern und Daten an den Server Der Server antworten per Server Responde Codes Ein (einwandfreier) Dialog erfolgt in (x) mehreren Schritten

16 Lehrstuhl für Kommunikationssysteme - Systeme II16 SMTP – Kommandos (Core) Befehle des Basis-Kommando-Sets HELO/EHLO Anmeldung/Identifikation des Clients MAIL Transaktion wird initiiert; Adresse des Senders RCPT Indentifiziert einen einzelnen Empfanger DATA Sendet Nachricht zum Server RSET Übertragung wird abgebrochen VRFY Prüft ob Ziel Mailbox (EXPN) Teilnehmer der Mailing Liste anzeigen (HELP) Hilfe zu Befehlen NOOP Kein Vorgang QUIT Schließen des Kommunikationskanals

17 Lehrstuhl für Kommunikationssysteme - Systeme II17 SMTP – verschicken telnet mailserver.domain.de msrv.domain.de ESMTP Sendmail ; Tue, 18 Oct :07: (CET) HELO mua.sub.domain.de 250 msrv.domain.de Hello mua.sub.domain.de [ ], pleased to meet you MAIL FROM: Sender RCPT TO: Recipient ok Mailkopf klar, nun Text, Daten...

18 Lehrstuhl für Kommunikationssysteme - Systeme II18 SMTP – verschicken DATA 354 Enter mail, end with "." on a line by itself Subject: TEST testing to talk directly to SMTP server more text h9MI7Tmo Message accepted for delivery QUIT msrv.domain.de closing connection Mail beendet und verschickt (einfach mal selbst ausprobieren)

19 Lehrstuhl für Kommunikationssysteme - Systeme II19 SMTP – Response Codes Mail Server Response Codes Code Bedeutung 1xx Befehl akzeptiert, jedoch gestoppt anhalten / fortfahren? 2xx Befehl erfolgreich ausgefuhrt nachster Befehl 3xx Befehl akzeptiert, jedoch gestoppt Zusatzangaben 4xx Temporarer Fehler 5xx Standiger Fehler x0x Syntax x1x Information x2x Verbindung x3x Nicht spezifiziert x4x Nicht spezifiziert x5x Mail System xxY Genauere Beschreibung der Kategorie (aus 2 digit)

20 Lehrstuhl für Kommunikationssysteme - Systeme II20 SMTP – Response Codes Mail Server Response Code Beispiele (teilweise im Kommunikationsablauf gesehen) Code Bedeutung 220 Service ready 221 closing connection 250 Ok 354 Enter mail, end with. 421 Service not available 452 Insufficient system storage 500 Command unrecognized 501 Error in parameters or arguments 554 Transaction failed

21 Lehrstuhl für Kommunikationssysteme - Systeme II21 SMTP – Erweiterung Multipurpose Internet Mail Extensions zur: Übertragung binärer Daten in s Anhängen von Dateien an s (Attachments) Spezifikation durch: N. Freed, N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045, 47 in 1996 N. Freed, N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. RFC 2046 November 1996

22 Lehrstuhl für Kommunikationssysteme - Systeme II22 SMTP – Erweiterung MIME Eigenschaften Erweitert SMTP um zusätzliche Header (MIME Header) Header Content-Type: gibt Typ der binären Daten an (MIME- Type) Header Content-Encoding: gibt Codierung der binären Daten an Eine darf mehrere Attachments enthalten Jedoch ohne Angabe von MIME-Headern wird weiterhin Text mit 7-Bit US-ASCII erwartet

23 Lehrstuhl für Kommunikationssysteme - Systeme II23 SMTP – MIME Header Syntax MIME-Header Header Content-Type: -Aufbau: Content-Type: type/subtype; parameters -Anhand subtype wird häufig externe Applikation (Viewer) gestartet -Angabe von Parametern ist optional -Beispiele für type/subtype

24 Lehrstuhl für Kommunikationssysteme - Systeme II24 SMTP – MIME Header Syntax MIME-Header Header Content-Transfer-Encoding: -Aufbau: Content-Transfer-Encoding: mechanism -Mailreader kann bei unbekanntem mechanism Inhalt der nicht darstellen -Typische eingesetzte Verfahren: base64, 7bit, 8bit, binary, quoted-printable

25 Lehrstuhl für Kommunikationssysteme - Systeme II25 SMTP – MIME Header Subject: Multipart Test MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= Test Teil 1 – nur Text Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data Test Teil 3 – wieder nur Text Anmerkungen Boundary darf nicht im Body der vorkommen Deshalb in der Regel eine lange Folge zufälliger Zeichen Anhand der boundary Rückschlüsse auf den MUA möglich

26 Lehrstuhl für Kommunikationssysteme - Systeme II26 Mailbox Zugriff Bisher Transfer von s zwischen Mailservern Transfer von s zwischen Mailreader und Mailserver (nur diese Richtung!) Wie kommt Mailreader (User) an seine empfangenen Mails ran? Spezialisierte Protokolle für den Zugriff POP(3) – Post Office Protocol IMAP(4) – Internet Message Access Protocol

27 Lehrstuhl für Kommunikationssysteme - Systeme II27 Post Office Protocol (v3) Problem – eigener Rechner nicht die ganze Zeit online zum Mailempfang, Mail gespeichert in Mailbox auf Mailserver POP3 (Post Office Protocol) ist einfaches Mail-Zugriffs- Protokoll Beschrieben in RFC 1939 Dynamische Kommunikation eines Clients mit einer Mailablage Im Normalfall Mails nur herunter geladen und dann vom Server gelöscht TCP am Port 110 POP3 Befehle bestehen aus Nicht-Case-Sensitiven ASCII Zeichen Schlüsselwörter und Argumente durch ein Leerzeichen getrennt

28 Lehrstuhl für Kommunikationssysteme - Systeme II28 Post Office Protocol (v3) POP3 Server-Antwort besteht aus Statusmeldung ( +OK oder -ERR) und Schlüsselwort Meldung kann bis zu 512 Zeichen lang sein Kommunikation findet in drei Phasen statt Autorisierungsphase -Client meldet sich an Transaktionsphase -Client fordert vom Server Aktionen Udate-Phase -Aktionen werden entgültig vollzogen

29 Lehrstuhl für Kommunikationssysteme - Systeme II29 Post Office Protocol (v3) POP Befehle: Authorisierungsphase -USER name - Mailbox-Besitzer -PASS string – Passwort des Mailbox-Besitzers -QUIT – Abbruch der Aktion -APOP name digest (optional) - Problem der unverschlüsselten Verbindung -Vermeidung Klartextpasswort (via PASS) – Server sendet zu Beginn der Session einen Timestamp, das zweite Argument beinhaltet eine MD5 Verschlüsselung des Timestamps (shared secret)

30 Lehrstuhl für Kommunikationssysteme - Systeme II30 Post Office Protocol (v3) POP Befehle: Transaktionsphase -STAT – Gibt Anzahl der Nachrichten und deren Größe als Oktalzahl an -LIST [msg] – Wird kein Argument gegeben werden alle Nachrichten aufgelistet, sonst die Nachricht mit der angegebenen Nummer in Byte -RETR msg – Nachricht Nr. [msg] wird herunter geladen -DELE msg – Nachricht Nr. [msg] wird zum löschen markiert -NOOP – Mache nichts (ähnlich wie auch bei SMTP)

31 Lehrstuhl für Kommunikationssysteme - Systeme II31 Post Office Protocol (v3) Transaktionsphase: -RSET – Alle als gelöscht markierten Nachrichten werde wieder in den Ausgangszustand gesetzt -TOP msg n [m] – (optionaler Befehl) schicke Header der Mail(s) n (-m) -UIDL [msg] (optional) – Ordnet jeder Nachricht eine eindeutige ID zu Update Phase -QUIT – Führe vorher markierte Aktionen aus (löschen) Recht einfaches Protokoll, so können Nachrichten nur einmal herunter geladen werden – Alternative IMAP

32 Lehrstuhl für Kommunikationssysteme - Systeme II32 Internet Message Access Protocol Beschrieben z.B. in RFC 3501 (IMAP4) Kein Download der Mails vom Server auf lokalen Rechner notwendig, aber möglich Zugriff auf Server-Verzeichnisse wie auf lokale Verzeichnisse Manipulation von Mailverzeichnissen auf dem Server (Erstellen, Umbenennen, Löschen; Setzen/Löschen von Flags; Suchen von Mails) Offline-Betrieb und Resynchronisation mit dem Server Vorteile Zugriff auf zentrale Mailbox von verschiedenen Arbeitsplätzen aus (gleiche Sicht unabhängig vom Standort) Inzwischen von allen gängigen Mail-Clients unterstützt

33 Lehrstuhl für Kommunikationssysteme - Systeme II33 Ende der siebten Vorlesung Ende der neunten Vorlesung Damit Abschluss der Applikationsschicht Implizit schon benutzt: TCP, UDP, Portnummern – Protokolle und Eigenschaften der Transportschicht Die Schicht zwischen IP und den Anwendungen

34 Lehrstuhl für Kommunikationssysteme - Systeme II34 Ende der siebten Vorlesung Ende der neunten Vorlesung Pfingstpause, weiter geht es am Montag, den 8.6. mit der praktischen Übung und am Mittwoch, den mit der nächsten Vorlesung Alle relevanten Informationen auf der Webseite zur Vorlesung: freiburg.de/php_veranstaltungsdetail.php?id=28 freiburg.de/php_veranstaltungsdetail.php?id=28 Vorbereitung: Lesen des Kapitels 3 im Kurose&Ross und zu Transportschicht in der angegebenen Literatur!


Herunterladen ppt "Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 9te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät."

Ähnliche Präsentationen


Google-Anzeigen