Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis
Vorwort
1 Neues in Java 8 und Java 7
2 Fortgeschrittene String-Verarbeitung
3 Threads und nebenläufige Programmierung
4 Datenstrukturen und Algorithmen
5 Raum und Zeit
6 Dateien, Verzeichnisse und Dateizugriffe
7 Datenströme
8 Die eXtensible Markup Language (XML)
9 Dateiformate
10 Grafische Oberflächen mit Swing
11 Grafikprogrammierung
12 JavaFX
13 Netzwerkprogrammierung
14 Verteilte Programmierung mit RMI
15 RESTful und SOAP-Web-Services
16 Technologien für die Infrastruktur
17 Typen, Reflection und Annotationen
18 Dynamische Übersetzung und Skriptsprachen
19 Logging und Monitoring
20 Sicherheitskonzepte
21 Datenbankmanagement mit JDBC
22 Java Native Interface (JNI)
23 Dienstprogramme für die Java-Umgebung
Stichwortverzeichnis

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java SE 8 Standard-Bibliothek von Christian Ullenboom
Das Handbuch für Java-Entwickler
Buch: Java SE 8 Standard-Bibliothek

Java SE 8 Standard-Bibliothek
Pfeil 13 Netzwerkprogrammierung
Pfeil 13.1 Grundlegende Begriffe
Pfeil 13.2 URI und URL
Pfeil 13.2.1 Die Klasse URI
Pfeil 13.2.2 Die Klasse URL
Pfeil 13.2.3 Informationen über eine URL *
Pfeil 13.2.4 Der Zugriff auf die Daten über die Klasse URL
Pfeil 13.3 Die Klasse URLConnection *
Pfeil 13.3.1 Methoden und Anwendung von URLConnection
Pfeil 13.3.2 Protokoll- und Content-Handler
Pfeil 13.3.3 Im Detail: Von der URL zur URLConnection
Pfeil 13.3.4 Der Protokoll-Handler für JAR-Dateien
Pfeil 13.3.5 Basic Authentication und Proxy-Authentifizierung
Pfeil 13.4 Mit GET und POST Daten übergeben *
Pfeil 13.4.1 Kodieren der Parameter für Serverprogramme
Pfeil 13.4.2 In Wikipedia suchen und mit GET-Request absenden
Pfeil 13.4.3 POST-Request absenden
Pfeil 13.5 Host- und IP-Adressen
Pfeil 13.5.1 Lebt der Rechner?
Pfeil 13.5.2 IP-Adresse des lokalen Hosts
Pfeil 13.5.3 Das Netz ist klasse *
Pfeil 13.5.4 NetworkInterface
Pfeil 13.6 Mit dem Socket zum Server
Pfeil 13.6.1 Das Netzwerk ist der Computer
Pfeil 13.6.2 Sockets
Pfeil 13.6.3 Eine Verbindung zum Server aufbauen
Pfeil 13.6.4 Server unter Spannung – die Ströme
Pfeil 13.6.5 Die Verbindung wieder abbauen
Pfeil 13.6.6 Informationen über den Socket *
Pfeil 13.6.7 Reine Verbindungsdaten über SocketAddress *
Pfeil 13.7 Client-Server-Kommunikation
Pfeil 13.7.1 Warten auf Verbindungen
Pfeil 13.7.2 Ein Multiplikationsserver
Pfeil 13.7.3 Blockierendes Lesen
Pfeil 13.8 Apache HttpComponents und Commons Net *
Pfeil 13.8.1 HttpComponents
Pfeil 13.8.2 Apache Commons Net
Pfeil 13.9 Arbeitsweise eines Webservers *
Pfeil 13.9.1 Das Hypertext Transfer Protocol (HTTP)
Pfeil 13.9.2 Anfragen an den Server
Pfeil 13.9.3 Die Antworten vom Server
Pfeil 13.9.4 Webserver mit com.sun.net.httpserver.HttpServer
Pfeil 13.10 Verbindungen durch einen Proxy-Server *
Pfeil 13.10.1 System-Properties
Pfeil 13.10.2 Verbindungen durch die Proxy-API
Pfeil 13.11 Datagram-Sockets *
Pfeil 13.11.1 Die Klasse DatagramSocket
Pfeil 13.11.2 Datagramme und die Klasse DatagramPacket
Pfeil 13.11.3 Auf ein hereinkommendes Paket warten
Pfeil 13.11.4 Ein Paket zum Senden vorbereiten
Pfeil 13.11.5 Methoden der Klasse DatagramPacket
Pfeil 13.11.6 Das Paket senden
Pfeil 13.12 E-Mail *
Pfeil 13.12.1 Wie eine Elektropost um die Welt geht
Pfeil 13.12.2 Das Simple Mail Transfer Protocol und RFC 822
Pfeil 13.12.3 POP (Post Office Protocol)
Pfeil 13.12.4 Die JavaMail API
Pfeil 13.12.5 E-Mails mittels POP3 abrufen
Pfeil 13.12.6 Multipart-Nachrichten verarbeiten
Pfeil 13.12.7 E-Mails versenden
Pfeil 13.12.8 Ereignisse und Suchen
Pfeil 13.13 Tiefer liegende Netzwerkeigenschaften *
Pfeil 13.13.1 MAC-Adressen auslesen
Pfeil 13.13.2 Internet Control Message Protocol (ICMP)
Pfeil 13.14 Zum Weiterlesen
 
