1. Internet-Grundlagen und Überblickswissen OSI –Modell (1)

Transcrição

1. Internet-Grundlagen und Überblickswissen
 OSI 7-Schichtenmodell
 Verteilte Anwendungen,
allgemeines Client-Server-Modell
 Pipes/Sockets als Kommunikationsmodell auf der IPSchicht
 WWW – ein klassisches Client-Server-System (C/S) mit
http als zustandsloses Verbindungsprotokoll in der
Anwendungsschicht
 Verbindungsorientierte C/S-Systeme
 Architektur von Web-Applikationen
 Möglichkeiten des clientseitigen Scriptings
 Multi-Tier-Architekturen von Web-Applikationen
 Möglichkeiten des serverseitigen Scriptings
Peter Sobe
Internettechnologien
1
OSI –Modell (1)
OSI-Referenzmodell:
Open Systems Interconnection Reference Model
Eingeführt 1983 von der ISO (Internationale
Normungsorganisation)
Zu dieser Zeit existierte TCP/IP bereits, das bis dahin
durch ein 4-Schichtenmodell erklärt wurde.
Ein Schichtenmodell ordnet verschiedenen NetzwerkTechniken jeweils eine Schicht zu. Die oberen Schichten
bauen auf der Funktionalität und den Schnittstellen der
unteren Schichten auf.
Peter Sobe
2
OSI –Modell (2)
Peter Sobe
3
OSI –Modell (3)
1: Bitübertragungsschicht – umfasst mechanische und
elektrische Elemente, das Übertragungsmedium und die
übertragungstechnischen Verfahren
2: Sicherungsschicht - Techniken zum Zugriff auf das
Übertragungsmedium, Datenflusskontrolle,
Fehlererkennung und –korrektur
3: Vermittlungsschicht – Weiterleitung der
Datenübertragung über ein Kommunikationsnetz aus
mehreren Leitungssegmenten und Schaltstellen (Router)
4: Transportschicht – Ende-zu-Ende-Steuerung für
Datenströme
Peter Sobe
4
OSI –Modell (4)
5: Sitzungsschicht – synchronisierter Datenaustausch, weitere
Mechanismen wie z.B. RPC (Remote Procedure Call)
6: Darstellungsschicht – Herstellung einer
systemunabhängigen Darstellung der Daten,
ggf. Anpassung an verschiedene Darstellungsformate,
Zusätzlich: Datenkompression und Verschlüsselung
7: Anwendungsschicht – verschiedene Anwendungen, wie z.B.
Dateitransfer (SCP,FTP), Email, Webserver/Webbrowser
Peter Sobe
5
Einfacheres 4-Schichten-Modell (1)
Angelehnt an TCP/IP mit Internetschicht und Transportschicht
logischer Datenaustausch
Rechner 1
4
3
2
1
Anwendungsschicht
Transportschicht
Internetschicht
Rechner 2
http, ftp,
smtp, pop,
....
4
TCP
3
IP
2
1
Netzzugangsschicht
Anwendungsschicht
Transportschicht
Internetschicht
http, ftp,
smtp, pop,
....
TCP
IP
Netzzugangsschicht
realer Datenaustausch mit elektr.
Signalen
Peter Sobe
6
Einfacheres 4-Schichten-Modell (2)
Die beiden entscheidenden Schnittstellen, die Internetschicht
und die Transportschicht gut zu erkennen. Darüber liegt dann
die Anwendungsschicht, die die bekannten Internetdienste
enthält.
Der Name Internettechnologien kommt natürlich von der
Internetschicht. Man rechnet alles, was direkt auf diese
Internetschicht aufsetzt oder darüber liegt zu den
Internettechnologien. In der Literatur ist oft der Begriff WebTechnologie zu finden.
Peter Sobe
7
Client-Server-Modell –
Grundlage für die Internettechnologien
Wir betrachten zwei Rechner, die über das Netz verbunden sind.
Auf jedem Rechner läuft eine Anwendung, die beide miteinander
kooperieren, d.h. Daten austauschen.
Eine Anwendung wird als Server bezeichnet, die andere als
Client. Der Server stellt einen Dienst bereit und der Client ist die
Anwendung, die den Dienst in Anspruch nimmt.
Gefordert:
Ein Protokoll, das bestimmt wie der Datenaustausch zwischen
Server und Client funktioniert.
 Zeitliche Abfolge der Nachrichten und Regeln für Client
und Server
 Inhalt und Format der einzelnen Nachrichten
