Vorlesung. Rechnernetze II Teil 11. Sommersemester 2007

Transkript

1 Vorlesung Rechnernetze II Teil 11 Sommersemester 2007 Christian Grimm Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze

2 Übersicht Performance von TCP Socket-Buffer und MTU alternative Varianten von TCP TCP-Highspeed und TCP-BIC Socket-Programmierung Ergänzung listen () Verbindungsabbau in TCP I/O-Modelle in UNIX Design von Servern Daemon Processes inetd C. Grimm 4. Juli 2007 Folie 2

3 Socket-Buffer Eigenschaften der Socket-Buffer in TCP Client: Speicher für gesendete (warten auf ACK) und zu sendende TCP-Segmente Server: Speicher für empfangene und zu verarbeitende TCP-Segmente (RecvBuffer) freier Speicher im Socket-Buffer entspricht Option RecvWindow im TCP-Header Eigenschaften der Socket-Buffer in UDP lediglich Weitergabe einzelner Datagramme von IP- zur Anwendungsschicht Achtung: falls Socket-Buffer auf Empfänger zu klein für ein UDP-Datagramm ist, wird das UDP-Datagramm verworfen bzw. zurückgewiesen Einstellungen Größen der Socket-Buffer können durch die Funktion setsockopt() gesetzt werden Default Werte variieren stark zwischen verschiedenen Betriebssystemen Achtung setsockopt() muss aufgerufen werden, bevor Client und Server MSS aushandeln gilt entsprechend auch bei Verwendung der Window Scale Option C. Grimm 4. Juli 2007 Folie 3

4 TCP-Durchsatz in Abhängigkeit der Socket-Buffer maximale Größen Ethernet: Default MTU beträgt Byte, bei Jumbo Frames Byte IP: IPv Byte inkl. 20 Byte Header, in IPv Byte zzgl. 40 Byte Header TCP: MSS beträgt maximale Größe eines IP-Paketes abzüglich 20 Byte TCP-Header Anwendung Betriebssystem Application Layer Größe durch Deklaration der Variablen read/write buffer bzw. bei Systemaufruf recv (..., nbyte) send (..., nbyte) TCP/UDP socket buffer Größe manipulieren durch setsockopt () MSS IP IP (re)assembly buffers Betriebssystem Netzwerk-Interface Data Link Layer input/output queue MTU MTU + Header/Trailer C. Grimm 4. Juli 2007 Folie 4

5 Nutzdatenrate in Abhängigkeit der Socket-Buffer Messung mit netperf zwischen SGI Onyx 2 uns SGI Origin 200 (IRIX 6.3) MBit/sec Gigabit Ethernet, normal framesize, MTU Byte 64 KByte Socket Buffer 128 KByte Socket Buffer 256 KByte Socket Buffer 512 KByte Socket Buffer 1024 KByte Socket Buffer Read/Write Buffer Size [KByte] C. Grimm 4. Juli 2007 Folie 5

6 Nutzdatenrate in Abhängigkeit der Socket-Buffer Messung mit netperf zwischen SGI Onyx 2 uns SGI Origin 200 (IRIX 6.3) MBit/sec Gigabit Ethernet, jumbo frames, MTU Byte KByte Socket Buffer 128 KByte Socket Buffer 256 KByte Socket Buffer 512 KByte Socket Buffer 1024 KByte Socket Buffer Read/Write Buffer Size [KByte] C. Grimm 4. Juli 2007 Folie 6

7 Berechnung der mittleren Datenrate in TCP Reno zunächst grobe Abschätzung mit folgenden Annahmen Rechnernetze I Teil 7 keine Timeouts, nur Duplicate Acknowledgement lange Übertragung: Slow Start kann vernachlässigt werden RTT ist konstant Congestion Window erreicht stets C max, bevor Duplicate Acknowledgement auftritt daraus folgt: nach Verlust beträgt Congestion Window C min = C max / 2 CongWindow [in MSS] C max C min mittlere Datenrate R (beachte: MSS und RTT sind konstante Größen) Datenrate schwankt linear zwischen C min MSS / RTT und C max MSS / RTT daraus folgt: mittlere Datenrate R ist der Mittelwert zwischen beiden Extremen t R = Cmax Cmin + MSS = 2 RTT RTT 1 Cmax Cmax + MSS = 2 RTT 2 RTT 3 C 4 RTT 1 max MSS C. Grimm 4. Juli 2007 Folie 7

8 Berechnung der mittleren Datenrate in TCP Reno hier Darstellung in Abhängigkeit der Paketverlustrate L (Loss Rate) Annahmen wie oben Rechnernetze I Teil 7 Verlust eines Pakets durch Duplicate Acknowledgement bei C max zunächst: Berechnung der Anzahl zwischen C max / 2 und C max gesendeten Segmente p C p = 2 max C = 2 max C C max max C / 2 n= 0 Loss Rate L = Anzahl verlorener Segmente / Anzahl gesendete Segmente = 1 / p L = 1 p = 3 C 8 2 max mittlere Datenrate R und mittleres Congestion Window C (MSS und RTT sind konstante Größen!) 3 C max 3 8 MSS 122, MSS R = MSS = = C 4 RTT 4 3L RTT L RTT 1,22 mit C = (auch TCP Response Function) L C. Grimm 4. Juli 2007 Folie 8 + C max C 4 max C n = 2 max max 3 für C 8 C L + 2 C max max max C >> C 4 max max C + 2 max C 2 max L MSS RTT = 3C C / 2 max n= = 8 2 max C 3 C 8 C max 2 2 max max + C / 2 max n= C 4 8 3L n max