Zum Seitenanfang

13.9Arbeitsweise eines Webservers * Zur vorigen ÜberschriftZur nächsten Überschrift

In diesem Abschnitt werden die Grundlagen eines Webservers behandelt. Dazu besprechen wir zunächst das Protokoll HTTP, auf dem das Web basiert.

 
Zum Seitenanfang

13.9.1Das Hypertext Transfer Protocol (HTTP) Zur vorigen ÜberschriftZur nächsten Überschrift

HTTP ist ein Protokoll für Hypermedia-Systeme und in RFC 2616 genau beschrieben. HTTP wird seit dem Aufkommen des World Wide Web – Näheres dazu finden Sie 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:

  • eine Zeile am Anfang: Dies kann entweder eine Anfrage (also eine Nachricht vom Client) oder eine Antwort vom Server sein.

  • einige Kopfzeilen (engl. header): Informationen über den Client oder Server, zum Beispiel über den Inhalt. Der Header endet immer mit einer Leerzeile.

  • 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.

 
Zum Seitenanfang

13.9.2Anfragen an den Server Zur vorigen ÜberschriftZur nächsten Überschrift

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 definiert mehrere Hauptmethoden, von denen drei zu den wichtigsten gehören:

  • GET: Eine einfache Anfrage nach einer Information. Der Client kann Daten an die URL anhängen und so zum Server schicken.

  • POST: Die POST-Methode erlaubt es dem Client, Daten über einen Datenstrom zum Server zu schicken.

  • 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 Webserver

Hier sehen Sie ein typisches Beispiel einer GET-Anfrage vom Client an den Standard-Webserver:

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.

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.

Tabelle 13.1Die wichtigsten Anfragemethoden von HTTP

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

URL

Erzeugte Anfrage

www.tutego.com/

GET / HTTP/1.1

www.tutego.com/../index.html

GET /../index.html HTTP/1.1

www.tutego.com/classes/applet.html

GET /classes/applet.html HTTP/1.1

Tabelle 13.2GET-Anfragen

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

[zB]Beispiel