Peter Sobe
8
Grundlage für die Internettechnologien
Werden im Internet Dienste von allgemeinem Interesse zur
Verfügung gestellt, müssen die Protokolle publiziert werden.
Oft werden dann auch Clients zur Verfügung gestellt, über die
solche Dienste genutzt werden können.
Zugangspunkte für Dienste (Adressen) müssen bekannt sein:
 Adresse des Servers (IP-Adresse)
 Unterscheidung der Zugangspunkte, wenn ein Server mehr
als einen Dienst bereit stellt (Port)
Die Adressierung ist Aufgabe der Transportschicht (TCP) im
OSI-Modell.
Peter Sobe
9
Adressierung der Server
Ein Dienst wird mit einer so genannten Portnummer versehen.
Portnummer und Rechner (IP-Nummer) bilden ein Socket und
sind im Internet eindeutig definiert. Damit gelingt es beim
Datenversand im Internet durch TCP das Ziel der Daten, den
Server, eindeutig zu adressieren.
Server: www.htw-dresden.de IP-V4-Adr.: 141.56.16.49
WWW-Server an Port 80
FTP-Server an Ports 20,21
Peter Sobe
10
Adressierung der Clients
Ein Client wird durch seine IP-Adresse ausgewiesen.
Jede Verbindung wird client-seitig einem anderem Port
zugeordnet. Damit kann der Client mehrere Verbindungen
gleichzeitig aufrecht erhalten.
Ports für Client-Prozesse werden durch Portmapper dynamisch
vergeben. Der Client-Port wird dem Server beim Verbindungsaufbau mitgeteilt.
Eine TCP-Verbindung (Socket-Verbindung) ist demnach durch
(Server-IP-Addr, Server_Port, Client-IP-Addr, Client-Port)
gekennzeichnet.
Peter Sobe
11
Szenarien (1)
Ein Server, mehrere Clients:
Clients
C1-IP-Adr,
C1-Port
Server
Server-IP-Adr,
Server-Port
C2-IP-Adr,
C2-Port
C3-IP-Adr,
C3-Port
Wenn Clients auf unterschiedlichen Rechnern laufen, dann
unterscheiden sich C1-IP-Adr, C2-IP-Adr und C3-IP-Adr.
Wenn Clients auf dem gleichen Rechner laufen (z.B. mehrere
Nutzer), dann unterscheiden sich ihre Port-Nummern, z.B. C2Port ≠ C1-Port
Peter Sobe
12
Szenarien (2)
Ein Client, mehrere Server:
Server
Client
S1-IP-Adr,
S1-Port
Client-IP-Adr,
Client-Port
S2-IP-Adr,
S2-Port
Wenn Server auf unterschiedlichen Rechnern laufen, dann
unterscheiden sich S1-IP-Adr und S2-IP-Adr.
Wenn verschiedene Server auf dem gleichen Rechner laufen, dann
unterscheiden sich ihre Port-Nummern, z.B. S2-Port ≠ S1-Port.
→ Nachrichten unterschiedlicher Verbindungen sind immer
unterscheidbar.
Peter Sobe
13
TCP und UDP (1)
TCP (Transmission Control Protocol) –
Verbindungsorientiertes Protokoll aus OSI Schicht 4,
 arbeitet intern wie dargestellte Socket- und PipeKommunikation
 TCP garantiert Reihenfolge der Daten und Fehlerfreiheit – bei
verlorenen Paketen werden diese wiederholt übertragen
 Auf TCP bauen viele Internetdienste auf, z.B. HTTP, FTP
Peter Sobe
14
TCP und UDP (2)
UDP (User Datagram Protocol) ist das verbindungslose
Pendant zu TCP – UDP kann schneller sein
 einzelne Pakete werden übertragen, ohne explizite
Verbindung
 keine Reihenfolgegarantie
 Pakete können verloren gehen
 einige Dienste, wie z.B. Audio-Streaming verwenden UDP
Peter Sobe
15
Client-Server-Kommunikation –
per Socket-Verbindung (1)
Eine Socket-Verbindung ist eine verbindungsorientierte
Kopplung zwischen zwei Prozessen, typischerweise einem
Server und einem Client.
Die Verbindung wird explizit aufgebaut, danach kann
bidirektional kommuniziert werden. Die Verbindung wird
geschlossen, wenn sie nicht mehr benötigt wird.
Vergleichbar mit Telefongespräch!
Prozess-2
Prozess-1
Peter Sobe
16
Phasen einer Socket-Verbindung als Sequenz-Diagramm
Server
Client
bind (port)
s=connect(server-ip-adr, port)
listen()
s = accept()
send(s, …)
recv(s, …)
send(s, …)
recv(s, …)
send(s, …)
recv(s, …)
close(s)
Peter Sobe
close(s)
17
• Der Server bindet eine Dienst an einen bekannten Port (bind)
und akzeptiert Verbindungen (accept).
• Ein Client verbindet sich mit einem Dienst an einem
bekannten Port (connect).
• Beide Prozesse können Daten senden und empfangen.
• Welcher Prozess wann sendet und wann empfängt, muss
durch das Protokoll zwischen Server und Client geklärt sein.
• Ein Server erzeugt typischerweise nach dem Annehmen einer
Verbindung (accept) einen neuen Thread für die Verbindung.
Der verbleibende Thread nimmt wieder neue Verbindungen
an (Multi-Client Server).
Peter Sobe
18
„Benannte Pipe“ als Kommunikationskanal (1)
Eine „benannte Pipe“ kann wie eine Datei angesehen werden,
die auf der Seite des Server-Rechners eingerichtet ist und einen
Kommunikationskanal zwischen zwei verteilten, kooperierenden
Anwendungen darstellt. Eine Anwendung schiebt Daten in den
Kanal hinein (schreiben) und die andere Anwendung holt sich
diese Daten auf der anderen Seite aus dem Kanal heraus
(lesen).
Auf der Clientseite wird über eine URL
\\hostname\pipe\pipename ein Handle zum entfernten Eingang
des Kanals bereitgestellt.
Peter Sobe
19
Pipe als Kommunikationskanal (2)
Tatsächlich wird mit dem Handle eine Datei verbunden, wodurch
der Datenaustausch wie eine normale Dateioperation auf einem
lokalen Rechner abläuft. Auf der Serverseite wird nur der
pipename als Handle zum lokalen Eingang des Kanals
bereitgestellt. Damit wird über das Handle der
Kommunikationskanal als eine Art virtuelle Datei angesehen und
der Datenaustausch über normale Dateioperationen abläuft.
Peter Sobe
20
Aktion
erzeugt
Pipe
Wartet auf
ankommend
e
Verbindung
empfängt
Daten
Sendet
Daten
Löst die
Verbindung
Schließt
Handle
Legende:
Aktion
CreateNamedPipe()
WaitNamedPipe()
ConnectNamedPipe()
CreateFile()
Wartet auf
Pipe verfügbar
Schließt
Datei an
Pipe an
ReadFile()
WriteFile()
sendet
Daten
WriteFile()
ReadFile()
empfängt
Daten
DisconnectNamedP ipe()
CloseHandle()
CloseHandle()
Schließt
Handle
Ablaufsteuerung vom Protokoll der Kooperation a bhängig
Austausch Daten
notwendiger Ablauf
-
Peter Sobe
21
Pipe-Funktionen des Servers
Erzeugen von Pipes - CreateNamedPipe()
Der Server muss auf seinem Rechner die Pipe erzeugen und
dabei die Funktionalität angeben. Bei der Erzeugung gibt er statt
seinem eigenen Computernamen einen Punkt an und legt den
Pipenamen fest,
z. B.: \\.\pipe\p1
Dieses Handle ist der erste Parameter der CreateNamedPipe()Funktion . Der Computername des Servers (hostname) muss
aber zusammen mit dem Pipenamen vom Client beim Zugriff auf
die Pipe benutzt werden.
Peter Sobe
22
Die weiteren Parameter bestimmen Pipe Art, Nutzungsmodi und
Eigenschaften der zu erzeugenden Pipe. Der Rückkehrwert ist
das Handle auf die Pipe. Wir verweisen hier auf die Beispiele,
wo einige Varianten verwendet wurden.
Beispiel als C-Quelltext:
hPipe=CreateNamedPipe("\\\\.\\pipe\\p1",
PIPE_ACCESS_INBOUND, PIPE_WAIT,
PIPE_UNLIMITED_INSTANCES,
256,256,1000,NULL);
Pufferlängen für Ein- und Ausgabe sind 256 Bytes, als Time-out
Zeit gilt 1000 ms und es sind keine Sicherheitsattribute gesetzt.
Peter Sobe
23
Warten auf Client-Verbindungen - ConnectNamedPipe()
Mit der ConnectNamedPipe()-Funktion leitet der Server einen
Warteprozess auf eine Clientanforderung ein. Der erste Parameter ist
das Pipe-Handle, der zweite Parameter ist NULL oder enthält einen
Pointer auf eine overlapped-Struktur. Der Rückkehrwert ist bei Erfolg
verschieden von 0.
Beispiel: ConnectNamedPipe(hPipe,NULL);
(Rückkehrwert wird hier nicht geprüft!)
Aufheben der Client-Verbindungen - DisConnectNamedPipe()
Mit der DisConnectNamedPipe()-Funktion beendet der Server eine
Verbindung zu einem Client. Der einzige Parameter ist das PipeHandle. Der Rückkehrwert ist bei Erfolg verschieden von 0.
Beispiel: DisConnectNamedPipe(hPipe);
(Rückkehrwert wird hier nicht geprüft!)
Peter Sobe
24
Schließen des Pipe-Handles - CloseHandle()
Mit der CloseHandle ()-Funktion schließt der Server das Handle
zu einer Pipe. Der Rückkehrwert ist bei Erfolg ungleich 0.
Beispiel: CloseHandle(hPipe); (Rückkehrwert wird hier nicht
geprüft!)
Pipe-Funktionen des Client
Warten auf die Verfügbarkeit der Pipe - WaitNamedPipe()
Mit der WaitNamedPipe()-Funktion wartet der Client auf die
Pipe, die der Server erzeugen muss. Der erste Parameter
enthält sowohl host- als auch pipe-Namen in der Form
\\hostname\pipe\pipename. Der zweite Parameter enthält eine
time-out-Angabe. Der Rückkehrwert ist bei ungleich 0.
Peter Sobe
25
Anschluß an eine Pipe - CreateFile()
Mit der CreateFile()-Funktion realisiert der Client das Öffnen der
Pipe als eine Datei. Der erste Parameter enthält das pipeHandle in der Form \\hostname\pipe\pipename. Die weiteren
Parameter entnehmen Sie bitte den Beispielen bzw. der
Systemdokumentation. Der Rückkehrwert ist bei Erfolg ein
Datei-Handle, sonst NULL.
Beispiel:
hPipe=Create(“\\\\PROF-EV05DWG90C\\pipe\\p1“,
GENERIC_WRITE, 0, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL );
(Rückkehrwert hPipe müsste auf verschieden NULL getestet
werden!)
Peter Sobe
26
Datenaustausch mit der Pipe
Der Client bedient sich hier normaler Datei-Operationen der
Windows-Plattform. Im Wesentlichen kommen dabei die
ReadFile()- und WriteFile()-Funktionen zum Einsatz. Um
konsistente Abläufe zu erhalten, ist es zweckmäßig, nach
Schreiboperationen die Pipe-Funktion FlushFileBuffers()
aufzurufen. Der einzige Parameter ist das Pipe-Handle. Damit
wird gewartet, bis die kooperierende Anwendung alle
Informationen gelesen hat. Wir verweisen hier auf die Beispiele,
wo einige Varianten verwendet wurden bzw. auf die
Systemdokumentation.
Beispiel: WriteFile( hPipe, text, strlen(text)+1, &dwW, NULL );
Bem.: text ist hier die Adresse eines Speicherbereichs, der die
zu übertragende Nachricht enthält!
Peter Sobe
27
Beenden der Verbindung mit der Pipe – CloseHandle()
Der Client beendet die Verbindung mit der Pipe durch Aufruf der
CloseHandle()-Funktion (vgl. 2.4.4).
Peter Sobe
28
RPC (1)
A new paradigm hides message transfer: Birrell and Nelson,
1984
Remote procedure call (RPC):
• A program calls a subroutine or procedure in another address
space
• RPC is initiated by a client: procedure call and wait for return
• request message to server (hidden)
• server calls procedure locally and transfers the parameters
• response message (hidden)
• client continues operation
• Sun RPC (UNIX), later Microsoft RPC,
• later CORBA and Java RMI for object-oriented languages
Peter Sobe
29
RPC (2)
RPC:
Client
Server
rc=calculate(p1,p2,p3, &solution);
calculate
wait …
client- und server-Stub
Peter Sobe
30
RPC (3)
IDL (interface definition language) for specifications of the
interfaces
Peter Sobe
31
WWW
Web – basierend auf dem Internet
 Das Internet war bereits eher als das Web vorhanden, mit