9 TCP-Reno in High-Performance-Netzen Berechnung der maximalen Paketverlustrate in High-Performance-Netzen für R=10 GBit/s, RTT = 100 ms und MSS = Byte ergibt sich L 2 1,22 MSS 10 Paket = = 2, R RTT Anmerkung zur MSS = Byte: Korrekt wäre hier MSS = Byte, sämtliche Berechnungen beziehen sich im Folgenden jedoch gem. RFCs auf diesen Wert (s. u.) diese Paketverlustrate entspricht einer unrealistischen(!) Bitfehlerrate von L 2 1,22 17 Bit MSS = 1, = R RTT für eine Paketverlustrate von ergibt sich eine mittlere Rate R von lediglich 1,22 MSS R = = 146MBit/s L RTT C. Grimm 4. Juli 2007 Folie 9

10 TCP-Reno in High-Performance-Netzen Zeitbedarf zur Wiederherstellung von C max in Congestion Avoidance Phase R = 10 GBit/s und RTT = 100 ms ergibt BDP = R RTT = 125 MByte mit MSS = Byte folgt erforderliches C max = MSS Achtung: nicht mit Gleichung Folie 8 unten rechnen, da dort mittlere Rate berechnet wird hier interessiert max. mögliche Rate nach einzelnem Paketverlust setzt TCP-Reno C neu = C max / 2 danach wird Congestion Window mit jeder RTT um 1 MSS erhöht d. h. um C max wieder zu erreichen vergehen C max / 2 RTT = 4.166,65 Sekunden 69 Minuten Fazit: Der Einsatz von TCP-Reno ist in High-Performance-Netzen problematisch zumindest bei einzelnen Paketverlusten und hohem BDP C. Grimm 4. Juli 2007 Folie 10

11 TCP-Reno in High-Performance-Netzen Messung der Reaktion auf Paketverluste R = 1 GBit/s, RTT=100 ms deterministischer Paketverlust bei jedem Paket R rech = 146 MBit/s es wurden 10 GByte Daten übertragen initialer Slow-Start Threshold beträgt ssthresh = FFFFFF 16 [MSS] (entspricht unendlich) TCP Reno TCP Reno average Übertragungsrate R [MBit/s] Anmerkung: Abweichung der tatsächlichen mittleren Datenrate von der rechnerischen unklar. Evtl. durch stärkeres Herabsetzen des Congestion Window nach Paketverlusten MBit/s tatsächlicher Mittelwert ca. 85 MBit/s Messdauer t [s] C. Grimm 4. Juli 2007 Folie 11

12 Transportprotokolle für High-Performance-Netze neues auf IP basierendes Transportprotokoll mit Congestion Signalisierung Vorteil: Unterscheidung zwischen Bitfehler und Paketverlust durch Congestion möglich Nachteil: erfordert Anpassung des Betriebssystems und der Netzwerkkomponenten neue TCP-Variante mit geändertem Congestion Control Vorteil: keine Änderung der Anwendungen notwendig Nachteil: erfordert Anpassung des Betriebssystems wird im Folgenden betrachtet neues auf UDP basierendes Transportprotokoll Vorteil: keine Änderung des Betriebssystems Nachteil: erfordert Anpassung der Anwendungen Übertragung über mehrere parallele TCP-Streams Vorteil: keine Änderungen an Kernel und Netzwerkkomponenten, erprobte Technik bekannt und implementiert in FTP, P2P, HTTP Nachteil: mangelhafte Fairness, Probleme mit Firewalls C. Grimm 4. Juli 2007 Folie 12

13 Varianten von TCP es existieren zahlreiche TCP-Varianten mit geändertem Congestion Control u. a. Highspeed, Scalable, BIC, CuBIC, Vegas, Hamilton, Westwood im Folgenden werden lediglich TCP-Highspeed und TCP-BIC näher betrachtet unterschiedliche Zielsetzungen Einsatzgebiete bessere Leistung in High-Performance-Netzen oder bessere Leistung bei sehr großer RTT (z. B. Satellitenstrecken) TCP Friendliness: Fairness gegenüber TCP-Reno wird entweder nur bei kleinem Congestion Window betrachtet oder soll immer gewährleistet sein Methoden zur Realisierung Änderung der Reaktion auf Paketverluste und/oder Acknowledgements Delay-basierte Reaktion Erhöhung der RTT wird als Congestion interpretiert C. Grimm 4. Juli 2007 Folie 13

14 TCP-Highspeed Zielsetzungen bessere Leistung in High-Performance-Netzen TCP Friendliness bei kleinem Congestion Window d. h. bei geringem BDP oder starker Congestion nicht verfolgt wird TCP Friendliness in High-Performance-Netzen mit geringer Verlustrate und großem BDP Realisierung durch veränderte Reaktion auf Paketverluste und Acknowledgements Rahmenbedingungen für den Entwurf nach RFC 3649 maximale Leistung soll erreicht werden für High-Performance Netze mit R = 10 GBit/s mit RTT = 100 ms MSS = Byte Verlustrate L = 10-7 Verhalten von TCP-Reno bei C 38 (entspricht einer Paketverlustrate L 10-3 ) C. Grimm 4. Juli 2007 Folie 14 C max = Anmerkung zur MSS = Byte: korrekt wäre MSS = Byte, sämtliche Berechnungen im RFC beziehen sich jedoch auf diesen Wert

15 TCP-Highspeed Response Function Ansatz es wird eine TCP Response Function gebildet, die diese Rahmenbedingungen erfüllt die TCP Response Function soll im logarithmischen Maßstab eine Gerade ergeben S L log( High_Window ) log( Low_Window) C = Low_Window mit S = = 0, Low_L log( High_L) log(low_l) und Low_Window = 38 High_Window = Low_L = 10-3 High_L = 10-7 Vergleich der berechneten mittleren Datenrate von TCP-Reno und TCP-Scalable aus R = C MSS / RTT mit MSS = Byte und RTT = 0,1 s für L = : R Reno = 4,6 MBit/s und R Highspeed = 4,6 MBit/s für L = : R Reno = 463 MBit/s und R Highspeed = MBit/s C. Grimm 4. Juli 2007 Folie 15

