Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Die Funktionsbibliothek
10 Threads und nebenläufige Programmierung
11 Raum und Zeit
12 Datenstrukturen und Algorithmen
13 Dateien und Datenströme
14 Die eXtensible Markup Language (XML)
15 Grafische Oberflächen mit Swing
16 Grafikprogrammierung
17 Netzwerkprogrammierung
18 Verteilte Programmierung mit RMI und Web-Services
19 JavaServer Pages und Servlets
20 Applets
21 Midlets und die Java ME
22 Datenbankmanagement mit JDBC
23 Reflection und Annotationen
24 Logging und Monitoring
25 Sicherheitskonzepte
26 Java Native Interface (JNI)
27 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Stichwort
Download: - ZIP, ca. 12,5 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> /Java-Insel | vor >>
Java ist auch eine Insel von Christian Ullenboom Programmieren mit der Java Standard Edition Version 6
Java ist auch eine Insel 7., aktualisierte Auflage geb., mit DVD (November 2007) 1.492 S., 49,90 Euro Galileo Computing ISBN 978-3-8362-1146-8 |
| 17 Netzwerkprogrammierung
|  | 17.1 Grundlegende Begriffe
|  |  | 17.1.1 Internet-Standards und RFC
|  | 17.2 URI und URL
|  |  | 17.2.1 URI
|  |  | 17.2.2 Die Klasse URL
|  |  | 17.2.3 Informationen über eine URL
|  |  | 17.2.4 Der Zugriff auf die Daten über die Klasse URL
|  |  | 17.2.5 Verbindungen durch einen Proxy-Server
|  | 17.3 Die Klasse URLConnection
|  |  | 17.3.1 Methoden und Anwendung von URLConnection
|  |  | 17.3.2 Protokoll- und Content-Handler
|  |  | 17.3.3 Im Detail: vom URL zur URLConnection
|  |  | 17.3.4 Der Protokoll-Handler für Jar-Dateien
|  |  | 17.3.5 Passwort-geschützte Seiten mit Basic Authentication/ Proxy-Authentifizierung
|  | 17.4 Mit GET und POST Daten übergeben
|  |  | 17.4.1 Kodieren der Parameter für Serverprogramme
|  |  | 17.4.2 Eine Suchmaschine ansprechen
|  | 17.5 Host- und IP-Adressen
|  |  | 17.5.1 Lebt der Rechner?
|  |  | 17.5.2 Das Netz ist Klasse ...
|  |  | 17.5.3 IP-Adresse des lokalen Hosts
|  | 17.6 NetworkInterface
|  | 17.7 Mit dem Socket zum Server
|  |  | 17.7.1 Das Netzwerk ist der Computer
|  |  | 17.7.2 Sockets
|  |  | 17.7.3 Eine Verbindung zum Server aufbauen
|  |  | 17.7.4 Server unter Spannung: die Ströme
|  |  | 17.7.5 Die Verbindung wieder abbauen
|  |  | 17.7.6 Informationen über den Socket
|  |  | 17.7.7 Reine Verbindungsdaten über SocketAddress
|  | 17.8 Client/Server-Kommunikation
|  |  | 17.8.1 Warten auf Verbindungen
|  |  | 17.8.2 Ein Multiplikationsserver
|  |  | 17.8.3 Blockierendes Lesen
|  |  | 17.8.4 Von außen erreichbar sein
|  | 17.9 Apache Jakarta Commons HttpClient und Net
|  |  | 17.9.1 Jakarta Commons HttpClient
|  |  | 17.9.2 Jakarta Commons Net
|  | 17.10 Arbeitsweise eines Webservers
|  |  | 17.10.1 Das Hypertext Transfer Protocol (HTTP)
|  |  | 17.10.2 Anfragen an den Server
|  |  | 17.10.3 Die Antworten vom Server
|  |  | 17.10.4 Webserver mit com.sun.net.httpserver.HttpServer
|  | 17.11 Datagram-Sockets
|  |  | 17.11.1 Die Klasse DatagramSocket
|  |  | 17.11.2 Datagramme und die Klasse DatagramPacket
|  |  | 17.11.3 Auf ein hereinkommendes Paket warten
|  |  | 17.11.4 Ein Paket zum Senden vorbereiten
|  |  | 17.11.5 Methoden der Klasse DatagramPacket
|  |  | 17.11.6 Das Paket senden
|  | 17.12 E-Mail
|  |  | 17.12.1 Wie eine E-Mail um die Welt geht
|  |  | 17.12.2 Das Simple Mail Transfer Protocol und RFC 822
|  |  | 17.12.3 POP (Post Office Protocol)
|  |  | 17.12.4 Die JavaMail API
|  |  | 17.12.5 E-Mails mittels POP3 abrufen
|  |  | 17.12.6 E-Mails versenden
|  |  | 17.12.7 Ereignisse und Suchen
|  | 17.13 Tiefer liegende Netzwerkeigenschaften
|  |  | 17.13.1 Internet Control Message Protocol (ICMP)
|  |  | 17.13.2 MAC-Adresse
|  | 17.14 Zum Weiterlesen
## 17.10 Arbeitsweise eines Webservers In diesem Kapitel lernen wir die Grundlagen eines Webservers kennen. Dazu besprechen wir zunächst das Protokoll HTTP, auf dem das Web basiert. Detaillierte Informationen aus Serversicht beschreibt das nächste Kapitel. Hier betrachten wir nur die Clientseite. ### 17.10.1 Das Hypertext Transfer Protocol (HTTP) Das 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 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 Kopf-Zeilen (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. ### 17.10.2 Anfragen an den Server 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 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.
Tabelle 17.1 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 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
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 www.tutego.com 80
Anschließend fordern wir mit GET /aufgaben/bond.txt HTTP/1.0 und zwei Returns in der Eingabe 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 England’s INDEPENDENT:
    ...
Hier klicken, um das Bild zu vergrößern Abbildung 17.1 GET-Anfrage über telnet an einen Webserver Wenn die GET-Anfrage falsch formuliert oder die Datei nicht vorhanden ist, folgt eine Fehlerausgabe: Hier klicken, um das Bild zu vergrößern Abbildung 17.2 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/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Hier sehen wir, dass durch diese Plauderei leicht Statistiken vom Browsereinsatz gemacht werden können. ### 17.10.3 Die Antworten vom Server 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 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 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 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: 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:
Tabelle 17.2 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: 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 zum Internet-Standard gehört und dementsprechend wünschenswert ist. Es hat gegenüber dem zweiten 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 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 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 [Eine Lempel-Ziv-Kodierung (LZ77) mit einem 32-Bit-CRC. Beschrieben in RFC 1952. ] (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 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. ### 17.10.4 Webserver mit com.sun.net.httpserver.HttpServer 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 Web-Server nötig. Aus diesem Grund hat Sun einen einfachen HTTP-Server integriert, der sich auch eingestä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. Im Mittelpunkt steht die Klasse HttpServer – 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 17.15 com/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 Funktion 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 Datum und den Anfragepfad enthält, kann so aussehen: Listing 17.16 com/tutego/insel/httpserver/HttpServerDemo.java, DateHandler
    class DateHandler implements HttpHandler
    {
      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() );

        OutputStream os = httpExchange.getResponseBody();
        os.write( response.getBytes() );
        os.close();
      }
    }
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 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. ### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
Name |
E-Mail |
Ihr Kommentar |
<< zurück | <top> | vor >>

Copyright © Galileo Press 2008
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, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de