verteilten Anwendungen, Dateitransfer, NetzwerkDateisystemen (NFS)
 Web: entstanden durch Vorhandensein des HTTP-Protokolls,
der HTML-Sprache, URLs und DNS (Distributed Name Service)
 Nutzung des Webs: ein klassisches Client/Server-Szenario
 Mit dem Web erfolgte eine Kultur- und Wirtschaftsrevolution, da
sich dadurch die Verhaltensweisen der Menschen, die
Organisation wirtschaftlicher Prozesse und auch politische
Aspekte geändert haben.
 Web 2.0: kollaboratives Web, inhaltlich kein Server-zentriertes
Web mehr
Peter Sobe
32
HTTP Protokoll (1)
Hypertext Transport Protocol, größtenteils zum Austausch von
Hypertext (HTML, xHTML) benutzt
Herkunft:
• Das Protokoll wurde ab 1989 von Roy Fielding, Tim BernersLee und anderen am CERN entwickelt
• Zusammenspiel mit den Konzepten URL und HTML.
URL: Unified Ressource Locator
HTML: Sprache zum Aufschreiben von Hypertext-Dokumenten
→ Geburt des WWW, (bzw. Web)
• Zur Kommunikation ist HTTP auf ein zuverlässiges
Transportprotokoll angewiesen. Dafür wird in nahezu allen
Fällen TCP verwendet (Quelle wikipedia)
Peter Sobe
33
HTTP Protokoll (2)
Über HTTPS kann die Übertragung aber verschlüsselt erfolgen.
HTTPS nutzt SSL aus Transportschicht (Secure Socket Layer) und
TLS. Ein HTTPS-Dienst wird typischerweise auf Port 443 angeboten.
HTTP-Eigenschaften:
 HTTP ist zustandslos
 Anfrage, Antwort, Ende: keine komplexen