Wir können das in einer Telnet-Sitzung einfach testen. (Ab Windows 7 muss dieses Tool allerdings erst aktiviert werden.[ 118 ](Beschrieben etwa unter http://praxistipps.chip.de/telnet-client-unter-windows-7-aktivieren_3601.)) Starten wir zunächst eine Telnet-Sitzung:

$ telnet www.tutego.com 80

Anschließend fordern wir mit GET /javabuch/aufgaben/bond.txt HTTP/1.0 und zwei Returns in der Eingabe eine Datei an.

Nach der Zeile mit der Anfrage können optionale Zeilen gesendet werden. So stellt ein HTTP-Client an den Server beispielsweise die folgende Anfrage:

GET / HTTP/1.0
Connection: Keep-Alive
User-Agent: SuperBrowser 2000
Host: merlin
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Hier sehen wir, dass durch diese Plauderei leicht Statistiken vom Browser-Einsatz erstellt werden können.

 
Zum Seitenanfang

13.9.3Die Antworten vom Server Zur vorigen ÜberschriftZur nächsten Überschrift

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

HTTP/1.0 200 OK
Server: Microsoft-PWS/2.0
Date: Sat, 10 Feb 2002 19:03:45 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Sat, 09 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 sind 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 für Menschen lesbaren 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 Antwortklasse (ähnlich wie es der FTP-Server macht). Die nachfolgenden Ziffern sind keiner Kategorie zuzuordnen. Für das erste Zeichen gibt es fünf Klassen:

  • 1xx: informierend
    Die Anfrage ist angekommen, und alles geht weiter.

  • 2xx: erfolgreich
    Die Aktion wurde erfolgreich empfangen, verstanden und akzeptiert.

  • 3xx: Rückfrage
    Um die Anfrage auszuführen, sind noch weitere Angaben nötig.

  • 4xx: Fehler beim Client
    Die Anfrage ist syntaktisch falsch oder kann nicht ausgeführt werden.

  • 5xx: Fehler beim Server
    Der Server kann die wahrscheinlich korrekte Anfrage nicht ausführen.

Gehen wir noch etwas genauer auf die Fehlertypen ein:

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

Tabelle 13.3Einige Statuscodes bei Antworten des HTTP-Servers

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

  • 200 OK: Die Anfrage vom Client war korrekt, und die Antwort des Servers stellt die gewünschte Information bereit.

  • 404 Not Found: Das referenzierte Dokument kann nicht gefunden werden.

  • 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 Format zum Internet-Standard gehört und dementsprechend wünschenswert ist. Es hat gegenüber dem zweiten Format den Vorteil, dass es eine feste Länge besitzt und das Jahr mit vier Ziffern darstellt:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, update in RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsolet 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 zu übermitteln, die nicht in der Statuszeile kodiert sind. 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 Meta-Information (Entity-Header) und der Nachricht selbst (überliefert im Entity-Body). Die in einem der Entity-Header-Felder übermittelten Meta-Informationen 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:

Typ

Untertyp

Beschreibung

text

plain

ASCII-Text (RFC 1521)

html

Hyper-Text Markup Language (RFC 1866)

multipart

mixed

mehrteilige Inhalte (RFC 1521)

form-data

Formulardaten aus HTML (RFC 1867)

application

octet-stream

allgemeine Binärdaten (RFC 1521)

postscript

PostScript von Adobe (RFC 1521)

rtf

Rich Text Format

pdf

PDF von Adobe

vnd.ms-excel

Microsoft Excel

vnd.ms-powerpoint

Microsoft PowerPoint

Tabelle 13.4Content-Types

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 gern 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 worden ist, wird die Socket-Verbindung geschlossen. Da jedes Anfrage-Antwort-Paar in eine Socket-Verbindung mündet, ist dieses Verfahren nicht besonders schnell und schont auch nicht das Netzwerk, da viele Pakete verschickt werden müssen, die sich um den Aufbau der Leitung kümmern.

 
Zum Seitenanfang

13.9.4Webserver mit com.sun.net.httpserver.HttpServer Zur vorigen ÜberschriftZur nächsten Überschrift

Java bietet seit der Version 6 eine API, um Web-Services anzusprechen und auch neue Web-Services zu definieren und am eigenen Rechner anzumelden. Doch um Web-Services anbieten und entfernten Clients Zugriff gewähren zu können, ist immer ein Webserver nötig. Aus diesem Grund hat Sun einen einfachen HTTP(S)-Server integriert, der sich auch eigenständig nutzen lässt; die Klassen sind zwar mehr oder weniger privat im Paket com.sun.net.httpserver deklariert, dennoch wollen wir ein Beispiel wagen.[ 119 ](Bei der normalen API-Dokumentation taucht die Klasse nicht auf. Im ZIP mit der Dokumentation ist die Klasse jedoch bei docs\jre\api\net\httpserver\spec beschrieben.)

Im Mittelpunkt steht die Klasse HttpServer/HttpsServer – eine abstrakte Oberklasse, von der die Fabrikmethoden create() und create(InetSocketAddress, int) ein konkretes Exemplar liefern. Im nächsten Schritt verbindet die Methode createContext(…) einen Pfad (wie etwa »/webapp1/«) mit einem bestimmten HttpHandler, der die Anfrage an den Pfad übernimmt:

Listing 13.19com/tutego/insel/httpserver/HttpServerDemo.java

public class HttpServerDemo {
public static void main( String[] args ) throws IOException {
HttpServer server = HttpServer.create( new InetSocketAddress( 80 ), 0 );
server.createContext( "/", new DateHandler() );
server.start();
}
}

Jeder Handler implementiert die Schnittstelle HttpHandler mit der Methode handle(HttpExchange), die über den Parameter HttpExchange Zugriff auf Header, Anfragekörper und Ergebnis ermöglicht.

Ein einfacher HttpHandler, der Anfragen mit einer HTML-Seite beantwortet, die das Datum und den Anfragepfad enthält, kann so aussehen:

Listing 13.20com/tutego/insel/httpserver/HttpServerDemo.java, DateHandler

class DateHandler implements HttpHandler {
@Override public void handle( HttpExchange httpExchange ) throws IOException {
httpExchange.getResponseHeaders().add( "Content-type", "text/html" );
String response = "<b>" + new Date() + "</b> for " +
httpExchange.getRequestURI();
httpExchange.sendResponseHeaders( 200, response.length() );

try ( OutputStream os = httpExchange.getResponseBody() ) {
os.write( response.getBytes() );
}
}
}

Die Methode getResponseHeaders() liefert ein Headers-Objekt (eine Map<String,List<String>>) zum Setzen der Response-Header. Das Beispiel setzt den Content-Type auf »text/html«. Die Methode sendResponseHeaders(…) schließt die Header-Angaben mit einem Statuscode (Response-Code) und der Content-Länge ab. getRequestURI() gibt den Pfad zurück und ermöglicht uns das Zerlegen der Elemente nach Verzeichnis, Datei, Dateiendung, Ankern und Parametern.

HttpExchange liefert mit getResponseBody() einen OutputStream, der das Ergebnisdokument formuliert. Die Methode getRequestBody() liefert einen InputStream für das, was der Client sendet. Das Beispiel schreibt die Bytes vom String in den OutputStream und schließt ihn anschließend.

Nach dem Start des Servers können wir im Webbrowser URLs wie http://localhost/ oder http://localhost/webapp/bla eingeben, und wir erhalten das Datum und die Pfadangabe.

 


Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java SE 8 Standard-Bibliothek Java SE 8 Standard-Bibliothek
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: Java ist auch eine Insel
Java ist auch eine Insel


Zum Rheinwerk-Shop: Professionell entwickeln mit Java EE 8
Professionell entwickeln mit Java EE 8


Zum Rheinwerk-Shop: Besser coden
Besser coden


Zum Rheinwerk-Shop: Entwurfsmuster
Entwurfsmuster


Zum Rheinwerk-Shop: IT-Projektmanagement
IT-Projektmanagement


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2018
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.

 
Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern