TCP, Ports und Anwendungsprotokolle

TCP, Ports und Anwendungsprotokolle
Inhaltsverzeichnis
1
AUFBAUSTRUKTUR VON NETZEN ......................................................... 2
2
SUBNETTING UND VARIABLE LENGTH OF SUBNETMASK (VLSM)..... 2
3
AUFBAU UND KONFIGURATION EINES ROUTERS............................... 2
4
ROUTING IN RECHNERNETZWERKEN .................................................. 2
5
TCP, PORTS UND ANWENDUNGSPROTOKOLLE ................................. 2
5.1 Transport Protokolle (TCP/IP) ........................................................... 3
5.1.1
Das Port-Konzept.................................................................. 3
5.1.2
Well Known Ports.................................................................. 9
5.1.3
Dynamic Ports..................................................................... 10
5.1.4
Die Socket-Abstraktion ....................................................... 10
5.2 Das User Datagram Protocol (UDP)................................................ 12
5.2.1
Eigenschaften von UDP...................................................... 13
5.3 Das Transmission Control Protocol (TCP)....................................... 14
5.3.1
Eigenschaften von TCP ...................................................... 15
5.3.2
TCP-Handshake zum Verbindungsaufbau.......................... 16
5.3.3
Flusskontrolle unter TCP .................................................... 16
5.3.4
Retransmissions ................................................................. 20
5.3.5
Der TCP-Verbindungsabbau............................................... 21
5.3.6
TCP als Basis für das Applikation Performance Monitoring 21
5.4 Anwendungsprotokolle .................................................................... 23
5.4.1
Das Client-Server Modell .................................................... 23
5.4.2
DNS .................................................................................... 23
5.4.3
Das Internet Control Message Protocol (ICMP) .................. 23
5.4.4
Telnet.................................................................................. 23
5.4.5
Das File Transfer Transfer Protokoll (FTP, TFTP) .............. 23
5.4.6
HTTP .................................................................................. 23
5.4.7
EMAIL ................................................................................. 23
Seite 1 / 23
Document History
Version, Date
Author(s) email address
Changes and other notes
2.7.2006
[email protected]
Basic Version
14.02.2006
S. Zehelein
Grafiken überarbeitet
1
AUFBAUSTRUKTUR VON NETZEN
2
SUBNETTING UND VARIABLE LENGTH OF SUBNETMASK (VLSM)
3
AUFBAU UND KONFIGURATION EINES ROUTERS
4
ROUTING IN RECHNERNETZWERKEN
5
TCP, PORTS UND ANWENDUNGSPROTOKOLLE
Seite 2 / 23
OSI-Layer
Protokolle (Internet)
Teinet
7 Application
FTP
Radius
SMTP
Tacacs
X
Windows
GDP
Transformation
HTTP
TFTP
DHCP
NTP
BOOTP
TACACS+
SNMP
6 Presentation
LPP
DNS
LDAP
IMAP
IMAP
5 Session
IGMP
DVMRP
G
a
t
e
w
a
y
RSVP
4 Transport
TCP
UDP
ICMP
3 Network
OSPF
RIP
BGP
IGRP
NHRP
EGP
GGP
EIGRP
IP
2b Link LLC
ARP RARP DARP IARP
2a Link MAC
Ethernet
802.3
Token Ring
802.5
ATM
ISDN
PPP / SLIP
FDDI
1 Physical
10BaseX
100BaseX
1000BaseX
RJxx
Modem
Standards
UTP / STP
SMF /MMF
H
u
b
S
w
i
t
c
h
R
o
u
t
e
r
Bild: Transport-Protokolle im ISO/OSI-Modell
5.1
Transport Protokolle (TCP/IP)
5.1.1 Das Port-Konzept
Seite 3 / 23
Bild: Aufbau eines TCP/IP-Ethernet-Datenpakets (Encapsulatiom)
Problem:
IP übermittelt Pakete von einem System zu einem anderen, dabei erfolgt keine
Sicherstellung, das Pakete auch ankommen (connectionless).
Außderdem erfolgt durch IP keine Zuordnung zu Applikationen. Frage: Wie werden
Anwendungen auf einem Host identifiziert?
Lösung 1: Direkte Adressierung von Prozessen
Direkte Angabe des Prozeses, für das ein Paket bestimmt ist (sog.
Adressierung von Prozessen bzw. Anwendungen)
Bewertung:
Problematisch, Prozess-ID sind vorher nicht bekannt und können sich zudem
ändern, da Prozesse dynamisch erzeugt (fork) und vernichtet (exit, kill) werden.
Lösung 2: Indirekte Adressierung, d.h. Verwendung von abstrakten Zielpunkten, sog.
Protocol Ports.
Pakete werden mit einer Kennung versehen, die eindeutig einen Dienst
spezifiziert. Diese Kennung nennt man Ports.
Voraussetzung:
Bevor zwei Systeme miteinander kommunizieren können, müssen sie sich auf
die entsprechenden Portnummern einigen.
Es gibt zwei Möglichkeiten Portnummern zu vergeben:
a) Zentrale Vergabe der Port-Nummern (universal binding, well known ports)
- durch die IANA (früher Portnummern <256, heute Portnummern < 1024).
- Wird verwendet für allgemeine Dienste wie Email, FTP, Telnet etc.
b) Dynamische Zuordnung der Portnummern (dynamic binding)
- für Portnummern > 1024, Zuordnung ist nicht standardisiert
Seite 4 / 23
- wird von Anwendungsprogrammen verwendet.
Bild: Ports und zugeordnete Anwendungen
Seite 5 / 23
# Copyright (c) 1993-1999 Microsoft Corp.
# Diese Datei enthält die Portnummern für bekannte Dienste gemäß IANA.
#
# Format:
# <Dienstname> <Portnummer>/<Protokoll> [Alias...]
[#<Kommentar>]
#
echo
7/tcp
echo
7/udp
discard
9/tcp
sink null
discard
9/udp
sink null
systat
11/tcp
users
#Active users
systat
11/tcp
users
#Active users
daytime
13/tcp
daytime
13/udp
qotd
17/tcp
quote
#Quote of the day
qotd
17/udp
quote
#Quote of the day
chargen
19/tcp
ttytst source
#Character generator
chargen
19/udp
ttytst source
#Character generator
ftp-data
20/tcp
#FTP, data
ftp
21/tcp
#FTP. control
telnet
23/tcp
smtp
25/tcp
mail
#Simple Mail Transfer
Protocol
time
37/tcp
timserver
time
37/udp
timserver
rlp
39/udp
resource
#Resource Location Protocol
nameserver
42/tcp
name
#Host Name Server
nameserver
42/udp
name
#Host Name Server
nicname
43/tcp
whois
domain
53/tcp
#Domain Name Server
domain
53/udp
#Domain Name Server
bootps
67/udp
dhcps
#Bootstrap Protocol Server
bootpc
68/udp
dhcpc
#Bootstrap Protocol Client
tftp
69/udp
#Trivial File Transfer
gopher
70/tcp
finger
79/tcp
http
80/tcp
www www-http
#World Wide Web
kerberos
88/tcp
krb5 kerberos-sec
#Kerberos
kerberos
88/udp
krb5 kerberos-sec
#Kerberos
hostname
101/tcp
hostnames
#NIC Host Name Server
iso-tsap
102/tcp
#ISO-TSAP Class 0
rtelnet
107/tcp
#Remote Telnet Service
pop2
109/tcp
postoffice
#Post Office Protocol Version 2
pop3
110/tcp
#Post Office Protocol Version 3
sunrpc
111/tcp
rpcbind portmap
#SUN Remote Procedure Call
sunrpc
111/udp
rpcbind portmap
#SUN Remote Procedure Call
auth
113/tcp
ident tap
#Identification Protocol
uucp-path
117/tcp
nntp
119/tcp
usenet
#Network News Transfer Protocol
ntp
123/udp
#Network Time Protocol
epmap
135/tcp
loc-srv
#DCE endpoint resolution
epmap
135/udp
loc-srv
#DCE endpoint resolution
netbios-ns
137/tcp
nbname
#NETBIOS Name Service
netbios-ns
137/udp
nbname
#NETBIOS Name Service
netbios-dgm
138/udp
nbdatagram
#NETBIOS Datagram Service
netbios-ssn
139/tcp
nbsession
#NETBIOS Session Service
imap
143/tcp
imap4
#Internet Message Access
Protocol
pcmail-srv
158/tcp
#PCMail Server
Seite 6 / 23
snmp
snmptrap
print-srv
bgp
irc
ipx
ldap
https
https
microsoft-ds
microsoft-ds
kpasswd
kpasswd
isakmp
exec
biff
login
who
cmd
syslog
printer
talk
ntalk
efs
router
timed
tempo
courier
conference
netnews
netwall
uucp
klogin
kshell
new-rwho
remotefs
rmonitor
monitor
ldaps
doom
doom
kerberos-adm
kerberos-adm
kerberos-iv
kpop
phone
ms-sql-s
ms-sql-s
ms-sql-m
ms-sql-m
wins
wins
ingreslock
l2tp
pptp
radius
radacct
nfsd
knetd
man
161/udp
162/udp
170/tcp
179/tcp
194/tcp
213/udp
389/tcp
443/tcp
443/udp
445/tcp
445/udp
464/tcp
464/udp
500/udp
512/tcp
512/udp
513/tcp
513/udp
514/tcp
514/udp
515/tcp
517/udp
518/udp
520/tcp
520/udp
525/udp
526/tcp
530/tcp
531/tcp
532/tcp
533/udp
540/tcp
543/tcp
544/tcp
550/udp
556/tcp
560/udp
561/udp
636/tcp
666/tcp
666/udp
749/tcp
749/udp
750/udp
1109/tcp
1167/udp
1433/tcp
1433/udp
1434/tcp
1434/udp
1512/tcp
1512/udp
1524/tcp
1701/udp
1723/tcp
1812/udp
1813/udp
2049/udp
2053/tcp
9535/tcp
#SNMP
#SNMP trap
#Network PostScript
#Border Gateway Protocol
#Internet Relay Chat Protocol
#IPX over IP
#Lightweight Directory Access Protocol
snmp-trap
MCom
MCom
# Kerberos (v5)
# Kerberos (v5)
#Internet Key Exchange
#Remote Process Execution
ike
comsat
#Remote Login
whod
shell
spooler
#Extended File Name Server
route routed
timeserver
newdate
rpc
chat
readnews
#For emergency broadcasts
uucpd
krcmd
new-who
rfs rfs_server
rmonitord
sldap
#Kerberos login
#Kerberos remote shell
#LDAP over TLS/SSL
#Doom Id Software
#Doom Id Software
#Kerberos administration
#Kerberos administration
#Kerberos version IV
#Kerberos POP
#Conference calling
#Microsoft-SQL-Server
#Microsoft-SQL-Server
#Microsoft-SQL-Monitor
#Microsoft-SQL-Monitor
#Microsoft Windows Internet Name Service
#Microsoft Windows Internet Name Service
ingres
nfs
#Layer Two Tunneling Protocol
#Point-to-point tunnelling protocol
#RADIUS authentication protocol
#RADIUS accounting protocol
#NFS server
#Kerberos de-multiplexor
#Remote Man Server
Bild: Portnummern-Zuordnungen in C:\WINNT\system32\drivers\etc\services
Seite 7 / 23
Für eine Gesamtübersicht der Ports siehe auch:
http://www.bekkoame.ne.jp/~s_ita/port/port1-99.html
Ziel der Adressierung ist der Dienst, nicht der konkrete Prozess.
Manche Prozesse bieten mehr als einen Dienst an und müssen mit mehreren Ports
verbunden werden.
Prozesse sollen ersetzt werden können, ohne dass alle Sender benachrichtigt werden
müssen (Reboot kann PIDs ändern)
Application
Application
Socket
Socket
TCP
TCP
IP
Channel
IP
IP
Channel
(e.g., Ethernet)
Host
Router
Host
Bild: TCP/IP-Verbindung
Das Betriebssystem stellt Funktionen zur Verfügung für
-
die Spezifikation und
-
den Zugriff auf Ports.
Die Protokoll-Software synchronisiert den Zugriff auf einen bestimmten Port:
-
Pakete, die von extern an einen bestimmten Port gesendet werden, werden
zunächst in eine Warteschlange gestellt, bis ein Prozess auf den Port zugreift.
Prozesse, die auf einen Port zugreifen, werden blockiert, bis ein Paket für diesen Port
eintrifft.
Seite 8 / 23
Applications
Applications
Descriptor references
TCP sockets
...
...
UDP sockets
Sockets bound to ports
TCP ports
1
2
...
...
65535
1
TCP
2
...
...
65535
UDP ports
UDP
IP
Bild: Zuordnung von Ports zu Applikationen
5.1.2 Well Known Ports
-
Werden für allgemeine Standarddienste (Telnet, Email, FTP, DNS ..) verwendet;
Den Standarddiensten sind damit eindeutige Portnummern zugeordnet.
-
Beispiele:
Dienst
Telnet
FTP
SMTP
HTTP
SNMP
usw.
-
Port
23
21
25
80
161
Protokoll
TCP
TCP
TCP
TCP
UDP
Unter www.rfc-editor.org können die RFC-Protokolldefinitionen eingesehen
werden (Request for Comments - RFC):
PPP
IPCP
PAP
SLIP
IPv4
ICMP
UDP
TCP
DNS
TFTP
HTTP/0.9
ping
finger
telnet
(RFC1661, RFC1662)
(RFC1332, RFC1877)
(RFC1334)
(RFC1055)
(RFC791)
(RFC792)
(RFC768)
(RFC793)
(RFC1034, RFC1035), client and server.
(RFC1350), server.
(RFC2068 for HTTP/1.1), server.
(RFC2151), client.
(RFC1288), client.
(RFC854, RFC857, RFC858), client.
Seite 9 / 23
-
Mit Hilfe von speziellen Konformitätstestprogrammen wie kann eine Prüfung auf
Einhaltung des RFC-Standards erfolgen. Siehe hierzu auch die Webseite
http://validator.w3.org :
“Welcome to the W3C Markup Validation Service; a free service that
checks documents like HTML and XHTML for conformance to W3C
Recommendations and other standards.”
-
Well Known Ports weisen Portnummern < 1024 auf.
ƒ
Heute gibt es viele Dienste, die feste Portnummern oberhalb von 1024
nutzen, z. B. RADIUS port 1812
ƒ
Diese Portnummern sind jedoch nicht reserviert
-
Portnummern <1024 werden unter Unix für privilegierte Programme verwendet.
-
Auf welche Ports ein System reagiert, hängt davon ab, welche Dienste
angeboten bzw. installiert sind (z.B. DNS-Dienst, SNMP Port161 etc.)
5.1.3 Dynamic Ports
-
Dynamic Ports werden von Anwendungen benutzt.
-
Portnummern sollen größer als 1024 sein, um Konflikte mit den Well Known Ports
zu vermeiden.
-
wird von Anwendungsprogrammen verwendet.
-
Die Festlegung der Dienste und der zugehörigen Port-Nummer befindet sich
in der Datei /etc/services (unter Unix) und
in der Datei C:\WINNT\system32\drivers\etc\services (unter
Windows); siehe Bild „Portnummern-Zuordnungen in
C:\WINNT\system32\drivers\etc\services“
-
es können eigene Definitionen hinzugefügt werden.
-
Portnummern möglichst nicht direkt verwenden, besser ist es, diese auf
symbolische Namen abzubilden (Port-Mapping), wie Telnet, FTP, SMTP etc.
5.1.4 Die Socket-Abstraktion
-
Sind auf beiden kommunizierenden Systemen die Tupel
Internet-Adresse + Protokoll + Port-Nummer
Seite 10 / 23
identisch konfiguriert, so kann der Dienst damit eindeutig adressiert werden. Die beiden
Tupel von Sender und Empfänger bilden die eindeutigen Endpunkte einer
Kommunikation.
-
Sockets sind die Endpunkte der Kommunikation
-
Verallgemeinerung des Dateizugriffsmechanismus in UNIX: I/O in UNIX erfolgt via „file
descriptor“. Ein „file descriptor“ ist ein Pointer, der mit einer realen Datei, einem FIFO,
Pipe, Terminal oder eben mit einer Netzwerkverbindung verknüpft ist ( „In UNIX ist
alles eine Datei!“)
-
Unterschied zu Dateien: Sockets können kreiert werden, ohne sie an eine spezielle
Zieladresse zu binden; die Bindung kann zu einem späteren Zeitpunkt erfolgen.
Bild: Socket-Datenstruktur
-
Die Berkley Sockets stellen eine Programmierschnittstelle für die Anwendungsentwicklung zur Verfügung; unter Windows: winsock.dll
-
Kommunikation findet nach dem Client/Server Modell statt.
Seite 11 / 23
Bild: Client/server-Modell
Bemerkungen:
o Kommunikation findet nur bei Bedarf statt
o Server kann mehrere Clients bedienen (sequentiell oder parallel)
Typisches Szenario:
o Ein Server läuft auf einem bestimmten Rechner und besitzt ein Socket,
das an eine bestimmte Port-Nummer gebunden ist. Der Server wartet und
hört bis ein Client eine Verbindung aufbauen will.
o Der Client kennt den Server-Namen, das Protokoll (TCP, UDP) und die
Server-Portnummer und versucht eine Verbindung herzustellen.
o Wenn alle Ressourcen verfügbar sind, akzeptiert der Server die
Verbindung. Nun wird ein neuer Socket auf einem anderen Port kreiert.
Dadurch kann zum einen weiterhin auf Verbindungswünsche (auf dem
Original-Port) reagiert werden, zum anderen kann mit dem Client (über
den neuen Socket) kommuniziert werden.
o Wenn die Verbindung akzeptiert wurde, wird auf der Client-Seite der
Socket erfolgreich angelegt und an eine lokale Port-Nummer gebunden.
o Client und Server können nun kommunizieren.
5.2
Das User Datagram Protocol (UDP)
Das User Datagramm Protocol ist ein ungesicherter, verbindungsloser Transportdienst
des IP-Protokolls.
Seite 12 / 23
Process Layer
FTP
PING
SMTP
Host
to
Host
Layer
TFTP
TELNET
SNMP
TCP
ICMP
ARP
RIP
UDP
EGP
RARP
HELLO
OSPF
IP
Internet
Layer
Network Access Layer
Bild: Das User Datagramm Protocol (UDP)
5.2.1 Eigenschaften von UDP
Bild: Aufbau eines IP-Datenpakets
Bild: Aufbau eines UDP-Datenpakets
Seite 13 / 23
-
IP adressiert nur Zielhosts, UDP hingegen erlaubt es Anwendungsprogrammen
Datagramme zu empfangen und zu versenden.
ungesichert
-
UDP besitzt eine optionale Checksum für transferierte Daten (Checksum = 1er
Komplement und wird über Header und Datenteil gebildet).
-
UDP stellt jedoch nicht sicher, ob die Pakete wirklich beim Empfänger
ankommen; im Fehlerfall finden keine automatischen Retransmissions statt.
-
Die Datensicherheit ist unter UDP also in jedem Fall durch das
Anwendungsprogramm zu gewährleisten.
verbindungslos
-
Pakete werden „ungefragt“ losgeschickt, d. h. Sender und Empfänger sind nicht
miteinander synchronisiert.
-
Vorteil: Da unter UDP keine Verbindungen auf- und abgebaut werden müssen
und der Acknowledgement-Mechanismus fehlt und somit keine TimeoutSituationen entstehen können, ist UDP im Allgemeinen schneller als TCP sein:
Wenn ein Paket verlorengeht, wird die Datenübertragung hier eben ungehindert
fortgesetzt, sofern nicht ein höheres Protokoll für Wiederholungen sorgt.
-
5.3
Vorteil: Kurzer Header
Das Transmission Control Protocol (TCP)
- TCP ist der zentrale Transportdienst im Internet (spezifiziert im RFC 793)
- Das „Transmission Control Protocol“ ist ein gesicherter, verbindungsorientierter
Transportdienst des IP-Protokolls.
- Die TCP-Pakete werden als „Segmente“ bezeichnet
Bild: TCP-Paketaufbau
Seite 14 / 23
Legende:
SEQUENCE NUMBER - Offset des ersten Datenbytes relativ zum Anfang des TCPStreams (garantiert die Einhaltung der Reihenfolge)
ACKNOWLEDGEMENT NUMBER - im nächsten TCP-Paket erwartete Sequence
Number
HLEN - Headerlänge, angegeben in 32bit-Worten
CODE BITS - Gebraucht für TCP-Funktionen; Verbindungsaufbau (SYN-Zeichen)
und Verbindungsabbau (FIN)
WINDOW - Anzahl der Bytes, die der Sender einwilligt zu empfangen, bevor er eine
Quittung erhalten möchte. Anschließend wird erneut die Sendung aufgenommen.
PRÜFSUMME - Prüfsumme über Header und Daten
5.3.1 Eigenschaften von TCP
Gesichert
-
Es wird sichergestellt, dass Pakete beim Sender ankommen. Andernfalls wird
erneut gesendet..
-
Die richtige reihenfolge der TCP-Segmente wird garantiert
Verbindungsorientiert
-
Sender und Empfänger tauschen sich vor der Datenübermittlung Parameter aus.
-
Beide bauen eine virtuelle Verbidnung „Virtual Circuit“ auf.
Die Details des Verbindungsaufbaus, der Verbindungssicherung und des
Verbindungsabbaus sind transparant, d. h. nach oben zur Applikationsebene
nicht sichtbar. Die Verbindung erscheint dadurch wie eine direkte eigene
Hardwareverbindung („Virtual Circuit“).
-
Verbindungen werden in definierter Weise angelegt und beendet, der Paketstrom
hört nicht einfach auf.
-
TCP erzeugt einen Datenstrom (stream oriented); Daten werden als Strom von Bytes
gesendet, evtl. bleiben die Blockgrenzen nicht erhalten
-
TCP baut eine Full-Duplex Verbidnung auf, d. h. eine gleichzeitige Verbindung in beiden
Richtungen ist möglich (wichtig für die Flusssteuerung).
-
TCP verwendet wie UDP das Port-Konzept.
Seite 15 / 23
5.3.2 TCP-Handshake zum Verbindungsaufbau
-
TCP verwendet einen 3-Wege Handshake
1) Sender sendet SYN mit einer zufällig gewählten Zahl SEQ für den Datenstrom
2) Empfänger bestätigt mit Angabe des nächsten erwarteten Paketes und wählt
gleichzeitig für seinen eigenen Datenstrom eine zufällige SEQ-Nummer.
3) Sender sendet analog zum Empfänger ein ACK; Die Verbindung ist damit aufgebaut,
optional kann mit der letzten Bestätigung bereits gesendet werden.
Bsp. 1: Verbindungsaufbau
5.3.3 Flusskontrolle unter TCP
-
TCP teilt den Datenfluss für die Übertragung in Segmente ein.
-
Der Empfänger steuert den Datenfluss durch Mitteilen der verfügbaren Buffer im
Headerparameter windowsize.
-
Ein Fenster mit der Größe 0 (windowsize = 0) stoppt die Sendung, durch allmähliches
Vergrößern der Fenstergröße wird der Datenfluss wieder in Gang gesetzt.
-
Der Empfänger kann zusätzliche ACKs schicken, wenn wieder Empfangspuffer zur
Verfügung stehen.
-
Eine Optimierung bei der Bestätigung von Segmenten ergibt sich nach dem Prinzip der
sliding windows
-
Jede Seite einer Verbindung darf die Anzahl an Bytes senden, die im Fenster
angegeben ist, ohne auf eine Quittung warten zu müssen.
-
Typischer Wert für die maximale Fenstergröße ist bei Workstations 4096 Bytes,
bei Servern in der Regel höher.
-
Höhere Werte insbesondere bei „long fat pipes“ wichtig (z. B. bei
hochbandbreitige Leitungsverbindungen mit großen Delays, z. B. bei
Transkontinentalverbindungen)
Seite 16 / 23
Bild: Zustandsdiagramm des TCP-Protokolls
Seite 17 / 23
Bsp. 1: Flusskontrolle
Bsp. 2: Flusskontrolle
Bild: Hilfe zu netstat
Seite 18 / 23
Bild: Anzeige aktueller TCP-Verbindungen mit netstat
Seite 19 / 23
Bild: Anzeige aktueller TCP-Verbindungen mit netstat
5.3.4 Retransmissions
-
Im Fehlerfall wird die TCP-Nachricht wiederholt (Retransmissions). Feste Timeout-Zeiten
bis zur Wiederholung der Nachricht sind ungünstig, da
- Verzögerungen meist variabel sind
- der Performanceverlust zu groß ist
- unnütze Netzbelastung durch Wiederholungen
-
Lösung: TCP ermittelt für jede Verbindung eine sog. „round trip time“ (RTT).
Die RRT ist die durchschnittliche Verzögerung zwischen Aussenden eines Segments
und Empfangen der Bestätigung (ACK).
- Der Retransmit-Timer basiert auf RTT.
Bild: Der Retransmit-Timer
Seite 20 / 23
5.3.5 Der TCP-Verbindungsabbau
Bild: Abbau einer TCP-Verbindung
5.3.6 TCP als Basis für das Applikation Performance Monitoring
TCP/IP-Verbindungen werden für Performance Betrachtungen („Performance Monitoring“)
herangezogen. Hiermit lassen sich sowohl Fehler in der Applikationssoftware als auch im
Kommunikationssystem detektiert.
Das TCP-Protokoll ermöglicht durch seinen Aufbau die Applikationsantwortzeit an einem
sehr servernahen Punkt.
Hierbei werden drei Verzögerungszonen unterschieden:
-
Netzwerkübertragungsdauer (Network Roundtrip Time)
-
Verarbeitungsdauer der Anfrage zur Applikationsmessung (Server Initial
Response Time)
-
Übertragungsdauer des Ergebnisses (Data Transfer Time)
Die folgende Darstellung zeigt an einem vereinfachten TCP/IP-Modell die einzelnen
Parameter:
Seite 21 / 23
Messeinheit
SYN
SYN-ACK
1)
ACK
Application Request
3)
Application Response: ACK + Data
4)
Application Data
2)
ACK
Legende:
1) Connection setup time
2) Network roundtrip time
3) Server initial response time
4) Data transfer time
Bild: Zeitparameter am TCP-Verbindungsmodell
Die Aufzeichnung dieser Parameter über die Zeit ergibt für jede erfasste Applikation ein
netzwerkspezifisches Muster. Diese Messwerte können jedoch nicht dazu genutzt
werden, die Qualität einer Verbindung zu bewerten (Gut oder Schlecht). Dies ist nur
möglich, indem die Aussagen der betroffenen Anwender oder vorherige
Referenzmessungen als Beobachtungsbasis genutzt werden.
Die Aufzeichnung der Antwortzeit über die Zeit lassen jedoch Aussagen über die
Änderung der Qualität zu, die dann den einzelnen Bereichen Netzwerk, Server und
Applikationen zugeordnet werden können.
Um diese Werte für eine Bewertung zu nutzen, ist eine Vielzahl von Beobachtungen
notwendig, deren Mittelwerte die entsprechenden Aussagen ermöglichen. Je mehr
einzelne TCP-Sessions innerhalb eines Zeitrasters erfasst werden können, desto
repräsentativer sind die entsprechenden Aussagen.
Seite 22 / 23
5.4
Anwendungsprotokolle
5.4.1 Das Client-Server Modell
Kommunikation findet nach dem Client/Server Modell statt.
Bild: Client/server-Modell
Bemerkungen:
- Kommunikation findet nur bei Bedarf statt
- Server kann mehrere Clients bedienen (sequentiell oder parallel)
In Bearbeitung:
5.4.2 DNS
5.4.3 Das Internet Control Message Protocol (ICMP)
5.4.4 Telnet
5.4.5 Das File Transfer Transfer Protokoll (FTP, TFTP)
5.4.6 HTTP
5.4.7 EMAIL
Seite 23 / 23