16 TCP-Highspeed Congestion Control Parameter Anpassungen des Congestion Windows, die die TCP Response Function erfüllen bei eintreffenden ACKs n+ 1 = Cn + ( n ) Cn C a C / bei auftretenden Paketverlusten C n+ 1 = 1 ( b( Cn )) Cn a(c) und b(c) ergeben sich aus der TCP Response Function (hier ohne Herleitung) für C 38 beträgt a(c) = 1 und b(c) = 0,5 und entspricht damit TCP-Reno existierende Implementierungen verwenden wg. besserer Performance Tabellen insgesamt werden ca. 200 Werte vorgegeben, mit denen interpoliert wird Auszug C a(c) b(c) ,50 0,35 0,22 0,10 C. Grimm 4. Juli 2007 Folie 16

17 TCP-Highspeed Congestion Control Parameter Verlauf der Congestion Control Parameter a(c) und b(c) a(c) als Zuwachs des Congestion Window bei eintreffenden ACKs 100 a(c) 10 1 TCP-Highspeed TCP-Reno C 0, b(c) als Verringerung des Congestion Window bei Paketverlusten 0,5 0,4 b(c) 0,3 0,2 TCP-Highspeed TCP-Reno 0,1 0, C C. Grimm 4. Juli 2007 Folie 17

18 TCP-Highspeed Messung der Reaktion auf Paketverluste R = 1 GBit/s, RTT=100 ms deterministischer Paketverlust bei jedem Paket es wurden 10 GByte Daten übertragen initialer Slow-Start Threshold beträgt ssthresh = FFFFFF 16 [MSS] (entspricht unendlich) Highspeed Highspeed average Übertragungsrate R [MBit/s] Messdauer t [s] C. Grimm 4. Juli 2007 Folie 18

19 TCP Friendliness von TCP-Highspeed Messaufbau zur TCP Friendliness von TCP-Highspeed und TCP-BIC Sender 1 TCP-Reno 1 GBit/s Router Router Empfänger Sender 1 1 GBit/s 1 GBit/s TCP-Highspeed TCP-BIC 1 GBit/s zufällige Paketverluste durch Überlastung deterministische Verzögerungen Messverfahren durch gleichzeitiges Senden von zwei Datenströmen mit 1 GBit/s auf einen Link mit 1 GBit/s werden zufällige Paketverluste provoziert zusätzlich wird durch deterministische Verzögerung aller Pakete höhere RTT emuliert der Datenstrom mit TCP-Reno wird zuerst gestartet, um von maximalem Durchsatz ausgehen zu können C. Grimm 4. Juli 2007 Folie 19

20 TCP-Highspeed geringe TCP Friendliness von TCP-Highspeed TCP-Reno wird deutlich verdrängt Highspeed Highspeed average Reno Reno average Übertragungsrate R [MBit/s] Messdauer t [s] C. Grimm 4. Juli 2007 Folie 20

21 TCP-BIC Ansatz Congestion Control als Suchproblem nach einem maximalen Congestion Window C max das Netz gibt ja/nein Feedback über ermitteltes Maximum durch Paketverluste Binary Congestion Information (BIC) Zielsetzungen (vgl. TCP-Highspeed) bessere Leistung in High-Performance-Netzen TCP Friendliness bei kleinem Congestion Window d. h. bei geringem BDP oder starker Congestion begrenzte TCP Friendliness in High-Performance-Netzen mit geringer Verlustrate Realisierung durch veränderte Reaktion auf Paketverluste und Acknowledgements zusätzlich Plateau-Phase für TCP Friendliness Achtung seit Kernel ist TCP-BIC der TCP-Standard unter Linux C. Grimm 4. Juli 2007 Folie 21

22 TCP-BIC TCP-BIC unterscheidet in Congestion Avoidance drei Phasen C max ist dabei der Mittelwert von C direkt vor und nach einem Paketverlust 1. Additive Increase lineare Annährung von C an C max bis zum Schwellwert C max S max allerdings größere Steigung, d. h. aggressiveres Verhalten als in TCP-Reno 2. Binary Search Plateauphase für TCP Friendliness langsamer Anstieg von C bis zum Erreichen von C max in dieser Phase können andere Datenströme ihr Congestion Window erhöhen 3. Maximum Probing Suche nach neuem Maximum kurzer Slow-Start in a), danach linearer Anstieg in b) bis nächster Paketverlust auftritt C Additive Increase Binary Search Maximum probing a) b) C max C max S max t C. Grimm 4. Juli 2007 Folie 22

23 TCP-BIC Reaktion auf Paketverluste R = 1 GBit/s, RTT=100 ms deterministischer Paketverlust bei jedem Paket es wurden 10 GByte Daten übertragen initialer Slow-Start threshold beträgt ssthresh = (Gründe für geringen Wert unklar) Slow-Start nicht erkennbar wg. geringem ssthresh, danach zeigt Implementierung in Linux stark abweichendes Verhalten BIC BIC average 600 Übertragungsrate R [MBit/s] Messdauer t [s] C. Grimm 4. Juli 2007 Folie 23

24 TCP-BIC geringe TCP Friendliness von TCP-BIC TCP-Reno wird auch von TCP-BIC deutlich verdrängt reno RTT 100 reno RTT 100 average bic RTT 100 bic RTT 100 average Übertragungsrate R [MBit/s] Messdauer t [s] C. Grimm 4. Juli 2007 Folie 24

