Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger

 << zurück
Java ist auch eine Insel von Christian Ullenboom
Programmieren für die Java 2-Plattform in der Version 5
Java ist auch eine Insel

Java ist auch eine Insel
5., akt. und erw. Auflage
1454 S., mit CD, 49,90 Euro
Galileo Computing
ISBN 3-89842-747-1
gp Kapitel 16 Das Netz
  gp 16.1 Grundlegende Begriffe
    gp 16.1.1 Internet-Standards und RFC
  gp 16.2 URI und URL
    gp 16.2.1 URI
    gp 16.2.2 Die Klasse URL
    gp 16.2.3 Informationen über eine URL
    gp 16.2.4 Der Zugriff auf die Daten über die Klasse URL
    gp 16.2.5 Verbindungen durch einen Proxy-Server
  gp 16.3 Die Klasse URLConnection
    gp 16.3.1 Methoden und Anwendung von URLConnection
    gp 16.3.2 Protokoll- und Content-Handler
    gp 16.3.3 Bilder-Handler
    gp 16.3.4 Zusammenfassung Content- und Protokoll-Handler
    gp 16.3.5 Im Detail: vom URL zu URLConnection
    gp 16.3.6 Der Protokoll-Handler für Jar-Dateien
    gp 16.3.7 Autorisierte URL-Verbindungen und Proxy-Authentifizierung mit Basic Authentication
  gp 16.4 Das Common Gateway Interface
    gp 16.4.1 Parameter für ein CGI-Programm
    gp 16.4.2 Kodieren der Parameter für CGI-Programme
    gp 16.4.3 Eine Suchmaschine ansprechen
  gp 16.5 Host- und IP-Adressen
    gp 16.5.1 Lebt der Rechner?
    gp 16.5.2 Das Netz ist Klasse …
    gp 16.5.3 IP-Adresse des lokalen Hosts
  gp 16.6 NetworkInterface
  gp 16.7 Mit dem Socket zum Server
    gp 16.7.1 Das Netzwerk ist der Computer
    gp 16.7.2 Sockets
    gp 16.7.3 Standarddienste unter Windows nachinstallieren
    gp 16.7.4 Eine Verbindung zum Server aufbauen
    gp 16.7.5 Server unter Spannung: die Ströme
    gp 16.7.6 Die Verbindung wieder abbauen
    gp 16.7.7 Ein kleines Echo – lebt der Rechner noch?
    gp 16.7.8 Blockierendes Lesen
    gp 16.7.9 Informationen über den Socket
    gp 16.7.10 Mit telnet an den Ports horchen
    gp 16.7.11 Reine Verbindungsdaten über SocketAddress
  gp 16.8 Client/Server-Kommunikation
    gp 16.8.1 Warten auf Verbindungen
    gp 16.8.2 Ein Multiplikations-Server
    gp 16.8.3 Von außen erreichbar sein
  gp 16.9 SSL-Verbindungen mit JSSE
  gp 16.10 Apache Jakarta Commons HttpClient und Net
    gp 16.10.1 Jakarta Commons HttpClient
    gp 16.10.2 Jakarta Commons Net
  gp 16.11 E-Mail
    gp 16.11.1 Wie eine E-Mail um die Welt geht
    gp 16.11.2 Das Simple Mail Transfer Protocol und RFC 822
    gp 16.11.3 POP (Post Office Protocol)
    gp 16.11.4 E-Mails versenden mit der JavaMail API von SUN
    gp 16.11.5 MimeMultipart-Nachrichten schicken
    gp 16.11.6 E-Mails mittels POP3 abrufen
    gp 16.11.7 Ereignisse und Suchen
  gp 16.12 Arbeitsweise eines Web-Servers
    gp 16.12.1 Das Hypertext Transfer Protocol (HTTP)
    gp 16.12.2 Anfragen an den Server
    gp 16.12.3 Die Antworten vom Server
  gp 16.13 Datagram-Sockets
    gp 16.13.1 Die Klasse DatagramSocket
    gp 16.13.2 Datagramme und die Klasse DatagramPacket
    gp 16.13.3 Auf ein hereinkommendes Paket warten
    gp 16.13.4 Ein Paket zum Senden vorbereiten
    gp 16.13.5 Methoden der Klasse DatagramPacket
    gp 16.13.6 Das Paket senden
  gp 16.14 Tiefer liegende Netzwerkeigenschaften
    gp 16.14.1 Internet Control Message Protocol (ICMP)
    gp 16.14.2 MAC-Adresse
  gp 16.15 Multicast-Kommunikation


Galileo Computing

16.12 Arbeitsweise eines Web-Serverdowntop

