Zusammenfassung Web Technologie PDF

Preview

Summary

Web 2 Technologien Kommunikationsprotokolle HTTP und Das (World Wide Web) schnelles Wachstum durch Massentauglichkeit (1992: 10 1997: 1 Million 2017: 1800 Millionen Websites) Menge aller Webseiten, die das Internet von Webservern (Websites) abrufbar sind elektronisches Hypertextdokument Hypertext: V...

Description

Web 2.0 Technologien Kommunikationsprotokolle HTTP und TCP/IP Das WWW (World Wide Web) -

-

-

schnelles Wachstum durch Massentauglichkeit (1992: 10 Websites; 1997: 1 Million Websites; 2017: 1800 Millionen Websites) Menge aller Webseiten, die über das Internet von Webservern (Websites) abrufbar sind elektronisches Hypertextdokument  Hypertext: Verweist mit Hyperlinks auf andere Hypertexte (Webseiten verweisen typischerweise auf andere Webseiten) Format und Zugriff:  kodiert in HTML (+ CSS + …) (Format des Inhalts)  Zugriff meist über HTTP / HTTPS ... (Kommunikations-Protokoll)  … auf einen Webserver (Website) (Server erbringt somit einen Dienst) WWW ≠ Internet „Web 2.0“ ist nur ein Schlagwort (es deutet eine Verschiebung in der Art der breiten Nutzung an)  Web 1.0: Ziel: Zugriff auf alles von überall (Software, Bilder, …)  Web 2.0: Ziel: Jeder kann selbst aktiv werden (Wikipedia, YouTube, …)

Das Internet -

-

Daten werden Schritt für Schritt durch das Netz transportiert (Routing)  Man braucht nur eine einzige Verbindung um „im Internet“ zu sein und alle Dienste nutzen zu können  Datenpakete: per „Routing“ schrittweise zum Ziel gebracht, redundante Wege sichern Ausfallsicherheit Jeder Rechner im Internet kann mit jedem anderen eine Verbindung aufbauen  keine prinzipiellen Unterschiede zwischen den Endknoten Jeder Knoten kann Dienste anbieten oder nutzen Netzneutralität  Alle Daten werden im Internet gleichbehandelt  Kein Inhalt oder Teilnehmer wird bevorzugt oder diskriminiert

 Für das WWW brauchen wir Internet-Kommunikation - Adressieren - Ort und Name des Ziels - Befolgen der Regeln (Protokoll) und besitzen eines Anschlusses

1

Basis-Kommunikationsprotokolle des Internets -

-

IP („Internet Protocol“)  Transportiert einzelne Datenpakete begrenzter Größe von einem Rechner zum anderen (Analogie: Brief)  Adressierung: IP-Adresse (s.u.)  Verlust, Vertauschung, etc. wird nicht behandelt TCP („Transmission Control Protocol“)  Baut auf IP auf  Transportiert Datensequenzen beliebiger Länge (Löst Probleme wie Verlust, Duplikation, Vertauschung)

 Gemeinsam: TCP/IP  Eine TCP/IP-Verbindung durch das Internet führt  von der Client-Applikation (im Client-Host)  zur Server-Applikation (im Server-Host)  über eine Kette von Router-Knoten im Internet  Realisierung des Protokolls durch Protokollmaschinen (PM)  Dies stellen den Dienst („Kommunikation über TCP/IP“) bereit

IPv4 -

-

Ursprüngliches Adressierungsschema des Internets IPv4-Adressen:  4 Dezimalzahlen von 0...255, getrennt durch '.' (z.B.: 1.2.3.4 oder 131.246.120.130)  Adressraum: 28*4 = ca. 4,3*109 = 4,3 Milliarden Adressen Vorteil v4: Von jedem internetfähigem System unterstützt Problem: Adressraum wird knapp  Man kann nicht alle Adressen verwenden (da das Routing zur Reduktion der Tabellengrößen nur nach groben Adressbereichen erfolgt). Deshalb liegen viele Adressen in Netzen, in denen sie nicht gebraucht werden.  Lösung: NAT (Network Address Translation)  eine Technik, um hinter einer externen IP-Adresse viele Rechner zu „verstecken“ (typisch z.B. bei heimischen DSL-Routern)