25 Fazit Performance von TCP TCP-Reno zeigt belegbare Schwächen in High-Performance-Netzen wesentliche Ursache ist linearer Anstieg der Datenrate in Congestion Avoidance Phase resultiert aus linearer Vergrößerung des Congestion Windows über der RTT d.h. Steigung hängt von RTT ab die Schwächen treten allerdings nur in besonderen Situationen auf bei hohem BDP und einzelnen Paketverlusten langen Übertragungsdauern entsprechen großen Datenvolumen mittlerweile sind zahlreiche alternative TCP-Varianten verfügbar zeigen häufig bessere Performance gegenüber TCP-Reno Modifikationen besonders in Congestion Avoidance Phase aggressivere, z. T. nicht lineare Vergrößerung des Congestion Windows TCP-Varianten zeigen jedoch geringe TCP Friendliness TCP-Varianten werden auch zukünftig ein großes Thema in der Forschung sein, u. a. Welche neuen sinnvollen Optimierungen sind möglich? Wie verhalten sich die Implementierungen neuer TCP-Varianten? TCP-Varianten sind durch UDT (oberhalb UDP!) auch für beliebige Betriebssysteme verfügbar Wie kann man unfaire Protokolle verhindern? C. Grimm 4. Juli 2007 Folie 25

26 Rückblick Socket-Programmierung grundlegende Funktionen Erzeugen eines Socket-Deskriptors (Analogie File-Deskriptor): socket () Zuweisung IP- Adresse und Port, im Prinzip nur auf Server notwendig: bind () verbindungsloses Senden und Empfangen über UDP: sendto () und recvfrom () Verbindungsaufbau in TCP: listen () / accept () auf Server (Passive Open) connect () auf Client (Active Open) verbindungsorientiertes Senden und Empfangen über TCP: send () und recv () Funktionen zur korrekten Darstellung der Daten network byte order ist big endian Umwandlung durch htons (), htonl (), ntohs () und ntohl () weitere Darstellung in den folgende Folien es werden ausschließlich TCP-Verbindungen betrachtet nähere Untersuchung des Passive Open, d. h. listen () und accept () C. Grimm 4. Juli 2007 Folie 26

27 Beispiel: Übertragung eines Strings (TCP) /* gcc -Wall -o clie_tcp_simplex clie_tcp_simplex.c */ #include <stdio.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <arpa/inet.h> #define BUFFERSIZE 20 #define PORT 7923 #define SERVER " " /* gcc -Wall -o serv_tcp_simplex serv_tcp_simplex.c */ #include <stdio.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <arpa/inet.h> #define BUFFERSIZE 20 #define PORT 7923 int main ( void ) { int char struct sockaddr_in sockfd; sendbuf[buffersize]; s_addr; int main ( argc, argv ) { int sockfd, newsockfd; int clielen, recvlen; char recvbuf[buffersize]; struct sockaddr_in s_addr, c_addr; if ( ( sockfd = socket ( AF_INET, SOCK_STREAM, 0 ) ) < 0 ) { perror ( "socket" ); return -1; } bzero ( ( char * ) &serv_addr, sizeof ( serv_addr ) ); s_addr.sin_family = AF_INET; s_addr.sin_addr.s_addr = inet_addr ( SERVER ); s_addr.sin_port = htons ( PORT ); if ( ( sockfd = socket ( AF_INET, SOCK_STREAM, 0 ) ) < 0 ) { perror ( "socket" ); return -1; } bzero ( ( char * ) &serv_addr, sizeof ( serv_addr ) ); s_addr.sin_family = AF_INET; s_addr.sin_addr.s_addr = htonl ( INADDR_ANY ); s_addr.sin_port = htons ( PORT ); if ( bind ( sockfd, (struct sockaddr *) &s_addr, sizeof ( s_addr ) ) < 0 ) { perror ( "bind" ); return -1; } } if ( connect ( sockfd, (struct sockaddr *) &s_addr, sizeof (s_addr) ) < 0 ) { perror ( "connect" ); return -1; } strcpy ( sendbuf, "Hi there!!" ); if ( send ( sockfd, sendbuf, strlen ( sendbuf ), 0 ) < 0 ) { perror ( "send" ); return -1; } close ( sockfd ); return 0; C. Grimm 4. Juli 2007 Folie 27 listen ( sockfd, 5 ); clielen = sizeof ( c_addr ); newsockfd = accept ( sockfd, (struct sockaddr *) &c_addr, &clielen ); if ( newsockfd < 0 ) { perror ( "accept" ); return -1; } recvlen = recv ( newsockfd, recvbuf, BUFFERSIZE, 0 ); if ( recvlen < 0 ) { perror ( "recv" ); return -1; } recvbuf[recvlen] = 0; printf ( "Empfangen: %s\n", recvbuf ); close ( sockfd ); close ( newsockfd ); return 0; }

28 listen () und accept () Einordnung listen () und accept () werden nur in TCP-basierten Anwendungen aufgerufen listen () und accept () werden nur auf einem Server aufgerufen listen () initialisiert u. a. Queues und Buffer für eingehende Requests (s. u.) ohne vorheriges listen () werden eingehende Requests vom Server abgewiesen mit listen () initialisiert das Betriebssystem die Ressourcen für einen Server Aufruf: listen ( int sd, int backlog ) sd backlog Socket-Deskriptor C. Grimm 4. Juli 2007 Folie 28 aus Manpage zu listen (): The backlog parameter defines the maximum length the queue of pending connections may grow to. mit accept () nimmt Server aufgebaute Verbindungen entgegen Aufruf: int accept ( int sd, struct sockaddr *addr, socklen_t *addrlen ) erzeugt einen neuen Socket-Deskriptor für die aufgebaute Verbindung über diesen Socket-Deskriptor kommunizieren der Server mit dem jeweiligen Client TCP/IP-Stack auf Server kann aber bereits vorher Daten von Client empfangen Daten werden deshalb im Socket-Buffer (d. h. RecvBuffer) abgelegt accept () blockiert, falls keine aufgebauten Verbindungen vorliegen (s. u.)