Kommunikationsszenarien
 Der Zustand eines Clients (Browsers) kann nur über s.g. Cookies
verwaltet werden
Typischer Protokollablauf:
• Anfrage an Server: GET mit Angabe des Dokuments und des
Servers
• Antwort: OK, Infos über Server und HTML-Dokument
Peter Sobe
34
HTTP Protokoll (3)
Typischer Protokollablauf:
•
•
Anfrage an Server:
GET /~sobe/Ueb_Internet/anfang.html HTTP/1.1
Host: www.htw-dresden.de
Antwort:
HTTP/1.1 200 OK
Date: Sun, 20 Mar 2011 11:59:21 GMT
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with
Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
Vary: Accept-Encoding
Content-Length: 1538
Connection: close
Content-Type: text/html; charset=iso-8859-1
< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN„
"http://www.w3.org/TR/html4/loose.dtd" >
< html> ...
Peter Sobe
35
HTTP-Protokoll (4)
HTTP-Operationen im Überblick:
GET – Anfordern einer Ressource mit Angabe einer URL
POST – Senden von Daten zum Server (z.B. für Formulare)
HEAD –Anfordern eines Headers zu einer Ressource
PUT – Hochladen einer Ressource,
bei Webservern oft nicht implementiert
DELETE – Löschen einer Ressource,
bei Webservern oft nicht implementiert
TRACE – Empfangen und Zurücksenden der Anforderung
OPTIONS – Server liefert eine Liste der unterstützten
Operationen zurück
CONNECT – nur für Proxy-Server
Das Hochladen von Web-Inhalten und Löschen erfolgt meistens
durch andere Protokolle (z.B. SFTP Secure File Transfer Prot.)
oder SSH (Secure Shell)
Peter Sobe
36
HTTP-Protokoll (5)
Weiteres in Kapitel 2
Detailinformationen zum HTTP-Protokoll in RFCs (Request
for Comments die De Facto-Standards darstellen)
RFC 1945 (HTTP/1.0) http://tools.ietf.org/html/rfc1945
RFC 2616 (HTTP/1.1) http://tools.ietf.org/html/rfc2616
Peter Sobe
37
HTML und xHTML
HTML – Hypertext Markup Language
Auszeichungssprache für Web-Seiten, folgte schon dem SMGLMeta-Standard
xHTML - eXtensible Hypertext Markup Language
XML konformes HTML, weitestgehend gleiche Elemente wie
HTML
Peter Sobe
38
Architektur von Web-Anwendungen (1)
In HTML lassen sich JavaScript-Programme einbetten, die auf der
Clientseite durch einen Interpreter ausgeführt werden. Damit lassen
sich gewisse „dynamische Effekte“ bei der Anzeige eines HTMLDokumentes erreichen. Das nennt man clientseitiges Scripting.
Es bleibt es bei einer Client-Server-Anwendung, d.h. einer
2-Schichten-Anwendung (2-Tier).
Effekte: Anzeigen neuer Bilder, zeitgebergesteuerte Animationen,
Reaktion auf Mausereignisse, Änderung von Eigenschaften von
Objekten (Farbe, Stil,…), Öffnen neuer Fenster, Message-Boxen und
Dialogfenster usw.
Peter Sobe
39
Architektur von Web-Anwendungen (2)
Client-seitiges Scripting (Fortsetzung):
Prüfung von Nutzereingaben auf Korrektheit. Ein JavaScript kann auf
Eigenschaften von Objekten der grafischen Oberfläche zugreifen und
über Methoden Manipulationen durchführen. Das wird durch ein
Document Object Model (DOM) ermöglicht.
Architektur-Klassen:
2-Tier: Web-Anwendung ohne Scripting, auch Webanwendungen mit
client-seitigem Scripting
3-Tier: Webanwendungen mit server-seitigem Scripting
4-Tier: Webanwendungen mit server-seitigem Scripting und einer
weiterer funktionalen Ebene (meistens eine Datenbank)
Peter Sobe
40
Client-seitiges Scripting (1)
Javascript
• auf Client-Seite ausgeführt
• Script-Code wird innerhalb der HTML-Seite übertragen
• Script-Code ist typischerweise im Head eingebettet
• Das Script kann die Webseite dynamisch verändern, oder
Nachrichtenboxen oder Dialoge initiieren
• Nachladen von Inhalten (im großen Stil) aber nicht möglich,
ohne eine neue Webseite zu laden
Peter Sobe
41
Client-seitiges Scripting (2)
Javascript – Beispiel:
…
<body … onload=“date()“>
<html>
<form id=“Formular“>
<head>
<input size=10 name=“Datum“/>
<title>Die Seite mit dem Datum</title>
</form>
<script language=“JavaScript“>
</html>
function date() {
var j,m,t;
var aktuellesdatum = new Date();
t = aktuellesdatum.getDate();
m = aktuellesdatum.getMonth()+1;
j = aktuellesdatum.getYear();
window.document.Formular.Datum=t+“.“+m+“19“+j;
}
</script>
</head>
Peter Sobe
42
Server-seitiges Scripting (1)
Die Aufbereitung von Web-Inhalten kann auch durch
Programmverarbeitung auf dem Server erfolgen.
Typische serverseitige Skript-Technologien:
 CGI + „irgendetwas, das auf dem Server ausgeführt werden