2

IPv6 -

-

-

Seit 1998 in der Normierung, Mischbetrieb mit IPv4 IPv6-Adressen:  8*4er-Gruppen von Hexadezimalziffern, getrennt durch ':' z.B.: 2001:0638:0208:ef61:0000:00ff:fe00:0002  Adressraum: 24*4*8 = ca. 3,4*1038  führende Nullen können gruppenweise weggelassen werden: z.B. 2001:638:208:ef61:0:ff:fe00:2  Gruppen von Nullen können (einmalig!) mit '::' abgekürzt werden: z.B. 2001:0:0:0:ff:0:0:2 = 2001::ff:0:0:2 = 2001:0:0:0:ff::2 Vorteile:  Sehr großer Adressraum  eingebettete Verschlüsselung, Signatur von Daten und Headern Probleme:  wird nur sehr langsam eingeführt  NAT nicht möglich (Signatur von Headern verhindert Änderung von Adressen)

Namensdienst „Domain Name System“ (DNS) -

Liefert Adressen zu Namen und Namen zu Adressen Manueller Zugriff durch Tools wie „nslookup“(# ist der Poert) oder „host“ (auch „ping“)

-

Es werden auch weitere Informationen über DNS übertragen, z.B.  „www.uni-kl.de“ ist ein Alias für „wta-web.rhrk.uni-kl.de“ also beide Namen führen zur selben Adresse (IPv4 und IPv6)  Es werden Mailgates angegeben, über die Emails an diese Adresse verschickt werden.

Ports -

-

Eine IPv4- oder IPv6-Adresse identifiziert einen Rechner („Host“)  Genauer: Eine Netzwerk-Schnittstelle. Ein Rechner kann mehrere Netzwerk Schnittstellen haben und dadurch auch mehrere IP-Adressen Ein Rechner („Server-Host“) kann viele Dienste gleichzeitig anbieten oder nutzen  Um diese unterscheiden zu können, werden neben der IP-Adresse Portnummern benutzt. Diese liegen zwischen 1 und 216-1 = 65535  Als Notation benutzt man meist die dezimale Portnummer hinter einem ':' 3

z.B.: www.uni-kl.de:80 = 131.246.120.130:80 für Port 80 auf dem Rechner www.uni-kl.de Einem konkreten Dienst werden meist feste Portnummern zugeordnet  80 für http, 443 für https, 110 für pop3 Wenn man also den Server-Namen und den Dienst-Typen kennt, kann man die komplette Adresse incl. Portnummer bestimmen  z.B. 131.246.120.130:80 wenn man auf den http-Dienst von www.uni-kl.de zugreifen will 

-

TCP/IP -

-

-

TCP-Verbindungen liefern einen gegen Verlust und andere unerwünschte Effekte gesicherten Kommunikationskanal  Gesichert: nicht gegen gezielte Manipulation gesichert, sondern gegen normale Übertragungsfehler  Eine völlig manipulationssichere Verbindung erfordert kryptographische Techniken  Anmerkung: Es gibt im TCP/IP-Protokollstack auch noch andere Verbindungstypen, z.B. UDP. Diese ist nicht gegen Verlust gesichert. In dieser Vorlesung brauchen wir aber nur TCP Über diesen Kommunikationskanal können die Beteiligten Nachrichten in beide Richtungen austauschen  Nachrichten sind hier Texte beliebiger Länge Eine TCP-Verbindung (Kommunikationskanal) besteht zwischen den Endpunkten der Verbindung  Client: Endpunkt, der den Dienst nutzen will  Server: Endpunkt, der den Dienst anbietet  Die Endpunkte sind jeweils die Ports in den Rechnern (Hosts)  Man nennt aber im Sinne eines Dienstes auch den ganzen Rechner Client oder Server (z.B. Web-Server)  Die Betriebssystemen von Client und Server stellen die Endpunkte als Sockets bereit (Socket-API)

 Die Verbindung besteht also zwischen einem Port im Client (Client-Port) und einem Port im Server (Server-Port) (Die Nummer des Client-Ports wird normalerweise beim Verbindungsaufbau zufällig gewählt)

4

TCP/IP-Verbindungen: Unix-/Linux-Tools ( netcat) -

Das Unix-/Linux-Tool netcat ermöglicht es, beide Seiten einer TCP/IP-Verbindung einfach zu realisieren

 2 Terminals unter Linux öffnen  Die TCP/IP-Verbindung besteht jetzt - Eingaben, die auf einer Seite gemacht werden, erscheinen auf der jeweils anderen Seite - Zum Beenden Strg-D Drücken, dann terminieren beide netcat-Instanzen - „-v“ aktiviert die Statusmeldungen - „-l“ aktiviert den Server-Mode

TCP/IP-Verbindungen: Unix-/Linux-Tools ( socat) -

Das Unix-/Linux-Tool socat („Socket-Cat“) hat noch zusätzliche Funktionen, ist aber etwas komplexer in der Bedienung (kann Daten transformieren)

-

Hostname „localhost“ 5

  

-

auf jedem Rechner existiert ein spezieller virtueller Netzwerkadapter mit der Adresse „localhost“ IPv4: localhost = 127.0.0.1 IPV6: localhost = ::1 Wenn man mit einem Prozess auf demselben Rechner kommunizieren will, kann man diese als Adresse nutzen

Binden von Server-Sockets an Adressen  Beim Erwarten von Verbindungen (listen) kann der Server einen Netzwerkadapter angeben, von dem die Verbindung kommen darf  Dazu gibt man die IP-Adresse eines eigenen Adapters an  Typische Anwendung: Dienste nur für den eigenen Host anbieten

Zugriff auf Webseiten -

Zugriff auf Webserver erfolgt per HTTP / HTTPS  Aufgabe des Web-Browsers (z.B. Firefox, Chrome, Safari, IE, …)  Realisierung als HTTP-Protokollmaschine (HTTP-PM)

-

HTTP-Protokoll  Kommunikationsprotokoll  zwischen Web-Client und Web-Server  Client und Server tauschen Nachrichten aus  Client sendet Requests  Server antwortet mit Responses  Requests und Responses bestehen aus  Header-Zeilen (Text)  Nutzlast (Text oder Binärdaten)  HTTP baut auf TCP/IP auf  Die ausgetauschten Nachrichten werden über TCP/IP übertragen  Wird realisiert vom Web-Client (Browser) und Web-Server  darüber liegende Schichten nutzen / erzeugen die Inhalte der Nachrichten

Ablauf (aus Sicht des Clients): 6

1. Schicht: TCP-Verbindung (Internet) - Verbindungs-Ziel: IP-Adresse + Port  z.B. Port 80 von www.uni-kl.de (Schreibweise: www.uni-kl.de:80) - Ergebnis: TCP-Verbindung zum Web-Server

2.

Schicht: HTTP-Protokoll - Anfrage des Clients an den Server (Request)  Request-Header  Gewünschte Funktion, Pfad  weitere Parameter, Kodierung, Formate - Antwort vom Server (Response)  Response-Header  Response-Status (z.B. 200 für „o.k.“)  weitere Parameter, Kodierung, Formate  Body (Nutzlast, also die angefragten Daten, z.B. der HTML-Text)  Kann auch in einem Request vorkommen (z.B. für File-Upload) - Das HTTP-Protokoll an sich ist zustandslos  Die HTTP-Engine des Servers vergisst sofort nach der Antwort die Informationen aus der letzten Anfrage  Entsprechend muss der Client bei jeder Anfrage alles mitliefern was der Server über ihn wissen muss.

3. Schicht: HTML-Rendering - Ziel: Darstellung der übertragenen Inhalte, interaktive Nutzung - Ggf. per HTTP weitere Inhalte holen (Bilder, CSS, …)  Neue TCP-Verbindung oder ggf. noch bestehende weiterverwenden - Ggf. enthaltenen Javascript-Code ausführen  Javascript-Code kann ebenfalls weitere HTTP-Anfragen erzeugen - Erhaltene Inhalte für den Nutzer darstellen (Page-Rendering)

4. Schicht: Lokale Interaktion mit dem Nutzer - Nutzer interagiert ohne Server-Kommunikation  Mit Javascript können weitere Anfragen erfolgen - Nutzer ruft schließlich nächste Webseite auf  Durch Aufrufen eines Links  Durch Abschicken eines lokal ausgefüllten Formulars - Nächste Webseite laden ...  Neue TCP-Verbindung oder ggf. noch bestehende weiterverwende

Simulation eines WEBSERVERS mit socat 7

REQUEST -

Server wartet auf Port 80  80 ist Standard-Port für http

-

Problem: Ports unter 1024 sind geschützt  Man braucht besondere Berechtigungen um hier Dienste anzubieten Lösung: High-Ports [1024 … 65535] benutzen  Einen (derzeit freien) Port aussuchen und explizit angeben  Problem bei „beliebten“ Portnummern auf Mehrbenutzersystemen (z.B. 1234, 8000, 8888, …)  Ein auf dem Host gerade benutzter Port ist nicht erlaubt  Ports können nach einem Verbindungsabbruch noch einige Zeit blockiert bleiben

-

-

Server wartet auf einem High-Port

-

Wir greifen auf unseren „Webserver“ zu  Im Browser eingeben http://localhost:12345/test/

-

Das ist also die Frage („Request“), die uns (als simulierter Webserver) der Browser (als Webclient) stellt Der Browser wartet nun auf eine Antwort

-

RESPONSE 8

Was würde der Webserver denn antworten?  Idee: Wir „belauschen“ die Kommunikation, dazu bauen wir mit socat eine „Abhörstation“ (Man in the Middle) -

Der Browser (Client) verbindet sich also mit dem socat (Man in the Middle) socat verbindet sich mit dem Web-Server socat reicht alle Anfragen in beide Richtungen weiter

Was bedeuten die „\r“? -

-

-

Zeilenumbrüche werden auf verschiedenen Systemen unterschiedlich kodiert Dabei werden zwei ASCII-Codes verwendet:  „\r“ = Carriage-Return (cr) → „Ganz nach links“  „\n“ = Newline / Linefeed (nl) → „Eine Zeile weiter“ Typische Zeichenkombinationen für ein Zeilenende:  „\r\n“ = Carriage-Return + Newline (crnl)  „\n“ = nur Newline (nl) Die Webstandards benutzen crnl  Leider benutzt Unix nur nl.  Daher rufen wir socat bei Eingabe von Konsole später mit einer Option auf, die die Umwandlung automatisch macht:

Simulation eines WEBCLIENTS mit socat 9

Trick: Ein- und Ausgaben von socat über Dateien -

Problem: Die manuelle Eingabe ist fehleranfällig und man bekommt schnell Probleme mit dem Timeout Lösung: Text-Dateien benutzen

 Anfragen in einer Datei vorbereiten  Der Anfrage wird aus der Datei request.txt gelesen („< ...“) (der Inhalt der Datei dient als Eingabe von socat)  Die Antwort wird in die Datei response.txt geschrieben („> ...“) (die Ausgabe von socat wird in die Datei umgeleitet)

HTTP-Protokoll von Hand 10

-

-

Wir haben uns bisher (mit dem Programm socat) angeschaut, wie Client und Server per HTTP kommunizieren Dazu müssen wir als Client ...  Request-Header erzeugen und  Response-Header verstehen Das wollen wir aber ja nicht immer so machen

Programmierter Einsatz des HTTP-Protokolls -

Es gibt verschiedene Ebenen, auf denen man HTTP in Programmen einsetzen kann Wir betrachten nun 3 Beispiele in der Programmiersprache Python

11

1.2 Das http Protokoll

12

Das http Protokoll   

Die Internet-Protokolle werden in RFCs („Request for Comments“) beschrieben -> Die RFCs definieren alle Internet-Standards, z.B. auch TCP/IP RFC 1945: HTTP/1.0, (1996) RFC 2616: HTTP/1.1, (1999)

HTTP/1.1 -

Ist die aktuell von fast allen Browsern und Servern genutzte HTTP-Version Wichtigster Unterschied zu HTTP/1.0: Einführung von „Connection: keep-alive“ (Nutzung einer TCP-Verbindung für mehrere Request-Response-Durchläufe)  Das Hauptdokument zu HTTP/1.1 (RFC 2616) ist über 10.000 Zeilen lang (176 Seiten)  Die Syntax-Regeln sind in EBNF (Erweiterte Backus-Naur-Form) angegeben

EBNF -

-

-

Erweiterte Backus-Naur-Form (EBNF)  Notation zur Definition einer kontextfreien Grammatik  Beschreibt also Regel zum Aufbau / der Analyse von Texten Elemente und Regeln  Terminale: bedeuten sich selbst (sog. Literale) -> z.B. „1“ oder „GET“  Nichtterminale: Geben an, wie komplexere Strukturen nach Produktionsregeln aufgebaut werden -> z.B. Binärziffer = „0“ | „1“ -> z.B. Binärzahl = Binärziffer | Binärzahl Binärziffer Standard-Dokumente verwenden oft eigene Varianten

Syntax einer HTTP-Nachricht

-

„|“ bedeutet „oder“ Also: jede HTTP-Message ist ein Request oder ein Response  Request und Resonse sind ebenfalls über Regeln definiert (Nichtterminale)  Nichtterminale sind jeweils anderweitig definiert

13

Das HTTP-Protokoll: REQUEST

-

Jeder Request beginnt mit einer Request-Line Dann kommt eine beliebige Anzahl („*“) von  General-Headern ODER  Request-Headern ODER  Entity-Headern  die jeweils mit CRLF enden (CRLF ist ein Zeilenumbruch, ASCII 10 und 13) - Dann kommt eine Leerzeile (nur CRLF) - Dann kann („[“ … „]“) ein Message-Body kommen

14

Das HTTP-Protokoll: RESPONSE

-

Der Response unterscheidet sich an zwei Stellen vom Request  Statt request-line kommt hier eine Status-line vor  Statt request-header kommt hier ein response-header vor

15

Status-Code Kategorien (Response) 1xx: Informational  Request received, continuing process 2xx: Success  The action was successfully received, understood, and accepted 3xx: Redirection  Further action must be taken in order to complete the request 4xx: Client Error  The request contains bad syntax or cannot be fulfilled 5xx: Server Error  The server failed to fulfill an apparently valid request

Wichtige Status-Codes (Response) 200 OK  Zugriff war erfolgreich 301 Moved Permanently 307 Temporary Redirect  Die URL ist nicht mehr gültig, es gibt aber einen neuen Ort  Der die neue URL wird im Location-Response-Header angegeben Location = "Location" ":" absoluteURI 404 Not Found  Die URL ist nicht gültig, es wird keine Alternative mitgeteilt 401 Unauthorized  Der Client darf nicht auf die Seite zugreifen 400 Bad Request 500 Internal Server Error

16

Adressen im WWW: URL / URI URI -

URI (Uniform Resource Identifier) identifiziert eine Ressource Spezifikation: RFC 3986 Format: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

URL und URN URL (Uniform Resource Locator) -

Spezielle URI lokalisiert eine Ressource Beispiel: http://www.cs.uni-kl.de/aktuelles Spezifikationen: RFC 1738, RFC 1808, ...

URN (Uniform Resource Name) -

Spezielle URI Dauerhafte, ortsunabhängige Bezeichnung (identifiziert sie auch → ist immer auch eine URI) Beispiel: urn:isbn:0321751043

Ursprungsidee -

Jede URI ist entweder URL oder URN (stimmt nicht mehr ganz)

URL-Schemata (gemäß RFC 1738) -

ftp http mailto file

File Transfer protocol Hypertext Transfer Protocol Electronic mail address Host-specific file names

17

Adressen

HTTP-URL -

Identifiziert Ort und Zugriffsmethode auf z.B. eine Webseite

18

URL-Pfade -

Idee: Die Pfadangabe gibt einen Knoten in einem Verzeichnisbaum an  In dem Baum gibt es  Verzeichnisse (enden mit „/“)  Dateien (enden nicht so)

URL-Pfade normalisieren -

-

-

In dem Pfad kann man aber nicht nur nach „unten“ gehen:  „./“ (auf der Stelle gehen)  „../“ einen Schritt nach oben gehen Beispiele:  „/a/u/./“ entspricht „/a/u/“  „/a/u/../“ entspricht „/a/“ Diese Elemente sind auflösbar.  man möchte sie entfernen  „Pfad-Normalisierung“  Regeln dazu in Abschnitt 4 (Step 6) von RFC 1808

Relative URL-Pfade -

-

Diese enthalten nur einen Teil eines Pfades  Fangen nicht mit „/“ an  z.B. „a/b“ oder „../u/x“ Diese beziehen sich auf eine Basis-URL Relative URLs können anhand der Basis-URL zu einer absoluten URL vervollständigt werden  Regeln dazu im RFC 1808

19

Relative URLs Die Basis-URL innerhalb einer Webseite ist z.B. die URL, von der sie geladen wurde (siehe RFC 1808, Abschnitt 3 + 10)  oder kann mit einem Base-Header in HTTP gesetzt werden  oder kann mit einem Base-Element in HTML gesetzt werden

Dateien vs. Verzeichnisse -

Sonderbehandlung bei Basis-URLs, deren Pfad nicht mit "/" endet  Das letzte Pfadelement der Basis-URL bezeichnet dann (vermutlich) eine Datei. (Der Web-Client kann das ja nicht sicher wissen.)

Binäre IPv4-Adressen in URLs Binäre IP-Adressen sind als Hostnamen ebenfalls erlaubt Beispiel: http://127.0.0.1:80/test → kein Problem, Verwendung wie Hostnamen

Binäre IPv6-Adressen in URLs Beispiel: http://10::20:88/test  Problem: Adressiert das nun … - Port 80 auf IPv6-Adresse 10::20:88 oder - Port 88 auf IPv6-Adresse 10::20? Daher ist diese Form nicht erlaubt  Syntaktisch korrekt: http://[10::20]:88/test  IPv6-Adressen werden in URLs in eckige Klammern eingefasst 20

Authentication Zugriffsbeschränkung -

-

Manche Inhalte sollen nur für bestimmte Nutzergruppen zugänglich sein  Kriterien: Person am Client, Ort des Clients, bestimmter Host, …  Zugriffsziele: URLs (z.B. Teilbäume unterhalb eines Pfades) Idee: Zwei Aspekte ...  Authentifizierung (engl. „Authentication“)  Frage: „Wer greift dazu? (Subjekt)  Wichtiger Aspekt: Manipulationssicherheit (Clients können lügen!!!)  Autorisierung (engl. „Authorization“)  Fragen: „Worauf greift er zu?“ (Objekt), „Darf der das?“ (Zugriffsrecht)

Analogie im Betriebsystembereich: User / Userrechte Authentifizierung = „Wer will da ...“ (...