29 Untersuchung des Parameters backlog Versuch 1 rufe Funktion listen () mit backlog von n auf warte danach ohne accept () auf Requests, z. B. durch sleep ( 60 ) im Beispiel oben baue während der Wartephase Verbindungen von mehreren Clients auf im Client genügt ein connect () mit anschließendem close () Erwartung es werden Verbindungen von n Clients durch Senden eines SYN-ACK akzeptiert danach werden keine weiteren SYN-ACK gesendet, der Verbindungsaufbau ist blockiert Ergebnis Durchführung s. Demo backlog = n Anzahl Connects folgt daraus Anzahl Connects = n + 4? Frage: was sind eigentlich pending connections? C. Grimm 4. Juli 2007 Folie 29

30 TCP State Transition Diagram normal transition for server normal transition for client other possible transitions appl: passive open send: <nothing> starting point CLOSED appl: state transitions taken when application issues operation recv: state transitions taken when segment received send: what is sent for this transition Quellen G. R. Wright, W. Richard Stevens, TCP/IP Illustrated Volume 2 The Implementation. Addison Wesley, G. McKinney. resources/tcpip_state_transition_dia gram.pdf. November active close SYN_RCVD FIN_WAIT_1 timeout send: RST appl: close send: FIN recv: SYN send: SYN, ACK recv: RST recv: ACK send: <nothing> appl: close send: FIN recv: FIN send: ACK LISTEN passive open recv: SYN send: SYN, ACK simultaneous open ESTABLISHED data transfer simultaneous close CLOSING appl: active open send: SYN appl: send data send: SYN recv: SYN, ACK send: SYN recv: FIN send: ACK SYN_SENT active open CLOSE_WAIT appl: close send: FIN LAST_ACK appl: close or timeout recv: ACK send: <nothing> recv: ACK send: <nothing> recv: FIN, ACK send: ACK recv: ACK send: <nothing> passive close FIN_WAIT_2 recv: FIN send: ACK TIME_WAIT 2MSL timeout C. Grimm 4. Juli 2007 Folie 30

31 Connection Queues in TCP TCP verwaltet für jeden listening Socket zwei Queues für eingehende Requests incomplete connection queue Verbindung ist im Zustand SYN_RCVD Warten auf ACK im three way handshake completed connection queue Verbindung ist im Zustand ESTABLISHED three way handshake ist erfolgreich beendet Anmerkung: beide Queues werden nicht FCFS abgearbeitet Einträge sind unabhängig voneinander backlog gibt die maximale Summe der Requests in beiden Queues an pending connections Zustand ESTABLISHED completed Connection Queue Zustand SYN_RCVD incomplete Connection Queue Zustand LISTEN Aufruf von accept () in Anwendung eingehendes ACK auf SYN-ACK eingehendes SYN, SYN-ACK gesendet C. Grimm 4. Juli 2007 Folie 31

32 Pending connections und 3-way handshake Ablauf 3-way handshake Aufruf von connect () Zustand SYN_SENT SYN Aufruf von listen () und accept () SYN, ACK Eintrag in incomplete queue Zustand SYN_RCVD connect () kehrt zurück Zustand ESTABLISHED ACK Eintrag wandert von incomplete queue in completed queue Zustand ESTABLISHED accept () kehrt zurück und liefert neuen Socket Client t t Server Anmerkung Server verwirft SYN des Client bei gefüllter incompleted queue sendet also auch kein RST an Client zurück Intention Client sendet nach Ablauf Connection Timeout SYN erneut dann ist hoffentlich Platz in incompleted queue C. Grimm 4. Juli 2007 Folie 32

33 Bemerkungen zu backlog es existiert keine eindeutige Definition des Parameters backlog Stevens: There has never been a formal definition of what the backlog means. Spezifikationen übernehmen i. d. R. ursprüngliche Definition aus 4.2BSD UNIX einige Betriebssysteme modifizieren backlog intern z. B. in BSD UNIX durch Multiplikation mit einem Fudge Factor von 1,5 Stevens: The reason for adding this fudge factor appears lost in history [Joy 1994]. nach Experiment scheint Linux Faktor 4 zu addieren Stevens: Untersuchung auf 6 verschiedenen Betriebssystemen brachte für ein backlog von 13 tatsächlich 6 verschiedene Werte (8, 13, 14, 18, 20 und 21) eine Limitierung der Connection Queues ermöglicht DoS-Attacken TCP SYN Flooding: Fluten durch SYN-Segmente mit gefälschter IP-Adresse (Client) Abhilfe: TCP SYN Cookies (werden hier nicht erläutert) Zusammenfasung bei gezielter Verwendung von backlog muss Betriebssystem berücksichtigt werden backlog ist nur bei stark belasteten Servern im Weitverkehrsbereich von Bedeutung C. Grimm 4. Juli 2007 Folie 33

34 Verbindungsabbau in Beispiel Folie 38 wird Verbindung über close () abgebaut Versuch zeigt, dass Client sofort nach close () beendet wird Client wartet nicht auf ACK des Servers für die letzten Daten und das FIN send () close () Client wird beendet DATA FIN Daten werden in Receive Buffer geschrieben ACK für DATA und FIN FIN close (), wenn Receive Buffer leer ist ACK für FIN Client t t Server Crash des Servers vor Bearbeitung der letzten Daten wird von Client nicht erkannt daraus folgt, dass close () nicht in dargestellter Weise verwendet werden sollte Frage: wie wird korrekter Verbindungsabbau in TCP sicher gestellt? C. Grimm 4. Juli 2007 Folie 34