In diesem Kapitel lernen wir die Grundlagen eines Web-Servers kennen. Dazu besprechen wir zunächst das Protokoll HTTP, auf dem das Web basiert. Detaillierte Informationen aus Server-Sicht werden im Servlet-Kapitel beschrieben. Hier betrachten wir nur die Client-Seite.


Galileo Computing

16.12.1 Das Hypertext Transfer Protocol (HTTP)  downtop

Das HTTP ist ein Protokoll für Hypermedia-Systeme und im RFC 2616 genau beschrieben. HTTP wird seit dem Aufkommen des World Wide Web – Näheres dazu unter http:// www.w3.org/ – intensiv genutzt. Das Web basiert auf der Seitenbeschreibungssprache HTML, die 1992 von Tim Berners-Lee entwickelt wurde. Die Entwicklung wurde am CERN vorgenommen, und seit den Prototypen ist die Entwicklung nicht nur im Bereich HTML fortgeschritten, sondern auch im Protokoll. Berners-Lee ist mit seiner Erfindung allerdings nicht reich geworden, da er ohne Patent- oder Copyright-Ansprüche nur ein Werkzeug zur Veröffentlichung wissenschaftlicher Berichte ermöglichen wollte.

HTTP definiert eine Kommunikation zwischen Client und Server. Typischerweise horcht der Server auf Port 80 (oder 8080) auf Anfragen des Clients. Das Protokoll benutzt eine TCP/IP-Socket-Verbindung und ist deutlich textbasiert. Alle HTTP-Anfragen haben ein allgemeines Format:

gp  Eine Zeile am Anfang
    Dies kann entweder eine Anfrage (also eine Nachricht vom Client) oder eine Antwort vom Server sein.
       
gp  Einige Kopf-Zeilen (engl. header)
    Informationen über den Client oder Server, zum Beispiel über den Inhalt. Der Header endet immer mit einer Leerzeile.
       
gp  Einen Körper (engl. body)
    Der Inhalt der Nachricht. Entweder Benutzerdaten vom Client oder die Antwort vom Server
       

Dieses Protokoll ist also sehr einfach und auch unabhängig von Datentypen. Was es ideal einsetzbar für verteilte Hypermedia-Informationssysteme macht.


Galileo Computing

16.12.2 Anfragen an den Server  downtop

Ist die Verbindung aufgebaut, wird eine Anfrage formuliert, auf welches Objekt (Dokument oder Programm) zugegriffen werden soll. Neben der Anfrage wird auch das Protokoll festgelegt, mit dem übertragen wird. HTTP 1.0 (und ebenso HTTP 1.1) definiert mehrere Hauptmethoden, von denen drei zu den wichtigsten gehören.

gp  GET. Dies ist eine Anfrage auf eine Information, die an einer bestimmten Stelle lokalisiert ist. Ein Client kann auch Daten zum Server schicken, indem er sie an die URL anhängt.
gp  POST. Die POST-Methode erlaubt es dem Client, Daten über einen Datenstrom zum Server zu schicken.
gp  HEAD. Funktioniert ähnlich wie GET, nur dass nicht das gesamte Dokument verschickt wird, sondern allein Informationen über das Objekt. So sendet diese Methode zum Beispiel innerhalb einer HTML-Seite die innerhalb von <HEAD>....</HEAD> befindlichen Informationen.

Eine Beispielanfrage an einen Web-Server

Hier ein typisches Beispiel einer GET-Anfrage vom Client an den Standard-Web-Server:

GET /directory/index.html HTTP/1.1

Das erste Wort ist die Methode des Aufrufs (auch Anfrage, engl. request). Neben den drei oben aufgeführten Methoden GET, POST und HEAD gibt es noch weitere, meist finden diese jedoch nur bei speziellen Anwendungen Verwendung.


Tabelle 16.3   Einige Anfragemethoden von HTTP

Methode Aufgabe
GET Liefert eine Datei.
HEAD Liefert nur Dateiinformationen.
POST Sendet Daten zum Server.
PUT Sendet Dateien zum Server.
DELETE Löscht eine Ressource.

Die zweite Angabe bei der Anfrage an den Server ist der Dateipfad. Er ist als relative Pfad-angabe zu sehen und folgt hinter der Methode.


URL Erzeugte Anfrage
www.trallala.com/ GET / HTTP/1.1
www.trallala.com/../index.html GET /../index.html HTTP/1.1
www.trallala.com/classes/applet.html GET /classes/applet.html HTTP/1.1

Die Anfrage endet bei einer Leerzeile (Zeile, die nur ein Carriage-Return (\r) und ein Linefeed (\n) enthält).