kann und Hypertext zurückliefert“ , typisch ist CGI in Verbindung
mit einem Perl-Skript
 PHP – eine Sprache, die in HTML eingebettet ist.
Peter Sobe
43
Server-seitiges Scripting (2)
PHP - Hypertext Processor
 auf Server-Seite ausgeführt
 Die Ausgabe des Scrips erzeugt Seiteninhalt
 nur die Ausgabe des Scripts wird per HTTP übertragen
 PHP-Syntax ist an C und Perl angelehnt
Beispiel:
<html>
…
<script language=“php“>
$i=1;
while($i<11) { echo “<br> \n“; $i=$i+1 }
</script>
…
</html>
Peter Sobe
44
Multi-Tier-Anwendungen
Peter Sobe
45
Multi-tier Anwendungen
Peter Sobe
46
Kontrollfragen
 Erklären Sie kurz den Unterschied zwischen den Begriffen
Internettechnologie und Web-Technologie!
 Welche Unterschiede bestehen bei der Benutzung einer
Pipe zwischen der Server- und der Clientseite?
 Ein Nutzer verwendet z.B. den Internet Explorer und fordert
von einem bekannten Web-Server ein Dokument an. Der
Browser zeigt das HTML-Dokument an. Über das Menü
Ansicht wählt er die Quelltext-Ansicht aus.
Kann er am Quelltext erkennen, ob die Web-Anwendung mit
serverseitigem Scripting gearbeitet hat?
Begründen Sie Ihre Antwort!
Peter Sobe
47

1. Internet-Grundlagen und Überblickswissen OSI –Modell (1)

Transcrição

Documentos relacionados

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

Zahlensysteme

x86 Assembler-Programmierung (1)

Preisliste Range Rover

Herzlich willkommen

Bericht über eine Migration von NT SBS auf Windows 2003

Montageanleitungen (PDF 148 KB)

Interoperabilität mit Office

Webhosting - easyWEB4u

Architekturbüro "Architekturwert"

java script xsl zaehler

Embedded Control bequem via Ethernet realisiert