35 Socket-Option SO_LINGER mit der Socket-Option SO_LINGER wird Wartezeit l_linger definiert close () wird blockiert, bis ACK für FIN eintrifft oder Timer l_linger abläuft Einheit von l_linger ist in 4.4BSD UNIX 1/100 s, in POSIX.1g UNIX 1 s in BSD UNIX ist l_linger vorzeichenbehafteter 16-Bit Wert, d. h. maximal 32,767 s Client wartet nach close () auf Bestätigung des FIN send () close () blockiert Client wird beendet l_linger DATA FIN ACK für DATA und FIN FIN Daten werden in Receive Buffer geschrieben close (), wenn Receive Buffer leer ist ACK für FIN Client t t Server Achtung SO_LINGER löst eigentliches Problem noch nicht! C. Grimm 4. Juli 2007 Folie 35

36 Verbindungsabbau mit shutdown () mit shutdown () wird eine Verbindung partiell beendet shutdown ( sockfd, SHUT_WR ): schließt schreibenden Teil der Verbindung shutdown ( sockfd, SHUT_RD ): schließt lesenden Teil der Verbindung ein folgendes read () blockiert bis zum Empfang weiterer Daten durch close () auf Server wird FIN an Client gesendet FIN zeigt Socket auf Client an, dass Server keine weiteren Daten sendet read () bricht ab, Client kann beendet werden send () shutdown (, SHUT_WR ) read () DATA FIN Daten werden in Receive Buffer geschrieben blockiert read () kehrt zurück, Client wird beendet ACK für DATA und FIN FIN ACK für FIN close (), wenn Receive Buffer leer ist Client t t Server C. Grimm 4. Juli 2007 Folie 36

37 Blocking I/O blockierende Funktionen kehren nach dem Aufruf nicht unmittelbar zurück, sondern warten auf ein Ereignis der zugehörige Prozess wird vom Kernel in den so genannten Sleep Mode gesetzt Auswahl blockierender Socket-Funktionen Input: read (), recv (), recvfrom () warten auf empfangene Daten für TCP ggf. einzelne Bytes aus einem TCP-Segment für UDP bis ein vollständiges UDP-Datagramm empfangen wird Output: write (), send (), sendto () warten, dass Daten geschrieben werden können (evtl. kein freier Socket-Buffer verfügbar) gilt nur für TCP, UDP blockiert sendto () nicht! Annahme eingehender Verbindungen: accept () wartet so lange, bis Request von Client gesendet und angenommen wird gilt nur für TCP Aufbau einer Verbindung: connect () sendet unmittelbar nach Aufruf SYN an Server (Übergang in Zustand SYN_SENT) wartet, bis Server SYN-ACK sendet d. h. mindestens eine RTT gilt nur für TCP C. Grimm 4. Juli 2007 Folie 37

38 Vermeidung von Blocking I/O Ziele Wartezeit für sinnvolle Aufgaben verwenden kein Zeitverlust, wenn auf Ereignisse unnötig gewartet wird dadurch in der Regel bessere Performance besonders wichtig für Server-Prozesse typische Fragen wann werden Daten empfangen bzw. wann enthält Buffer Daten? wann können Daten gesendet werden bzw. wann werden Daten in Buffer geschrieben? allgemein: wann kehren die ursprünglich blockierenden Funktionen zurück? Überlegung für Funktion recvfrom () eine Empfangs-Operation besteht im Betriebssystem aus zwei Phasen 1. Übergabe der Daten von dem Netzwerk-Interface an den Kernel 2. Kopieren der Daten aus dem Kernel an den Prozess der Empfang der Daten im Netzwerk-Interface wird durch die Hardware gesteuert ist deshalb für Betriebssystem im eigentlichen Sinne nicht sichtbar C. Grimm 4. Juli 2007 Folie 38

39 I/O-Modelle in UNIX UNIX sieht generell 5 verschiedene Modelle für I/O-Operationen vor Blocking I/O (s. o.) Nonblocking I/O blockierende Funktion wird durch fcntl () in nonblocking Mode gesetzt Funktion wird wiederholt aufgerufen, bis Ergebnis vorliegt zwischen den Aufrufen können andere Funktionen ausgeführt werden I/O multiplexing Anwendung initialisiert einen Pool von Sockets (s. u. Beispiel inetd) mit den Funktionen select () oder poll () werden daraus gezielt Sockets ausgewählt typisch werden die Sockets ausgewählt, für die Daten vorliegen Sockets blockieren sich nicht gegenseitig, d. h. sehr gut für parallele Verbindungen geeignet andere Funktionen können jedoch nicht ausgeführt werden Signal driven I/O Anwendung initialisiert SIGIO Signal-Handle im Betriebssystem Anwendung wird vom Betriebssystem über Signal SIGIO informiert, wenn Daten vorliegen Anwendung kann währenddessen beliebige Funktionen ausführen sobald Anwendung Signal SIGIO vom Betriebssystem erhält, wird recvfrom () aufgerufen Asynchronous I/O (aio_functions) in Posix.1 realtime extensions von 1993 spezifiziert kaum verbreitet, bisher nicht für Sockets implementiert C. Grimm 4. Juli 2007 Folie 39

40 Blocking I/O Anwendung recvfrom () system call Kernel no datagram ready 1. Phase Warten auf Daten Prozess blockiert datagram ready copy datagram process datagram return data copy complete 2. Phase Kopieren der Daten von Kernel an Prozess C. Grimm 4. Juli 2007 Folie 40

41 Nonblocking I/O Anwendung recvfrom () system call EWOULDBLOCK Kernel no datagram ready Prozess ruft recvfrom () so lange auf, bis Ergebnis > 0 ist recvfrom () recvfrom () recvfrom () system call EWOULDBLOCK system call EWOULDBLOCK system call no datagram ready no datagram ready datagram ready copy datagram 1. Phase Warten auf Daten process datagram return data copy complete 2. Phase Kopieren der Daten von Kernel an Prozess C. Grimm 4. Juli 2007 Folie 41