Beispiel   Wir können das in einer Telnet-Sitzung einfach testen. Starten wir zunächst eine Telnet-Sitzung:
$ telnet java-tutor.com 80
Anschließend fordern wir mit GET /aufgaben/bond.txt HTTP/1.0 eine Datei an. Es folgt eine lange Ausgabe:
HTTP/1.1 200 OK
Date: Sun, 10 Feb 2002 18:20:01 GMT
Server: Apache/1.3.19 (Unix) FrontPage/4.0.4.3
Last-Modified: Mon, 12 Jun 2000 11:41:03 GMT
ETag: "1db3c8–28e-3944cc4f"
Accept-Ranges: bytes
Content-Length: 654
Connection: close
Content-Type: text/plain
From Englands INDEPENDENT:
...

Abbildung
Hier klicken, um das Bild zu Vergrößern

Abbildung 16.2   GET-Anfrage über telnet an einen Web-Server

Wenn die GET-Anfrage falsch formuliert oder die Datei nicht vorhanden ist, folgt eine Fehlerausgabe:

Abbildung
Hier klicken, um das Bild zu Vergrößern

Abbildung 16.3   Ungültige Anfrage

Nach der Zeile mit der Anfrage können optionale Zeilen gesendet werden. So stellt der Netscape Navigator 2.0 (also der Client) an den Server beispielsweise die folgende Anfrage:

