26

RVS (Fach) / RvS2 (Lektion)

Diese Lektion wurde von blumenkohl erstellt.

Lektion lernen

Diese Lektion ist leider nicht zum lernen freigegeben.

zurück  |  weiter 1 / 1

• Client/Server-Paradigma Client: Initiiert Kontakt mit dem Server Fordert einen Dienst vom Server an Server: Bietet dem Client Dienstleistungen an
• Peer-to-Peer-Paradigma Anwendungen bestehen aus gleichartigen Teilen Peers (auch Agenten genannt) Skalierbarkeit: +Keine zentralen Funktionen benötigt -Verwaltung von vielen Peer-Peer-Assoziationen   Peers wirken für andere Peers als Server und umgekehrt
• Anwendungen und Anwendungsprotokolle Anwendung: Anwendungsprozesse werden in Endsystemen (Hosts) ausgeführt Sie tauschen Anwendungsnachrichten aus Anwendungsprotokolle: Legen Syntax und Semantik der Anwendungsnachrichten fest Legen Ablauf des Nachrichtenaustauschs fest
• Schnittstelle zum Transportsystem Ein Anwendungsprozess kommuniziert (sendet/empfängt) über das Netz durch eine Software-Schnittstelle, ein so genanntes Socket Programmierschnittstelle API (Application Programming Interface)
• Adressierung Jeder Host hat eindeutige IP-Adresse. Paar aus IP-Adresse für Rechner und Port-Nummer für Anwendung. Beispiele: Echo-Server: TCP- oder UDP-Port 7 HTTP-Server: TCP-Port 80 SMTP-Mail-Server: TCP-Port 25 POP3-Mail-Server:TCP-Port 110
• Anwendungsanforderungen an Transportdienst Zuverlässigkeit beim Datentransfer Einige Anwendungen erfordern hohe Zuverlässigkeit (z.B. Dateitransfer). Andere können einen gewissen Datenverlust verkraften (z.B. Audio-Übertragungen). Zeitverhalten Einige Anwendungen verlangen die Einhaltung von Zeitschranken (z.B. Steuerungen, Spiele) andere verkraften auch längere Verzögerungen (z.B. Email, Dateitransfer) Bandbreite Einige Anwendungen benötigen eine gewisse minimale Bandbreite (z.B. Multimedia). Andere (elastische) Anwendungen nutzen die Bandbreite, die verfügbar ist (z.B. Dateitransfer) Sicherheit Einige Anwendungen haben hohe Sicherheitsanforderungen (z.B. E-Banking) Andere nutzen nur allgemein einsehbare Daten (z.B. Fernsehen über Internet) Interaktion mit anderen Anwendungen Manche Anwendungen sollen andere nicht beeinflussen (z.B. Monitoring)
• TCP und UDP TCP verbindungsorientiert zuverlässiger Transport Flusskontrolle Überlastkontrolle kein Timing keine garantierte Bandbreite UDP nicht verbindungsorientiert unzuverlässiger Transport keine Fluss- und Überlastkontrolle kein Timing keine garantierte Bandbreite
• HTTP Client-Server Client: Browser fordert WWW-Objekte an, empfängt sie und stellt sie dar. Server: WWW-Server sendet enstprechende Objekte Benutzt TCP Client initiiert TCP-Verbindung zum Server Server akzeptiert Verbindung HTTP-Pakete werden ausgetauscht TCP-Verbindung wird beendet Zustandtslos Server speichert keine Informationen über vorangegangene Verbindungen
• Nonpersistent-/Persistent-HTTP Nonpersistent-HTTP Maximal ein Objekt kann pro Verbindung übertragen werden HTTP/1.0 benutzt Nonpersistent-HTTP Persistent-HTTP Mehrere Objekte könne pro Verbindung übertragen werden Persistent-HTTP ohne Pipelining Der Client fordert erst ein neues Objekt an, nachdem das vorangehende empfangen wurde. Persistent-HTTP mit Pipelining Der Client fordert ein neues Objekt an, sobald er auf eine Referenz stößt. HTTP/1.1 benutzt Persistent-HTTP mit Pipelining im Default-Modus
• HTTP-PDUs Nachrichten sind Request- oder Response-Nachrichten Response-Status-Codes 200 OK 301 Moved Permanently 400 Bad request 404 Not Found 505 HTTP Version Not Supported
• Anzeige
• HTTP-Operationen (GET), Caching, Conditional Get GET-Methode: Fordert das Objekt mit gegebener URL an Caching: Landen von Seiten kann aufwändig/langwierig sein => Caching im Browser => Caching im Proxy-Server Conditional GET: Ziel: Sende angefordertes Objekt nicht, wenn Client bereits eine aktuelle Version im Cache hat. Client (u.U. Proxy) sendet das Datum seiner Kopie mit)  
• Authentifikation und Autorisierung Authentifikation Client gibt Id an und Beweis dafür, dass er es auch ist. Autorisierung Zugriff für Client nur im Rahmen der ihm zugewiesenen Privilegien.   Üblicher Ansatz: Benutzername, Passwort, IP-Adresse Zustandslos: Client muss Autorisierung in jeder Anfrage präsentieren
• Zustandsspeicherung mit Cookies Basiskomponenten: 1. Cookie-Zeile im Header der HTTP-Response Nachricht 2. Cookie-Zeile in der HTTP-Request Nachricht 3. Cookie-Datei auf dem Benutzerrechner, vom Browser verwaltet 4. Datenbank mit Cookies auf Server-Seite Vorteile Autorisierung Einkaufsarten (Speichern von Käufen, Bezahlung,...) Empfehlungen Zustand einer Benutzersitzung Nachteile Cookies übermitteln Informationen Bei jedem neuen Zugriff kann die vorhandene Information ergänzt werden. Suchmaschienen nutzen Cookies um über Nutzer zu lernen Informationen können an Dritte weitergegebene werden.  
• FTP - Seperate Kontroll- und Datenverbindungen FTP Client ruft FTP Server über Port 21 auf und spezifiziert TCP als Transportprotokoll. Client autorisiert sich über die Kontrollverbindung. Client kann sich die Verzeichnisse des Servers mittels der Kontrollkommandos ansehen. Dateitransfer führt zur Öffnung einer TCP-Datenverbindung. (Port 20) Nach dem Transfer schließt der Server die Datenverbindung. Server öffnet eine neue Datenverbindung zur Übertragung der nächsten Datei. Server speichert den Zustand des Clients (Verzeichnis, Authentifizierung). FTP sendet Kontrollinformation seperat (out of band) im Gegensatz zu HTTP (in band)  
• FTP - Kommandos und Antworten Einige Kommandos Nach dem Aufruf "ftp <hostname>" muss das Password eingegeben werden. "binary" setzt den Übertragungsmodus auf binär (statt ASCII) "ls" listst das entfernte Verzeichnis. "put" überträgt eine Datei zum entfernten Rechner. "get" überträgt eine Datei vom entfernten Rechner. Einige Rückgabewerte Jedes Kommando wird vom Server per Reply beantwortet. Verwendete Statuscodes: 331 Username ok, password required 125 Data connection already open; transfer starting 425 Can't open data connection 452 error writing file   FTP ist "altes" Protokoll, hat schwerwiegende Sicherheitsmängel (z.B. unverschlüsselte Passwortübertragung, unverschlüsselte Dateiübertragung)
• E-MAIL: Protokolle SMTP: Simple Mail Transfer Protocol Benutzt TCP, um E-Mails vom Sender (Mail Server des Senders) zum Empfänger (Mail Server des Empfängers) zu transferieren. 3 Phasen: Handshake Nachrichtentransfer Beenden der Verbindung 7-bit ASCII-Format zeilenweise organisiert. Empfangen von Emails Mail-Server speichert empfangene Emails. User-Agenten greifen auf die Emails zu, durch POP: Post Office Protocol Autorisierung und Download IMAP: Internet Mail Access Protocol Komplexer und variantenreicher
• E-Mail: MIME - Multimedia Mail Extensions Multimedia-Daten oder auf kodierte Daten können nicht direkt per Email verschickt werden, da sie nicht ASCII-kodiert sind. Lösung MIME-Format Beim Sender: Daten ins ASCII kodieren. MIME Header hinzufügen, in welchem das Dateiformat angegeben ist. Beim Empfänger: Interpretation des MIME Headers. Decodierung des ASCII-Textes. Aufruf des zugehörigen Programms zum Anzeigen der Daten.
• DNS - Domain Name System Verteilte Datenbank implementiert eine Hierarchie von Name-Servern. Protokoll der Anwendungsschicht zur Übersetzung Name <-> IP Adresse. Zentraler Dienst des Internets auf der Anwendungsebene realisiert. DNS-Namen werden von rechts nach links abgearbeitet. Namenshierarchie kann als Baum visualisiert werden. Blätter sind Rechnernamen, Innere Knoten gehören zu Domains
• Warum kein zentrales DNS? Zentraler Ausfallpunkt Großes Verkehrsaufkommen Weit entfernte Datenbank Schlechte Wartbarkeit
• DNS: Nameserver-Hierarchie Im DNS hat kein Server alle Abbildungen von Namen auf IP-Adressen. Lokale Name-Server Gehören zu einem ISP. (local (default) name server) Jede Anfrage wird erst zum lokalen Server geleitet. Root Name-Server Einige wenige, meist in den USA, empfangen Anfangen von lokalen Name-Servern. Autorative Name-Server Jeder Host gehört zu einem autorativen Name-Server, der seine Adresse verbindlich speichert. Antwortet auf Anfragen bzgl. zugehöriger Hosts.
• DNS: Root Name Server Werden von lokalen Name-Servern kontaktiert, wenn diese eine Adresse/einen Namen nicht auflösen können. Root Name-Server (13 Weltweit) fragen den zugehörigen autorativen Name-Server, falls sie die Adresse nicht kennen. erhalten von diesem die Abbildung und leiten sie an den lokalen Name-Server weiter. Falls der zugehörige autorative Name-Server nicht bekannt, Nachfrage bei intermediate Name-Server, um autorativen Name-Server zu finden.
• DNS: Anfrage-Ketten Rekursive Anfrage: Angefragter Name-Server ist für die Auflösung der Adresse verantwortlich. Dies kann zu zahlreichen weiteren Anfragen und hoher Last führen. Iterative Anfrage: Angefragter Server antwortet mit der Adresse des nächsten Name-Servers. Fragender Server kontaktiert direkt diesen Server.
• DNS: Caching und Aktualisierung Nachdem ein Name-Server eine Abbildung Name <-> IP Adresse erhalten hat, speichert er diese im Cache. Einträge im Cache, die nicht nachgefragt wurden, werden nach einer Zeitspanne wieder gelöscht. Struktur der Einträge (Name, Wert, Typ, TTL) Typ A Name IP-Adresse beschreiben die Abbildung Typ NS Name beschreibt eine Domain und IP Adresse die Adresse des autorativen Servers Typ CNAME Name ist ein Alias-Name und Wert der vollständige Name Typ MX Name ist ein Alias-Name für einen Mail-Server und Wert ist der vollständige Name TTL time to live
• Sockets: Kommunikations-API API erlaubt die Wahl des Trasportprotokolls und das Setzen einiger Parameter. Elemente der logischen Architektur SAP (Service Access Point) und CEP (Connection Endpoint) Elemente der Implementierung Sockets, Programmschnittstellen-Elemente zum Kommunikationssystem, implementieren SAPs und CEPs; Netz-E/A = Socket-E/A ähnlich Datei E/A. Socket hat Filedeskriptornummer (Socket-ID ist FD)  
• TCP-Sockets Client initiiert den Verbindungsaufbau. Server-Prozess muss dazu laufen. Server muss einen Socket generiert haben. Client muss Server-Adresse kennen (IP-Adresse, Portnr.) Generiert TCP-Socket. Spezifiziert die IP-Adresse und die Port-Nummer des Server-Sockets zur Kontaktaufnahme. Client fordert den Aufbau einer TCP-Verbindung an. Mit dem Verbindungsaufbau generiert der Server einen neuen Socket zur Kommunikation mit dem Client. (so kann Server nebenläufig mit meheren Clients kommunizieren) Anwendungssicht TCP bietet eine zuverlässige, reihenfolgentreue Verbindung
• UDP-Sockets UDP nutzt keine Verbindung zwischen Client und Server. Kein Verbindungsauf- und abbau. Sender muss mit jedem Senden die IP-Adresse und Port-Nummer des Empfängers angeben. Empfänger erfährt die IP-Adresse und Port-Nummer des Senders aus dem empfangenen Datagram. Anwendungssicht: UDP bietet nur eine unzuverlässige Nachrichtenübertragung. Daten können in falscher Reihenfolge ankommen oder ohne Anzeige ganz verloren gehen.

zurück  |  weiter 1 / 1