42 I/O Multiplexing Anwendung Kernel Prozess wartet auf einen beliebigen von mehreren geöffneten Sockets select () system call no datagram ready 1. Phase Warten auf Daten return readable datagram ready Prozess blockiert, während Daten an Anwendung kopiert werden recvfrom () process datagram system call return data copy datagram copy complete 2. Phase Kopieren der Daten von Kernel an Prozess C. Grimm 4. Juli 2007 Folie 42

43 Signal driven I/O Anwendung init SIGIO signal handler sigaction () system call return Kernel Prozess wird ungehindert weiter bearbeitet 1. Phase Warten auf Daten signal handler deliver SIGIO datagram ready Prozess blockiert, während Daten an Anwendung kopiert werden recvfrom () process datagram system call return data copy datagram copy complete 2. Phase Kopieren der Daten von Kernel an Prozess C. Grimm 4. Juli 2007 Folie 43

44 Asynchronous I/O Anwendung aio_read () system call return Kernel no datagram ready 1. Phase Warten auf Daten Prozess wird unbehindert weiter bearbeitet datagram ready copy datagram signal handler process datagram sendet das durch aio_read () spezifizierte Signal copy complete 2. Phase Kopieren der Daten von Kernel an Prozess C. Grimm 4. Juli 2007 Folie 44

45 Vergleich der I/O-Modelle für recvfrom () Blocking Nonblocking I/O Multiplexing Signal-driven I/O Asynchronous I/O initiate blocked check check check check check check check check check check blocked ready notification initiate 1. Phase Warten auf Daten blocked initiate blocked initiate blocked 2. Phase Kopieren der Daten von Kernel an Prozess complete complete complete complete notification 1. Phase wird verschieden behandelt, 2. Phase wird gleich behandelt, da recvfrom () stets blockiert behandelt beide Phasen C. Grimm 4. Juli 2007 Folie 45

46 Design von Server-Applikationen Merkmale für Implementierung von Servern stateful oder stateless connectionless oder connection oriented iterative oder concurrent Stateful Server Zustandsinformationen werden über mehrere Übertragungsvorgänge gespeichert Probleme Clients können zu unerwarteten Zeitpunkten aus- und eingeschaltet werden durch Fehler im Netz können zu unerwarteten Zeitpunkten Daten verloren oder vervielfacht werden Speicherung des Status erfordert hohen Aufwand auf Server i. d. R. über Datenbanken sorgfältige Berücksichtigung von Fehlern erfordert hohen Aufwand auf Client und Server s. RPC in RNII Teil 12 Stateless Server die typische Server-Implementierung im Internet jeder Übertragungsvorgang wird von Verbindungsauf- und Abbau begrenzt dabei ist es egal, ob ein einzelnes Objekt oder eine Reihe von Objekten (z. B. Persistent Connections über HTTP) übertragen wird C. Grimm 4. Juli 2007 Folie 46

47 Design von Server-Applikationen Connectionless Server typisch im Internet über UDP geringer Overhead, d. h. hohe Performance keine Sicherheit darüber, ob Daten korrekt übertragen werden unkritische (Echtzeit-)Anwendungen im LAN sowie periodische oder Broadcast-Dienste u. a. NFS, DNS, NTP, RTP, DHCP theoretisch keine Begrenzung der Anzahl gleichzeitiger Clients alle Daten werden über denselben Socket-Deskriptor empfangen eine Trennung der Clients muss explizit durch Server-Applikation erfolgen Connection oriented Server typisch im Internet über TCP Verbindungs-Management wird vom Betriebssystem übernommen durch notwendigen Overhead geringere Performance Sicherheit darüber, ob Daten korrekt übertragen werden oder ob Fehler auftreten typisch für zeitunkritische Datendienste im WAN u. a. HTTP, SMTP, IMAP, FTP, SSH, FTP jede Verbindung benötigt einen eigenen Socket, d. h. ist über Deskriptor identifizierbar Trennung der Clients erfolgt implizit durch das Betriebssystem daraus folgt limitierte Anzahl gleichzeitig zu bearbeitender Clients C. Grimm 4. Juli 2007 Folie 47

48 Design von Server-Applikationen Iterative Server Server-Applikation kann nur jeweils eine Verbindung bearbeiten typisch für einfache TCP-Server empfangene Requests müssen warten, bis aktuelle Verbindung abgebaut wird blockierender Server ggf. werden eingehende Requests abgewiesen, solange ein Request bearbeitet wird Concurrent Server der eigentliche Server-Prozess nimmt lediglich Requests entgegen der Server-Prozess startet für jede Verbindung einen Kind-Prozess Request wird an Kind-Prozess übergeben und dort verarbeitet nach Abbau der Verbindung wird Kind-Prozess beendet hohe Performance durch parallele Bearbeitung mehrerer Verbindungen typisch für TCP-Server mit mehreren gleichzeitigen Verbindungen WWW, FTP, P2P jeder Kind-Prozess belegt zusätzliche System-Ressourcen C. Grimm 4. Juli 2007 Folie 48

49 Implementierung Concurrent Server klassische Variante unter UNIX durch fork () wird Kind-Prozess gestartet in TCP-basiertem Server wird fork () nach accept ()aufgerufen in UDP-basiertem Server wird fork () nach recvfrom () aufgerufen fork () ist nicht geeignet für hohe Performance besser prefork () d Server Anwendung startet auf Vorrat mehrere Kind-Prozesse eingehende Requests werden an Kind-Prozesse verteilt Kind-Prozesse werden nach Verbindungsabbau nicht beendet bei Bedarf werden zusätzliche Kind-Prozesse gestartet Beispiel: WWW-Server Apache Version 1.x moderne Alternative: Threads für jede Verbindung wird ein Thread gestartet schneller als fork () und geringerer Verbrauch von Ressourcen einfacher Austausch von Informationen zwischen verschiedenen Threads auch prethreaded Server möglich C. Grimm 4. Juli 2007 Folie 49