GET / HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/2.0 (Win95; I)
Host: merlin
Accept: image/gifimage/x-xbitmapimage/jpegimage/pjpeg*/*

Hier sehen wir, dass durch diese Plauderei leicht Statistiken vom Browsereinsatz gemacht werden können.


Galileo Computing

16.12.3 Die Antworten vom Server  toptop

Der Server antwortet ebenfalls mit einer Statuszeile, einem Header (mit Informationen über sich selbst) und dem Inhalt. Der Web-Browser muss sich also um eine Antwort des Web-Servers kümmern. Eine vom Microsoft Web-Server generierte Antwort kann etwa wie folgt aussehen:

HTTP/1.0 200 OK
Server: Microsoft-PWS/2.0
Date: Sat10 Feb 2002 19:03:45 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Sat09 May 1998 09:52:22 GMT
Content-Length: 26
Hier kommt die HTML Seite

Die Antwort ist wieder durch eine Leerzeile getrennt. Der Header vom HTTP setzt sich aus drei Teilen zusammen, dem General-Header (dazu gehört etwa Date), dem Response-Header (dazu gehört Server) und dem Entity-Header (Content-Length und Content-Type). (Der Client kann zusätzlich einen Request-Header belegen.)

Jedes Feld im Header besteht aus einem Namen, gefolgt von einem Doppelpunkt. Dann folgt der Wert. Groß- und Kleinschreibung ist für die Feldnamen irrelevant.

Die erste Zeile wird Statuszeile genannt und beinhaltet die Version des Protokolls und den Statuscode. Der danach folgende Text ist optional und beschreibt in einer menschlichen Form den Statuscode.

Die Version

Die erste Version des Protokolls HTTP (HTTP/0.9) sah nur eine einfache Übertragung von Daten über das Internet vor. HTTP/1.0 war da schon eine Erweiterung, denn die Daten konnten als MIME-Nachrichten verschickt werden. Zudem waren Metadaten (wie die Länge der Botschaft) verfügbar. Da aber HTTP/1.0 Nachteile im Caching aufweist und für jede Datei eine neue Verbindung aufbaut, also keine persistenten Verbindungen unterstützt, wurde das HTTP/1.1 eingeführt.

Der Statuscode

Der Statuscode gibt Auskunft über das Ergebnis der Anfrage. Er besteht aus einer Zahl mit drei Ziffern. Der zusätzliche optionale Text ist nur für den Menschen.

Das erste Zeichen des Statuscodes definiert die Antwort-Klasse (ähnlich wie es der FTP-Server macht). Die nachfolgenden Ziffern sind keiner Kategorie zuzuordnen. Für das erste Zeichen gibt es fünf Klassen:

gp  1xx: Informierend Die Anfrage ist angekommen, und alles geht weiter.
gp  2xx: Erfolgreich Die Aktion wurde erfolgreich empfangen, verstanden und akzeptiert.
gp  3xx: Rückfrage Um die Anfrage auszuführen, sind noch weitere Angaben nötig.
gp  4xx: Fehler beim Client Die Anfrage ist syntaktisch falsch oder kann nicht ausgeführt werden.
gp  5xx: Fehler beim Server Der Server kann die wahrscheinlich korrekte Anfrage nicht ausführen.

Gehen wir noch etwas genauer auf die Fehlertypen ein.


Tabelle 16.4   Einige Statuscodes bei Antworten des HTTP-Servers

Statuscode Optionaler Text
200 OK
201 Created
202 Accepted
204 No Content
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
304 Not Modified
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable

Am häufigsten handelt es sich bei den Rückgabewerten um:

gp  200 OK
    Die Anfrage vom Client war korrekt, und die Antwort des Servers stellt die gewünschte Information bereit.
       
gp  404 Not Found
    Das referenzierte Dokument kann nicht gefunden werden.
       
gp  500 Internal Server Error
    Meistens durch schlechte CGI-Programme hervorgerufen.
       

Der Text in der Tabelle kann vom Statuscode abweichen.

General Header Fields

Zu jeder übermittelten Nachricht (nicht Entity) gibt es abfragbare Felder. Diese gelten sowohl für den Client als auch für den Server. Zu ihnen gehören: Cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade und Via. Zu den Header-Informationen gehört auch die Uhrzeit des abgesendeten Pakets. Das Datum kann in drei verschiedenen Formaten gesendet werden, wobei das erste zum Internet-Standard gehört und dementsprechend wünschenswert ist. Es hat gegenüber dem zweiten den Vorteil, dass es eine feste Läge besitzt und das Jahr mit vier Ziffern darstellt:

Sun06 Nov 1994 08:49:37 GMT   ; RFC 822update in RFC 1123
Sunday06-Nov-94 08:49:37 GMT  ; RFC 850obsolet seit RFC 1036
Sun Nov  6 08:49:37 1994        ; ANSI C asctime() Format

Ein HTTP/1.1-Client, der die Datumswerte ausliest, muss also drei Datumsformate akzeptieren.

Felder im Response-Header

Der Response-Header erlaubt dem Server, zusätzliche Informationen, die nicht in der Statuszeile kodiert sind, zu übermitteln. Die Felder geben Auskunft über den Server. Folgende Felder sind möglich: Age, Location, Proxy-Authenticate, Public, Retry-After, Server, Vary, Warning und WWW-Authenticate.

Entity Header Fields

Eine Entity ist eine Information, die aufgrund einer Anfrage gesendet wird. Die Entity besteht aus einer Metainformation (Entity-Header) und der Nachricht selbst (überliefert im Entity-Body). Die in einem der Entity-Header-Felder übermittelten Metainformationen sind etwa Informationen über die Länge des Blocks oder über die letzte Änderung der Länge. Ist kein Entity-Body definiert, liefern die Felder Informationen über die Ressourcen, ohne sie wirklich im Entity-Body zu senden: Allow, Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, ETag, Expires und Last-Modified.

Der Dateiinhalt und der Content-Type

HTTP nutzt die Internet Media-Types (verwandt mit den MIME-Types) im Content-Type. Dieser Content-Type gibt den Datentyp des übermittelten Datenstroms an. Einige Beispiele mit Referenzen:


Type Untertyp Beschreibung
text plain ASCII-Text (RFC1521)
html Hyper-Text Markup Language (RFC1866)
multipart mixed Mehrere Inhalte (RFC1521)
form-data Formulardaten aus HTML (RFC1867)
application octet-stream Allgemeine Binärdaten (RFC1521)
postscript Postscript von Adobe (RFC1521)
rtf Rich Text Format
pdf PDF von Adobe
vnd.ms-excel Microsoft Excel
vnd.ms-powerpoint Microsoft Powerpoint

Jede über HTTP/1.1 übermittelte Nachricht mit einem Entity-Body sollte einen Header mit Content-Type enthalten. Ist dieser Typ nicht gegeben, versucht der Client anhand der URL-Endung oder durch Betrachtung des Datenstroms herauszufinden, um welchen Typ es sich handelt. Bleibt dies jedoch unklar, wird ihm der Typ »application/octet-stream« zugewiesen. Content-Types werden gerne benutzt, um Daten zu komprimieren. Diese verlieren dadurch nicht ihre Identität. In diesem Fall ist das Feld Content-Encoding im Entity-Header gesetzt, und bei einem GNU Zip-Packverfahren (gzip) ist dann folgende Zeile im Datenstrom mit dabei:

Content-Encoding: gzip

Nach den Headern folgt als Antwort die Datei. Nachdem diese übertragen wurde, wird die Socket-Verbindung geschlossen. Da jedes Anfrage/Antwort-Paar in einer Socket-Verbindung mündet, ist dieses Verfahren nicht besonders schnell und schont auch nicht das Netzwerk, da viele Pakete, die sich um den Aufbau der Leitung kümmern, verschickt werden müssen.




1  Eine Lempel-Ziv-Kodierung (LZ77) mit einem 32–Bit-CRC. Beschrieben in RFC 1952.

 << zurück




Copyright © Galileo Press GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de