TCP, Ports und Anwendungsprotokolle
Werbung
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