50 Daemon Processes Ziel: Server-Prozesse sollen im Hintergrund laufen und keine anderen Prozesse stören durch keine anderen Prozesse gestört werden unabhängig von Eingaben an der Konsole bzw. Terminals laufen automatisch beim Hochfahren des Systems gestartet werden Lösung: Daemon Processes laufen im Hintergrund ab erwarten keine Eingaben senden Logging- bzw. Debug-Informationen an syslogd ein eigener Daemon typische Anwendungen für Daemons Server-Prozesse (WWW-Server, FTP-Server) Durchführung administrativer Aufgaben auf einem System hier nicht von Interesse Start von Daemons cron startet Daemon periodisch zu vorgegebenen Zeitpunkten at startet Daemon einmalig zu einem vorgegebenen Zeitpunkt inetd der Internet Superserver, startet Daemon bei eingehendem Request C. Grimm 4. Juli 2007 Folie 50

51 Daemon Processes Prozess-Tabelle auf einem UNIX-System (fett: Daemon Processes) UID PID PPID C STIME TTY TIME CMD root Feb 23? 0:01 sched root Feb 23? 0:10 /etc/init - root Feb 23? 0:00 pageout root Feb 23? 198:00 fsflush root Feb 23? 0:00 /usr/lib/saf/sac -t 300 root May 02? 2:25 /usr/local/sbin/sshd root Feb 23? 0:00 /usr/lib/sysevent/syseventd root Feb 23? 0:00 /usr/lib/saf/ttymon root Feb 23? 0:02 /usr/sbin/syslogd root Feb 23? 0:00 /usr/sbin/cron root Feb 23? 0:00 /usr/lib/utmpd root Feb 23? 0:00 /usr/sbin/mdmonitord grimm :46:10 pts/1 0:00 ps -ef root Feb 24? 0:01 /usr/lib/inet/xntpd grimm :45:51? 0:00 /usr/local/sbin/sshd grimm :45:51 pts/1 0:00 -sh root :45:48? 0:00 /usr/local/sbin/sshd C. Grimm 4. Juli 2007 Folie 51

52 inetd der Internet Superserver Problem für jeden Service muss ein einzelner Prozess gestartet werden jeder Prozess startet u. U. eine Reihe von Kind-Prozessen hoher Bedarf an Ressourcen, die u. U. nicht genutzt werden Lösung: inetd der Daemon inetd sammelt eingehende Requests auf verschiedenen Ports startet entsprechendend den Ports die jeweiligen Anwendungen seit 4.3 BSD UNIX ist inetd Bestandteil des Betriebssystems inetd wird oft als potentieller Angriffspunkt angesehen häufig sind es allerdings die Anwendungen, die durch inetd gestartet werden Überlauf der Prozesstabelle durch Denial of Service Angriffe auf abgesicherten Systemen sollte kein inetd gestartet werden Verbesserung in aktuellen Betriebssystemen: xinetd C. Grimm 4. Juli 2007 Folie 52

53 Konfiguration inetd inetd liest beim Start Konfiguration aus Datei /etc/inetd.conf ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd name dgram udp wait root /usr/sbin/in.tnamed in.tnamed shell stream tcp nowait root /usr/sbin/in.rshd in.rshd login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot Ablauf inetd öffnet bei Initialisierung Socket für jeden aufgeführten Dienst (Port!) ftpd telnetd rlogind tftpd. Konfiguration aus /etc/inetd.conf bei Initialisierung inetd Aufruf durch fork () oder exec () Requests auf verschiedene Ports C. Grimm 4. Juli 2007 Folie 53

54 Einträge in /etc/inetd.conf die Datei /etc/inetd.conf besteht auf aus sieben Spalten ftp stream tcp nowait root /usr/sbin/ftpd ftpd -l tftp dgram udp wait root /usr/sbin/tftpd tftpd s /tftpboot service-name: Name des Dienstes gleich lautender Eintrag wird in der Datei /etc/services gesucht, um Port zu ermitteln socket-type: stream für TCP und dgram für UDP protocol: TCP oder UDP ursprünglich auch für IP vorgesehen, jetzt auch TCP6 und UDP6 für IPv6 wait-flag (s. u.) login-name: Benutzer, unter dessen Rechten der Prozess gestartet wird server-program: das zu startende Programm inklusive Pfad server-program-arguments: Name des Programms inklusive Argumenten Bedeutung des wait-flag nowait: concurrent Server, d. h. parallele Bearbeitung von Requests (typisch für TCP) wait: iterativer Server, d. h. sequentielle Bearbeitung von Requests (typisch für UDP) inetd lehnt eingehende Requests ab, bis laufender Server beendet wird theoretisch ist auch TCP mit wait und UDP mit nowait möglich C. Grimm 4. Juli 2007 Folie 54

55 Ablaufdiagramm inetd inetd socket () Initialisierung Betrieb bind () if TCP: listen () select () if TCP: accept () fork () if TCP: close connected socket für jeden Dienst in /etc/inetd.conf Kind-Prozess von inetd schließe alle Deskriptoren außer Socket für Dienst erzeuge Deskriptoren 0, 1, 2 schließe socket für Dienst if user root: setgid (), setusid () exec () Dienst C. Grimm 4. Juli 2007 Folie 55

56 Literatur W. R. Stevens. UNIX Network Programming. Prentice Hall, 1998 C. Grimm 4. Juli 2007 Folie 56

57 Übersicht Performance von TCP Socket-Buffer und MTU alternative Varianten von TCP TCP-Highspeed und TCP-BIC Socket-Programmierung Ergänzung listen () Verbindungsabbau in TCP I/O-Modelle in UNIX Design von Servern Daemon Processes inetd C. Grimm 4. Juli 2007 Folie 57